From owner-freebsd-arm@FreeBSD.ORG Sun Feb 23 00:42:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40FC3816 for ; Sun, 23 Feb 2014 00:42:05 +0000 (UTC) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 03D231DB1 for ; Sun, 23 Feb 2014 00:42:04 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i7so2683700oag.16 for ; Sat, 22 Feb 2014 16:42:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oKVugfEwkELmzb6Sd/RL6Jqj3JXYkzPtq8Clm40EGQM=; b=W++QbWSkDd9YmRjsTsCKu+Q1niOjyOcjKLTnQ6+nLu1Uq/ua9gF/HyrfPdOgVWoSdR eSu4u3XnL6u6fZgo4tOOmQg8sWpxh5UdUPa45jXHOOMDK0Is1l78IgpK6andQ7sRBBaC Poaok0NszHKbeiV59tK/+pat9tWsrlX2t6exDSwY0IRqGKGzikd7gPsnnr7F1JwYzG36 x9Fzv+9ciNtvwxxGBJBIqTQfzMvsLLscYxCvw8RvN1tPaQbPBzWVDJw+nERzyrDeKABQ cnLqhwvFNHmEXHaJuLUw5LbqVp35bDcOctxcflxb6YCIQspQO0v03L3Uy3Pjn+YQ3BVP gwpQ== X-Gm-Message-State: ALoCoQk6Ol6q5W35ZaqFc9sN9okWS13g5J49vxw3GJcfQCggGUAeGbQwHucW8i0AN3SXzO5RXgTQ MIME-Version: 1.0 X-Received: by 10.60.92.202 with SMTP id co10mr16038434oeb.73.1393116124105; Sat, 22 Feb 2014 16:42:04 -0800 (PST) Received: by 10.182.165.167 with HTTP; Sat, 22 Feb 2014 16:42:04 -0800 (PST) X-Originating-IP: [2001:44b8:31b0:aa00:c685:8ff:fe35:3e2d] In-Reply-To: <53077971.8060406@gmail.com> References: <87ob2gxfg0.fsf@gmail.com> <1392997297.1145.88.camel@revolution.hippie.lan> <53077971.8060406@gmail.com> Date: Sun, 23 Feb 2014 11:42:04 +1100 Message-ID: Subject: Re: Beaglebone Black: crash during portsnap extract From: Jason Birch To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 00:42:05 -0000 > > What this doesn't explain is why it's getting a timeout in the first > place. No single sdcard transaction is supposed to take longer than 250 > milliseconds according to the SD spec. Henryk notes that this doesn't occur when just copying the tree around -- although that'll be many smaller files instead of one big one. I wonder if it's specifically happening in conjunction with bsdtar -- I'll try and contrive a testcase later this afternoon. I fixed > that in r261983, which does a lighter-weight reset that may let the > controller recover and subsequent retries will work. I'll give that a shot a little later. Thanks! JB From owner-freebsd-arm@FreeBSD.ORG Sun Feb 23 02:20:19 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1CA74AE; Sun, 23 Feb 2014 02:20:19 +0000 (UTC) Received: from mx0.deglitch.com (unknown [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5577A1695; Sun, 23 Feb 2014 02:20:19 +0000 (UTC) Received: from [192.168.5.42] (ip-64-134-239-19.public.wayport.net [64.134.239.19]) by mx0.deglitch.com (Postfix) with ESMTPSA id 1629C8FC40; Sun, 23 Feb 2014 06:20:08 +0400 (MSK) References: <1393010014.1145.137.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <1393010014.1145.137.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <85093695-0F2C-4D88-985F-6C150A03D330@FreeBSD.org> X-Mailer: iPad Mail (11B554a) From: Stanislav Sedov Subject: Re: u-boot-2014.01 and freebsd arm Date: Sat, 22 Feb 2014 18:20:02 -0800 To: Ian Lepore Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 02:20:19 -0000 > On Feb 21, 2014, at 11:13 AM, Ian Lepore wrote: >=20 > I haven't tried the newer u-boot on my other boards yet (BBW, rpi). >=20 > If anyone feels like doing a bit of work on u-boot, I think it would be > great if we could get FFS support into u-boot so that we can boot from a > disk image that doesn't need an msdos partition just to hold ubldr. > There is a patchset for this that no longer applies cleanly (at least to > 2014.01, I haven't tried earlier versions). It's available at > http://www.springdaemons.com/stas/u-boot-ffs.patch if anyone wants to > give it a shot. I'll give a shot in porting my patch to the latest uboot tonight. I'll need= to get latest uboot working on my board first though, but the changes themselves should be easy to port. -- ST4096-RIPE= From owner-freebsd-arm@FreeBSD.ORG Sun Feb 23 02:21:55 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57F864F1; Sun, 23 Feb 2014 02:21:55 +0000 (UTC) Received: from mx0.deglitch.com (unknown [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 06DB316FA; Sun, 23 Feb 2014 02:21:55 +0000 (UTC) Received: from [192.168.5.42] (ip-64-134-239-19.public.wayport.net [64.134.239.19]) by mx0.deglitch.com (Postfix) with ESMTPSA id 5221C8FC40; Sun, 23 Feb 2014 06:21:41 +0400 (MSK) References: <1393010014.1145.137.camel@revolution.hippie.lan> <5308C9F7.5090300@FreeBSD.org> Mime-Version: 1.0 (1.0) In-Reply-To: <5308C9F7.5090300@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (11B554a) From: Stanislav Sedov Subject: Re: u-boot-2014.01 and freebsd arm Date: Sat, 22 Feb 2014 18:21:31 -0800 To: Kevin Lo Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 02:21:55 -0000 > On Feb 22, 2014, at 8:01 AM, Kevin Lo wrote: > > It seems that there is a license issue preventing integration of > UFS support into U-Boot's source. See all discussion threads: > http://marc.info/?t=127792848100003&r=1&w=2 That was one of the reasons it didn't go to the main tree. I feel that we should try again as it seems that uboot might be more liberal with licenses now. -- ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Sun Feb 23 15:58:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA3467CF for ; Sun, 23 Feb 2014 15:58:10 +0000 (UTC) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B59318D9 for ; Sun, 23 Feb 2014 15:58:10 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id hz1so5478436pad.36 for ; Sun, 23 Feb 2014 07:58:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zZ3rTkJm3w/gwf3zpZmGCR0G+mX3mNxg3BErZHcekuM=; b=QD3LHCl7ITaiKgH0BZw6DXSeki7FE1VLgFDFbGzZ0+hlb0uxFsDOXzxD750BTcV7Ur CAIHIIlsS1TTfNpnANzZZcgV+TX6WsrsKRuanzwfPx4oHsC8N6LZfcK7D0aeqBpufhA0 rXVmE+qUC+qgQ3urPU01uF2vJGxoETcwJ5skQo669YHHlbWNg4V6oVDVKEic7mCbxzey INdTs0t/KmgZgySPblOK8j0nz4NQjSQCBvGcpdXLXYepKleamSyNBiAfQTvlqQDOYzQ/ LD7b3Y8IwaZR/HHRaXkeLp4wWTS7fIDUgiE7nJGDlfCZ2Bd1y9+dplGbFf+lOiJb8Ma3 ZNzw== X-Gm-Message-State: ALoCoQlGqRxxfm+jD1crjfrJRt3puw5oL16Ht/ENvhJEKZ50RywVRMrnycEDVTVYevxSO7VhmvG7 X-Received: by 10.66.122.201 with SMTP id lu9mr19779060pab.40.1393171084194; Sun, 23 Feb 2014 07:58:04 -0800 (PST) Received: from macmini.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ns7sm41267806pbc.32.2014.02.23.07.58.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Feb 2014 07:58:03 -0800 (PST) Subject: Re: u-boot-2014.01 and freebsd arm Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 23 Feb 2014 08:58:01 -0700 Content-Transfer-Encoding: 7bit Message-Id: <516E59B4-E242-457D-9BA9-547D08BEBEF1@bsdimp.com> References: <1393010014.1145.137.camel@revolution.hippie.lan> <5308C9F7.5090300@FreeBSD.org> To: Stanislav Sedov X-Mailer: Apple Mail (2.1085) Cc: Kevin Lo , freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 15:58:10 -0000 On Feb 22, 2014, at 7:21 PM, Stanislav Sedov wrote: > >> On Feb 22, 2014, at 8:01 AM, Kevin Lo wrote: >> >> It seems that there is a license issue preventing integration of >> UFS support into U-Boot's source. See all discussion threads: >> http://marc.info/?t=127792848100003&r=1&w=2 > > That was one of the reasons it didn't go to the main tree. I feel that > we should try again as it seems that uboot might be more liberal > with licenses now. Also, the objections seemed fairly bogus... Warner From owner-freebsd-arm@FreeBSD.ORG Mon Feb 24 11:06:45 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D835A62 for ; Mon, 24 Feb 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E5274160C for ; Mon, 24 Feb 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1OB6iKs027441 for ; Mon, 24 Feb 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1OB6ixl027439 for freebsd-arm@FreeBSD.org; Mon, 24 Feb 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Feb 2014 11:06:44 GMT Message-Id: <201402241106.s1OB6ixl027439@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 11:06:45 -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/186823 arm icu port won't compile on Raspberry Pi o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/180080 arm Unmapped buffers on ARMv7 big-RAM boards o arm/179688 arm [patch] [rpi] serial console eats some characters at m o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o ports/175605 arm please fix build binutils-2.23.1 in raspberry pi 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 ports/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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 35 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 24 12:13:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1847B31 for ; Mon, 24 Feb 2014 12:13:40 +0000 (UTC) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 854081DAE for ; Mon, 24 Feb 2014 12:13:40 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id i11so292803oag.9 for ; Mon, 24 Feb 2014 04:13:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=D1aT+dgkBw1/tJkx4V4uziJicuxgtUjLXj60VAblCgk=; b=HX11SALcT6JKRH7mgoZENFZi1R/bUuIOvVdaczD2/5hNFMYqKtuBWaPH67cWBBL2ZC Q59r3gkh2C6lfdKe420J43RUfw0yj1Ut3b/l7conmfG4JIPsZUuJlJAnAjDkpbDizTQI zLByE0I73rnZtVLUuiXrkT5x+6NLEXSDi+5triaLeYu2CaurzRie44Ay2ODTOxPi7rcT 027hloBrIbJIYLj90sNNO6veoek0sK3fryrih/vFYHLAQDqAShypFP2SB9fR0z2sgAQL /cmf6VkF7psZITltysNtehZnNRedJX5n/cc3+/1c3eme6o7mw7Tf40oJ1ljyoXqxR3l8 TFUw== X-Gm-Message-State: ALoCoQktZywzg1UW84BYJz4v3Pw8e7KENXe6rZmVSNkIFJYXFVmnEAWFdyFpxTUPBF7tNkcVXfe6 MIME-Version: 1.0 X-Received: by 10.60.94.175 with SMTP id dd15mr21227544oeb.56.1393244012875; Mon, 24 Feb 2014 04:13:32 -0800 (PST) Received: by 10.182.165.167 with HTTP; Mon, 24 Feb 2014 04:13:32 -0800 (PST) X-Originating-IP: [2001:44b8:31b0:aa00:c685:8ff:fe35:3e2d] In-Reply-To: References: <87ob2gxfg0.fsf@gmail.com> <1392997297.1145.88.camel@revolution.hippie.lan> <53077971.8060406@gmail.com> Date: Mon, 24 Feb 2014 23:13:32 +1100 Message-ID: Subject: Re: Beaglebone Black: crash during portsnap extract From: Jason Birch To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 12:13:40 -0000 > > Henryk notes that this doesn't occur when just copying the tree around -- > although that'll be many smaller files instead of one big one. I wonder if > it's specifically happening in conjunction with bsdtar -- I'll try and > contrive a testcase later this afternoon. I can't trigger this as a non-privileged user. I can reliably trigger this by a simple `tar xf /var/db/portsnap/.tgz` as root. I'm taking r262372 for a spin now (Which of course includes your r261983), and have been able to successfully extract the ports tree as root without being dumped into ddb. Though... I have been sitting here waiting for the snapshot verification for quite a while, but that's another story. The only thing untoward I see is that UFS lock order reversal... lock order reversal: 1st 0xc2f73394 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101 2nd 0xcd25c3c8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xc2f93934 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101 ... but I think that's well known at this point and isn't a cause for my concern. Thanks Ian! From owner-freebsd-arm@FreeBSD.ORG Mon Feb 24 13:26:19 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BDADD14; Mon, 24 Feb 2014 13:26:19 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3841C15A4; Mon, 24 Feb 2014 13:26:18 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 09260B836; Mon, 24 Feb 2014 15:26:15 +0200 (SAST) Date: Mon, 24 Feb 2014 15:26:14 +0200 From: John Hay To: Ian Lepore Subject: Re: status of AVILA and CAMBRIA code Message-ID: <20140224132614.GA31984@zibbi.meraka.csir.co.za> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com> <20140221130530.GA202@zibbi.meraka.csir.co.za> <1393001249.1145.98.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393001249.1145.98.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 13:26:19 -0000 Hi Ian, On Fri, Feb 21, 2014 at 09:47:29AM -0700, Ian Lepore wrote: > On Fri, 2014-02-21 at 15:05 +0200, John Hay wrote: > > On Wed, Feb 19, 2014 at 09:29:38AM -0800, John-Mark Gurney wrote: > > > John Hay wrote this message on Wed, Feb 19, 2014 at 12:59 +0200: > > > > What is the status of AVILA and CAMBRIA builds in our tree? Have anybody > > > > had success recently? From the lists I can see that other people have > > > > also asked in September 2013, but I cannot figure out if there was any > > > > successes at that stage. :-) > > ... > > > > > > > > Somewhere along the line the ethernet npe0 device also broke, writing > > > > "npe0: npestart_locked: too many fragments 0". But I did not test the > > > > npe0 device with every build and only realised it this morning, so I > > > > do not know where it broke. :-) > > > > > > Not sure about these issues... > > > > Ok, I found the place. It is svn 246713 by kib: > > > > ########### > > Reform the busdma API so that new types may be added without modifying > > every architecture's busdma_machdep.c. It is done by unifying the > > bus_dmamap_load_buffer() routines so that they may be called from MI > > code. The MD busdma is then given a chance to do any final processing > > in the complete() callback. > > > > The cam changes unify the bus_dmamap_load* handling in cam drivers. > > > > The arm and mips implementations are updated to track virtual > > addresses for sync(). Previously this was done in a type specific > > way. Now it is done in a generic way by recording the list of > > virtuals in the map. > > > > Submitted by: jeff (sponsored by EMC/Isilon) > > Reviewed by: kan (previous version), scottl, > > mjacob (isp(4), no objections for target mode changes) > > Discussed with: ian (arm changes) > > Tested by: marius (sparc64), mips (jmallet), isci(4) on x86 (jharris), > > amd64 (Fabian Keil > > ########### > > > > After that tx packets will cause this message: > > npe0: npestart_locked: too many fragments. > > > > Then updating to 246881 by ian: > > > > ############# > > In _bus_dmamap_addseg(), the return value must be zero for error, or the size > > actually added to the segment (possibly smaller than the requested size if > > boundary crossings had to be avoided). > > ############# > > > > This makes it a bit better in that some packets seem to go through. It > > looks like 3 out of 4 will go out and the forth will cause the same > > message as above. > > > > I have added a printf just above bus_dmamap_load_mbuf_sg() in > > npestart_locked() to show some of the mbuf values: > > > > ############ > > npe0: npestart_locked: m_len 42, data 0xc0d3dcd6, next 0 > > [...] > > ############ > > > > Any ideas? > > > > John > > I can't see the path through the busdma code that leads to that result. > It looks like there are two ways the mapping can fail, maybe it would > help to know which path it's taking. In arm/busdma_machdep.c the two > error paths out of the mapping loop are at lines 1066 and 1077, could > you try putting printfs at those locations so we know which case is > happening? Maybe printing some of the values involved with taking those > exits would be helpful too. > > Maybe also check for map->sync_count being non-zero on entry to > _bus_dmamap_load_buffer() and print something if it is. The printfs you > did earlier make it look like there's never actually a second mbuf > chained off the first (which makes sense for such small packets), I > think that number should always be zero on entry because the outer loop > in kern/subr_bus_dma.c should only ever run once. Ok, here is the patch I used to add printfs to arm/busdma_machdep.c ################### Index: arm/busdma_machdep.c =================================================================== --- arm/busdma_machdep.c (revision 246713) +++ arm/busdma_machdep.c (working copy) @@ -1008,6 +1008,8 @@ vm_offset_t vaddr = (vm_offset_t)buf; int error = 0; + if (map->sync_count != 0) + printf("_bus_dmamap_load_buffer: map->sync_count %d\n", map->sync_count); if (segs == NULL) segs = dmat->segments; if ((flags & BUS_DMA_LOAD_MBUF) != 0) @@ -1052,8 +1054,10 @@ sl = &map->slist[map->sync_count - 1]; if (map->sync_count == 0 || vaddr != sl->vaddr + sl->datacount) { - if (++map->sync_count > dmat->nsegments) + if (++map->sync_count > dmat->nsegments) { + printf("_bus_dmamap_load_buffer: map->sync_count %d, dmat->nsegments %d\n", map->sync_count, dmat->nsegments); goto cleanup; + } sl++; sl->vaddr = vaddr; sl->datacount = sgsize; @@ -1064,6 +1068,8 @@ sgsize = _bus_dmamap_addseg(dmat, map, curaddr, sgsize, segs, segp); if (sgsize == 0) + printf("_bus_dmamap_load_buffer: sgsize == 0, dmat flags %x\n", dmat->flags); + if (sgsize == 0) break; vaddr += sgsize; buflen -= sgsize; @@ -1075,6 +1081,7 @@ */ if (buflen != 0) { _bus_dmamap_unload(dmat, map); + printf("_bus_dmamap_load_buffer: buflen %jd\n", (intmax_t)buflen); return (EFBIG); /* XXX better return value here? */ } return (0); ################### The result looks like this. With printfs in _bus_dmamap_load_buffer(), we also see messages for the receive side. ################### ping 146.64.5.1 PING 146.64.5.1 (146.64.5.1): 56 data bytes npe0: npestart_locked: m_len 98, data 0xc0d3ed66, next 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=0 ttl=64 time=9.089 ms npe0: npestart_locked: m_len 98, data 0xc0d3ea66, next 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=1 ttl=64 time=9.262 ms npe0: npestart_locked: m_len 98, data 0xc0d3e766, next 0 _bus_dmamap_load_buffer: map->sync_count 2 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=2 ttl=64 time=9.291 ms npe0: npestart_locked: m_len 98, data 0xc0d3e466, next 0 _bus_dmamap_load_buffer: map->sync_count 3 _bus_dmamap_load_buffer: map->sync_count 4, dmat->nsegments 3 _bus_dmamap_load_buffer: buflen 98 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 98, data 0xc0d3e366, next 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=4 ttl=64 time=5.494 ms npe0: npestart_locked: m_len 98, data 0xc0d3e066, next 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=5 ttl=64 time=9.294 ms npe0: npestart_locked: m_len 98, data 0xc0d3dc66, next 0 _bus_dmamap_load_buffer: map->sync_count 2 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=6 ttl=64 time=9.323 ms npe0: npestart_locked: m_len 98, data 0xc0d3d966, next 0 _bus_dmamap_load_buffer: map->sync_count 3 _bus_dmamap_load_buffer: map->sync_count 4, dmat->nsegments 3 _bus_dmamap_load_buffer: buflen 98 npe0: npestart_locked: too many fragments 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 npe0: npestart_locked: m_len 98, data 0xc0d3d866, next 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=8 ttl=64 time=5.509 ms npe0: npestart_locked: m_len 98, data 0xc0d3d566, next 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=9 ttl=64 time=9.316 ms npe0: npestart_locked: m_len 98, data 0xc0d3d266, next 0 _bus_dmamap_load_buffer: map->sync_count 2 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=10 ttl=64 time=9.266 ms npe0: npestart_locked: m_len 98, data 0xc0d3d166, next 0 _bus_dmamap_load_buffer: map->sync_count 3 _bus_dmamap_load_buffer: map->sync_count 4, dmat->nsegments 3 _bus_dmamap_load_buffer: buflen 98 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 98, data 0xc0d3d066, next 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=12 ttl=64 time=5.469 ms npe0: npestart_locked: m_len 98, data 0xc0d3d366, next 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=13 ttl=64 time=9.276 ms npe0: npestart_locked: m_len 98, data 0xc0d3d666, next 0 _bus_dmamap_load_buffer: map->sync_count 2 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=14 ttl=64 time=9.302 ms npe0: npestart_locked: m_len 98, data 0xc0d3db66, next 0 _bus_dmamap_load_buffer: map->sync_count 3 _bus_dmamap_load_buffer: map->sync_count 4, dmat->nsegments 3 _bus_dmamap_load_buffer: buflen 98 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 98, data 0xc0d3da66, next 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=16 ttl=64 time=5.484 ms npe0: npestart_locked: m_len 98, data 0xc0d3dd66, next 0 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 1 _bus_dmamap_load_buffer: map->sync_count 2, dmat->nsegments 1 _bus_dmamap_load_buffer: buflen 1536 64 bytes from 146.64.5.1: icmp_seq=17 ttl=64 time=9.306 ms ################### Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Mon Feb 24 14:26:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B48166F; Mon, 24 Feb 2014 14:26:51 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id ABAE31BA8; Mon, 24 Feb 2014 14:26:50 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 3B8583F44D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1393252002; bh=6CIRyxWYv6u7fuXfoH/iTRhHow/o58P5vL9zBSupLsM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=w8huPsoXRDG6WC5NGsyg9F0HzeHACq3ZSuN4addMzp3mnS/mU6sHvRYeA+dMyeHqF IMQobQWqnO7pM19zBgvjsMDVnb5LIfXhLAKRc4VpemQTbZzNRT2qzDYvOpc7zaRt5U YbvpplcgFMR9DHSzUunefdtrY/SALQ7SaKg/NqYI= Date: Mon, 24 Feb 2014 15:26:42 +0100 From: Ilya Bakulin To: Warner Losh Subject: Re: MMC/SDIO stack under CAM Message-ID: <20140224142642.GA32538@olymp.kibab.com> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> Cc: Adrian Chadd , freebsd-hackers@freebsd.org, Alexander Motin , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 14:26:51 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 16, 2014 at 11:05:35AM -0700, Warner Losh wrote: > that's cool! I'd thought of writing a mmcsim that I could use to develop = the stack on x86, but time pressures of my job precluded that (though in hi= nd sight, it would have saved a lot of time). I assume that by "mmcsim" you mean not MMC SIM for CAM, but MMC SIMulator := -) Yeah so essentially it should be able to return some "fake" data to the upper layer, maybe based on configuration (ie 1 GB SD, 16 GB SDHC, .= =2E.). > > For SDIO card, the situation will be different. Essentially, > > we should allow a device driver to send arbitrary messages to the card. > > So the device driver will attach directly to the scbus. > >=20 > > Please let me know your thoughts about it. > > I really want SDIO make its way into the kernel, because there > > is an increasing number of ARM boards on the market that have integrated > > SDIO WLAN on them and we cannot support them fully. >=20 > Generally, I like this idea... I'd be very interested in some of the spe= cifics to make the direct attachment work with SDIO. That's the one area I = either don't think I understand your proposal well enough, or I do and I'm = concerned about it. :) So maybe write a bit more about the details of the S= DIO cards and how they's interact with CAM in this scenario... >=20 > The notion of moving MMC/SD into the CAM stack has been around since I st= arted working on MMC. At the time, CAM was too SCSI centric to do it, but A= lexander Motin's work has generally improved that situation, so it may be p= ossible now to do it and shake out the few dark corners of CAM where this i= sn't the case. I also think it should help performance a lot since we're cu= rrently single threaded to the card (but that's also the nature of the bus)= , which introduces some round-trip latencies between too many threads that = CAM may help us avoid. >=20 > Warner After talking with Alexander about CAM, here is the updated proposal: * All card communication logic should be placed in MMC XPT layer, with the = new CCB type that describes MMC request + some data needed by the system. So almost everything from sys/dev/mmc/mmc.c goes there. * da(4) is a driver for SCSI disks. It makes more sense to adapt mmcsd(4) t= o use CAM. So mmcsd(4) will create CCBs and pass them to CAM layer, getting async no= tifications via standard CAM callback mechanism. * It is possible to write drivers for SDIO devices exactly like adopted mmc= sd(4). Every such driver would be then built as CAM peripheral driver, which mea= ns it will be able to send/receive CCBs. To do that, every driver has to call PERIPHDRIVER_DECLARE() macro, subscr= ibing to CAM "new device found" events. The ongoing work for MMC CAM is here: https://github.com/kibab/freebsd/compare/master...mmccam Not so much stuff here yet. PS: In theory, ssince there is already an existing interface for passing CA= M CCBs between userland and kernel, it WOULD be posssible to create device drivers entirely in userland... Like= microkernel OSes do. But our network stack doesn'have such feature I guess... -- Ilya --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlMLVqAACgkQo9vlj1oadwjVWACg7ZgrzQ4f31Si3XN5p9Y3LLeC N84AoKTada+XSlMYa8t6JVfZVz/zJNx2 =XWE5 -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-arm@FreeBSD.ORG Mon Feb 24 14:40:32 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DA39E51; Mon, 24 Feb 2014 14:40:32 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E54F11DB6; Mon, 24 Feb 2014 14:40:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1OEeVGt002065; Mon, 24 Feb 2014 14:40:31 GMT (envelope-from imp@freefall.freebsd.org) Received: (from imp@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1OEeV1W002064; Mon, 24 Feb 2014 07:40:31 -0700 (MST) (envelope-from imp) Date: Mon, 24 Feb 2014 07:40:31 -0700 (MST) Message-Id: <201402241440.s1OEeV1W002064@freefall.freebsd.org> To: freebsd@damnhippie.dyndns.org, imp@FreeBSD.org, freebsd-arm@FreeBSD.org From: imp@FreeBSD.org Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 14:40:32 -0000 Synopsis: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards State-Changed-From-To: patched->closed State-Changed-By: imp State-Changed-When: Mon Feb 24 07:39:42 MST 2014 State-Changed-Why: This bug has been fixed in 10. http://www.freebsd.org/cgi/query-pr.cgi?pr=155214 From owner-freebsd-arm@FreeBSD.ORG Mon Feb 24 14:41:23 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB119133; Mon, 24 Feb 2014 14:41:23 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B02AB1DC7; Mon, 24 Feb 2014 14:41:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1OEfN2K002152; Mon, 24 Feb 2014 14:41:23 GMT (envelope-from imp@freefall.freebsd.org) Received: (from imp@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1OEfNbF002151; Mon, 24 Feb 2014 07:41:23 -0700 (MST) (envelope-from imp) Date: Mon, 24 Feb 2014 07:41:23 -0700 (MST) Message-Id: <201402241441.s1OEfNbF002151@freefall.freebsd.org> To: loos.br@gmail.com, imp@FreeBSD.org, freebsd-arm@FreeBSD.org From: imp@FreeBSD.org Subject: Re: arm/179688: [patch] [rpi] serial console eats some characters at moutroot prompt X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 14:41:23 -0000 Synopsis: [patch] [rpi] serial console eats some characters at moutroot prompt State-Changed-From-To: open->closed State-Changed-By: imp State-Changed-When: Mon Feb 24 07:41:04 MST 2014 State-Changed-Why: Fixed in head, soon to be fixed in stable... http://www.freebsd.org/cgi/query-pr.cgi?pr=179688 From owner-freebsd-arm@FreeBSD.ORG Mon Feb 24 15:18:03 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2052E304; Mon, 24 Feb 2014 15:18:03 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA6DD121A; Mon, 24 Feb 2014 15:18:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1OFI2Tg014722; Mon, 24 Feb 2014 15:18:02 GMT (envelope-from br@freefall.freebsd.org) Received: (from br@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1OFI1ic014721; Mon, 24 Feb 2014 15:18:01 GMT (envelope-from br) Date: Mon, 24 Feb 2014 15:18:01 GMT Message-Id: <201402241518.s1OFI1ic014721@freefall.freebsd.org> To: br@bsdpad.com, br@FreeBSD.org, freebsd-arm@FreeBSD.org From: br@FreeBSD.org Subject: Re: arm/180080: Unmapped buffers on ARMv7 big-RAM boards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 15:18:03 -0000 Synopsis: Unmapped buffers on ARMv7 big-RAM boards State-Changed-From-To: open->closed State-Changed-By: br State-Changed-When: Mon Feb 24 15:18:01 UTC 2014 State-Changed-Why: fixed at r255967 http://www.freebsd.org/cgi/query-pr.cgi?pr=180080 From owner-freebsd-arm@FreeBSD.ORG Mon Feb 24 15:59:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1824C56; Mon, 24 Feb 2014 15:59:41 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D32516CD; Mon, 24 Feb 2014 15:59:41 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id i17so9208241qcy.25 for ; Mon, 24 Feb 2014 07:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PahaQLMQTOHd1z7R7M2aVktrw9JWHTLBAC1nkz94mag=; b=K+BA6l4mlNuxQd6sozc7OPf4KYF0Sk2Mo9Hjz8l/0jA79KjWAVi3FEg5aY7AO/M0RP xRChV1SVV2Mp2GL4KGksomLS1Y9f+iqDUrUzgrjFls0SsWuwUKu4dvoeIFzF9YQYCjPY fxZC7j2DmIeVpnCW+FexU0KWyeX9NuDUuhFcQpAYnX/3P//S4TeRdmdS/Z/a6WJkYQe+ 82qJwJfXPEbliRgMU4b6x35MJaKGVjxq5QqmGlQb193Exmn1kCEwLtyHe7b9C2wCQR4O Fa59Szeq6RHtXJH5fm6hI95hicGHYNSUuI51dqISNicPw0Loz7utzhgNDVfS+M5cqTVN /j9A== MIME-Version: 1.0 X-Received: by 10.224.121.137 with SMTP id h9mr31128161qar.55.1393257580418; Mon, 24 Feb 2014 07:59:40 -0800 (PST) Received: by 10.224.16.10 with HTTP; Mon, 24 Feb 2014 07:59:40 -0800 (PST) In-Reply-To: <20140224142642.GA32538@olymp.kibab.com> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> Date: Mon, 24 Feb 2014 07:59:40 -0800 Message-ID: Subject: Re: MMC/SDIO stack under CAM From: Adrian Chadd To: Ilya Bakulin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 15:59:41 -0000 hi, Let me just reiterate some .. well, experience doing this stuff at QCA. You really, absolutely don't want too much overhead in the MMC/SDIO path between whatever is issuing things and the network driver. There was significant performance work done at QCA on a local MMC/SDIO driver and bus to get extremely low latency and CPU utilisation when pushing around small transactions. The current CAM locking model is not geared towards getting to high transaction rates. You may think this is a very architecturally pretty solution and it indeed may be. But if it doesn't perform as well as the existing local hacks that vendors have done, no company deploying this hardware is going to want to use it. They'll end up realising there's this massive CAM storage layer in between and either have to sit down to rip it up and replace it with something lightweight, or they'll say "screw it" and go back to the vendor supplied hacked up Linux solution. So I highly recommend you profile things - and profile things with lots of small transactions. If the CAM overhead is more than a tiny, tiny fraction of CPU at 25,000 pps, your solution won't scale. :-) -a On 24 February 2014 06:26, Ilya Bakulin wrote: > On Sun, Feb 16, 2014 at 11:05:35AM -0700, Warner Losh wrote: >> that's cool! I'd thought of writing a mmcsim that I could use to develop= the stack on x86, but time pressures of my job precluded that (though in h= ind sight, it would have saved a lot of time). > > I assume that by "mmcsim" you mean not MMC SIM for CAM, but MMC SIMulator= :-) > Yeah so essentially it should be able to return some "fake" data > to the upper layer, maybe based on configuration (ie 1 GB SD, 16 GB SDHC,= ...). > >> > For SDIO card, the situation will be different. Essentially, >> > we should allow a device driver to send arbitrary messages to the card= . >> > So the device driver will attach directly to the scbus. >> > >> > Please let me know your thoughts about it. >> > I really want SDIO make its way into the kernel, because there >> > is an increasing number of ARM boards on the market that have integrat= ed >> > SDIO WLAN on them and we cannot support them fully. >> >> Generally, I like this idea... I'd be very interested in some of the sp= ecifics to make the direct attachment work with SDIO. That's the one area I= either don't think I understand your proposal well enough, or I do and I'm= concerned about it. :) So maybe write a bit more about the details of the = SDIO cards and how they's interact with CAM in this scenario... >> >> The notion of moving MMC/SD into the CAM stack has been around since I s= tarted working on MMC. At the time, CAM was too SCSI centric to do it, but = Alexander Motin's work has generally improved that situation, so it may be = possible now to do it and shake out the few dark corners of CAM where this = isn't the case. I also think it should help performance a lot since we're c= urrently single threaded to the card (but that's also the nature of the bus= ), which introduces some round-trip latencies between too many threads that= CAM may help us avoid. >> >> Warner > > After talking with Alexander about CAM, here is the updated proposal: > > * All card communication logic should be placed in MMC XPT layer, with th= e new CCB type > that describes MMC request + some data needed by the system. > So almost everything from sys/dev/mmc/mmc.c goes there. > * da(4) is a driver for SCSI disks. It makes more sense to adapt mmcsd(4)= to use CAM. > So mmcsd(4) will create CCBs and pass them to CAM layer, getting async = notifications > via standard CAM callback mechanism. > * It is possible to write drivers for SDIO devices exactly like adopted m= mcsd(4). > Every such driver would be then built as CAM peripheral driver, which m= eans it will be able > to send/receive CCBs. > To do that, every driver has to call PERIPHDRIVER_DECLARE() macro, subs= cribing to CAM "new device found" events. > > The ongoing work for MMC CAM is here: > https://github.com/kibab/freebsd/compare/master...mmccam > Not so much stuff here yet. > > PS: In theory, ssince there is already an existing interface for passing = CAM CCBs between userland and kernel, > it WOULD be posssible to create device drivers entirely in userland... Li= ke microkernel OSes do. > But our network stack doesn'have such feature I guess... > > -- > Ilya From owner-freebsd-arm@FreeBSD.ORG Tue Feb 25 07:22:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 894B63A3 for ; Tue, 25 Feb 2014 07:22:44 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 065E114CE for ; Tue, 25 Feb 2014 07:22:43 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id c11so330190lbj.40 for ; Mon, 24 Feb 2014 23:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=/6CTshraZ/sGMhA0FPnlCFDP4bEZj1lQTymmF6C6M8A=; b=ct6IO0VIgBQhc7smkejvJLuX6jAiuur9t1u3UTupe2guce2NnyjR/3mMai5yOquuEC 2J+c+rz6/QVhMznGO1R1jkOlyKcZ/op4hPulWIJNxT74EPZfucfxUl8QXe1FedIpTwmb sGVVeVAlumTDrw+hKoiObS3s4QnJZ5vnsFT0YMFJrldoillgw0Hta4cl7230OxmKLbhM Mj4zdZlOot979yaZ0SJ5gEvRwzWDBKNXD17pVjSo/I83ekh3LcOBIpiAyUZaCvVsK23C jDzQbUos6i7GdbK5DUalNFT9pix4BV05IfFVDzy5eu748KbntHEMPmQvSYEPmf6bWN+5 X34g== X-Received: by 10.112.205.5 with SMTP id lc5mr14221531lbc.40.1393312961959; Mon, 24 Feb 2014 23:22:41 -0800 (PST) Received: from moiseev.ccl.ru (moiseev.ccl.ru. [195.222.137.198]) by mx.google.com with ESMTPSA id y2sm29386662lal.10.2014.02.24.23.22.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 23:22:39 -0800 (PST) Message-ID: <530C44B7.7040001@gmail.com> Date: Tue, 25 Feb 2014 13:22:31 +0600 From: =?windows-1251?Q?=C2=FF=F7=E5=F1=EB=E0=E2_=CC=EE=E8=F1=E5=E5=E2?= User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: mpd5 not connected Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 07:22:44 -0000 Hi all! At RPI-B successfully created vpn-connection, which gives access to the network 10.0.0.0 / 8. Further inside the vpn-connection I'm trying to create a new connection to the server 10.100.65.27, which results in an error: Feb 25 12:48:25 raspberry mpd: [B2] Bundle: Interface ng1 created Feb 25 12:48:25 raspberry mpd: [L2] Link: OPEN event Feb 25 12:48:25 raspberry mpd: [L2] LCP: Open event Feb 25 12:48:25 raspberry mpd: [L2] LCP: state change Initial --> Starting Feb 25 12:48:25 raspberry mpd: [L2] LCP: LayerStart Feb 25 12:49:40 raspberry mpd: [L2] PPTP call failed Feb 25 12:49:40 raspberry mpd: [L2] Link: DOWN event Feb 25 12:49:40 raspberry mpd: [L2] LCP: Down event Feb 25 12:49:40 raspberry mpd: [L2] Link: reconnection attempt 1 in 1 seconds Feb 25 12:49:41 raspberry mpd: [L2] Link: reconnection attempt 1 Feb 25 12:50:56 raspberry mpd: [L2] PPTP call failed Feb 25 12:50:56 raspberry mpd: [L2] Link: DOWN event Feb 25 12:50:56 raspberry mpd: [L2] LCP: Down event Packets pass: # tcpdump -i ng0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ng0, link-type NULL (BSD loopback), capture size 65535 bytes 13:16:31.084475 IP 10.100.65.93.16290 > 10.100.65.27.pptp: Flags [S], seq 1234408069, win 65535, options [mss 1416,nop,wscale 6,sackOK,TS val 58997701 ecr 0], length 0 13:16:31.094796 IP 10.100.65.27.pptp > 10.100.65.93.16290: Flags [.], ack 1234408070, win 1024, length 0 13:16:48.695908 IP 10.100.65.93.25931 > 10.100.65.27.pptp: Flags [S], seq 252118709, win 65535, options [mss 1416,nop,wscale 6,sackOK,TS val 59015311 ecr 0], length 0 13:16:48.704843 IP 10.100.65.27.pptp > 10.100.65.93.25931: Flags [S.], seq 3296563462, ack 252118710, win 65535, options [mss 1416,nop,wscale 6,sackOK,TS val 2197804102 ecr 59015311], length 0 13:16:51.694465 IP 10.100.65.93.25931 > 10.100.65.27.pptp: Flags [S], seq 252118709, win 65535, options [mss 1416,nop,wscale 6,sackOK,TS val 59018311 ecr 0], length 0 ^C # ifconfig lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 ue0: flags=8843 metric 0 mtu 1500 options=80001 ether b8:27:eb:b5:b0:3c inet 192.168.88.248 netmask 0xffffff00 broadcast 192.168.88.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 ng0: flags=88d1 metric 0 mtu 1456 inet 10.100.65.93 --> 10.100.65.19 netmask 0xffffffff inet6 fe80::ba27:ebff:feb5:b03c%ng0 prefixlen 64 scopeid 0x3 nd6 options=29 ng1: flags=8890 metric 0 mtu 1500 nd6 options=29 # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.88.1 UGS 0 2401 ue0 10.100.65.19 link#3 UH 0 0 ng0 10.100.65.27 10.100.65.19 UGHS 0 234 ng0 10.100.65.93 link#3 UHS 0 0 lo0 127.0.0.1 link#1 UH 0 2 lo0 192.168.88.0/24 link#2 U 0 4445 ue0 192.168.88.248 link#2 UHS 0 0 lo0 # uname -a FreeBSD raspberry.home 10.0-STABLE FreeBSD 10.0-STABLE #0 r261200: Tue Jan 28 22:58:29 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm # mpd5 --version Version 5.7 (root@raspberry.home 11:10 24-Feb-2014) If I point out the route for the second connection through another computer, then both connections are established successfully. The problem arises only through working through the first vpn-connection. Firewall disabled. Exactly the same configuration on another local computer i386 works without problems. What may be the reason? From owner-freebsd-arm@FreeBSD.ORG Tue Feb 25 19:16:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FC6C6E6 for ; Tue, 25 Feb 2014 19:16:54 +0000 (UTC) Received: from thetys.cloudzeeland.nl (webrz.xs4all.nl [83.161.133.58]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2FF11DA0 for ; Tue, 25 Feb 2014 19:16:53 +0000 (UTC) Received: from thetys.cloudzeeland.nl (thetys.cloudzeeland.nl [10.10.10.31]) by thetys.cloudzeeland.nl (Postfix) with ESMTP id C8FF51644599 for ; Tue, 25 Feb 2014 20:16:35 +0100 (CET) Received: from [10.10.10.70] (sedna.cloudzeeland.nl [10.10.10.70]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by thetys.cloudzeeland.nl (Postfix) with ESMTPSA id A9B581644569 for ; Tue, 25 Feb 2014 20:16:35 +0100 (CET) Message-ID: <530CEC23.20200@cloudzeeland.nl> Date: Tue, 25 Feb 2014 20:16:51 +0100 From: Jos Chrispijn Organization: Pi for President! User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Reboot issue Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on thetys.cloudzeeland.nl X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 19:16:54 -0000 When I reboot, FreeBSD 10 standard holds, displaying that it cannot access media. If I then power down and up, it works fine. I already did a autosize_enable="NO" in my rc.conf. Can you tell what goes wrong here and how I can solve it? Thanks! -- Jos Chrispijn 'Nope, it doesn't have a standard case...' From owner-freebsd-arm@FreeBSD.ORG Wed Feb 26 12:04:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8ADB823E for ; Wed, 26 Feb 2014 12:04:15 +0000 (UTC) Received: from wp376.webpack.hosteurope.de (wp376.webpack.hosteurope.de [IPv6:2a01:488:42::50ed:8591]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4967E11F0 for ; Wed, 26 Feb 2014 12:04:15 +0000 (UTC) Received: from xdsl-78-34-186-231.netcologne.de ([78.34.186.231] helo=dijkstra-old.hb22.cruwe.de); authenticated by wp376.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1WIdDg-00052Q-Sp; Wed, 26 Feb 2014 13:04:13 +0100 Date: Wed, 26 Feb 2014 13:03:57 +0100 From: "Christopher J. Ruwe" To: freebsd-arm@freebsd.org Subject: apparently, disabled POSIX scheduler in snapshot images makes ports fail Message-ID: <20140226130357.206cf9ae@dijkstra-old.hb22.cruwe.de> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-bounce-key: webpack.hosteurope.de;cjr@cruwe.de;1393416255;a9771200; X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 12:04:15 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkkgYW0g dHJ5aW5nIHRvIGJ1aWxkIHBvc3RncmVzcWwtY2xpZW50IGZvciBBUk12NiBSYXNwYmVycnkgUGkg d2l0aA0KbWFjaGluZXMgaW5zdGFsbGVkIGZyb20gdGhlIGltYWdlcyBwcm92aWRlZCBvbiB0aGUg b2ZmaWNpYWwgc2VydmVycw0KYW5kIGEgY3VzdG9tIGltYWdlIGZyb20gdGhlIGNyb2NoZXQuDQoN ClRoYXQgZmFpbHMgYmVjYXVzZSBpbiB0aGUgY29uZmlndXJlIHN0YWdlLCB0aGUgdGVzdCBmb3Ig dGhyZWFkIHNhZmV0eQ0KZmFpbHMgYW5kIGR1bXBzIGNvcmUuDQoNCiAgICAgIGNoZWNraW5nIHRo cmVhZCBzYWZldHkgb2YgcmVxdWlyZWQgbGlicmFyeSBmdW5jdGlvbnMuLi4gQWJvcnQgXA0KICAg ICAgdHJhcCAoY29yZSBkdW1wZWQpIA0KICAgICAgbm8NCiAgICAgIGNvbmZpZ3VyZTogZXJyb3I6 IHRocmVhZCB0ZXN0IHByb2dyYW0gZmFpbGVkDQogICAgICBUaGlzIHBsYXRmb3JtIGlzIG5vdCB0 aHJlYWQtc2FmZS4gIENoZWNrIHRoZSBmaWxlICdjb25maWcubG9nJyBcDQogICAgICBvciBjb21w aWxlIA0KICAgICAgYW5kIHJ1biBzcmMvdGVzdC90aHJlYWQvdGhyZWFkX3Rlc3QgZm9yIHRoZSBl eGFjdCByZWFzb24uDQogICAgICBVc2UgLS1kaXNhYmxlLXRocmVhZC1zYWZldHkgdG8gZGlzYWJs ZSB0aHJlYWQgc2FmZXR5Lg0KICAgICAgPT09PiAgU2NyaXB0ICJjb25maWd1cmUiIGZhaWxlZCB1 bmV4cGVjdGVkbHkuDQogICAgICBQbGVhc2UgcmVwb3J0IHRoZSBwcm9ibGVtIHRvIHBnc3FsQEZy ZWVCU0Qub3JnIFttYWludGFpbmVyXSBhbmQNCiAgICAgIGF0dGFjaCB0aGUgIi91c3IvcG9ydHMv ZGF0YWJhc2VzL3Bvc3RncmVzcWw5MC1jbGllbnQvd29yay9wb3N0Z3Jlc3FsLTkuMC4xNS9jb25m aWcubG9nIiANCiAgICAgIGluY2x1ZGluZyB0aGUgb3V0cHV0IG9mIHRoZSBmYWlsdXJlIG9mIHlv dXIgbWFrZSBjb21tYW5kLiBBbHNvLA0KICAgICAgaXQgbWlnaHQgYmUgIGEgZ29vZCBpZGVhIHRv IHByb3ZpZGUgYW4gb3ZlcnZpZXcgb2YgYWxsIHBhY2thZ2VzDQogICAgICBpbnN0YWxsZWQgb24g eW91ciBzeXN0ZW0gKGUuZy4gYSAvdXNyL2xvY2FsL3NiaW4vcGtnLXN0YXRpYyBpbmZvDQogICAg ICAtZyAtRWEpLiANCiAgICAgICoqKiBFcnJvciBjb2RlIDENCg0KSW52ZXN0aWdhdGluZywgSSBm b3VuZCBhIHNpbWlsYXIgcHJvYmxlbSB3aGVyZSBzb21lYm9keSBmYWlsZWQgdG8NCmNvbXBpbGUg cG9zdGdyZXNxbCBwb3J0cyBkdWUgdG8gIGRpc2FibGVkIEtQT1NJWF9QUklPUklUWV9TQ0hFRFVM SU5HDQppbiB0aGUga2VybmVsLg0KDQpBcyBpbiB0aGF0IHNpdHVhdGlvbiwgaW4gdGhlIEtQT1NJ WCBzY2hlZHVsZXIgaXMgZGlzYWJsZWQ6DQoNCiAgICMgIHN0cmluZ3MgL2Jvb3Qva2VybmVsL2tl cm5lbCB8IGdyZXAgUE9TSVgNCiAgIG5mc2NsX2ZpbGxsb2Nrb3duZXI6IG5vdCBGX1BPU0lYIG9y IEZfRkxPQ0sNCiAgIFBPU0lYIFAxMDAzLjFCIHJlYWx0aW1lIGV4dGVuc2lvbnMNCiAgIFRoZSB2 ZXJzaW9uIG9mIFBPU0lYIDEwMDMuMiB3aXRoIHdoaWNoIHRoZSBzeXN0ZW0gYXR0ZW1wdHMgdG8g XA0KICAgY29tcGx5IA0KICAgVmVyc2lvbiBvZiBQT1NJWCBhdHRlbXB0aW5nIHRvIGNvbXBseSB0 bw0KICAgUE9TSVggcmVhbCB0aW1lIHNpZ25hbA0KICAgUE9TSVggc2hhcmVkIG1lbW9yeQ0KDQpU aGUgZXhwZWN0ZWQgIm9wdGlvbnMgX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HIiBpcyBvYnZp b3VzbHkNCm1pc3NpbmcsIHdoaWNoIGV4cGxhaW5zIHRoZSBidWlsZCBmYWlsdXJlLg0KDQpZZXQs IGluIHN0YWJsZS8xMCwgS1BPU0lYIHNlZW1zIHRvIGJlIGVuYWJsZWQ6DQoNCiAgICAgW2NqckBk aWprc3RyYTovdXNyL3NyY10kIGdyZXAgUE9TSVggc3lzL2FybS9jb25mL1JQSS1CDQogICAgIG9w dGlvbnMgX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HICNQb3NpeCBQMTAwM18xQiByZWFsLXRp bWUgXA0KICAgICBleHRlbnNpb25zIA0KDQpXaHkgaXMgX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVM SU5HIHRoZW4gZGlzYWJsZWQgaW4gdGhlIHNuYXBzaG90cz8gSXMNCm15IHRoaW5raW5nIHdyb25n Pw0KDQoNClRoYW5rcyBhbmQgY2hlZXJzLA0KLSAtLSANCkNocmlzdG9waGVyIA0KDQpUWjogICAg ICAgICBHTVQgKyAxaA0KR251UEcvR1BHOiAgMHhFOERFMkMxNA0KIA0KRnJlZUJTRCAxMC4wLVNU QUJMRSAjMCByMjYyMjkxK2NmMGZhNDgoc3RhYmxlLzEwKTogU2F0IEZlYiAyMiAwMjowMToyNg0K Q0VUIDIwMTQgY2pyQGRpamtzdHJhLmhiMjIuY3J1d2UuZGU6L3Vzci9vYmovdXNyL3NyYy9zeXMv R0VORVJJQyANCiANClB1bmN0dWF0aW9uIG1hdHRlcnM6DQoiTGV0cyBlYXQgR3JhbmRtYSBvciBM ZXRzIGVhdCwgR3JhbmRtYSIgLSBQdW5jdHVhdGlvbiBzYXZlcyBsaXZlcy4NCiJBIHBhbmRhIGVh dHMgc2hvb3RzIGFuZCBsZWF2ZXMiIG9yICJBIHBhbmRhIGVhdHMsIHNob290cywgYW5kIGxlYXZl cyIgLQ0KUHVuY3R1YXRpb24gdGVhY2hlcyBwcm9wZXIgYmlvbG9neS4NCg0KIldpdGggc3VmZmlj aWVudCB0aHJ1c3QsIHBpZ3MgZmx5IGp1c3QgZmluZS4gSG93ZXZlciwgdGhpcyBpcyBub3QNCm5l Y2Vzc2FyaWx5IGEgZ29vZCBpZGVhLiBJdCBpcyBoYXJkIHRvIGJlIHN1cmUgd2hlcmUgdGhleSBh cmUgZ29pbmcgdG8NCmxhbmQsIGFuZCBpdCBjb3VsZCBiZSBkYW5nZXJvdXMgc2l0dGluZyB1bmRl ciB0aGVtIGFzIHRoZXkgZmx5DQpvdmVyaGVhZC4iIChSRkMgMTkyNSkNCi0tLS0tQkVHSU4gUEdQ IFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2Mi4wLjIyIChGcmVlQlNEKQ0KDQppUUlj QkFFQkNnQUdCUUpURGRnMkFBb0pFSlRJS1cvbzNpd1VzaEVRQU1ZK2kzZHFlOWpmTGl6UGxUc1Vq MG1nDQpjMDZwdmkzOXF3dlg5N2hIanQ0Zy9Eak5FbVZIR3BjZ2NNdDdJVW1GM2pvRFlTU1JETmxh WDhBUEI0d1RoQTNkDQpZd2ptZWp0MEZMSHY2d3FkdFRQMjlSb2ZMY0Y0YWxETmtvbFluRkZHQTRl ZHRSR00yNHJSeENaRjFVODg3a2xjDQozOFF5K09halRrNksvTDlrSW1abnFkSGY2dTVHdnZ6L0s5 S3hlcUs2SDcwdHJIYVVnM2JNOVd1cG5EcWdUR2M2DQpKTkhiNEt1V3RoR2Z1R3VBeFJvdU52R3dK d25vbTB1TmVuS1UxRDBaOEtSTW1iR2FScUNOdlBSODZWdSs3YUZBDQozZWxLZVlGRGhpajluajNS TzJySEdUZWViZVpiTlJJMkNKQUlSMnVFWit4cEVKUkp1eWRlSDI1UWx4Q25xNDZZDQpsZWFFZWZm YnJtb2tKeGxLZ2ZIMFRqRE1ZRTVQOERuSXQ0Y3NPMVY4cWQ5dU9jVTlkYW9jZ09VYTVLRU16TDBn DQpINFJueDNFYm5TcmpsYWJIOWpWRnAxN1ZTYkRQbkU2SjJYZHFmeENOVlpLcElwY1NsQi9ISG1k OVFOYkQ0OS9xDQpyK0s2QzBqK3RYVXc4RC9FQ1A5Qzl2U0dObUpHTzZ6QUliNVJaNGU0cm1ZT1Y0 WmFyNU1hYm4raXMvUVpueHF2DQpDYkRodFFLNzNZNW9US05seW04eGJoYnQwTWtnb1ErWFh0TVRE MTR4WWN3ZjhYekJtOTFFdlc1MGJ0NWFWcTZFDQpQRDEwWXNtNVBtZFZpaTFXd0hMUnFMdDFXQkFQ VUlKc2NjcWhEcWN3WUJBT2hKZ25vNW1obGRUYi94bHZ3N3IxDQorZktJRUFUNEgwc2dtdkxpckhj Qg0KPVlHcGYNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-arm@FreeBSD.ORG Wed Feb 26 17:09:11 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F42DE2D for ; Wed, 26 Feb 2014 17:09:11 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3D2910C7 for ; Wed, 26 Feb 2014 17:09:10 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WIfsa-000MrT-EZ; Wed, 26 Feb 2014 14:54:36 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1QEsWWn039656; Wed, 26 Feb 2014 07:54:32 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Xg2vkcvRy8QI07/bVBmbK Subject: Re: apparently, disabled POSIX scheduler in snapshot images makes ports fail From: Ian Lepore To: "Christopher J. Ruwe" In-Reply-To: <20140226130357.206cf9ae@dijkstra-old.hb22.cruwe.de> References: <20140226130357.206cf9ae@dijkstra-old.hb22.cruwe.de> Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Feb 2014 07:54:32 -0700 Message-ID: <1393426472.1149.92.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 17:09:11 -0000 On Wed, 2014-02-26 at 13:03 +0100, Christopher J. Ruwe wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > I am trying to build postgresql-client for ARMv6 Raspberry Pi with > machines installed from the images provided on the official servers > and a custom image from the crochet. > > That fails because in the configure stage, the test for thread safety > fails and dumps core. > > checking thread safety of required library functions... Abort \ > trap (core dumped) > no > configure: error: thread test program failed > This platform is not thread-safe. Check the file 'config.log' \ > or compile > and run src/test/thread/thread_test for the exact reason. > Use --disable-thread-safety to disable thread safety. > ===> Script "configure" failed unexpectedly. > Please report the problem to pgsql@FreeBSD.org [maintainer] and > attach the "/usr/ports/databases/postgresql90-client/work/postgresql-9.0.15/config.log" > including the output of the failure of your make command. Also, > it might be a good idea to provide an overview of all packages > installed on your system (e.g. a /usr/local/sbin/pkg-static info > -g -Ea). > *** Error code 1 > > Investigating, I found a similar problem where somebody failed to > compile postgresql ports due to disabled KPOSIX_PRIORITY_SCHEDULING > in the kernel. > > As in that situation, in the KPOSIX scheduler is disabled: > > # strings /boot/kernel/kernel | grep POSIX > nfscl_filllockowner: not F_POSIX or F_FLOCK > POSIX P1003.1B realtime extensions > The version of POSIX 1003.2 with which the system attempts to \ > comply > Version of POSIX attempting to comply to > POSIX real time signal > POSIX shared memory > > The expected "options _KPOSIX_PRIORITY_SCHEDULING" is obviously > missing, which explains the build failure. > > Yet, in stable/10, KPOSIX seems to be enabled: > > [cjr@dijkstra:/usr/src]$ grep POSIX sys/arm/conf/RPI-B > options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time \ > extensions > > Why is _KPOSIX_PRIORITY_SCHEDULING then disabled in the snapshots? Is > my thinking wrong? > > > Thanks and cheers, > - -- > Christopher Your method of grepping for the string isn't reliable. To see if posix priority scheduling is available, use: sysctl kern.features.kposix_priority_scheduling It's almost certainly going to be set to one. Then the question becomes "what is the actual abort that's happening during configure?" -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Feb 27 12:16:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5FA58A5 for ; Thu, 27 Feb 2014 12:16:53 +0000 (UTC) Received: from wp376.webpack.hosteurope.de (wp376.webpack.hosteurope.de [IPv6:2a01:488:42::50ed:8591]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A00F710EC for ; Thu, 27 Feb 2014 12:16:53 +0000 (UTC) Received: from xdsl-78-35-64-118.netcologne.de ([78.35.64.118] helo=dijkstra-old.hb22.cruwe.de); authenticated by wp376.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1WIztT-0002bY-Et; Thu, 27 Feb 2014 13:16:51 +0100 Date: Wed, 26 Feb 2014 16:31:26 +0100 From: "Christopher J. Ruwe" (by way of Christopher J. Ruwe ) To: Ian Lepore Message-ID: <20140226163126.20bfa6a1@dijkstra-old.hb22.cruwe.de> In-Reply-To: <1393426472.1149.92.camel@revolution.hippie.lan> References: <20140226130357.206cf9ae@dijkstra-old.hb22.cruwe.de> <1393426472.1149.92.camel@revolution.hippie.lan> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Date: Thu, 27 Feb 2014 13:16:50 +0100 Resent-From: Christopher J. Ruwe Subject: Re: apparently, disabled POSIX scheduler in snapshot images makes ports fail Resent-Message-ID: <20140227131650.25e295bd@dijkstra-old.hb22.cruwe.de> Resent-To: freebsd-arm@freebsd.org X-bounce-key: webpack.hosteurope.de;cjr@cruwe.de;1393503413;a0879dc7; X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 12:16:54 -0000 On Wed, 26 Feb 2014 07:54:32 -0700 Ian Lepore wrote: > On Wed, 2014-02-26 at 13:03 +0100, Christopher J. Ruwe wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > I am trying to build postgresql-client for ARMv6 Raspberry Pi with > > machines installed from the images provided on the official servers > > and a custom image from the crochet. > > > > That fails because in the configure stage, the test for thread > > safety fails and dumps core. > > > > checking thread safety of required library functions... Abort > > \ trap (core dumped) > > no > > configure: error: thread test program failed > > This platform is not thread-safe. Check the file > > 'config.log' \ or compile > > and run src/test/thread/thread_test for the exact reason. > > Use --disable-thread-safety to disable thread safety. > > ===> Script "configure" failed unexpectedly. > > Please report the problem to pgsql@FreeBSD.org [maintainer] > > and attach the > > "/usr/ports/databases/postgresql90-client/work/postgresql-9.0.15/config.log" > > including the output of the failure of your make command. Also, it > > might be a good idea to provide an overview of all packages > > installed on your system (e.g. a /usr/local/sbin/pkg-static info -g > > -Ea). *** Error code 1 > > > > Investigating, I found a similar problem where somebody failed to > > compile postgresql ports due to disabled KPOSIX_PRIORITY_SCHEDULING > > in the kernel. > > > > As in that situation, in the KPOSIX scheduler is disabled: > > > > # strings /boot/kernel/kernel | grep POSIX > > nfscl_filllockowner: not F_POSIX or F_FLOCK > > POSIX P1003.1B realtime extensions > > The version of POSIX 1003.2 with which the system attempts to \ > > comply > > Version of POSIX attempting to comply to > > POSIX real time signal > > POSIX shared memory > > > > The expected "options _KPOSIX_PRIORITY_SCHEDULING" is obviously > > missing, which explains the build failure. > > > > Yet, in stable/10, KPOSIX seems to be enabled: > > > > [cjr@dijkstra:/usr/src]$ grep POSIX sys/arm/conf/RPI-B > > options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time \ > > extensions > > > > Why is _KPOSIX_PRIORITY_SCHEDULING then disabled in the snapshots? > > Is my thinking wrong? > > > > > > Thanks and cheers, > > - -- > > Christopher > > Your method of grepping for the string isn't reliable. To see if > posix priority scheduling is available, use: > > sysctl kern.features.kposix_priority_scheduling > > It's almost certainly going to be set to one. Then the question > becomes "what is the actual abort that's happening during configure?" > > -- Ian > The answer is yes, [...].kposix_priority_scheduling=1. Hmm ... I hoped for an easy solution ... Thanks, -- Christopher TZ: GMT + 1h GnuPG/GPG: 0xE8DE2C14 FreeBSD 10.0-STABLE #0 r262291+cf0fa48(stable/10): Sat Feb 22 02:01:26 CET 2014 cjr@dijkstra.hb22.cruwe.de:/usr/obj/usr/src/sys/GENERIC Punctuation matters: "Lets eat Grandma or Lets eat, Grandma" - Punctuation saves lives. "A panda eats shoots and leaves" or "A panda eats, shoots, and leaves" - Punctuation teaches proper biology. "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." (RFC 1925) From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 03:23:51 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 935B8322 for ; Fri, 28 Feb 2014 03:23:51 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 684A51754 for ; Fri, 28 Feb 2014 03:23:51 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJE3B-000Fxg-RI for freebsd-arm@FreeBSD.org; Fri, 28 Feb 2014 03:23:50 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1S3NlGS041503 for ; Thu, 27 Feb 2014 20:23:47 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+UrFx2N6+7J6L4GY7Mhvs8 Subject: wandboard / imx6 hard float From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Feb 2014 20:23:47 -0700 Message-ID: <1393557827.1149.117.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 03:23:51 -0000 After some testing last week I determined that hard float works on imx6, so I enabled it (added option VFP) in the kernel configs. To check whether it's enabled, see if "sysctl hw.floatingpoint" is set to 1. To actually use the hardware floating point you have to add some options to CFLAGS: * For clang CFLAGS="-mfloat-abi=softfp" * For gcc CFLAGS="-mfloat-abi=softfp -mfpu=vfp" * You can do that on the make command line, in the environment, or in /etc/make.conf. I think the implication of float-abi=softfp is that floating point arguments are passed in integer registers, and we're losing some performance with that. But as I vaguely understand it, we're still missing some piece of support code to enable full eabihf. Maybe somebody who knows the status of that can fill in my hand-wavy blanks. Hardware floating point makes a huge performance difference in apps that use floating point. Using the venerable benchmarks/flops program from ports, here's the results on my Wandboard quad running @ 984 MHz... ------------------------------------------------------- FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module Error RunTime MFLOPS (usec) 1 -1.5632e-13 3.0377 4.6087 2 -1.0347e-13 1.8709 3.7416 3 -3.1197e-14 3.1652 5.3709 4 7.7938e-14 2.7834 5.3890 5 -3.2641e-14 6.2713 4.6243 6 -9.9920e-16 5.4799 5.2920 7 -5.5650e-11 4.0721 2.9469 8 2.7700e-14 5.7273 5.2381 Iterations = 8000000 NullTime (usec) = 0.0000 MFLOPS(1) = 4.1535 MFLOPS(2) = 4.1052 MFLOPS(3) = 4.7811 MFLOPS(4) = 5.3043 ------------------------------------------------------- FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module Error RunTime MFLOPS (usec) 1 -7.6739e-13 0.1058 132.2879 2 -5.7021e-13 0.0621 112.7249 3 -2.4314e-14 0.0967 175.8202 4 6.8501e-14 0.0875 171.3418 5 -1.6320e-14 0.1924 150.7668 6 1.3961e-13 0.1730 167.6504 7 -3.6152e-11 0.1160 103.4433 8 9.0483e-15 0.1771 169.3994 Iterations = 256000000 NullTime (usec) = 0.0081 MFLOPS(1) = 127.7076 MFLOPS(2) = 135.7852 MFLOPS(3) = 153.9281 MFLOPS(4) = 170.3133 ------------------------------------------------------ -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 03:45:16 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DB55767 for ; Fri, 28 Feb 2014 03:45:16 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 538AA18EC for ; Fri, 28 Feb 2014 03:45:16 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJENv-000L3u-0B for freebsd-arm@FreeBSD.org; Fri, 28 Feb 2014 03:45:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1S3jC5p041514 for ; Thu, 27 Feb 2014 20:45:12 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/uA8P2JDHOxzH/2otYx794 Subject: imx6 / wandboard SMP From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Feb 2014 20:45:12 -0700 Message-ID: <1393559112.1149.132.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 03:45:16 -0000 Thanks to an excellent patchset contributed by Juergen Weiss we now have SMP for Wandboard and imx6 in general. To test this yourself, update to r262587 or later and add "option SMP" to your kernel config. I haven't yet committed kernel config changes to add "option SMP" because I didn't want to take anyone by surprise on an update. It seems to be pretty stable in the limited testing I've done, but I stress "limited" (I haven't even tested sdcard yet, just nfsroot). I committed the bulk of the work last weekend, and today I committed the last bits, involving using the WFI instruction in the idle loop and doing some minimal setup of the imx6 power control to keep the cores powered on enough to process timer interrupts during WFI. More on that in a separate message. So a big round of thanks to Juergen for the SMP work, and to Steven Lawrance for the temperature-sensor stuff so we can be sure the SMP stuff isn't cooking our chips. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 03:56:34 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEAE3C9D for ; Fri, 28 Feb 2014 03:56:34 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 840DD19AB for ; Fri, 28 Feb 2014 03:56:34 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJEYr-0003u1-Dd for freebsd-arm@FreeBSD.org; Fri, 28 Feb 2014 03:56:33 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1S3uUiC041523 for ; Thu, 27 Feb 2014 20:56:30 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ROvVE+BOXIUwrd3QtgMQZ Subject: Using WFI instruction on all armv7-based systems From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Feb 2014 20:56:30 -0700 Message-ID: <1393559790.1149.143.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 03:56:34 -0000 When I first got multiple cores running in my imx6 work, I noticed that my core temperature climbed to 78C and stuck there even with the board 100% idle, and it didn't go up if I loaded the board to 100% busy. It turns out the cpu_sleep() routine we've been using didn't work right for armv7 and the idle thread was just spinning, so all cores were running flat-out all the time. I added code to do the wait-for-interrupt the new armv7 way, using the WFI instruction instead of a coprocessor function. Now the temperature idles at 54C. This change should help all armv7 chips run cooler, not just imx6. I've tested it on imx53 and on my BeagleBone White. After adding the WFI on imx6 I had a lot of trouble with the system hanging during boot. I eventually tracked it down to the chip's power management features -- it was disabling clocks to parts of the ARM cores needed to wake up from WFI, and we don't have the support code yet to use the alternate interrupt controller in low power mode and all that other complicated clocks-and-power stuff. I mention the imx6 problem just in case the same sort of thing crops up on some of the other armv7 chips that I don't have here to test. If you notice strange crashes or hangs, uneven jerky system response, bad timekeeping (like ntpd keeps stepping the clock) then maybe your chip also automatically powers down important stuff during WFI. Let me know and we'll figure out how to fix it, or some way to make WFI optional until it can be fixed. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 13:42:51 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71F3C94D for ; Fri, 28 Feb 2014 13:42:51 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 463421C76 for ; Fri, 28 Feb 2014 13:42:50 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJNiD-0008cQ-VU for freebsd-arm@FreeBSD.org; Fri, 28 Feb 2014 13:42:50 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1SDgkJw042113 for ; Fri, 28 Feb 2014 06:42:46 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+vxPRXrbyIAgsxZEc7JjRw Subject: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Feb 2014 06:42:46 -0700 Message-ID: <1393594966.1149.161.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 13:42:51 -0000 I've added a new imx6 unified kernel config named IMX6. It has no compiled-in fdt, and can boot all three flavors of Wandboard when u-boot and ubldr load a dtb file. Folks should start using it and eventually the WANDBOARD* configs will go away when nobody needs them anymore. I build ubldr to load at address 11000000 and let it load the kernel at 12000000. (The kernel can load on any 1MB boundary, but ubldr doesn't make use of that feature yet.) ubldr will take a dtb file loaded by u-boot and pass it along to the kernel. Another option is to put the .dtb file in your /boot/kernel or /boot/modules directory, and ubldr will load it from there, using the filename set in the u-boot env var fdt_file. Unfortunately we can't do a single image that boots any wandboard, because u-boot itself has to be different for each board. This is what my u-boot env looks like on each wandboard: => printenv baudrate=115200 bootcmd=run ubnet bootdelay=1 console=ttymxc0 fdt_file=wandboard-dual.dtb loadaddr=11000000 loaderdev=net ubmmc=fatload mmc 0 ${loadaddr} ubldr; bootelf ubnet=dhcp ${loadaddr} /wand/boot/ubldr;bootelf Environment size: 265/8188 bytes The only thing that differs per-board is the fdt_file setting, and the u-boot binary itself. The "loaderdev=net" variable tells ubldr to load the kernel from the network device rather than disk. So now all my different model wandboards boot the same kernel and run from the same nfs root directory. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 15:44:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 758E55C7 for ; Fri, 28 Feb 2014 15:44:44 +0000 (UTC) Received: from thetys.cloudzeeland.nl (webrz.xs4all.nl [83.161.133.58]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3433D18C5 for ; Fri, 28 Feb 2014 15:44:43 +0000 (UTC) Received: from thetys.cloudzeeland.nl (thetys.cloudzeeland.nl [10.10.10.31]) by thetys.cloudzeeland.nl (Postfix) with ESMTP id 7F45816445FD; Fri, 28 Feb 2014 16:44:11 +0100 (CET) Received: from [10.10.10.70] (sedna.cloudzeeland.nl [10.10.10.70]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by thetys.cloudzeeland.nl (Postfix) with ESMTPSA id 5A17E16445C8; Fri, 28 Feb 2014 16:44:11 +0100 (CET) Message-ID: <5310AEE5.5060002@webrz.net> Date: Fri, 28 Feb 2014 16:44:37 +0100 From: Jos Chrispijn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 To: Jos Chrispijn , freebsd-arm@freebsd.org Subject: Re: Reboot issue References: <530CEC23.20200@cloudzeeland.nl> In-Reply-To: <530CEC23.20200@cloudzeeland.nl> X-Virus-Scanned: ClamAV using ClamSMTP on thetys.cloudzeeland.nl MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 15:44:44 -0000 [SOLVED] Jos Chrispijn: Can you tell what goes wrong here and how I can solve it? Thanks! Just found out that if I really power down both USB + Pi (of which power I get from this USB as well) it all goes fine. BR, Jos From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 15:56:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F3E2AF6; Fri, 28 Feb 2014 15:56:27 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E1ED7199C; Fri, 28 Feb 2014 15:56:26 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id u14so2584633lbd.33 for ; Fri, 28 Feb 2014 07:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=uLHiMwGbZr+o4x3l6LBO7Xzi9XAApb7LQPVz4fGFkmA=; b=by2PSMRD8YJs5NbkdK9PqIaaFRtiGXyrXJv2Snh9nzFjWMzYGIeYWQglCc8nKfhQSN 6K+4qWaahzKFGk9X1d3VDJrMP77uRl5dTcmpst0qP+fgj3kQMFKn5p+rlhUiBI9TRl+s T6Ks58KpcVtvJSRGz5pz0FACYiLOCz8bC5xvfzFvFIQy4945gIO27QzoHXgvetZramBn dkOlqlcVwlwt1q5ODpXQoXP+ahX5zEHCo/lnRJ4exERqVwiovqHV9gWibXkKUFSeGV/w zxgrQtREWuQG8KCKEzWExsrtFG/9wW6OXjHvPNDbiM8XvZ/+KZll+hJwBXAQ8zjlswyd KdUA== X-Received: by 10.112.77.138 with SMTP id s10mr2200299lbw.59.1393602984951; Fri, 28 Feb 2014 07:56:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.129.232 with HTTP; Fri, 28 Feb 2014 07:55:44 -0800 (PST) From: Odhiambo Washington Date: Fri, 28 Feb 2014 18:55:44 +0300 Message-ID: Subject: pcDuino support To: "freebsd-current@freebsd.org" , freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 15:56:27 -0000 I'd like to buy something for my kids to play with and I was thing about pcDuino, because of the nice specs. I'd like to know if the pcDuino support is complete now for FreeBSD-10. Should I buy it? If not, what is the BEST recommendation? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 "I can't hear you -- I'm using the scrambler." From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 16:41:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69D3EBF6 for ; Fri, 28 Feb 2014 16:41:32 +0000 (UTC) Received: from uk1rly2283.eechost.net (uk1rly2283.eechost.net [217.69.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 3183E1D62 for ; Fri, 28 Feb 2014 16:41:31 +0000 (UTC) Received: from [31.186.37.179] (helo=smtp.marelmo.com) by uk1rly2283.eechost.net with esmtpa (Exim 4.72) (envelope-from ) id 1WJQKS-0003Ex-4M for freebsd-arm@freebsd.org; Fri, 28 Feb 2014 16:30:28 +0000 Received: from [192.168.63.1] (helo=steve.marelmo.com) by smtp.marelmo.com with smtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WJQK2-0000Fq-R1 for freebsd-arm@freebsd.org; Fri, 28 Feb 2014 16:30:02 +0000 Date: Fri, 28 Feb 2014 16:30:02 +0000 From: Steve O'Hara-Smith To: freebsd-arm@freebsd.org Subject: Re: Reboot issue Message-Id: <20140228163002.dd8953f61fc2568774331cf3@sohara.org> In-Reply-To: <5310AEE5.5060002@webrz.net> References: <530CEC23.20200@cloudzeeland.nl> <5310AEE5.5060002@webrz.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Auth-Info: 15567@permanet.ie (plain) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 16:41:32 -0000 On Fri, 28 Feb 2014 16:44:37 +0100 Jos Chrispijn wrote: > [SOLVED] > Jos Chrispijn: > > Can you tell what goes wrong here and how I can solve it? Thanks! > > Just found out that if I really power down both USB + Pi (of which > power I get from this USB as well) it all goes fine. If you're using a powered USB hub with the Pi then the Pi can be partially powered via the USB connection as well as from the power connector. -- Steve O'Hara-Smith From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 18:10:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 329B5513 for ; Fri, 28 Feb 2014 18:10:19 +0000 (UTC) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED402164F for ; Fri, 28 Feb 2014 18:10:18 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id i11so4435141oag.32 for ; Fri, 28 Feb 2014 10:10:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qgHV0NUk2b7JHjKMbTE2K3bftg/xVx6TMfnB5/Cq4Rw=; b=cRlG1qFHyvmbRayxRM1ufot/H73Rs6mR6vt0MkBsDcgv1Q5I7wRPALH/APwyTWPBh1 olhN+W291QJqcFtg1MKic3vhnIwTgeoQhbbLNyblvSzRdbZPAfquw8vgbRwYWyX9ACBD BM+jQqflRF9pD4/s3/CryrDJFikRLviYC2qlZbTRJcK683A8DBdyOD7hFzxdyXO6AowN 9kaaz6b2iMB/99sXMkIkugw/xGnDlFd5Nwr9YuJ2kJ09yE3ipDXFliMJlG133nvYydz4 5PM3qPPpo0QwPvOnZvKQUUBv5GAox3RN1JAkzGDpAz0IwGVWP/7y8EK9+mT8uLa5OBQa jP+A== X-Gm-Message-State: ALoCoQkcWaqEGj0nx8Ch8zVX2VXSkb/Gp9PfX+IEK/IxrWUGmceWu/NZIDuvHlwwy907InCHZjQX MIME-Version: 1.0 X-Received: by 10.182.128.138 with SMTP id no10mr14984636obb.32.1393611011880; Fri, 28 Feb 2014 10:10:11 -0800 (PST) Received: by 10.182.104.169 with HTTP; Fri, 28 Feb 2014 10:10:11 -0800 (PST) In-Reply-To: <1393594966.1149.161.camel@revolution.hippie.lan> References: <1393594966.1149.161.camel@revolution.hippie.lan> Date: Fri, 28 Feb 2014 11:10:11 -0700 Message-ID: Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 18:10:19 -0000 I'll give updating Crochet for this a spin. I'm not that familiar with DTS however. I presume I need to drop the DTS blobs onto the FAT partition? On Fri, Feb 28, 2014 at 6:42 AM, Ian Lepore wrote: > I've added a new imx6 unified kernel config named IMX6. It has no > compiled-in fdt, and can boot all three flavors of Wandboard when u-boot > and ubldr load a dtb file. Folks should start using it and eventually > the WANDBOARD* configs will go away when nobody needs them anymore. > > I build ubldr to load at address 11000000 and let it load the kernel at > 12000000. (The kernel can load on any 1MB boundary, but ubldr doesn't > make use of that feature yet.) ubldr will take a dtb file loaded by > u-boot and pass it along to the kernel. Another option is to put > the .dtb file in your /boot/kernel or /boot/modules directory, and ubldr > will load it from there, using the filename set in the u-boot env var > fdt_file. > > Unfortunately we can't do a single image that boots any wandboard, > because u-boot itself has to be different for each board. This is what > my u-boot env looks like on each wandboard: > > => printenv > baudrate=115200 > bootcmd=run ubnet > bootdelay=1 > console=ttymxc0 > fdt_file=wandboard-dual.dtb > loadaddr=11000000 > loaderdev=net > ubmmc=fatload mmc 0 ${loadaddr} ubldr; bootelf > ubnet=dhcp ${loadaddr} /wand/boot/ubldr;bootelf > > Environment size: 265/8188 bytes > > The only thing that differs per-board is the fdt_file setting, and the > u-boot binary itself. The "loaderdev=net" variable tells ubldr to load > the kernel from the network device rather than disk. So now all my > different model wandboards boot the same kernel and run from the same > nfs root directory. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 18:18:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21F9599D; Fri, 28 Feb 2014 18:18:35 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D5F8B1737; Fri, 28 Feb 2014 18:18:34 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id y20so1009514ier.13 for ; Fri, 28 Feb 2014 10:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2UJ2EhYHMbqP8EPu3+5C8a70hRT29IBb/A4KwB3AW7I=; b=G/NuMeAk4V8pl3Ebn+FtvOk4hsd0xh01VAYLNGwp++57wdvtFYZO64qcweDIzG6yLv evkxdmixGX6nT0yQpmVB98QV1UGZT6lDm1zEDgfsYXHgyIh1nNKFl8WWZqNUD5X4v51X uCQ/SrD6xxhj+eMsoDtdpXgshoIKv1mhEkqlws12gSPCeI4At0loQdrjCk1aRUV0eUC6 fPLYzLdTyOpYRYvMdOJA36z8fStI+ewyiBNZ4l19XIjzBTh6w+sVvm1gzE+lYV1ltKrQ EtUHxELVRFfBuctknkdYdcQEtEA+f7esUR7+tR5osjIz2fo/wsGlWlJ4f0GccxC4p0eU TEXg== X-Received: by 10.50.50.241 with SMTP id f17mr5612807igo.23.1393611514377; Fri, 28 Feb 2014 10:18:34 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id m4sm9430216ige.0.2014.02.28.10.18.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 10:18:33 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Warner Losh In-Reply-To: Date: Fri, 28 Feb 2014 11:18:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1393594966.1149.161.camel@revolution.hippie.lan> To: Tom Everett X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 18:18:35 -0000 On Feb 28, 2014, at 11:10 AM, Tom Everett wrote: > I'll give updating Crochet for this a spin. I'm not that familiar = with DTS > however. I presume I need to drop the DTS blobs onto the FAT = partition? Yes. For now, this will be a manual step for the moment, but will be = automated soonish. I=92m working on overhauling the dts stuff we have in the = system right now and will commit something for that shortly after I finish=85 I = expect full Crochet integration to follow after that. Warner > On Fri, Feb 28, 2014 at 6:42 AM, Ian Lepore wrote: >=20 >> I've added a new imx6 unified kernel config named IMX6. It has no >> compiled-in fdt, and can boot all three flavors of Wandboard when = u-boot >> and ubldr load a dtb file. Folks should start using it and = eventually >> the WANDBOARD* configs will go away when nobody needs them anymore. >>=20 >> I build ubldr to load at address 11000000 and let it load the kernel = at >> 12000000. (The kernel can load on any 1MB boundary, but ubldr = doesn't >> make use of that feature yet.) ubldr will take a dtb file loaded by >> u-boot and pass it along to the kernel. Another option is to put >> the .dtb file in your /boot/kernel or /boot/modules directory, and = ubldr >> will load it from there, using the filename set in the u-boot env var >> fdt_file. >>=20 >> Unfortunately we can't do a single image that boots any wandboard, >> because u-boot itself has to be different for each board. This is = what >> my u-boot env looks like on each wandboard: >>=20 >> =3D> printenv >> baudrate=3D115200 >> bootcmd=3Drun ubnet >> bootdelay=3D1 >> console=3Dttymxc0 >> fdt_file=3Dwandboard-dual.dtb >> loadaddr=3D11000000 >> loaderdev=3Dnet >> ubmmc=3Dfatload mmc 0 ${loadaddr} ubldr; bootelf >> ubnet=3Ddhcp ${loadaddr} /wand/boot/ubldr;bootelf >>=20 >> Environment size: 265/8188 bytes >>=20 >> The only thing that differs per-board is the fdt_file setting, and = the >> u-boot binary itself. The "loaderdev=3Dnet" variable tells ubldr to = load >> the kernel from the network device rather than disk. So now all my >> different model wandboards boot the same kernel and run from the same >> nfs root directory. >>=20 >> -- Ian >>=20 >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>=20 >=20 >=20 >=20 > --=20 > A better world shall emerge based on faith and understanding - = Douglas > MacArthur > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 18:25:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEBD5BCF for ; Fri, 28 Feb 2014 18:25:30 +0000 (UTC) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 934D917FB for ; Fri, 28 Feb 2014 18:25:30 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wm4so4285793obc.3 for ; Fri, 28 Feb 2014 10:25:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XD7eQ2oScPSdVLmFbGjQg0tSgNxOkXzXZdRBN2u9eKo=; b=Fs0cpSIYtBHckEP/218jPw98k9MrdSYtSuT92AdQe+1FgvhwBfsvGqR9WEXC0B0Iw3 gOp37yoQyKqTNecFthzDh9oqv/h2WYl6vGsQUQyRN8Y1YM3eVKnT4lXC65Atfo0f2JhY DiqHKTTXWPJGOsjyaERdd7+8i2JpQR1lRWhhxzFX/9x/FHKzAOCx/lfvB5Jo0BOMoSI5 YmGbhMNfoDMHu+ykPSF3tgdiD0uPkxQvRN4pjTreui0l5iP2ORlZ3S/C1LnPJuYKF4A+ 65W/s9Z9aM8EZPHsb9xzt9em2E8L0rK//IoVsvmEgVQRqmlA/zZVquigQwlvNdeYs4kN GDfw== X-Gm-Message-State: ALoCoQni5G9WFrEzGYM05hs46mHx/ijQCzmbBm4GbQFHZOoH64D9yu1jH/1pyxbAMizCs6vILbYb MIME-Version: 1.0 X-Received: by 10.182.33.6 with SMTP id n6mr14826549obi.48.1393611573044; Fri, 28 Feb 2014 10:19:33 -0800 (PST) Received: by 10.182.104.169 with HTTP; Fri, 28 Feb 2014 10:19:32 -0800 (PST) In-Reply-To: References: <1393594966.1149.161.camel@revolution.hippie.lan> Date: Fri, 28 Feb 2014 11:19:32 -0700 Message-ID: Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Tom Everett To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 18:25:31 -0000 I'll give it a try. On Fri, Feb 28, 2014 at 11:18 AM, Warner Losh wrote: > > On Feb 28, 2014, at 11:10 AM, Tom Everett wrote: > > > I'll give updating Crochet for this a spin. I'm not that familiar with > DTS > > however. I presume I need to drop the DTS blobs onto the FAT partition? > > Yes. For now, this will be a manual step for the moment, but will be > automated > soonish. I'm working on overhauling the dts stuff we have in the system > right > now and will commit something for that shortly after I finish... I expect > full > Crochet integration to follow after that. > > Warner > > > On Fri, Feb 28, 2014 at 6:42 AM, Ian Lepore wrote: > > > >> I've added a new imx6 unified kernel config named IMX6. It has no > >> compiled-in fdt, and can boot all three flavors of Wandboard when u-boot > >> and ubldr load a dtb file. Folks should start using it and eventually > >> the WANDBOARD* configs will go away when nobody needs them anymore. > >> > >> I build ubldr to load at address 11000000 and let it load the kernel at > >> 12000000. (The kernel can load on any 1MB boundary, but ubldr doesn't > >> make use of that feature yet.) ubldr will take a dtb file loaded by > >> u-boot and pass it along to the kernel. Another option is to put > >> the .dtb file in your /boot/kernel or /boot/modules directory, and ubldr > >> will load it from there, using the filename set in the u-boot env var > >> fdt_file. > >> > >> Unfortunately we can't do a single image that boots any wandboard, > >> because u-boot itself has to be different for each board. This is what > >> my u-boot env looks like on each wandboard: > >> > >> => printenv > >> baudrate=115200 > >> bootcmd=run ubnet > >> bootdelay=1 > >> console=ttymxc0 > >> fdt_file=wandboard-dual.dtb > >> loadaddr=11000000 > >> loaderdev=net > >> ubmmc=fatload mmc 0 ${loadaddr} ubldr; bootelf > >> ubnet=dhcp ${loadaddr} /wand/boot/ubldr;bootelf > >> > >> Environment size: 265/8188 bytes > >> > >> The only thing that differs per-board is the fdt_file setting, and the > >> u-boot binary itself. The "loaderdev=net" variable tells ubldr to load > >> the kernel from the network device rather than disk. So now all my > >> different model wandboards boot the same kernel and run from the same > >> nfs root directory. > >> > >> -- Ian > >> > >> > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >> > > > > > > > > -- > > A better world shall emerge based on faith and understanding - Douglas > > MacArthur > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 18:27:15 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23235D06 for ; Fri, 28 Feb 2014 18:27:15 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D83B9181F for ; Fri, 28 Feb 2014 18:27:14 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJS9S-0007Tg-1v; Fri, 28 Feb 2014 18:27:14 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1SIRBml042319; Fri, 28 Feb 2014 11:27:11 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Ki/U/rdKjea28IZboZdGD Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Ian Lepore To: Tom Everett In-Reply-To: References: <1393594966.1149.161.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Feb 2014 11:27:11 -0700 Message-ID: <1393612031.1149.182.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 18:27:15 -0000 It can work a couple different ways... The .dtb files can be on the fat partition and the u-boot script stuff can use "fatload" to load them and set fdt_addr= to the load address, and ubldr will find them. The .dtb files can be on the ufs partition in /boot/kernel/ or /boot/modules and all u-boot has to do is set fdt_file=filename.dtb and ubldr will load the file from the ufs partition. I favor the latter method, because I'd like to see us get all the way to eliminating the msdos partition in the long run. -- Ian On Fri, 2014-02-28 at 11:10 -0700, Tom Everett wrote: > I'll give updating Crochet for this a spin. I'm not that familiar with DTS > however. I presume I need to drop the DTS blobs onto the FAT partition? > > > > On Fri, Feb 28, 2014 at 6:42 AM, Ian Lepore wrote: > > > I've added a new imx6 unified kernel config named IMX6. It has no > > compiled-in fdt, and can boot all three flavors of Wandboard when u-boot > > and ubldr load a dtb file. Folks should start using it and eventually > > the WANDBOARD* configs will go away when nobody needs them anymore. > > > > I build ubldr to load at address 11000000 and let it load the kernel at > > 12000000. (The kernel can load on any 1MB boundary, but ubldr doesn't > > make use of that feature yet.) ubldr will take a dtb file loaded by > > u-boot and pass it along to the kernel. Another option is to put > > the .dtb file in your /boot/kernel or /boot/modules directory, and ubldr > > will load it from there, using the filename set in the u-boot env var > > fdt_file. > > > > Unfortunately we can't do a single image that boots any wandboard, > > because u-boot itself has to be different for each board. This is what > > my u-boot env looks like on each wandboard: > > > > => printenv > > baudrate=115200 > > bootcmd=run ubnet > > bootdelay=1 > > console=ttymxc0 > > fdt_file=wandboard-dual.dtb > > loadaddr=11000000 > > loaderdev=net > > ubmmc=fatload mmc 0 ${loadaddr} ubldr; bootelf > > ubnet=dhcp ${loadaddr} /wand/boot/ubldr;bootelf > > > > Environment size: 265/8188 bytes > > > > The only thing that differs per-board is the fdt_file setting, and the > > u-boot binary itself. The "loaderdev=net" variable tells ubldr to load > > the kernel from the network device rather than disk. So now all my > > different model wandboards boot the same kernel and run from the same > > nfs root directory. > > > > -- Ian > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > > From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 18:38:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E18E275; Fri, 28 Feb 2014 18:38:58 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3781191E; Fri, 28 Feb 2014 18:38:54 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so3662680iec.5 for ; Fri, 28 Feb 2014 10:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version; bh=3UPKEhTrbl8My9ESswor5KY1M16YT99NxFSlK0hFB3s=; b=tVriGWI8uQhoDi3B4NBnzFwGuggDB34U6V0KptlmO4cHpQF0clrUPyqXojmm2Gp/hU 8I00VdW9R+8acY+aG4iNXcHRjJADjJazFzwK3zyEK7cR3UGYdiybeTAGThVbuL7E4ILT tKFubAPcTb6jPjDYCsZW8pVyLoxb6rw3hytBjr/RwLCcvhzYmyKrd6WX8S6OOXTObjEM FSAOR42nyXElclIprFFoKoPrYlK0IdWI7GWIUA0nLkcQq01qMsSGq4nYWVvbiG/7zc/N WlZXa6B+bWt8/DOxbxJGoGsXhSzimUGFLIyirGeKu24X0RchM4nEKox/uL1d/6pi+IWU EP9A== X-Received: by 10.42.215.207 with SMTP id hf15mr12605462icb.17.1393612733737; Fri, 28 Feb 2014 10:38:53 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qk2sm19587991igc.1.2014.02.28.10.38.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 10:38:52 -0800 (PST) From: Warner Losh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Fwd: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc sys/conf sys/tools/fdt Date: Fri, 28 Feb 2014 11:38:50 -0700 References: <201402281829.s1SITAQk019090@svn.freebsd.org> To: freebsd-arm , mips@freebsd.org, powerpc@freebsd.org, embedded@freebsd.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 18:38:58 -0000 Greetings, This commit changes how we do DTS -> DTB compiling. For the most part, = it should be a NOP, if all my tests are good, but I may have oopsed = something without realizing it. This commit does switch us back to the GPL dtc. That cannot be helped. = The BSDL one was too far away from working, but if that status ever changes, = I=92m happy to change the defaults back. This change was discussed by most of = the major workers in arm@ and mips@ land before changing back, and they = felt, as I do, that using vendor dts files unmodified was a bigger win for = embedded than the regression back to a GPL=92d piece of software when the BSDL=92d = one isn=92t up to the task today of coping with this new world order. If = that changes, then I=92d be happy to switch back. Hope this doesn=92t break anybody. I=92ll be around if it does. Warner Begin forwarded message: > From: Warner Losh > Subject: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts = sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc = sys/conf sys/tools/fdt > Date: February 28, 2014 at 11:29:10 AM MST > To: src-committers@freebsd.org, svn-src-all@freebsd.org, = svn-src-head@freebsd.org >=20 > Author: imp > Date: Fri Feb 28 18:29:09 2014 > New Revision: 262614 > URL: http://svnweb.freebsd.org/changeset/base/262614 >=20 > Log: > Integrate device-tree upstream files into the build process: > (1) Invoke cpp to bring in files via #include (although the old > /include/ stuff is supported still). > (2) bring in files from either vendor tree or freebsd-custom files > when building. > (3) move all dts* files from sys/boot/fdt/dts to > sys/boot/fdt/dts/${MACHINE} as appropriate. > (4) encode all the magic to do the build in sys/tools/fdt/make_dtb.sh > so that the different places in the tree use the exact same = logic. > (5) switch back to gpl dtc by default. the bsdl one in the tree has > significant issues not easily addressed by those unfamiliar with > the code. >=20 > Added: > head/sys/boot/fdt/dts/arm/ > head/sys/boot/fdt/dts/arm/am335x-evm.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/am335x-evm.dts > head/sys/boot/fdt/dts/arm/am335x.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/am335x.dtsi > head/sys/boot/fdt/dts/arm/bcm2835.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/bcm2835.dtsi > head/sys/boot/fdt/dts/arm/beaglebone-black.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/beaglebone-black.dts > head/sys/boot/fdt/dts/arm/beaglebone.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/beaglebone.dts > head/sys/boot/fdt/dts/arm/cubieboard.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/cubieboard.dts > head/sys/boot/fdt/dts/arm/cubieboard2.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/cubieboard2.dts > head/sys/boot/fdt/dts/arm/db78100.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/db78100.dts > head/sys/boot/fdt/dts/arm/db78460.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/db78460.dts > head/sys/boot/fdt/dts/arm/db88f5182.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f5182.dts > head/sys/boot/fdt/dts/arm/db88f5281.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f5281.dts > head/sys/boot/fdt/dts/arm/db88f6281.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f6281.dts > head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/digi-ccwmx53.dts > head/sys/boot/fdt/dts/arm/dockstar.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/dockstar.dts > head/sys/boot/fdt/dts/arm/dreamplug-1001.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/dreamplug-1001.dts > head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/dreamplug-1001N.dts > head/sys/boot/fdt/dts/arm/ea3250.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/ea3250.dts > head/sys/boot/fdt/dts/arm/efikamx.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/efikamx.dts > head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/exynos5250-arndale.dts > head/sys/boot/fdt/dts/arm/exynos5250.dtsi > - copied, changed from r262613, = head/sys/boot/fdt/dts/exynos5250.dtsi > head/sys/boot/fdt/dts/arm/imx51x.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/imx51x.dtsi > head/sys/boot/fdt/dts/arm/imx53-qsb.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/imx53-qsb.dts > head/sys/boot/fdt/dts/arm/imx53x.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/imx53x.dtsi > head/sys/boot/fdt/dts/arm/imx6.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/imx6.dtsi > head/sys/boot/fdt/dts/arm/p1020rdb.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/p1020rdb.dts > head/sys/boot/fdt/dts/arm/p2020ds.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/p2020ds.dts > head/sys/boot/fdt/dts/arm/p2041rdb.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041rdb.dts > head/sys/boot/fdt/dts/arm/p2041si.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041si.dtsi > head/sys/boot/fdt/dts/arm/p3041ds.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041ds.dts > head/sys/boot/fdt/dts/arm/p3041si.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041si.dtsi > head/sys/boot/fdt/dts/arm/p5020ds.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020ds.dts > head/sys/boot/fdt/dts/arm/p5020si.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020si.dtsi > head/sys/boot/fdt/dts/arm/pandaboard.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/pandaboard.dts > head/sys/boot/fdt/dts/arm/rk3188-radxa.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/rk3188-radxa.dts > head/sys/boot/fdt/dts/arm/rk3188.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/rk3188.dtsi > head/sys/boot/fdt/dts/arm/rpi.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/rpi.dts > head/sys/boot/fdt/dts/arm/sheevaplug.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/sheevaplug.dts > head/sys/boot/fdt/dts/arm/tegra20-paz00.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/tegra20-paz00.dts > head/sys/boot/fdt/dts/arm/tegra20.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/tegra20.dtsi > head/sys/boot/fdt/dts/arm/trimslice.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/trimslice.dts > head/sys/boot/fdt/dts/arm/ts7800.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/ts7800.dts > head/sys/boot/fdt/dts/arm/versatilepb.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/versatilepb.dts > head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts > head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/vybrid-cosmic.dts > head/sys/boot/fdt/dts/arm/vybrid-quartz.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/vybrid-quartz.dts > head/sys/boot/fdt/dts/arm/vybrid.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/vybrid.dtsi > head/sys/boot/fdt/dts/arm/wandboard-dual.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/wandboard-dual.dts > head/sys/boot/fdt/dts/arm/wandboard-quad.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/wandboard-quad.dts > head/sys/boot/fdt/dts/arm/wandboard-solo.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/wandboard-solo.dts > head/sys/boot/fdt/dts/arm/zedboard.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/zedboard.dts > head/sys/boot/fdt/dts/mips/ > head/sys/boot/fdt/dts/mips/beri-netfpga.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/beri-netfpga.dts > head/sys/boot/fdt/dts/mips/beri-sim.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/beri-sim.dts > head/sys/boot/fdt/dts/mips/beripad-de4.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/beripad-de4.dts > head/sys/boot/fdt/dts/mips/xlp-basic.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/xlp-basic.dts > head/sys/boot/fdt/dts/powerpc/ > head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/mpc8555cds.dts > head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/mpc8572ds.dts > head/sys/tools/fdt/make_dtb.sh (contents, props changed) > Deleted: > head/sys/boot/fdt/dts/am335x-evm.dts > head/sys/boot/fdt/dts/am335x.dtsi > head/sys/boot/fdt/dts/bcm2835.dtsi > head/sys/boot/fdt/dts/beaglebone-black.dts > head/sys/boot/fdt/dts/beaglebone.dts > head/sys/boot/fdt/dts/beri-netfpga.dts > head/sys/boot/fdt/dts/beri-sim.dts > head/sys/boot/fdt/dts/beripad-de4.dts > head/sys/boot/fdt/dts/cubieboard.dts > head/sys/boot/fdt/dts/cubieboard2.dts > head/sys/boot/fdt/dts/db78100.dts > head/sys/boot/fdt/dts/db78460.dts > head/sys/boot/fdt/dts/db88f5182.dts > head/sys/boot/fdt/dts/db88f5281.dts > head/sys/boot/fdt/dts/db88f6281.dts > head/sys/boot/fdt/dts/digi-ccwmx53.dts > head/sys/boot/fdt/dts/dockstar.dts > head/sys/boot/fdt/dts/dreamplug-1001.dts > head/sys/boot/fdt/dts/dreamplug-1001N.dts > head/sys/boot/fdt/dts/ea3250.dts > head/sys/boot/fdt/dts/efikamx.dts > head/sys/boot/fdt/dts/exynos5250-arndale.dts > head/sys/boot/fdt/dts/exynos5250.dtsi > head/sys/boot/fdt/dts/imx51x.dtsi > head/sys/boot/fdt/dts/imx53-qsb.dts > head/sys/boot/fdt/dts/imx53x.dtsi > head/sys/boot/fdt/dts/imx6.dtsi > head/sys/boot/fdt/dts/mpc8555cds.dts > head/sys/boot/fdt/dts/mpc8572ds.dts > head/sys/boot/fdt/dts/p1020rdb.dts > head/sys/boot/fdt/dts/p2020ds.dts > head/sys/boot/fdt/dts/p2041rdb.dts > head/sys/boot/fdt/dts/p2041si.dtsi > head/sys/boot/fdt/dts/p3041ds.dts > head/sys/boot/fdt/dts/p3041si.dtsi > head/sys/boot/fdt/dts/p5020ds.dts > head/sys/boot/fdt/dts/p5020si.dtsi > head/sys/boot/fdt/dts/pandaboard.dts > head/sys/boot/fdt/dts/rk3188-radxa.dts > head/sys/boot/fdt/dts/rk3188.dtsi > head/sys/boot/fdt/dts/rpi.dts > head/sys/boot/fdt/dts/sheevaplug.dts > head/sys/boot/fdt/dts/tegra20-paz00.dts > head/sys/boot/fdt/dts/tegra20.dtsi > head/sys/boot/fdt/dts/trimslice.dts > head/sys/boot/fdt/dts/ts7800.dts > head/sys/boot/fdt/dts/versatilepb.dts > head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts > head/sys/boot/fdt/dts/vybrid-cosmic.dts > head/sys/boot/fdt/dts/vybrid-quartz.dts > head/sys/boot/fdt/dts/vybrid.dtsi > head/sys/boot/fdt/dts/wandboard-dual.dts > head/sys/boot/fdt/dts/wandboard-quad.dts > head/sys/boot/fdt/dts/wandboard-solo.dts > head/sys/boot/fdt/dts/xlp-basic.dts > head/sys/boot/fdt/dts/zedboard.dts > Modified: > head/Makefile.inc1 > head/share/mk/bsd.own.mk > head/sys/conf/files >=20 > Modified: head/Makefile.inc1 > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/Makefile.inc1 Fri Feb 28 18:06:00 2014 = (r262613) > +++ head/Makefile.inc1 Fri Feb 28 18:29:09 2014 = (r262614) > @@ -1262,7 +1262,7 @@ _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/ > lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge > .endif >=20 > -# Default to building the BSDL DTC, but build the GPL one if users = explicitly > +# Default to building the GPL DTC, but build the BSDL one if users = explicitly > # request it. > _dtc=3D usr.bin/dtc > .if ${MK_GPL_DTC} !=3D "no" > @@ -1853,7 +1853,7 @@ builddtb: > echo "ERROR: FDT_DTS_FILE must be specified!"; \ > exit 1; \ > fi; \ > - if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} ]; then \ > + if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE} = ]; then \ > echo "ERROR: Specified DTS file (${FDT_DTS_FILE}) does = not \ > exist!"; \ > exit 1; \ > @@ -1863,9 +1863,9 @@ builddtb: > directory"; \ > fi > @PATH=3D${TMPPATH} \ > - dtc -O dtb -o \ > - ${DTBOUTPUTPATH}/`echo ${FDT_DTS_FILE} | cut -d. -f1`.dtb -b = 0 \ > - -p 1024 ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} > + ${.CURDIR}/sys/tools/fdt/make_dtb.sh ${.CURDIR}/sys \ > + ${FDT_DTS_FILE} \ > + ${DTBOUTPUTPATH}/`basename ${FDT_DTS_FILE} .dts` >=20 > ############### >=20 >=20 > Modified: head/share/mk/bsd.own.mk > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/share/mk/bsd.own.mk Fri Feb 28 18:06:00 2014 = (r262613) > +++ head/share/mk/bsd.own.mk Fri Feb 28 18:29:09 2014 = (r262614) > @@ -287,6 +287,7 @@ __DEFAULT_YES_OPTIONS =3D \ > GNU \ > GPIB \ > GPIO \ > + GPL_DTC \ > GROFF \ > HTML \ > ICONV \ > @@ -368,7 +369,6 @@ __DEFAULT_NO_OPTIONS =3D \ > CLANG_EXTRAS \ > CTF \ > DEBUG_FILES \ > - GPL_DTC \ > HESIOD \ > INSTALL_AS_USER \ > LLDB \ >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/am335x-evm.dts (from = r262613, head/sys/boot/fdt/dts/am335x-evm.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/am335x.dtsi (from = r262613, head/sys/boot/fdt/dts/am335x.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/bcm2835.dtsi (from = r262613, head/sys/boot/fdt/dts/bcm2835.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone-black.dts = (from r262613, head/sys/boot/fdt/dts/beaglebone-black.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone.dts (from = r262613, head/sys/boot/fdt/dts/beaglebone.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard.dts (from = r262613, head/sys/boot/fdt/dts/cubieboard.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard2.dts (from = r262613, head/sys/boot/fdt/dts/cubieboard2.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/db78100.dts (from = r262613, head/sys/boot/fdt/dts/db78100.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/db78460.dts (from = r262613, head/sys/boot/fdt/dts/db78460.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5182.dts (from = r262613, head/sys/boot/fdt/dts/db88f5182.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5281.dts (from = r262613, head/sys/boot/fdt/dts/db88f5281.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/db88f6281.dts (from = r262613, head/sys/boot/fdt/dts/db88f6281.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts (from = r262613, head/sys/boot/fdt/dts/digi-ccwmx53.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/dockstar.dts (from = r262613, head/sys/boot/fdt/dts/dockstar.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001.dts = (from r262613, head/sys/boot/fdt/dts/dreamplug-1001.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts = (from r262613, head/sys/boot/fdt/dts/dreamplug-1001N.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/ea3250.dts (from = r262613, head/sys/boot/fdt/dts/ea3250.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/efikamx.dts (from = r262613, head/sys/boot/fdt/dts/efikamx.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts = (from r262613, head/sys/boot/fdt/dts/exynos5250-arndale.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250.dtsi (from = r262613, head/sys/boot/fdt/dts/exynos5250.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/imx51x.dtsi (from = r262613, head/sys/boot/fdt/dts/imx51x.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/imx53-qsb.dts (from = r262613, head/sys/boot/fdt/dts/imx53-qsb.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/imx53x.dtsi (from = r262613, head/sys/boot/fdt/dts/imx53x.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/imx6.dtsi (from = r262613, head/sys/boot/fdt/dts/imx6.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p1020rdb.dts (from = r262613, head/sys/boot/fdt/dts/p1020rdb.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p2020ds.dts (from = r262613, head/sys/boot/fdt/dts/p2020ds.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p2041rdb.dts (from = r262613, head/sys/boot/fdt/dts/p2041rdb.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p2041si.dtsi (from = r262613, head/sys/boot/fdt/dts/p2041si.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p3041ds.dts (from = r262613, head/sys/boot/fdt/dts/p3041ds.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p3041si.dtsi (from = r262613, head/sys/boot/fdt/dts/p3041si.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p5020ds.dts (from = r262613, head/sys/boot/fdt/dts/p5020ds.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p5020si.dtsi (from = r262613, head/sys/boot/fdt/dts/p5020si.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/pandaboard.dts (from = r262613, head/sys/boot/fdt/dts/pandaboard.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188-radxa.dts (from = r262613, head/sys/boot/fdt/dts/rk3188-radxa.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188.dtsi (from = r262613, head/sys/boot/fdt/dts/rk3188.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/rpi.dts (from r262613, = head/sys/boot/fdt/dts/rpi.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/sheevaplug.dts (from = r262613, head/sys/boot/fdt/dts/sheevaplug.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20-paz00.dts (from = r262613, head/sys/boot/fdt/dts/tegra20-paz00.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20.dtsi (from = r262613, head/sys/boot/fdt/dts/tegra20.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/trimslice.dts (from = r262613, head/sys/boot/fdt/dts/trimslice.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/ts7800.dts (from = r262613, head/sys/boot/fdt/dts/ts7800.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/versatilepb.dts (from = r262613, head/sys/boot/fdt/dts/versatilepb.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts = (from r262613, head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts (from = r262613, head/sys/boot/fdt/dts/vybrid-cosmic.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-quartz.dts (from = r262613, head/sys/boot/fdt/dts/vybrid-quartz.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid.dtsi (from = r262613, head/sys/boot/fdt/dts/vybrid.dtsi) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-dual.dts = (from r262613, head/sys/boot/fdt/dts/wandboard-dual.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-quad.dts = (from r262613, head/sys/boot/fdt/dts/wandboard-quad.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-solo.dts = (from r262613, head/sys/boot/fdt/dts/wandboard-solo.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/zedboard.dts (from = r262613, head/sys/boot/fdt/dts/zedboard.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/mips/beri-netfpga.dts (from = r262613, head/sys/boot/fdt/dts/beri-netfpga.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/mips/beri-sim.dts (from = r262613, head/sys/boot/fdt/dts/beri-sim.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/mips/beripad-de4.dts (from = r262613, head/sys/boot/fdt/dts/beripad-de4.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/mips/xlp-basic.dts (from = r262613, head/sys/boot/fdt/dts/xlp-basic.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts = (from r262613, head/sys/boot/fdt/dts/mpc8555cds.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts (from = r262613, head/sys/boot/fdt/dts/mpc8572ds.dts) > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Modified: head/sys/conf/files > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/sys/conf/files Fri Feb 28 18:06:00 2014 = (r262613) > +++ head/sys/conf/files Fri Feb 28 18:29:09 2014 = (r262614) > @@ -14,11 +14,12 @@ acpi_quirks.h optional acpi = \ > # from the specified source (DTS) file: .dts -> = .dtb > # > fdt_dtb_file optional fdt \ > - compile-with "if [ -f $S/boot/fdt/dts/${FDT_DTS_FILE} ]; then = dtc -O dtb -o ${FDT_DTS_FILE:R}.dtb -b 0 -p 1024 = $S/boot/fdt/dts/${FDT_DTS_FILE}; fi" \ > + compile-with "sh $S/tools/fdt/make_dtb.sh $S ${FDT_DTS_FILE} = ${.CURDIR}/${FDT_DTS_FILE:R}.dtb" \ > no-obj no-implicit-rule before-depend \ > clean "${FDT_DTS_FILE:R}.dtb" > fdt_static_dtb.h optional fdt fdt_dtb_static \ > - compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} ." \ > + compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} = ${.CURDIR}" \ > + dependency "fdt_dtb_file" \ > no-obj no-implicit-rule before-depend \ > clean "fdt_static_dtb.h" > feeder_eq_gen.h optional sound = \ > @@ -1370,7 +1371,7 @@ dev/fb/splash.c optional sc = splash > dev/fdt/fdt_common.c optional fdt > dev/fdt/fdt_slicer.c optional fdt cfi | fdt nand > dev/fdt/fdt_static_dtb.S optional fdt fdt_dtb_static \ > - dependency "$S/boot/fdt/dts/${FDT_DTS_FILE}" > + dependency "$S/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE}" > dev/fdt/simplebus.c optional fdt > dev/fe/if_fe.c optional fe > dev/fe/if_fe_pccard.c optional fe pccard >=20 > Added: head/sys/tools/fdt/make_dtb.sh > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/sys/tools/fdt/make_dtb.sh Fri Feb 28 18:29:09 2014 = (r262614) > @@ -0,0 +1,11 @@ > +#!/bin/sh > +# > +# $FreeBSD$ > + > +# Script generates dtb file ($3) from dts source ($2) in build tree S = ($1) > +S=3D$1 > +dts=3D$2 > +dtb=3D$3 > + > +cpp -x assembler-with-cpp -I $S/gnu/dts/include -I = $S/boot/fdt/dts/${MACHINE} -I $S/gnu/dts/${MACHINE} -include $dts = /dev/null |=20 > + dtc -O dtb -o $dtb -b 0 -p 1024 -i $S/boot/fdt/dts -i = $S/gnu/dts/${MACHINE} >=20 From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 19:25:46 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83A7BA17; Fri, 28 Feb 2014 19:25:46 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 66DCF1D6E; Fri, 28 Feb 2014 19:25:46 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 279DE5E303; Fri, 28 Feb 2014 19:16:28 +0000 (UTC) Date: Fri, 28 Feb 2014 19:16:21 +0000 From: Andrew Turner To: Ian Lepore Subject: Re: wandboard / imx6 hard float Message-ID: <20140228191621.5dcb0c6d@bender.Home> In-Reply-To: <1393557827.1149.117.camel@revolution.hippie.lan> References: <1393557827.1149.117.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 19:25:46 -0000 On Thu, 27 Feb 2014 20:23:47 -0700 Ian Lepore wrote: > After some testing last week I determined that hard float works on > imx6, so I enabled it (added option VFP) in the kernel configs. To > check whether it's enabled, see if "sysctl hw.floatingpoint" is set > to 1. > > To actually use the hardware floating point you have to add some > options to CFLAGS: > > * For clang CFLAGS="-mfloat-abi=softfp" > * For gcc CFLAGS="-mfloat-abi=softfp -mfpu=vfp" > * You can do that on the make command line, in the environment, > or in /etc/make.conf. > > I think the implication of float-abi=softfp is that floating point > arguments are passed in integer registers, and we're losing some > performance with that. But as I vaguely understand it, we're still > missing some piece of support code to enable full eabihf. Maybe > somebody who knows the status of that can fill in my hand-wavy blanks. You are correct. There are three values for float-abi: * soft - Use the software float library, pass float vales in integer registers. This is what we are currently using. * softfp - Use the VFP unit where available, also pass float values in integer registers * hard - Use the VFP unit where available, pass float values in vfp registers. The soft and softfp variants of the ABI are binary compatible. I am considering changing the default armv6 ABI to softfp as, as far as I can tell, all SoCs we support have a VFP unit. However it may be better to move to a hard-float ABI and leave armv6 as it is. The main thing blocking adding support for armv6hf was clang was missing the FreeBSD code to handle it, and our version of GCC is too old to support vfp with ARM EABI hard float. I also have some changes to the EABI helper functions to add a hard-float version. Most software compiled for the hardfloat ABI will not need them, however someone may call one of these functions directly so we should provide them. Andrew From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 23:19:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48C6E7B9 for ; Fri, 28 Feb 2014 23:19:34 +0000 (UTC) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 303A91438 for ; Fri, 28 Feb 2014 23:19:34 +0000 (UTC) Received: from mail.nomadlogic.org (localhost [127.0.0.1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPS id 85EC8125EC6 for ; Fri, 28 Feb 2014 15:19:33 -0800 (PST) Received: from pop.rubicorp.com (unknown [72.34.113.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPSA id 6F4A6125EAD for ; Fri, 28 Feb 2014 15:19:33 -0800 (PST) Message-ID: <53111985.2010004@nomadlogic.org> Date: Fri, 28 Feb 2014 15:19:33 -0800 From: Pete Wright User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: bootelf required? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 23:19:34 -0000 hey there - i'm hacking on a utilite arm9 box and am running into an issue. the stock boot environment does not seem to include the "bootelf" command. looking at the "uEnv.txt" file generated by corchet-freebsd i have the following: > cat uEnv.txt uenvcmd=fatload mmc 0:1 88000000 ubldr;bootelf 88000000; unfortunately it does not look like the uboot environment on this system contains bootelf: CM-FX6 # bootelf Unknown command 'bootelf' - try 'help' CM-FX6 # boot bootm boot bootd bootz bootp is bootelf a hard requirement for our environment? alternatively - is there a way to run an alternative bootloader that supports bootelf? cheers! -pete -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 23:21:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B8A1806 for ; Fri, 28 Feb 2014 23:21:06 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 47DEF1442 for ; Fri, 28 Feb 2014 23:21:06 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id at1so4180616iec.28 for ; Fri, 28 Feb 2014 15:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hixoEXIUWveIXJnjMS4EgnMV669gEV0QhT+1epxFuiE=; b=KzIqe8LtdLOLg7+07zIoji2EHSuPMIQ7wmNIsfdeow13FCaHWBayvAuDyTafrpaZTD iIuwkHEpnsAz1+dhqPeW/V+JTQX3ZHiXrHoaIfux9D6c75QjeH8UfZlYb1bwFURmb7PN 9Hk+ahymSQHdPax1u/mJxWpvqddsezbmZoWhroE89xijZ7KWiqBsDHfPrsxs+wvZ0jot IPaBr5Z3D+suhaoRfjK/a+ZfhaVHiniiGJmTgEQsUBl/+W8W7V5ZEip4KwYRQ+GNILJz 39Cx2lhSgumArCMA5LXwKUbuyvIQVHEtxmnL0GQjoeCtuIwFHcPejRmHd5x2IDIE3JXW KB6w== X-Received: by 10.50.118.41 with SMTP id kj9mr7122312igb.1.1393629665759; Fri, 28 Feb 2014 15:21:05 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id vu3sm11869258igc.6.2014.02.28.15.21.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 15:21:04 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: bootelf required? From: Warner Losh In-Reply-To: <53111985.2010004@nomadlogic.org> Date: Fri, 28 Feb 2014 16:21:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <280DDC61-858D-4142-A688-005F3AD6AAD4@bsdimp.com> References: <53111985.2010004@nomadlogic.org> To: Pete Wright X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 23:21:06 -0000 Look up the =91start=92 symbol address and try =91go =92 where = likely is 0x880000c0 iirc. Warner On Feb 28, 2014, at 4:19 PM, Pete Wright wrote: > hey there - i'm hacking on a utilite arm9 box and am running into an > issue. the stock boot environment does not seem to include the > "bootelf" command. >=20 > looking at the "uEnv.txt" file generated by corchet-freebsd i have the > following: >> cat uEnv.txt > uenvcmd=3Dfatload mmc 0:1 88000000 ubldr;bootelf 88000000; >=20 >=20 > unfortunately it does not look like the uboot environment on this = system > contains bootelf: >=20 > CM-FX6 # bootelf > Unknown command 'bootelf' - try 'help' > CM-FX6 # boot > bootm boot bootd bootz bootp >=20 >=20 > is bootelf a hard requirement for our environment? alternatively - is > there a way to run an alternative bootloader that supports bootelf? >=20 > cheers! > -pete >=20 > --=20 > Pete Wright > pete@nomadlogic.org > twitter =3D> @nomadlogicLA >=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 Fri Feb 28 23:31:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66D23B0B for ; Fri, 28 Feb 2014 23:31:48 +0000 (UTC) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C77715AD for ; Fri, 28 Feb 2014 23:31:48 +0000 (UTC) Received: from mail.nomadlogic.org (localhost [127.0.0.1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPS id B786F125EC6; Fri, 28 Feb 2014 15:31:41 -0800 (PST) Received: from pop.rubicorp.com (unknown [72.34.113.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPSA id B00C0125EAD; Fri, 28 Feb 2014 15:31:41 -0800 (PST) Message-ID: <53111C5D.9050708@nomadlogic.org> Date: Fri, 28 Feb 2014 15:31:41 -0800 From: Pete Wright User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: bootelf required? References: <53111985.2010004@nomadlogic.org> <280DDC61-858D-4142-A688-005F3AD6AAD4@bsdimp.com> In-Reply-To: <280DDC61-858D-4142-A688-005F3AD6AAD4@bsdimp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 23:31:48 -0000 On 02/28/14 15:21, Warner Losh wrote: > Look up the start symbol address and try go where likely is 0x880000c0 > iirc. > thanks for the tip! doesn't seem to be helping - system hangs after: CM-FX6 # go 0x880000c0 ## Starting application at 0x880000C0 ... printenv contains the following line: run_eboot=echo Starting EBOOT ...; mmc dev ${mmcdev} && mmc rescan && mmc read 10042000 a 400 && go 10042000 which i manually ran like so: CM-FX6 # mmc dev 2 mmc2 is current device CM-FX6 # mmc rescan CM-FX6 # fatload mmc 2 0x10800000 ubldr reading ubldr 245290 bytes read CM-FX6 # mmc read 10042000 a 400 MMC read: dev # 2, block # 10, count 1024 ... 1024 blocks read: OK CM-FX6 # go 10042000 ## Starting application at 0x10042000 ... at which point the box becomes unresponsive and i manually power-cycle it. -pete -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-arm@FreeBSD.ORG Fri Feb 28 23:58:30 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A378569 for ; Fri, 28 Feb 2014 23:58:30 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B4C91763 for ; Fri, 28 Feb 2014 23:58:29 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJXJu-000HMu-Sy; Fri, 28 Feb 2014 23:58:23 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1SNwKxQ042644; Fri, 28 Feb 2014 16:58:20 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1913yilBQVqjHTabj75qX9k Subject: Re: bootelf required? From: Ian Lepore To: Pete Wright In-Reply-To: <53111C5D.9050708@nomadlogic.org> References: <53111985.2010004@nomadlogic.org> <280DDC61-858D-4142-A688-005F3AD6AAD4@bsdimp.com> <53111C5D.9050708@nomadlogic.org> Content-Type: text/plain; charset="windows-1251" Date: Fri, 28 Feb 2014 16:58:20 -0700 Message-ID: <1393631900.1149.191.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s1SNwKxQ042644 Cc: Warner Losh , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 23:58:30 -0000 The more likely entry point for ubldr is an offset of 0x54. If the version of u-boot is new and enables data caches, the "go" command doesn't disable them like our software expects (bootelf and bootm and the other more formal boot commands do). That might make the full sequence something like: fatload mmc 2 88000000 ubldr dcache off ; dcache flush go 88000054 For that to work, ubldr has to have been linked to run at 88000000. Whatever value crochet uses for UBLDR_LOADADDR=3D is what should be used as the loadaddr in u-boot. Any address in the range of 10000000 - 8x000000 should work. The 'x' factor is where u-boot itself lives, gotta be careful not to load over the top of it. Usually the 'bdinfo' command in u-boot will tell you about the memory u-boot itself uses. 88000000 is probably safe on a 2gb system. I'm not sure what the "mmc read 10042000 a 400 && go 10042000" thing is all about. -- Ian On Fri, 2014-02-28 at 15:31 -0800, Pete Wright wrote: >=20 > On 02/28/14 15:21, Warner Losh wrote: > > Look up the =91start=92 symbol address and try =91go =92 where = likely is 0x880000c0 > > iirc. > >=20 >=20 > thanks for the tip! doesn't seem to be helping - system hangs after: > CM-FX6 # go 0x880000c0 > ## Starting application at 0x880000C0 ... >=20 > printenv contains the following line: > run_eboot=3Decho Starting EBOOT ...; mmc dev ${mmcdev} && mmc rescan && > mmc read 10042000 a 400 && go 10042000 >=20 > which i manually ran like so: >=20 > CM-FX6 # mmc dev 2 > mmc2 is current device > CM-FX6 # mmc rescan > CM-FX6 # fatload mmc 2 0x10800000 ubldr > reading ubldr >=20 > 245290 bytes read > CM-FX6 # mmc read 10042000 a 400 >=20 > MMC read: dev # 2, block # 10, count 1024 ... 1024 blocks read: OK > CM-FX6 # go 10042000 > ## Starting application at 0x10042000 ... >=20 > at which point the box becomes unresponsive and i manually power-cycle = it. >=20 >=20 > -pete >=20 From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 00:55:11 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DB103C4 for ; Sat, 1 Mar 2014 00:55:11 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13B431C25 for ; Sat, 1 Mar 2014 00:55:10 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJYCl-0003Sf-Mx for freebsd-arm@FreeBSD.org; Sat, 01 Mar 2014 00:55:03 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s210t0VB042731 for ; Fri, 28 Feb 2014 17:55:00 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+9aYMB25olVPtxmNUVG2fr Subject: clang 3.4 and u-boot From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Feb 2014 17:55:00 -0700 Message-ID: <1393635300.1149.205.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 00:55:11 -0000 I just noticed this in 'cc --help' output for clang 3.4: -ffixed-r9 Reserve the r9 register (ARM only) Does that mean we can now build u-boot with clang and not need to build a recent gcc from ports? I don't have time to experiment with it right now, but that might shave some time off a crochet build. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 03:09:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F01B2CC; Sat, 1 Mar 2014 03:09:35 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F3AA517C1; Sat, 1 Mar 2014 03:09:34 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id y6so3252079igj.5 for ; Fri, 28 Feb 2014 19:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zartM2lf81q9gZK8MapqraIlQOOG0djL3xlh3Sblgxw=; b=JqqhJx3fY0PbKPncnglM/LpFrPcX3P+xjPIMLzZ/Luonck3RDu/WMngnA+b1orPGfc vQycKZlFYqF6XObbmKv9Q100bozPeBldwyDfjwXY2pTDp4oGmtnP4m3iTkn0KdInKDY7 Hehu+qbh/gjmYPsLFR2QvHg2DnxZGmEYOSMS5NNurzhomnCwXuS9pYIyHU4recHAiq/E Sq6DqVzJUb58YoDSrcL0XblfZl5hVrE1F6esI3zrZ6FA3ScQg2DYLvdMMjLWpGzBwqau E7njaB3FowVi4eedQ423oJfjYzl4Zp1SpxLvbdovFwVJB2+uFYlsoARDE/7vbiPDZ3+6 WNzg== MIME-Version: 1.0 X-Received: by 10.43.51.65 with SMTP id vh1mr14819511icb.24.1393643374359; Fri, 28 Feb 2014 19:09:34 -0800 (PST) Received: by 10.64.107.3 with HTTP; Fri, 28 Feb 2014 19:09:34 -0800 (PST) In-Reply-To: References: Date: Sat, 1 Mar 2014 11:09:34 +0800 Message-ID: Subject: Re: pcDuino support From: Ganbold Tsagaankhuu To: Odhiambo Washington Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 03:09:35 -0000 Hi, On Fri, Feb 28, 2014 at 11:55 PM, Odhiambo Washington wrote: > I'd like to buy something for my kids to play with and I was thing about > pcDuino, because of the nice specs. > > I'd like to know if the pcDuino support is complete now for FreeBSD-10. > We have just basic support of Allwinner A10/A20 SoC in src tree. Only usb ehci and gpio support is there. I hope EMAC ethernet controller and mmc drivers go into src tree soon maybe after some code polishes. So for kids maybe RPI or Beaglebone black can be useful, since these are more supported and yet not so expensive. Another options could be Freescale SoC boards like wandboard, phytec Cosmic board etc. hope this helps, Ganbold > > Should I buy it? If not, what is the BEST recommendation? > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254733744121/+254722743223 > "I can't hear you -- I'm using the scrambler." > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 07:13:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAF7ADB8 for ; Sat, 1 Mar 2014 07:13:52 +0000 (UTC) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B68AF10A4 for ; Sat, 1 Mar 2014 07:13:52 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id g12so2969366oah.22 for ; Fri, 28 Feb 2014 23:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=V0x2XzMBJ02uZDI6QU7KCNywFXDNmb7HACEBXmyDFYc=; b=bcoUDqo5M7v9Pu6nB5xBWsXe86HTIcT6z/HLSone0S89KADww51lJidSoArQWazzhs LxolCNABLM/FeIhkAk8hRkVZmhDHncbg7qCS+vOh4M/u7Nau3EekU+BizRpXTlRIFv5I ooSpEZnNzCq2BAO+6NuvjAeqTFmnx8+QfE1qQAAYIfA1woUNrAdMGPS9ImyUYOSQNIhF so1JgrjtmjFSER2pt/a/b9ZQfLHI7zfcQzWkRFB1KIx6FMDhLIZAdxgk2HVYUV0egLf7 0izRq+mPLjWq9OnuWShJOKcapuplNqyD5MGRMEbMWVPMcwOHT52Os0R+Zzy06ak8/GoO waWA== MIME-Version: 1.0 X-Received: by 10.182.142.5 with SMTP id rs5mr17768047obb.39.1393658032126; Fri, 28 Feb 2014 23:13:52 -0800 (PST) Received: by 10.182.108.103 with HTTP; Fri, 28 Feb 2014 23:13:52 -0800 (PST) Date: Fri, 28 Feb 2014 23:13:52 -0800 Message-ID: Subject: Raspberry pi packages From: jungleboogie0 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 07:13:53 -0000 Hi List, Thanks to the freeBSD team for working on ARM stuff. It's really exciting to know that freeBSD can run on x86 hardware and ARM processors. I hope both platforms continue to succeed well into 2014. I have a raspberry pi with freebsd 10-current loaded onto it and I'm trying to find a source for recent packages for pkg. I've installed from source on a few things, but, as we know, this is time consuming to do. Most of the package directories I have seen online are from December 2012 to July 2013. Is there a more recent package repository fro freeBSD arm raspberry pi? I have not yet used the crochet tool. Thanks for any assistance with this. Best, jungle -- ------- inum: 883510009902611 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 09:57:59 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26AE2B70; Sat, 1 Mar 2014 09:57:59 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 51DC71E3B; Sat, 1 Mar 2014 09:57:57 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s219vtM2007985; Sat, 1 Mar 2014 11:57:55 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s219vtsG007980; Sat, 1 Mar 2014 09:57:55 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 09:57:55 GMT Message-Id: <201403010957.s219vtsG007980@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 09:57:59 -0000 TB --- 2014-03-01 09:50:44 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 09:50:44 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 09:50:44 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 09:50:44 - cleaning the object tree TB --- 2014-03-01 09:50:44 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 09:51:34 - At svn revision 262652 TB --- 2014-03-01 09:51:35 - building world TB --- 2014-03-01 09:51:35 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 09:51:35 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 09:51:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 09:51:35 - SRCCONF=/dev/null TB --- 2014-03-01 09:51:35 - TARGET=arm TB --- 2014-03-01 09:51:35 - TARGET_ARCH=arm TB --- 2014-03-01 09:51:35 - TZ=UTC TB --- 2014-03-01 09:51:35 - __MAKE_CONF=/dev/null TB --- 2014-03-01 09:51:35 - cd /src TB --- 2014-03-01 09:51:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 09:51:45 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 09:57:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 09:57:55 - ERROR: failed to build world TB --- 2014-03-01 09:57:55 - 312.78 user 125.64 system 431.08 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 10:07:55 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05846C04; Sat, 1 Mar 2014 10:07:55 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 31BE21150; Sat, 1 Mar 2014 10:07:53 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21A7pbK052923; Sat, 1 Mar 2014 12:07:51 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21A7p0p052922; Sat, 1 Mar 2014 10:07:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 10:07:51 GMT Message-Id: <201403011007.s21A7p0p052922@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 10:07:55 -0000 TB --- 2014-03-01 10:00:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 10:00:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 10:00:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 10:00:28 - cleaning the object tree TB --- 2014-03-01 10:00:37 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 10:01:25 - At svn revision 262652 TB --- 2014-03-01 10:01:26 - building world TB --- 2014-03-01 10:01:26 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 10:01:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 10:01:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 10:01:26 - SRCCONF=/dev/null TB --- 2014-03-01 10:01:26 - TARGET=arm TB --- 2014-03-01 10:01:26 - TARGET_ARCH=arm TB --- 2014-03-01 10:01:26 - TZ=UTC TB --- 2014-03-01 10:01:26 - __MAKE_CONF=/dev/null TB --- 2014-03-01 10:01:26 - cd /src TB --- 2014-03-01 10:01:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 10:01:37 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 10:07:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 10:07:51 - ERROR: failed to build world TB --- 2014-03-01 10:07:51 - 314.59 user 135.96 system 442.69 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 10:18:00 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FD05B6A; Sat, 1 Mar 2014 10:18:00 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBC341319; Sat, 1 Mar 2014 10:17:59 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21AHu5k097710; Sat, 1 Mar 2014 12:17:56 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21AHuDM097709; Sat, 1 Mar 2014 10:17:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 10:17:56 GMT Message-Id: <201403011017.s21AHuDM097709@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 10:18:00 -0000 TB --- 2014-03-01 10:10:31 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 10:10:31 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 10:10:31 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 10:10:31 - cleaning the object tree TB --- 2014-03-01 10:10:40 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 10:11:31 - At svn revision 262653 TB --- 2014-03-01 10:11:32 - building world TB --- 2014-03-01 10:11:32 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 10:11:32 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 10:11:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 10:11:32 - SRCCONF=/dev/null TB --- 2014-03-01 10:11:32 - TARGET=arm TB --- 2014-03-01 10:11:32 - TARGET_ARCH=arm TB --- 2014-03-01 10:11:32 - TZ=UTC TB --- 2014-03-01 10:11:32 - __MAKE_CONF=/dev/null TB --- 2014-03-01 10:11:32 - cd /src TB --- 2014-03-01 10:11:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 10:11:42 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 10:17:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 10:17:56 - ERROR: failed to build world TB --- 2014-03-01 10:17:56 - 314.64 user 138.33 system 445.34 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 10:28:00 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21ACF862; Sat, 1 Mar 2014 10:28:00 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C53A152A; Sat, 1 Mar 2014 10:27:58 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21ARuYc042709; Sat, 1 Mar 2014 12:27:56 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21ARuPR042708; Sat, 1 Mar 2014 10:27:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 10:27:56 GMT Message-Id: <201403011027.s21ARuPR042708@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 10:28:00 -0000 TB --- 2014-03-01 10:20:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 10:20:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 10:20:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 10:20:28 - cleaning the object tree TB --- 2014-03-01 10:20:34 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 10:21:29 - At svn revision 262653 TB --- 2014-03-01 10:21:30 - building world TB --- 2014-03-01 10:21:30 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 10:21:30 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 10:21:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 10:21:30 - SRCCONF=/dev/null TB --- 2014-03-01 10:21:30 - TARGET=arm TB --- 2014-03-01 10:21:30 - TARGET_ARCH=arm TB --- 2014-03-01 10:21:30 - TZ=UTC TB --- 2014-03-01 10:21:30 - __MAKE_CONF=/dev/null TB --- 2014-03-01 10:21:30 - cd /src TB --- 2014-03-01 10:21:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 10:21:41 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 10:27:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 10:27:56 - ERROR: failed to build world TB --- 2014-03-01 10:27:56 - 315.66 user 139.70 system 447.49 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 10:32:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04AF8128 for ; Sat, 1 Mar 2014 10:32:27 +0000 (UTC) Received: from thetys.cloudzeeland.nl (webrz.xs4all.nl [83.161.133.58]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B83FC1671 for ; Sat, 1 Mar 2014 10:32:26 +0000 (UTC) Received: from thetys.cloudzeeland.nl (thetys.cloudzeeland.nl [10.10.10.31]) by thetys.cloudzeeland.nl (Postfix) with ESMTP id 898571644573 for ; Sat, 1 Mar 2014 11:31:56 +0100 (CET) Received: from [10.10.10.70] (sedna.cloudzeeland.nl [10.10.10.70]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by thetys.cloudzeeland.nl (Postfix) with ESMTPSA id 6ABA61644571 for ; Sat, 1 Mar 2014 11:31:56 +0100 (CET) Message-ID: <5311B739.1050705@cloudzeeland.nl> Date: Sat, 01 Mar 2014 11:32:25 +0100 From: Jos Chrispijn Organization: Pi for President! User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Group topics Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on thetys.cloudzeeland.nl X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 10:32:27 -0000 [ARM nub] Can you tell me which topics I should put here as some may be better sent to the BSD mailing list instead of the ARM mailinglist. Are there specific ports and BSD releated topics that I can also put in this group? thank you, Jos -- Jos Chrispijn 'Nope, it doesn't have a standard case...' From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 10:37:59 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9B4176F; Sat, 1 Mar 2014 10:37:59 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 016B41719; Sat, 1 Mar 2014 10:37:58 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21AbtVu087134; Sat, 1 Mar 2014 12:37:55 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21AbtuL087131; Sat, 1 Mar 2014 10:37:55 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 10:37:55 GMT Message-Id: <201403011037.s21AbtuL087131@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 10:38:00 -0000 TB --- 2014-03-01 10:30:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 10:30:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 10:30:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 10:30:28 - cleaning the object tree TB --- 2014-03-01 10:30:35 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 10:31:31 - At svn revision 262653 TB --- 2014-03-01 10:31:32 - building world TB --- 2014-03-01 10:31:32 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 10:31:32 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 10:31:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 10:31:32 - SRCCONF=/dev/null TB --- 2014-03-01 10:31:32 - TARGET=arm TB --- 2014-03-01 10:31:32 - TARGET_ARCH=arm TB --- 2014-03-01 10:31:32 - TZ=UTC TB --- 2014-03-01 10:31:32 - __MAKE_CONF=/dev/null TB --- 2014-03-01 10:31:32 - cd /src TB --- 2014-03-01 10:31:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 10:31:43 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 10:37:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 10:37:55 - ERROR: failed to build world TB --- 2014-03-01 10:37:55 - 313.76 user 140.74 system 446.94 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 10:44:44 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B37A4610 for ; Sat, 1 Mar 2014 10:44:44 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4768018BF for ; Sat, 1 Mar 2014 10:44:44 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id BA54BB833; Sat, 1 Mar 2014 12:44:31 +0200 (SAST) Date: Sat, 1 Mar 2014 12:44:31 +0200 From: John Hay To: freebsd-arm@FreeBSD.org Subject: Re: status of AVILA and CAMBRIA code Message-ID: <20140301104431.GA82389@zibbi.meraka.csir.co.za> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com> <20140221130530.GA202@zibbi.meraka.csir.co.za> <1393001249.1145.98.camel@revolution.hippie.lan> <20140224132614.GA31984@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140224132614.GA31984@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 10:44:44 -0000 On Mon, Feb 24, 2014 at 03:26:14PM +0200, John Hay wrote: > Hi Ian, > > On Fri, Feb 21, 2014 at 09:47:29AM -0700, Ian Lepore wrote: > > On Fri, 2014-02-21 at 15:05 +0200, John Hay wrote: > > > On Wed, Feb 19, 2014 at 09:29:38AM -0800, John-Mark Gurney wrote: > > > > John Hay wrote this message on Wed, Feb 19, 2014 at 12:59 +0200: > > > > > What is the status of AVILA and CAMBRIA builds in our tree? Have anybody > > > > > had success recently? From the lists I can see that other people have > > > > > also asked in September 2013, but I cannot figure out if there was any > > > > > successes at that stage. :-) > > > ... > > > > > > > > > > Somewhere along the line the ethernet npe0 device also broke, writing > > > > > "npe0: npestart_locked: too many fragments 0". But I did not test the > > > > > npe0 device with every build and only realised it this morning, so I > > > > > do not know where it broke. :-) It looks like adding a few bus_dmamap_unload()s in if_npe.c fixed it. Here is my patch that seems to fix it. Does it look ok? Can I commit it? Index: xscale/ixp425/if_npe.c =================================================================== --- xscale/ixp425/if_npe.c (revision 246713) +++ xscale/ixp425/if_npe.c (working copy) @@ -1037,6 +1037,8 @@ sc = npes[NPE_QM_Q_NPE(entry)]; npe = P2V(NPE_QM_Q_ADDR(entry), &sc->txdma); + bus_dmamap_sync(sc->txdma.mtag, npe->ix_map, BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->txdma.mtag, npe->ix_map); m_freem(npe->ix_m); npe->ix_m = NULL; @@ -1112,6 +1114,12 @@ DPRINTF(sc, "%s: entry 0x%x neaddr 0x%x ne_len 0x%x\n", __func__, entry, npe->ix_neaddr, npe->ix_hw->ix_ne[0].len); + + /* Flush mbuf memory for rx'd data */ + bus_dmamap_sync(dma->mtag, npe->ix_map, + BUS_DMASYNC_POSTREAD); + bus_dmamap_unload(dma->mtag, npe->ix_map); + /* * Allocate a new mbuf to replenish the rx buffer. * If doing so fails we drop the rx'd frame so we @@ -1126,10 +1134,6 @@ struct npehwbuf *hw = npe->ix_hw; struct ifnet *ifp = sc->sc_ifp; - /* Flush mbuf memory for rx'd data */ - bus_dmamap_sync(dma->mtag, npe->ix_map, - BUS_DMASYNC_POSTREAD); - /* XXX flush hw buffer; works now 'cuz coherent */ /* set m_len etc. per rx frame size */ mrx->m_len = be32toh(hw->ix_ne[0].len) & 0xffff; John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 10:47:47 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C24DE680; Sat, 1 Mar 2014 10:47:47 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EEF4118FE; Sat, 1 Mar 2014 10:47:46 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21AlhWw031138; Sat, 1 Mar 2014 12:47:43 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21AlhFw031135; Sat, 1 Mar 2014 10:47:43 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 10:47:43 GMT Message-Id: <201403011047.s21AlhFw031135@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 10:47:47 -0000 TB --- 2014-03-01 10:40:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 10:40:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 10:40:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 10:40:28 - cleaning the object tree TB --- 2014-03-01 10:40:36 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 10:41:23 - At svn revision 262653 TB --- 2014-03-01 10:41:24 - building world TB --- 2014-03-01 10:41:24 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 10:41:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 10:41:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 10:41:24 - SRCCONF=/dev/null TB --- 2014-03-01 10:41:24 - TARGET=arm TB --- 2014-03-01 10:41:24 - TARGET_ARCH=arm TB --- 2014-03-01 10:41:24 - TZ=UTC TB --- 2014-03-01 10:41:24 - __MAKE_CONF=/dev/null TB --- 2014-03-01 10:41:24 - cd /src TB --- 2014-03-01 10:41:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 10:41:34 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 10:47:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 10:47:43 - ERROR: failed to build world TB --- 2014-03-01 10:47:43 - 316.71 user 125.48 system 435.02 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 10:58:19 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46D3F511; Sat, 1 Mar 2014 10:58:19 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53AB91AD1; Sat, 1 Mar 2014 10:58:17 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21Avs1a077225; Sat, 1 Mar 2014 12:57:54 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21AvsO2077224; Sat, 1 Mar 2014 10:57:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 10:57:54 GMT Message-Id: <201403011057.s21AvsO2077224@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 10:58:19 -0000 TB --- 2014-03-01 10:50:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 10:50:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 10:50:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 10:50:28 - cleaning the object tree TB --- 2014-03-01 10:50:38 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 10:51:27 - At svn revision 262653 TB --- 2014-03-01 10:51:28 - building world TB --- 2014-03-01 10:51:28 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 10:51:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 10:51:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 10:51:28 - SRCCONF=/dev/null TB --- 2014-03-01 10:51:28 - TARGET=arm TB --- 2014-03-01 10:51:28 - TARGET_ARCH=arm TB --- 2014-03-01 10:51:28 - TZ=UTC TB --- 2014-03-01 10:51:28 - __MAKE_CONF=/dev/null TB --- 2014-03-01 10:51:28 - cd /src TB --- 2014-03-01 10:51:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 10:51:39 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 10:57:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 10:57:54 - ERROR: failed to build world TB --- 2014-03-01 10:57:54 - 315.64 user 136.36 system 445.41 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 11:07:56 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60B3939B; Sat, 1 Mar 2014 11:07:56 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3FC6D1CF8; Sat, 1 Mar 2014 11:07:54 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21B7qb4022139; Sat, 1 Mar 2014 13:07:52 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21B7qEj022138; Sat, 1 Mar 2014 11:07:52 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 11:07:52 GMT Message-Id: <201403011107.s21B7qEj022138@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 11:07:56 -0000 TB --- 2014-03-01 11:00:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 11:00:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 11:00:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 11:00:28 - cleaning the object tree TB --- 2014-03-01 11:00:38 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 11:01:27 - At svn revision 262653 TB --- 2014-03-01 11:01:28 - building world TB --- 2014-03-01 11:01:28 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 11:01:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 11:01:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 11:01:28 - SRCCONF=/dev/null TB --- 2014-03-01 11:01:28 - TARGET=arm TB --- 2014-03-01 11:01:28 - TARGET_ARCH=arm TB --- 2014-03-01 11:01:28 - TZ=UTC TB --- 2014-03-01 11:01:28 - __MAKE_CONF=/dev/null TB --- 2014-03-01 11:01:28 - cd /src TB --- 2014-03-01 11:01:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 11:01:39 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 11:07:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 11:07:52 - ERROR: failed to build world TB --- 2014-03-01 11:07:52 - 315.46 user 135.61 system 443.29 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 11:17:55 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D409358; Sat, 1 Mar 2014 11:17:55 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 491101065; Sat, 1 Mar 2014 11:17:53 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21BHpBt066936; Sat, 1 Mar 2014 13:17:51 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21BHp58066934; Sat, 1 Mar 2014 11:17:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 11:17:51 GMT Message-Id: <201403011117.s21BHp58066934@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 11:17:55 -0000 TB --- 2014-03-01 11:10:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 11:10:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 11:10:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 11:10:28 - cleaning the object tree TB --- 2014-03-01 11:10:36 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 11:11:26 - At svn revision 262653 TB --- 2014-03-01 11:11:27 - building world TB --- 2014-03-01 11:11:27 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 11:11:27 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 11:11:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 11:11:27 - SRCCONF=/dev/null TB --- 2014-03-01 11:11:27 - TARGET=arm TB --- 2014-03-01 11:11:27 - TARGET_ARCH=arm TB --- 2014-03-01 11:11:27 - TZ=UTC TB --- 2014-03-01 11:11:27 - __MAKE_CONF=/dev/null TB --- 2014-03-01 11:11:27 - cd /src TB --- 2014-03-01 11:11:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 11:11:38 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 11:17:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 11:17:51 - ERROR: failed to build world TB --- 2014-03-01 11:17:51 - 314.83 user 135.18 system 442.50 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 11:27:54 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BD7B26D; Sat, 1 Mar 2014 11:27:54 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87E171288; Sat, 1 Mar 2014 11:27:53 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21BRoqs008366; Sat, 1 Mar 2014 13:27:50 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21BRoxA008365; Sat, 1 Mar 2014 11:27:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 11:27:50 GMT Message-Id: <201403011127.s21BRoxA008365@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 11:27:54 -0000 TB --- 2014-03-01 11:20:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 11:20:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 11:20:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 11:20:28 - cleaning the object tree TB --- 2014-03-01 11:20:36 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 11:21:29 - At svn revision 262653 TB --- 2014-03-01 11:21:30 - building world TB --- 2014-03-01 11:21:30 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 11:21:30 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 11:21:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 11:21:30 - SRCCONF=/dev/null TB --- 2014-03-01 11:21:30 - TARGET=arm TB --- 2014-03-01 11:21:30 - TARGET_ARCH=arm TB --- 2014-03-01 11:21:30 - TZ=UTC TB --- 2014-03-01 11:21:30 - __MAKE_CONF=/dev/null TB --- 2014-03-01 11:21:30 - cd /src TB --- 2014-03-01 11:21:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 11:21:41 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 11:27:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 11:27:50 - ERROR: failed to build world TB --- 2014-03-01 11:27:50 - 312.62 user 136.70 system 441.70 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 11:37:54 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A35A7F20; Sat, 1 Mar 2014 11:37:54 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CDF9514C0; Sat, 1 Mar 2014 11:37:53 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21Bbo6k052908; Sat, 1 Mar 2014 13:37:50 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21BboeU052900; Sat, 1 Mar 2014 11:37:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 11:37:50 GMT Message-Id: <201403011137.s21BboeU052900@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 11:37:54 -0000 TB --- 2014-03-01 11:30:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 11:30:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 11:30:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 11:30:28 - cleaning the object tree TB --- 2014-03-01 11:30:36 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 11:31:28 - At svn revision 262653 TB --- 2014-03-01 11:31:29 - building world TB --- 2014-03-01 11:31:29 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 11:31:29 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 11:31:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 11:31:29 - SRCCONF=/dev/null TB --- 2014-03-01 11:31:29 - TARGET=arm TB --- 2014-03-01 11:31:29 - TARGET_ARCH=arm TB --- 2014-03-01 11:31:29 - TZ=UTC TB --- 2014-03-01 11:31:29 - __MAKE_CONF=/dev/null TB --- 2014-03-01 11:31:29 - cd /src TB --- 2014-03-01 11:31:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 11:31:39 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 11:37:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 11:37:50 - ERROR: failed to build world TB --- 2014-03-01 11:37:50 - 313.51 user 135.93 system 441.73 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 11:47:54 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79AE2F81; Sat, 1 Mar 2014 11:47:54 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A84DA1656; Sat, 1 Mar 2014 11:47:53 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21BloEc097817; Sat, 1 Mar 2014 13:47:50 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21BloBr097813; Sat, 1 Mar 2014 11:47:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 11:47:50 GMT Message-Id: <201403011147.s21BloBr097813@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 11:47:54 -0000 TB --- 2014-03-01 11:40:29 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 11:40:29 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 11:40:29 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 11:40:29 - cleaning the object tree TB --- 2014-03-01 11:40:38 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 11:41:25 - At svn revision 262653 TB --- 2014-03-01 11:41:26 - building world TB --- 2014-03-01 11:41:26 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 11:41:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 11:41:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 11:41:26 - SRCCONF=/dev/null TB --- 2014-03-01 11:41:26 - TARGET=arm TB --- 2014-03-01 11:41:26 - TARGET_ARCH=arm TB --- 2014-03-01 11:41:26 - TZ=UTC TB --- 2014-03-01 11:41:26 - __MAKE_CONF=/dev/null TB --- 2014-03-01 11:41:26 - cd /src TB --- 2014-03-01 11:41:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 11:41:36 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 11:47:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 11:47:50 - ERROR: failed to build world TB --- 2014-03-01 11:47:50 - 315.71 user 133.52 system 441.30 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 11:57:48 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B40CBCEC; Sat, 1 Mar 2014 11:57:48 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF6FB17B9; Sat, 1 Mar 2014 11:57:47 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21BviLh041050; Sat, 1 Mar 2014 13:57:44 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21BviiA040881; Sat, 1 Mar 2014 11:57:44 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 11:57:44 GMT Message-Id: <201403011157.s21BviiA040881@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 11:57:48 -0000 TB --- 2014-03-01 11:50:29 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 11:50:29 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 11:50:29 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 11:50:29 - cleaning the object tree TB --- 2014-03-01 11:50:37 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 11:51:24 - At svn revision 262653 TB --- 2014-03-01 11:51:25 - building world TB --- 2014-03-01 11:51:25 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 11:51:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 11:51:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 11:51:25 - SRCCONF=/dev/null TB --- 2014-03-01 11:51:25 - TARGET=arm TB --- 2014-03-01 11:51:25 - TARGET_ARCH=arm TB --- 2014-03-01 11:51:25 - TZ=UTC TB --- 2014-03-01 11:51:25 - __MAKE_CONF=/dev/null TB --- 2014-03-01 11:51:25 - cd /src TB --- 2014-03-01 11:51:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 11:51:36 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 11:57:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 11:57:44 - ERROR: failed to build world TB --- 2014-03-01 11:57:44 - 315.30 user 127.39 system 435.02 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 12:07:55 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC0BFAF9; Sat, 1 Mar 2014 12:07:55 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E70721935; Sat, 1 Mar 2014 12:07:54 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21C7pV2087365; Sat, 1 Mar 2014 14:07:51 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21C7p3R087360; Sat, 1 Mar 2014 12:07:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 12:07:51 GMT Message-Id: <201403011207.s21C7p3R087360@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 12:07:55 -0000 TB --- 2014-03-01 12:00:29 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 12:00:29 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 12:00:29 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 12:00:29 - cleaning the object tree TB --- 2014-03-01 12:00:39 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 12:01:28 - At svn revision 262653 TB --- 2014-03-01 12:01:29 - building world TB --- 2014-03-01 12:01:29 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 12:01:29 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 12:01:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 12:01:29 - SRCCONF=/dev/null TB --- 2014-03-01 12:01:29 - TARGET=arm TB --- 2014-03-01 12:01:29 - TARGET_ARCH=arm TB --- 2014-03-01 12:01:29 - TZ=UTC TB --- 2014-03-01 12:01:29 - __MAKE_CONF=/dev/null TB --- 2014-03-01 12:01:29 - cd /src TB --- 2014-03-01 12:01:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 12:01:39 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 12:07:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 12:07:51 - ERROR: failed to build world TB --- 2014-03-01 12:07:51 - 315.11 user 135.12 system 442.80 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 12:18:01 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D338C8C8; Sat, 1 Mar 2014 12:18:01 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D64F1AB3; Sat, 1 Mar 2014 12:18:00 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21CHvCC032616; Sat, 1 Mar 2014 14:17:57 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21CHvo2032615; Sat, 1 Mar 2014 12:17:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 12:17:57 GMT Message-Id: <201403011217.s21CHvo2032615@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 12:18:02 -0000 TB --- 2014-03-01 12:10:29 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 12:10:29 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 12:10:29 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 12:10:29 - cleaning the object tree TB --- 2014-03-01 12:10:38 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 12:11:31 - At svn revision 262653 TB --- 2014-03-01 12:11:32 - building world TB --- 2014-03-01 12:11:32 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 12:11:32 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 12:11:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 12:11:32 - SRCCONF=/dev/null TB --- 2014-03-01 12:11:32 - TARGET=arm TB --- 2014-03-01 12:11:32 - TARGET_ARCH=arm TB --- 2014-03-01 12:11:32 - TZ=UTC TB --- 2014-03-01 12:11:32 - __MAKE_CONF=/dev/null TB --- 2014-03-01 12:11:32 - cd /src TB --- 2014-03-01 12:11:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 12:11:43 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 12:17:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 12:17:57 - ERROR: failed to build world TB --- 2014-03-01 12:17:57 - 315.71 user 141.02 system 448.78 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 12:27:58 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 179F88DD; Sat, 1 Mar 2014 12:27:58 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3AFAC1C5A; Sat, 1 Mar 2014 12:27:56 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21CRsOs077415; Sat, 1 Mar 2014 14:27:54 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21CRse6077413; Sat, 1 Mar 2014 12:27:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 12:27:54 GMT Message-Id: <201403011227.s21CRse6077413@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 12:27:58 -0000 TB --- 2014-03-01 12:20:29 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 12:20:29 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 12:20:29 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 12:20:29 - cleaning the object tree TB --- 2014-03-01 12:20:35 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 12:21:28 - At svn revision 262653 TB --- 2014-03-01 12:21:29 - building world TB --- 2014-03-01 12:21:29 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 12:21:29 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 12:21:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 12:21:29 - SRCCONF=/dev/null TB --- 2014-03-01 12:21:29 - TARGET=arm TB --- 2014-03-01 12:21:29 - TARGET_ARCH=arm TB --- 2014-03-01 12:21:29 - TZ=UTC TB --- 2014-03-01 12:21:29 - __MAKE_CONF=/dev/null TB --- 2014-03-01 12:21:29 - cd /src TB --- 2014-03-01 12:21:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 12:21:40 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 12:27:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 12:27:54 - ERROR: failed to build world TB --- 2014-03-01 12:27:54 - 314.36 user 137.97 system 445.04 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 12:37:54 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A41C5764; Sat, 1 Mar 2014 12:37:54 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D18221DE2; Sat, 1 Mar 2014 12:37:53 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21CbooO022346; Sat, 1 Mar 2014 14:37:50 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21CboYf022345; Sat, 1 Mar 2014 12:37:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 12:37:50 GMT Message-Id: <201403011237.s21CboYf022345@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 12:37:54 -0000 TB --- 2014-03-01 12:30:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 12:30:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 12:30:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 12:30:28 - cleaning the object tree TB --- 2014-03-01 12:30:38 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 12:31:24 - At svn revision 262653 TB --- 2014-03-01 12:31:25 - building world TB --- 2014-03-01 12:31:25 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 12:31:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 12:31:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 12:31:25 - SRCCONF=/dev/null TB --- 2014-03-01 12:31:25 - TARGET=arm TB --- 2014-03-01 12:31:25 - TARGET_ARCH=arm TB --- 2014-03-01 12:31:25 - TZ=UTC TB --- 2014-03-01 12:31:25 - __MAKE_CONF=/dev/null TB --- 2014-03-01 12:31:25 - cd /src TB --- 2014-03-01 12:31:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 12:31:36 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 12:37:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 12:37:50 - ERROR: failed to build world TB --- 2014-03-01 12:37:50 - 316.05 user 134.46 system 442.80 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 12:47:58 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F16B6D9; Sat, 1 Mar 2014 12:47:58 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B58D107E; Sat, 1 Mar 2014 12:47:57 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21Clssi067141; Sat, 1 Mar 2014 14:47:54 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21ClsVh067139; Sat, 1 Mar 2014 12:47:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 12:47:54 GMT Message-Id: <201403011247.s21ClsVh067139@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 12:47:58 -0000 TB --- 2014-03-01 12:40:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 12:40:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 12:40:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 12:40:28 - cleaning the object tree TB --- 2014-03-01 12:40:36 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 12:41:27 - At svn revision 262653 TB --- 2014-03-01 12:41:28 - building world TB --- 2014-03-01 12:41:28 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 12:41:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 12:41:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 12:41:28 - SRCCONF=/dev/null TB --- 2014-03-01 12:41:28 - TARGET=arm TB --- 2014-03-01 12:41:28 - TARGET_ARCH=arm TB --- 2014-03-01 12:41:28 - TZ=UTC TB --- 2014-03-01 12:41:28 - __MAKE_CONF=/dev/null TB --- 2014-03-01 12:41:28 - cd /src TB --- 2014-03-01 12:41:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 12:41:39 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 12:47:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 12:47:54 - ERROR: failed to build world TB --- 2014-03-01 12:47:54 - 314.43 user 140.04 system 446.35 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 12:57:56 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2AB55E9; Sat, 1 Mar 2014 12:57:56 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0B1511ED; Sat, 1 Mar 2014 12:57:55 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21CvqFk011722; Sat, 1 Mar 2014 14:57:52 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21CvqIf011516; Sat, 1 Mar 2014 12:57:52 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 12:57:52 GMT Message-Id: <201403011257.s21CvqIf011516@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 12:57:56 -0000 TB --- 2014-03-01 12:50:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 12:50:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 12:50:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 12:50:28 - cleaning the object tree TB --- 2014-03-01 12:50:36 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 12:51:29 - At svn revision 262653 TB --- 2014-03-01 12:51:30 - building world TB --- 2014-03-01 12:51:30 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 12:51:30 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 12:51:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 12:51:30 - SRCCONF=/dev/null TB --- 2014-03-01 12:51:30 - TARGET=arm TB --- 2014-03-01 12:51:30 - TARGET_ARCH=arm TB --- 2014-03-01 12:51:30 - TZ=UTC TB --- 2014-03-01 12:51:30 - __MAKE_CONF=/dev/null TB --- 2014-03-01 12:51:30 - cd /src TB --- 2014-03-01 12:51:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 12:51:40 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 12:57:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 12:57:51 - ERROR: failed to build world TB --- 2014-03-01 12:57:51 - 314.17 user 137.07 system 443.62 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 13:07:59 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 570C55F6; Sat, 1 Mar 2014 13:07:59 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84F89135C; Sat, 1 Mar 2014 13:07:58 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21D7to9056830; Sat, 1 Mar 2014 15:07:55 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21D7tbc056829; Sat, 1 Mar 2014 13:07:55 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 13:07:55 GMT Message-Id: <201403011307.s21D7tbc056829@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 13:07:59 -0000 TB --- 2014-03-01 13:00:28 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 13:00:28 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 13:00:28 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 13:00:28 - cleaning the object tree TB --- 2014-03-01 13:00:34 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 13:01:30 - At svn revision 262653 TB --- 2014-03-01 13:01:31 - building world TB --- 2014-03-01 13:01:31 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 13:01:31 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 13:01:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 13:01:31 - SRCCONF=/dev/null TB --- 2014-03-01 13:01:31 - TARGET=arm TB --- 2014-03-01 13:01:31 - TARGET_ARCH=arm TB --- 2014-03-01 13:01:31 - TZ=UTC TB --- 2014-03-01 13:01:31 - __MAKE_CONF=/dev/null TB --- 2014-03-01 13:01:31 - cd /src TB --- 2014-03-01 13:01:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 13:01:42 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.sbin/nmtree/../../contrib/mtree/spec.c:657: warning: implicit declaration of function 'uid_from_user' cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/specspec.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mtree/verify.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/usr.sbin/nmtree/../../contrib/mknod/pack_dev.c cc -O2 -pipe -I/src/usr.sbin/nmtree/../../contrib/mknod -I/src/usr.sbin/nmtree/../../lib/libnetbsd -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -static -L/obj/arm.arm/src/tmp/legacy/usr/lib -o mtree compare.o crc.o create.o excludes.o getid.o misc.o mtree.o only.o spec.o specspec.o verify.o pack_dev.o -lmd -lutil /obj/arm.arm/src/tmp/src/usr.sbin/nmtree/../../lib/libnetbsd/libnetbsd.a -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree /obj/arm.arm/src/tmp/legacy/usr/sbin/mtree -> /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree ln: /obj/arm.arm/src/tmp/legacy/usr/sbin/nmtree: No such file or directory *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin/nmtree *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-01 13:07:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 13:07:55 - ERROR: failed to build world TB --- 2014-03-01 13:07:55 - 315.89 user 138.73 system 447.12 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 15:47:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 512B2B49 for ; Sat, 1 Mar 2014 15:47:12 +0000 (UTC) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2472215A6 for ; Sat, 1 Mar 2014 15:47:11 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id p10so1980051pdj.17 for ; Sat, 01 Mar 2014 07:47:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=nj3cO68chXDdx9VAsw93LLzT6cBj+HulizjGgIyUV/g=; b=ZS3d5jKBKWJdAQZHGrVEDtZYigld64Xcqng2EaJejP9lJ4gWt5tNDO3b1rC9YnEaoq gwoaBMtCgCLq2zDlA3+aoKyU+7c8EIcQm7SYtmKfi9TJqANX0zaWLt70dbbzHL4jyuaM 1BXolJ0O5rPWOjxF7Zk80ylkHDJtOdt2TI2gWa2EZKm3tdoqGmFZJ/R6v+u3gE/POZQ4 fo/bKMNgUnc2Mm4jpE4ddHzEylsF+D6s35y3C9+2uj5m7KVkCu/r9FUaXYodXuPBUOPd 0PqXz9DHIx/qtZphl8ykXMxa7YV3D7iEjQxPGoSQ0Db5+szb4296wt4sJZlIrtWOawLf a1kQ== X-Gm-Message-State: ALoCoQndpcG8hg60frm9E1q0wxTYB6BIzRGwyoFYHxlmx5fqzYjs2YQiiTxeekwdORTIomN79UP2 X-Received: by 10.68.184.66 with SMTP id es2mr10076518pbc.19.1393688831276; Sat, 01 Mar 2014 07:47:11 -0800 (PST) Received: from [192.168.2.123] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPSA id qf7sm40762946pac.14.2014.03.01.07.47.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Mar 2014 07:47:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: bootelf required? From: Tim Kientzle In-Reply-To: <53111985.2010004@nomadlogic.org> Date: Sat, 1 Mar 2014 07:47:07 -0800 Content-Transfer-Encoding: 7bit Message-Id: <126C1F80-FDB6-40D0-B5F4-ED3EBC723A85@kientzle.com> References: <53111985.2010004@nomadlogic.org> To: Pete Wright X-Mailer: Apple Mail (2.1827) Cc: freebsd-arm ml X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 15:47:12 -0000 On Feb 28, 2014, at 3:19 PM, Pete Wright wrote: > hey there - i'm hacking on a utilite arm9 box and am running into an > issue. the stock boot environment does not seem to include the > "bootelf" command. > > looking at the "uEnv.txt" file generated by corchet-freebsd i have the > following: >> cat uEnv.txt > uenvcmd=fatload mmc 0:1 88000000 ubldr;bootelf 88000000; > > > unfortunately it does not look like the uboot environment on this system > contains bootelf: > > CM-FX6 # bootelf > Unknown command 'bootelf' - try 'help' > CM-FX6 # boot > bootm boot bootd bootz bootp > > > is bootelf a hard requirement for our environment? > alternatively - is > there a way to run an alternative bootloader that supports bootelf? If you can recompile U-Boot, then it's easy to add bootelf support. If your board has U-Boot in ROM where it can't be replaced, you might be able to use that to chain-load a more capable U-Boot that can then bootelf the ubldr. (FreeBSD on RPi does something similar.) Tim From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 15:48:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26D2AB85 for ; Sat, 1 Mar 2014 15:48:38 +0000 (UTC) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED69B15AD for ; Sat, 1 Mar 2014 15:48:37 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id kq14so2043503pab.38 for ; Sat, 01 Mar 2014 07:48:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=C+iCZT0hCWjiuZ1+tXnEFPT2NN+vW4mNisXk4gugERw=; b=gv/TseUXhNLzVqSKw4cquxL7aj+ndSt4tQT7oYueuRuX1yYU2Pyk3L3UIwcRFyrME7 FASWpiPDvjmUBq46iDYzg9rYUbIXEg+GOUeW/QOcTKZMN/e/x87yqPRNL1Nl7nyISWYF 8gXD1d6J8+5rueSIW7u3rh1X7yLLAZGE1uJB/v3/cGiWEgfXBARqNlgtlUQG+FzurylK evKGj2YqAgVrID1AHeKIwQ5JEbWgilIyiQ0S/weMkd2UdTry6rQbIfUNMrDpdpUoqQeK oH64avGCHyQSNpkDwgibSepDaf8y3E7oEHQJL3SgQi9SeXXcofxo+ZmDdlxFSJo2a3mc +Dfw== X-Gm-Message-State: ALoCoQlWFPO5vBrEfY2dRTycq197pW6oL1QD5GY5El9xjhF5OXaKCvcMGe4V6mA+/ZRnyFAkOw12 X-Received: by 10.68.129.5 with SMTP id ns5mr1004109pbb.147.1393688464354; Sat, 01 Mar 2014 07:41:04 -0800 (PST) Received: from [192.168.2.123] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPSA id vx10sm40638837pac.17.2014.03.01.07.41.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Mar 2014 07:41:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Tim Kientzle In-Reply-To: <1393594966.1149.161.camel@revolution.hippie.lan> Date: Sat, 1 Mar 2014 07:41:01 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <1393594966.1149.161.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1827) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 15:48:38 -0000 On Feb 28, 2014, at 5:42 AM, Ian Lepore wrote: > I've added a new imx6 unified kernel config named IMX6. It has no > compiled-in fdt, and can boot all three flavors of Wandboard when u-boot > and ubldr load a dtb file. Folks should start using it and eventually > the WANDBOARD* configs will go away when nobody needs them anymore. Nice! Another step towards GENERIC ARM. > the .dtb file in your /boot/kernel or /boot/modules directory, and ubldr > will load it from there, using the filename set in the u-boot env var > fdt_file. Using a U-Boot env var to specify the FDT is a nice idea. > Unfortunately we can't do a single image that boots any wandboard, > because u-boot itself has to be different for each board. This is what > my u-boot env looks like on each wandboard: > > => printenv > baudrate=115200 > bootcmd=run ubnet > bootdelay=1 > console=ttymxc0 > fdt_file=wandboard-dual.dtb > loadaddr=11000000 > loaderdev=net > ubmmc=fatload mmc 0 ${loadaddr} ubldr; bootelf > ubnet=dhcp ${loadaddr} /wand/boot/ubldr;bootelf > > Environment size: 265/8188 bytes > > The only thing that differs per-board is the fdt_file setting, and the > u-boot binary itself. If you could get to a single U-Boot binary, you might be able to do what BeagleBone does: The U-boot.env script detects the board variation and conditionally loads the correct DTB blob. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 15:49:11 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22400BBE for ; Sat, 1 Mar 2014 15:49:11 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8FB315AF for ; Sat, 1 Mar 2014 15:49:10 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJmA1-0006wk-M5; Sat, 01 Mar 2014 15:49:09 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s21Fn5C3044409; Sat, 1 Mar 2014 08:49:05 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX182teorEwndFq5wms4dPJe8 Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <1393594966.1149.161.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 01 Mar 2014 08:49:05 -0700 Message-ID: <1393688945.1149.225.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 15:49:11 -0000 On Sat, 2014-03-01 at 07:41 -0800, Tim Kientzle wrote: > On Feb 28, 2014, at 5:42 AM, Ian Lepore wrote: > > > I've added a new imx6 unified kernel config named IMX6. It has no > > compiled-in fdt, and can boot all three flavors of Wandboard when u-boot > > and ubldr load a dtb file. Folks should start using it and eventually > > the WANDBOARD* configs will go away when nobody needs them anymore. > > Nice! Another step towards GENERIC ARM. > > > the .dtb file in your /boot/kernel or /boot/modules directory, and ubldr > > will load it from there, using the filename set in the u-boot env var > > fdt_file. > > Using a U-Boot env var to specify the FDT is a nice idea. > > > Unfortunately we can't do a single image that boots any wandboard, > > because u-boot itself has to be different for each board. This is what > > my u-boot env looks like on each wandboard: > > > > => printenv > > baudrate=115200 > > bootcmd=run ubnet > > bootdelay=1 > > console=ttymxc0 > > fdt_file=wandboard-dual.dtb > > loadaddr=11000000 > > loaderdev=net > > ubmmc=fatload mmc 0 ${loadaddr} ubldr; bootelf > > ubnet=dhcp ${loadaddr} /wand/boot/ubldr;bootelf > > > > Environment size: 265/8188 bytes > > > > The only thing that differs per-board is the fdt_file setting, and the > > u-boot binary itself. > > If you could get to a single U-Boot binary, you might > be able to do what BeagleBone does: The U-boot.env > script detects the board variation and conditionally > loads the correct DTB blob. That's my long-term goal, but it'll take some major u-boot hacking, probably won't happen for months. The imx6 quad chip is different enough from the solo and dual-lite that a single u-boot to handle both will be kind of tricky the way the u-boot code is structured now. Doing a single u-boot for solo+dual-lite is so trivial I'm not sure why wandboard didn't do it that way. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 16:08:40 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A17583FB; Sat, 1 Mar 2014 16:08:40 +0000 (UTC) Received: from turing.morphism.de (smtp.morphism.de [IPv6:2001:4178:4:204::25]) by mx1.freebsd.org (Postfix) with ESMTP id 64B441709; Sat, 1 Mar 2014 16:08:40 +0000 (UTC) Received: from localhost (moore.morphism.de [IPv6:2001:4178:4:202::136]) by turing.morphism.de (Postfix) with ESMTP id A5ECE4C581; Sat, 1 Mar 2014 16:08:38 +0000 (UTC) Date: Sat, 1 Mar 2014 16:08:38 +0000 From: Markus Pfeiffer To: Ian Lepore Subject: Re: imx6 / wandboard SMP Message-ID: <20140301160838.GP57328@moore.morphism.de> References: <1393559112.1149.132.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zxEKvxCKojqA/Afl" Content-Disposition: inline In-Reply-To: <1393559112.1149.132.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Markus Pfeiffer List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 16:08:40 -0000 --zxEKvxCKojqA/Afl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear Ian, On Thu, Feb 27, 2014 at 08:45:12PM -0700, Ian Lepore wrote: > Thanks to an excellent patchset contributed by Juergen Weiss we now have > SMP for Wandboard and imx6 in general. =20 >=20 > To test this yourself, update to r262587 or later and add "option SMP" > to your kernel config. I just tested this on my wandboard quad and didn't see any immediate proble= ms. Obviously i didn't do any heavy SMP testing yet. Thanks for you and Juergen for making that work. Markus --zxEKvxCKojqA/Afl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (DragonFly) iQIcBAEBAgAGBQJTEgYGAAoJEBRHBRYBD4mPDosQALH41Fgfb4K6/DI2djwcyn5P YupiFFeB2DLgPVkXzkMI0E+1a8n6NcfUPnuz5qmut7MSuzYiqNQwfkBIw7pvU6hu YIFvnTXRZZDNnRqhs2eL6ZxoEWtpaU4nasaPGPAyJyJAtg25xGI5SaluwkRykDwT W7dR7/cOtWP1pcjIwqx1Z4jUEcnqUcKm5RcWMA/MQ1F7Af39A4r9Qdkt5fwjj8Pz +qw3l58BMj/0tNkzm5bbDJeBi8UlzEQw91p8RV9snm9Gf7JkXiFuFWoWvsNvm9X7 6gHAvRb2pTwPwngciQjWsf0MGCR8K6Php/PHLQmc8UxlbxL2Q1niu1WRTq4maVWe iu+pe24WzYFY0kRffsfdWeLpDTG5ZXIV7litsC0XKRa635oRzhA9g1DZsmHArfHv ltM1oK2AjqEqpc7XtHYPcPzZ5mq9YygmA0HJsMmBa9tvJD0ukduzS129FbIl28PW FCdgfyL6lm1Cehh1lciNKx9nYdqOP7yCByj2XWaRgx4h2ZHGCSYPs3u7kR8qi0hL PAZ/8wc4HFxaLI32afB0z4wSG5xrMcpYziq/eFZ9+8yCOylIHWcHAsNUi2kdLLSB iV41fHboSMNYhJ/PeBEKNC5DhZk0DzWHw351+Vy67jnHoYFsGB4uiLFJ7l58Fpqn hEteRGPjW5XOJAyjK7RO =675c -----END PGP SIGNATURE----- --zxEKvxCKojqA/Afl-- From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 16:34:40 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E390DB90; Sat, 1 Mar 2014 16:34:40 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9FFB518E8; Sat, 1 Mar 2014 16:34:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 72E9B3F447 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1393691678; bh=siVdtO74AdYdDM9PgeilwZ454vlc/Fr6dZS2myvmbIs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=sCnFhpGIkteOxlO7FVodg//kb901tPihPKMnix4E6IoyreL/E+fI1gT91e5UiIgua GnBOf8M52NDTt+jQxk4piA6NGrzCUsj/RWHT9AUQnnXlmtA5x5jrR/BFu75Uxz+icX Xb2SII4NNUqNUzbBSN28sQwWT4WaBI8P8mUGOs+8= Message-ID: <53120C14.5010007@bakulin.de> Date: Sat, 01 Mar 2014 17:34:28 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: Stanislav Sedov , Kevin Lo Subject: Re: u-boot-2014.01 and freebsd arm References: <1393010014.1145.137.camel@revolution.hippie.lan> <5308C9F7.5090300@FreeBSD.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X2uNQHT9cVQHJPJ49d1lGHlprTo0UL9An" Cc: freebsd-arm , Patrick Wildt , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 16:34:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X2uNQHT9cVQHJPJ49d1lGHlprTo0UL9An Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 23.02.14, 03:21, Stanislav Sedov wrote: >=20 >> On Feb 22, 2014, at 8:01 AM, Kevin Lo wrote: >> >> It seems that there is a license issue preventing integration of >> UFS support into U-Boot's source. See all discussion threads: >> http://marc.info/?t=3D127792848100003&r=3D1&w=3D2 >=20 > That was one of the reasons it didn't go to the main tree. I feel that= > we should try again as it seems that uboot might be more liberal > with licenses now. >=20 > -- > ST4096-RIPE > _______________________________________________ So does it make sense to kick off the integration process once again? Seems FreeBSD is not the only one system that needs this, Bitrig people are interested in it too. I'm also CCing Patrick Wildt, a Bitrig developer. --=20 Regards, Ilya Bakulin --X2uNQHT9cVQHJPJ49d1lGHlprTo0UL9An Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlMSDBsACgkQo9vlj1oadwiyJQCdEa1KA/dg5ZMu23ywEmJ2pDiT yZwAn3l7UDmCNtQ/AWZip2Sol7b/zytH =gmkP -----END PGP SIGNATURE----- --X2uNQHT9cVQHJPJ49d1lGHlprTo0UL9An-- From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 16:46:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79645D0F; Sat, 1 Mar 2014 16:46:40 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 06DA7197F; Sat, 1 Mar 2014 16:46:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 79A1F3F447 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1393692398; bh=d+8GHcINLy78fyewYr4+BaecZQM39xZyj6/tH5aoXfs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=gP/mFgu2B0Dtddl6tkVvXgg3cDBDp3K8L7xPeD4wzXRmGFNmKD8jg98LfIjEWn0Bk isPtKWOkPic3MDZPCoYm7LyH23TG8ec/kNYEd7gDsGsfZscvauTR5Z4Y65R12FIYkx OicOG/i3ATEifhR0AvXj/k3vdu9ZeX1Gb5hBcVPs= Message-ID: <53120EE8.1080600@bakulin.de> Date: Sat, 01 Mar 2014 17:46:32 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: Adrian Chadd Subject: Re: MMC/SDIO stack under CAM References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE" Cc: "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 16:46:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adrian, On 24.02.14, 16:59, Adrian Chadd wrote: > hi, >=20 > Let me just reiterate some .. well, experience doing this stuff at QCA.= >=20 > You really, absolutely don't want too much overhead in the MMC/SDIO > path between whatever is issuing things and the network driver. >=20 > There was significant performance work done at QCA on a local MMC/SDIO > driver and bus to get extremely low latency and CPU utilisation when > pushing around small transactions. The current CAM locking model is > not geared towards getting to high transaction rates. So here you mean some work done on Linux MMC/SDIO stack by QCA which made it far better than current Linux MMC stack in terms of high SDIO I/O rates? >=20 > You may think this is a very architecturally pretty solution and it > indeed may be. But if it doesn't perform as well as the existing local > hacks that vendors have done, no company deploying this hardware is > going to want to use it. They'll end up realising there's this massive > CAM storage layer in between and either have to sit down to rip it up > and replace it with something lightweight, or they'll say "screw it" > and go back to the vendor supplied hacked up Linux solution. I think that if the "architecturally pretty solution" behaves worse than some ugly hacks, then it may be not so pretty or the architecture is just broken by design. > So I highly recommend you profile things - and profile things with > lots of small transactions. If the CAM overhead is more than a tiny, > tiny fraction of CPU at 25,000 pps, your solution won't scale. :-) I don't really know what to compare with. For MMC/SD cards it is pretty obvious, but then these cards will be likely the bottleneck, not the stac= k. And the only goal would be to not make the stack slower than it is now. But, as ATA devices are much faster than MMC/SD, I don't think this will be a problem. For SDIO things are different. But we don't have any drivers (yet), excep= t mv_sdiowl that I'm writing, to test on. So I have to bring the SDIO stack on CAM, than bring mv_sdiowl to the state when it can actually transmit the data, and then compare performance with the vendor-supplied Linux driver. We'll see then if there is a room for improvement... --=20 Regards, Ilya Bakulin --IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlMSDusACgkQo9vlj1oadwjzzQCeMSzl4e8wUqCK4s3kgBZpr1U8 JD8Anjz2mbLF4XVpGfCHDTIu5AlaKseg =JJfS -----END PGP SIGNATURE----- --IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE-- From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 16:54:08 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E514180; Sat, 1 Mar 2014 16:54:08 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52E041A32; Sat, 1 Mar 2014 16:54:06 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s21Gro1I034890; Sat, 1 Mar 2014 18:53:50 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s21GrnF6034773; Sat, 1 Mar 2014 16:53:49 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Mar 2014 16:53:49 GMT Message-Id: <201403011653.s21GrnF6034773@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 16:54:08 -0000 TB --- 2014-03-01 13:10:31 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 13:10:31 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 13:10:31 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 13:10:31 - cleaning the object tree TB --- 2014-03-01 13:10:38 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 13:11:26 - At svn revision 262654 TB --- 2014-03-01 13:11:27 - building world TB --- 2014-03-01 13:11:27 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 13:11:27 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 13:11:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 13:11:27 - SRCCONF=/dev/null TB --- 2014-03-01 13:11:27 - TARGET=arm TB --- 2014-03-01 13:11:27 - TARGET_ARCH=arm TB --- 2014-03-01 13:11:27 - TZ=UTC TB --- 2014-03-01 13:11:27 - __MAKE_CONF=/dev/null TB --- 2014-03-01 13:11:27 - cd /src TB --- 2014-03-01 13:11:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 13:11:38 UTC 2014 >>> 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 Sat Mar 1 16:36:50 UTC 2014 TB --- 2014-03-01 16:36:50 - generating LINT kernel config TB --- 2014-03-01 16:36:50 - cd /src/sys/arm/conf TB --- 2014-03-01 16:36:50 - /usr/bin/make -B LINT TB --- 2014-03-01 16:36:50 - cd /src/sys/arm/conf TB --- 2014-03-01 16:36:50 - /usr/sbin/config -m LINT TB --- 2014-03-01 16:36:50 - building LINT kernel TB --- 2014-03-01 16:36:50 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 16:36:50 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 16:36:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 16:36:50 - SRCCONF=/dev/null TB --- 2014-03-01 16:36:50 - TARGET=arm TB --- 2014-03-01 16:36:50 - TARGET_ARCH=arm TB --- 2014-03-01 16:36:50 - TZ=UTC TB --- 2014-03-01 16:36:50 - __MAKE_CONF=/dev/null TB --- 2014-03-01 16:36:50 - cd /src TB --- 2014-03-01 16:36:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 1 16:36:50 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/at91/uart_dev_at91usart.c /src/sys/arm/at91/uart_dev_at91usart.c:243:3: error: field designator 'grab' does not refer to any field in type 'struct uart_ops' .grab = at91_usart_grab, ^ /src/sys/arm/at91/uart_dev_at91usart.c:244:3: error: field designator 'ungrab' does not refer to any field in type 'struct uart_ops' .ungrab = at91_usart_ungrab, ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-03-01 16:53:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-01 16:53:48 - ERROR: failed to build LINT kernel TB --- 2014-03-01 16:53:48 - 10027.15 user 3314.56 system 13396.96 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 17:05:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D1855E0; Sat, 1 Mar 2014 17:05:16 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0364B1AEA; Sat, 1 Mar 2014 17:05:15 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id x13so2105689qcv.5 for ; Sat, 01 Mar 2014 09:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UKD0jDEu5cCttp1btYnIRgYeaCfAhV3PII+xMt9Vajw=; b=0+LLqBlPljOV5KRGRUEaKssstXfQ7Bt26m9YbiATlk5zUxAR6Bw1qmF3fgXn8lKZ0v 2BUYvlaPufyvZH8BPfGmdZfKh9RkvvC4jdCe35Bp+19pxCODhjWuvaCr2GmvXFzPXcDj brPEdAIcOrGy/Qt3dECD8Ih1QC3JpFbrbDzM5ao2PxzqloI/+dRWAvZBOaTUF8TjFKpe YtsbZyDIpbmYBqblPV37BqHOt4IzBUp1t/edb/PZu7c9ELZNu0wTAzDI52zDEt4P57aL OR1324CS9vR57VEvl98q6+3GD8JUPuPOIOvv9TTwBqmYX3ljFujUNh8ieO5JJnjad39A 0EZw== MIME-Version: 1.0 X-Received: by 10.140.42.54 with SMTP id b51mr11420271qga.87.1393693515192; Sat, 01 Mar 2014 09:05:15 -0800 (PST) Received: by 10.224.16.10 with HTTP; Sat, 1 Mar 2014 09:05:15 -0800 (PST) In-Reply-To: <53120EE8.1080600@bakulin.de> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> Date: Sat, 1 Mar 2014 09:05:15 -0800 Message-ID: Subject: Re: MMC/SDIO stack under CAM From: Adrian Chadd To: Ilya Bakulin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 17:05:16 -0000 On 1 March 2014 08:46, Ilya Bakulin wrote: > Hi Adrian, > > On 24.02.14, 16:59, Adrian Chadd wrote: >> hi, >> >> Let me just reiterate some .. well, experience doing this stuff at QCA. >> >> You really, absolutely don't want too much overhead in the MMC/SDIO >> path between whatever is issuing things and the network driver. >> >> There was significant performance work done at QCA on a local MMC/SDIO >> driver and bus to get extremely low latency and CPU utilisation when >> pushing around small transactions. The current CAM locking model is >> not geared towards getting to high transaction rates. > > So here you mean some work done on Linux MMC/SDIO stack by QCA > which made it far better than current Linux MMC stack in terms of > high SDIO I/O rates? Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at small transactions to sustain the wifi speeds customers required. >> >> You may think this is a very architecturally pretty solution and it >> indeed may be. But if it doesn't perform as well as the existing local >> hacks that vendors have done, no company deploying this hardware is >> going to want to use it. They'll end up realising there's this massive >> CAM storage layer in between and either have to sit down to rip it up >> and replace it with something lightweight, or they'll say "screw it" >> and go back to the vendor supplied hacked up Linux solution. > > I think that if the "architecturally pretty solution" behaves worse than > some ugly hacks, then it may be not so pretty or the architecture is > just broken > by design. > >> So I highly recommend you profile things - and profile things with >> lots of small transactions. If the CAM overhead is more than a tiny, >> tiny fraction of CPU at 25,000 pps, your solution won't scale. :-) > > I don't really know what to compare with. For MMC/SD cards it is pretty > obvious, but then these cards will be likely the bottleneck, not the stack. > And the only goal would be to not make the stack slower than it is now. > But, as ATA devices are much faster than MMC/SD, I don't think this will > be a problem. > > For SDIO things are different. But we don't have any drivers (yet), except > mv_sdiowl that I'm writing, to test on. So I have to bring the SDIO > stack on CAM, > than bring mv_sdiowl to the state when it can actually transmit the > data, and then > compare performance with the vendor-supplied Linux driver. > We'll see then if there is a room for improvement... That sounds like a plan. Just note that although storage looks like it's doing much more throughput, the IO size also matters. As I said above, it's not uncommon to have > 1000 receive frames a second on 802.11n; and that can peak much higher than that. That's not the kind of IO rate you see on SD cards. :-) -a From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 18:00:00 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D554F9F for ; Sat, 1 Mar 2014 18:00:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78B3F1F9F for ; Sat, 1 Mar 2014 18:00:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s21I005b091937 for ; Sat, 1 Mar 2014 18:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s21I00xb091936; Sat, 1 Mar 2014 18:00:00 GMT (envelope-from gnats) Resent-Date: Sat, 1 Mar 2014 18:00:00 GMT Resent-Message-Id: <201403011800.s21I00xb091936@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, Takanori Sawada Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70EA8B29 for ; Sat, 1 Mar 2014 17:56:37 +0000 (UTC) Received: from newred.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D1961F58 for ; Sat, 1 Mar 2014 17:56:37 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by newred.freebsd.org (8.14.7/8.14.7) with ESMTP id s21HuaGH056871 for ; Sat, 1 Mar 2014 17:56:37 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.7/8.14.7/Submit) id s21Huanw056870; Sat, 1 Mar 2014 17:56:36 GMT (envelope-from nobody) Message-Id: <201403011756.s21Huanw056870@cgiserv.freebsd.org> Date: Sat, 1 Mar 2014 17:56:36 GMT From: Takanori Sawada To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/187179: Wandboard ffec cannot receive IPv6 multicast X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 18:00:00 -0000 >Number: 187179 >Category: arm >Synopsis: Wandboard ffec cannot receive IPv6 multicast >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: Sat Mar 01 18:00:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Takanori Sawada >Release: FreeBSD 11.0-CURRENT >Organization: >Environment: FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #12 9e667e1(master): Sun Mar 2 01:57:57 JST 2014 tak@localhost.localdomain:/home/tak/share/github/freebsd-objs/arm.armv6/home/tak/share/github/freebsd/sys/WANDBOARD-DUAL arm >Description: Wandboard ffec cannot receive IPv6 multicast. - ping6 (From Wandboard to Test Server) ping6 ff02::1%ffec0 netstat -i ===> Cannot receive NS multicast. transmit OK. ping6 server_linklocal_address%ffec0 netstat -i ===> Cannot receive NS multicast. transmit OK. - ping6 (From Test Server to Wandboard) tcpdump -i ffec0 ping6 Wandboard_ffec_linklocal_address%em0 ===> Cannot receive ICMPv6 Echo Request Multicast. >How-To-Repeat: >Fix: I found ffec multicast filter problem. Patch file attached. Patch attached with submission follows: diff --git sys/dev/ffec/if_ffec.c sys/dev/ffec/if_ffec.c index 05a6c99..ca5b77b 100644 --- sys/dev/ffec/if_ffec.c +++ sys/dev/ffec/if_ffec.c @@ -954,14 +954,14 @@ ffec_setup_rxfilter(struct ffec_softc *sc) if ((ifp->if_flags & IFF_ALLMULTI)) ghash = 0xffffffffffffffffLLU; else { - ghash = 0; + ghash = 0LLU; if_maddr_rlock(ifp); TAILQ_FOREACH(ifma, &sc->ifp->if_multiaddrs, ifma_link) { if (ifma->ifma_addr->sa_family != AF_LINK) continue; crc = ether_crc32_be(LLADDR((struct sockaddr_dl *) ifma->ifma_addr), ETHER_ADDR_LEN); - ghash |= 1 << (crc & 0x3f); + ghash |= 1LLU << (crc & 0x3f); } if_maddr_runlock(ifp); } >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 19:01:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A0E6315; Sat, 1 Mar 2014 19:01:35 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 59B43151F; Sat, 1 Mar 2014 19:01:35 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so4726160iec.19 for ; Sat, 01 Mar 2014 11:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GZ+DllS1XVrQhETujv42HhCJoJehzllkHpydt/qxrbM=; b=zn2q3n0TDs+KMmUAHK/tz+Ko/8WCsNgcXbqvmzQWNMNfANeYCsj7efB9wLpJ3+JuhR j+cawNitWJgh4Pp0nT10OJ92U5blzDltKkV8vSSLK+rs78rwMoPEIf0yXsKhiz3NTd43 4j/ZSRGCimtSvwkVXm3lRMT88suxl3aJqB9QAc69TvazZQYkGzeaC/g9z+6QS4vNrsc9 nDNg7xtbRixtAvZ/xcx+4iC/8UkISaJJOUCG6HA+ygvwWjlTd+ch0H02Z30O+tSLsFtz L3UOxC9NQgkgbqT+rLLseeZfjGeQCrBgZZshX+xsVDmdtOCEo8W7+WU90uRb7BOYR0Z0 ZtAw== X-Received: by 10.50.79.194 with SMTP id l2mr12376810igx.8.1393700494788; Sat, 01 Mar 2014 11:01:34 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id c17sm20551956igo.4.2014.03.01.11.01.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Mar 2014 11:01:33 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Warner Losh In-Reply-To: <1393688945.1149.225.camel@revolution.hippie.lan> Date: Sat, 1 Mar 2014 12:01:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <05B4DCBB-E8A9-4EC1-B50C-3D2965828BF1@bsdimp.com> References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393688945.1149.225.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 19:01:35 -0000 On Mar 1, 2014, at 8:49 AM, Ian Lepore wrote: > On Sat, 2014-03-01 at 07:41 -0800, Tim Kientzle wrote: >> On Feb 28, 2014, at 5:42 AM, Ian Lepore wrote: >>=20 >>> I've added a new imx6 unified kernel config named IMX6. It has no >>> compiled-in fdt, and can boot all three flavors of Wandboard when = u-boot >>> and ubldr load a dtb file. Folks should start using it and = eventually >>> the WANDBOARD* configs will go away when nobody needs them anymore. >>=20 >> Nice! Another step towards GENERIC ARM. Yes, many more steps to go, but if we can have a generic kernel per SoC = that=92s miles ahead of where we are now. >>> the .dtb file in your /boot/kernel or /boot/modules directory, and = ubldr >>> will load it from there, using the filename set in the u-boot env = var >>> fdt_file. >>=20 >> Using a U-Boot env var to specify the FDT is a nice idea. When U-Boot itself doesn=92t have the DTB already in the image, yes. >>> Unfortunately we can't do a single image that boots any wandboard, >>> because u-boot itself has to be different for each board. This is = what >>> my u-boot env looks like on each wandboard: >>>=20 >>> =3D> printenv >>> baudrate=3D115200 >>> bootcmd=3Drun ubnet >>> bootdelay=3D1 >>> console=3Dttymxc0 >>> fdt_file=3Dwandboard-dual.dtb >>> loadaddr=3D11000000 >>> loaderdev=3Dnet >>> ubmmc=3Dfatload mmc 0 ${loadaddr} ubldr; bootelf >>> ubnet=3Ddhcp ${loadaddr} /wand/boot/ubldr;bootelf >>>=20 >>> Environment size: 265/8188 bytes >>>=20 >>> The only thing that differs per-board is the fdt_file setting, and = the >>> u-boot binary itself. >>=20 >> If you could get to a single U-Boot binary, you might >> be able to do what BeagleBone does: The U-boot.env >> script detects the board variation and conditionally >> loads the correct DTB blob. >=20 > That's my long-term goal, but it'll take some major u-boot hacking, > probably won't happen for months. The imx6 quad chip is different > enough from the solo and dual-lite that a single u-boot to handle both > will be kind of tricky the way the u-boot code is structured now. = Doing > a single u-boot for solo+dual-lite is so trivial I'm not sure why > wandboard didn't do it that way. Things get more complicated when more boards are involved=85 For all the Atmel boards, the user or board maker (more typically) will have to include the DTB so you know which one of the dozens of choices is present=85But then again, from the kernel/ubldr perspective, the right = DTB is present, and you are good to go Warner= From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 21:55:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 803A2437; Sat, 1 Mar 2014 21:55:55 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4194F12D2; Sat, 1 Mar 2014 21:55:55 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id n16so5553231oag.17 for ; Sat, 01 Mar 2014 13:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=11wDit7FWCOChsMDzB/7Daj7q50Hz1qQ8SWEzoTfbzE=; b=Ama6BsgTv08VLc3nnRCAXFRu8pyYEF5wiDG3GIGpvsTwRc/er0A90cAMbNYFrrfmXP cUic2pP11Rv14gJ8ClCOJw9tfjp68mPVoF5p6xLgmux5xCWwJ3nnyzDxFByq+WLDi1Qr PeaGp8eg7rTyv9rqL8jtCpLac4kSSWzbX01YQm1q9rXzjcHiX373P/4px43mpgUTtcoD IEwsjWfBZMl9BHC2pXALlVw3z93UppQP/d3RrfG/ug7/JTT4QLkbO7GCYiLEFkEQ5jcs m79p83u5ZO2EsxpvzZPknqzSsywE8kDfO5jyiHCL26GchcvGrffQc55k/zlsw7E0UqUt b3jA== MIME-Version: 1.0 X-Received: by 10.182.48.233 with SMTP id p9mr20660024obn.44.1393710954567; Sat, 01 Mar 2014 13:55:54 -0800 (PST) Received: by 10.182.80.7 with HTTP; Sat, 1 Mar 2014 13:55:54 -0800 (PST) Date: Sat, 1 Mar 2014 22:55:54 +0100 Message-ID: Subject: [ARM] FYI: Broadcom Open-Sources VideoCore IV 3D Graphics Stack From: Oliver Pinter To: current@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 21:55:55 -0000 license: 3 clause BSD http://www.phoronix.com/scan.php?page=news_item&px=MTYxODQ http://blog.broadcom.com/chip-design/android-for-all-broadcom-gives-developers-keys-to-the-videocore-kingdom/ From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 03:50:00 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF24DBC2 for ; Sun, 2 Mar 2014 03:50:00 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BEEBC162B for ; Sun, 2 Mar 2014 03:50:00 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJxPV-000KZ0-2H; Sun, 02 Mar 2014 03:49:53 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s223noVx044693; Sat, 1 Mar 2014 20:49:50 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18uOFsb+IMpW1/wdO6PcMhW Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Ian Lepore To: Tom Everett In-Reply-To: References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393731762.1149.233.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 01 Mar 2014 20:49:50 -0700 Message-ID: <1393732190.1149.238.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 03:50:01 -0000 On Sat, 2014-03-01 at 20:44 -0700, Tom Everett wrote: > I've got an image that loads the dtb from the FAT partition. However, it > was mentioned that the dtb could be loaded from the UFS partition. Given > that u-boot doesn't have UFS support, how would this work? > Ubldr does it, not u-boot. I modified ubldr a couple days ago. It first looks for a file arleady loaded by u-boot. If u-boot didn't load one, it next looks for a u-boot environment variable named fdt_file and loads that file from the ufs file system if it can find it in /boot/kernel or /boot/modules. So basically just stop loading the file in u-boot and put a copy of the file in /boot/modules and ubldr will load it. I noticed in the boot log you posted that you didn't enable SMP and it's only running one core, is that what you intended? I didn't turn on SMP by default yet, but I probably will in a few days because it seems fairly stable so far. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 03:42:51 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDC2AB70 for ; Sun, 2 Mar 2014 03:42:51 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BEE6F1614 for ; Sun, 2 Mar 2014 03:42:51 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJxIb-00079I-J9; Sun, 02 Mar 2014 03:42:45 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s223gg82044687; Sat, 1 Mar 2014 20:42:42 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+IicnfVKrHtT2hTZDOn84r Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Ian Lepore To: Tom Everett In-Reply-To: References: <1393594966.1149.161.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 01 Mar 2014 20:42:42 -0700 Message-ID: <1393731762.1149.233.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 03:42:52 -0000 On Sat, 2014-03-01 at 18:01 -0700, Tom Everett wrote: > I'm looking at the crochet code, and I see in freebsd_install_fdt that both > *.dtb and *.dts are supported. However on the source tree it's imx6.dtsi. > What's the difference b/t a dts file and a dtsi file? A .dtsi file is an include file used by .dts files. A .dtb is the binary (compiled) form used by the kernel. So there are several wandboard-something.dts files, each of which includes imx6.dtsi where all the common parts live. For a new imx6 device, a new board-named file similar to one of the wandboard files is necessary, and it would also include imx6.dtsi. We're pushing hard towards just using the standard dtb files from vendors, but we've got a bit of work to do before we're there. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 03:44:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3946FB79 for ; Sun, 2 Mar 2014 03:44:30 +0000 (UTC) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F24931619 for ; Sun, 2 Mar 2014 03:44:29 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id vb8so5440696obc.25 for ; Sat, 01 Mar 2014 19:44:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZN0k+H+sUqKhZxpdu0Kd99h4++3zyzp8Wk7LlBgrkgA=; b=UWzyt6po6HWnvfKeJZBCsTPdjKk26VZhFJdfQGohLVr7gJldNRKBD1nTQ8/iHmgeht BSJcwG49tgiG9Wsf1gEDRhgP2Yu6vl00ZKWBUu+cpQKMQUBhjC3JItvK8ZeJvFHO4gtr 78oeKOdTVZA1QCCZkZtzEfHESTuheOrHVnJf9YmYpGAA/1C6axd+RiRx1CH43dDxhWnf UW77tjywt0HOT4iZ6uXPudEwJnZ4+YToHBJx+9pg7Yeu8BXMmJxYL8miQHxplvcxzamJ 6dFsro0+h2KzlENrif1vSDEZkxQ945O2BTg5rHkwjqSNauaE+YDbKdBeK0h9bspK0Q1z Vbmw== X-Gm-Message-State: ALoCoQnC5PPz2XeeYguK46Pqezd1dMC4X74h5NWgVB3GIhn0ylBM3WU4uPS9xEMXOhzthvl/gfd1 MIME-Version: 1.0 X-Received: by 10.182.66.164 with SMTP id g4mr339743obt.47.1393731867931; Sat, 01 Mar 2014 19:44:27 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sat, 1 Mar 2014 19:44:27 -0800 (PST) In-Reply-To: <1393731762.1149.233.camel@revolution.hippie.lan> References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393731762.1149.233.camel@revolution.hippie.lan> Date: Sat, 1 Mar 2014 20:44:27 -0700 Message-ID: Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 03:44:30 -0000 I've got an image that loads the dtb from the FAT partition. However, it was mentioned that the dtb could be loaded from the UFS partition. Given that u-boot doesn't have UFS support, how would this work? On Sat, Mar 1, 2014 at 8:42 PM, Ian Lepore wrote: > On Sat, 2014-03-01 at 18:01 -0700, Tom Everett wrote: > > I'm looking at the crochet code, and I see in freebsd_install_fdt that > both > > *.dtb and *.dts are supported. However on the source tree it's imx6.dtsi. > > What's the difference b/t a dts file and a dtsi file? > > A .dtsi file is an include file used by .dts files. A .dtb is the > binary (compiled) form used by the kernel. > > So there are several wandboard-something.dts files, each of which > includes imx6.dtsi where all the common parts live. For a new imx6 > device, a new board-named file similar to one of the wandboard files is > necessary, and it would also include imx6.dtsi. > > We're pushing hard towards just using the standard dtb files from > vendors, but we've got a bit of work to do before we're there. > > -- Ian > > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 07:53:41 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F25FC1CF; Sun, 2 Mar 2014 07:53:40 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 324D6169B; Sun, 2 Mar 2014 07:53:39 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s227r7aS004275; Sun, 2 Mar 2014 09:53:07 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s227r5d0004010; Sun, 2 Mar 2014 07:53:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 2 Mar 2014 07:53:05 GMT Message-Id: <201403020753.s227r5d0004010@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 07:53:41 -0000 TB --- 2014-03-02 04:10:36 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-02 04:10:36 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-02 04:10:36 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-02 04:10:36 - cleaning the object tree TB --- 2014-03-02 04:11:32 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-02 04:11:43 - At svn revision 262679 TB --- 2014-03-02 04:11:44 - building world TB --- 2014-03-02 04:11:44 - CROSS_BUILD_TESTING=YES TB --- 2014-03-02 04:11:44 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-02 04:11:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-02 04:11:44 - SRCCONF=/dev/null TB --- 2014-03-02 04:11:44 - TARGET=arm TB --- 2014-03-02 04:11:44 - TARGET_ARCH=arm TB --- 2014-03-02 04:11:44 - TZ=UTC TB --- 2014-03-02 04:11:44 - __MAKE_CONF=/dev/null TB --- 2014-03-02 04:11:44 - cd /src TB --- 2014-03-02 04:11:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 2 04:11:54 UTC 2014 >>> 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 Mar 2 07:36:00 UTC 2014 TB --- 2014-03-02 07:36:00 - generating LINT kernel config TB --- 2014-03-02 07:36:00 - cd /src/sys/arm/conf TB --- 2014-03-02 07:36:00 - /usr/bin/make -B LINT TB --- 2014-03-02 07:36:00 - cd /src/sys/arm/conf TB --- 2014-03-02 07:36:00 - /usr/sbin/config -m LINT TB --- 2014-03-02 07:36:00 - building LINT kernel TB --- 2014-03-02 07:36:00 - CROSS_BUILD_TESTING=YES TB --- 2014-03-02 07:36:00 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-02 07:36:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-02 07:36:00 - SRCCONF=/dev/null TB --- 2014-03-02 07:36:00 - TARGET=arm TB --- 2014-03-02 07:36:00 - TARGET_ARCH=arm TB --- 2014-03-02 07:36:00 - TZ=UTC TB --- 2014-03-02 07:36:00 - __MAKE_CONF=/dev/null TB --- 2014-03-02 07:36:00 - cd /src TB --- 2014-03-02 07:36:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 2 07:36:00 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/at91/uart_dev_at91usart.c /src/sys/arm/at91/uart_dev_at91usart.c:243:3: error: field designator 'grab' does not refer to any field in type 'struct uart_ops' .grab = at91_usart_grab, ^ /src/sys/arm/at91/uart_dev_at91usart.c:244:3: error: field designator 'ungrab' does not refer to any field in type 'struct uart_ops' .ungrab = at91_usart_ungrab, ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-03-02 07:53:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-02 07:53:04 - ERROR: failed to build LINT kernel TB --- 2014-03-02 07:53:04 - 10011.54 user 3308.51 system 13348.45 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 19:38:46 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0644715A for ; Sat, 1 Mar 2014 19:38:46 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C95E71774 for ; Sat, 1 Mar 2014 19:38:45 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WJpkC-0000Jq-Sf; Sat, 01 Mar 2014 19:38:45 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s21Jcg1t044563; Sat, 1 Mar 2014 12:38:42 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/71NuMO+HoV+kDzeR3lln+ Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Ian Lepore To: Warner Losh In-Reply-To: <05B4DCBB-E8A9-4EC1-B50C-3D2965828BF1@bsdimp.com> References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393688945.1149.225.camel@revolution.hippie.lan> <05B4DCBB-E8A9-4EC1-B50C-3D2965828BF1@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" Date: Sat, 01 Mar 2014 12:38:41 -0700 Message-ID: <1393702721.1149.230.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s21Jcg1t044563 Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 19:38:46 -0000 On Sat, 2014-03-01 at 12:01 -0700, Warner Losh wrote: > On Mar 1, 2014, at 8:49 AM, Ian Lepore wrote: >=20 > > On Sat, 2014-03-01 at 07:41 -0800, Tim Kientzle wrote: > >> On Feb 28, 2014, at 5:42 AM, Ian Lepore wrote: > >>=20 > >>> I've added a new imx6 unified kernel config named IMX6. It has no > >>> compiled-in fdt, and can boot all three flavors of Wandboard when u= -boot > >>> and ubldr load a dtb file. Folks should start using it and eventua= lly > >>> the WANDBOARD* configs will go away when nobody needs them anymore. > >>=20 > >> Nice! Another step towards GENERIC ARM. >=20 > Yes, many more steps to go, but if we can have a generic kernel per SoC= that=A2s > miles ahead of where we are now. >=20 > >>> the .dtb file in your /boot/kernel or /boot/modules directory, and = ubldr > >>> will load it from there, using the filename set in the u-boot env v= ar > >>> fdt_file. > >>=20 > >> Using a U-Boot env var to specify the FDT is a nice idea. >=20 > When U-Boot itself doesn=A2t have the DTB already in the image, yes. The way wandboard's boot setup works, the u-boot binary just provides a default filename for fdt_file and their image has the file on the msdos partition, and they use an env-var script to load the file before loading the kernel. I removed all that cruft from the environment and let ubldr load the file named in fdt_file from the ufs filesystem. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 01:01:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 143DDDF4 for ; Sun, 2 Mar 2014 01:01:35 +0000 (UTC) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CEB0614DA for ; Sun, 2 Mar 2014 01:01:34 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id uy5so2230096obc.6 for ; Sat, 01 Mar 2014 17:01:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KZmBlTUKgsFMA0js6P4WxFItjEkDQk7f1W6GAQZMXUo=; b=l6IKgi1vb3SrBcJdFCpoL1XnOF6YvvwHY2R+vy50lRgF6Kb/a3Bl8BNJL0R1zZWIsT zE0Y4eQ36EJjJxY8p3pxGZawqzBOrJVDqfgcPp4Rv8FHkcVErMts+6saYtYvdi+cnLyq 7N1gZZmOd0jV+fqkxsXC5upsfGycKCFQNLe4dfudqbhOINJ34iMTgLBU0tCbvX+Y3jX5 AJG+BNiS2JOS3Wx4qKWgHXw9wpK+z1DRVl9J//HUnecXvl85qAIg0byo6K6lnct7jtu6 pgrmj02vOW0ABJCxzsL1BGQ6xCY3X8Gu1tz0cgdeM7DTW0dAhFOo1bj963U7gvJzPLg5 kYlQ== X-Gm-Message-State: ALoCoQnFi5WzcCbzM+bCIMsN0baVNe1pSyd30SNlUI25Hrt0ZbMTP6Ng/mPDrS869XKUnCl2oFvM MIME-Version: 1.0 X-Received: by 10.60.63.197 with SMTP id i5mr9872959oes.38.1393722088512; Sat, 01 Mar 2014 17:01:28 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sat, 1 Mar 2014 17:01:28 -0800 (PST) In-Reply-To: References: <1393594966.1149.161.camel@revolution.hippie.lan> Date: Sat, 1 Mar 2014 18:01:28 -0700 Message-ID: Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Tom Everett To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 01:01:35 -0000 I'm looking at the crochet code, and I see in freebsd_install_fdt that both *.dtb and *.dts are supported. However on the source tree it's imx6.dtsi. What's the difference b/t a dts file and a dtsi file? On Sat, Mar 1, 2014 at 8:41 AM, Tim Kientzle wrote: > > On Feb 28, 2014, at 5:42 AM, Ian Lepore wrote: > > > I've added a new imx6 unified kernel config named IMX6. It has no > > compiled-in fdt, and can boot all three flavors of Wandboard when u-boot > > and ubldr load a dtb file. Folks should start using it and eventually > > the WANDBOARD* configs will go away when nobody needs them anymore. > > Nice! Another step towards GENERIC ARM. > > > the .dtb file in your /boot/kernel or /boot/modules directory, and ubldr > > will load it from there, using the filename set in the u-boot env var > > fdt_file. > > Using a U-Boot env var to specify the FDT is a nice idea. > > > Unfortunately we can't do a single image that boots any wandboard, > > because u-boot itself has to be different for each board. This is what > > my u-boot env looks like on each wandboard: > > > > => printenv > > baudrate=115200 > > bootcmd=run ubnet > > bootdelay=1 > > console=ttymxc0 > > fdt_file=wandboard-dual.dtb > > loadaddr=11000000 > > loaderdev=net > > ubmmc=fatload mmc 0 ${loadaddr} ubldr; bootelf > > ubnet=dhcp ${loadaddr} /wand/boot/ubldr;bootelf > > > > Environment size: 265/8188 bytes > > > > The only thing that differs per-board is the fdt_file setting, and the > > u-boot binary itself. > > If you could get to a single U-Boot binary, you might > be able to do what BeagleBone does: The U-boot.env > script detects the board variation and conditionally > loads the correct DTB blob. > > 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" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 03:21:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03F61999 for ; Sun, 2 Mar 2014 03:21:55 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BBA221499 for ; Sun, 2 Mar 2014 03:21:54 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id as1so4472229iec.3 for ; Sat, 01 Mar 2014 19:21:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=MmUux+XQfhhHd5LTVK2XJgfDaC07LCCWdU04GVjmgIg=; b=J1aitSThGMLYqoF9yaO1KYD6Clb0RHDiCQjnKSzYi89lSAtydNsS3PzD2LwkgDJJGU euyUKSh4doWFzW0NWtKsLMFSEmdKbhdj0hTTqeHVbfMn5bRGratd9v1Y4R1EMDWmwCO5 tum1Ye61EOAEmm+TFFtd8b53rypmR8lFmAkAZlKmUIvV9IV9coO4Dq7Lr7sLNwTq3zTe x+jin05cEzwrBVv87IbyApeuPLgJsTlkRO5TxCGVUil1367Yl8+NlMa9HQ7wg/Os8WJt 932CEHVaI+dUjvWrSq8kXJHVui+e/tyT/8XY8H3L/FaZgOsx9kHPQ8bJY0cH/EU3CHvK RNGA== X-Gm-Message-State: ALoCoQlGP8mu+nqPXlzi9amU7SNuR/XH/JfgRGEO6izY75UQiaPtlZvMeyBnCC0zrj5vRiQN9HXp X-Received: by 10.42.27.136 with SMTP id j8mr176431icc.69.1393730508196; Sat, 01 Mar 2014 19:21:48 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id bf7sm24360281igb.9.2014.03.01.19.21.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Mar 2014 19:21:47 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Warner Losh In-Reply-To: <1393702721.1149.230.camel@revolution.hippie.lan> Date: Sat, 1 Mar 2014 20:21:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393688945.1149.225.camel@revolution.hippie.lan> <05B4DCBB-E8A9-4EC1-B50C-3D2965828BF1@bsdimp.com> <1393702721.1149.230.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 03:21:55 -0000 On Mar 1, 2014, at 12:38 PM, Ian Lepore wrote: > On Sat, 2014-03-01 at 12:01 -0700, Warner Losh wrote: >> On Mar 1, 2014, at 8:49 AM, Ian Lepore wrote: >>=20 >>> On Sat, 2014-03-01 at 07:41 -0800, Tim Kientzle wrote: >>>> On Feb 28, 2014, at 5:42 AM, Ian Lepore wrote: >>>>=20 >>>>> I've added a new imx6 unified kernel config named IMX6. It has no >>>>> compiled-in fdt, and can boot all three flavors of Wandboard when = u-boot >>>>> and ubldr load a dtb file. Folks should start using it and = eventually >>>>> the WANDBOARD* configs will go away when nobody needs them = anymore. >>>>=20 >>>> Nice! Another step towards GENERIC ARM. >>=20 >> Yes, many more steps to go, but if we can have a generic kernel per = SoC that=A2s >> miles ahead of where we are now. >>=20 >>>>> the .dtb file in your /boot/kernel or /boot/modules directory, and = ubldr >>>>> will load it from there, using the filename set in the u-boot env = var >>>>> fdt_file. >>>>=20 >>>> Using a U-Boot env var to specify the FDT is a nice idea. >>=20 >> When U-Boot itself doesn=A2t have the DTB already in the image, yes. >=20 > The way wandboard's boot setup works, the u-boot binary just provides = a > default filename for fdt_file and their image has the file on the = msdos > partition, and they use an env-var script to load the file before > loading the kernel. I removed all that cruft from the environment and > let ubldr load the file named in fdt_file from the ufs filesystem. Very cool... Warner From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 05:49:17 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D11D0755; Sun, 2 Mar 2014 05:49:17 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0EAF1D48; Sun, 2 Mar 2014 05:49:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s225nHYp021881; Sun, 2 Mar 2014 05:49:17 GMT (envelope-from hrs@freefall.freebsd.org) Received: (from hrs@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s225nHU9021880; Sun, 2 Mar 2014 05:49:17 GMT (envelope-from hrs) Date: Sun, 2 Mar 2014 05:49:17 GMT Message-Id: <201403020549.s225nHU9021880@freefall.freebsd.org> To: hrs@FreeBSD.org, freebsd-arm@FreeBSD.org, hrs@FreeBSD.org From: hrs@FreeBSD.org Subject: Re: arm/187179: Wandboard ffec cannot receive IPv6 multicast X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 05:49:17 -0000 Synopsis: Wandboard ffec cannot receive IPv6 multicast Responsible-Changed-From-To: freebsd-arm->hrs Responsible-Changed-By: hrs Responsible-Changed-When: Sun Mar 2 05:49:06 UTC 2014 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=187179 From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 00:24:17 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02652814; Sun, 2 Mar 2014 00:24:17 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37CEA10EA; Sun, 2 Mar 2014 00:24:15 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s220OAtJ039756; Sun, 2 Mar 2014 02:24:10 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s220O66K039364; Sun, 2 Mar 2014 00:24:06 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 2 Mar 2014 00:24:06 GMT Message-Id: <201403020024.s220O66K039364@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 00:24:17 -0000 TB --- 2014-03-01 20:40:44 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-01 20:40:44 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-01 20:40:44 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-01 20:40:44 - cleaning the object tree TB --- 2014-03-01 20:41:40 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-01 20:41:47 - At svn revision 262666 TB --- 2014-03-01 20:41:48 - building world TB --- 2014-03-01 20:41:48 - CROSS_BUILD_TESTING=YES TB --- 2014-03-01 20:41:48 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-01 20:41:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-01 20:41:48 - SRCCONF=/dev/null TB --- 2014-03-01 20:41:48 - TARGET=arm TB --- 2014-03-01 20:41:48 - TARGET_ARCH=arm TB --- 2014-03-01 20:41:48 - TZ=UTC TB --- 2014-03-01 20:41:48 - __MAKE_CONF=/dev/null TB --- 2014-03-01 20:41:48 - cd /src TB --- 2014-03-01 20:41:48 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 1 20:41:59 UTC 2014 >>> 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 Mar 2 00:07:11 UTC 2014 TB --- 2014-03-02 00:07:11 - generating LINT kernel config TB --- 2014-03-02 00:07:11 - cd /src/sys/arm/conf TB --- 2014-03-02 00:07:11 - /usr/bin/make -B LINT TB --- 2014-03-02 00:07:11 - cd /src/sys/arm/conf TB --- 2014-03-02 00:07:11 - /usr/sbin/config -m LINT TB --- 2014-03-02 00:07:11 - building LINT kernel TB --- 2014-03-02 00:07:11 - CROSS_BUILD_TESTING=YES TB --- 2014-03-02 00:07:11 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-02 00:07:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-02 00:07:11 - SRCCONF=/dev/null TB --- 2014-03-02 00:07:11 - TARGET=arm TB --- 2014-03-02 00:07:11 - TARGET_ARCH=arm TB --- 2014-03-02 00:07:11 - TZ=UTC TB --- 2014-03-02 00:07:11 - __MAKE_CONF=/dev/null TB --- 2014-03-02 00:07:11 - cd /src TB --- 2014-03-02 00:07:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 2 00:07:11 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/at91/uart_dev_at91usart.c /src/sys/arm/at91/uart_dev_at91usart.c:243:3: error: field designator 'grab' does not refer to any field in type 'struct uart_ops' .grab = at91_usart_grab, ^ /src/sys/arm/at91/uart_dev_at91usart.c:244:3: error: field designator 'ungrab' does not refer to any field in type 'struct uart_ops' .ungrab = at91_usart_ungrab, ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-03-02 00:24:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-02 00:24:05 - ERROR: failed to build LINT kernel TB --- 2014-03-02 00:24:05 - 10020.79 user 3319.93 system 13400.81 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 03:04:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AEC98A2; Sun, 2 Mar 2014 03:04:49 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CACC412F6; Sun, 2 Mar 2014 03:04:48 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so1541701ieb.26 for ; Sat, 01 Mar 2014 19:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MmUux+XQfhhHd5LTVK2XJgfDaC07LCCWdU04GVjmgIg=; b=YP6CCWHamC7kWv0nZSvPCQNACXMlpKafHF3oGwA+9jYE2IBE9e+ZH75syhPHR5VGG5 ggiGg1aqAO0xxgyetP+vWWQTfvmiQFK9jqGOo2UxoW7CUfd9oGAdlYDqt0Zk3evhdPbH dUvbkblVLJ1iZCEsTLQXbXYxnEK/osRmFtv2ZU9YVkKnpG2QlKlts5GhbZV/4nTOkHmk x9SZlxs93koTsN436y1G+/vMYDawbfUJjpys/yzAsvOzr1/BuHjUbyeFwirA2OT/UQGe XFcEySiR2+J7jBMPCKR53K+l2BTwQwPeU2lOiVOrf1UV+hXXJ9UWTpBw1kwhjwyXye/9 UO7w== X-Received: by 10.42.53.10 with SMTP id l10mr19001226icg.33.1393729488245; Sat, 01 Mar 2014 19:04:48 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id vu3sm24262405igc.6.2014.03.01.19.04.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Mar 2014 19:04:47 -0800 (PST) Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Warner Losh In-Reply-To: <1393702721.1149.230.camel@revolution.hippie.lan> Date: Sat, 1 Mar 2014 20:04:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393688945.1149.225.camel@revolution.hippie.lan> <05B4DCBB-E8A9-4EC1-B50C-3D2965828BF1@bsdimp.com> <1393702721.1149.230.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 03:04:49 -0000 On Mar 1, 2014, at 12:38 PM, Ian Lepore wrote: > On Sat, 2014-03-01 at 12:01 -0700, Warner Losh wrote: >> On Mar 1, 2014, at 8:49 AM, Ian Lepore wrote: >>=20 >>> On Sat, 2014-03-01 at 07:41 -0800, Tim Kientzle wrote: >>>> On Feb 28, 2014, at 5:42 AM, Ian Lepore wrote: >>>>=20 >>>>> I've added a new imx6 unified kernel config named IMX6. It has no >>>>> compiled-in fdt, and can boot all three flavors of Wandboard when = u-boot >>>>> and ubldr load a dtb file. Folks should start using it and = eventually >>>>> the WANDBOARD* configs will go away when nobody needs them = anymore. >>>>=20 >>>> Nice! Another step towards GENERIC ARM. >>=20 >> Yes, many more steps to go, but if we can have a generic kernel per = SoC that=A2s >> miles ahead of where we are now. >>=20 >>>>> the .dtb file in your /boot/kernel or /boot/modules directory, and = ubldr >>>>> will load it from there, using the filename set in the u-boot env = var >>>>> fdt_file. >>>>=20 >>>> Using a U-Boot env var to specify the FDT is a nice idea. >>=20 >> When U-Boot itself doesn=A2t have the DTB already in the image, yes. >=20 > The way wandboard's boot setup works, the u-boot binary just provides = a > default filename for fdt_file and their image has the file on the = msdos > partition, and they use an env-var script to load the file before > loading the kernel. I removed all that cruft from the environment and > let ubldr load the file named in fdt_file from the ufs filesystem. Very cool... Warner From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 03:38:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0330B25 for ; Sun, 2 Mar 2014 03:38:39 +0000 (UTC) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73C0A1580 for ; Sun, 2 Mar 2014 03:38:38 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id va2so805616obc.10 for ; Sat, 01 Mar 2014 19:38:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RMYftZ52B6QNqMFTF/wNHWkw8+WyVH+oIL1fOTRhRH8=; b=XU/fKRvxFqlk+RTA7z9p4wJcSz0lPobSRa082EV763TibwulT9A2n3W6wl+CqoLGSx NccvGTzjnAnRrSM0fkHlhqyodesOZOB5Kj4+BdR8VWOEAGQW+PjYkVTzbDfBZMtIt3/I EulyDd3b0PvKsSLJ16nL7HXcxzt/YXM9NnAWpe9wl2PwjMERyFiUD8S3t5Oj8HYIDrIV ex3QS6qFwnPACbzjZ6FCG4kf6Zl9Q2IDcyQO/GY033+FCkOqgcNSLuATJAWdjtFB8AR2 H23wPAV3kEb7hMKAt/TKlc8p+JPeHqKXatV4TYsLaWozzKyoqlY9otsEQnG7koVwPpiW 3QBw== X-Gm-Message-State: ALoCoQmdtnInmsmd+JB9EZesm9QoWrNY5g1nkHbNsmDaKsbWKlzgImKz79l52xfa/zm2TE2Wz2U8 MIME-Version: 1.0 X-Received: by 10.60.174.170 with SMTP id bt10mr325459oec.47.1393731517959; Sat, 01 Mar 2014 19:38:37 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sat, 1 Mar 2014 19:38:37 -0800 (PST) In-Reply-To: References: <1393594966.1149.161.camel@revolution.hippie.lan> Date: Sat, 1 Mar 2014 20:38:37 -0700 Message-ID: Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Tom Everett To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 03:38:39 -0000 ok I figured out what the dtsi file is. I've got a bootable image here: http://files.khubla.com/freebsd-wandboard/FreeBSD-armv6-11.0-IMX6-r262666.img.gz and the boot log is here http://files.khubla.com/freebsd-wandboard/FreeBSD-armv6-11.0-IMX6-r262666.txt I put the dtb file on the FAT partition and loaded it using uEnv.txt. On Sat, Mar 1, 2014 at 6:01 PM, Tom Everett wrote: > I'm looking at the crochet code, and I see in freebsd_install_fdt that > both *.dtb and *.dts are supported. However on the source tree it's > imx6.dtsi. What's the difference b/t a dts file and a dtsi file? > > > > On Sat, Mar 1, 2014 at 8:41 AM, Tim Kientzle wrote: > >> >> On Feb 28, 2014, at 5:42 AM, Ian Lepore wrote: >> >> > I've added a new imx6 unified kernel config named IMX6. It has no >> > compiled-in fdt, and can boot all three flavors of Wandboard when u-boot >> > and ubldr load a dtb file. Folks should start using it and eventually >> > the WANDBOARD* configs will go away when nobody needs them anymore. >> >> Nice! Another step towards GENERIC ARM. >> >> > the .dtb file in your /boot/kernel or /boot/modules directory, and ubldr >> > will load it from there, using the filename set in the u-boot env var >> > fdt_file. >> >> Using a U-Boot env var to specify the FDT is a nice idea. >> >> > Unfortunately we can't do a single image that boots any wandboard, >> > because u-boot itself has to be different for each board. This is what >> > my u-boot env looks like on each wandboard: >> > >> > => printenv >> > baudrate=115200 >> > bootcmd=run ubnet >> > bootdelay=1 >> > console=ttymxc0 >> > fdt_file=wandboard-dual.dtb >> > loadaddr=11000000 >> > loaderdev=net >> > ubmmc=fatload mmc 0 ${loadaddr} ubldr; bootelf >> > ubnet=dhcp ${loadaddr} /wand/boot/ubldr;bootelf >> > >> > Environment size: 265/8188 bytes >> > >> > The only thing that differs per-board is the fdt_file setting, and the >> > u-boot binary itself. >> >> If you could get to a single U-Boot binary, you might >> be able to do what BeagleBone does: The U-boot.env >> script detects the board variation and conditionally >> loads the correct DTB blob. >> >> 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" >> > > > > -- > A better world shall emerge based on faith and understanding - Douglas > MacArthur > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 03:52:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53D05BEA for ; Sun, 2 Mar 2014 03:52:00 +0000 (UTC) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1783216A0 for ; Sun, 2 Mar 2014 03:51:59 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id wo20so3207243obc.22 for ; Sat, 01 Mar 2014 19:51:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PaVhzWFT9maYMyxTaCWgWULvPVUiGAM59vrOxeiEDbQ=; b=lSK3BqDvf6oE5csUIijXG//IvLsXnBBhFXrlDG5yuQ9U7DQEs5SWtlRsW9O46mEe33 VuGcL0aGMhHUDUgV0JoE+oku6Bn1Nt7+5Ydls8wN1OemmrveWuEe+fvpFPcK9RSqbpyV nX6490fswCZua7tfeZk6Fo+Q1saAKpHVDeYVOVtN1huD//AVidOrRp6jcmglcHNHXsav cERMRFhE5C0QqfsBAIWHp8m3ebxvKrDsCyluFVYitRWbGvHAmMUHQfDWTQAIYW0R/inM G3DzWyE4RbMJdXcQYX5ELBwFbmC17Yn00wnc6ImDjI2ARoVxg4xcP6p15XCjy5vTdTnR AZ/Q== X-Gm-Message-State: ALoCoQlsQ71NbwjMvEDJXkZHLZbAR2aXiQPbtfQepxdJW1YTnMP+UdqP+Rg3ueTsQBHPZho1KNrS MIME-Version: 1.0 X-Received: by 10.182.66.164 with SMTP id g4mr356640obt.47.1393732313717; Sat, 01 Mar 2014 19:51:53 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sat, 1 Mar 2014 19:51:53 -0800 (PST) In-Reply-To: <1393732190.1149.238.camel@revolution.hippie.lan> References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393731762.1149.233.camel@revolution.hippie.lan> <1393732190.1149.238.camel@revolution.hippie.lan> Date: Sat, 1 Mar 2014 20:51:53 -0700 Message-ID: Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 03:52:00 -0000 Awesome, I'll give this new ubldr a try. No, I didn't enable SMP; I used the default IMX6 kernel. I look forward to it being enabled. On Sat, Mar 1, 2014 at 8:49 PM, Ian Lepore wrote: > On Sat, 2014-03-01 at 20:44 -0700, Tom Everett wrote: > > I've got an image that loads the dtb from the FAT partition. However, it > > was mentioned that the dtb could be loaded from the UFS partition. Given > > that u-boot doesn't have UFS support, how would this work? > > > > Ubldr does it, not u-boot. > > I modified ubldr a couple days ago. It first looks for a file arleady > loaded by u-boot. If u-boot didn't load one, it next looks for a u-boot > environment variable named fdt_file and loads that file from the ufs > file system if it can find it in /boot/kernel or /boot/modules. > > So basically just stop loading the file in u-boot and put a copy of the > file in /boot/modules and ubldr will load it. > > I noticed in the boot log you posted that you didn't enable SMP and it's > only running one core, is that what you intended? I didn't turn on SMP > by default yet, but I probably will in a few days because it seems > fairly stable so far. > > -- Ian > > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 12:10:47 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B41F4F3; Sun, 2 Mar 2014 12:10:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 002B91A9B; Sun, 2 Mar 2014 12:10:46 +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 s22CAeC7071042; Sun, 2 Mar 2014 07:10: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 s22CAebY071035; Sun, 2 Mar 2014 12:10:40 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 2 Mar 2014 12:10:40 GMT Message-Id: <201403021210.s22CAebY071035@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 12:10:47 -0000 TB --- 2014-03-02 10:30:27 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-03-02 10:30:27 - 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 --- 2014-03-02 10:30:27 - starting HEAD tinderbox run for arm/arm TB --- 2014-03-02 10:30:27 - cleaning the object tree TB --- 2014-03-02 10:30:27 - /usr/local/bin/svn stat /src TB --- 2014-03-02 10:30:34 - At svn revision 262685 TB --- 2014-03-02 10:30:35 - building world TB --- 2014-03-02 10:30:35 - CROSS_BUILD_TESTING=YES TB --- 2014-03-02 10:30:35 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-02 10:30:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-02 10:30:35 - SRCCONF=/dev/null TB --- 2014-03-02 10:30:35 - TARGET=arm TB --- 2014-03-02 10:30:35 - TARGET_ARCH=arm TB --- 2014-03-02 10:30:35 - TZ=UTC TB --- 2014-03-02 10:30:35 - __MAKE_CONF=/dev/null TB --- 2014-03-02 10:30:35 - cd /src TB --- 2014-03-02 10:30:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 2 10:30:42 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_cursor.c -o frm_cursor.o cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_data.c -o frm_data.o cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_def.c -o frm_def.o cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_driver.c -o frm_driver.o /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_driver.c:4506:9: error: comparison of integers of different signs: 'wchar_t' (aka 'unsigned int') and 'int' [-Werror,-Wsign-compare] if (c == FIRST_ACTIVE_MAGIC) ~ ^ ~~~~~~~~~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. bmake[5]: stopped in /src/lib/ncurses/formw *** Error code 1 Stop. bmake[4]: stopped in /src/lib/ncurses *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-03-02 12:10:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-02 12:10:39 - ERROR: failed to build world TB --- 2014-03-02 12:10:39 - 4874.60 user 891.66 system 6012.19 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 15:25:06 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 256D6C22; Sun, 2 Mar 2014 15:25:06 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52ED61A99; Sun, 2 Mar 2014 15:25:04 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s22FOhqC010032; Sun, 2 Mar 2014 17:24:43 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s22FOaYT009073; Sun, 2 Mar 2014 15:24:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 2 Mar 2014 15:24:36 GMT Message-Id: <201403021524.s22FOaYT009073@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 15:25:06 -0000 TB --- 2014-03-02 11:40:44 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-02 11:40:44 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-02 11:40:44 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-02 11:40:44 - cleaning the object tree TB --- 2014-03-02 11:41:39 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-02 11:41:47 - At svn revision 262685 TB --- 2014-03-02 11:41:48 - building world TB --- 2014-03-02 11:41:48 - CROSS_BUILD_TESTING=YES TB --- 2014-03-02 11:41:48 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-02 11:41:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-02 11:41:48 - SRCCONF=/dev/null TB --- 2014-03-02 11:41:48 - TARGET=arm TB --- 2014-03-02 11:41:48 - TARGET_ARCH=arm TB --- 2014-03-02 11:41:48 - TZ=UTC TB --- 2014-03-02 11:41:48 - __MAKE_CONF=/dev/null TB --- 2014-03-02 11:41:48 - cd /src TB --- 2014-03-02 11:41:48 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 2 11:41:58 UTC 2014 >>> 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 Mar 2 15:07:40 UTC 2014 TB --- 2014-03-02 15:07:40 - generating LINT kernel config TB --- 2014-03-02 15:07:40 - cd /src/sys/arm/conf TB --- 2014-03-02 15:07:40 - /usr/bin/make -B LINT TB --- 2014-03-02 15:07:40 - cd /src/sys/arm/conf TB --- 2014-03-02 15:07:40 - /usr/sbin/config -m LINT TB --- 2014-03-02 15:07:40 - building LINT kernel TB --- 2014-03-02 15:07:40 - CROSS_BUILD_TESTING=YES TB --- 2014-03-02 15:07:40 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-02 15:07:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-02 15:07:40 - SRCCONF=/dev/null TB --- 2014-03-02 15:07:40 - TARGET=arm TB --- 2014-03-02 15:07:40 - TARGET_ARCH=arm TB --- 2014-03-02 15:07:40 - TZ=UTC TB --- 2014-03-02 15:07:40 - __MAKE_CONF=/dev/null TB --- 2014-03-02 15:07:40 - cd /src TB --- 2014-03-02 15:07:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 2 15:07:40 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/at91/uart_dev_at91usart.c /src/sys/arm/at91/uart_dev_at91usart.c:243:3: error: field designator 'grab' does not refer to any field in type 'struct uart_ops' .grab = at91_usart_grab, ^ /src/sys/arm/at91/uart_dev_at91usart.c:244:3: error: field designator 'ungrab' does not refer to any field in type 'struct uart_ops' .ungrab = at91_usart_ungrab, ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-03-02 15:24:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-02 15:24:35 - ERROR: failed to build LINT kernel TB --- 2014-03-02 15:24:35 - 10036.58 user 3326.78 system 13431.34 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 16:30:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC42F5AB for ; Sun, 2 Mar 2014 16:30:14 +0000 (UTC) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F68310F5 for ; Sun, 2 Mar 2014 16:30:14 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id h18so5781420igc.1 for ; Sun, 02 Mar 2014 08:30:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QZh2nY79bvy+KRwAgEsa3IiNYTk27pVMDsIItBruHiE=; b=VAfcePff1wwakO5fHqdMH8v/2Iv0TSOheZ1aBmXZgyqXhfnF+ilwn/QxGuSRI0ClD/ HPZhUAaVhLGKnMyIVNIrUt0eosG0kfJfM2ZfwnDoxTFILwlv89QLX2zXN5HW5uRUYZOi BeJsN4fao7GNHka/plnsMPmGTvuXrGBNAqQM4KLRN+H6XsmADuPyznQ9V0gcK+pQz/gk mUvoUruk0NG5bGDyGk8m3XkRkLJ8WTwQuH887j74QntR8iH62dNvl4/x0Uska5rdN0AH 3VpEw8FzBDgCKCRuk8Z1K13RHZLWN//7dep/0p+/wkhGiwxHFocRrSQI7Cru38bh0e76 suiQ== X-Gm-Message-State: ALoCoQm9QHYOcpqHblTGQzvXWQGyQ/ouStOzDCMiGcmgJcdt1KxlnVML4adAd1nh1OdRUXbxnYMq X-Received: by 10.42.246.8 with SMTP id lw8mr21641566icb.22.1393777807940; Sun, 02 Mar 2014 08:30:07 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id dz8sm29966116igb.5.2014.03.02.08.30.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 08:30:07 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Warner Losh In-Reply-To: <1393731762.1149.233.camel@revolution.hippie.lan> Date: Sun, 2 Mar 2014 09:30:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9BF14340-2267-473E-B047-E377AA258713@bsdimp.com> References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393731762.1149.233.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 16:30:15 -0000 On Mar 1, 2014, at 8:42 PM, Ian Lepore wrote: > On Sat, 2014-03-01 at 18:01 -0700, Tom Everett wrote: >> I'm looking at the crochet code, and I see in freebsd_install_fdt = that both >> *.dtb and *.dts are supported. However on the source tree it's = imx6.dtsi. >> What's the difference b/t a dts file and a dtsi file? >=20 > A .dtsi file is an include file used by .dts files. A .dtb is the > binary (compiled) form used by the kernel. >=20 > So there are several wandboard-something.dts files, each of which > includes imx6.dtsi where all the common parts live. For a new imx6 > device, a new board-named file similar to one of the wandboard files = is > necessary, and it would also include imx6.dtsi. As would other boards that use the imx6 SoC. They=92d have their own = .dts file that included the imx6.dsti and customized it for how they are = wired together. > We're pushing hard towards just using the standard dtb files from > vendors, but we've got a bit of work to do before we're there. I have some rough changes that allow us to build N different DTBs as = part of the kernel build, but not glom them into the kernel. Not strictly = required for this, but helpful. I=92m planning on having Atmel use 100% vendor supplied files as well. It is a very good goal. There=92s also efforts on the linux side to = separate out the device-trees from the linux kernel, which is where I grabbed the = recent /vendor/device-tree stuff from. Warner From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 16:41:16 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB4C37B4 for ; Sun, 2 Mar 2014 16:41:16 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 790D411AF for ; Sun, 2 Mar 2014 16:41:16 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WK9Rz-000AYM-76; Sun, 02 Mar 2014 16:41:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s22GfCw9045450; Sun, 2 Mar 2014 09:41:12 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19SK2E2ZxN37Yf7VTy7VVQc Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Ian Lepore To: Warner Losh In-Reply-To: <9BF14340-2267-473E-B047-E377AA258713@bsdimp.com> References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393731762.1149.233.camel@revolution.hippie.lan> <9BF14340-2267-473E-B047-E377AA258713@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" Date: Sun, 02 Mar 2014 09:41:12 -0700 Message-ID: <1393778472.1149.242.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s22GfCw9045450 Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 16:41:16 -0000 On Sun, 2014-03-02 at 09:30 -0700, Warner Losh wrote: > On Mar 1, 2014, at 8:42 PM, Ian Lepore wrote: >=20 > > On Sat, 2014-03-01 at 18:01 -0700, Tom Everett wrote: > >> I'm looking at the crochet code, and I see in freebsd_install_fdt th= at both > >> *.dtb and *.dts are supported. However on the source tree it's imx6.= dtsi. > >> What's the difference b/t a dts file and a dtsi file? > >=20 > > A .dtsi file is an include file used by .dts files. A .dtb is the > > binary (compiled) form used by the kernel. > >=20 > > So there are several wandboard-something.dts files, each of which > > includes imx6.dtsi where all the common parts live. For a new imx6 > > device, a new board-named file similar to one of the wandboard files = is > > necessary, and it would also include imx6.dtsi. >=20 > As would other boards that use the imx6 SoC. They=A2d have their own .d= ts > file that included the imx6.dsti and customized it for how they are wir= ed > together. >=20 > > We're pushing hard towards just using the standard dtb files from > > vendors, but we've got a bit of work to do before we're there. >=20 > I have some rough changes that allow us to build N different DTBs as pa= rt > of the kernel build, but not glom them into the kernel. Not strictly re= quired > for this, but helpful. >=20 > I=A2m planning on having Atmel use 100% vendor supplied files as well. > It is a very good goal. There=A2s also efforts on the linux side to sep= arate out > the device-trees from the linux kernel, which is where I grabbed the re= cent > /vendor/device-tree stuff from. >=20 > Warner For imx6, the big obstacle to using vendor dtb files is now just the device instantiation order. The stock dts files list devices basically in order of their memory-mapped register addresses, but we need the interrupt controller to be available first regardless of where it's mapped, and likewise for a few other critical devices. I need to do another round of experimentation with the EARLY_DRIVER_MODULE() stuff and multipass device instantiation. We may not be all that far from success. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 18:32:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA4E71F4 for ; Sun, 2 Mar 2014 18:32:08 +0000 (UTC) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8EDFC1AF9 for ; Sun, 2 Mar 2014 18:32:08 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id uq10so267222igb.5 for ; Sun, 02 Mar 2014 10:32:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=V6U0ukesuG3O/jE2RbYGgmZovtUr+8fl2ltJPn07vFQ=; b=OKhOb5iulf4iseAavd+h6kceRoevBjVaFJCn8EzZ4E/eAGQJqztPXeb6YwhsTcvoRr AnvwUeapZ3tIfRj3M4/3BtxOrYBlaeHAbY9oq9Zqg/c8JhVmpyOsEdtQQnIjkLwMLtpw I8o/PSC7EnajNuFUY27xX7h4ksUNCfilMV2ecOX67XXlSfUEr+nJCn/0OPYIFFWsnF94 uggusQk8HOaWtgMqTpsRB8vvTAEYbtYiqziXu/L0yQ2FMo2efbD7lo+1s8Fs0lHg2iID VI5PwXhoE9EfRHm42ryXEcrKti7rMD/10SZnx7VgA59dcnmaKibysUrrU9hdgQ55KbJI V60w== X-Gm-Message-State: ALoCoQk6/4yZIlEAs0h66XxXmorJwmi8iYLuKcIHc1AaviGmJcZr7OCxcSVsjYlFhfX5S5KcBdcz X-Received: by 10.42.215.207 with SMTP id hf15mr22697845icb.17.1393785121881; Sun, 02 Mar 2014 10:32:01 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id r4sm30909984igh.1.2014.03.02.10.32.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 10:32:01 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1253 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Warner Losh In-Reply-To: <1393778472.1149.242.camel@revolution.hippie.lan> Date: Sun, 2 Mar 2014 11:32:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393731762.1149.233.camel@revolution.hippie.lan> <9BF14340-2267-473E-B047-E377AA258713@bsdimp.com> <1393778472.1149.242.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 18:32:08 -0000 On Mar 2, 2014, at 9:41 AM, Ian Lepore wrote: > On Sun, 2014-03-02 at 09:30 -0700, Warner Losh wrote: >> On Mar 1, 2014, at 8:42 PM, Ian Lepore wrote: >>=20 >>> On Sat, 2014-03-01 at 18:01 -0700, Tom Everett wrote: >>>> I'm looking at the crochet code, and I see in freebsd_install_fdt = that both >>>> *.dtb and *.dts are supported. However on the source tree it's = imx6.dtsi. >>>> What's the difference b/t a dts file and a dtsi file? >>>=20 >>> A .dtsi file is an include file used by .dts files. A .dtb is the >>> binary (compiled) form used by the kernel. >>>=20 >>> So there are several wandboard-something.dts files, each of which >>> includes imx6.dtsi where all the common parts live. For a new imx6 >>> device, a new board-named file similar to one of the wandboard files = is >>> necessary, and it would also include imx6.dtsi. >>=20 >> As would other boards that use the imx6 SoC. They=92d have their own = .dts >> file that included the imx6.dsti and customized it for how they are = wired >> together. >>=20 >>> We're pushing hard towards just using the standard dtb files from >>> vendors, but we've got a bit of work to do before we're there. >>=20 >> I have some rough changes that allow us to build N different DTBs as = part >> of the kernel build, but not glom them into the kernel. Not strictly = required >> for this, but helpful. >>=20 >> I=92m planning on having Atmel use 100% vendor supplied files as = well. >> It is a very good goal. There=92s also efforts on the linux side to = separate out >> the device-trees from the linux kernel, which is where I grabbed the = recent >> /vendor/device-tree stuff from. >>=20 >> Warner >=20 > For imx6, the big obstacle to using vendor dtb files is now just the > device instantiation order. The stock dts files list devices = basically > in order of their memory-mapped register addresses, but we need the > interrupt controller to be available first regardless of where it's > mapped, and likewise for a few other critical devices. >=20 > I need to do another round of experimentation with the > EARLY_DRIVER_MODULE() stuff and multipass device instantiation. We = may > not be all that far from success. Taking your patches, I expanded them so that I could list the interrupt = controller and such last on my Atmel boards, but still have it attach first=85 I = want to make sure that I can get the NAND working just from the FDT file and then I=92d= feel comfortable committing. Interested in peeking at the diffs before I do? Warner= From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 19:41:02 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E7F076B; Sun, 2 Mar 2014 19:41:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E892E11A6; Sun, 2 Mar 2014 19:41:01 +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 s22Jf0nO014527; Sun, 2 Mar 2014 14:41:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s22Jf0qk014526; Sun, 2 Mar 2014 19:41:00 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 2 Mar 2014 19:41:00 GMT Message-Id: <201403021941.s22Jf0qk014526@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 19:41:02 -0000 TB --- 2014-03-02 18:00:19 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-03-02 18:00:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-02 18:00:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-03-02 18:00:19 - cleaning the object tree TB --- 2014-03-02 18:01:52 - /usr/local/bin/svn stat /src TB --- 2014-03-02 18:01:56 - At svn revision 262694 TB --- 2014-03-02 18:01:57 - building world TB --- 2014-03-02 18:01:57 - CROSS_BUILD_TESTING=YES TB --- 2014-03-02 18:01:57 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-02 18:01:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-02 18:01:57 - SRCCONF=/dev/null TB --- 2014-03-02 18:01:57 - TARGET=arm TB --- 2014-03-02 18:01:57 - TARGET_ARCH=arm TB --- 2014-03-02 18:01:57 - TZ=UTC TB --- 2014-03-02 18:01:57 - __MAKE_CONF=/dev/null TB --- 2014-03-02 18:01:57 - cd /src TB --- 2014-03-02 18:01:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 2 18:02:04 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_cursor.c -o frm_cursor.o cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_data.c -o frm_data.o cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_def.c -o frm_def.o cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_driver.c -o frm_driver.o /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_driver.c:4506:9: error: comparison of integers of different signs: 'wchar_t' (aka 'unsigned int') and 'int' [-Werror,-Wsign-compare] if (c == FIRST_ACTIVE_MAGIC) ~ ^ ~~~~~~~~~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. bmake[5]: stopped in /src/lib/ncurses/formw *** Error code 1 Stop. bmake[4]: stopped in /src/lib/ncurses *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-03-02 19:41:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-02 19:41:00 - ERROR: failed to build world TB --- 2014-03-02 19:41:00 - 4875.54 user 866.42 system 6040.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 19:51:00 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A3CAB9E for ; Sun, 2 Mar 2014 19:51:00 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30534128E for ; Sun, 2 Mar 2014 19:50:59 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WKCPa-000LGM-Ou for freebsd-arm@FreeBSD.org; Sun, 02 Mar 2014 19:50:59 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s22JoupB045596 for ; Sun, 2 Mar 2014 12:50:56 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19yDcD+r74vAqgXptZ1dk41 Subject: imx6 SMP enabled by default From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Mar 2014 12:50:55 -0700 Message-ID: <1393789855.1149.246.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 19:51:00 -0000 As of r262695 option SMP is turned on in the IMX6 kernel config. I also added a new tunable so that if you have trouble that might be related to SMP you can "set hw.ncpu=1" at the ubldr prompt or in /boot/loader.rc and it will boot with a single core (you can set any number from 1 to the number cores the chip has). Also, FYI, you can put "set autoboot_delay=2" in /boot/loader.rc (or any number you're happy with). You can hit a key at any point while it's loading the kernel and it will give you the interactive prompt before booting, so a short delay works fine. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 20:09:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EB3C4D7 for ; Sun, 2 Mar 2014 20:09:27 +0000 (UTC) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56D9D1388 for ; Sun, 2 Mar 2014 20:09:26 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id gq1so6035314obb.18 for ; Sun, 02 Mar 2014 12:09:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yFzOj1bE24wpCEv8u+Fql57L1EFZqK6CRH3y7ji6SH8=; b=hc3hEyjK7DHJTcXxaTQh6TZOt6nYDUrdY0Uzuc6PYomAWNhblVdu1SffHn8Zcah1EV JCQS7VpE9X5+vX34ln/PwJOX1uZaVGxSpJ2wP2FM8vMEuei3SM3DE59s4T35piPd40xl z/PdHMk9SQ861K2f+V6rzH4no8S6Oraaq99HJEMH3n9mSZ0kUtisEqCMMscrMxzd0SbR m4PR/bvYirUUH5MHH7tS5c2bIRGBkk0Nr91oPETHBj7jnKMwDq0uQrzIytmP6hVzPaUs Eqd9i8GiZKQNP5gqC2k5IlYQLQNvAAwxJRt7/BA0Qg0R0X+lTIDDKZAZuNFXcLv+Mb6b 9G8g== X-Gm-Message-State: ALoCoQngjrTJ+tLiSnQgFb7AkDGUg8DgUPkf/zj0te4c7Od7BVt7Yy1Vs76/3c8L3uFYAw9nlPlz MIME-Version: 1.0 X-Received: by 10.182.128.138 with SMTP id no10mr24239757obb.32.1393790966186; Sun, 02 Mar 2014 12:09:26 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sun, 2 Mar 2014 12:09:26 -0800 (PST) In-Reply-To: <1393789855.1149.246.camel@revolution.hippie.lan> References: <1393789855.1149.246.camel@revolution.hippie.lan> Date: Sun, 2 Mar 2014 13:09:26 -0700 Message-ID: Subject: Re: imx6 SMP enabled by default From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 20:09:27 -0000 I enabled the SMP flag in revision 262666 and voila, I have 4 cores! The boot log is here http://files.khubla.com/freebsd-wandboard/FreeBSD-armv6-11.0-IMX6-r262666.txt and the build is here http://files.khubla.com/freebsd-wandboard/FreeBSD-armv6-11.0-IMX6-r262666.img.gz On Sun, Mar 2, 2014 at 12:50 PM, Ian Lepore wrote: > As of r262695 option SMP is turned on in the IMX6 kernel config. I also > added a new tunable so that if you have trouble that might be related to > SMP you can "set hw.ncpu=1" at the ubldr prompt or in /boot/loader.rc > and it will boot with a single core (you can set any number from 1 to > the number cores the chip has). > > Also, FYI, you can put "set autoboot_delay=2" in /boot/loader.rc (or any > number you're happy with). You can hit a key at any point while it's > loading the kernel and it will give you the interactive prompt before > booting, so a short delay works fine. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 22:54:41 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD77B9B7; Sun, 2 Mar 2014 22:54:41 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0ED4412AE; Sun, 2 Mar 2014 22:54:40 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s22MsGkn010364; Mon, 3 Mar 2014 00:54:16 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s22MsCUL009918; Sun, 2 Mar 2014 22:54:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 2 Mar 2014 22:54:12 GMT Message-Id: <201403022254.s22MsCUL009918@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 22:54:42 -0000 TB --- 2014-03-02 19:10:45 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-02 19:10:45 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-02 19:10:45 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-02 19:10:45 - cleaning the object tree TB --- 2014-03-02 19:11:39 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-02 19:11:45 - At svn revision 262694 TB --- 2014-03-02 19:11:46 - building world TB --- 2014-03-02 19:11:46 - CROSS_BUILD_TESTING=YES TB --- 2014-03-02 19:11:46 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-02 19:11:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-02 19:11:46 - SRCCONF=/dev/null TB --- 2014-03-02 19:11:46 - TARGET=arm TB --- 2014-03-02 19:11:46 - TARGET_ARCH=arm TB --- 2014-03-02 19:11:46 - TZ=UTC TB --- 2014-03-02 19:11:46 - __MAKE_CONF=/dev/null TB --- 2014-03-02 19:11:46 - cd /src TB --- 2014-03-02 19:11:46 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 2 19:11:58 UTC 2014 >>> 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 Mar 2 22:37:17 UTC 2014 TB --- 2014-03-02 22:37:17 - generating LINT kernel config TB --- 2014-03-02 22:37:17 - cd /src/sys/arm/conf TB --- 2014-03-02 22:37:17 - /usr/bin/make -B LINT TB --- 2014-03-02 22:37:17 - cd /src/sys/arm/conf TB --- 2014-03-02 22:37:17 - /usr/sbin/config -m LINT TB --- 2014-03-02 22:37:17 - building LINT kernel TB --- 2014-03-02 22:37:17 - CROSS_BUILD_TESTING=YES TB --- 2014-03-02 22:37:17 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-02 22:37:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-02 22:37:17 - SRCCONF=/dev/null TB --- 2014-03-02 22:37:17 - TARGET=arm TB --- 2014-03-02 22:37:17 - TARGET_ARCH=arm TB --- 2014-03-02 22:37:17 - TZ=UTC TB --- 2014-03-02 22:37:17 - __MAKE_CONF=/dev/null TB --- 2014-03-02 22:37:17 - cd /src TB --- 2014-03-02 22:37:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 2 22:37:17 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/at91/uart_dev_at91usart.c /src/sys/arm/at91/uart_dev_at91usart.c:243:3: error: field designator 'grab' does not refer to any field in type 'struct uart_ops' .grab = at91_usart_grab, ^ /src/sys/arm/at91/uart_dev_at91usart.c:244:3: error: field designator 'ungrab' does not refer to any field in type 'struct uart_ops' .ungrab = at91_usart_ungrab, ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-03-02 22:54:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-02 22:54:11 - ERROR: failed to build LINT kernel TB --- 2014-03-02 22:54:11 - 10032.41 user 3322.23 system 13405.80 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 23:56:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2664517; Sun, 2 Mar 2014 23:56:19 +0000 (UTC) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 10F6B184E; Sun, 2 Mar 2014 23:56:18 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id h10so3984767eak.22 for ; Sun, 02 Mar 2014 15:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=r/EEzXsRPt4GOCkAdcyDJVvG3PgQOpvyegLiLjx3MFQ=; b=g9eCkjZ9KGXnmYP7/YwkGBH8H1yFa3F1BXl5mTyP2l4MGNx9dXww9Fz0SW2XRZ/MjH KoEEBN2O4cPjMYNkzjO0wvBi9qJuQGFAZYPGvSPgmRpFbHXJzTEZmJNHOJ+sBIWcK1g5 IFWdztAl7sCCZFYXqX7c17Wln4MvaSlK5EjpzwqwpUzEM3YJ/zomSRo7KGXdE/E0iv3m cgUxPjzx9SwOPlHZ5R9ElEIXgn8zu8PJiqSoMfS/jkdCHReZMEKlKexHgQ/72DKWyGYs B04YLHBYv/sTTdiIbxUTxFhwwYazDyiM/1f8ZcCi48xA3D9H73ZsEOgnxLiXY5eoOoQe Y1Ug== MIME-Version: 1.0 X-Received: by 10.204.81.14 with SMTP id v14mr5909456bkk.3.1393804577340; Sun, 02 Mar 2014 15:56:17 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.205.71.201 with HTTP; Sun, 2 Mar 2014 15:56:17 -0800 (PST) Date: Sun, 2 Mar 2014 18:56:17 -0500 X-Google-Sender-Auth: 0fIeyW3wagW4_GZIa8h4rRj6W2U Message-ID: Subject: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: freebsd-embedded@freebsd.org Content-Type: multipart/mixed; boundary=047d7beb9394b8344804f3a86a73 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 23:56:19 -0000 --047d7beb9394b8344804f3a86a73 Content-Type: text/plain; charset=ISO-8859-1 Hi, The attached patch (fdt_probe_order_control.patch) allows control over the probe order of simplebus child devices by using a "probe-order" property in simplebus child nodes in the .dts file. This was motivated by booting FreeBSD from the eMMC on a BeagleBone Black, which has a pluggable microSD card slot in addition to the eMMC. The order that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes the pluggable slot to be probed/attached first, so the device name assigned to the eMMC soldered to the board changes depending on whether there is a card in the pluggable slot, which makes establishing appropriate /etc/fstab contents less than convenient. By using the "probe-order" property in sys/boot/fdt/dts/beaglebone-black.dts (see attached beaglebone_black_mmc_probe_order.patch), I am able to swap the order in which the mmc units are probed/attached for that board. This avoids inappropriate hacking of the mmc definition order in am335x.dtsi, which is shared among multiple boards. This is not a general solution to the problem of wanting stable device names for hard-wired MMC devices when pluggable slots are present in the system. There could, for example, be a multi-slot MMC controller with a mixture of hard-wired and pluggable devices attached, and this would not address that case. However, it does address the needs of BeagleBone Black, and the mechanism may be of use for similar issues on other platforms. Both patches were generated against 10-STABLE, r262447. -Patrick --047d7beb9394b8344804f3a86a73 Content-Type: application/octet-stream; name="fdt_probe_order_control.patch" Content-Disposition: attachment; filename="fdt_probe_order_control.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsaz0nxi0 SW5kZXg6IHN5cy9kZXYvZmR0L3NpbXBsZWJ1cy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvZmR0 L3NpbXBsZWJ1cy5jCShyZXZpc2lvbiAyNjI0NDcpCisrKyBzeXMvZGV2L2ZkdC9zaW1wbGVidXMu Ywkod29ya2luZyBjb3B5KQpAQCAtMTYxLDE2ICsxNjEsNjEgQEAKIAlzdHJ1Y3Qgc2ltcGxlYnVz X2RldmluZm8gKmRpOwogCXN0cnVjdCBzaW1wbGVidXNfc29mdGMgKnNjOwogCXBoYW5kbGVfdCBk dF9ub2RlLCBkdF9jaGlsZDsKKyNkZWZpbmUgUFJPQkVfVU5PUkRFUkVEIElOVDMyX01JTgorCWlu dDMyX3QgcHJvYmVfb3JkZXI7CisJc3RydWN0IHNvcnRxX2VudHJ5IHsKKwkJVEFJTFFfRU5UUlko c29ydHFfZW50cnkpIGxpbms7CisJCWludDMyX3QgcHJvYmVfb3JkZXI7CisJCXBoYW5kbGVfdCBk dF9jaGlsZDsKKwl9ICpuZXdfc3FlLCAqc3FlLCAqc3FlX3RtcDsKKwlUQUlMUV9IRUFEKHNvcnRx X2hlYWQsIHNvcnRxX2VudHJ5KSBzcSA9IFRBSUxRX0hFQURfSU5JVElBTElaRVIoc3EpOwogCiAJ c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAKIAkvKgotCSAqIFdhbGsgc2ltcGxlLWJ1cyBh bmQgYWRkIGRpcmVjdCBzdWJvcmRpbmF0ZXMgYXMgb3VyIGNoaWxkcmVuLgorCSAqIFdhbGsgc2lt cGxlLWJ1cyBhbmQgcXVldWUgZGlyZWN0IHN1Ym9yZGluYXRlcyB0byBiZSBhZGRlZCBhcyBvdXIK KwkgKiBjaGlsZHJlbiBiZWxvdywgcmVzcGVjdGluZyBhbnkgc3BlY2lmaWVkIHByb2JlIG9yZGVy aW5nLgogCSAqLwogCWR0X25vZGUgPSBvZndfYnVzX2dldF9ub2RlKGRldik7CiAJZm9yIChkdF9j aGlsZCA9IE9GX2NoaWxkKGR0X25vZGUpOyBkdF9jaGlsZCAhPSAwOwogCSAgICBkdF9jaGlsZCA9 IE9GX3BlZXIoZHRfY2hpbGQpKSB7CiAKKwkJbmV3X3NxZSA9IG1hbGxvYyhzaXplb2YoKnNxZSks IE1fU0lNUExFQlVTLCBNX1dBSVRPSyk7CisJCW5ld19zcWUtPmR0X2NoaWxkID0gZHRfY2hpbGQ7 CisKKwkJLyoKKwkJICogUHJlc2VydmUgdGhlIGV4aXN0aW5nIG9yZGVyLCB1bmxlc3MgdGhpcyBj aGlsZCBoYXMgYQorCQkgKiBzcGVjaWZpZWQgcHJvYmUtb3JkZXIgYW5kIGl0IGlzIGxlc3MgdGhh biB0aGUgc3BlY2lmaWVkCisJCSAqIHByb2JlIG9yZGVyIG9mIGEgcHJldmlvdXMgY2hpbGQsIGlu IHdoaWNoIGNhc2UgdGhpcyBjaGlsZAorCQkgKiBpcyBpbnNlcnRlZCBqdXN0IHByaW9yIHRvIHRo YXQgcHJldmlvdXMgY2hpbGQuCisJCSAqLworCQlpZiAoT0ZfZ2V0cHJvcChkdF9jaGlsZCwgInBy b2JlLW9yZGVyIiwgJnByb2JlX29yZGVyLCBzaXplb2YocHJvYmVfb3JkZXIpKSA+IDApIHsKKwkJ CW5ld19zcWUtPnByb2JlX29yZGVyID0gKGludDMyX3QpZmR0X2RhdGFfZ2V0KCZwcm9iZV9vcmRl ciwgMSk7CisKKwkJCVRBSUxRX0ZPUkVBQ0goc3FlLCAmc3EsIGxpbmspIHsKKwkJCQlpZiAoKFBS T0JFX1VOT1JERVJFRCAhPSBzcWUtPnByb2JlX29yZGVyKSAmJgorCQkJCSAgICAobmV3X3NxZS0+ cHJvYmVfb3JkZXIgPCBzcWUtPnByb2JlX29yZGVyKSkgeworCQkJCQlUQUlMUV9JTlNFUlRfQkVG T1JFKHNxZSwgbmV3X3NxZSwgbGluayk7CisJCQkJCWJyZWFrOworCQkJCX0KKwkJCX0KKworCQkJ aWYgKE5VTEwgPT0gc3FlKSB7CisJCQkJVEFJTFFfSU5TRVJUX1RBSUwoJnNxLCBuZXdfc3FlLCBs aW5rKTsKKwkJCX0KKwkJfSBlbHNlIHsKKwkJCW5ld19zcWUtPnByb2JlX29yZGVyID0gUFJPQkVf VU5PUkRFUkVEOworCQkJVEFJTFFfSU5TRVJUX1RBSUwoJnNxLCBuZXdfc3FlLCBsaW5rKTsKKwkJ fQorCX0KKworCS8qCisJICogQWRkIHRoZSBxdWV1ZWQgc3Vib3JkaW5hdGVzIGFzIGNoaWxkcmVu LgorCSAqLworCVRBSUxRX0ZPUkVBQ0hfU0FGRShzcWUsICZzcSwgbGluaywgc3FlX3RtcCkgewor CQlkdF9jaGlsZCA9IHNxZS0+ZHRfY2hpbGQ7CisJCWZyZWUoc3FlLCBNX1NJTVBMRUJVUyk7CisK IAkJLyogQ2hlY2sgYW5kIHByb2Nlc3MgJ3N0YXR1cycgcHJvcGVydHkuICovCiAJCWlmICghKGZk dF9pc19lbmFibGVkKGR0X2NoaWxkKSkpCiAJCQljb250aW51ZTsK --047d7beb9394b8344804f3a86a73 Content-Type: application/octet-stream; name="beaglebone_black_probe_order.patch" Content-Disposition: attachment; filename="beaglebone_black_probe_order.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsaz0qzm1 SW5kZXg6IHN5cy9ib290L2ZkdC9kdHMvYmVhZ2xlYm9uZS1ibGFjay5kdHMKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gc3lzL2Jvb3QvZmR0L2R0cy9iZWFnbGVib25lLWJsYWNrLmR0cwkocmV2aXNpb24gMjYyNDQ3 KQorKysgc3lzL2Jvb3QvZmR0L2R0cy9iZWFnbGVib25lLWJsYWNrLmR0cwkod29ya2luZyBjb3B5 KQpAQCAtMTM2LDggKzEzNiwxMiBAQAogCQltbWNoczFANDgxRDgwMDAgewogICAgICAgICAgICAg ICAgIAlidXMtd2lkdGggPSA8OD47CiAJCQlzdGF0dXMgPSAib2theSI7CisJCQlwcm9iZS1vcmRl ciA9IDwxMDAwPjsKIAkJfTsKIAorCQltbWNoczBANDgwNjAwMDAgeworCQkJcHJvYmUtb3JkZXIg PSA8MTAwMT47CisJCX07CiAgCiAJCWkyY0A0NGUwYjAwMCB7CiAJCQlwbWljQDI0IHsK --047d7beb9394b8344804f3a86a73-- From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 00:47:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2714B228 for ; Mon, 3 Mar 2014 00:47:09 +0000 (UTC) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C60611C28 for ; Mon, 3 Mar 2014 00:47:08 +0000 (UTC) Received: from 127.0.0.1 (exit1.torproxy.org [89.187.142.208]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id s230ktaI021034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 2 Mar 2014 19:46:58 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <5313D0FE.8010008@ceetonetechnology.com> Date: Sun, 02 Mar 2014 19:46:54 -0500 From: George Rosamond MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: TMPFS in kernels Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 00:47:09 -0000 Is there a reason why TMPFS(5) is not in the 10-Stable's ALIX and RPI-B kernels, yet in BEAGLEBONE? Haven't checked the others. Seems like a strong and mature replacement for md(4) from my experiences, and probably belongs in the Crochet fstabs. I have been using on Alix, RPis, x86 for a long while, and never had any (noticeable) issues. g From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 01:58:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8047723 for ; Mon, 3 Mar 2014 01:58:37 +0000 (UTC) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA04211E9 for ; Mon, 3 Mar 2014 01:58:37 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wn1so647589obc.11 for ; Sun, 02 Mar 2014 17:58:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EDtHli6N6Lo1Ty9nGoD7AeE2yle3OnhfEU1I6lbhDkk=; b=Fu/RUk1c/eY9dN0hY4dEVZgSv81ezi8tweHsYHP/zOQWq4O8xAprPswQ2VpolPPIFm jy5U4mfxGQEtfg4DLIBKBeItSVFhe/E9ITaVwN7jLWwm3Ssu6KKpgMCxFJo8hz5X/O45 tZjiH5EGV3JH9I+CG6gbG6kvuyASlfVsLwLTq0aKQWJuDx70t32+QTK+RABi1zpS8aH6 IsyolpxiPU+uhhs83kX2UEUu5kwLxt9j647gQMis8r8mccEJwMi818WM2xcxyjc77D31 OuDa1byBQqcsxKzlpHjnHYLjHGJ3ABxMegyTfVemXK2fuPLlokwDoVnB4SgjXed2SB7X Qj6w== X-Gm-Message-State: ALoCoQmIAbVqskf6Q3wE3szOKr6XpNFTi+LKAwhVPQzuXviltShiKdiJV45OcBjE6G1cToAcIxVT MIME-Version: 1.0 X-Received: by 10.60.62.243 with SMTP id b19mr14147301oes.42.1393811459129; Sun, 02 Mar 2014 17:50:59 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sun, 2 Mar 2014 17:50:59 -0800 (PST) In-Reply-To: <1393778472.1149.242.camel@revolution.hippie.lan> References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393731762.1149.233.camel@revolution.hippie.lan> <9BF14340-2267-473E-B047-E377AA258713@bsdimp.com> <1393778472.1149.242.camel@revolution.hippie.lan> Date: Sun, 2 Mar 2014 18:50:59 -0700 Message-ID: Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 01:58:38 -0000 I've got my wandboard quad booting now, with wandboard-quad.dtb in /boot/kernel/. I've submitted a patch to crochet-freebsd and the latest build is up at my FTP. Ian, your patch to ubldr appears to work perfectly. On Sun, Mar 2, 2014 at 9:41 AM, Ian Lepore wrote: > On Sun, 2014-03-02 at 09:30 -0700, Warner Losh wrote: > > On Mar 1, 2014, at 8:42 PM, Ian Lepore wrote: > > > > > On Sat, 2014-03-01 at 18:01 -0700, Tom Everett wrote: > > >> I'm looking at the crochet code, and I see in freebsd_install_fdt > that both > > >> *.dtb and *.dts are supported. However on the source tree it's > imx6.dtsi. > > >> What's the difference b/t a dts file and a dtsi file? > > > > > > A .dtsi file is an include file used by .dts files. A .dtb is the > > > binary (compiled) form used by the kernel. > > > > > > So there are several wandboard-something.dts files, each of which > > > includes imx6.dtsi where all the common parts live. For a new imx6 > > > device, a new board-named file similar to one of the wandboard files is > > > necessary, and it would also include imx6.dtsi. > > > > As would other boards that use the imx6 SoC. They'd have their own .dts > > file that included the imx6.dsti and customized it for how they are wired > > together. > > > > > We're pushing hard towards just using the standard dtb files from > > > vendors, but we've got a bit of work to do before we're there. > > > > I have some rough changes that allow us to build N different DTBs as part > > of the kernel build, but not glom them into the kernel. Not strictly > required > > for this, but helpful. > > > > I'm planning on having Atmel use 100% vendor supplied files as well. > > It is a very good goal. There's also efforts on the linux side to > separate out > > the device-trees from the linux kernel, which is where I grabbed the > recent > > /vendor/device-tree stuff from. > > > > Warner > > For imx6, the big obstacle to using vendor dtb files is now just the > device instantiation order. The stock dts files list devices basically > in order of their memory-mapped register addresses, but we need the > interrupt controller to be available first regardless of where it's > mapped, and likewise for a few other critical devices. > > I need to do another round of experimentation with the > EARLY_DRIVER_MODULE() stuff and multipass device instantiation. We may > not be all that far from success. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 02:13:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5D66868 for ; Mon, 3 Mar 2014 02:13:16 +0000 (UTC) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77CE11326 for ; Mon, 3 Mar 2014 02:13:15 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id p10so3061932pdj.26 for ; Sun, 02 Mar 2014 18:13:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZiWqgVy3xXSTJ+0JBbKn1MbySJquw1qD1TWFB/XVMqE=; b=MjtwV66vydeDwxhStyJCO753Y+qgfh86WvGo+HWWdnbD/aNwi4OaBvIl9s0IKNZxYX /yKJ3FMa4I6RL+LeaOCiYEHlzG8lWmMJ9fkjPpwr4LtpPfWcQFg7LeS2R5PM2rlFe41Y YGuZYZAc5uJGXB6RH00aXy69+0NWCjr0UlCDRNxKkCH33NA0ZCw4YVPc7bW4YbnOihSW hvrwYARka3JpyxycT79ZhtqFJfe5z9U8PbSg8dhu8KxW2ezSc4o387mJNby/Oy3125LU bMsmyMTjR0RqAJKkkdB8TV3K4p+Iu3GL43V2MvWr4p0ALrLp6mgY7mscwg4+7251pMBP 0GZQ== X-Gm-Message-State: ALoCoQmfHUBQzsMss8solpePKebuHqa2eN8uU88zSmul3y3e3qj8lVKwIWb0QHEwKCPUH3muY13o X-Received: by 10.66.160.225 with SMTP id xn1mr5378665pab.108.1393812789748; Sun, 02 Mar 2014 18:13:09 -0800 (PST) Received: from localhost.localdomain (z88l218.static.ctm.net. [202.175.88.218]) by mx.google.com with ESMTPSA id gj9sm30017646pbc.7.2014.03.02.18.13.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 18:13:08 -0800 (PST) Message-ID: <5313E532.2070608@linaro.org> Date: Mon, 03 Mar 2014 10:13:06 +0800 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: Device Tree mailing References: <1392222417.13563.93.camel@kazak.uk.xensource.com> In-Reply-To: <1392222417.13563.93.camel@kazak.uk.xensource.com> X-Forwarded-Message-Id: <1392222417.13563.93.camel@kazak.uk.xensource.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 02:13:16 -0000 Hello all, A device tree ML has been created to discuss about binding specification. As discussed on a previous thread [1], FreeBSD device tree binding doesn't always match bindings used by all the boards. It prevents FreeBSD to boot out-of-box (e.g. without a modified DT). It might be interested to have some people from BSD on this mailing list. Regards, [1] http://lists.freebsd.org/pipermail/freebsd-xen/2014-January/001974.html -------- Original Message -------- Subject: [Fwd: New mailing lists] Date: Wed, 12 Feb 2014 16:26:57 +0000 From: Ian Campbell Organisation: Citrix Systems, Inc. To: Julien Grall Can you forward this to whoever @ NetBSD you think might be interested? Cheers, Ian. -------- Forwarded Message -------- From: Grant Likely To: devicetree@vger.kernel.org Cc: Rob Herring , Mark Rutland , Kumar Gala , Paweł Moll , Ian Campbell , Yoder Stuart-B08248 , David Gibson Subject: New mailing lists Date: Tue, 11 Feb 2014 13:13:01 +0000 Hi all, As per the discussion two weeks ago[1], I've requested two new mailing lists; devicetree-spec@vger.kernel.org and devicetree-compiler@vger.kernel.org. The lists were created to help filter out the noise for specific device tree topics. The -compiler list is for discussion specifically related to dtc and other tools. The -spec list is for "core" binding discussions, so anything that affects entire subsystems or the kinds of things that would make sense to be added to ePAPR. Here are the subscribe links: http://vger.kernel.org/vger-lists.html#devicetree-compiler http://vger.kernel.org/vger-lists.html#devicetree-spec Archives for all devicetree lists can be found here: http://gmane.org/find.php?list=devicetree g. [1] http://www.spinics.net/lists/devicetree/msg19209.html From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 02:38:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30BA0A13 for ; Mon, 3 Mar 2014 02:38:11 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA3A114AB for ; Mon, 3 Mar 2014 02:38:10 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so414283iec.16 for ; Sun, 02 Mar 2014 18:38:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=2sMHPLd4EibfAk/WkktsSivFvzO+978wges/RFSKv48=; b=iOX6i1SGJh0Nm56G/rNRq/MyQ1+8lsYFRjsqN2ow1EtSGLw5XGzesLxYDY2e5tCHPL Nu/jSk4p47y64MBcF4laXPnCnF2KO0C64PAh5tQZ/sOZzsMm4oVBqB0sgUeWc4dqJqHb Govb7z4HYNGrZvhgY+Vnx1q2Ap1nPG2n8KdMwz5uon8cLnFUZT72LANWZLbfl6zKp1SW u9yeitr1mGIZ7t5y7Nfyb1DTNGP9TXefz+59SJNcmd01LechT2otFVGwDIkFNVdsNZTj APhaZTq2pEYzDhKV1E2vDxYPHHQsGynCJCUwDG8EyyDfOeYyf+SDUJazd3sK+yQ1k3Rx /BXA== X-Gm-Message-State: ALoCoQmVngDHO70XzHjiK80RBCal5OyO/duI6WMkMYKDlpN26vk0+lAWZcSRMSA8lApr4AtNhN7R X-Received: by 10.43.155.209 with SMTP id lj17mr95356icc.94.1393814289789; Sun, 02 Mar 2014 18:38:09 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id sc8sm34675367igb.0.2014.03.02.18.38.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 18:38:09 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Sun, 2 Mar 2014 19:38:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> References: To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 02:38:11 -0000 On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: > Hi, >=20 > The attached patch (fdt_probe_order_control.patch) allows control over = the > probe order of simplebus child devices by using a "probe-order" = property in > simplebus child nodes in the .dts file Where is the probe-order property defined? I can=92t seem to find it in = the bindings. Also, I don=92t think it is necessary. This is a software construct, so = doesn=92t really belong in the dts file. I=92d really like to avoid FreeBSD specific = hacks in the DTS files. > This was motivated by booting FreeBSD from the eMMC on a BeagleBone = Black, > which has a pluggable microSD card slot in addition to the eMMC. The = order > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes = the > pluggable slot to be probed/attached first, so the device name = assigned to > the eMMC soldered to the board changes depending on whether there is a = card > in the pluggable slot, which makes establishing appropriate /etc/fstab > contents less than convenient. Sounds like you=92d like to have some sort of name to instance mapping. The typical way this is solved is by naming the partitions so that = ordering doesn=92t matter. Even if you don=92t handle this at the filesystem = level, which is how others cope, you=92d want this to be more of a direct binding = rather than an ordering so that you get the effect you want (constant name) directly, = rather than as a side-effect of ordering. If you insist on that, then having a something more like = =93freesbd,unit-number=94 property would also accomplish this. But that would only wire the = controller unit number, and not the resulting mmcsdX device. > By using the "probe-order" property in > sys/boot/fdt/dts/beaglebone-black.dts (see attached > beaglebone_black_mmc_probe_order.patch), I am able to swap the order = in > which the mmc units are probed/attached for that board. This avoids > inappropriate hacking of the mmc definition order in am335x.dtsi, = which is > shared among multiple boards. >=20 > This is not a general solution to the problem of wanting stable device > names for hard-wired MMC devices when pluggable slots are present in = the > system. There could, for example, be a multi-slot MMC controller with = a > mixture of hard-wired and pluggable devices attached, and this would = not > address that case. However, it does address the needs of BeagleBone = Black, > and the mechanism may be of use for similar issues on other platforms. As it isn=92t a generic solution, I=92d be biased against adopting it. = What=92s wrong with using glabel to accomplish this (either with a label specific = property, or by using a ufs label and mounting /dev/ufs/foo). Warner > Both patches were generated against 10-STABLE, r262447. >=20 > -Patrick > = _______= ________________________________________ > 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 Mar 3 02:45:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F1EFC7A for ; Mon, 3 Mar 2014 02:45:26 +0000 (UTC) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 48094156E for ; Mon, 3 Mar 2014 02:45:25 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so5610591iec.33 for ; Sun, 02 Mar 2014 18:45:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=SoH6Mm6K0x+TlGbVzhlc39F5BewnWL5SjH39rDUJM6Y=; b=Z1k5HRDrbOgKK0g26CiUSRdKq4N7CxP+GCaqkFSMAcusyRyOQDs9cKbRROJg4C96le tflopFllARHxxbl2Ru+KrS8QenwVYuuXSDjzTXqjwUBmkEvl94fwzids0He3aoD7QLdv 3d7elug5PoT7ZVTcEbTlYyQx9MgqxH/30aISPQiUMpV8jcfTc2dY28Irvn3Gk3bEjbvl TItTPqhq+sjKjq5xwFixPOSLL1VP1Z/bcEQtv9xIqkPYB9xndpJlFTLi6K3ZwNFdQYFZ 7QeBNSeMQtpfUdpQSlI51Q/JEYeH7H7fyVJvUnw0Q4/rSRRza7FkoV2nhSKZHbEILF6h 0vQw== X-Gm-Message-State: ALoCoQkqRlR6yZlu9cJktS2ywW75SsygsSaOoIchNqVhrBXl9tp/w9SQDG7yhbjR/AbrWaNXYZv4 X-Received: by 10.42.129.9 with SMTP id o9mr23619346ics.38.1393814725154; Sun, 02 Mar 2014 18:45:25 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id dz8sm34695637igb.5.2014.03.02.18.45.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 18:45:24 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Device Tree mailing From: Warner Losh In-Reply-To: <5313E532.2070608@linaro.org> Date: Sun, 2 Mar 2014 19:45:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1392222417.13563.93.camel@kazak.uk.xensource.com> <5313E532.2070608@linaro.org> To: Julien Grall X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 02:45:26 -0000 On Mar 2, 2014, at 7:13 PM, Julien Grall = wrote: > Hello all, >=20 > A device tree ML has been created to discuss about binding = specification. Already subscribed a while ago :) > As discussed on a previous thread [1], FreeBSD device tree binding = doesn't always match bindings used by all the boards. It prevents = FreeBSD to boot out-of-box (e.g. without a modified DT). A situation we=E2=80=99d like to correct. I believe the issues from that = thread had been corrected (it was a simple bug), and generally we are striving to have = the standard DTB work correctly. While we may fall short in a couple of areas, those = are simple bugs that should be highlighted. > It might be interested to have some people from BSD on this mailing = list. Yes, the more the merrier. Warner > Regards, >=20 > [1] = http://lists.freebsd.org/pipermail/freebsd-xen/2014-January/001974.html >=20 >=20 > -------- Original Message -------- > Subject: [Fwd: New mailing lists] > Date: Wed, 12 Feb 2014 16:26:57 +0000 > From: Ian Campbell > Organisation: Citrix Systems, Inc. > To: Julien Grall >=20 > Can you forward this to whoever @ NetBSD you think might be = interested? Is NetBSD going to start using FDT now? > Cheers, > Ian. > -------- Forwarded Message -------- > From: Grant Likely > To: devicetree@vger.kernel.org > Cc: Rob Herring , Mark Rutland > , Kumar Gala , Pawe=C5=82 = Moll > , Ian Campbell , Yoder > Stuart-B08248 , David Gibson > > Subject: New mailing lists > Date: Tue, 11 Feb 2014 13:13:01 +0000 >=20 > Hi all, >=20 > As per the discussion two weeks ago[1], I've requested two new mailing > lists; devicetree-spec@vger.kernel.org and > devicetree-compiler@vger.kernel.org. The lists were created to help > filter out the noise for specific device tree topics. The -compiler > list is for discussion specifically related to dtc and other tools. > The -spec list is for "core" binding discussions, so anything that > affects entire subsystems or the kinds of things that would make sense > to be added to ePAPR. >=20 > Here are the subscribe links: > http://vger.kernel.org/vger-lists.html#devicetree-compiler > http://vger.kernel.org/vger-lists.html#devicetree-spec >=20 > Archives for all devicetree lists can be found here: > http://gmane.org/find.php?list=3Ddevicetree >=20 > g. >=20 > [1] http://www.spinics.net/lists/devicetree/msg19209.html >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 03:10:55 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 831DE20D; Mon, 3 Mar 2014 03:10:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3F2A5194D; Mon, 3 Mar 2014 03:10: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 s233ArP7055817; Sun, 2 Mar 2014 22:10:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s233ArHg055813; Mon, 3 Mar 2014 03:10:53 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 3 Mar 2014 03:10:53 GMT Message-Id: <201403030310.s233ArHg055813@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 03:10:55 -0000 TB --- 2014-03-03 01:30:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-03-03 01:30: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 --- 2014-03-03 01:30:17 - starting HEAD tinderbox run for arm/arm TB --- 2014-03-03 01:30:17 - cleaning the object tree TB --- 2014-03-03 01:31:50 - /usr/local/bin/svn stat /src TB --- 2014-03-03 01:31:53 - At svn revision 262700 TB --- 2014-03-03 01:31:54 - building world TB --- 2014-03-03 01:31:54 - CROSS_BUILD_TESTING=YES TB --- 2014-03-03 01:31:54 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-03 01:31:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-03 01:31:54 - SRCCONF=/dev/null TB --- 2014-03-03 01:31:54 - TARGET=arm TB --- 2014-03-03 01:31:54 - TARGET_ARCH=arm TB --- 2014-03-03 01:31:54 - TZ=UTC TB --- 2014-03-03 01:31:54 - __MAKE_CONF=/dev/null TB --- 2014-03-03 01:31:54 - cd /src TB --- 2014-03-03 01:31:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 3 01:32:01 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_cursor.c -o frm_cursor.o cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_data.c -o frm_data.o cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_def.c -o frm_def.o cc -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/obj/arm.arm/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncursesw -I/src/lib/ncurses/formw/../ncurses -I/src/lib/ncurses/formw/../../../contrib/ncurses/include -I/src/lib/ncurses/formw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/src/lib/ncurses/formw/../../../contrib/ncurses/form -I/src/lib/ncurses/formw/../../../contrib/ncurses/menu -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_driver.c -o frm_driver.o /src/lib/ncurses/formw/../../../contrib/ncurses/form/frm_driver.c:4506:9: error: comparison of integers of different signs: 'wchar_t' (aka 'unsigned int') and 'int' [-Werror,-Wsign-compare] if (c == FIRST_ACTIVE_MAGIC) ~ ^ ~~~~~~~~~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. bmake[5]: stopped in /src/lib/ncurses/formw *** Error code 1 Stop. bmake[4]: stopped in /src/lib/ncurses *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-03-03 03:10:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-03 03:10:53 - ERROR: failed to build world TB --- 2014-03-03 03:10:53 - 4874.62 user 864.31 system 6036.01 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 03:52:49 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 329C5CE3 for ; Mon, 3 Mar 2014 03:52:49 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0441B23B for ; Mon, 3 Mar 2014 03:52:48 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WKJvm-000M1e-1j; Mon, 03 Mar 2014 03:52:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s233qbW9046122; Sun, 2 Mar 2014 20:52:38 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18h7KLnWwHEh1ymOM9JtQbK Subject: Re: status of AVILA and CAMBRIA code From: Ian Lepore To: John Hay In-Reply-To: <20140301104431.GA82389@zibbi.meraka.csir.co.za> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com> <20140221130530.GA202@zibbi.meraka.csir.co.za> <1393001249.1145.98.camel@revolution.hippie.lan> <20140224132614.GA31984@zibbi.meraka.csir.co.za> <20140301104431.GA82389@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Mar 2014 20:52:37 -0700 Message-ID: <1393818757.1149.267.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 03:52:49 -0000 On Sat, 2014-03-01 at 12:44 +0200, John Hay wrote: > On Mon, Feb 24, 2014 at 03:26:14PM +0200, John Hay wrote: > > Hi Ian, > > > > On Fri, Feb 21, 2014 at 09:47:29AM -0700, Ian Lepore wrote: > > > On Fri, 2014-02-21 at 15:05 +0200, John Hay wrote: > > > > On Wed, Feb 19, 2014 at 09:29:38AM -0800, John-Mark Gurney wrote: > > > > > John Hay wrote this message on Wed, Feb 19, 2014 at 12:59 +0200: > > > > > > What is the status of AVILA and CAMBRIA builds in our tree? Have anybody > > > > > > had success recently? From the lists I can see that other people have > > > > > > also asked in September 2013, but I cannot figure out if there was any > > > > > > successes at that stage. :-) > > > > ... > > > > > > > > > > > > Somewhere along the line the ethernet npe0 device also broke, writing > > > > > > "npe0: npestart_locked: too many fragments 0". But I did not test the > > > > > > npe0 device with every build and only realised it this morning, so I > > > > > > do not know where it broke. :-) > > It looks like adding a few bus_dmamap_unload()s in if_npe.c fixed it. Here is > my patch that seems to fix it. Does it look ok? Can I commit it? > > Index: xscale/ixp425/if_npe.c > =================================================================== > --- xscale/ixp425/if_npe.c (revision 246713) > +++ xscale/ixp425/if_npe.c (working copy) > @@ -1037,6 +1037,8 @@ > > sc = npes[NPE_QM_Q_NPE(entry)]; > npe = P2V(NPE_QM_Q_ADDR(entry), &sc->txdma); > + bus_dmamap_sync(sc->txdma.mtag, npe->ix_map, BUS_DMASYNC_POSTWRITE); > + bus_dmamap_unload(sc->txdma.mtag, npe->ix_map); > m_freem(npe->ix_m); > npe->ix_m = NULL; > > @@ -1112,6 +1114,12 @@ > > DPRINTF(sc, "%s: entry 0x%x neaddr 0x%x ne_len 0x%x\n", > __func__, entry, npe->ix_neaddr, npe->ix_hw->ix_ne[0].len); > + > + /* Flush mbuf memory for rx'd data */ > + bus_dmamap_sync(dma->mtag, npe->ix_map, > + BUS_DMASYNC_POSTREAD); > + bus_dmamap_unload(dma->mtag, npe->ix_map); > + > /* > * Allocate a new mbuf to replenish the rx buffer. > * If doing so fails we drop the rx'd frame so we > @@ -1126,10 +1134,6 @@ > struct npehwbuf *hw = npe->ix_hw; > struct ifnet *ifp = sc->sc_ifp; > > - /* Flush mbuf memory for rx'd data */ > - bus_dmamap_sync(dma->mtag, npe->ix_map, > - BUS_DMASYNC_POSTREAD); > - > /* XXX flush hw buffer; works now 'cuz coherent */ > /* set m_len etc. per rx frame size */ > mrx->m_len = be32toh(hw->ix_ne[0].len) & 0xffff; > > John I think this is more correct, but one more thing is needed... it looks like design here was to load a map then not unload it until the next time you're about to load it. I think that's a bad idea and your changes are the better way, but there are still a few unload calls scattered around that now need to be deleted because they would be unloading a map that was already unloaded when the IO completed. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 03:56:18 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3014EDDA for ; Mon, 3 Mar 2014 03:56:18 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 049DA255 for ; Mon, 3 Mar 2014 03:56:17 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WKJzE-000NYz-Th; Mon, 03 Mar 2014 03:56:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s233uEXd046129; Sun, 2 Mar 2014 20:56:14 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/J06I05UAk0DfD8u/Dg+ni Subject: Re: TMPFS in kernels From: Ian Lepore To: George Rosamond In-Reply-To: <5313D0FE.8010008@ceetonetechnology.com> References: <5313D0FE.8010008@ceetonetechnology.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Mar 2014 20:56:14 -0700 Message-ID: <1393818974.1149.270.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 03:56:18 -0000 On Sun, 2014-03-02 at 19:46 -0500, George Rosamond wrote: > Is there a reason why TMPFS(5) is not in the 10-Stable's ALIX and RPI-B > kernels, yet in BEAGLEBONE? Haven't checked the others. > > Seems like a strong and mature replacement for md(4) from my > experiences, and probably belongs in the Crochet fstabs. I have been > using on Alix, RPis, x86 for a long while, and never had any > (noticeable) issues. > > g I agree. Should we add it to all configs, or just to armv6 configs? -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 04:05:12 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E84CE8C for ; Mon, 3 Mar 2014 04:05:12 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7129E2E6 for ; Mon, 3 Mar 2014 04:05:12 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WKK7r-0001Fi-CF; Mon, 03 Mar 2014 04:05:11 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s23458lD046138; Sun, 2 Mar 2014 21:05:08 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/oEQak62qw4ACXqmF8A5/n Subject: Re: Raspberry Pi Clock Frequency From: Ian Lepore To: Jordan Starcher In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Mar 2014 21:05:08 -0700 Message-ID: <1393819508.1149.274.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 04:05:12 -0000 On Thu, 2014-01-23 at 23:31 -0500, Jordan Starcher wrote: > Hi, > > I was wondering if it is possible to adjust the CPU frequency on the > Raspberry Pi under FreeBSD 10.0-RELEASE? I've been trying to find what the > clock is currently set at using sysctl but I cannot seem to find any values > that show the frequency. I also checked the FreeBSD kernel source and did > not see any related tunable aside from hw.bcm2835.min_freq. Is this the > tunable I would use? > > Thanks, > Jordan I just realized this never got answered, sorry about that. That tunable you mention was a workaround for rpi sdcard problems, and it never actually helped anyway and should probably be removed. If there's a way to change the cpu frequency, it's not in the scanty little doc I've got about that processor. If it can be done, the how-to can probably be found in the linux source, but I don't have time to work on it. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 04:06:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB35DECD; Mon, 3 Mar 2014 04:06:41 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 11D3D2EB; Mon, 3 Mar 2014 04:06:41 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 1AA3AB817; Mon, 3 Mar 2014 06:06:32 +0200 (SAST) Date: Mon, 3 Mar 2014 06:06:32 +0200 From: John Hay To: Ian Lepore Subject: Re: status of AVILA and CAMBRIA code Message-ID: <20140303040631.GA85204@zibbi.meraka.csir.co.za> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com> <20140221130530.GA202@zibbi.meraka.csir.co.za> <1393001249.1145.98.camel@revolution.hippie.lan> <20140224132614.GA31984@zibbi.meraka.csir.co.za> <20140301104431.GA82389@zibbi.meraka.csir.co.za> <1393818757.1149.267.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393818757.1149.267.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 04:06:42 -0000 On Sun, Mar 02, 2014 at 08:52:37PM -0700, Ian Lepore wrote: > On Sat, 2014-03-01 at 12:44 +0200, John Hay wrote: > > On Mon, Feb 24, 2014 at 03:26:14PM +0200, John Hay wrote: > > > Hi Ian, > > > > > > On Fri, Feb 21, 2014 at 09:47:29AM -0700, Ian Lepore wrote: > > > > On Fri, 2014-02-21 at 15:05 +0200, John Hay wrote: > > > > > On Wed, Feb 19, 2014 at 09:29:38AM -0800, John-Mark Gurney wrote: > > > > > > John Hay wrote this message on Wed, Feb 19, 2014 at 12:59 +0200: > > > > > > > What is the status of AVILA and CAMBRIA builds in our tree? Have anybody > > > > > > > had success recently? From the lists I can see that other people have > > > > > > > also asked in September 2013, but I cannot figure out if there was any > > > > > > > successes at that stage. :-) > > > > > ... > > > > > > > > > > > > > > Somewhere along the line the ethernet npe0 device also broke, writing > > > > > > > "npe0: npestart_locked: too many fragments 0". But I did not test the > > > > > > > npe0 device with every build and only realised it this morning, so I > > > > > > > do not know where it broke. :-) > > > > It looks like adding a few bus_dmamap_unload()s in if_npe.c fixed it. Here is > > my patch that seems to fix it. Does it look ok? Can I commit it? > > > > Index: xscale/ixp425/if_npe.c > > =================================================================== > > --- xscale/ixp425/if_npe.c (revision 246713) > > +++ xscale/ixp425/if_npe.c (working copy) > > @@ -1037,6 +1037,8 @@ > > > > sc = npes[NPE_QM_Q_NPE(entry)]; > > npe = P2V(NPE_QM_Q_ADDR(entry), &sc->txdma); > > + bus_dmamap_sync(sc->txdma.mtag, npe->ix_map, BUS_DMASYNC_POSTWRITE); > > + bus_dmamap_unload(sc->txdma.mtag, npe->ix_map); > > m_freem(npe->ix_m); > > npe->ix_m = NULL; > > > > @@ -1112,6 +1114,12 @@ > > > > DPRINTF(sc, "%s: entry 0x%x neaddr 0x%x ne_len 0x%x\n", > > __func__, entry, npe->ix_neaddr, npe->ix_hw->ix_ne[0].len); > > + > > + /* Flush mbuf memory for rx'd data */ > > + bus_dmamap_sync(dma->mtag, npe->ix_map, > > + BUS_DMASYNC_POSTREAD); > > + bus_dmamap_unload(dma->mtag, npe->ix_map); > > + > > /* > > * Allocate a new mbuf to replenish the rx buffer. > > * If doing so fails we drop the rx'd frame so we > > @@ -1126,10 +1134,6 @@ > > struct npehwbuf *hw = npe->ix_hw; > > struct ifnet *ifp = sc->sc_ifp; > > > > - /* Flush mbuf memory for rx'd data */ > > - bus_dmamap_sync(dma->mtag, npe->ix_map, > > - BUS_DMASYNC_POSTREAD); > > - > > /* XXX flush hw buffer; works now 'cuz coherent */ > > /* set m_len etc. per rx frame size */ > > mrx->m_len = be32toh(hw->ix_ne[0].len) & 0xffff; > > > > John > > I think this is more correct, but one more thing is needed... it looks > like design here was to load a map then not unload it until the next > time you're about to load it. I think that's a bad idea and your > changes are the better way, but there are still a few unload calls > scattered around that now need to be deleted because they would be > unloading a map that was already unloaded when the IO completed. Thanks, I'll look into the other unloads. I get the feeling that the design was actually to only unload if the interface is stopped which worked fine until map->sync_count was introduced in arm/busdma_machdep.c? Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 04:13:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17FA6D9 for ; Mon, 3 Mar 2014 04:13:45 +0000 (UTC) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D2ECE37E for ; Mon, 3 Mar 2014 04:13:44 +0000 (UTC) Received: from 127.0.0.1 (fiber19415337171.heldenvannu.net [37.153.194.171] (may be forged)) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id s234DZNd025311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 2 Mar 2014 23:13:41 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <5314016B.1000107@ceetonetechnology.com> Date: Sun, 02 Mar 2014 23:13:31 -0500 From: George Rosamond MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: TMPFS in kernels References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> In-Reply-To: <1393818974.1149.270.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 04:13:45 -0000 Ian Lepore: > On Sun, 2014-03-02 at 19:46 -0500, George Rosamond wrote: >> Is there a reason why TMPFS(5) is not in the 10-Stable's ALIX and RPI-B >> kernels, yet in BEAGLEBONE? Haven't checked the others. >> >> Seems like a strong and mature replacement for md(4) from my >> experiences, and probably belongs in the Crochet fstabs. I have been >> using on Alix, RPis, x86 for a long while, and never had any >> (noticeable) issues. >> >> g > > I agree. Should we add it to all configs, or just to armv6 configs? > I'd assume we should have it all the kernels.. especially since most of them are running off flash-type media, which makes memory-based disks pretty vital. g From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 04:28:32 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66EDE301 for ; Mon, 3 Mar 2014 04:28:32 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 256CA636 for ; Mon, 3 Mar 2014 04:28:31 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WKKUL-000ESh-1Q; Mon, 03 Mar 2014 04:28:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s234SLAv046157; Sun, 2 Mar 2014 21:28:21 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/ghYg5tQ01kd4ffrGhFezH Subject: Re: status of AVILA and CAMBRIA code From: Ian Lepore To: John Hay In-Reply-To: <20140303040631.GA85204@zibbi.meraka.csir.co.za> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com> <20140221130530.GA202@zibbi.meraka.csir.co.za> <1393001249.1145.98.camel@revolution.hippie.lan> <20140224132614.GA31984@zibbi.meraka.csir.co.za> <20140301104431.GA82389@zibbi.meraka.csir.co.za> <1393818757.1149.267.camel@revolution.hippie.lan> <20140303040631.GA85204@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Mar 2014 21:28:21 -0700 Message-ID: <1393820901.1149.276.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 04:28:32 -0000 On Mon, 2014-03-03 at 06:06 +0200, John Hay wrote: > On Sun, Mar 02, 2014 at 08:52:37PM -0700, Ian Lepore wrote: > > On Sat, 2014-03-01 at 12:44 +0200, John Hay wrote: > > > On Mon, Feb 24, 2014 at 03:26:14PM +0200, John Hay wrote: > > > > Hi Ian, > > > > > > > > On Fri, Feb 21, 2014 at 09:47:29AM -0700, Ian Lepore wrote: > > > > > On Fri, 2014-02-21 at 15:05 +0200, John Hay wrote: > > > > > > On Wed, Feb 19, 2014 at 09:29:38AM -0800, John-Mark Gurney wrote: > > > > > > > John Hay wrote this message on Wed, Feb 19, 2014 at 12:59 +0200: > > > > > > > > What is the status of AVILA and CAMBRIA builds in our tree? Have anybody > > > > > > > > had success recently? From the lists I can see that other people have > > > > > > > > also asked in September 2013, but I cannot figure out if there was any > > > > > > > > successes at that stage. :-) > > > > > > ... > > > > > > > > > > > > > > > > Somewhere along the line the ethernet npe0 device also broke, writing > > > > > > > > "npe0: npestart_locked: too many fragments 0". But I did not test the > > > > > > > > npe0 device with every build and only realised it this morning, so I > > > > > > > > do not know where it broke. :-) > > > > > > It looks like adding a few bus_dmamap_unload()s in if_npe.c fixed it. Here is > > > my patch that seems to fix it. Does it look ok? Can I commit it? > > > > > > Index: xscale/ixp425/if_npe.c > > > =================================================================== > > > --- xscale/ixp425/if_npe.c (revision 246713) > > > +++ xscale/ixp425/if_npe.c (working copy) > > > @@ -1037,6 +1037,8 @@ > > > > > > sc = npes[NPE_QM_Q_NPE(entry)]; > > > npe = P2V(NPE_QM_Q_ADDR(entry), &sc->txdma); > > > + bus_dmamap_sync(sc->txdma.mtag, npe->ix_map, BUS_DMASYNC_POSTWRITE); > > > + bus_dmamap_unload(sc->txdma.mtag, npe->ix_map); > > > m_freem(npe->ix_m); > > > npe->ix_m = NULL; > > > > > > @@ -1112,6 +1114,12 @@ > > > > > > DPRINTF(sc, "%s: entry 0x%x neaddr 0x%x ne_len 0x%x\n", > > > __func__, entry, npe->ix_neaddr, npe->ix_hw->ix_ne[0].len); > > > + > > > + /* Flush mbuf memory for rx'd data */ > > > + bus_dmamap_sync(dma->mtag, npe->ix_map, > > > + BUS_DMASYNC_POSTREAD); > > > + bus_dmamap_unload(dma->mtag, npe->ix_map); > > > + > > > /* > > > * Allocate a new mbuf to replenish the rx buffer. > > > * If doing so fails we drop the rx'd frame so we > > > @@ -1126,10 +1134,6 @@ > > > struct npehwbuf *hw = npe->ix_hw; > > > struct ifnet *ifp = sc->sc_ifp; > > > > > > - /* Flush mbuf memory for rx'd data */ > > > - bus_dmamap_sync(dma->mtag, npe->ix_map, > > > - BUS_DMASYNC_POSTREAD); > > > - > > > /* XXX flush hw buffer; works now 'cuz coherent */ > > > /* set m_len etc. per rx frame size */ > > > mrx->m_len = be32toh(hw->ix_ne[0].len) & 0xffff; > > > > > > John > > > > I think this is more correct, but one more thing is needed... it looks > > like design here was to load a map then not unload it until the next > > time you're about to load it. I think that's a bad idea and your > > changes are the better way, but there are still a few unload calls > > scattered around that now need to be deleted because they would be > > unloading a map that was already unloaded when the IO completed. > > Thanks, I'll look into the other unloads. I get the feeling that the > design was actually to only unload if the interface is stopped which > worked fine until map->sync_count was introduced in arm/busdma_machdep.c? > > Regards > > John In both the places where bus_dmamap_load_mbuf_sg() is called, an unload is done right before the load. It's almost like an attempt to hoard resources lest something else grab them while the driver is idle. :) -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 04:39:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1459D480 for ; Mon, 3 Mar 2014 04:39:08 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB3976D4 for ; Mon, 3 Mar 2014 04:39:07 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id fb1so1737484pad.1 for ; Sun, 02 Mar 2014 20:39:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ztSZjoa/c3/h6Pml0YyS326dUEkbSbE6DRxt+xR3dtc=; b=JcU53g026oOCQL5QQhxcZNRNNFXFNH4jjQFaFERlim9FN/5o+GHdhuYo7haObAD0dl G6EtQPDfdBVGAK2h0oAnzKYJC8/KRC+ZXiU4i6FKa8t9DvfyFU9WKfSqduSO6zDw9utp s2ozNCXiyUTST2EpZu4BcYWww17cc7HD73oeKAgZTHQEve+3wiBTgHQyZEINjOb1QqAb S8UuVRouCdmuN9RUX7pIRyJfNughBFlAZ9pnpa1NMP4i/zDVtPrrLoSl6YZc0+KKN7hu cUjWc+XHyyy8v13iWq11Cp8xgYm0YLl7+QzF4SJwLxK4Ud6ibyAx7gbfgont75NTTxkj vjLQ== X-Gm-Message-State: ALoCoQk25kUMYNl3WYmuX2fI/x/JHEqJMR985/7mWUjdRpm9jvQGKPC3QzjiC6qhSW2NhilpqzgE X-Received: by 10.68.7.66 with SMTP id h2mr17127470pba.91.1393821541000; Sun, 02 Mar 2014 20:39:01 -0800 (PST) Received: from [10.133.170.126] (z88l218.static.ctm.net. [202.175.88.218]) by mx.google.com with ESMTPSA id qq5sm30976305pbb.24.2014.03.02.20.38.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 20:39:00 -0800 (PST) Message-ID: <53140762.1080603@linaro.org> Date: Mon, 03 Mar 2014 12:38:58 +0800 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: Device Tree mailing References: <1392222417.13563.93.camel@kazak.uk.xensource.com> <5313E532.2070608@linaro.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 04:39:08 -0000 On 03/03/14 10:45, Warner Losh wrote: > > On Mar 2, 2014, at 7:13 PM, Julien Grall wrote: > >> Hello all, >> >> A device tree ML has been created to discuss about binding specification. > > Already subscribed a while ago :) > >> As discussed on a previous thread [1], FreeBSD device tree binding doesn't always match bindings used by all the boards. It prevents FreeBSD to boot out-of-box (e.g. without a modified DT). > > A situation we’d like to correct. I believe the issues from that thread had been > corrected (it was a simple bug), and generally we are striving to have the standard > DTB work correctly. While we may fall short in a couple of areas, those are > simple bugs that should be highlighted. I haven't check the FreeBSD for a month now. I saw that Nathan has reworked FDT code since this thread, thanks to him. The bug where FreeBSD were not able to deal with #interrupt-cells > 2 seems to be fixed (I haven't had time to verify it). I think the issue on device enumeration from the DT is still there. I will have to give a try to be sure. >> It might be interested to have some people from BSD on this mailing list. > > Yes, the more the merrier. > > Warner > >> Regards, >> >> [1] http://lists.freebsd.org/pipermail/freebsd-xen/2014-January/001974.html >> >> >> -------- Original Message -------- >> Subject: [Fwd: New mailing lists] >> Date: Wed, 12 Feb 2014 16:26:57 +0000 >> From: Ian Campbell >> Organisation: Citrix Systems, Inc. >> To: Julien Grall >> >> Can you forward this to whoever @ NetBSD you think might be interested? > > Is NetBSD going to start using FDT now? Good question, I think Ian meant FreeBSD here. ;) -- Julien Grall From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 04:54:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D1D35F5 for ; Mon, 3 Mar 2014 04:54:09 +0000 (UTC) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E823583E for ; Mon, 3 Mar 2014 04:54:08 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id ur14so1145688igb.4 for ; Sun, 02 Mar 2014 20:54:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=n12ymBnm5SyZ9vPfvH/OIvCnKALXTinZ1QUTXrOjuRA=; b=VRrmQGdWfd8oY1WIuPDkoKd1kn2A0hcoytETYXaYppPYTCiWIRbo80RMjMZ5FtUp6F dkDtFuvCzpKzFGMO5C5FN03DjxvcA+KaBfSGnuYgcuORdb4OQ53m5wRD7NPh7IBSfZc1 Y8jLACjeqE1hXwOixSW8ZBCpB89Zp1HGM3m+oYgxeUkqYbqBFEB9YO1Osp0blL2NAcN/ N3qEtpzN9LihsUFJHU48BI90IJI/nXqsUZb094WMjaolJWE0zX2OrbwilU8/Q5WiGRUZ MB9czG6Y+sqBUgfUdhX4j90PVfyshZVsdA5RTEV+gLMTJtkvC8WdT4i+p+Vjwwe4sCfp KqbQ== X-Gm-Message-State: ALoCoQn5VRBdjY29Boi3iEV4lt/rBqaZEK7BKLvyphfYfJDD1Av7dlHSDZpnya7d1JiG80eDsCYq X-Received: by 10.42.40.83 with SMTP id k19mr24209970ice.3.1393822442203; Sun, 02 Mar 2014 20:54:02 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id pn6sm35677460igb.4.2014.03.02.20.54.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 20:54:01 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Device Tree mailing From: Warner Losh In-Reply-To: <53140762.1080603@linaro.org> Date: Sun, 2 Mar 2014 21:54:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1392222417.13563.93.camel@kazak.uk.xensource.com> <5313E532.2070608@linaro.org> <53140762.1080603@linaro.org> To: Julien Grall X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 04:54:09 -0000 On Mar 2, 2014, at 9:38 PM, Julien Grall = wrote: >=20 >=20 > On 03/03/14 10:45, Warner Losh wrote: >>=20 >> On Mar 2, 2014, at 7:13 PM, Julien Grall = wrote: >>=20 >>> Hello all, >>>=20 >>> A device tree ML has been created to discuss about binding = specification. >>=20 >> Already subscribed a while ago :) >>=20 >>> As discussed on a previous thread [1], FreeBSD device tree binding = doesn't always match bindings used by all the boards. It prevents = FreeBSD to boot out-of-box (e.g. without a modified DT). >>=20 >> A situation we=92d like to correct. I believe the issues from that = thread had been >> corrected (it was a simple bug), and generally we are striving to = have the standard >> DTB work correctly. While we may fall short in a couple of areas, = those are >> simple bugs that should be highlighted. >=20 > I haven't check the FreeBSD for a month now. I saw that Nathan has = reworked FDT code since this thread, thanks to him. >=20 > The bug where FreeBSD were not able to deal with #interrupt-cells > 2 = seems to be fixed (I haven't had time to verify it). Cool! If there=92s a problem, please let us know=85 Atmel (my main focus = these days for somewhat crazy reasons) uses interrupt-cell =3D=3D 3, but I haven=92t tested it to know that it works, just that it doesn=92t = crash right away... > I think the issue on device enumeration from the DT is still there. I = will have to give a try to be sure. Yea, there still might be ordering issues there. We=92re working on a = possible solution to that which works for Atmel and should work for = others. Warner >>> It might be interested to have some people from BSD on this mailing = list. >>=20 >> Yes, the more the merrier. >>=20 >> Warner >>=20 >>> Regards, >>>=20 >>> [1] = http://lists.freebsd.org/pipermail/freebsd-xen/2014-January/001974.html >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: [Fwd: New mailing lists] >>> Date: Wed, 12 Feb 2014 16:26:57 +0000 >>> From: Ian Campbell >>> Organisation: Citrix Systems, Inc. >>> To: Julien Grall >>>=20 >>> Can you forward this to whoever @ NetBSD you think might be = interested? >>=20 >> Is NetBSD going to start using FDT now? >=20 > Good question, I think Ian meant FreeBSD here. ;) >=20 > --=20 > Julien Grall From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 05:53:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE2049FE; Mon, 3 Mar 2014 05:53:05 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89447BD4; Mon, 3 Mar 2014 05:53:05 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id w8so1652099qac.12 for ; Sun, 02 Mar 2014 21:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=APOa/ItWds8IsZHtg6RAwx8vuGJuaf1NPDkW6uHT/Yk=; b=yckF3YlikKJ1MLHn5++IpZRx2uvZ4bj8P7GAnu1XOgoTyC/CAVkOrKgc3BD7TwXHJW /8uJd7+ot4T2Kh+eKfNcB4gPQY4eM35k9pCsUX0Xp5c8KKxaly8OeK1DkrmvdsHPJASl a7vndNgKZKP6PhSebmmEzkJZcBvPrbMFxixoFW32iqGQfeh4l33xA92O1DY3w+ItWO2n IiEtJy8FT9xMiDiSpW3Fgrpp9QcmatnmI4uCtaUTdkOhFA28UflQGlEaqH8EPtk+eNvJ uQ4PePL/FB3RRpk0b5OY9iC7gAV5AmK5Z4SssXd8qJCXOl7CCazJqiJWhQtaKWDyNaMA TTRQ== MIME-Version: 1.0 X-Received: by 10.224.166.210 with SMTP id n18mr18986699qay.6.1393825984716; Sun, 02 Mar 2014 21:53:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Sun, 2 Mar 2014 21:53:04 -0800 (PST) In-Reply-To: <1393819508.1149.274.camel@revolution.hippie.lan> References: <1393819508.1149.274.camel@revolution.hippie.lan> Date: Sun, 2 Mar 2014 21:53:04 -0800 X-Google-Sender-Auth: XFZfmXquUCu6n4Y3y9b4tmeoKV8 Message-ID: Subject: Re: Raspberry Pi Clock Frequency From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: Jordan Starcher , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 05:53:05 -0000 I believe it's something that is done in the bootloader config, not by Linux itself. Phew. -a On 2 March 2014 20:05, Ian Lepore wrote: > On Thu, 2014-01-23 at 23:31 -0500, Jordan Starcher wrote: >> Hi, >> >> I was wondering if it is possible to adjust the CPU frequency on the >> Raspberry Pi under FreeBSD 10.0-RELEASE? I've been trying to find what the >> clock is currently set at using sysctl but I cannot seem to find any values >> that show the frequency. I also checked the FreeBSD kernel source and did >> not see any related tunable aside from hw.bcm2835.min_freq. Is this the >> tunable I would use? >> >> Thanks, >> Jordan > > I just realized this never got answered, sorry about that. > > That tunable you mention was a workaround for rpi sdcard problems, and > it never actually helped anyway and should probably be removed. > > If there's a way to change the cpu frequency, it's not in the scanty > little doc I've got about that processor. If it can be done, the how-to > can probably be found in the linux source, but I don't have time to work > on it. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 06:10:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38BF2BD7; Mon, 3 Mar 2014 06:10:29 +0000 (UTC) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4FEC97; Mon, 3 Mar 2014 06:10:28 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 264B2B827; Sun, 2 Mar 2014 22:10:22 -0800 (PST) To: Adrian Chadd Subject: Re: Raspberry Pi Clock Frequency In-reply-to: Your message of "Sun, 02 Mar 2014 21:53:04 PST." References: <1393819508.1149.274.camel@revolution.hippie.lan> Comments: In-reply-to Adrian Chadd message dated "Sun, 02 Mar 2014 21:53:04 -0800." Date: Sun, 02 Mar 2014 22:10:22 -0800 From: Bakul Shah Message-Id: <20140303061022.264B2B827@mail.bitblocks.com> Cc: Jordan Starcher , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 06:10:29 -0000 On Sun, 02 Mar 2014 21:53:04 PST Adrian Chadd wrote: > I believe it's something that is done in the bootloader config, not by > Linux itself. You can set freq in config.txt as arm_freq= > On 2 March 2014 20:05, Ian Lepore wrote: > > > > If there's a way to change the cpu frequency, it's not in the scanty > > little doc I've got about that processor. If it can be done, the how-to > > can probably be found in the linux source, but I don't have time to work > > on it. See https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 06:11:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CEFFC1D for ; Mon, 3 Mar 2014 06:11:47 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id D65F2D08 for ; Mon, 3 Mar 2014 06:11:46 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 39688B833; Mon, 3 Mar 2014 08:11:36 +0200 (SAST) Date: Mon, 3 Mar 2014 08:11:36 +0200 From: John Hay To: George Rosamond Subject: Re: TMPFS in kernels Message-ID: <20140303061136.GB85204@zibbi.meraka.csir.co.za> References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5314016B.1000107@ceetonetechnology.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 06:11:47 -0000 On Sun, Mar 02, 2014 at 11:13:31PM -0500, George Rosamond wrote: > Ian Lepore: > > On Sun, 2014-03-02 at 19:46 -0500, George Rosamond wrote: > >> Is there a reason why TMPFS(5) is not in the 10-Stable's ALIX and RPI-B > >> kernels, yet in BEAGLEBONE? Haven't checked the others. > >> > >> Seems like a strong and mature replacement for md(4) from my > >> experiences, and probably belongs in the Crochet fstabs. I have been > >> using on Alix, RPis, x86 for a long while, and never had any > >> (noticeable) issues. > >> > >> g > > > > I agree. Should we add it to all configs, or just to armv6 configs? > > > > I'd assume we should have it all the kernels.. especially since most of > them are running off flash-type media, which makes memory-based disks > pretty vital. Our embedded systems also use compact flash disks mounted ro. We have been (ab)using the nice etc/rc.initdiskless and etc/rc.d/var scripts by just having an etc/diskless and populated conf/base and conf/defaults directories. But it seems those scripts just work with md devices. John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 06:15:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7530C89 for ; Mon, 3 Mar 2014 06:15:29 +0000 (UTC) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FEB2D2A for ; Mon, 3 Mar 2014 06:15:29 +0000 (UTC) Received: by mail-ig0-f170.google.com with SMTP id uq10so1260027igb.1 for ; Sun, 02 Mar 2014 22:15:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Qhlr/7a4OKIUY8OFACJpUTg+YNYuJLrFX/sI0gZ29fg=; b=DLtiw6MiggBpUfIUAt4xj/BpDgbfWMAkoymbYL2IakksdRai5gh0XkPsVj5CiJKUxo l8uAP6G6ArR7HDT7iYvGM4u2FYvjI3HeBOlii4tb8F9nKf9C+r1wd7qh9Tupq2VMmhhg jr2lUxX2OQXmHQo4rCFVSGJ5HPLXmPk8PLb9tFfuScoRDVERYzRtCXhNZ7lo6EZODeB0 zpQzP2jxOuiofXVvFYkgJLSsIsJpgZ0XhvYB29k5lELsvTi4qMmqvmKbPmDVWSXlA54U IbFI+CPpDbIxRvuyEN+6PW+e/xVd3hezWLsv5dbEZXVp88gfjbQSdURw0YkWbUN8GNxs fYGg== X-Gm-Message-State: ALoCoQm7Ypq5EKBtWb3Ykp7Ue0/f1FcKYLbTt3lDVF+chB20EGKM0jrTarn3j2n9kBKC11mfjpMo X-Received: by 10.42.232.206 with SMTP id jv14mr24111704icb.52.1393827323444; Sun, 02 Mar 2014 22:15:23 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ai4sm36236783igd.3.2014.03.02.22.15.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 22:15:23 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: TMPFS in kernels From: Warner Losh In-Reply-To: <20140303061136.GB85204@zibbi.meraka.csir.co.za> Date: Sun, 2 Mar 2014 23:15:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <595B99F0-264D-41D3-9151-FFCFD0261AFD@bsdimp.com> References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> To: John Hay X-Mailer: Apple Mail (2.1874) Cc: George Rosamond , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 06:15:29 -0000 On Mar 2, 2014, at 11:11 PM, John Hay wrote: > On Sun, Mar 02, 2014 at 11:13:31PM -0500, George Rosamond wrote: >> Ian Lepore: >>> On Sun, 2014-03-02 at 19:46 -0500, George Rosamond wrote: >>>> Is there a reason why TMPFS(5) is not in the 10-Stable's ALIX and = RPI-B >>>> kernels, yet in BEAGLEBONE? Haven't checked the others. >>>>=20 >>>> Seems like a strong and mature replacement for md(4) from my >>>> experiences, and probably belongs in the Crochet fstabs. I have = been >>>> using on Alix, RPis, x86 for a long while, and never had any >>>> (noticeable) issues. >>>>=20 >>>> g >>>=20 >>> I agree. Should we add it to all configs, or just to armv6 configs? >>>=20 >>=20 >> I'd assume we should have it all the kernels.. especially since most = of >> them are running off flash-type media, which makes memory-based disks >> pretty vital. >=20 > Our embedded systems also use compact flash disks mounted ro. We have > been (ab)using the nice etc/rc.initdiskless and etc/rc.d/var scripts > by just having an etc/diskless and populated conf/base and = conf/defaults > directories. But it seems those scripts just work with md devices. NANOBSD works that way too=85 tmpfs is a bit nicer since it doesn=92t = hard-wire the allocation, but that can suffer a bit from the vagaries of system demand=85. Warner From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 06:29:49 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B9D5D54; Mon, 3 Mar 2014 06:29:49 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 03E7ADE7; Mon, 3 Mar 2014 06:29:46 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 67D77B817; Mon, 3 Mar 2014 08:29:44 +0200 (SAST) Date: Mon, 3 Mar 2014 08:29:44 +0200 From: John Hay To: Ian Lepore Subject: Re: status of AVILA and CAMBRIA code Message-ID: <20140303062944.GC85204@zibbi.meraka.csir.co.za> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com> <20140221130530.GA202@zibbi.meraka.csir.co.za> <1393001249.1145.98.camel@revolution.hippie.lan> <20140224132614.GA31984@zibbi.meraka.csir.co.za> <20140301104431.GA82389@zibbi.meraka.csir.co.za> <1393818757.1149.267.camel@revolution.hippie.lan> <20140303040631.GA85204@zibbi.meraka.csir.co.za> <1393820901.1149.276.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393820901.1149.276.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 06:29:49 -0000 On Sun, Mar 02, 2014 at 09:28:21PM -0700, Ian Lepore wrote: > On Mon, 2014-03-03 at 06:06 +0200, John Hay wrote: > > On Sun, Mar 02, 2014 at 08:52:37PM -0700, Ian Lepore wrote: > > > On Sat, 2014-03-01 at 12:44 +0200, John Hay wrote: > > > > On Mon, Feb 24, 2014 at 03:26:14PM +0200, John Hay wrote: > > > > > Hi Ian, > > > > > > > > > > On Fri, Feb 21, 2014 at 09:47:29AM -0700, Ian Lepore wrote: > > > > > > On Fri, 2014-02-21 at 15:05 +0200, John Hay wrote: > > > > > > > On Wed, Feb 19, 2014 at 09:29:38AM -0800, John-Mark Gurney wrote: > > > > > > > > John Hay wrote this message on Wed, Feb 19, 2014 at 12:59 +0200: > > > > > > > > > What is the status of AVILA and CAMBRIA builds in our tree? Have anybody > > > > > > > > > had success recently? From the lists I can see that other people have > > > > > > > > > also asked in September 2013, but I cannot figure out if there was any > > > > > > > > > successes at that stage. :-) > > > > > > > ... > > > > > > > > > > > > > > > > > > Somewhere along the line the ethernet npe0 device also broke, writing > > > > > > > > > "npe0: npestart_locked: too many fragments 0". But I did not test the > > > > > > > > > npe0 device with every build and only realised it this morning, so I > > > > > > > > > do not know where it broke. :-) > > > > > > > > It looks like adding a few bus_dmamap_unload()s in if_npe.c fixed it. Here is > > > > my patch that seems to fix it. Does it look ok? Can I commit it? > > > > > > > > Index: xscale/ixp425/if_npe.c > > > > =================================================================== > > > > --- xscale/ixp425/if_npe.c (revision 246713) > > > > +++ xscale/ixp425/if_npe.c (working copy) > > > > @@ -1037,6 +1037,8 @@ > > > > > > > > sc = npes[NPE_QM_Q_NPE(entry)]; > > > > npe = P2V(NPE_QM_Q_ADDR(entry), &sc->txdma); > > > > + bus_dmamap_sync(sc->txdma.mtag, npe->ix_map, BUS_DMASYNC_POSTWRITE); > > > > + bus_dmamap_unload(sc->txdma.mtag, npe->ix_map); > > > > m_freem(npe->ix_m); > > > > npe->ix_m = NULL; > > > > > > > > @@ -1112,6 +1114,12 @@ > > > > > > > > DPRINTF(sc, "%s: entry 0x%x neaddr 0x%x ne_len 0x%x\n", > > > > __func__, entry, npe->ix_neaddr, npe->ix_hw->ix_ne[0].len); > > > > + > > > > + /* Flush mbuf memory for rx'd data */ > > > > + bus_dmamap_sync(dma->mtag, npe->ix_map, > > > > + BUS_DMASYNC_POSTREAD); > > > > + bus_dmamap_unload(dma->mtag, npe->ix_map); > > > > + > > > > /* > > > > * Allocate a new mbuf to replenish the rx buffer. > > > > * If doing so fails we drop the rx'd frame so we > > > > @@ -1126,10 +1134,6 @@ > > > > struct npehwbuf *hw = npe->ix_hw; > > > > struct ifnet *ifp = sc->sc_ifp; > > > > > > > > - /* Flush mbuf memory for rx'd data */ > > > > - bus_dmamap_sync(dma->mtag, npe->ix_map, > > > > - BUS_DMASYNC_POSTREAD); > > > > - > > > > /* XXX flush hw buffer; works now 'cuz coherent */ > > > > /* set m_len etc. per rx frame size */ > > > > mrx->m_len = be32toh(hw->ix_ne[0].len) & 0xffff; > > > > > > > > John > > > > > > I think this is more correct, but one more thing is needed... it looks > > > like design here was to load a map then not unload it until the next > > > time you're about to load it. I think that's a bad idea and your > > > changes are the better way, but there are still a few unload calls > > > scattered around that now need to be deleted because they would be > > > unloading a map that was already unloaded when the IO completed. > > > > Thanks, I'll look into the other unloads. I get the feeling that the > > design was actually to only unload if the interface is stopped which > > worked fine until map->sync_count was introduced in arm/busdma_machdep.c? > > > > Regards > > > > John > > In both the places where bus_dmamap_load_mbuf_sg() is called, an unload > is done right before the load. It's almost like an attempt to hoard > resources lest something else grab them while the driver is idle. :) Ahh, we have been looking at different versions of the file. I have been looking at an older version, because I cannot get any console output with the src tree after about August last year. Neither with -current or with 10-stable. I see that cogent made a commit to try and fix this issue on Oct 22, svn 256943. I'll have a look at that. Maybe one day I'll be able to run the Avila/Cambrias on a recentish code base. :-) John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 06:40:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76DBFF7A; Mon, 3 Mar 2014 06:40:50 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E097EA4; Mon, 3 Mar 2014 06:40:50 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id w5so3118309qac.34 for ; Sun, 02 Mar 2014 22:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tgK4QavgUOAzzMoMkMWS/oPfZaGkmlUiMf3Rh+z1MQU=; b=nbJkO0KQc1zsGhCp2Aqkfgkh9xnQN6gFULFEShnHGHcNCs55Eek8R6Wz3NswZ9iHd0 +0YykgF2uiqH4IptmOstsj5KPp+51uuntjXJt5G9wHfA+U4igf0Ze5ldaZZLlF1akrF5 AOay3CiC+dh2/gzsJ91u7qKWl3agokWjLRFMAbaMrJ9hSnU0JQGuUhoX3BX9qLjZ7JdD DW3pHt0Ph1nNSQ+ycHMyqwARRPbEiLv5cpc0HT7sbg2wFZj8vZPKUCQKVqEvQDjEKAYQ rehqnMLzSJtWq/RHDBmaTD7lrieHSEa0hs82RxbpcaC2vlTa+00vK18QSn/3JXUsDN8r V8dw== MIME-Version: 1.0 X-Received: by 10.229.66.202 with SMTP id o10mr21183521qci.7.1393828849224; Sun, 02 Mar 2014 22:40:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Sun, 2 Mar 2014 22:40:49 -0800 (PST) In-Reply-To: <20140303062944.GC85204@zibbi.meraka.csir.co.za> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com> <20140221130530.GA202@zibbi.meraka.csir.co.za> <1393001249.1145.98.camel@revolution.hippie.lan> <20140224132614.GA31984@zibbi.meraka.csir.co.za> <20140301104431.GA82389@zibbi.meraka.csir.co.za> <1393818757.1149.267.camel@revolution.hippie.lan> <20140303040631.GA85204@zibbi.meraka.csir.co.za> <1393820901.1149.276.camel@revolution.hippie.lan> <20140303062944.GC85204@zibbi.meraka.csir.co.za> Date: Sun, 2 Mar 2014 22:40:49 -0800 X-Google-Sender-Auth: AIotJZvJm7CAsqJbzmzl5_zlTbc Message-ID: Subject: Re: status of AVILA and CAMBRIA code From: Adrian Chadd To: John Hay Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 06:40:50 -0000 On 2 March 2014 22:29, John Hay wrote: >> In both the places where bus_dmamap_load_mbuf_sg() is called, an unload >> is done right before the load. It's almost like an attempt to hoard >> resources lest something else grab them while the driver is idle. :) > > Ahh, we have been looking at different versions of the file. I have been > looking at an older version, because I cannot get any console output > with the src tree after about August last year. Neither with -current or > with 10-stable. I see that cogent made a commit to try and fix this > issue on Oct 22, svn 256943. I'll have a look at that. Maybe one day I'll > be able to run the Avila/Cambrias on a recentish code base. :-) > > John > -- > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za yeah, one thing at a time. jmg has been spending some cycles chasing down the broken-ness after the EABI transition and some bitrot; so now it'll boot, but it'll fail shortly after boot. It's better than it was. :-) I'm going to send ian a cambria/avila this week to try and kick this along. -a From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 07:40:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54446393; Mon, 3 Mar 2014 07:40:18 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC1A63EB; Mon, 3 Mar 2014 07:40:17 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so603435iec.30 for ; Sun, 02 Mar 2014 23:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PKpK/B01s6I7GcDkjM7cbaMvBaxPhT1keHDjsu7wPQw=; b=agd7ZP75QEqhDq5Nbq6YwxNLGsYqIGlKLlNcHSfxqqqJRg8w9Iq2YSAKAkM8y5CwJU wfpjNHnp9Sh93L8hkis+YXjbLsyOZydvPH+iLrbY1EKEJHGFqezavSBl+fzT8DzbxRy9 Ghs2N4rgnq9MI0uCjc9yTFiJhF+nNhFLXRdZ9+96ZGW9s91Z4Wpn/oXkQtc8ior+WZE0 GpyIqvAv/I4fj+a0Dh/VDyPwcPVDhT/nV7bT1lzVZzugdoq1nIGN3mEfVbRMhdlFVgi6 EJ7/keqA+nCsuQLhgJcgTHB1olS6iFUpqm5X6jVdqfcvhQ63lzM0c8Fud38fX/lZHDJl p7Kw== MIME-Version: 1.0 X-Received: by 10.50.111.226 with SMTP id il2mr19872147igb.15.1393832417380; Sun, 02 Mar 2014 23:40:17 -0800 (PST) Received: by 10.64.107.3 with HTTP; Sun, 2 Mar 2014 23:40:17 -0800 (PST) In-Reply-To: References: <201402281829.s1SITAQk019090@svn.freebsd.org> Date: Mon, 3 Mar 2014 15:40:17 +0800 Message-ID: Subject: Re: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc sys/conf sys/tools/fdt From: Ganbold Tsagaankhuu To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , embedded@freebsd.org, mips@freebsd.org, powerpc@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 07:40:18 -0000 Hi, On Sat, Mar 1, 2014 at 2:38 AM, Warner Losh wrote: > Greetings, > > This commit changes how we do DTS -> DTB compiling. For the most part, it > should be a NOP, if all my tests are good, but I may have oopsed somethin= g > without realizing it. > > This commit does switch us back to the GPL dtc. That cannot be helped. Th= e > BSDL one was too far away from working, but if that status ever changes, > I'm > happy to change the defaults back. This change was discussed by most of t= he > major workers in arm@ and mips@ land before changing back, and they felt, > as I do, that using vendor dts files unmodified was a bigger win for > embedded > than the regression back to a GPL'd piece of software when the BSDL'd one > isn't up to the task today of coping with this new world order. If that > changes, > then I'd be happy to switch back. > > Hope this doesn't break anybody. I'll be around if it does. > It seems crashing when building kernel for cubieboard2. Part of build log: -------------------------------------------------------------- >>> stage 3.1: making dependencies -------------------------------------------------------------- cd /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2; MAKEOBJDIRPREFIX=3D/usr/obj/arm.armv6 MACHINE_ARCH=3Darmv6 MACHINE=3Darm CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/groff_fo= nt GROFF_TMAC_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=3D/usr/obj/arm.armv6/usr/src/tmp _LDSCRIPTROOT=3D VERSION=3D"FreeBSD 11.0-CURRENT armv6 1100010" INSTALL=3D"sh /usr/src/tools/install.sh" PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6/u= sr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games:/= usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/arm.armv6/usr/src/tmp/usr= /sbin:/usr/obj/arm.armv6/usr/src/tmp/usr/bin:/usr/obj/arm.armv6/usr/src/tmp= /usr/games:/sbin:/bin:/usr/sbin:/usr/bin CC=3D"cc " CXX=3D"c++ " CPP=3D"cpp " AS=3D"as" AR=3D"ar" LD=3D"ld" NM=3Dn= m OBJDUMP=3D RANLIB=3Dranlib STRINGS=3D COMPILER_TYPE=3Dclang make -m /usr/src/share/mk KERNEL=3Dkernel depend -DNO_MODULES_OBJ machine -> /usr/src/sys/arm/include awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h 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 -Wno-unused-function -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding /usr/src/sys/arm/arm/genassym.c NM=3D'nm' sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h sh /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys cubieboard2.dts /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dtb Segmentation fault (core dumped) *** Error code 139 Stop. make: stopped in /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2 *** Error code 1 Stop. make: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src root@bsd:/usr/src # sh /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys cubieboard2.dts /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dtb :158:10: fatal error: 'cubieboard2.dts' file not found #include "cubieboard2.dts" ^ 1 error generated. Segmentation fault (core dumped) Ganbold > > Warner > > Begin forwarded message: > > > From: Warner Losh > > Subject: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts > sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc > sys/conf sys/tools/fdt > > Date: February 28, 2014 at 11:29:10 AM MST > > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > > > > Author: imp > > Date: Fri Feb 28 18:29:09 2014 > > New Revision: 262614 > > URL: http://svnweb.freebsd.org/changeset/base/262614 > > > > Log: > > Integrate device-tree upstream files into the build process: > > (1) Invoke cpp to bring in files via #include (although the old > > /include/ stuff is supported still). > > (2) bring in files from either vendor tree or freebsd-custom files > > when building. > > (3) move all dts* files from sys/boot/fdt/dts to > > sys/boot/fdt/dts/${MACHINE} as appropriate. > > (4) encode all the magic to do the build in sys/tools/fdt/make_dtb.sh > > so that the different places in the tree use the exact same logic. > > (5) switch back to gpl dtc by default. the bsdl one in the tree has > > significant issues not easily addressed by those unfamiliar with > > the code. > > > > Added: > > head/sys/boot/fdt/dts/arm/ > > head/sys/boot/fdt/dts/arm/am335x-evm.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/am335x-evm.dt= s > > head/sys/boot/fdt/dts/arm/am335x.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/am335x.dtsi > > head/sys/boot/fdt/dts/arm/bcm2835.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/bcm2835.dtsi > > head/sys/boot/fdt/dts/arm/beaglebone-black.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/beaglebone-black.dts > > head/sys/boot/fdt/dts/arm/beaglebone.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/beaglebone.dt= s > > head/sys/boot/fdt/dts/arm/cubieboard.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/cubieboard.dt= s > > head/sys/boot/fdt/dts/arm/cubieboard2.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/cubieboard2.d= ts > > head/sys/boot/fdt/dts/arm/db78100.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/db78100.dts > > head/sys/boot/fdt/dts/arm/db78460.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/db78460.dts > > head/sys/boot/fdt/dts/arm/db88f5182.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f5182.dts > > head/sys/boot/fdt/dts/arm/db88f5281.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f5281.dts > > head/sys/boot/fdt/dts/arm/db88f6281.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f6281.dts > > head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/digi-ccwmx53.dts > > head/sys/boot/fdt/dts/arm/dockstar.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/dockstar.dts > > head/sys/boot/fdt/dts/arm/dreamplug-1001.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/dreamplug-1001.dts > > head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/dreamplug-1001N.dts > > head/sys/boot/fdt/dts/arm/ea3250.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/ea3250.dts > > head/sys/boot/fdt/dts/arm/efikamx.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/efikamx.dts > > head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/exynos5250-arndale.dts > > head/sys/boot/fdt/dts/arm/exynos5250.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/exynos5250.dt= si > > head/sys/boot/fdt/dts/arm/imx51x.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/imx51x.dtsi > > head/sys/boot/fdt/dts/arm/imx53-qsb.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/imx53-qsb.dts > > head/sys/boot/fdt/dts/arm/imx53x.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/imx53x.dtsi > > head/sys/boot/fdt/dts/arm/imx6.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/imx6.dtsi > > head/sys/boot/fdt/dts/arm/p1020rdb.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/p1020rdb.dts > > head/sys/boot/fdt/dts/arm/p2020ds.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/p2020ds.dts > > head/sys/boot/fdt/dts/arm/p2041rdb.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041rdb.dts > > head/sys/boot/fdt/dts/arm/p2041si.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041si.dtsi > > head/sys/boot/fdt/dts/arm/p3041ds.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041ds.dts > > head/sys/boot/fdt/dts/arm/p3041si.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041si.dtsi > > head/sys/boot/fdt/dts/arm/p5020ds.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020ds.dts > > head/sys/boot/fdt/dts/arm/p5020si.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020si.dtsi > > head/sys/boot/fdt/dts/arm/pandaboard.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/pandaboard.dt= s > > head/sys/boot/fdt/dts/arm/rk3188-radxa.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/rk3188-radxa.dts > > head/sys/boot/fdt/dts/arm/rk3188.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/rk3188.dtsi > > head/sys/boot/fdt/dts/arm/rpi.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/rpi.dts > > head/sys/boot/fdt/dts/arm/sheevaplug.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/sheevaplug.dt= s > > head/sys/boot/fdt/dts/arm/tegra20-paz00.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/tegra20-paz00.dts > > head/sys/boot/fdt/dts/arm/tegra20.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/tegra20.dtsi > > head/sys/boot/fdt/dts/arm/trimslice.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/trimslice.dts > > head/sys/boot/fdt/dts/arm/ts7800.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/ts7800.dts > > head/sys/boot/fdt/dts/arm/versatilepb.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/versatilepb.d= ts > > head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts > > head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/vybrid-cosmic.dts > > head/sys/boot/fdt/dts/arm/vybrid-quartz.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/vybrid-quartz.dts > > head/sys/boot/fdt/dts/arm/vybrid.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/vybrid.dtsi > > head/sys/boot/fdt/dts/arm/wandboard-dual.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/wandboard-dual.dts > > head/sys/boot/fdt/dts/arm/wandboard-quad.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/wandboard-quad.dts > > head/sys/boot/fdt/dts/arm/wandboard-solo.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/wandboard-solo.dts > > head/sys/boot/fdt/dts/arm/zedboard.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/zedboard.dts > > head/sys/boot/fdt/dts/mips/ > > head/sys/boot/fdt/dts/mips/beri-netfpga.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/beri-netfpga.dts > > head/sys/boot/fdt/dts/mips/beri-sim.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/beri-sim.dts > > head/sys/boot/fdt/dts/mips/beripad-de4.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/beripad-de4.d= ts > > head/sys/boot/fdt/dts/mips/xlp-basic.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/xlp-basic.dts > > head/sys/boot/fdt/dts/powerpc/ > > head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/mpc8555cds.dt= s > > head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/mpc8572ds.dts > > head/sys/tools/fdt/make_dtb.sh (contents, props changed) > > Deleted: > > head/sys/boot/fdt/dts/am335x-evm.dts > > head/sys/boot/fdt/dts/am335x.dtsi > > head/sys/boot/fdt/dts/bcm2835.dtsi > > head/sys/boot/fdt/dts/beaglebone-black.dts > > head/sys/boot/fdt/dts/beaglebone.dts > > head/sys/boot/fdt/dts/beri-netfpga.dts > > head/sys/boot/fdt/dts/beri-sim.dts > > head/sys/boot/fdt/dts/beripad-de4.dts > > head/sys/boot/fdt/dts/cubieboard.dts > > head/sys/boot/fdt/dts/cubieboard2.dts > > head/sys/boot/fdt/dts/db78100.dts > > head/sys/boot/fdt/dts/db78460.dts > > head/sys/boot/fdt/dts/db88f5182.dts > > head/sys/boot/fdt/dts/db88f5281.dts > > head/sys/boot/fdt/dts/db88f6281.dts > > head/sys/boot/fdt/dts/digi-ccwmx53.dts > > head/sys/boot/fdt/dts/dockstar.dts > > head/sys/boot/fdt/dts/dreamplug-1001.dts > > head/sys/boot/fdt/dts/dreamplug-1001N.dts > > head/sys/boot/fdt/dts/ea3250.dts > > head/sys/boot/fdt/dts/efikamx.dts > > head/sys/boot/fdt/dts/exynos5250-arndale.dts > > head/sys/boot/fdt/dts/exynos5250.dtsi > > head/sys/boot/fdt/dts/imx51x.dtsi > > head/sys/boot/fdt/dts/imx53-qsb.dts > > head/sys/boot/fdt/dts/imx53x.dtsi > > head/sys/boot/fdt/dts/imx6.dtsi > > head/sys/boot/fdt/dts/mpc8555cds.dts > > head/sys/boot/fdt/dts/mpc8572ds.dts > > head/sys/boot/fdt/dts/p1020rdb.dts > > head/sys/boot/fdt/dts/p2020ds.dts > > head/sys/boot/fdt/dts/p2041rdb.dts > > head/sys/boot/fdt/dts/p2041si.dtsi > > head/sys/boot/fdt/dts/p3041ds.dts > > head/sys/boot/fdt/dts/p3041si.dtsi > > head/sys/boot/fdt/dts/p5020ds.dts > > head/sys/boot/fdt/dts/p5020si.dtsi > > head/sys/boot/fdt/dts/pandaboard.dts > > head/sys/boot/fdt/dts/rk3188-radxa.dts > > head/sys/boot/fdt/dts/rk3188.dtsi > > head/sys/boot/fdt/dts/rpi.dts > > head/sys/boot/fdt/dts/sheevaplug.dts > > head/sys/boot/fdt/dts/tegra20-paz00.dts > > head/sys/boot/fdt/dts/tegra20.dtsi > > head/sys/boot/fdt/dts/trimslice.dts > > head/sys/boot/fdt/dts/ts7800.dts > > head/sys/boot/fdt/dts/versatilepb.dts > > head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts > > head/sys/boot/fdt/dts/vybrid-cosmic.dts > > head/sys/boot/fdt/dts/vybrid-quartz.dts > > head/sys/boot/fdt/dts/vybrid.dtsi > > head/sys/boot/fdt/dts/wandboard-dual.dts > > head/sys/boot/fdt/dts/wandboard-quad.dts > > head/sys/boot/fdt/dts/wandboard-solo.dts > > head/sys/boot/fdt/dts/xlp-basic.dts > > head/sys/boot/fdt/dts/zedboard.dts > > Modified: > > head/Makefile.inc1 > > head/share/mk/bsd.own.mk > > head/sys/conf/files > > > > Modified: head/Makefile.inc1 > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > --- head/Makefile.inc1 Fri Feb 28 18:06:00 2014 (r262613) > > +++ head/Makefile.inc1 Fri Feb 28 18:29:09 2014 (r262614) > > @@ -1262,7 +1262,7 @@ _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/ > > lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge > > .endif > > > > -# Default to building the BSDL DTC, but build the GPL one if users > explicitly > > +# Default to building the GPL DTC, but build the BSDL one if users > explicitly > > # request it. > > _dtc=3D usr.bin/dtc > > .if ${MK_GPL_DTC} !=3D "no" > > @@ -1853,7 +1853,7 @@ builddtb: > > echo "ERROR: FDT_DTS_FILE must be specified!"; \ > > exit 1; \ > > fi; \ > > - if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} ]; then \ > > + if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE} > ]; then \ > > echo "ERROR: Specified DTS file (${FDT_DTS_FILE}) does no= t > \ > > exist!"; \ > > exit 1; \ > > @@ -1863,9 +1863,9 @@ builddtb: > > directory"; \ > > fi > > @PATH=3D${TMPPATH} \ > > - dtc -O dtb -o \ > > - ${DTBOUTPUTPATH}/`echo ${FDT_DTS_FILE} | cut -d. -f1`.dtb -b = 0 > \ > > - -p 1024 ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} > > + ${.CURDIR}/sys/tools/fdt/make_dtb.sh ${.CURDIR}/sys \ > > + ${FDT_DTS_FILE} \ > > + ${DTBOUTPUTPATH}/`basename ${FDT_DTS_FILE} .dts` > > > > ############### > > > > > > Modified: head/share/mk/bsd.own.mk > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > --- head/share/mk/bsd.own.mk Fri Feb 28 18:06:00 2014 (r262613) > > +++ head/share/mk/bsd.own.mk Fri Feb 28 18:29:09 2014 (r262614) > > @@ -287,6 +287,7 @@ __DEFAULT_YES_OPTIONS =3D \ > > GNU \ > > GPIB \ > > GPIO \ > > + GPL_DTC \ > > GROFF \ > > HTML \ > > ICONV \ > > @@ -368,7 +369,6 @@ __DEFAULT_NO_OPTIONS =3D \ > > CLANG_EXTRAS \ > > CTF \ > > DEBUG_FILES \ > > - GPL_DTC \ > > HESIOD \ > > INSTALL_AS_USER \ > > LLDB \ > > > > Copied and modified: head/sys/boot/fdt/dts/arm/am335x-evm.dts (from > r262613, head/sys/boot/fdt/dts/am335x-evm.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/am335x.dtsi (from > r262613, head/sys/boot/fdt/dts/am335x.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/bcm2835.dtsi (from > r262613, head/sys/boot/fdt/dts/bcm2835.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone-black.dts > (from r262613, head/sys/boot/fdt/dts/beaglebone-black.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone.dts (from > r262613, head/sys/boot/fdt/dts/beaglebone.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard.dts (from > r262613, head/sys/boot/fdt/dts/cubieboard.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard2.dts (from > r262613, head/sys/boot/fdt/dts/cubieboard2.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/db78100.dts (from > r262613, head/sys/boot/fdt/dts/db78100.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/db78460.dts (from > r262613, head/sys/boot/fdt/dts/db78460.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5182.dts (from > r262613, head/sys/boot/fdt/dts/db88f5182.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5281.dts (from > r262613, head/sys/boot/fdt/dts/db88f5281.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/db88f6281.dts (from > r262613, head/sys/boot/fdt/dts/db88f6281.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts (from > r262613, head/sys/boot/fdt/dts/digi-ccwmx53.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/dockstar.dts (from > r262613, head/sys/boot/fdt/dts/dockstar.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001.dts (from > r262613, head/sys/boot/fdt/dts/dreamplug-1001.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts (fro= m > r262613, head/sys/boot/fdt/dts/dreamplug-1001N.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/ea3250.dts (from r262613= , > head/sys/boot/fdt/dts/ea3250.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/efikamx.dts (from > r262613, head/sys/boot/fdt/dts/efikamx.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts > (from r262613, head/sys/boot/fdt/dts/exynos5250-arndale.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250.dtsi (from > r262613, head/sys/boot/fdt/dts/exynos5250.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/imx51x.dtsi (from > r262613, head/sys/boot/fdt/dts/imx51x.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/imx53-qsb.dts (from > r262613, head/sys/boot/fdt/dts/imx53-qsb.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/imx53x.dtsi (from > r262613, head/sys/boot/fdt/dts/imx53x.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/imx6.dtsi (from r262613, > head/sys/boot/fdt/dts/imx6.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p1020rdb.dts (from > r262613, head/sys/boot/fdt/dts/p1020rdb.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p2020ds.dts (from > r262613, head/sys/boot/fdt/dts/p2020ds.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p2041rdb.dts (from > r262613, head/sys/boot/fdt/dts/p2041rdb.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p2041si.dtsi (from > r262613, head/sys/boot/fdt/dts/p2041si.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p3041ds.dts (from > r262613, head/sys/boot/fdt/dts/p3041ds.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p3041si.dtsi (from > r262613, head/sys/boot/fdt/dts/p3041si.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p5020ds.dts (from > r262613, head/sys/boot/fdt/dts/p5020ds.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p5020si.dtsi (from > r262613, head/sys/boot/fdt/dts/p5020si.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/pandaboard.dts (from > r262613, head/sys/boot/fdt/dts/pandaboard.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188-radxa.dts (from > r262613, head/sys/boot/fdt/dts/rk3188-radxa.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188.dtsi (from > r262613, head/sys/boot/fdt/dts/rk3188.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/rpi.dts (from r262613, > head/sys/boot/fdt/dts/rpi.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/sheevaplug.dts (from > r262613, head/sys/boot/fdt/dts/sheevaplug.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20-paz00.dts (from > r262613, head/sys/boot/fdt/dts/tegra20-paz00.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20.dtsi (from > r262613, head/sys/boot/fdt/dts/tegra20.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/trimslice.dts (from > r262613, head/sys/boot/fdt/dts/trimslice.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/ts7800.dts (from r262613= , > head/sys/boot/fdt/dts/ts7800.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/versatilepb.dts (from > r262613, head/sys/boot/fdt/dts/versatilepb.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts > (from r262613, head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts (from > r262613, head/sys/boot/fdt/dts/vybrid-cosmic.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-quartz.dts (from > r262613, head/sys/boot/fdt/dts/vybrid-quartz.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid.dtsi (from > r262613, head/sys/boot/fdt/dts/vybrid.dtsi) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-dual.dts (from > r262613, head/sys/boot/fdt/dts/wandboard-dual.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-quad.dts (from > r262613, head/sys/boot/fdt/dts/wandboard-quad.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-solo.dts (from > r262613, head/sys/boot/fdt/dts/wandboard-solo.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/zedboard.dts (from > r262613, head/sys/boot/fdt/dts/zedboard.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/mips/beri-netfpga.dts (from > r262613, head/sys/boot/fdt/dts/beri-netfpga.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/mips/beri-sim.dts (from > r262613, head/sys/boot/fdt/dts/beri-sim.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/mips/beripad-de4.dts (from > r262613, head/sys/boot/fdt/dts/beripad-de4.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/mips/xlp-basic.dts (from > r262613, head/sys/boot/fdt/dts/xlp-basic.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts (from > r262613, head/sys/boot/fdt/dts/mpc8555cds.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts (from > r262613, head/sys/boot/fdt/dts/mpc8572ds.dts) > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Modified: head/sys/conf/files > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > --- head/sys/conf/files Fri Feb 28 18:06:00 2014 (r262613) > > +++ head/sys/conf/files Fri Feb 28 18:29:09 2014 (r262614) > > @@ -14,11 +14,12 @@ acpi_quirks.h optional acpi > \ > > # from the specified source (DTS) file: .dts -> .dt= b > > # > > fdt_dtb_file optional fdt \ > > - compile-with "if [ -f $S/boot/fdt/dts/${FDT_DTS_FILE} ]; then dtc > -O dtb -o ${FDT_DTS_FILE:R}.dtb -b 0 -p 1024 > $S/boot/fdt/dts/${FDT_DTS_FILE}; fi" \ > > + compile-with "sh $S/tools/fdt/make_dtb.sh $S ${FDT_DTS_FILE} > ${.CURDIR}/${FDT_DTS_FILE:R}.dtb" \ > > no-obj no-implicit-rule before-depend \ > > clean "${FDT_DTS_FILE:R}.dtb" > > fdt_static_dtb.h optional fdt fdt_dtb_static \ > > - compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} ." \ > > + compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} > ${.CURDIR}" \ > > + dependency "fdt_dtb_file" \ > > no-obj no-implicit-rule before-depend \ > > clean "fdt_static_dtb.h" > > feeder_eq_gen.h optional sound > \ > > @@ -1370,7 +1371,7 @@ dev/fb/splash.c optional sc splas= h > > dev/fdt/fdt_common.c optional fdt > > dev/fdt/fdt_slicer.c optional fdt cfi | fdt nand > > dev/fdt/fdt_static_dtb.S optional fdt fdt_dtb_static \ > > - dependency "$S/boot/fdt/dts/${FDT_DTS_FILE}" > > + dependency "$S/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE}" > > dev/fdt/simplebus.c optional fdt > > dev/fe/if_fe.c optional fe > > dev/fe/if_fe_pccard.c optional fe pccard > > > > Added: head/sys/tools/fdt/make_dtb.sh > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > > +++ head/sys/tools/fdt/make_dtb.sh Fri Feb 28 18:29:09 2014 > (r262614) > > @@ -0,0 +1,11 @@ > > +#!/bin/sh > > +# > > +# $FreeBSD$ > > + > > +# Script generates dtb file ($3) from dts source ($2) in build tree S > ($1) > > +S=3D$1 > > +dts=3D$2 > > +dtb=3D$3 > > + > > +cpp -x assembler-with-cpp -I $S/gnu/dts/include -I > $S/boot/fdt/dts/${MACHINE} -I $S/gnu/dts/${MACHINE} -include $dts /dev/nu= ll > | > > + dtc -O dtb -o $dtb -b 0 -p 1024 -i $S/boot/fdt/dts -i > $S/gnu/dts/${MACHINE} > > > > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 08:44:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 797CCFEF; Mon, 3 Mar 2014 08:44:12 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C4DDB1E; Mon, 3 Mar 2014 08:44:12 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id lx4so1312074iec.9 for ; Mon, 03 Mar 2014 00:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BDg11Jj52PUCaqZIvLHLXN1rO0gIzuDSJNdVcRWuDYc=; b=mSByb1iD3U4zx0JwHlmjc1CMNIDuZiM+FeAixZ8fspG9hFgkieUZj94Mfa6vtqUQNt 4VJzJ1Frixo0w7T0UFJ306rmbrTj3gd2O82PIhEGEEGwEtKIn6Uo9vF9okmCaatxQNzZ 4Ct7C/GzacjME+kKfp1W/boY0jJqkkHuAQfluMIKWkGfLta46YWawYYZTJ+QHlFoKjIi We2P4EMaVR9BatwminJZZ+gVBQ5UYq282fZmhckLwJFI0vtArgYK+kRY7i0mhs7LCvRN nTjNkh+VX7/2tD8n2jIPy0DYdPeyMQx72gxq4oWiTCaf8i6IFoYgmiUzsaWXR1wC9qNu HFrw== MIME-Version: 1.0 X-Received: by 10.51.17.104 with SMTP id gd8mr20406337igd.48.1393836251474; Mon, 03 Mar 2014 00:44:11 -0800 (PST) Received: by 10.64.107.3 with HTTP; Mon, 3 Mar 2014 00:44:11 -0800 (PST) In-Reply-To: References: <201402281829.s1SITAQk019090@svn.freebsd.org> Date: Mon, 3 Mar 2014 16:44:11 +0800 Message-ID: Subject: Re: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc sys/conf sys/tools/fdt From: Ganbold Tsagaankhuu To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , embedded@freebsd.org, mips@freebsd.org, powerpc@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 08:44:12 -0000 On Mon, Mar 3, 2014 at 3:40 PM, Ganbold Tsagaankhuu wrot= e: > Hi, > > On Sat, Mar 1, 2014 at 2:38 AM, Warner Losh wrote: > >> Greetings, >> >> This commit changes how we do DTS -> DTB compiling. For the most part, i= t >> should be a NOP, if all my tests are good, but I may have oopsed somethi= ng >> without realizing it. >> >> This commit does switch us back to the GPL dtc. That cannot be helped. T= he >> BSDL one was too far away from working, but if that status ever changes, >> I'm >> happy to change the defaults back. This change was discussed by most of >> the >> major workers in arm@ and mips@ land before changing back, and they felt= , >> as I do, that using vendor dts files unmodified was a bigger win for >> embedded >> than the regression back to a GPL'd piece of software when the BSDL'd on= e >> isn't up to the task today of coping with this new world order. If that >> changes, >> then I'd be happy to switch back. >> >> Hope this doesn't break anybody. I'll be around if it does. >> > > > It seems crashing when building kernel for cubieboard2. > > Part of build log: > > -------------------------------------------------------------- > >>> stage 3.1: making dependencies > -------------------------------------------------------------- > cd /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2; > MAKEOBJDIRPREFIX=3D/usr/obj/arm.armv6 MACHINE_ARCH=3Darmv6 MACHINE=3Dar= m > CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bi= n > GROFF_FONT_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/groff_= font > GROFF_TMAC_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=3D/usr/obj/arm.armv6/usr/src/tmp _LDSCRIPTROOT=3D > VERSION=3D"FreeBSD 11.0-CURRENT armv6 1100010" INSTALL=3D"sh > /usr/src/tools/install.sh" > PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6= /usr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games= :/usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/arm.armv6/usr/src/tmp/u= sr/sbin:/usr/obj/arm.armv6/usr/src/tmp/usr/bin:/usr/obj/arm.armv6/usr/src/t= mp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > CC=3D"cc " CXX=3D"c++ " CPP=3D"cpp " AS=3D"as" AR=3D"ar" LD=3D"ld" NM= =3Dnm OBJDUMP=3D > RANLIB=3Dranlib STRINGS=3D COMPILER_TYPE=3Dclang make -m /usr/src/share/= mk > KERNEL=3Dkernel depend -DNO_MODULES_OBJ > machine -> /usr/src/sys/arm/include > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h > 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 -Wno-unused-function -nostdinc -I. > -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilte= r > -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal > -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -funwind-tables -mllvm -arm-enable-ehabi > -ffreestanding /usr/src/sys/arm/arm/genassym.c > NM=3D'nm' sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h > sh /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys cubieboard2.dts > /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dtb > Segmentation fault (core dumped) > *** Error code 139 > > Stop. > make: stopped in /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2 > *** Error code 1 > > Stop. > make: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > root@bsd:/usr/src # sh /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys > cubieboard2.dts /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dt= b > :158:10: fatal error: 'cubieboard2.dts' file not found > #include "cubieboard2.dts" > ^ > 1 error generated. > Segmentation fault (core dumped) > > Sorry for the noise, I had to build kernel toolchain again, now it works. Ganbold > > > Ganbold > > > > >> >> Warner >> >> Begin forwarded message: >> >> > From: Warner Losh >> > Subject: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts >> sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc >> sys/conf sys/tools/fdt >> > Date: February 28, 2014 at 11:29:10 AM MST >> > To: src-committers@freebsd.org, svn-src-all@freebsd.org, >> svn-src-head@freebsd.org >> > >> > Author: imp >> > Date: Fri Feb 28 18:29:09 2014 >> > New Revision: 262614 >> > URL: http://svnweb.freebsd.org/changeset/base/262614 >> > >> > Log: >> > Integrate device-tree upstream files into the build process: >> > (1) Invoke cpp to bring in files via #include (although the old >> > /include/ stuff is supported still). >> > (2) bring in files from either vendor tree or freebsd-custom files >> > when building. >> > (3) move all dts* files from sys/boot/fdt/dts to >> > sys/boot/fdt/dts/${MACHINE} as appropriate. >> > (4) encode all the magic to do the build in sys/tools/fdt/make_dtb.sh >> > so that the different places in the tree use the exact same logic= . >> > (5) switch back to gpl dtc by default. the bsdl one in the tree has >> > significant issues not easily addressed by those unfamiliar with >> > the code. >> > >> > Added: >> > head/sys/boot/fdt/dts/arm/ >> > head/sys/boot/fdt/dts/arm/am335x-evm.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/am335x-evm.d= ts >> > head/sys/boot/fdt/dts/arm/am335x.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/am335x.dtsi >> > head/sys/boot/fdt/dts/arm/bcm2835.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/bcm2835.dtsi >> > head/sys/boot/fdt/dts/arm/beaglebone-black.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/beaglebone-black.dts >> > head/sys/boot/fdt/dts/arm/beaglebone.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/beaglebone.d= ts >> > head/sys/boot/fdt/dts/arm/cubieboard.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/cubieboard.d= ts >> > head/sys/boot/fdt/dts/arm/cubieboard2.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/cubieboard2.dts >> > head/sys/boot/fdt/dts/arm/db78100.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/db78100.dts >> > head/sys/boot/fdt/dts/arm/db78460.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/db78460.dts >> > head/sys/boot/fdt/dts/arm/db88f5182.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f5182.dt= s >> > head/sys/boot/fdt/dts/arm/db88f5281.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f5281.dt= s >> > head/sys/boot/fdt/dts/arm/db88f6281.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f6281.dt= s >> > head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/digi-ccwmx53.dts >> > head/sys/boot/fdt/dts/arm/dockstar.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/dockstar.dts >> > head/sys/boot/fdt/dts/arm/dreamplug-1001.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/dreamplug-1001.dts >> > head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/dreamplug-1001N.dts >> > head/sys/boot/fdt/dts/arm/ea3250.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/ea3250.dts >> > head/sys/boot/fdt/dts/arm/efikamx.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/efikamx.dts >> > head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/exynos5250-arndale.dts >> > head/sys/boot/fdt/dts/arm/exynos5250.dtsi >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/exynos5250.dtsi >> > head/sys/boot/fdt/dts/arm/imx51x.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/imx51x.dtsi >> > head/sys/boot/fdt/dts/arm/imx53-qsb.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/imx53-qsb.dt= s >> > head/sys/boot/fdt/dts/arm/imx53x.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/imx53x.dtsi >> > head/sys/boot/fdt/dts/arm/imx6.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/imx6.dtsi >> > head/sys/boot/fdt/dts/arm/p1020rdb.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p1020rdb.dts >> > head/sys/boot/fdt/dts/arm/p2020ds.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p2020ds.dts >> > head/sys/boot/fdt/dts/arm/p2041rdb.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041rdb.dts >> > head/sys/boot/fdt/dts/arm/p2041si.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041si.dtsi >> > head/sys/boot/fdt/dts/arm/p3041ds.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041ds.dts >> > head/sys/boot/fdt/dts/arm/p3041si.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041si.dtsi >> > head/sys/boot/fdt/dts/arm/p5020ds.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020ds.dts >> > head/sys/boot/fdt/dts/arm/p5020si.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020si.dtsi >> > head/sys/boot/fdt/dts/arm/pandaboard.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/pandaboard.d= ts >> > head/sys/boot/fdt/dts/arm/rk3188-radxa.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/rk3188-radxa.dts >> > head/sys/boot/fdt/dts/arm/rk3188.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/rk3188.dtsi >> > head/sys/boot/fdt/dts/arm/rpi.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/rpi.dts >> > head/sys/boot/fdt/dts/arm/sheevaplug.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/sheevaplug.d= ts >> > head/sys/boot/fdt/dts/arm/tegra20-paz00.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/tegra20-paz00.dts >> > head/sys/boot/fdt/dts/arm/tegra20.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/tegra20.dtsi >> > head/sys/boot/fdt/dts/arm/trimslice.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/trimslice.dt= s >> > head/sys/boot/fdt/dts/arm/ts7800.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/ts7800.dts >> > head/sys/boot/fdt/dts/arm/versatilepb.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/versatilepb.dts >> > head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts >> > head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/vybrid-cosmic.dts >> > head/sys/boot/fdt/dts/arm/vybrid-quartz.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/vybrid-quartz.dts >> > head/sys/boot/fdt/dts/arm/vybrid.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/vybrid.dtsi >> > head/sys/boot/fdt/dts/arm/wandboard-dual.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/wandboard-dual.dts >> > head/sys/boot/fdt/dts/arm/wandboard-quad.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/wandboard-quad.dts >> > head/sys/boot/fdt/dts/arm/wandboard-solo.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/wandboard-solo.dts >> > head/sys/boot/fdt/dts/arm/zedboard.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/zedboard.dts >> > head/sys/boot/fdt/dts/mips/ >> > head/sys/boot/fdt/dts/mips/beri-netfpga.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/beri-netfpga.dts >> > head/sys/boot/fdt/dts/mips/beri-sim.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/beri-sim.dts >> > head/sys/boot/fdt/dts/mips/beripad-de4.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/beripad-de4.dts >> > head/sys/boot/fdt/dts/mips/xlp-basic.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/xlp-basic.dt= s >> > head/sys/boot/fdt/dts/powerpc/ >> > head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/mpc8555cds.d= ts >> > head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/mpc8572ds.dt= s >> > head/sys/tools/fdt/make_dtb.sh (contents, props changed) >> > Deleted: >> > head/sys/boot/fdt/dts/am335x-evm.dts >> > head/sys/boot/fdt/dts/am335x.dtsi >> > head/sys/boot/fdt/dts/bcm2835.dtsi >> > head/sys/boot/fdt/dts/beaglebone-black.dts >> > head/sys/boot/fdt/dts/beaglebone.dts >> > head/sys/boot/fdt/dts/beri-netfpga.dts >> > head/sys/boot/fdt/dts/beri-sim.dts >> > head/sys/boot/fdt/dts/beripad-de4.dts >> > head/sys/boot/fdt/dts/cubieboard.dts >> > head/sys/boot/fdt/dts/cubieboard2.dts >> > head/sys/boot/fdt/dts/db78100.dts >> > head/sys/boot/fdt/dts/db78460.dts >> > head/sys/boot/fdt/dts/db88f5182.dts >> > head/sys/boot/fdt/dts/db88f5281.dts >> > head/sys/boot/fdt/dts/db88f6281.dts >> > head/sys/boot/fdt/dts/digi-ccwmx53.dts >> > head/sys/boot/fdt/dts/dockstar.dts >> > head/sys/boot/fdt/dts/dreamplug-1001.dts >> > head/sys/boot/fdt/dts/dreamplug-1001N.dts >> > head/sys/boot/fdt/dts/ea3250.dts >> > head/sys/boot/fdt/dts/efikamx.dts >> > head/sys/boot/fdt/dts/exynos5250-arndale.dts >> > head/sys/boot/fdt/dts/exynos5250.dtsi >> > head/sys/boot/fdt/dts/imx51x.dtsi >> > head/sys/boot/fdt/dts/imx53-qsb.dts >> > head/sys/boot/fdt/dts/imx53x.dtsi >> > head/sys/boot/fdt/dts/imx6.dtsi >> > head/sys/boot/fdt/dts/mpc8555cds.dts >> > head/sys/boot/fdt/dts/mpc8572ds.dts >> > head/sys/boot/fdt/dts/p1020rdb.dts >> > head/sys/boot/fdt/dts/p2020ds.dts >> > head/sys/boot/fdt/dts/p2041rdb.dts >> > head/sys/boot/fdt/dts/p2041si.dtsi >> > head/sys/boot/fdt/dts/p3041ds.dts >> > head/sys/boot/fdt/dts/p3041si.dtsi >> > head/sys/boot/fdt/dts/p5020ds.dts >> > head/sys/boot/fdt/dts/p5020si.dtsi >> > head/sys/boot/fdt/dts/pandaboard.dts >> > head/sys/boot/fdt/dts/rk3188-radxa.dts >> > head/sys/boot/fdt/dts/rk3188.dtsi >> > head/sys/boot/fdt/dts/rpi.dts >> > head/sys/boot/fdt/dts/sheevaplug.dts >> > head/sys/boot/fdt/dts/tegra20-paz00.dts >> > head/sys/boot/fdt/dts/tegra20.dtsi >> > head/sys/boot/fdt/dts/trimslice.dts >> > head/sys/boot/fdt/dts/ts7800.dts >> > head/sys/boot/fdt/dts/versatilepb.dts >> > head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts >> > head/sys/boot/fdt/dts/vybrid-cosmic.dts >> > head/sys/boot/fdt/dts/vybrid-quartz.dts >> > head/sys/boot/fdt/dts/vybrid.dtsi >> > head/sys/boot/fdt/dts/wandboard-dual.dts >> > head/sys/boot/fdt/dts/wandboard-quad.dts >> > head/sys/boot/fdt/dts/wandboard-solo.dts >> > head/sys/boot/fdt/dts/xlp-basic.dts >> > head/sys/boot/fdt/dts/zedboard.dts >> > Modified: >> > head/Makefile.inc1 >> > head/share/mk/bsd.own.mk >> > head/sys/conf/files >> > >> > Modified: head/Makefile.inc1 >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > --- head/Makefile.inc1 Fri Feb 28 18:06:00 2014 (r262613= ) >> > +++ head/Makefile.inc1 Fri Feb 28 18:29:09 2014 (r262614= ) >> > @@ -1262,7 +1262,7 @@ _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/ >> > lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge >> > .endif >> > >> > -# Default to building the BSDL DTC, but build the GPL one if users >> explicitly >> > +# Default to building the GPL DTC, but build the BSDL one if users >> explicitly >> > # request it. >> > _dtc=3D usr.bin/dtc >> > .if ${MK_GPL_DTC} !=3D "no" >> > @@ -1853,7 +1853,7 @@ builddtb: >> > echo "ERROR: FDT_DTS_FILE must be specified!"; \ >> > exit 1; \ >> > fi; \ >> > - if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} ]; then \ >> > + if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE} >> ]; then \ >> > echo "ERROR: Specified DTS file (${FDT_DTS_FILE}) does >> not \ >> > exist!"; \ >> > exit 1; \ >> > @@ -1863,9 +1863,9 @@ builddtb: >> > directory"; \ >> > fi >> > @PATH=3D${TMPPATH} \ >> > - dtc -O dtb -o \ >> > - ${DTBOUTPUTPATH}/`echo ${FDT_DTS_FILE} | cut -d. -f1`.dtb -b >> 0 \ >> > - -p 1024 ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} >> > + ${.CURDIR}/sys/tools/fdt/make_dtb.sh ${.CURDIR}/sys \ >> > + ${FDT_DTS_FILE} \ >> > + ${DTBOUTPUTPATH}/`basename ${FDT_DTS_FILE} .dts` >> > >> > ############### >> > >> > >> > Modified: head/share/mk/bsd.own.mk >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > --- head/share/mk/bsd.own.mk Fri Feb 28 18:06:00 2014 (r262613= ) >> > +++ head/share/mk/bsd.own.mk Fri Feb 28 18:29:09 2014 (r262614= ) >> > @@ -287,6 +287,7 @@ __DEFAULT_YES_OPTIONS =3D \ >> > GNU \ >> > GPIB \ >> > GPIO \ >> > + GPL_DTC \ >> > GROFF \ >> > HTML \ >> > ICONV \ >> > @@ -368,7 +369,6 @@ __DEFAULT_NO_OPTIONS =3D \ >> > CLANG_EXTRAS \ >> > CTF \ >> > DEBUG_FILES \ >> > - GPL_DTC \ >> > HESIOD \ >> > INSTALL_AS_USER \ >> > LLDB \ >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/am335x-evm.dts (from >> r262613, head/sys/boot/fdt/dts/am335x-evm.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/am335x.dtsi (from >> r262613, head/sys/boot/fdt/dts/am335x.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/bcm2835.dtsi (from >> r262613, head/sys/boot/fdt/dts/bcm2835.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone-black.dts >> (from r262613, head/sys/boot/fdt/dts/beaglebone-black.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone.dts (from >> r262613, head/sys/boot/fdt/dts/beaglebone.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard.dts (from >> r262613, head/sys/boot/fdt/dts/cubieboard.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard2.dts (from >> r262613, head/sys/boot/fdt/dts/cubieboard2.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/db78100.dts (from >> r262613, head/sys/boot/fdt/dts/db78100.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/db78460.dts (from >> r262613, head/sys/boot/fdt/dts/db78460.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5182.dts (from >> r262613, head/sys/boot/fdt/dts/db88f5182.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5281.dts (from >> r262613, head/sys/boot/fdt/dts/db88f5281.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/db88f6281.dts (from >> r262613, head/sys/boot/fdt/dts/db88f6281.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts (from >> r262613, head/sys/boot/fdt/dts/digi-ccwmx53.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/dockstar.dts (from >> r262613, head/sys/boot/fdt/dts/dockstar.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001.dts (fro= m >> r262613, head/sys/boot/fdt/dts/dreamplug-1001.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts >> (from r262613, head/sys/boot/fdt/dts/dreamplug-1001N.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/ea3250.dts (from >> r262613, head/sys/boot/fdt/dts/ea3250.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/efikamx.dts (from >> r262613, head/sys/boot/fdt/dts/efikamx.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts >> (from r262613, head/sys/boot/fdt/dts/exynos5250-arndale.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250.dtsi (from >> r262613, head/sys/boot/fdt/dts/exynos5250.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/imx51x.dtsi (from >> r262613, head/sys/boot/fdt/dts/imx51x.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/imx53-qsb.dts (from >> r262613, head/sys/boot/fdt/dts/imx53-qsb.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/imx53x.dtsi (from >> r262613, head/sys/boot/fdt/dts/imx53x.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/imx6.dtsi (from r262613= , >> head/sys/boot/fdt/dts/imx6.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p1020rdb.dts (from >> r262613, head/sys/boot/fdt/dts/p1020rdb.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p2020ds.dts (from >> r262613, head/sys/boot/fdt/dts/p2020ds.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p2041rdb.dts (from >> r262613, head/sys/boot/fdt/dts/p2041rdb.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p2041si.dtsi (from >> r262613, head/sys/boot/fdt/dts/p2041si.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p3041ds.dts (from >> r262613, head/sys/boot/fdt/dts/p3041ds.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p3041si.dtsi (from >> r262613, head/sys/boot/fdt/dts/p3041si.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p5020ds.dts (from >> r262613, head/sys/boot/fdt/dts/p5020ds.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p5020si.dtsi (from >> r262613, head/sys/boot/fdt/dts/p5020si.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/pandaboard.dts (from >> r262613, head/sys/boot/fdt/dts/pandaboard.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188-radxa.dts (from >> r262613, head/sys/boot/fdt/dts/rk3188-radxa.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188.dtsi (from >> r262613, head/sys/boot/fdt/dts/rk3188.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/rpi.dts (from r262613, >> head/sys/boot/fdt/dts/rpi.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/sheevaplug.dts (from >> r262613, head/sys/boot/fdt/dts/sheevaplug.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20-paz00.dts (from >> r262613, head/sys/boot/fdt/dts/tegra20-paz00.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20.dtsi (from >> r262613, head/sys/boot/fdt/dts/tegra20.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/trimslice.dts (from >> r262613, head/sys/boot/fdt/dts/trimslice.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/ts7800.dts (from >> r262613, head/sys/boot/fdt/dts/ts7800.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/versatilepb.dts (from >> r262613, head/sys/boot/fdt/dts/versatilepb.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts >> (from r262613, head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts (from >> r262613, head/sys/boot/fdt/dts/vybrid-cosmic.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-quartz.dts (from >> r262613, head/sys/boot/fdt/dts/vybrid-quartz.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid.dtsi (from >> r262613, head/sys/boot/fdt/dts/vybrid.dtsi) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-dual.dts (fro= m >> r262613, head/sys/boot/fdt/dts/wandboard-dual.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-quad.dts (fro= m >> r262613, head/sys/boot/fdt/dts/wandboard-quad.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-solo.dts (fro= m >> r262613, head/sys/boot/fdt/dts/wandboard-solo.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/zedboard.dts (from >> r262613, head/sys/boot/fdt/dts/zedboard.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/mips/beri-netfpga.dts (from >> r262613, head/sys/boot/fdt/dts/beri-netfpga.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/mips/beri-sim.dts (from >> r262613, head/sys/boot/fdt/dts/beri-sim.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/mips/beripad-de4.dts (from >> r262613, head/sys/boot/fdt/dts/beripad-de4.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/mips/xlp-basic.dts (from >> r262613, head/sys/boot/fdt/dts/xlp-basic.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts (fro= m >> r262613, head/sys/boot/fdt/dts/mpc8555cds.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts (from >> r262613, head/sys/boot/fdt/dts/mpc8572ds.dts) >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Modified: head/sys/conf/files >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > --- head/sys/conf/files Fri Feb 28 18:06:00 2014 (r262613= ) >> > +++ head/sys/conf/files Fri Feb 28 18:29:09 2014 (r262614= ) >> > @@ -14,11 +14,12 @@ acpi_quirks.h optional acpi >> \ >> > # from the specified source (DTS) file: .dts -> .d= tb >> > # >> > fdt_dtb_file optional fdt \ >> > - compile-with "if [ -f $S/boot/fdt/dts/${FDT_DTS_FILE} ]; then dt= c >> -O dtb -o ${FDT_DTS_FILE:R}.dtb -b 0 -p 1024 >> $S/boot/fdt/dts/${FDT_DTS_FILE}; fi" \ >> > + compile-with "sh $S/tools/fdt/make_dtb.sh $S ${FDT_DTS_FILE} >> ${.CURDIR}/${FDT_DTS_FILE:R}.dtb" \ >> > no-obj no-implicit-rule before-depend \ >> > clean "${FDT_DTS_FILE:R}.dtb" >> > fdt_static_dtb.h optional fdt fdt_dtb_static \ >> > - compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} ." \ >> > + compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} >> ${.CURDIR}" \ >> > + dependency "fdt_dtb_file" \ >> > no-obj no-implicit-rule before-depend \ >> > clean "fdt_static_dtb.h" >> > feeder_eq_gen.h optional sound >> \ >> > @@ -1370,7 +1371,7 @@ dev/fb/splash.c optional sc spla= sh >> > dev/fdt/fdt_common.c optional fdt >> > dev/fdt/fdt_slicer.c optional fdt cfi | fdt nand >> > dev/fdt/fdt_static_dtb.S optional fdt fdt_dtb_static \ >> > - dependency "$S/boot/fdt/dts/${FDT_DTS_FILE}" >> > + dependency "$S/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE}" >> > dev/fdt/simplebus.c optional fdt >> > dev/fe/if_fe.c optional fe >> > dev/fe/if_fe_pccard.c optional fe pccard >> > >> > Added: head/sys/tools/fdt/make_dtb.sh >> > >> =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > --- /dev/null 00:00:00 1970 (empty, because file is newly added) >> > +++ head/sys/tools/fdt/make_dtb.sh Fri Feb 28 18:29:09 2014 >> (r262614) >> > @@ -0,0 +1,11 @@ >> > +#!/bin/sh >> > +# >> > +# $FreeBSD$ >> > + >> > +# Script generates dtb file ($3) from dts source ($2) in build tree S >> ($1) >> > +S=3D$1 >> > +dts=3D$2 >> > +dtb=3D$3 >> > + >> > +cpp -x assembler-with-cpp -I $S/gnu/dts/include -I >> $S/boot/fdt/dts/${MACHINE} -I $S/gnu/dts/${MACHINE} -include $dts /dev/n= ull >> | >> > + dtc -O dtb -o $dtb -b 0 -p 1024 -i $S/boot/fdt/dts -i >> $S/gnu/dts/${MACHINE} >> > >> >> _______________________________________________ >> freebsd-mips@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-mips >> To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >> > > From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 11:06:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 953E6DAA for ; Mon, 3 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 67A9E932 for ; Mon, 3 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s23B6fof008426 for ; Mon, 3 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s23B6e8q008424 for freebsd-arm@FreeBSD.org; Mon, 3 Mar 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Mar 2014 11:06:40 GMT Message-Id: <201403031106.s23B6e8q008424@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 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/186823 arm icu port won't compile on Raspberry Pi o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o ports/175605 arm please fix build binutils-2.23.1 in raspberry pi 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 ports/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) 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 32 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 14:17:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C37BEBE1 for ; Mon, 3 Mar 2014 14:17:40 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 870DAD75 for ; Mon, 3 Mar 2014 14:17:40 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id lx4so933124iec.38 for ; Mon, 03 Mar 2014 06:17:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WQTdnqPXPGEIoxHa/1CyVhEXUBv8PQS62DYno1KCfMA=; b=KUmltTYaQpYAz+Exk3J2u+wJCFaOdqWhmTZPyXL8MqRRHS0UcCBluhiShWySqcIakY PGOh2mpywy6C8P4CQDeZS5oKYuiSgifloNbNmS98YKZX5QEmlo18htEkk4qqADdD0ZWa VLHjTWxCZ7bf8X8AUAxwhWCWQg5ZcEpAveeDIg0P980z1MTcTsH5/mI3n0ZuHWEZ/omA ZVb9RscWb14Zjo+lVVvWU8WkdCzCTOcQFtOVLbcnVGWrHUfLDsnS/FDJzgr4Zk9shtl/ X2ppbubvN85YN4VixXBJ7A5SRx01VeQZR/TVMu37giRFnkDSM3KfT7IzdjpR2iS+xgik yuYQ== X-Gm-Message-State: ALoCoQmrBdAiIegHUAhV8Stqpid6AH2P0eklgkJLdEE6/op1fRMb3t+Msuh752rzpGKS/aulQSIy X-Received: by 10.43.65.145 with SMTP id xm17mr26753435icb.35.1393856254039; Mon, 03 Mar 2014 06:17:34 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id u1sm39633048igm.8.2014.03.03.06.17.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 06:17:33 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc sys/conf sys/tools/fdt From: Warner Losh In-Reply-To: Date: Mon, 3 Mar 2014 07:17:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <017B0102-1A8E-4E0B-96BD-BF0213AB3B48@gmail.com> References: <201402281829.s1SITAQk019090@svn.freebsd.org> To: Ganbold Tsagaankhuu X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm , embedded@freebsd.org, mips@freebsd.org, powerpc@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:17:40 -0000 On Mar 3, 2014, at 1:44 AM, Ganbold Tsagaankhuu = wrote: > On Mon, Mar 3, 2014 at 3:40 PM, Ganbold Tsagaankhuu = wrote: >=20 >> Hi, >>=20 >> On Sat, Mar 1, 2014 at 2:38 AM, Warner Losh wrote: >>=20 >>> Greetings, >>>=20 >>> This commit changes how we do DTS -> DTB compiling. For the most = part, it >>> should be a NOP, if all my tests are good, but I may have oopsed = something >>> without realizing it. >>>=20 >>> This commit does switch us back to the GPL dtc. That cannot be = helped. The >>> BSDL one was too far away from working, but if that status ever = changes, >>> I'm >>> happy to change the defaults back. This change was discussed by most = of >>> the >>> major workers in arm@ and mips@ land before changing back, and they = felt, >>> as I do, that using vendor dts files unmodified was a bigger win for >>> embedded >>> than the regression back to a GPL'd piece of software when the = BSDL'd one >>> isn't up to the task today of coping with this new world order. If = that >>> changes, >>> then I'd be happy to switch back. >>>=20 >>> Hope this doesn't break anybody. I'll be around if it does. >>>=20 >>=20 >>=20 >> It seems crashing when building kernel for cubieboard2. >>=20 >> Part of build log: >>=20 >> -------------------------------------------------------------- >>>>> stage 3.1: making dependencies >> -------------------------------------------------------------- >> cd /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2; >> MAKEOBJDIRPREFIX=3D/usr/obj/arm.armv6 MACHINE_ARCH=3Darmv6 = MACHINE=3Darm >> CPUTYPE=3D = GROFF_BIN_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin >> = GROFF_FONT_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/groff_fo= nt >> GROFF_TMAC_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/tmac >> _SHLIBDIRPREFIX=3D/usr/obj/arm.armv6/usr/src/tmp _LDSCRIPTROOT=3D >> VERSION=3D"FreeBSD 11.0-CURRENT armv6 1100010" INSTALL=3D"sh >> /usr/src/tools/install.sh" >> = PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6/u= sr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games:= /usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/arm.armv6/usr/src/tmp/u= sr/sbin:/usr/obj/arm.armv6/usr/src/tmp/usr/bin:/usr/obj/arm.armv6/usr/src/= tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >> CC=3D"cc " CXX=3D"c++ " CPP=3D"cpp " AS=3D"as" AR=3D"ar" LD=3D"ld" = NM=3Dnm OBJDUMP=3D >> RANLIB=3Dranlib STRINGS=3D COMPILER_TYPE=3Dclang make -m = /usr/src/share/mk >> KERNEL=3Dkernel depend -DNO_MODULES_OBJ >> machine -> /usr/src/sys/arm/include >> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m = -h >> awk -f /usr/src/sys/tools/makeobjops.awk = /usr/src/sys/kern/device_if.m -h >> 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 -Wno-unused-function -nostdinc -I. >> -I/usr/src/sys -I/usr/src/sys/contrib/altq = -I/usr/src/sys/contrib/ipfilter >> -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal >> -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm >> -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb = -I/usr/src/sys/dev/cxgbe >> -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS >> -include opt_global.h -funwind-tables -mllvm -arm-enable-ehabi >> -ffreestanding /usr/src/sys/arm/arm/genassym.c >> NM=3D'nm' sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s >> awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src = -p >> awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src = -q >> awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src = -h >> sh /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys cubieboard2.dts >> /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dtb >> Segmentation fault (core dumped) >> *** Error code 139 >>=20 >> Stop. >> make: stopped in /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2 >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /usr/src >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /usr/src >> root@bsd:/usr/src # sh /usr/src/sys/tools/fdt/make_dtb.sh = /usr/src/sys >> cubieboard2.dts = /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dtb >> :158:10: fatal error: 'cubieboard2.dts' file not found >> #include "cubieboard2.dts" >> ^ >> 1 error generated. >> Segmentation fault (core dumped) >>=20 >>=20 >=20 > Sorry for the noise, I had to build kernel toolchain again, now it = works. Sounds like I should add an entry in UPDATING=85 Warner > Ganbold >=20 >=20 >=20 >>=20 >>=20 >> Ganbold >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Warner >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: Warner Losh >>>> Subject: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts >>> sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc >>> sys/conf sys/tools/fdt >>>> Date: February 28, 2014 at 11:29:10 AM MST >>>> To: src-committers@freebsd.org, svn-src-all@freebsd.org, >>> svn-src-head@freebsd.org >>>>=20 >>>> Author: imp >>>> Date: Fri Feb 28 18:29:09 2014 >>>> New Revision: 262614 >>>> URL: http://svnweb.freebsd.org/changeset/base/262614 >>>>=20 >>>> Log: >>>> Integrate device-tree upstream files into the build process: >>>> (1) Invoke cpp to bring in files via #include (although the old >>>> /include/ stuff is supported still). >>>> (2) bring in files from either vendor tree or freebsd-custom files >>>> when building. >>>> (3) move all dts* files from sys/boot/fdt/dts to >>>> sys/boot/fdt/dts/${MACHINE} as appropriate. >>>> (4) encode all the magic to do the build in = sys/tools/fdt/make_dtb.sh >>>> so that the different places in the tree use the exact same = logic. >>>> (5) switch back to gpl dtc by default. the bsdl one in the tree has >>>> significant issues not easily addressed by those unfamiliar = with >>>> the code. >>>>=20 >>>> Added: >>>> head/sys/boot/fdt/dts/arm/ >>>> head/sys/boot/fdt/dts/arm/am335x-evm.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/am335x-evm.dts >>>> head/sys/boot/fdt/dts/arm/am335x.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/am335x.dtsi >>>> head/sys/boot/fdt/dts/arm/bcm2835.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/bcm2835.dtsi >>>> head/sys/boot/fdt/dts/arm/beaglebone-black.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/beaglebone-black.dts >>>> head/sys/boot/fdt/dts/arm/beaglebone.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/beaglebone.dts >>>> head/sys/boot/fdt/dts/arm/cubieboard.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/cubieboard.dts >>>> head/sys/boot/fdt/dts/arm/cubieboard2.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/cubieboard2.dts >>>> head/sys/boot/fdt/dts/arm/db78100.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/db78100.dts >>>> head/sys/boot/fdt/dts/arm/db78460.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/db78460.dts >>>> head/sys/boot/fdt/dts/arm/db88f5182.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f5182.dts >>>> head/sys/boot/fdt/dts/arm/db88f5281.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f5281.dts >>>> head/sys/boot/fdt/dts/arm/db88f6281.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f6281.dts >>>> head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/digi-ccwmx53.dts >>>> head/sys/boot/fdt/dts/arm/dockstar.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/dockstar.dts >>>> head/sys/boot/fdt/dts/arm/dreamplug-1001.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/dreamplug-1001.dts >>>> head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/dreamplug-1001N.dts >>>> head/sys/boot/fdt/dts/arm/ea3250.dts >>>> - copied, changed from r262613, head/sys/boot/fdt/dts/ea3250.dts >>>> head/sys/boot/fdt/dts/arm/efikamx.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/efikamx.dts >>>> head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/exynos5250-arndale.dts >>>> head/sys/boot/fdt/dts/arm/exynos5250.dtsi >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/exynos5250.dtsi >>>> head/sys/boot/fdt/dts/arm/imx51x.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/imx51x.dtsi >>>> head/sys/boot/fdt/dts/arm/imx53-qsb.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/imx53-qsb.dts >>>> head/sys/boot/fdt/dts/arm/imx53x.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/imx53x.dtsi >>>> head/sys/boot/fdt/dts/arm/imx6.dtsi >>>> - copied, changed from r262613, head/sys/boot/fdt/dts/imx6.dtsi >>>> head/sys/boot/fdt/dts/arm/p1020rdb.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p1020rdb.dts >>>> head/sys/boot/fdt/dts/arm/p2020ds.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p2020ds.dts >>>> head/sys/boot/fdt/dts/arm/p2041rdb.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p2041rdb.dts >>>> head/sys/boot/fdt/dts/arm/p2041si.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p2041si.dtsi >>>> head/sys/boot/fdt/dts/arm/p3041ds.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p3041ds.dts >>>> head/sys/boot/fdt/dts/arm/p3041si.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p3041si.dtsi >>>> head/sys/boot/fdt/dts/arm/p5020ds.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p5020ds.dts >>>> head/sys/boot/fdt/dts/arm/p5020si.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p5020si.dtsi >>>> head/sys/boot/fdt/dts/arm/pandaboard.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/pandaboard.dts >>>> head/sys/boot/fdt/dts/arm/rk3188-radxa.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/rk3188-radxa.dts >>>> head/sys/boot/fdt/dts/arm/rk3188.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/rk3188.dtsi >>>> head/sys/boot/fdt/dts/arm/rpi.dts >>>> - copied, changed from r262613, head/sys/boot/fdt/dts/rpi.dts >>>> head/sys/boot/fdt/dts/arm/sheevaplug.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/sheevaplug.dts >>>> head/sys/boot/fdt/dts/arm/tegra20-paz00.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/tegra20-paz00.dts >>>> head/sys/boot/fdt/dts/arm/tegra20.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/tegra20.dtsi >>>> head/sys/boot/fdt/dts/arm/trimslice.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/trimslice.dts >>>> head/sys/boot/fdt/dts/arm/ts7800.dts >>>> - copied, changed from r262613, head/sys/boot/fdt/dts/ts7800.dts >>>> head/sys/boot/fdt/dts/arm/versatilepb.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/versatilepb.dts >>>> head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts >>>> head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/vybrid-cosmic.dts >>>> head/sys/boot/fdt/dts/arm/vybrid-quartz.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/vybrid-quartz.dts >>>> head/sys/boot/fdt/dts/arm/vybrid.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/vybrid.dtsi >>>> head/sys/boot/fdt/dts/arm/wandboard-dual.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/wandboard-dual.dts >>>> head/sys/boot/fdt/dts/arm/wandboard-quad.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/wandboard-quad.dts >>>> head/sys/boot/fdt/dts/arm/wandboard-solo.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/wandboard-solo.dts >>>> head/sys/boot/fdt/dts/arm/zedboard.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/zedboard.dts >>>> head/sys/boot/fdt/dts/mips/ >>>> head/sys/boot/fdt/dts/mips/beri-netfpga.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/beri-netfpga.dts >>>> head/sys/boot/fdt/dts/mips/beri-sim.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/beri-sim.dts >>>> head/sys/boot/fdt/dts/mips/beripad-de4.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/beripad-de4.dts >>>> head/sys/boot/fdt/dts/mips/xlp-basic.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/xlp-basic.dts >>>> head/sys/boot/fdt/dts/powerpc/ >>>> head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/mpc8555cds.dts >>>> head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/mpc8572ds.dts >>>> head/sys/tools/fdt/make_dtb.sh (contents, props changed) >>>> Deleted: >>>> head/sys/boot/fdt/dts/am335x-evm.dts >>>> head/sys/boot/fdt/dts/am335x.dtsi >>>> head/sys/boot/fdt/dts/bcm2835.dtsi >>>> head/sys/boot/fdt/dts/beaglebone-black.dts >>>> head/sys/boot/fdt/dts/beaglebone.dts >>>> head/sys/boot/fdt/dts/beri-netfpga.dts >>>> head/sys/boot/fdt/dts/beri-sim.dts >>>> head/sys/boot/fdt/dts/beripad-de4.dts >>>> head/sys/boot/fdt/dts/cubieboard.dts >>>> head/sys/boot/fdt/dts/cubieboard2.dts >>>> head/sys/boot/fdt/dts/db78100.dts >>>> head/sys/boot/fdt/dts/db78460.dts >>>> head/sys/boot/fdt/dts/db88f5182.dts >>>> head/sys/boot/fdt/dts/db88f5281.dts >>>> head/sys/boot/fdt/dts/db88f6281.dts >>>> head/sys/boot/fdt/dts/digi-ccwmx53.dts >>>> head/sys/boot/fdt/dts/dockstar.dts >>>> head/sys/boot/fdt/dts/dreamplug-1001.dts >>>> head/sys/boot/fdt/dts/dreamplug-1001N.dts >>>> head/sys/boot/fdt/dts/ea3250.dts >>>> head/sys/boot/fdt/dts/efikamx.dts >>>> head/sys/boot/fdt/dts/exynos5250-arndale.dts >>>> head/sys/boot/fdt/dts/exynos5250.dtsi >>>> head/sys/boot/fdt/dts/imx51x.dtsi >>>> head/sys/boot/fdt/dts/imx53-qsb.dts >>>> head/sys/boot/fdt/dts/imx53x.dtsi >>>> head/sys/boot/fdt/dts/imx6.dtsi >>>> head/sys/boot/fdt/dts/mpc8555cds.dts >>>> head/sys/boot/fdt/dts/mpc8572ds.dts >>>> head/sys/boot/fdt/dts/p1020rdb.dts >>>> head/sys/boot/fdt/dts/p2020ds.dts >>>> head/sys/boot/fdt/dts/p2041rdb.dts >>>> head/sys/boot/fdt/dts/p2041si.dtsi >>>> head/sys/boot/fdt/dts/p3041ds.dts >>>> head/sys/boot/fdt/dts/p3041si.dtsi >>>> head/sys/boot/fdt/dts/p5020ds.dts >>>> head/sys/boot/fdt/dts/p5020si.dtsi >>>> head/sys/boot/fdt/dts/pandaboard.dts >>>> head/sys/boot/fdt/dts/rk3188-radxa.dts >>>> head/sys/boot/fdt/dts/rk3188.dtsi >>>> head/sys/boot/fdt/dts/rpi.dts >>>> head/sys/boot/fdt/dts/sheevaplug.dts >>>> head/sys/boot/fdt/dts/tegra20-paz00.dts >>>> head/sys/boot/fdt/dts/tegra20.dtsi >>>> head/sys/boot/fdt/dts/trimslice.dts >>>> head/sys/boot/fdt/dts/ts7800.dts >>>> head/sys/boot/fdt/dts/versatilepb.dts >>>> head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts >>>> head/sys/boot/fdt/dts/vybrid-cosmic.dts >>>> head/sys/boot/fdt/dts/vybrid-quartz.dts >>>> head/sys/boot/fdt/dts/vybrid.dtsi >>>> head/sys/boot/fdt/dts/wandboard-dual.dts >>>> head/sys/boot/fdt/dts/wandboard-quad.dts >>>> head/sys/boot/fdt/dts/wandboard-solo.dts >>>> head/sys/boot/fdt/dts/xlp-basic.dts >>>> head/sys/boot/fdt/dts/zedboard.dts >>>> Modified: >>>> head/Makefile.inc1 >>>> head/share/mk/bsd.own.mk >>>> head/sys/conf/files >>>>=20 >>>> Modified: head/Makefile.inc1 >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- head/Makefile.inc1 Fri Feb 28 18:06:00 2014 = (r262613) >>>> +++ head/Makefile.inc1 Fri Feb 28 18:29:09 2014 = (r262614) >>>> @@ -1262,7 +1262,7 @@ _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/ >>>> lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge >>>> .endif >>>>=20 >>>> -# Default to building the BSDL DTC, but build the GPL one if users >>> explicitly >>>> +# Default to building the GPL DTC, but build the BSDL one if users >>> explicitly >>>> # request it. >>>> _dtc=3D usr.bin/dtc >>>> .if ${MK_GPL_DTC} !=3D "no" >>>> @@ -1853,7 +1853,7 @@ builddtb: >>>> echo "ERROR: FDT_DTS_FILE must be specified!"; \ >>>> exit 1; \ >>>> fi; \ >>>> - if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} ]; then = \ >>>> + if [ ! -f = ${.CURDIR}/sys/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE} >>> ]; then \ >>>> echo "ERROR: Specified DTS file (${FDT_DTS_FILE}) does >>> not \ >>>> exist!"; \ >>>> exit 1; \ >>>> @@ -1863,9 +1863,9 @@ builddtb: >>>> directory"; \ >>>> fi >>>> @PATH=3D${TMPPATH} \ >>>> - dtc -O dtb -o \ >>>> - ${DTBOUTPUTPATH}/`echo ${FDT_DTS_FILE} | cut -d. -f1`.dtb = -b >>> 0 \ >>>> - -p 1024 ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} >>>> + ${.CURDIR}/sys/tools/fdt/make_dtb.sh ${.CURDIR}/sys \ >>>> + ${FDT_DTS_FILE} \ >>>> + ${DTBOUTPUTPATH}/`basename ${FDT_DTS_FILE} .dts` >>>>=20 >>>> ############### >>>>=20 >>>>=20 >>>> Modified: head/share/mk/bsd.own.mk >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- head/share/mk/bsd.own.mk Fri Feb 28 18:06:00 2014 = (r262613) >>>> +++ head/share/mk/bsd.own.mk Fri Feb 28 18:29:09 2014 = (r262614) >>>> @@ -287,6 +287,7 @@ __DEFAULT_YES_OPTIONS =3D \ >>>> GNU \ >>>> GPIB \ >>>> GPIO \ >>>> + GPL_DTC \ >>>> GROFF \ >>>> HTML \ >>>> ICONV \ >>>> @@ -368,7 +369,6 @@ __DEFAULT_NO_OPTIONS =3D \ >>>> CLANG_EXTRAS \ >>>> CTF \ >>>> DEBUG_FILES \ >>>> - GPL_DTC \ >>>> HESIOD \ >>>> INSTALL_AS_USER \ >>>> LLDB \ >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/am335x-evm.dts (from >>> r262613, head/sys/boot/fdt/dts/am335x-evm.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/am335x.dtsi (from >>> r262613, head/sys/boot/fdt/dts/am335x.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/bcm2835.dtsi (from >>> r262613, head/sys/boot/fdt/dts/bcm2835.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone-black.dts >>> (from r262613, head/sys/boot/fdt/dts/beaglebone-black.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone.dts (from >>> r262613, head/sys/boot/fdt/dts/beaglebone.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard.dts (from >>> r262613, head/sys/boot/fdt/dts/cubieboard.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard2.dts = (from >>> r262613, head/sys/boot/fdt/dts/cubieboard2.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/db78100.dts (from >>> r262613, head/sys/boot/fdt/dts/db78100.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/db78460.dts (from >>> r262613, head/sys/boot/fdt/dts/db78460.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/db88f5182.dts (from >>> r262613, head/sys/boot/fdt/dts/db88f5182.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/db88f5281.dts (from >>> r262613, head/sys/boot/fdt/dts/db88f5281.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/db88f6281.dts (from >>> r262613, head/sys/boot/fdt/dts/db88f6281.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts = (from >>> r262613, head/sys/boot/fdt/dts/digi-ccwmx53.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/dockstar.dts (from >>> r262613, head/sys/boot/fdt/dts/dockstar.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001.dts = (from >>> r262613, head/sys/boot/fdt/dts/dreamplug-1001.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts >>> (from r262613, head/sys/boot/fdt/dts/dreamplug-1001N.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/ea3250.dts (from >>> r262613, head/sys/boot/fdt/dts/ea3250.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/efikamx.dts (from >>> r262613, head/sys/boot/fdt/dts/efikamx.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: = head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts >>> (from r262613, head/sys/boot/fdt/dts/exynos5250-arndale.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250.dtsi = (from >>> r262613, head/sys/boot/fdt/dts/exynos5250.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/imx51x.dtsi (from >>> r262613, head/sys/boot/fdt/dts/imx51x.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/imx53-qsb.dts (from >>> r262613, head/sys/boot/fdt/dts/imx53-qsb.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/imx53x.dtsi (from >>> r262613, head/sys/boot/fdt/dts/imx53x.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/imx6.dtsi (from = r262613, >>> head/sys/boot/fdt/dts/imx6.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p1020rdb.dts (from >>> r262613, head/sys/boot/fdt/dts/p1020rdb.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p2020ds.dts (from >>> r262613, head/sys/boot/fdt/dts/p2020ds.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p2041rdb.dts (from >>> r262613, head/sys/boot/fdt/dts/p2041rdb.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p2041si.dtsi (from >>> r262613, head/sys/boot/fdt/dts/p2041si.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p3041ds.dts (from >>> r262613, head/sys/boot/fdt/dts/p3041ds.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p3041si.dtsi (from >>> r262613, head/sys/boot/fdt/dts/p3041si.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p5020ds.dts (from >>> r262613, head/sys/boot/fdt/dts/p5020ds.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p5020si.dtsi (from >>> r262613, head/sys/boot/fdt/dts/p5020si.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/pandaboard.dts (from >>> r262613, head/sys/boot/fdt/dts/pandaboard.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/rk3188-radxa.dts = (from >>> r262613, head/sys/boot/fdt/dts/rk3188-radxa.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/rk3188.dtsi (from >>> r262613, head/sys/boot/fdt/dts/rk3188.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/rpi.dts (from = r262613, >>> head/sys/boot/fdt/dts/rpi.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/sheevaplug.dts (from >>> r262613, head/sys/boot/fdt/dts/sheevaplug.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/tegra20-paz00.dts = (from >>> r262613, head/sys/boot/fdt/dts/tegra20-paz00.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/tegra20.dtsi (from >>> r262613, head/sys/boot/fdt/dts/tegra20.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/trimslice.dts (from >>> r262613, head/sys/boot/fdt/dts/trimslice.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/ts7800.dts (from >>> r262613, head/sys/boot/fdt/dts/ts7800.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/versatilepb.dts = (from >>> r262613, head/sys/boot/fdt/dts/versatilepb.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: = head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts >>> (from r262613, head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts = (from >>> r262613, head/sys/boot/fdt/dts/vybrid-cosmic.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-quartz.dts = (from >>> r262613, head/sys/boot/fdt/dts/vybrid-quartz.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/vybrid.dtsi (from >>> r262613, head/sys/boot/fdt/dts/vybrid.dtsi) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-dual.dts = (from >>> r262613, head/sys/boot/fdt/dts/wandboard-dual.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-quad.dts = (from >>> r262613, head/sys/boot/fdt/dts/wandboard-quad.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-solo.dts = (from >>> r262613, head/sys/boot/fdt/dts/wandboard-solo.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/zedboard.dts (from >>> r262613, head/sys/boot/fdt/dts/zedboard.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/mips/beri-netfpga.dts = (from >>> r262613, head/sys/boot/fdt/dts/beri-netfpga.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/mips/beri-sim.dts (from >>> r262613, head/sys/boot/fdt/dts/beri-sim.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/mips/beripad-de4.dts = (from >>> r262613, head/sys/boot/fdt/dts/beripad-de4.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/mips/xlp-basic.dts (from >>> r262613, head/sys/boot/fdt/dts/xlp-basic.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts = (from >>> r262613, head/sys/boot/fdt/dts/mpc8555cds.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts = (from >>> r262613, head/sys/boot/fdt/dts/mpc8572ds.dts) >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Modified: head/sys/conf/files >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- head/sys/conf/files Fri Feb 28 18:06:00 2014 = (r262613) >>>> +++ head/sys/conf/files Fri Feb 28 18:29:09 2014 = (r262614) >>>> @@ -14,11 +14,12 @@ acpi_quirks.h optional acpi >>> \ >>>> # from the specified source (DTS) file: .dts -> = .dtb >>>> # >>>> fdt_dtb_file optional fdt \ >>>> - compile-with "if [ -f $S/boot/fdt/dts/${FDT_DTS_FILE} ]; then = dtc >>> -O dtb -o ${FDT_DTS_FILE:R}.dtb -b 0 -p 1024 >>> $S/boot/fdt/dts/${FDT_DTS_FILE}; fi" \ >>>> + compile-with "sh $S/tools/fdt/make_dtb.sh $S ${FDT_DTS_FILE} >>> ${.CURDIR}/${FDT_DTS_FILE:R}.dtb" \ >>>> no-obj no-implicit-rule before-depend \ >>>> clean "${FDT_DTS_FILE:R}.dtb" >>>> fdt_static_dtb.h optional fdt fdt_dtb_static \ >>>> - compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} ." = \ >>>> + compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} >>> ${.CURDIR}" \ >>>> + dependency "fdt_dtb_file" \ >>>> no-obj no-implicit-rule before-depend \ >>>> clean "fdt_static_dtb.h" >>>> feeder_eq_gen.h optional sound >>> \ >>>> @@ -1370,7 +1371,7 @@ dev/fb/splash.c optional sc = splash >>>> dev/fdt/fdt_common.c optional fdt >>>> dev/fdt/fdt_slicer.c optional fdt cfi | fdt nand >>>> dev/fdt/fdt_static_dtb.S optional fdt fdt_dtb_static \ >>>> - dependency "$S/boot/fdt/dts/${FDT_DTS_FILE}" >>>> + dependency "$S/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE}" >>>> dev/fdt/simplebus.c optional fdt >>>> dev/fe/if_fe.c optional fe >>>> dev/fe/if_fe_pccard.c optional fe pccard >>>>=20 >>>> Added: head/sys/tools/fdt/make_dtb.sh >>>>=20 >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- /dev/null 00:00:00 1970 (empty, because file is newly added) >>>> +++ head/sys/tools/fdt/make_dtb.sh Fri Feb 28 18:29:09 2014 >>> (r262614) >>>> @@ -0,0 +1,11 @@ >>>> +#!/bin/sh >>>> +# >>>> +# $FreeBSD$ >>>> + >>>> +# Script generates dtb file ($3) from dts source ($2) in build = tree S >>> ($1) >>>> +S=3D$1 >>>> +dts=3D$2 >>>> +dtb=3D$3 >>>> + >>>> +cpp -x assembler-with-cpp -I $S/gnu/dts/include -I >>> $S/boot/fdt/dts/${MACHINE} -I $S/gnu/dts/${MACHINE} -include $dts = /dev/null >>> | >>>> + dtc -O dtb -o $dtb -b 0 -p 1024 -i $S/boot/fdt/dts -i >>> $S/gnu/dts/${MACHINE} >>>>=20 >>>=20 >>> _______________________________________________ >>> freebsd-mips@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-mips >>> To unsubscribe, send any mail to = "freebsd-mips-unsubscribe@freebsd.org" >>>=20 >>=20 >>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 15:20:00 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1BA164E for ; Mon, 3 Mar 2014 15:20:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 943B9328 for ; Mon, 3 Mar 2014 15:20:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s23FK06O088942 for ; Mon, 3 Mar 2014 15:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s23FK0gV088941; Mon, 3 Mar 2014 15:20:00 GMT (envelope-from gnats) Resent-Date: Mon, 3 Mar 2014 15:20:00 GMT Resent-Message-Id: <201403031520.s23FK0gV088941@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, Svatopluk Kraus Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3659151F for ; Mon, 3 Mar 2014 15:14:51 +0000 (UTC) Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 227C72FF for ; Mon, 3 Mar 2014 15:14:51 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s23FEoNe083769 for ; Mon, 3 Mar 2014 15:14:50 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s23FEoUS083764; Mon, 3 Mar 2014 15:14:50 GMT (envelope-from nobody) Message-Id: <201403031514.s23FEoUS083764@cgiserv.freebsd.org> Date: Mon, 3 Mar 2014 15:14:50 GMT From: Svatopluk Kraus To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/187223: omap4 clock frequency computation overflow X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:20:00 -0000 >Number: 187223 >Category: arm >Synopsis: omap4 clock frequency computation overflow >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 Mar 03 15:20:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Svatopluk Kraus >Release: FreeBSD 11.0-CURRENT >Organization: >Environment: Pandaboard ES >Description: uint32_t is not enough. See patch. >How-To-Repeat: >Fix: Patch attached with submission follows: Index: sys/arm/ti/omap4/omap4_prcm_clks.c =================================================================== --- sys/arm/ti/omap4/omap4_prcm_clks.c (revision 262153) +++ sys/arm/ti/omap4/omap4_prcm_clks.c (working copy) @@ -984,13 +984,11 @@ pll_mult = ((clksel >> 8) & 0x7ff); pll_div = (clksel & 0x7f) + 1; - /* Get the system clock freq */ omap4_clk_get_sysclk_freq(NULL, &sysclk); - /* Calculate the MPU freq */ - mpuclk = (sysclk * pll_mult) / pll_div; + mpuclk = ((uint64_t)sysclk * pll_mult) / pll_div; /* Return the value */ if (freq) >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Mon Mar 3 16:12:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D89E225 for ; Mon, 3 Mar 2014 16:12:20 +0000 (UTC) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EA09A71 for ; Mon, 3 Mar 2014 16:12:20 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id 63so11849755qgz.6 for ; Mon, 03 Mar 2014 08:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DpAXIWoD3mEAmJRB1T2sVyx8KKm4FiCvD5MY9ezkihc=; b=TGm8gmO/8r/RbcJRasPUwHO67BCE/u6wzW5fLwzoGAh3Cmw6LpPxFoQLg7Hr8AIYOJ Fxi9178twMRX69RAlKsLtKDtuJGouhMhcz74YKQgheOs0cvRnMVXu9i0YCqR9GG7wVRx hRzQCt0mTjGmbliz8Qphef/nLgfj9Uf/u0zv2EgZOos7VNoLEqCYKQ7AeQhoBn3yhLoy OpMcKjGbYTC71Gudluz4z8kQu4IKGqlHMnyc9bgctMByNqlJC/IwQncrS31TLfUlqpV+ tt+XL4Q1rTh+J55XOxsOJt/PvBvLFZtvKzIdXH4t/kPuqFvtlVXmWSdA4wV3tj54zzMx O+Cw== MIME-Version: 1.0 X-Received: by 10.140.109.72 with SMTP id k66mr23488452qgf.20.1393863139418; Mon, 03 Mar 2014 08:12:19 -0800 (PST) Received: by 10.140.31.69 with HTTP; Mon, 3 Mar 2014 08:12:19 -0800 (PST) Date: Mon, 3 Mar 2014 17:12:19 +0100 Message-ID: Subject: Pandaboard ES and SD card From: Svatopluk Kraus To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 16:12:20 -0000 Hi, I finally have found time to install FreeBSD 11.0-CURRENT on Pandaboard ES on my table. It's been installed to SD card. When I boot to multiuser, it's very very slow. It looks that SD card write performance is very poor. When I boot to singleuser, it's OK. However, when I make root filesystem read-write by one command and immediately readonly by second one, the second one takes a few minutes to finish. When I've digged in arm/ti/ti_mmchs.s, I've got following times for READ and WRITE commands: typical read times (start & duration & command), ... [1393858258.909d4fb4650dcb70] [0.002f97afec8ba994] READ [1393858258.929795e2f7db5ec0] [0.002f90d496ec7d4c] READ [1393858258.9492673f18af4ec0] [0.002f9d607a66e41c] READ [1393858258.968d155674da0d5e] [0.002f937e2ea37cca] READ [1393858258.988790d78e6fd5a2] [0.002f9eb09b235414] READ [1393858258.9a78744ecab1413e] [0.002f90dded2a9cda] READ [1393858258.9c735a3cec62b616] [0.002f97cbef46083e] READ [1393858258.9e6ee0b8064ec2aa] [0.002f933cd2f09fe8] READ [1393858258.a069e2838966634a] [0.002f959262788368] READ [1393858258.a26467518add9a00] [0.002f8f9722ac4c70] READ [1393858258.a45e59f14fb6c986] [0.002f9d31cb304656] READ [1393858258.a659525d3e70bc98] [0.002f8ae2ad5e65e2] READ [1393858258.a853df0c0452931e] [0.002f9cd46cc30aca] READ ... typical write times (start & duration & command). ... [1393856255.8be604dff29d07a0] [0.00d9cf712d331d58] WRITE [1393856255.8e9100859c4fedd2] [0.00da3f856cebe4e6] WRITE [1393856255.913c1530607b6288] [0.00da8f1a826cd93a] WRITE [1393856255.93e7b97bcc483d9a] [0.00dad6ced3832dbe] WRITE [1393856255.9693e68c8a1752c0] [0.2276ea0a1d732724] WRITE <- [1393856255.badca6f90c5564ea] [0.22df71f44f623e3e] WRITE <- [1393856255.df8e42a6890234a4] [0.24ae2f1172203ed0] WRITE <- [1393856256.060e4c7acd0c290a] [0.00e76cb09c67c3ba] WRITE [1393856256.08c68da8b0554498] [0.00e7b1d75881776a] WRITE [1393856256.0b7f57d3eb15578e] [0.00e83c08cdfa8020] WRITE [1393856256.0e36d38be88f1e08] [0.00e882dd093ddf54] WRITE [1393856256.10f0762d8d8cbe10] [0.00e8c0f06a43a968] WRITE [1393856256.13aa6a2dc9ef5c9a] [0.00e938916637f4c8] WRITE [1393856256.1664fc08109773d4] [0.22b74fce5c0401e2] WRITE <- [1393856256.3aedb9baa4273c8e] [0.2305517892cef37c] WRITE <- [1393856256.5fc52a62081f2238] [0.24aaf338d2067a84] WRITE <- [1393856256.8641d9129fd99066] [0.00e770cfadd3b168] WRITE [1393856256.88fae819e4c25a9c] [0.04d7472f5f571cbc] WRITE ... Times are struct bintime printed in %lld.%016llx (sec.frac) format. Writing times have got really big variation. Any idea or experience? Svatopluk Kraus PS. Of course, I don't mention occasional "Spurious interrupt detected" print. From owner-freebsd-arm@FreeBSD.ORG Tue Mar 4 06:06:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27FFAFD0; Tue, 4 Mar 2014 06:06:02 +0000 (UTC) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FDDD375; Tue, 4 Mar 2014 06:06:01 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id 6so72137bkj.13 for ; Mon, 03 Mar 2014 22:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tVdIUYm5kt+YkZnrRacL1NYu17ePDQ7GXK52gXApz7g=; b=JGLrmJsQ3dtGliR+P3ATx8jVkPsJ3S//bhPK6YYS18CMzGrtpqgeXxTHbei7/kKsLr DddGISsDboav4zJjseL7Gg4gIzqKV99tp3BvfYGhgAlK645At6hGfHVoP6wBqBJ6JIEg LW+WkkFTF730J7Z5CN9pPWek9DkI1vo4bq4MQpRDFqQpKFo44UQQGk2xHtMOS21RY3OK YIv5nqmkFjV2GJ06M2+9g/dRCfiG/yLgf1/Oq7yMuocPNr+lHmCpGdkBicZ2YCJmyehs Pb+3hoR1AtnvnZe2aobmFeFDoUK0Fuh4sWFpYYfK38KHIYdNpH0uw1Qc2i34dWU0LR6b u1wA== MIME-Version: 1.0 X-Received: by 10.204.62.5 with SMTP id v5mr85191bkh.46.1393913159443; Mon, 03 Mar 2014 22:05:59 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.205.71.201 with HTTP; Mon, 3 Mar 2014 22:05:59 -0800 (PST) In-Reply-To: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> Date: Tue, 4 Mar 2014 01:05:59 -0500 X-Google-Sender-Auth: YT_NCq_RQT_IPHoqb53emVfKswk Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 06:06:02 -0000 On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh wrote: > > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: > > > Hi, > > > > The attached patch (fdt_probe_order_control.patch) allows control over > the > > probe order of simplebus child devices by using a "probe-order" property > in > > simplebus child nodes in the .dts file > > Where is the probe-order property defined? I can't seem to find it in the > bindings. > Also, I don't think it is necessary. This is a software construct, so > doesn't really > belong in the dts file. I'd really like to avoid FreeBSD specific hacks in > the DTS > files. > It is currently not in any bindings, and has the status of being something of my own invention and something possibly not ever used outside of private codebases. I think this is something that would fit conceptually with the miscellaneous bindings defined in ePAPR, as it is a rather generic property. As to this being a software construct, I appreciate and support the goal of keeping DTS files as pure hardware descriptions (and I'd also argue that the way the status property is sometimes used turns it into a software construct). Let's completely avoid the issue of am I arguing for adding a software construct to DTS files by looking at this another way. Instead of a 'probe-order' property that specifies a sort key, I could have the same quality of result (same warts and all, as discussed below) with a property that indicates whether the device is hardwired or has some sort of pluggable interface (a property, say, called 'pluggable'). That would be a pure hardware-as-it-is-designed description, and having that information would allow me to do a sort that orders non-pluggable ahead of pluggable in the probe/attach process. > > > This was motivated by booting FreeBSD from the eMMC on a BeagleBone > Black, > > which has a pluggable microSD card slot in addition to the eMMC. The > order > > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes the > > pluggable slot to be probed/attached first, so the device name assigned > to > > the eMMC soldered to the board changes depending on whether there is a > card > > in the pluggable slot, which makes establishing appropriate /etc/fstab > > contents less than convenient. > > Sounds like you'd like to have some sort of name to instance mapping. > The typical way this is solved is by naming the partitions so that ordering > doesn't matter. Even if you don't handle this at the filesystem level, > which > is how others cope, you'd want this to be more of a direct binding rather > than an > ordering so that you get the effect you want (constant name) directly, > rather > than as a side-effect of ordering. > Yes, ideally I'd like to be able to assign a name to every MMC/SD card slot (hardwired or otherwise) in a system that depends only on the physical location of that slot, and be able to resolve that name to an mmcsd device instance. This works-here-side-effect-based approach is a result of the ideal solution seemingly not being within reach given the available resources. Using partition naming/glabel is a fair point, and does address the /etc/fstab issue, but it still leaves me short of being able to construct a product function that relies on knowing what's where when there is no partitioning/filesystem in place, for example, something that boils down to 'dd this image to the eMMC [or to the card in the card slot]'. Perhaps the answer to that is to build something using devinfo(3)/devd(8) to identify what mmcsdX is currently attached to each controller when I need to know. > If you insist on that, then having a something more like > "freesbd,unit-number" > property would also accomplish this. But that would only wire the > controller unit > number, and not the resulting mmcsdX device. > I understand fully that the utility of this goes as far as having none of the hardwired devices sharing controllers with pluggable devices in such a way that the controllers can find the attached pluggable devices first. Subject to that limitation as it is, this does usefully apply to at least one real system now, and it is a behavior I can take advantage of when designing new hardware to make developing the associated FreeBSD-based product software easier (namely, by not having to cobble together a poor-man's udev [which is not saying users of udev are exactly rich], and/or worry about how a customer might label the fat partition on an SD card they insert). More generally, whether this is or isn't a widely useful thing in the end, what is the current process for introducing a new property for use in DTS files? > > By using the "probe-order" property in > > sys/boot/fdt/dts/beaglebone-black.dts (see attached > > beaglebone_black_mmc_probe_order.patch), I am able to swap the order in > > which the mmc units are probed/attached for that board. This avoids > > inappropriate hacking of the mmc definition order in am335x.dtsi, which > is > > shared among multiple boards. > > > > This is not a general solution to the problem of wanting stable device > > names for hard-wired MMC devices when pluggable slots are present in the > > system. There could, for example, be a multi-slot MMC controller with a > > mixture of hard-wired and pluggable devices attached, and this would not > > address that case. However, it does address the needs of BeagleBone > Black, > > and the mechanism may be of use for similar issues on other platforms. > > As it isn't a generic solution, I'd be biased against adopting it. What's > wrong > with using glabel to accomplish this (either with a label specific > property, or > by using a ufs label and mounting /dev/ufs/foo). > > It is not my intention to lobby for adding this to the kernel at this point. Whether it is widely-enough or only very-narrowly useful I would say is currently unknown. My intention in posting this patch was for others on the list(s) that might find it useful to see it and have access to it, and to attract thoughtful criticism such as yours. I appreciate you taking the time to respond. -Patrick From owner-freebsd-arm@FreeBSD.ORG Tue Mar 4 10:31:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FE3425D for ; Tue, 4 Mar 2014 10:31:04 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 26E19EFD for ; Tue, 4 Mar 2014 10:31:04 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id uy5so4834496obc.34 for ; Tue, 04 Mar 2014 02:31:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WjXKMXj8SCjao2BuUKi1QVCm/DXexv4lBMZXsfSEzls=; b=pXLtM+2Gr/Sn9VsVQgQJBPeceYpXX5JIys3FP0C937FjkzHDpgajtfB8E4hLKZkeCs kp0NuAZH6zlfmPJ6Vs/fy1q5LBB8JRwlmp63UzxpOiqy+uKwjtsMzvhI/zwZ9T+l+/sm enYEKXjWUtzIPomDMRDTDqAq7pZ4UdM/yf1RDzLmy+8QjI30XUJWpzF/9YyaQ4MI9aK8 zit2JhWMyhllBgycajZ0Dwu7G1n0CJBMTK2IUM1YpSZs7ce5U78OUciMd7K8gkGlBn8/ HyxdD+e1EmfJFRZAYkpO9fGuh+PR+V6Aznd2KIiiEQBBURIvTdfRX/0VGFc09dPb/dl0 UPgw== X-Received: by 10.60.141.105 with SMTP id rn9mr4303949oeb.27.1393929063382; Tue, 04 Mar 2014 02:31:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.194 with HTTP; Tue, 4 Mar 2014 02:30:33 -0800 (PST) In-Reply-To: <20140303061136.GB85204@zibbi.meraka.csir.co.za> References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> From: Jia-Shiun Li Date: Tue, 4 Mar 2014 18:30:33 +0800 Message-ID: Subject: Re: TMPFS in kernels To: John Hay Content-Type: text/plain; charset=UTF-8 Cc: George Rosamond , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 10:31:04 -0000 On Mon, Mar 3, 2014 at 2:11 PM, John Hay wrote: > Our embedded systems also use compact flash disks mounted ro. We have > been (ab)using the nice etc/rc.initdiskless and etc/rc.d/var scripts > by just having an etc/diskless and populated conf/base and conf/defaults > directories. But it seems those scripts just work with md devices. I remember hacking it a while ago to adopt tmpfs instead on my pxeboot test environment. It only requires changing the line mdmfs mounting md to 'mount -t tmpfs' (plus mount options), and everything else will work as usual. -Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Tue Mar 4 13:21:28 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB69B40; Tue, 4 Mar 2014 13:21:28 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDC5E398; Tue, 4 Mar 2014 13:21:27 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WKpHd-000F1l-5E; Tue, 04 Mar 2014 13:21:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s24DLHnf048013; Tue, 4 Mar 2014 06:21:17 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19j/00SiHz8tybK9XhxlVbs Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Ian Lepore To: Patrick Kelsey In-Reply-To: References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Mar 2014 06:21:17 -0700 Message-ID: <1393939277.1149.300.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@FreeBSD.org, freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 13:21:28 -0000 On Tue, 2014-03-04 at 01:05 -0500, Patrick Kelsey wrote: > On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh wrote: > > > > > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: > > > > > Hi, > > > > > > The attached patch (fdt_probe_order_control.patch) allows control over > > the > > > probe order of simplebus child devices by using a "probe-order" property > > in > > > simplebus child nodes in the .dts file > > > > Where is the probe-order property defined? I can't seem to find it in the > > bindings. > > Also, I don't think it is necessary. This is a software construct, so > > doesn't really > > belong in the dts file. I'd really like to avoid FreeBSD specific hacks in > > the DTS > > files. > > > > It is currently not in any bindings, and has the status of being something > of my own invention and something possibly not ever used outside of private > codebases. I think this is something that would fit conceptually with the > miscellaneous bindings defined in ePAPR, as it is a rather generic > property. As to this being a software construct, I appreciate and support > the goal of keeping DTS files as pure hardware descriptions (and I'd also > argue that the way the status property is sometimes used turns it into a > software construct). > > Let's completely avoid the issue of am I arguing for adding a software > construct to DTS files by looking at this another way. Instead of a > 'probe-order' property that specifies a sort key, I could have the same > quality of result (same warts and all, as discussed below) with a property > that indicates whether the device is hardwired or has some sort of > pluggable interface (a property, say, called 'pluggable'). That would be a > pure hardware-as-it-is-designed description, and having that information > would allow me to do a sort that orders non-pluggable ahead of pluggable in > the probe/attach process. > > > > > > > This was motivated by booting FreeBSD from the eMMC on a BeagleBone > > Black, > > > which has a pluggable microSD card slot in addition to the eMMC. The > > order > > > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes the > > > pluggable slot to be probed/attached first, so the device name assigned > > to > > > the eMMC soldered to the board changes depending on whether there is a > > card > > > in the pluggable slot, which makes establishing appropriate /etc/fstab > > > contents less than convenient. > > > > Sounds like you'd like to have some sort of name to instance mapping. > > The typical way this is solved is by naming the partitions so that ordering > > doesn't matter. Even if you don't handle this at the filesystem level, > > which > > is how others cope, you'd want this to be more of a direct binding rather > > than an > > ordering so that you get the effect you want (constant name) directly, > > rather > > than as a side-effect of ordering. > > > > Yes, ideally I'd like to be able to assign a name to every MMC/SD card slot > (hardwired or otherwise) in a system that depends only on the physical > location of that slot, and be able to resolve that name to an mmcsd device > instance. This works-here-side-effect-based approach is a result of the > ideal solution seemingly not being within reach given the available > resources. Using partition naming/glabel is a fair point, and does address > the /etc/fstab issue, but it still leaves me short of being able to > construct a product function that relies on knowing what's where when there > is no partitioning/filesystem in place, for example, something that boils > down to 'dd this image to the eMMC [or to the card in the card slot]'. > Perhaps the answer to that is to build something using devinfo(3)/devd(8) > to identify what mmcsdX is currently attached to each controller when I > need to know. > > > > If you insist on that, then having a something more like > > "freesbd,unit-number" > > property would also accomplish this. But that would only wire the > > controller unit > > number, and not the resulting mmcsdX device. > > > > I understand fully that the utility of this goes as far as having none of > the hardwired devices sharing controllers with pluggable devices in such a > way that the controllers can find the attached pluggable devices first. > Subject to that limitation as it is, this does usefully apply to at least > one real system now, and it is a behavior I can take advantage of when > designing new hardware to make developing the associated FreeBSD-based > product software easier (namely, by not having to cobble together a > poor-man's udev [which is not saying users of udev are exactly rich], > and/or worry about how a customer might label the fat partition on an SD > card they insert). > > More generally, whether this is or isn't a widely useful thing in the end, > what is the current process for introducing a new property for use in DTS > files? > > > > > By using the "probe-order" property in > > > sys/boot/fdt/dts/beaglebone-black.dts (see attached > > > beaglebone_black_mmc_probe_order.patch), I am able to swap the order in > > > which the mmc units are probed/attached for that board. This avoids > > > inappropriate hacking of the mmc definition order in am335x.dtsi, which > > is > > > shared among multiple boards. > > > > > > This is not a general solution to the problem of wanting stable device > > > names for hard-wired MMC devices when pluggable slots are present in the > > > system. There could, for example, be a multi-slot MMC controller with a > > > mixture of hard-wired and pluggable devices attached, and this would not > > > address that case. However, it does address the needs of BeagleBone > > Black, > > > and the mechanism may be of use for similar issues on other platforms. > > > > As it isn't a generic solution, I'd be biased against adopting it. What's > > wrong > > with using glabel to accomplish this (either with a label specific > > property, or > > by using a ufs label and mounting /dev/ufs/foo). > > > > > It is not my intention to lobby for adding this to the kernel at this > point. Whether it is widely-enough or only very-narrowly useful I would > say is currently unknown. My intention in posting this patch was for > others on the list(s) that might find it useful to see it and have access > to it, and to attract thoughtful criticism such as yours. > > I appreciate you taking the time to respond. > > -Patrick There's a standard property for mmc/sd devices, "non-removable" whose presence denotes things like soldered-on eMMC parts. Only one of our many sdhci drivers supports it right now (imx). In general the core part of the driver (dev/sdhci) doesn't have good support for insert/remove/presence detection that's handled off to the side (whether it's non-removable or a gpio pin). That alone doesn't solve the wider problem, though, which I think breaks down into two pieces. Let's say you've got two slots, call them left and right. You end up with these two problems... * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if there's a card in the left slot when I boot; I don't want it to change. * I want the slot on the left to be named '1' and the right to be '0'. The first problem is easily solved without impacting dts in any way. We just wire down the relationship controllerN -> mmcN -> mmcsdN. This is exactly equivelent to the old ATA_STATIC_ID option in its effect -- you don't get to choose the names, but you know they won't change based on which devices are present. It could be controlled with a tunable. It's harder to envision the fix for the second part without adding an ad-hoc property for the devices. Even with a property I'm not sure how easy it would be. There's been talk of moving mmcsd towards using CAM. I don't know that much about cam, but I suspect it rules out doing anything about #1 as well. At least, I've never heard of wiring down /dev/daN to a specific device/slot/whatever. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Mar 4 14:18:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C58A9C80 for ; Tue, 4 Mar 2014 14:18:33 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B95CB17 for ; Tue, 4 Mar 2014 14:18:33 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id rl12so4294359iec.4 for ; Tue, 04 Mar 2014 06:18:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1WAyLUBy7JVV90a7udK3Tk3JWwo/TVbXYKXh3yKcOmw=; b=WF4c/T9s4lyrm0JNButdDprwYB+tmLKizDV4E+Wxpg0xHq/LRtxy6cc93lemOmFHHm inVP/w24tMHceLedHB+Go5vnC273KQvYoHkzvKSgK7SK2R5JBjUaHIDBCzJWqUqaa/4W OI4V+5IpztYVJdUt9dJI94BnBm3wY68uO5fv5z5gp+y47YmMcucJn33HM206Hau/zK4q Zose+sRivckT2SzXkzC+teOdlf8Ri7yBleJXKHj8IV+rJSUPVx3LLak87U9hMcUqZ+XM oYSx06wDIrChmuyX6gEP5BcgOcJQquSuLB/c9e6PuL7a1tNDuor9u7+CYa6a9bZSNe82 nTKg== X-Gm-Message-State: ALoCoQkxrfv5ZoZdqpuqsBmBhphmxg5o2ioLj9g1PmSft265KPrB0A33gOMvyYtvsjbg5roONXwu X-Received: by 10.42.129.9 with SMTP id o9mr31419798ics.38.1393942707471; Tue, 04 Mar 2014 06:18:27 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id gd5sm3012340igd.5.2014.03.04.06.18.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 06:18:26 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: <1393939277.1149.300.camel@revolution.hippie.lan> Date: Tue, 4 Mar 2014 07:18:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <04264938-F826-4B3A-8285-94C1092EC3F5@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@FreeBSD.org, freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:18:33 -0000 On Mar 4, 2014, at 6:21 AM, Ian Lepore wrote: > There's been talk of moving mmcsd towards using CAM. I don't know = that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a = specific > device/slot/whatever. CAM has supported this for years, through hints. Not sure there=92s an = FDT binding for it yet. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Mar 4 14:30:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C790433; Tue, 4 Mar 2014 14:30:13 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2EAA2CAC; Tue, 4 Mar 2014 14:30:12 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s24EPOB9027697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 15:25:25 +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 s24EPEvL082602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2014 15:25:14 +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 s24EPE8f038990; Tue, 4 Mar 2014 15:25:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s24EPDlY038989; Tue, 4 Mar 2014 15:25:13 +0100 (CET) (envelope-from ticso) Date: Tue, 4 Mar 2014 15:25:13 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) Message-ID: <20140304142513.GH15675@cicely7.cicely.de> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393939277.1149.300.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-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:30:13 -0000 On Tue, Mar 04, 2014 at 06:21:17AM -0700, Ian Lepore wrote: > There's a standard property for mmc/sd devices, "non-removable" whose > presence denotes things like soldered-on eMMC parts. Only one of our > many sdhci drivers supports it right now (imx). In general the core > part of the driver (dev/sdhci) doesn't have good support for > insert/remove/presence detection that's handled off to the side (whether > it's non-removable or a gpio pin). > > That alone doesn't solve the wider problem, though, which I think breaks > down into two pieces. Let's say you've got two slots, call them left > and right. You end up with these two problems... > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > there's a card in the left slot when I boot; I don't want it to > change. > * I want the slot on the left to be named '1' and the right to be > '0'. > > The first problem is easily solved without impacting dts in any way. We > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > don't get to choose the names, but you know they won't change based on > which devices are present. It could be controlled with a tunable. > > It's harder to envision the fix for the second part without adding an > ad-hoc property for the devices. Even with a property I'm not sure how > easy it would be. > > There's been talk of moving mmcsd towards using CAM. I don't know that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a specific > device/slot/whatever. CAM has wiring support. This had been the case for SCSI even before CAM was written and was vital in the days with many SCSI drives but without disk labeling support. Example from sys/conf/NOTES: hint.scbus.0.at="ahc0" hint.scbus.1.at="ahc1" hint.scbus.1.bus="0" hint.scbus.3.at="ahc2" hint.scbus.3.bus="0" hint.scbus.2.at="ahc2" hint.scbus.2.bus="1" hint.da.0.at="scbus0" hint.da.0.target="0" hint.da.0.unit="0" hint.da.1.at="scbus3" hint.da.1.target="1" hint.da.2.at="scbus2" hint.da.2.target="3" hint.sa.1.at="scbus1" hint.sa.1.target="6" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Mar 4 14:49:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7273EA87 for ; Tue, 4 Mar 2014 14:49:03 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 39B0CE45 for ; Tue, 4 Mar 2014 14:49:02 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id lx4so2477330iec.10 for ; Tue, 04 Mar 2014 06:48:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=i0Vuz2pilFUmPAOUEhkbaJQV7jNP5F/Nn+GX8DMJZ/k=; b=Y5D+KGVDV0lc3hyBwoPh8rgUgvgVf+PFGmWVOekDnAlvUUHZJUHbggBcJXUlZ8D0H5 3mAZ1rcAVijHGeLvhQfwdzVNfm12UH4dmk7xBlknCCePMp0RuUztP8lEmKBE2RMaSqz5 l5JXOW+E11tXXH+BRZbsi/5uABwek3LGMbf86XjwNKz4+BLV879VlJ5piWZC6H4WJc98 c2QfS7L05/sOrisvh9HUCC7AVgUmVO/HCtB+KtLvgLACxEigHjnpy6Z41cpLOU7SkIsz N5byNFaJW9khRS+xWK5Wqnco1N/PUYXa7L1nVEpL1lIno6RiGfdqoTRwLpFdy75Po792 nmxA== X-Gm-Message-State: ALoCoQmj93Q/kkQYRaDFRpCAuQ0qb/LNpV2JiXimRTmn8ufXS2zykcQF8DFdb+79c6cJHjOe7XdC X-Received: by 10.43.150.80 with SMTP id kn16mr7430357icc.63.1393944535989; Tue, 04 Mar 2014 06:48:55 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f1sm3262336igy.2.2014.03.04.06.48.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 06:48:55 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: TMPFS in kernels From: Warner Losh In-Reply-To: Date: Tue, 4 Mar 2014 07:48:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> To: Jia-Shiun Li X-Mailer: Apple Mail (2.1874) Cc: George Rosamond , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:49:03 -0000 On Mar 4, 2014, at 3:30 AM, Jia-Shiun Li wrote: > On Mon, Mar 3, 2014 at 2:11 PM, John Hay wrote: >> Our embedded systems also use compact flash disks mounted ro. We have >> been (ab)using the nice etc/rc.initdiskless and etc/rc.d/var scripts >> by just having an etc/diskless and populated conf/base and = conf/defaults >> directories. But it seems those scripts just work with md devices. >=20 > I remember hacking it a while ago to adopt tmpfs instead on my pxeboot > test environment. It only requires changing the line mdmfs mounting md = to > 'mount -t tmpfs' (plus mount options), and everything else will work = as usual. I=92ll have to give it a spin on NanoBSD then, at least as an option=85 Warner From owner-freebsd-arm@FreeBSD.ORG Tue Mar 4 15:05:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A96E4E42 for ; Tue, 4 Mar 2014 15:05:15 +0000 (UTC) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F83FFC7 for ; Tue, 4 Mar 2014 15:05:15 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id uq10so1630458igb.5 for ; Tue, 04 Mar 2014 07:05:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=MDjqcPoGmamcHa+Kgfi5I4de6f3Jgf4TgNPAYEMpwhc=; b=PM225VJGPlD74AKgHihxNOjoOEtegSD1H/BhQwmJiGP37feK+XuYNk70bPEoJUO2Tz r1et1LWhDaZinuKKfIH6lHE7++qAUiL06VQ6r9Mhc11v1FYGq2x/cL7k4ieoX03dWBi2 qrSOo22t9fFBLZ+RfzjCe+cVz+Sox/tkVhqb0gFE1ZMeOZtqoaiUWu4ue5K2oDLa/ODL f5BQOkjfWj1yf4G7/QcYgkmDPPZ2K34jCF38jL26VgFdEc3mSkEfjPHjxbduRiXg4Qbl Ag8pJmq9H+x1SgiRbqJrLsMOMQA+8y1kqqS/QTjfXhodu8TLuPFk9ISH0kNuU9EvTfdb 5Oww== X-Gm-Message-State: ALoCoQnFIXkRHIO87PMe3mGS+cRSpqxgy4AxtILRxFPEGwQrjF8mh/HSp6BLiqY3PN37VF9s3DEg X-Received: by 10.43.65.145 with SMTP id xm17mr628294icb.35.1393945509501; Tue, 04 Mar 2014 07:05:09 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id rj10sm50728789igc.8.2014.03.04.07.05.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 07:05:08 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Tue, 4 Mar 2014 08:05:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7110A2B6-A7E4-42F8-8232-9B09BE769C74@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:05:15 -0000 On Mar 3, 2014, at 11:05 PM, Patrick Kelsey wrote: > On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh wrote: >=20 > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: >=20 > > Hi, > > > > The attached patch (fdt_probe_order_control.patch) allows control = over the > > probe order of simplebus child devices by using a "probe-order" = property in > > simplebus child nodes in the .dts file >=20 > Where is the probe-order property defined? I can=92t seem to find it = in the bindings. > Also, I don=92t think it is necessary. This is a software construct, = so doesn=92t really > belong in the dts file. I=92d really like to avoid FreeBSD specific = hacks in the DTS > files. >=20 > It is currently not in any bindings, and has the status of being = something of my own invention and something possibly not ever used = outside of private codebases. I think this is something that would fit = conceptually with the miscellaneous bindings defined in ePAPR, as it is = a rather generic property. As to this being a software construct, I = appreciate and support the goal of keeping DTS files as pure hardware = descriptions (and I'd also argue that the way the status property is = sometimes used turns it into a software construct). Generally, anything that=92s a FreeBSD invention needs to be prefixed by = =91freebsd,=92 or we need to get it through the semi-standarded = device-tree list process. > Let's completely avoid the issue of am I arguing for adding a software = construct to DTS files by looking at this another way. Instead of a = 'probe-order' property that specifies a sort key, I could have the same = quality of result (same warts and all, as discussed below) with a = property that indicates whether the device is hardwired or has some sort = of pluggable interface (a property, say, called 'pluggable'). That = would be a pure hardware-as-it-is-designed description, and having that = information would allow me to do a sort that orders non-pluggable ahead = of pluggable in the probe/attach process. There=92s already properties for this defined, so that wouldn=92t be = terrible. But I=92m not sure how that would affect the order. > > This was motivated by booting FreeBSD from the eMMC on a BeagleBone = Black, > > which has a pluggable microSD card slot in addition to the eMMC. = The order > > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi = causes the > > pluggable slot to be probed/attached first, so the device name = assigned to > > the eMMC soldered to the board changes depending on whether there is = a card > > in the pluggable slot, which makes establishing appropriate = /etc/fstab > > contents less than convenient. >=20 > Sounds like you=92d like to have some sort of name to instance = mapping. > The typical way this is solved is by naming the partitions so that = ordering > doesn=92t matter. Even if you don=92t handle this at the filesystem = level, which > is how others cope, you=92d want this to be more of a direct binding = rather than an > ordering so that you get the effect you want (constant name) directly, = rather > than as a side-effect of ordering. >=20 > Yes, ideally I'd like to be able to assign a name to every MMC/SD card = slot (hardwired or otherwise) in a system that depends only on the = physical location of that slot, and be able to resolve that name to an = mmcsd device instance. This works-here-side-effect-based approach is a = result of the ideal solution seemingly not being within reach given the = available resources. Using partition naming/glabel is a fair point, and = does address the /etc/fstab issue, but it still leaves me short of being = able to construct a product function that relies on knowing what's where = when there is no partitioning/filesystem in place, for example, = something that boils down to 'dd this image to the eMMC [or to the card = in the card slot]'. Perhaps the answer to that is to build something = using devinfo(3)/devd(8) to identify what mmcsdX is currently attached = to each controller when I need to know. We don=92t assign names based on physical location in FreeBSD generally. = The old concept of wiring a card to an address is mostly gone at this = point. You can get information from devinfo to find where the devices actually = live, and do things based on that. There=92s supposed to be (but might = not actually be) sufficient plug and play information so that people = that are invested in tying a physical location to a particular task can = dig that information out. > If you insist on that, then having a something more like = =93freesbd,unit-number=94 > property would also accomplish this. But that would only wire the = controller unit > number, and not the resulting mmcsdX device. >=20 > I understand fully that the utility of this goes as far as having none = of the hardwired devices sharing controllers with pluggable devices in = such a way that the controllers can find the attached pluggable devices = first. Subject to that limitation as it is, this does usefully apply to = at least one real system now, and it is a behavior I can take advantage = of when designing new hardware to make developing the associated = FreeBSD-based product software easier (namely, by not having to cobble = together a poor-man's udev [which is not saying users of udev are = exactly rich], and/or worry about how a customer might label the fat = partition on an SD card they insert). Device security goes well beyond device enumeration ordering, but that=92s= a fair point. > More generally, whether this is or isn't a widely useful thing in the = end, what is the current process for introducing a new property for use = in DTS files? You need to get it approved via the devicetree-spec@vger.kernel.org = mailing list to make it official. There are efforts to move this away = from Linux infrastructure to its own infrastructure... > > By using the "probe-order" property in > > sys/boot/fdt/dts/beaglebone-black.dts (see attached > > beaglebone_black_mmc_probe_order.patch), I am able to swap the order = in > > which the mmc units are probed/attached for that board. This avoids > > inappropriate hacking of the mmc definition order in am335x.dtsi, = which is > > shared among multiple boards. > > > > This is not a general solution to the problem of wanting stable = device > > names for hard-wired MMC devices when pluggable slots are present in = the > > system. There could, for example, be a multi-slot MMC controller = with a > > mixture of hard-wired and pluggable devices attached, and this would = not > > address that case. However, it does address the needs of BeagleBone = Black, > > and the mechanism may be of use for similar issues on other = platforms. >=20 > As it isn=92t a generic solution, I=92d be biased against adopting it. = What=92s wrong > with using glabel to accomplish this (either with a label specific = property, or > by using a ufs label and mounting /dev/ufs/foo). >=20 >=20 > It is not my intention to lobby for adding this to the kernel at this = point. Whether it is widely-enough or only very-narrowly useful I would = say is currently unknown. My intention in posting this patch was for = others on the list(s) that might find it useful to see it and have = access to it, and to attract thoughtful criticism such as yours. Sure. Tying devices name to physical location is a hardish FreeBSD = problem, but has been since around FreeBSD 3. =46rom the sounds of things, you=92d want any SD card found on this = controller to have a unique name=85 The move to CAM may help that, but = we=92d need to invent FDT bindings, I think, for CAM to get the device = wiring info it currently gets from hints... > I appreciate you taking the time to respond. Sure thing=85 Warner= From owner-freebsd-arm@FreeBSD.ORG Tue Mar 4 23:50:36 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F246E906 for ; Tue, 4 Mar 2014 23:50:35 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B4BACD92 for ; Tue, 4 Mar 2014 23:50:35 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WKz6Y-00081B-4S; Tue, 04 Mar 2014 23:50:34 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s24NoVwY048468; Tue, 4 Mar 2014 16:50:31 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+vYq93E/tkNyDjB5iRqK64 Subject: Re: Pandaboard ES and SD card From: Ian Lepore To: Svatopluk Kraus In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Mar 2014 16:50:31 -0700 Message-ID: <1393977031.1149.325.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 23:50:36 -0000 On Mon, 2014-03-03 at 17:12 +0100, Svatopluk Kraus wrote: > Hi, > > I finally have found time to install FreeBSD 11.0-CURRENT on Pandaboard ES > on my table. It's been installed to SD card. When I boot to multiuser, > it's very very slow. It looks that SD card write performance is very poor. > When I boot to singleuser, it's OK. However, when I make root filesystem > read-write by one command and immediately readonly by second one, the > second one takes a few minutes to finish. > > When I've digged in arm/ti/ti_mmchs.s, I've got following times for READ > and WRITE commands: > > typical read times (start & duration & command), > ... > [1393858258.909d4fb4650dcb70] [0.002f97afec8ba994] READ > [1393858258.929795e2f7db5ec0] [0.002f90d496ec7d4c] READ > [1393858258.9492673f18af4ec0] [0.002f9d607a66e41c] READ > [1393858258.968d155674da0d5e] [0.002f937e2ea37cca] READ > [1393858258.988790d78e6fd5a2] [0.002f9eb09b235414] READ > [1393858258.9a78744ecab1413e] [0.002f90dded2a9cda] READ > [1393858258.9c735a3cec62b616] [0.002f97cbef46083e] READ > [1393858258.9e6ee0b8064ec2aa] [0.002f933cd2f09fe8] READ > [1393858258.a069e2838966634a] [0.002f959262788368] READ > [1393858258.a26467518add9a00] [0.002f8f9722ac4c70] READ > [1393858258.a45e59f14fb6c986] [0.002f9d31cb304656] READ > [1393858258.a659525d3e70bc98] [0.002f8ae2ad5e65e2] READ > [1393858258.a853df0c0452931e] [0.002f9cd46cc30aca] READ > ... > > typical write times (start & duration & command). > ... > [1393856255.8be604dff29d07a0] [0.00d9cf712d331d58] WRITE > [1393856255.8e9100859c4fedd2] [0.00da3f856cebe4e6] WRITE > [1393856255.913c1530607b6288] [0.00da8f1a826cd93a] WRITE > [1393856255.93e7b97bcc483d9a] [0.00dad6ced3832dbe] WRITE > [1393856255.9693e68c8a1752c0] [0.2276ea0a1d732724] WRITE <- > [1393856255.badca6f90c5564ea] [0.22df71f44f623e3e] WRITE <- > [1393856255.df8e42a6890234a4] [0.24ae2f1172203ed0] WRITE <- > [1393856256.060e4c7acd0c290a] [0.00e76cb09c67c3ba] WRITE > [1393856256.08c68da8b0554498] [0.00e7b1d75881776a] WRITE > [1393856256.0b7f57d3eb15578e] [0.00e83c08cdfa8020] WRITE > [1393856256.0e36d38be88f1e08] [0.00e882dd093ddf54] WRITE > [1393856256.10f0762d8d8cbe10] [0.00e8c0f06a43a968] WRITE > [1393856256.13aa6a2dc9ef5c9a] [0.00e938916637f4c8] WRITE > [1393856256.1664fc08109773d4] [0.22b74fce5c0401e2] WRITE <- > [1393856256.3aedb9baa4273c8e] [0.2305517892cef37c] WRITE <- > [1393856256.5fc52a62081f2238] [0.24aaf338d2067a84] WRITE <- > [1393856256.8641d9129fd99066] [0.00e770cfadd3b168] WRITE > [1393856256.88fae819e4c25a9c] [0.04d7472f5f571cbc] WRITE > ... > > Times are struct bintime printed in %lld.%016llx (sec.frac) format. > > Writing times have got really big variation. > Any idea or experience? > > Svatopluk Kraus > > PS. Of course, I don't mention occasional "Spurious interrupt detected" > print. The ti_mmchs driver does all IO one sector at a time, and single-sector writes are the worst case for sdcard performance. I've seen single-sector writes go as slow as 20K/sec. Try switching to the ti_sdhci driver (switch the entry in files.omap4). I don't know for sure that ti_sdhci will work with pandaboard, it's only been tested on beaglebone that I know of. But if it works you should see read speeds around 16MB/sec and writes at about 7MB/sec. The "mount -uw / ; mount -ur /" is a completely separate thing. That takes about 30 seconds on every sdcard-based system I have. I don't know why, but it's really annoying. I don't think it's a driver thing, it happens with several different drivers. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 00:54:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A522AB5 for ; Wed, 5 Mar 2014 00:54:44 +0000 (UTC) Received: from wa3yre.wynn.com (wa3yre.wynn.com [199.89.147.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 48BB75EE for ; Wed, 5 Mar 2014 00:54:43 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by wa3yre.wynn.com (8.14.3/8.12.6) with ESMTP id s250salH058146 for ; Tue, 4 Mar 2014 19:54:37 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 4 Mar 2014 19:54:36 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Jumping back into this Message-ID: <20140304195436.37c15d21@ivory.wynn.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 00:54:44 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpHcmVldGlu Zy0NCg0KSSBoYXZlIGJlZW4gYXdheSBmcm9tIEZyZWVCU0QgYXJtIGZvciBtYW55IG1vb25zIGR1 ZSB0byBvdGhlciB0aGluZ3MNCmdvaW5nIHdpdGggbXkgbGlmZSB0aGF0IHdlcmUgbGFyZ2UgdGlt ZSBzaW5rcy4NCg0KSSBhbSBsb29raW5nIHRvIGp1bXAgYmFjayBvbiB0aGUgRnJlZUJTRCBBUk0g SEVBRCBiYW5kd2Fnb24sIGJ1dCBteSBQaQ0KYW5kIEJlYWdsZUJvbmUgYXJlIHJ1bm5pbmcgc3Vj aCBvbGQgc29mdHdhcmUgYXQgdGhpcyBwb2ludCB0aGF0IGN2c3VwDQphbmQgcmVidWlsZCBhcmUg bm90IGFuIG9wdGlvbi4NCg0KU28uLi4uLndoYXQgaXMgY29uc2lkZXJlZCB0aGUgY3VycmVudCBi ZXN0IHdheSB0byBnZXQgYmFjayB0byB0cmFja2luZw0KaGVhZD8gDQoNClRoYW5rcyBmb2xrcyEN Cg0KLSAtQnJldHQNCg0KLSAtLSANCg0Kd3lua29vcEB3eW5uLmNvbSAgICAgICAgICAgICAgIGh0 dHA6Ly9wcmQ0Lnd5bm4uY29tL3d5bmtvb3AvcGdwLWtleXMudHh0DQo5MTctNjQyLTY5MjUNCjky OS0yNzItMDAwMA0KDQpJIHdvdWxkIG5ldmVyIGludmFkZSB0aGUgVW5pdGVkIFN0YXRlcy4gIFRo ZXJlIHdvdWxkIGJlIGEgZ3VuIGJlaGluZA0KZXZlcnkgYmxhZGUgb2YgZ3Jhc3MuICAtLUlzb3Jv a3UgWWFtYW1vdG8NCg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdu dVBHIHYyLjAuMjIgKERhcndpbikNCg0KaVFFY0JBRUJBZ0FHQlFKVEZuWE1BQW9KRUs2SzN5cmMr UnVEMytVSC9ST0xLMzNLdm4yb1hPWnhyZ3VGR0tQdQ0KcTVWRldZdzViQ0ZmQ2toS1Jjc0R2dGtD Y2RzWWU1aFErQXJlNzl6cnJqdW9lTmQvVmJjcTdzV2o4bGJ4Vk5QeA0KdjFaRGpuUjAySmJ4ejA2 ZDFkVEN3Z3ljQW9hUXg0R2E4cTQ2bEZVblRCSEwzOWFIWjJ5SnNkVjRSSkFxenFaUQ0KMGxUWkpa cDJwUUZzckJ6cDJQZEpyb2FuUVZYb0U3bU52YWtKbzB1TURuTmF6Z21YbEsxWXJZYjhONlVlSHZx Ug0KTFpFSnNiQUFRNUlodVFHTTFNZEpBU252R0REV2dLVmthV2VUYjJ2UVRRRG1EQVphdnF2TWdZ dUM0NmtKeGpTaQ0KU2FjNTJraThiQzVYOEFuSlZRRXFQNXBycTVmSzRtdGJnT213aElNdjJUVURH M2RWSzlKZzJsSjNZZnVxNzBNPQ0KPWhOY28NCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 02:13:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C0FC9C2 for ; Wed, 5 Mar 2014 02:13:10 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1992D6D for ; Wed, 5 Mar 2014 02:13:09 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id hw13so407889qab.32 for ; Tue, 04 Mar 2014 18:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=npFyDb3EG4xW5333z1rUU5GZ176nA9qw3o9eBKKhPDo=; b=anissSvMzdFZpfFjrz7UbBoD6qsOT+Zb+uL8sn6g/G8W40R3FwV1119T4csIWN+Nj4 N4jR0GGY3uPVszK9L8XXbbCsrDe6bHUdOWameUIAPQJ4DYZ240/nlElCnZGiYmu5mGzr z25HKwQBDCZCeFvyTx2zh1tdMIdDrjEEDBwv/B1Fh0kkfJtdSLtPDMYmL0X+m7Oj/tge HpsOKVDrIHeoZATPA8YxBScyHVYUe2y+81AmN3cIWmBV51W9nf1MaVp41/YTwd5xeZX+ VpPurteOw7W1eQfaDkWHW08f0BYXJntTPY3O4jnFjr/sQwQJh4hGGVEC03lv7INI2T7v RQ0Q== MIME-Version: 1.0 X-Received: by 10.224.11.136 with SMTP id t8mr3817524qat.26.1393985588939; Tue, 04 Mar 2014 18:13:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Tue, 4 Mar 2014 18:13:08 -0800 (PST) In-Reply-To: <20140304195436.37c15d21@ivory.wynn.com> References: <20140304195436.37c15d21@ivory.wynn.com> Date: Tue, 4 Mar 2014 18:13:08 -0800 X-Google-Sender-Auth: vZTkuUyWscw8U10bvSl0udYKNY4 Message-ID: Subject: Re: Jumping back into this From: Adrian Chadd To: Brett Wynkoop Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 02:13:10 -0000 Hi! Grab the latest -HEAD tree and Crochet, and build away. -a On 4 March 2014 16:54, Brett Wynkoop wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Greeting- > > I have been away from FreeBSD arm for many moons due to other things > going with my life that were large time sinks. > > I am looking to jump back on the FreeBSD ARM HEAD bandwagon, but my Pi > and BeagleBone are running such old software at this point that cvsup > and rebuild are not an option. > > So.....what is considered the current best way to get back to tracking > head? > > Thanks folks! > > - -Brett > > - -- > > wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt > 917-642-6925 > 929-272-0000 > > I would never invade the United States. There would be a gun behind > every blade of grass. --Isoroku Yamamoto > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (Darwin) > > iQEcBAEBAgAGBQJTFnXMAAoJEK6K3yrc+RuD3+UH/ROLK33Kvn2oXOZxrguFGKPu > q5VFWYw5bCFfCkhKRcsDvtkCcdsYe5hQ+Are79zrrjuoeNd/Vbcq7sWj8lbxVNPx > v1ZDjnR02Jbxz06d1dTCwgycAoaQx4Ga8q46lFUnTBHL39aHZ2yJsdV4RJAqzqZQ > 0lTZJZp2pQFsrBzp2PdJroanQVXoE7mNvakJo0uMDnNazgmXlK1YrYb8N6UeHvqR > LZEJsbAAQ5IhuQGM1MdJASnvGDDWgKVkaWeTb2vQTQDmDAZavqvMgYuC46kJxjSi > Sac52ki8bC5X8AnJVQEqP5prq5fK4mtbgOmwhIMv2TUDG3dVK9Jg2lJ3Yfuq70M= > =hNco > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Mar 5 02:43:35 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B54154D; Wed, 5 Mar 2014 02:43:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CBF3FB3; Wed, 5 Mar 2014 02:43:35 +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 s252hYLW036527; Tue, 4 Mar 2014 21:43:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s252hYEq036525; Wed, 5 Mar 2014 02:43:34 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 5 Mar 2014 02:43:34 GMT Message-Id: <201403050243.s252hYEq036525@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 02:43:35 -0000 TB --- 2014-03-05 01:30:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-03-05 01:30:18 - 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 --- 2014-03-05 01:30:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-03-05 01:30:18 - cleaning the object tree TB --- 2014-03-05 01:30:18 - /usr/local/bin/svn stat /src TB --- 2014-03-05 01:30:23 - At svn revision 262763 TB --- 2014-03-05 01:30:24 - building world TB --- 2014-03-05 01:30:24 - CROSS_BUILD_TESTING=YES TB --- 2014-03-05 01:30:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-05 01:30:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-05 01:30:24 - SRCCONF=/dev/null TB --- 2014-03-05 01:30:24 - TARGET=arm TB --- 2014-03-05 01:30:24 - TARGET_ARCH=arm TB --- 2014-03-05 01:30:24 - TZ=UTC TB --- 2014-03-05 01:30:24 - __MAKE_CONF=/dev/null TB --- 2014-03-05 01:30:24 - cd /src TB --- 2014-03-05 01:30:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Mar 5 01:30:30 UTC 2014 >>> 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 [...] In file included from /src/lib/libc/net/getifaddrs.c:42: /obj/arm.arm/src/tmp/usr/include/net/route.h:128:13: error: field has incomplete type 'struct mtx' struct mtx rt_mtx; /* mutex for routing entry */ ^ /obj/arm.arm/src/tmp/usr/include/net/route.h:128:9: note: forward declaration of 'struct mtx' struct mtx rt_mtx; /* mutex for routing entry */ ^ 1 error generated. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/libc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-03-05 02:43:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-05 02:43:34 - ERROR: failed to build world TB --- 2014-03-05 02:43:34 - 3857.16 user 424.38 system 4395.52 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 03:14:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4355E6C0 for ; Wed, 5 Mar 2014 03:14:22 +0000 (UTC) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE0AB3A1 for ; Wed, 5 Mar 2014 03:14:21 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id e9so506631qcy.26 for ; Tue, 04 Mar 2014 19:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H8KxLCu5CIqZubnXDg1vTNwrqoIoPKFil9Eux3PvOqA=; b=LVjOnZGu77E0ztAM38QNiv8eeegIWajz5vbDAcw1gcek/YhjH0zlWK7KLGsFMD5wGE g6g0QJ4FjqeyslsCjrWN+9m0Mlz1nuZHTgkQw1pLIGvG6em2toRqeV/KOp74XNKe2tZe llJdLyke3C4/0yiRG7qkl5FaiQ49JJ4LkenoI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H8KxLCu5CIqZubnXDg1vTNwrqoIoPKFil9Eux3PvOqA=; b=JjAGGAIdC3ViJSoV0IgK7+IX/DrOgyhheAjyl0u3Pxmq9sAt88zdN8fHVJ6O2NbPTw piOsQeUpLWhKtCrEPq+YtgokSKGe3ETHwtIpKpoC4+UZKCdK32GvOObhvsz4WG9p0BbK qITO6+escS69v3OrmgcDOYmXg4/7cdD9vL0bDCvISin2415pZHrA8olkWI6FDHNhySqB YmbEZ6cRELNJbpAhAT13pRxEZ45rzd/qjQwvoEKKsw1xMORPqJvYiTs/w7qcyAAFoaSE ayhJ5Z/Nj1SIgqEt/+WFgYg0zb65EGMrMhUh3e5Y0JxfNXB0EGfgF6DYbZle1SlaZeLa qCqA== X-Gm-Message-State: ALoCoQmU5jpCKx+fBEe73DstwDuvoxVSdyFelNKn1UWSqBdcEZMbCo3z5j3guJ1tMDwC1jly75N9 X-Received: by 10.224.161.140 with SMTP id r12mr4043058qax.24.1393989260296; Tue, 04 Mar 2014 19:14:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.147.225 with HTTP; Tue, 4 Mar 2014 19:13:50 -0800 (PST) In-Reply-To: <20140304195436.37c15d21@ivory.wynn.com> References: <20140304195436.37c15d21@ivory.wynn.com> From: Eitan Adler Date: Tue, 4 Mar 2014 22:13:50 -0500 Message-ID: Subject: Re: Jumping back into this To: Brett Wynkoop Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 03:14:22 -0000 On 4 March 2014 19:54, Brett Wynkoop wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Greeting- > > I have been away from FreeBSD arm for many moons due to other things > going with my life that were large time sinks. > > I am looking to jump back on the FreeBSD ARM HEAD bandwagon, but my Pi > and BeagleBone are running such old software at this point that cvsup > and rebuild are not an option. > > So.....what is considered the current best way to get back to tracking > head? svn or the git mirror: http://freebsd.org/doc/handbook/svn.html github.com/freebsd/freebsd -- Eitan Adler From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 06:06:50 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 244AC2C5; Wed, 5 Mar 2014 06:06:50 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5817E0; Wed, 5 Mar 2014 06:06:49 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id F1C05B828; Wed, 5 Mar 2014 08:06:39 +0200 (SAST) Date: Wed, 5 Mar 2014 08:06:39 +0200 From: John Hay To: Ian Lepore Subject: Re: Pandaboard ES and SD card Message-ID: <20140305060639.GA22828@zibbi.meraka.csir.co.za> References: <1393977031.1149.325.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393977031.1149.325.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 06:06:50 -0000 On Tue, Mar 04, 2014 at 04:50:31PM -0700, Ian Lepore wrote: > On Mon, 2014-03-03 at 17:12 +0100, Svatopluk Kraus wrote: > > Hi, > > > > I finally have found time to install FreeBSD 11.0-CURRENT on Pandaboard ES > > on my table. It's been installed to SD card. When I boot to multiuser, > > it's very very slow. It looks that SD card write performance is very poor. > > When I boot to singleuser, it's OK. However, when I make root filesystem > > read-write by one command and immediately readonly by second one, the > > second one takes a few minutes to finish. ... > > The "mount -uw / ; mount -ur /" is a completely separate thing. That > takes about 30 seconds on every sdcard-based system I have. I don't > know why, but it's really annoying. I don't think it's a driver thing, > it happens with several different drivers. It is svn 230553 to vfs_subr.c that causes it. ############## When doing vflush(WRITECLOSE), clean vnode pages. Unmounts do vfs_msync() before calling VFS_UNMOUNT(), but there is still a race allowing a process to dirty pages after msync finished. Remounts rw->ro just left dirty pages in system. --- head/sys/kern/vfs_subr.c 2012/01/17 01:08:01 230249 +++ head/sys/kern/vfs_subr.c 2012/01/25 20:54:09 230553 @@ -2496,6 +2496,18 @@ * vnodes open for writing. */ if (flags & WRITECLOSE) { + if (vp->v_object != NULL) { + VM_OBJECT_LOCK(vp->v_object); + vm_object_page_clean(vp->v_object, 0, 0, 0); + VM_OBJECT_UNLOCK(vp->v_object); + } + error = VOP_FSYNC(vp, MNT_WAIT, td); + if (error != 0) { + VOP_UNLOCK(vp, 0); + vdrop(vp); + MNT_VNODE_FOREACH_ABORT(mp, mvp); + return (error); + } error = VOP_GETATTR(vp, &vattr, td->td_ucred); VI_LOCK(vp); ############## I'm running with the pfsense patch which basically put an if() around it, with a sysctl that is not set. https://redmine.pfsense.org/projects/pfsense-tools/repository/revisions/008742971cb44d8c0f81929504ab7330442c4ba4/entry/patches/RELENG_8_3/vfs_subr_mount_RO.diff With 230553 only the AVILA watchdog will reset the box everytime you make a config change. I'm sure there must be something wrong or very un-optimal with that code because with a very slow flash interface I cannot see how doing "mount -u -w /; vi /etc/rc.conf; mount -u -r /", can cause the last mount to take half a minute or more. John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 06:53:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD21F76C; Wed, 5 Mar 2014 06:53:49 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0D09CDA; Wed, 5 Mar 2014 06:53:48 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ec20so382897lab.39 for ; Tue, 04 Mar 2014 22:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w7LcJ9uQP48xbWxPvvAoLfI8VUVFNN5THwn5WqSEtCk=; b=g86DhWM7ElFTgtbR2FBjwDsOQI1dvkLjLvct/C5XnW/Gfyys07xQtFWKC+Y2dLMzAP X3pm/j5PogPTlY41AWBGI1ZIHAHP6PMz9yu5QjQ2Pd8rDi4uSSag+YjphBxLX/DQ+Fl/ mf5h08WdIBDAv66Fl3LnvXeEziP1gCV/rKborvSP9DeLjZu9KcxqoCE8QFzhEeD7ytdq GXeTW5ZxMrf72q9jQJsLDcZoyblfAEnJRuHNSFEmcJNM87nOdAjyxGiUHwyZ2WbVx6nY k/uhWKiBA7fEjqJdgUUyH8LcMdB4NTDie2ZtZhmDll+I5/bY2M6xv8q22wOruOUMHC9+ hEnw== MIME-Version: 1.0 X-Received: by 10.112.77.138 with SMTP id s10mr110546lbw.59.1394002426743; Tue, 04 Mar 2014 22:53:46 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Tue, 4 Mar 2014 22:53:46 -0800 (PST) In-Reply-To: <1393939277.1149.300.camel@revolution.hippie.lan> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> Date: Wed, 5 Mar 2014 01:53:46 -0500 X-Google-Sender-Auth: RcUlIv0UuuCSFCW0q6fIaFcdswc Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 06:53:50 -0000 On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > There's a standard property for mmc/sd devices, "non-removable" whose > presence denotes things like soldered-on eMMC parts. Only one of our > many sdhci drivers supports it right now (imx). In general the core > part of the driver (dev/sdhci) doesn't have good support for > insert/remove/presence detection that's handled off to the side (whether > it's non-removable or a gpio pin). > > That alone doesn't solve the wider problem, though, which I think breaks > down into two pieces. Let's say you've got two slots, call them left > and right. You end up with these two problems... > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > there's a card in the left slot when I boot; I don't want it to > change. > And not just a boot-time issue, of course. If you were to remove those two cards and then reinsert them in the opposite time-order, their device names would swap. > * I want the slot on the left to be named '1' and the right to be > '0'. > > The first problem is easily solved without impacting dts in any way. We > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > don't get to choose the names, but you know they won't change based on > which devices are present. It could be controlled with a tunable. > > It's harder to envision the fix for the second part without adding an > ad-hoc property for the devices. Even with a property I'm not sure how > easy it would be. > We should be able to assign a geographic address (controllerX:slotY) to each mmcsd device in a given system (let's ignore for now the theoretical possibility of multiple cards on one bus). The 'controllerX' part of the address could be the controller's pathname from the devicetree, or an index assigned by mmcbr machinery at attach time. The "slotY" part of the address is assigned by the specific controller device driver using some internally-determined fixed mapping between the assigned values and its physical slots. This geographic address could be used to create an additional set of /dev entries with stable names. There could be a mechanism for user-configurable aliases for the geographical addresses. That kind of approach addresses both concerns, avoids trying to control device unit number assignment, and doesn't require any special support from the device tree. In the theoretically possible case of multiple MMC devices on one bus, the next piece of identifying information in the geographic address would have to be the RCA assigned to the card. As far as I am aware, in such a multidrop configuration, there is generally no way for a controller to know which RCA is assigned to which slot due to the contention-based (that is, non-geographic) nature of the initialization protocol, so this would be a configuration in which stable names would not be possible without an ad-hoc, out-of-band hardware support. Does anyone know if sharing a bus is only a possibility with MMC cards? I *think*, but am not feeling authoritative, that SD/SDIO cards do not support multiple devices on one bus. > > There's been talk of moving mmcsd towards using CAM. I don't know that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a specific > device/slot/whatever. > > -- Ian > > > From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 07:00:05 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 927B7BF6; Wed, 5 Mar 2014 07:00:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DBBBD6E; Wed, 5 Mar 2014 07:00:05 +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 s25704pJ064991; Wed, 5 Mar 2014 02:00:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s25704SR064984; Wed, 5 Mar 2014 07:00:04 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 5 Mar 2014 07:00:04 GMT Message-Id: <201403050700.s25704SR064984@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 07:00:05 -0000 TB --- 2014-03-05 04:00:16 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-03-05 04:00:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-05 04:00:16 - starting HEAD tinderbox run for arm/arm TB --- 2014-03-05 04:00:16 - cleaning the object tree TB --- 2014-03-05 04:02:03 - /usr/local/bin/svn stat /src TB --- 2014-03-05 04:02:07 - At svn revision 262773 TB --- 2014-03-05 04:02:08 - building world TB --- 2014-03-05 04:02:08 - CROSS_BUILD_TESTING=YES TB --- 2014-03-05 04:02:08 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-05 04:02:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-05 04:02:08 - SRCCONF=/dev/null TB --- 2014-03-05 04:02:08 - TARGET=arm TB --- 2014-03-05 04:02:08 - TARGET_ARCH=arm TB --- 2014-03-05 04:02:08 - TZ=UTC TB --- 2014-03-05 04:02:08 - __MAKE_CONF=/dev/null TB --- 2014-03-05 04:02:08 - cd /src TB --- 2014-03-05 04:02:08 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Mar 5 04:02:14 UTC 2014 >>> 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 [...] cc -O -pipe -Wall -Wmissing-prototypes -Wno-uninitialized -Wstrict-prototypes -DENABLE_ALTQ -I/src/sbin/pfctl -DWITH_INET6 -DWITH_INET -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/sbin/pfctl/pfctl.c /src/sbin/pfctl/pfctl.c:799:25: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] rule->bytes[1]), rule->u_states_cur); ^~~~~~~~~~~~~~~~~~ /src/sbin/pfctl/pfctl.c:804:8: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] rule->u_states_tot); ^~~~~~~~~~~~~~~~~~ 2 errors generated. *** Error code 1 Stop. bmake[3]: stopped in /src/sbin/pfctl *** Error code 1 Stop. bmake[2]: stopped in /src/sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-03-05 07:00:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-05 07:00:04 - ERROR: failed to build world TB --- 2014-03-05 07:00:04 - 8709.64 user 1465.62 system 10787.72 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 07:17:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F7E2924 for ; Wed, 5 Mar 2014 07:17:42 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D03A4F79 for ; Wed, 5 Mar 2014 07:17:41 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w61so695379wes.1 for ; Tue, 04 Mar 2014 23:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hPeI9g19QzlkZuCLGWS98n8PR4OSUmiJ8AnAkxYjn6A=; b=iCt9uRuKW0NpTBBuxEadW4C41unyEYSb2E6UzxiuhLMo6KyGJefkYN+41xf7QjVBhs 6mzkFnS2Jav+noTTGBjZRLhAZ7vK8s+dgPNPxj2dhXq/HtsFGe/iea59byw+uX5YDK5L c47Ugvq30xxwkr8MqHNETcDhEJCww6Kl7oJcQ778iXH2loZ9IR9NoEr1YM5pTooEDfrD 12Evq6rGsW8JzAj4sXgs3trwM0tS37hUvkpZiZNbTq8rSB22QsxZr+y55mHlHRrBS6S0 U4wFljXLZigLbNVBZ7ZkVrWu0WQfZ/dy2kRWdfVEc8tFQvDk/rlUnd75HwnPYMvcYozH BXqQ== MIME-Version: 1.0 X-Received: by 10.194.87.163 with SMTP id az3mr5712037wjb.63.1394003860052; Tue, 04 Mar 2014 23:17:40 -0800 (PST) Received: by 10.217.43.69 with HTTP; Tue, 4 Mar 2014 23:17:40 -0800 (PST) Date: Wed, 5 Mar 2014 09:17:40 +0200 Message-ID: Subject: CompuLab - FreeScale i.MX6 CPU From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 07:17:42 -0000 Hi, I am interested with CompuLab Utilite Standart board. ( http://utilite-computer.com/web/utilite-models ) I saw that over SVN, FreeBSD has i.MX6 cpu support. What about drivers of this board? Does HDMI and NICs works? Can you suggest a cheap and two ethernet arm board that FreeBSD works. Best regards, From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 11:48:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E920160A for ; Wed, 5 Mar 2014 11:48:25 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD2AFD81 for ; Wed, 5 Mar 2014 11:48:25 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id wp4so866349obc.40 for ; Wed, 05 Mar 2014 03:48:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=91aypn5KV6RR2oRDQwJKOsKqzbzNflf5FrMeNuZzTMw=; b=DDZCiQIYOzWpu+8LOXdrA8h3wWFFesQnrlo/8ttlWykBId76hCC8msXCLvGD2Ra1fh V4iw93UG/mCMIV6/tBAR4QkotSg0xfFnX/03QS6sO0hx5W2+MZA6LgpWcmZtOY+m7hUQ 2K6eyTCBzWu26tyyla1BNrFMZCVgR6lzRmRtR2enE4p1lTx+UXbQ4oMVlmHdcn9f/p/0 j8MfFrVf+U2+RkBg0ejK24/Yhq4oiJGyvFuZgbEglcLIIOhqrxfEu1l8jeUT2hkS/gzk 3tRrpQaVi8RuZ9x6K9L4qHVroGuOMsF5aLDTuUQGZGXYaMHM8oWjABmMucyZNwCSn6+G AJxQ== X-Gm-Message-State: ALoCoQnyp027O7dgz8Rsc/IimNaoDWD8gf9qkyyavTCkLR6oCt9yUZvHpKLleXUgMrPRz/ZZma8m MIME-Version: 1.0 X-Received: by 10.182.112.130 with SMTP id iq2mr1170657obb.57.1394020099395; Wed, 05 Mar 2014 03:48:19 -0800 (PST) Received: by 10.182.165.167 with HTTP; Wed, 5 Mar 2014 03:48:19 -0800 (PST) X-Originating-IP: [2001:44b8:31b0:aa00:c685:8ff:fe35:3e2d] In-Reply-To: References: <87ob2gxfg0.fsf@gmail.com> <1392997297.1145.88.camel@revolution.hippie.lan> <53077971.8060406@gmail.com> Date: Wed, 5 Mar 2014 22:48:19 +1100 Message-ID: Subject: Re: Beaglebone Black: crash during portsnap extract From: Jason Birch To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:48:26 -0000 I'm not sure the underlying problem is solved here -- I encountered it on r262372 when compiling lang/perl5.16 overnight, and I see emails dating back to at least September 2013 on r255438, which followed with a discussion on what you can possibly do to recover in these scenarios. In the mean time, I might purchase a faster SD card for use with my BeagleBone Black as a cheap (effortwise) work-around, as I'm using a spare Class 4 I had lying around. On Mon, Feb 24, 2014 at 11:13 PM, Jason Birch wrote: > Henryk notes that this doesn't occur when just copying the tree around -- >> although that'll be many smaller files instead of one big one. I wonder if >> it's specifically happening in conjunction with bsdtar -- I'll try and >> contrive a testcase later this afternoon. > > > I can't trigger this as a non-privileged user. I can reliably trigger this > by a simple `tar xf /var/db/portsnap/.tgz` as root. > > I'm taking r262372 for a spin now (Which of course includes your r261983), > and have been able to successfully extract the ports tree as root without > being dumped into ddb. Though... I have been sitting here waiting for the > snapshot verification for quite a while, but that's another story. The only > thing untoward I see is that UFS lock order reversal... > > lock order reversal: > 1st 0xc2f73394 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101 > 2nd 0xcd25c3c8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 > 3rd 0xc2f93934 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101 > > ... but I think that's well known at this point and isn't a cause for my > concern. > > Thanks Ian! > From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 13:31:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF7C2C26 for ; Wed, 5 Mar 2014 13:31:47 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B11159EA for ; Wed, 5 Mar 2014 13:31:47 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id hl1so10823605igb.4 for ; Wed, 05 Mar 2014 05:31:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=v3nL8+l2MOPOQwrfj7uRwzmfI/Vvjwopc6aX8ig5em8=; b=gasfI8b2vw7KeNnV36p4uDdR5h6/Xywq/mW8z+bmyvL967Wxo1ps/+NtjUH/Ju1iDt Ic6BVEFUgvBmkVbHNH4KBffvezkyLS96VqKaAyN8H9Q+PdUOno++LZlahy+sQYJq1G0d s874aXeWRErh7U3avFMkwNypv1LNGmDa8Ink5W+d9Cn1yZ4t6ai3F3NwOkii1gI8L9eM E1c/QRC6zVWaMT/M3FSwlDtre2ms045WawQQbQRXn/KIZfTt7RszqfkWHoEGsDF093bx E6CXo4jLlTlqJqIS39/Wuu3zQCZUpiSbc45dCMN6Qhb0KQ/qh1qFAYpGFzaHMEXEQBU2 yQ9w== X-Gm-Message-State: ALoCoQk2cKU6xOpjJReXLSxzxutLOwrPUyk45k/btI+evUHmwny8RVRpNEU360/PMvVmPopjxjjX X-Received: by 10.50.119.132 with SMTP id ku4mr8927242igb.35.1394026300866; Wed, 05 Mar 2014 05:31:40 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id v2sm13404632igk.7.2014.03.05.05.31.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 05:31:40 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 06:31:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:31:48 -0000 On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: >=20 > There's a standard property for mmc/sd devices, "non-removable" whose > presence denotes things like soldered-on eMMC parts. Only one of our > many sdhci drivers supports it right now (imx). In general the core > part of the driver (dev/sdhci) doesn't have good support for > insert/remove/presence detection that's handled off to the side = (whether > it's non-removable or a gpio pin). >=20 > That alone doesn't solve the wider problem, though, which I think = breaks > down into two pieces. Let's say you've got two slots, call them left > and right. You end up with these two problems... >=20 > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 = if > there's a card in the left slot when I boot; I don't want it = to > change. >=20 > And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. > =20 > * I want the slot on the left to be named '1' and the right to = be > '0'. >=20 > The first problem is easily solved without impacting dts in any way. = We > just wire down the relationship controllerN -> mmcN -> mmcsdN. This = is > exactly equivelent to the old ATA_STATIC_ID option in its effect -- = you > don't get to choose the names, but you know they won't change based on > which devices are present. It could be controlled with a tunable. >=20 > It's harder to envision the fix for the second part without adding an > ad-hoc property for the devices. Even with a property I'm not sure = how > easy it would be. >=20 > We should be able to assign a geographic address (controllerX:slotY) = to each mmcsd device in a given system (let's ignore for now the = theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. There=92s already a chance to run a script when a device is attached = that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. Why is mmc so different it needs its own mechanism? Warner > That kind of approach addresses both concerns, avoids trying to = control device unit number assignment, and doesn't require any special = support from the device tree. >=20 > In the theoretically possible case of multiple MMC devices on one bus, = the next piece of identifying information in the geographic address = would have to be the RCA assigned to the card. As far as I am aware, in = such a multidrop configuration, there is generally no way for a = controller to know which RCA is assigned to which slot due to the = contention-based (that is, non-geographic) nature of the initialization = protocol, so this would be a configuration in which stable names would = not be possible without an ad-hoc, out-of-band hardware support. Does = anyone know if sharing a bus is only a possibility with MMC cards? I = *think*, but am not feeling authoritative, that SD/SDIO cards do not = support multiple devices on one bus. > =20 >=20 > There's been talk of moving mmcsd towards using CAM. I don't know = that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a = specific > device/slot/whatever. >=20 > -- Ian >=20 >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 15:03:00 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8E22B52; Wed, 5 Mar 2014 15:03:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6595033E; Wed, 5 Mar 2014 15:03:00 +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 s25F2xBm031325; Wed, 5 Mar 2014 10:02:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s25F2xPP031322; Wed, 5 Mar 2014 15:02:59 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 5 Mar 2014 15:02:59 GMT Message-Id: <201403051502.s25F2xPP031322@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 15:03:00 -0000 TB --- 2014-03-05 12:00:19 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-03-05 12:00:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-05 12:00:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-03-05 12:00:19 - cleaning the object tree TB --- 2014-03-05 12:05:33 - /usr/local/bin/svn stat /src TB --- 2014-03-05 12:05:37 - At svn revision 262781 TB --- 2014-03-05 12:05:38 - building world TB --- 2014-03-05 12:05:38 - CROSS_BUILD_TESTING=YES TB --- 2014-03-05 12:05:38 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-05 12:05:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-05 12:05:38 - SRCCONF=/dev/null TB --- 2014-03-05 12:05:38 - TARGET=arm TB --- 2014-03-05 12:05:38 - TARGET_ARCH=arm TB --- 2014-03-05 12:05:38 - TZ=UTC TB --- 2014-03-05 12:05:38 - __MAKE_CONF=/dev/null TB --- 2014-03-05 12:05:38 - cd /src TB --- 2014-03-05 12:05:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Mar 5 12:05:44 UTC 2014 >>> 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 [...] cc -O -pipe -Wall -Wmissing-prototypes -Wno-uninitialized -Wstrict-prototypes -DENABLE_ALTQ -I/src/sbin/pfctl -DWITH_INET6 -DWITH_INET -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/sbin/pfctl/pfctl.c /src/sbin/pfctl/pfctl.c:799:25: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] rule->bytes[1]), rule->u_states_cur); ^~~~~~~~~~~~~~~~~~ /src/sbin/pfctl/pfctl.c:804:8: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] rule->u_states_tot); ^~~~~~~~~~~~~~~~~~ 2 errors generated. *** Error code 1 Stop. bmake[3]: stopped in /src/sbin/pfctl *** Error code 1 Stop. bmake[2]: stopped in /src/sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-03-05 15:02:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-05 15:02:59 - ERROR: failed to build world TB --- 2014-03-05 15:02:59 - 8711.56 user 1456.88 system 10959.61 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 18:55:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE3E1E98; Wed, 5 Mar 2014 18:55:58 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA6F4E6D; Wed, 5 Mar 2014 18:55:57 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so1020371lbi.30 for ; Wed, 05 Mar 2014 10:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=I7zc9OQgiYTicjrU8DpLYtH888nxwDgi952COvK+C1o=; b=KporpxlEpERvTCqkrUSvDFJBIwj1uyxHYtwkIjsuIYSjFiXq48bB983EvxOBojxHDo cbBj5uGRHJaI0cspJLd4277FJQxn9iZCjx7oq0vrygfl+DP10pXnpXMa0zMoiiOvloy1 DsmRNGsrmw6tFoeuTY2zwUfh6oxCfiHMrk/+iUzPO58XOSS3WM6OU2ym/j0K6C7DfX5p bYcb86klyryBk4oBK3E3nF8SdsZol6CVgOOAqN7YpBal14VENpcb7zdNbVM4xBqIZDAm MmgjGjFCC4nC/7AAnAk/vhXgLe2sYGBlT+MnLzrVQu9BxrUOH5PxB4u73jL6lVdoPGYs 476Q== MIME-Version: 1.0 X-Received: by 10.152.172.103 with SMTP id bb7mr2520422lac.49.1394045755731; Wed, 05 Mar 2014 10:55:55 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 10:55:55 -0800 (PST) In-Reply-To: <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> Date: Wed, 5 Mar 2014 13:55:55 -0500 X-Google-Sender-Auth: hUgRJUIBql3DzZ-hk-6J0zryuhU Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:55:58 -0000 On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > There's a standard property for mmc/sd devices, "non-removable" whose > > presence denotes things like soldered-on eMMC parts. Only one of our > > many sdhci drivers supports it right now (imx). In general the core > > part of the driver (dev/sdhci) doesn't have good support for > > insert/remove/presence detection that's handled off to the side (whether > > it's non-removable or a gpio pin). > > > > That alone doesn't solve the wider problem, though, which I think breaks > > down into two pieces. Let's say you've got two slots, call them left > > and right. You end up with these two problems... > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > > there's a card in the left slot when I boot; I don't want it to > > change. > > > > And not just a boot-time issue, of course. If you were to remove those > two cards and then reinsert them in the opposite time-order, their device > names would swap. > > > > * I want the slot on the left to be named '1' and the right to be > > '0'. > > > > The first problem is easily solved without impacting dts in any way. We > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > > don't get to choose the names, but you know they won't change based on > > which devices are present. It could be controlled with a tunable. > > > > It's harder to envision the fix for the second part without adding an > > ad-hoc property for the devices. Even with a property I'm not sure how > > easy it would be. > > > > We should be able to assign a geographic address (controllerX:slotY) to > each mmcsd device in a given system (let's ignore for now the theoretical > possibility of multiple cards on one bus). The 'controllerX' part of the > address could be the controller's pathname from the devicetree, or an index > assigned by mmcbr machinery at attach time. The "slotY" part of the > address is assigned by the specific controller device driver using some > internally-determined fixed mapping between the assigned values and its > physical slots. This geographic address could be used to create an > additional set of /dev entries with stable names. There could be a > mechanism for user-configurable aliases for the geographical addresses. > > There's already a chance to run a script when a device is attached that > can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > > Why is mmc so different it needs its own mechanism? > I'm laying out my view of the information that would be needed and the types of actions that would have to be taken based on that information to solve the issue. I'm not saying devd can't be the piece that is used to implement the actions (indeed, I noted devd as a potential building block for a solution in my initial response). I'm also not saying mmc needs its own mechanism, I'm saying it needs /a/ mechanism, and so far there still seems to be something missing (because it's not there, or I'm still ignorant of it). What seems to be missing is geographical addressing for mmc devices. I think what you might be saying is that the existing mmcsd add/remove code could be augmented to send devctl notifications, along the lines of: devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... controller= slot= rca=") and then I and the fine author of devctl and devd would be pleased. -Patrick From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 21:25:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E2841AC for ; Wed, 5 Mar 2014 21:25:07 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C52B9F70 for ; Wed, 5 Mar 2014 21:25:06 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so1755718ieb.12 for ; Wed, 05 Mar 2014 13:25:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1Q85jbcZOR80W0xpcwTOj/Eq244eAbVtni/k61r9+Sc=; b=ZEeNZgSqPGbxSYw2mqh00Iart0NDpHb6LO0y+TYpm78rooms8I8poO+d1CkZqwcMft nVtFbWnn1+og+tuNYi+kDEOq6FW6dwmo3kWs6t0KXy1D2uL6oJVkQm/p0uoorR+JClgB QIsphMdSOG78ftsF5bxUfMYH7wWBWsU57OtybuUVJczuNg6BbtuMOUcQKUlrcejuKrp5 +EaG2BJ+i9sEAi5NM6PppyihimstkBNX9w6MlJfM0+RXxYDfErDJDP3ap9l4rhDhgtIv hYgLcvKSV+VG9c9V4Er+qnoD4zDc9lwTxNQT2WfKH/ayAomOoCqffHfolaqGG5UdHX0S XyPw== X-Gm-Message-State: ALoCoQn50e05v+edxpYyulCSJzRjCAwWGc046tgG4Kwm0KT7ztYbNi7Ygu0x12W2e3X4jt4ZZoYy X-Received: by 10.43.170.193 with SMTP id nr1mr2457087icc.82.1394054700459; Wed, 05 Mar 2014 13:25:00 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f1sm17122264igy.2.2014.03.05.13.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 13:24:59 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 14:24:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:25:07 -0000 On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: >=20 > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: >=20 > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > There's a standard property for mmc/sd devices, "non-removable" = whose > > presence denotes things like soldered-on eMMC parts. Only one of = our > > many sdhci drivers supports it right now (imx). In general the core > > part of the driver (dev/sdhci) doesn't have good support for > > insert/remove/presence detection that's handled off to the side = (whether > > it's non-removable or a gpio pin). > > > > That alone doesn't solve the wider problem, though, which I think = breaks > > down into two pieces. Let's say you've got two slots, call them = left > > and right. You end up with these two problems... > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 = if > > there's a card in the left slot when I boot; I don't want it = to > > change. > > > > And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. > > > > * I want the slot on the left to be named '1' and the right to = be > > '0'. > > > > The first problem is easily solved without impacting dts in any way. = We > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This = is > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- = you > > don't get to choose the names, but you know they won't change based = on > > which devices are present. It could be controlled with a tunable. > > > > It's harder to envision the fix for the second part without adding = an > > ad-hoc property for the devices. Even with a property I'm not sure = how > > easy it would be. > > > > We should be able to assign a geographic address (controllerX:slotY) = to each mmcsd device in a given system (let's ignore for now the = theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. >=20 > There=92s already a chance to run a script when a device is attached = that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. >=20 > Why is mmc so different it needs its own mechanism? >=20 > I'm laying out my view of the information that would be needed and the = types of actions that would have to be taken based on that information = to solve the issue. I'm not saying devd can't be the piece that is used = to implement the actions (indeed, I noted devd as a potential building = block for a solution in my initial response). I'm also not saying mmc = needs its own mechanism, I'm saying it needs /a/ mechanism, and so far = there still seems to be something missing (because it's not there, or = I'm still ignorant of it). >=20 > What seems to be missing is geographical addressing for mmc devices. >=20 > I think what you might be saying is that the existing mmcsd add/remove = code could be augmented to send devctl notifications, along the lines = of: >=20 > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") >=20 > and then I and the fine author of devctl and devd would be pleased. MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: at91_mci0 mmc0 mmcsd0 at rca=3D0xb368 So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is = ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 Warner= From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 21:56:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C2858AA; Wed, 5 Mar 2014 21:56:05 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7E02BE; Wed, 5 Mar 2014 21:56:04 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id y1so1139360lam.37 for ; Wed, 05 Mar 2014 13:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ng7adWkPMKnLijqoT28RKh0vpUtyT+ZOZ/fwDaFiiGM=; b=xkEheOH7OouvT4awjNT3rOGk7usqHOrAqPQ4ij42FOg16Ssk9VwxpPPnwcocJ+R8yD F94Ry4jA3aQFPToQl8Sq0W1y310ljn4qc4y3w21FFA1lpHv75HmEdC9ft5O0UtON5Cc0 9V23CrDsS9w9eXFXLGOc1hrjs7HjLgQhReuheLwbSo+tIJr5j+IXWRPiJKTB7EySs8an MOnxJSmwyUda0lmfRK9nXY+6eHglqbAQ1/Qlk35taWNizHafeCeqbdFjB0W+nCVxRa7U hwwqavb0ZggV4hJ2ed664Lj9MX/28u91HsXVXDsxb2t3FuxtgbghOWCdfMPM09Q6k2Rv adgA== MIME-Version: 1.0 X-Received: by 10.152.181.37 with SMTP id dt5mr3242115lac.43.1394056562325; Wed, 05 Mar 2014 13:56:02 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 13:56:02 -0800 (PST) In-Reply-To: <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> Date: Wed, 5 Mar 2014 16:56:02 -0500 X-Google-Sender-Auth: ZCJ9SdXeFPz5hc2HF0Hels8UoLQ Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:56:05 -0000 On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > > > There's a standard property for mmc/sd devices, "non-removable" whose > > > presence denotes things like soldered-on eMMC parts. Only one of our > > > many sdhci drivers supports it right now (imx). In general the core > > > part of the driver (dev/sdhci) doesn't have good support for > > > insert/remove/presence detection that's handled off to the side > (whether > > > it's non-removable or a gpio pin). > > > > > > That alone doesn't solve the wider problem, though, which I think > breaks > > > down into two pieces. Let's say you've got two slots, call them left > > > and right. You end up with these two problems... > > > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > > > there's a card in the left slot when I boot; I don't want it to > > > change. > > > > > > And not just a boot-time issue, of course. If you were to remove > those two cards and then reinsert them in the opposite time-order, their > device names would swap. > > > > > > * I want the slot on the left to be named '1' and the right to be > > > '0'. > > > > > > The first problem is easily solved without impacting dts in any way. > We > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > > > don't get to choose the names, but you know they won't change based on > > > which devices are present. It could be controlled with a tunable. > > > > > > It's harder to envision the fix for the second part without adding an > > > ad-hoc property for the devices. Even with a property I'm not sure how > > > easy it would be. > > > > > > We should be able to assign a geographic address (controllerX:slotY) > to each mmcsd device in a given system (let's ignore for now the > theoretical possibility of multiple cards on one bus). The 'controllerX' > part of the address could be the controller's pathname from the devicetree, > or an index assigned by mmcbr machinery at attach time. The "slotY" part > of the address is assigned by the specific controller device driver using > some internally-determined fixed mapping between the assigned values and > its physical slots. This geographic address could be used to create an > additional set of /dev entries with stable names. There could be a > mechanism for user-configurable aliases for the geographical addresses. > > > > There's already a chance to run a script when a device is attached that > can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > > > > Why is mmc so different it needs its own mechanism? > > > > I'm laying out my view of the information that would be needed and the > types of actions that would have to be taken based on that information to > solve the issue. I'm not saying devd can't be the piece that is used to > implement the actions (indeed, I noted devd as a potential building block > for a solution in my initial response). I'm also not saying mmc needs its > own mechanism, I'm saying it needs /a/ mechanism, and so far there still > seems to be something missing (because it's not there, or I'm still > ignorant of it). > > > > What seems to be missing is geographical addressing for mmc devices. > > > > I think what you might be saying is that the existing mmcsd add/remove > code could be augmented to send devctl notifications, along the lines of: > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... > controller= > slot= rca=") > > > > and then I and the fine author of devctl and devd would be pleased. > > MMC doesn't need anything special here. That's already present. Looking at > the device tree we see on one of the platforms that's handy for me to > access: > > at91_mci0 > mmc0 > mmcsd0 at rca=0xb368 > > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is > ultimately the FDT node where things came from. There's not a user-defined > slot associated with this (and we should have a SLOT A vs SLOT B as a > location info for this platform, because we can have two cards on the one > bus in the MMC case), true, but for your use case I don't think that you > need it. We should be attaching the host controller regardless of whether > the or not there's a card in there, so it will be fixed. While some > additional information would be useful to publish, I don't think your use > case requires it... > > The reason you need something extra here is that what is there now breaks down whenever you don't have a one-to-one mapping between controllers and buses. Any controller with more than one slot can yield something of the form: sdhci0 mmc0 mmcsd0 at rca=0xabcd mmc1 mmcsd1 at rca=0x1234 and you have no idea what physical slot in the system mmcsd0 and mmcsd1 are in. For my immediate use case, sure, I can rely on the one-to-one relationship between controllers and buses. At this point, though, rather than skate by on that happy coincidence, I'd rather invest what now seems to be a rather small amount of effort adding mmcsd devctl notifications that would cover the multiple-slots-per-controller case as well, and then build the rest of what I want on top of that information coming out of devd. On the at91 platform cited above, that allows you to connect two MMC cards to the same bus (i.e., multidrop configuration), is there any way to distinguish which card is in which physical slot? I'm still under the impression that this is the one case where we aren't going to be able to determine the physical location of every mmcsd device. -Patrick From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 22:44:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F394389C for ; Wed, 5 Mar 2014 22:44:25 +0000 (UTC) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B5007928 for ; Wed, 5 Mar 2014 22:44:25 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id to1so1862701ieb.34 for ; Wed, 05 Mar 2014 14:44:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HOq1Ddfp1unL9wCPfgLIjB5qtYWTIUKcoPHCR3P70ZU=; b=d8qqzrTBi8FxZo+ae3+ljsbkBGGMBptdrdQVeYhLql2igD764p/KVyJfYAC2+inIWj 2Qj7MIm0gNnvAp/+bIkb/cZQTnbxigrE4jQiNmLam1yplDrNLRi7REBM6TaZZjdKuG2X xmYkprtIyP3JahjTAH4LwJqBXfL+jEu2EwFz/RXODOlRlmm5DXOdypInsoh+Z0f5eWhf tpEQ7rKimKhlMthcEVELH3E0iUbElWG+1q+azoQFZhcb0U+aFiD6ZgJ79Nryj/nqCXRv 91p64C93374GV6Y0Y5hLdQfT91Gmc+y1ZVBJajW+TpSoybGkoZPFW/yhsE5VzPO40WHd f3tA== X-Gm-Message-State: ALoCoQn4tJt7ZYqmBqKqSUNu7oRFZ6QjISSJYtpd3JLlytF9/0NQ3sNsmK+0zT9qTFSDnMNxWPTg X-Received: by 10.50.47.79 with SMTP id b15mr12006255ign.12.1394059464805; Wed, 05 Mar 2014 14:44:24 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f1sm17748349igy.2.2014.03.05.14.44.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 14:44:24 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 15:44:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 22:44:26 -0000 On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: >=20 > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: >=20 > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore = wrote: > > > > > > There's a standard property for mmc/sd devices, "non-removable" = whose > > > presence denotes things like soldered-on eMMC parts. Only one of = our > > > many sdhci drivers supports it right now (imx). In general the = core > > > part of the driver (dev/sdhci) doesn't have good support for > > > insert/remove/presence detection that's handled off to the side = (whether > > > it's non-removable or a gpio pin). > > > > > > That alone doesn't solve the wider problem, though, which I think = breaks > > > down into two pieces. Let's say you've got two slots, call them = left > > > and right. You end up with these two problems... > > > > > > * Sometimes the right slot is mmcsd0, but it turns into = mmcsd1 if > > > there's a card in the left slot when I boot; I don't want = it to > > > change. > > > > > > And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. > > > > > > * I want the slot on the left to be named '1' and the right = to be > > > '0'. > > > > > > The first problem is easily solved without impacting dts in any = way. We > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. = This is > > > exactly equivelent to the old ATA_STATIC_ID option in its effect = -- you > > > don't get to choose the names, but you know they won't change = based on > > > which devices are present. It could be controlled with a tunable. > > > > > > It's harder to envision the fix for the second part without adding = an > > > ad-hoc property for the devices. Even with a property I'm not = sure how > > > easy it would be. > > > > > > We should be able to assign a geographic address = (controllerX:slotY) to each mmcsd device in a given system (let's ignore = for now the theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. > > > > There=92s already a chance to run a script when a device is attached = that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. > > > > Why is mmc so different it needs its own mechanism? > > > > I'm laying out my view of the information that would be needed and = the types of actions that would have to be taken based on that = information to solve the issue. I'm not saying devd can't be the piece = that is used to implement the actions (indeed, I noted devd as a = potential building block for a solution in my initial response). I'm = also not saying mmc needs its own mechanism, I'm saying it needs /a/ = mechanism, and so far there still seems to be something missing (because = it's not there, or I'm still ignorant of it). > > > > What seems to be missing is geographical addressing for mmc devices. > > > > I think what you might be saying is that the existing mmcsd = add/remove code could be augmented to send devctl notifications, along = the lines of: > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") > > > > and then I and the fine author of devctl and devd would be pleased. >=20 > MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: >=20 > at91_mci0 > mmc0 > mmcsd0 at rca=3D0xb368 >=20 > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is = ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 >=20 >=20 > The reason you need something extra here is that what is there now = breaks down whenever you don't have a one-to-one mapping between = controllers and buses. Any controller with more than one slot can yield = something of the form: >=20 > sdhci0 > mmc0 > mmcsd0 at rca=3D0xabcd > mmc1 > mmcsd1 at rca=3D0x1234 >=20 > and you have no idea what physical slot in the system mmcsd0 and = mmcsd1 are in. The driver isn=92t going to be able to help you, because it reports mmc0 = based on the data it gets from slot 0 status registers, and mmc1 based = on slot 1 status registers. Since there=92s no notion of how that maps = to physical hardware, the driver can=92t do anything automatically. And = since mmc on down is populated by FreeSBD, there=92s no hints in the FDT = tree for them. > For my immediate use case, sure, I can rely on the one-to-one = relationship between controllers and buses. At this point, though, = rather than skate by on that happy coincidence, I'd rather invest what = now seems to be a rather small amount of effort adding mmcsd devctl = notifications that would cover the multiple-slots-per-controller case as = well, and then build the rest of what I want on top of that information = coming out of ddvd. Trouble is, how do we know what to send with this new notification. = That=92s the part I=92m having trouble with. Where does that data come = from? And how is it different than what=92s in the device tree? > On the at91 platform cited above, that allows you to connect two MMC = cards to the same bus (i.e., multidrop configuration), is there any way = to distinguish which card is in which physical slot? I'm still under = the impression that this is the one case where we aren't going to be = able to determine the physical location of every mmcsd device. Actually, there=92s two different configurations, I believe. One that = supports two SD cards (SLOT A / SLOT B) and one that supports MMC multi = drop. The former has been tested at least once, while the latter I don=92t= think had ever been checked. Warner= From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 23:01:35 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA3B3D0C; Wed, 5 Mar 2014 23:01:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 85124AB9; Wed, 5 Mar 2014 23:01:35 +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 s25N1YX9036255; Wed, 5 Mar 2014 18:01:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s25N1Y2g036250; Wed, 5 Mar 2014 23:01:34 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 5 Mar 2014 23:01:34 GMT Message-Id: <201403052301.s25N1Y2g036250@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 23:01:36 -0000 TB --- 2014-03-05 19:50:16 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-03-05 19:50:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-05 19:50:16 - starting HEAD tinderbox run for arm/arm TB --- 2014-03-05 19:50:16 - cleaning the object tree TB --- 2014-03-05 19:56:29 - /usr/local/bin/svn stat /src TB --- 2014-03-05 19:56:32 - At svn revision 262803 TB --- 2014-03-05 19:56:33 - building world TB --- 2014-03-05 19:56:33 - CROSS_BUILD_TESTING=YES TB --- 2014-03-05 19:56:33 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-05 19:56:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-05 19:56:33 - SRCCONF=/dev/null TB --- 2014-03-05 19:56:33 - TARGET=arm TB --- 2014-03-05 19:56:33 - TARGET_ARCH=arm TB --- 2014-03-05 19:56:33 - TZ=UTC TB --- 2014-03-05 19:56:33 - __MAKE_CONF=/dev/null TB --- 2014-03-05 19:56:33 - cd /src TB --- 2014-03-05 19:56:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Mar 5 19:56:40 UTC 2014 >>> 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 [...] cc -O -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET -DINET6 -DPF -DNETGRAPH -DIPX -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c /src/usr.bin/netstat/route.c /src/usr.bin/netstat/route.c:333:7: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] kread_counter((u_long )rt->rt_pksent)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/usr.bin/netstat/route.c:871:7: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] kread_counter((u_long )rt->rt_pksent)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2 errors generated. *** Error code 1 Stop. bmake[3]: stopped in /src/usr.bin/netstat *** Error code 1 Stop. bmake[2]: stopped in /src/usr.bin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-03-05 23:01:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-05 23:01:34 - ERROR: failed to build world TB --- 2014-03-05 23:01:34 - 9066.55 user 1529.34 system 11477.84 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 23:11:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E03F013D for ; Wed, 5 Mar 2014 23:11:53 +0000 (UTC) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C64EDB0D for ; Wed, 5 Mar 2014 23:11:53 +0000 (UTC) Received: from mail.nomadlogic.org (localhost [127.0.0.1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPS id B033F125EC6 for ; Wed, 5 Mar 2014 15:11:46 -0800 (PST) Received: from pop.rubicorp.com (unknown [72.34.113.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPSA id 9458A125EAD for ; Wed, 5 Mar 2014 15:11:46 -0800 (PST) Message-ID: <5317AF31.8050408@nomadlogic.org> Date: Wed, 05 Mar 2014 15:11:45 -0800 From: Pete Wright User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: CompuLab - FreeScale i.MX6 CPU References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 23:11:53 -0000 On 03/04/14 23:17, zkan KIRIK wrote: > Hi, > > I am interested with CompuLab Utilite Standart board. ( > http://utilite-computer.com/web/utilite-models ) > I saw that over SVN, FreeBSD has i.MX6 cpu support. > What about drivers of this board? > > Does HDMI and NICs works? > > Can you suggest a cheap and two ethernet arm board that FreeBSD works. > hey there Ozkan - I am hacking on getting this working in my minimal spare time. there are a couple major issues i've run into: 1) not really full featured u-boot environment, no usb boot support for example 2) flaky microSD support (had to try out several different cards to find a working one from sandisk) 3) network stack w/in u-boot has been unstable (unable to tftpboot images due to timeouts) the board does have some potential though - but it is not plug-and-play at this point. having said that - the up side is there is ton's of opportunity to make an impact on getting support for this device working in the freebsd-arm community :) cheers, -pete -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 00:53:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0C23811; Thu, 6 Mar 2014 00:53:13 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE6FF64B; Thu, 6 Mar 2014 00:53:12 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so1276322lbi.30 for ; Wed, 05 Mar 2014 16:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=q/enwDvvL6xYQB36OxlVhzTMsF1J81oWV/NRWNPFDd8=; b=WoedIAuoQiwKgK4JubQ6fNYUJeAbgeYcXeu5dMPUcyGnNlY1j23DbC+WUGxKohUGVI cQLtTOd9lnKGcEZebx4VNFDgueheWPRTZlMrJAF+Cq9JVjROObscTVhwVCCFzuhFRxL1 oxX1Q0KoJkLlg1rIbPc+HbhTxCysohUAIL6YOaeCvkznDQ3b9akurAyWBRaeH9IE8UKR bilvw87e1PQVvykeOQImRYIINB99uBqhESHscDQpZzFSj9BTYUGe+xKMxJb/7GSSRZ3z xb6Fszw4rG81mjxVsTFBWnz9+wo0Ca9UGnQMJYN7g2RE7j1QRz0oGJiCvz/xmLVXILpH 1J1A== MIME-Version: 1.0 X-Received: by 10.152.234.130 with SMTP id ue2mr5781303lac.0.1394067190985; Wed, 05 Mar 2014 16:53:10 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 16:53:10 -0800 (PST) In-Reply-To: <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> Date: Wed, 5 Mar 2014 19:53:10 -0500 X-Google-Sender-Auth: 8ktgL6o7K4ty-hbimS3WPZBpxlU Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:53:14 -0000 On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: > > On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: > > > > > > > > > On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > > > > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > > > > > There's a standard property for mmc/sd devices, "non-removable" whose > > > > presence denotes things like soldered-on eMMC parts. Only one of our > > > > many sdhci drivers supports it right now (imx). In general the core > > > > part of the driver (dev/sdhci) doesn't have good support for > > > > insert/remove/presence detection that's handled off to the side > (whether > > > > it's non-removable or a gpio pin). > > > > > > > > That alone doesn't solve the wider problem, though, which I think > breaks > > > > down into two pieces. Let's say you've got two slots, call them left > > > > and right. You end up with these two problems... > > > > > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 > if > > > > there's a card in the left slot when I boot; I don't want it > to > > > > change. > > > > > > > > And not just a boot-time issue, of course. If you were to remove > those two cards and then reinsert them in the opposite time-order, their > device names would swap. > > > > > > > > * I want the slot on the left to be named '1' and the right to > be > > > > '0'. > > > > > > > > The first problem is easily solved without impacting dts in any way. > We > > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This > is > > > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- > you > > > > don't get to choose the names, but you know they won't change based > on > > > > which devices are present. It could be controlled with a tunable. > > > > > > > > It's harder to envision the fix for the second part without adding an > > > > ad-hoc property for the devices. Even with a property I'm not sure > how > > > > easy it would be. > > > > > > > > We should be able to assign a geographic address (controllerX:slotY) > to each mmcsd device in a given system (let's ignore for now the > theoretical possibility of multiple cards on one bus). The 'controllerX' > part of the address could be the controller's pathname from the devicetree, > or an index assigned by mmcbr machinery at attach time. The "slotY" part > of the address is assigned by the specific controller device driver using > some internally-determined fixed mapping between the assigned values and > its physical slots. This geographic address could be used to create an > additional set of /dev entries with stable names. There could be a > mechanism for user-configurable aliases for the geographical addresses. > > > > > > There's already a chance to run a script when a device is attached > that can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > > > > > > Why is mmc so different it needs its own mechanism? > > > > > > I'm laying out my view of the information that would be needed and the > types of actions that would have to be taken based on that information to > solve the issue. I'm not saying devd can't be the piece that is used to > implement the actions (indeed, I noted devd as a potential building block > for a solution in my initial response). I'm also not saying mmc needs its > own mechanism, I'm saying it needs /a/ mechanism, and so far there still > seems to be something missing (because it's not there, or I'm still > ignorant of it). > > > > > > What seems to be missing is geographical addressing for mmc devices. > > > > > > I think what you might be saying is that the existing mmcsd add/remove > code could be augmented to send devctl notifications, along the lines of: > > > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... > controller= > slot= rca=") > > > > > > and then I and the fine author of devctl and devd would be pleased. > > > > MMC doesn't need anything special here. That's already present. Looking > at the device tree we see on one of the platforms that's handy for me to > access: > > > > at91_mci0 > > mmc0 > > mmcsd0 at rca=0xb368 > > > > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is > ultimately the FDT node where things came from. There's not a user-defined > slot associated with this (and we should have a SLOT A vs SLOT B as a > location info for this platform, because we can have two cards on the one > bus in the MMC case), true, but for your use case I don't think that you > need it. We should be attaching the host controller regardless of whether > the or not there's a card in there, so it will be fixed. While some > additional information would be useful to publish, I don't think your use > case requires it... > > > > > > The reason you need something extra here is that what is there now > breaks down whenever you don't have a one-to-one mapping between > controllers and buses. Any controller with more than one slot can yield > something of the form: > > > > sdhci0 > > mmc0 > > mmcsd0 at rca=0xabcd > > mmc1 > > mmcsd1 at rca=0x1234 > > > > and you have no idea what physical slot in the system mmcsd0 and mmcsd1 > are in. > > The driver isn't going to be able to help you, because it reports mmc0 > based on the data it gets from slot 0 status registers, and mmc1 based on > slot 1 status registers. Since there's no notion of how that maps to > physical hardware, the driver can't do anything automatically. And since > mmc on down is populated by FreeSBD, there's no hints in the FDT tree for > them. > > > For my immediate use case, sure, I can rely on the one-to-one > relationship between controllers and buses. At this point, though, rather > than skate by on that happy coincidence, I'd rather invest what now seems > to be a rather small amount of effort adding mmcsd devctl notifications > that would cover the multiple-slots-per-controller case as well, and then > build the rest of what I want on top of that information coming out of ddvd. > > Trouble is, how do we know what to send with this new notification. That's > the part I'm having trouble with. Where does that data come from? And how > is it different than what's in the device tree? > > Each controller driver maintains an instance of struct mmc_host for each physical bus interface (typically referred to as a 'slot' in the drivers) it has. When a card is detected in a given slot by the driver, the driver creates an mmc bus instance and attaches the struct mmc_host corresponding to that slot to provide the ivar values. So let's say struct mmc_host gets a new member 'slot_number', and a new ivar MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of struct mmc_host a driver maintains gets set to a controller-relative index of the corresponding physical interface - the controller will do this the same way every time, because it is tied to the register layout of the controller. After the mmc bus instance is created and its ivars are set, probe-and-attach is run on that bus, and an mmcsd device instance is created for each card that is found. At the point where the mmcsd device instance is created, one knows the parent bus for that new mmcsd device, and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that bus, as well as the name of the controller device instance that is the parent of the parent bus. It thus possible at that point to devctl_notify("MMC", "DEVICE", "ATTACH", "... controller= slot= ") Because the controller attachment order is the same on every boot, as is the slot number ivar for a given bus interface on each controller hardware instance, an identical attach message will be generated every time a card is discovered in that physical location in the system. For a given system, there will thus be a fixed mapping between {controller_instance,slot} tuples that appear in these messages and the physical MMC/SD device locations. In the above, I've left out the value of rca from the discussion because upon further reflection, it cannot be stably tied to a physical location. If there is a multidrop MMC bus in a system, the physical card locations on that bus will not be able to be referred to with stable names. This is the one area where a new property in the FDT could be useful to convey multidrop-or-not for each bus interface on a controller. The new property could be 'freebsd,max-devices' and would be an array of cells that indicates the maximum number of MMC/SD devices that can be connected to the controller bus interface corresponding to that cell index. The devctl notification could then include a multidrop indicator in the message. > > On the at91 platform cited above, that allows you to connect two MMC > cards to the same bus (i.e., multidrop configuration), is there any way to > distinguish which card is in which physical slot? I'm still under the > impression that this is the one case where we aren't going to be able to > determine the physical location of every mmcsd device. > > Actually, there's two different configurations, I believe. One that > supports two SD cards (SLOT A / SLOT B) and one that supports MMC multi > drop. The former has been tested at least once, while the latter I don't > think had ever been checked. > I think MMC multidrop will remain a limitation, and perhaps an insignificant one (does *anyone* know of a current system that does this?). -Patrick From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 01:03:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C97C8A61 for ; Thu, 6 Mar 2014 01:03:08 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BF9F766 for ; Thu, 6 Mar 2014 01:03:08 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id fb1so1877533pad.15 for ; Wed, 05 Mar 2014 17:03:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=7sbU++ktENm+Fyc+1OZHbIBRsCavaa50VhRDyZ7/RLY=; b=I2qBmoNEho4XE3KiVSLbFAkxmQPZNEzSgR5Sgp5H2vMfQ2bymEc/JOExrjChUu9YoB Jk+Jkm/2v3hyl8sYJLSQuCfYJKSxJRXca/Uhm4iuWWHvXs9ScqufSbpdIYkifMMVG7Xx bM2G/ZOikTsIFYyelaQXgNmDYaeYCna/r2FOiDKviyDPJAf3VAvhiEi74jkIbh6EaqSC QQb0mbLLyo36SEICsdDv6bJAM8PLgLee/mSj/a5R2/pTp5Z1iFIzecJu2FyPxjTGkfX6 38Ojsi0SVlel8nSyLpK5zsZmI8njS2vV5OE+eBb7ygGC+fWBRUmDvYZeB8TdQlWGacyK J92g== X-Gm-Message-State: ALoCoQnNIJipsSwbyliUWrKLv+y3GquVpYtscHs1obXoz+CKNamQnkyU0+tAmpLGH147BxaTWhmd X-Received: by 10.68.245.162 with SMTP id xp2mr10768179pbc.69.1394067782329; Wed, 05 Mar 2014 17:03:02 -0800 (PST) Received: from lglt-rottaway.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id sm5sm24991394pab.19.2014.03.05.17.03.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 17:03:01 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 18:02:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 01:03:08 -0000 On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: >=20 > On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >=20 > > > > > > > > On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > > > > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh = wrote: > > > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey = wrote: > > > > > > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore = wrote: > > > > > > > > There's a standard property for mmc/sd devices, "non-removable" = whose > > > > presence denotes things like soldered-on eMMC parts. Only one = of our > > > > many sdhci drivers supports it right now (imx). In general the = core > > > > part of the driver (dev/sdhci) doesn't have good support for > > > > insert/remove/presence detection that's handled off to the side = (whether > > > > it's non-removable or a gpio pin). > > > > > > > > That alone doesn't solve the wider problem, though, which I = think breaks > > > > down into two pieces. Let's say you've got two slots, call them = left > > > > and right. You end up with these two problems... > > > > > > > > * Sometimes the right slot is mmcsd0, but it turns into = mmcsd1 if > > > > there's a card in the left slot when I boot; I don't = want it to > > > > change. > > > > > > > > And not just a boot-time issue, of course. If you were to = remove those two cards and then reinsert them in the opposite = time-order, their device names would swap. > > > > > > > > * I want the slot on the left to be named '1' and the = right to be > > > > '0'. > > > > > > > > The first problem is easily solved without impacting dts in any = way. We > > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. = This is > > > > exactly equivelent to the old ATA_STATIC_ID option in its effect = -- you > > > > don't get to choose the names, but you know they won't change = based on > > > > which devices are present. It could be controlled with a = tunable. > > > > > > > > It's harder to envision the fix for the second part without = adding an > > > > ad-hoc property for the devices. Even with a property I'm not = sure how > > > > easy it would be. > > > > > > > > We should be able to assign a geographic address = (controllerX:slotY) to each mmcsd device in a given system (let's ignore = for now the theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. > > > > > > There=92s already a chance to run a script when a device is = attached that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. > > > > > > Why is mmc so different it needs its own mechanism? > > > > > > I'm laying out my view of the information that would be needed and = the types of actions that would have to be taken based on that = information to solve the issue. I'm not saying devd can't be the piece = that is used to implement the actions (indeed, I noted devd as a = potential building block for a solution in my initial response). I'm = also not saying mmc needs its own mechanism, I'm saying it needs /a/ = mechanism, and so far there still seems to be something missing (because = it's not there, or I'm still ignorant of it). > > > > > > What seems to be missing is geographical addressing for mmc = devices. > > > > > > I think what you might be saying is that the existing mmcsd = add/remove code could be augmented to send devctl notifications, along = the lines of: > > > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") > > > > > > and then I and the fine author of devctl and devd would be = pleased. > > > > MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: > > > > at91_mci0 > > mmc0 > > mmcsd0 at rca=3D0xb368 > > > > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which = is ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 > > > > > > The reason you need something extra here is that what is there now = breaks down whenever you don't have a one-to-one mapping between = controllers and buses. Any controller with more than one slot can yield = something of the form: > > > > sdhci0 > > mmc0 > > mmcsd0 at rca=3D0xabcd > > mmc1 > > mmcsd1 at rca=3D0x1234 > > > > and you have no idea what physical slot in the system mmcsd0 and = mmcsd1 are in. >=20 > The driver isn=92t going to be able to help you, because it reports = mmc0 based on the data it gets from slot 0 status registers, and mmc1 = based on slot 1 status registers. Since there=92s no notion of how that = maps to physical hardware, the driver can=92t do anything automatically. = And since mmc on down is populated by FreeSBD, there=92s no hints in the = FDT tree for them. >=20 >=20 > > For my immediate use case, sure, I can rely on the one-to-one = relationship between controllers and buses. At this point, though, = rather than skate by on that happy coincidence, I'd rather invest what = now seems to be a rather small amount of effort adding mmcsd devctl = notifications that would cover the multiple-slots-per-controller case as = well, and then build the rest of what I want on top of that information = coming out of ddvd. >=20 > Trouble is, how do we know what to send with this new notification. = That=92s the part I=92m having trouble with. Where does that data come = from? And how is it different than what=92s in the device tree? >=20 >=20 > Each controller driver maintains an instance of struct mmc_host for = each physical bus interface (typically referred to as a 'slot' in the = drivers) it has. When a card is detected in a given slot by the driver, = the driver creates an mmc bus instance and attaches the struct mmc_host = corresponding to that slot to provide the ivar values. So let's say = struct mmc_host gets a new member 'slot_number', and a new ivar = MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of = struct mmc_host a driver maintains gets set to a controller-relative = index of the corresponding physical interface - the controller will do = this the same way every time, because it is tied to the register layout = of the controller. >=20 > After the mmc bus instance is created and its ivars are set, = probe-and-attach is run on that bus, and an mmcsd device instance is = created for each card that is found. At the point where the mmcsd = device instance is created, one knows the parent bus for that new mmcsd = device, and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that = bus, as well as the name of the controller device instance that is the = parent of the parent bus. It thus possible at that point to=20 >=20 > devctl_notify("MMC", "DEVICE", "ATTACH", "... = controller=3D = slot=3D ") >=20 > Because the controller attachment order is the same on every boot, as = is the slot number ivar for a given bus interface on each controller = hardware instance, an identical attach message will be generated every = time a card is discovered in that physical location in the system. For = a given system, there will thus be a fixed mapping between = {controller_instance,slot} tuples that appear in these messages and the = physical MMC/SD device locations. I=92m curious how that=92s materially different than the parent=92s mmc = instance number. That too is invariant between boots. There=92s a 1:1 - = onto mapping between this instance number and any controller/slot tuple = that would be created. Also, there doesn=92t need to be a special MMC message for this. If we = do create the notion of a slot number per controller, that would be part = of the location information that is in the location string for the = normal attach message. > In the above, I've left out the value of rca from the discussion = because upon further reflection, it cannot be stably tied to a physical = location. If there is a multidrop MMC bus in a system, the physical = card locations on that bus will not be able to be referred to with = stable names. This is the one area where a new property in the FDT = could be useful to convey multidrop-or-not for each bus interface on a = controller. The new property could be 'freebsd,max-devices' and would = be an array of cells that indicates the maximum number of MMC/SD devices = that can be connected to the controller bus interface corresponding to = that cell index. The devctl notification could then include a multidrop = indicator in the message. rca is more of a serial number than a location number. Useful for other = reasons. I=92m not sure how =91freebsd,max-devices=92 would solve the problem. = The controller already knows that. If we really want to tie things to a = physical location/ description, I=92d opt for something more like = =91freebsd,slot-names =3D =93Slot 0=94, =93Slot 1=94;=92 type of thing, = where you could just as easily have =93Top Card=94 =93bottom card=94 or = =93boot card=94 and =93customer card=94 if you wanted. Then the = controller could query this property to get the names to populate = somewhere in the PNP info for this device. The mmcsd driver would then = be free to also create a /dev/Blah alias as well for the disk, but I = don=92t know if that would cause aliases to get created for all the geom = children or not... > > On the at91 platform cited above, that allows you to connect two MMC = cards to the same bus (i.e., multidrop configuration), is there any way = to distinguish which card is in which physical slot? I'm still under = the impression that this is the one case where we aren't going to be = able to determine the physical location of every mmcsd device. >=20 > Actually, there=92s two different configurations, I believe. One that = supports two SD cards (SLOT A / SLOT B) and one that supports MMC multi = drop. The former has been tested at least once, while the latter I don=92t= think had ever been checked. >=20 > I think MMC multidrop will remain a limitation, and perhaps an = insignificant one (does *anyone* know of a current system that does = this?). I=92ve never heard of anybody trying this and having it fail in the past = 8 or so years since I wrote the SD/MMC stack. At the time I wrote it, it = was already ancient history=85 Warner= From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 02:48:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EB012FB; Thu, 6 Mar 2014 02:48:57 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF25BF1C; Thu, 6 Mar 2014 02:48:56 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id x3so2241400qcv.39 for ; Wed, 05 Mar 2014 18:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=4/A2H+UPg0fQbuHEF8sPKkJWLna4IZhWjRoy7VgDBCU=; b=bYRNRKA/9GTei0KzMEPLQ3YaPsthw6IjYFdaB9SoDXYcBixyEl9o+b3CTmP+nom8ED 0nbpjZkjIl3HLpgy07jm8Iqxc3Il+penhh6YuC/dNCFa7t4qe0ehro4qLuQFvmYYltr5 y2cyPstCJFws3fIYtW2zcbAabPiHeRFXleKpwnBhfIZpF3eWJYJnY748RgwWq7ehXf/V xrTQKKLjwIsN98SaRsZMdjom8iPtO0Vjk3AF6E+dvxRwApvGpSWSOzqySbLdnHQucLvF H6vdcGK2mzyoyOyVR+wefiPDm/+dIq5kV9wPiGEh68Lj4XLdMNV2cURwQs/vNTOGYbqG XUvg== X-Received: by 10.140.40.5 with SMTP id w5mr10374914qgw.65.1394074136077; Wed, 05 Mar 2014 18:48:56 -0800 (PST) Received: from [172.16.0.124] (c-174-54-20-106.hsd1.pa.comcast.net. [174.54.20.106]) by mx.google.com with ESMTPSA id v12sm14100254qav.23.2014.03.05.18.48.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 18:48:54 -0800 (PST) Sender: Patrick Kelsey References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> Mime-Version: 1.0 (1.0) In-Reply-To: <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> X-Mailer: iPhone Mail (10B329) From: Patrick Kelsey Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) Date: Wed, 5 Mar 2014 21:48:50 -0500 To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 02:48:57 -0000 On Mar 5, 2014, at 8:02 PM, Warner Losh wrote: >=20 > On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: >=20 >>=20 >>=20 >>=20 >> On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: >>=20 >> On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: >>>=20 >>> On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: >>>>=20 >>>> On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: >>>>>=20 >>>>> There's a standard property for mmc/sd devices, "non-removable" whose >>>>> presence denotes things like soldered-on eMMC parts. Only one of our >>>>> many sdhci drivers supports it right now (imx). In general the core >>>>> part of the driver (dev/sdhci) doesn't have good support for >>>>> insert/remove/presence detection that's handled off to the side (wheth= er >>>>> it's non-removable or a gpio pin). >>>>>=20 >>>>> That alone doesn't solve the wider problem, though, which I think brea= ks >>>>> down into two pieces. Let's say you've got two slots, call them left >>>>> and right. You end up with these two problems... >>>>>=20 >>>>> * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if= >>>>> there's a card in the left slot when I boot; I don't want it to= >>>>> change. >>>>>=20 >>>>> And not just a boot-time issue, of course. If you were to remove thos= e two cards and then reinsert them in the opposite time-order, their device n= ames would swap. >>>>>=20 >>>>> * I want the slot on the left to be named '1' and the right to be= >>>>> '0'. >>>>>=20 >>>>> The first problem is easily solved without impacting dts in any way. W= e >>>>> just wire down the relationship controllerN -> mmcN -> mmcsdN. This i= s >>>>> exactly equivelent to the old ATA_STATIC_ID option in its effect -- yo= u >>>>> don't get to choose the names, but you know they won't change based on= >>>>> which devices are present. It could be controlled with a tunable. >>>>>=20 >>>>> It's harder to envision the fix for the second part without adding an >>>>> ad-hoc property for the devices. Even with a property I'm not sure ho= w >>>>> easy it would be. >>>>>=20 >>>>> We should be able to assign a geographic address (controllerX:slotY) t= o each mmcsd device in a given system (let's ignore for now the theoretical p= ossibility of multiple cards on one bus). The 'controllerX' part of the add= ress could be the controller's pathname from the devicetree, or an index ass= igned by mmcbr machinery at attach time. The "slotY" part of the address is= assigned by the specific controller device driver using some internally-det= ermined fixed mapping between the assigned values and its physical slots. T= his geographic address could be used to create an additional set of /dev ent= ries with stable names. There could be a mechanism for user-configurable al= iases for the geographical addresses. >>>>=20 >>>> There=E2=80=99s already a chance to run a script when a device is attac= hed that can create /dev/slot0 or /dev/slot1 that has geographical informati= on available to it. People use ddvd for this in the USB world all the time t= o make sure that tty devices get a symlink based on their location or serial= number. >>>>=20 >>>> Why is mmc so different it needs its own mechanism? >>>>=20 >>>> I'm laying out my view of the information that would be needed and the t= ypes of actions that would have to be taken based on that information to sol= ve the issue. I'm not saying devd can't be the piece that is used to implem= ent the actions (indeed, I noted devd as a potential building block for a so= lution in my initial response). I'm also not saying mmc needs its own mecha= nism, I'm saying it needs /a/ mechanism, and so far there still seems to be s= omething missing (because it's not there, or I'm still ignorant of it). >>>>=20 >>>> What seems to be missing is geographical addressing for mmc devices. >>>>=20 >>>> I think what you might be saying is that the existing mmcsd add/remove c= ode could be augmented to send devctl notifications, along the lines of: >>>>=20 >>>> devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... controller=3D slot=3D rca= =3D") >>>>=20 >>>> and then I and the fine author of devctl and devd would be pleased. >>>=20 >>> MMC doesn=E2=80=99t need anything special here. That=E2=80=99s already p= resent. Looking at the device tree we see on one of the platforms that=E2=80= =99s handy for me to access: >>>=20 >>> at91_mci0 >>> mmc0 >>> mmcsd0 at rca=3D0xb368 >>>=20 >>> So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is u= ltimately the FDT node where things came from. There=E2=80=99s not a user-de= fined slot associated with this (and we should have a SLOT A vs SLOT B as a l= ocation info for this platform, because we can have two cards on the one bus= in the MMC case), true, but for your use case I don=E2=80=99t think that yo= u need it. We should be attaching the host controller regardless of whether t= he or not there=E2=80=99s a card in there, so it will be fixed. While some a= dditional information would be useful to publish, I don=E2=80=99t think your= use case requires it=E2=80=A6 >>>=20 >>>=20 >>> The reason you need something extra here is that what is there now break= s down whenever you don't have a one-to-one mapping between controllers and b= uses. Any controller with more than one slot can yield something of the for= m: >>>=20 >>> sdhci0 >>> mmc0 >>> mmcsd0 at rca=3D0xabcd >>> mmc1 >>> mmcsd1 at rca=3D0x1234 >>>=20 >>> and you have no idea what physical slot in the system mmcsd0 and mmcsd1 a= re in. >>=20 >> The driver isn=E2=80=99t going to be able to help you, because it reports= mmc0 based on the data it gets from slot 0 status registers, and mmc1 based= on slot 1 status registers. Since there=E2=80=99s no notion of how that map= s to physical hardware, the driver can=E2=80=99t do anything automatically. A= nd since mmc on down is populated by FreeSBD, there=E2=80=99s no hints in th= e FDT tree for them. >>=20 >>=20 >>> For my immediate use case, sure, I can rely on the one-to-one relationsh= ip between controllers and buses. At this point, though, rather than skate b= y on that happy coincidence, I'd rather invest what now seems to be a rather= small amount of effort adding mmcsd devctl notifications that would cover t= he multiple-slots-per-controller case as well, and then build the rest of wh= at I want on top of that information coming out of ddvd. >>=20 >> Trouble is, how do we know what to send with this new notification. That=E2= =80=99s the part I=E2=80=99m having trouble with. Where does that data come f= rom? And how is it different than what=E2=80=99s in the device tree? >>=20 >>=20 >> Each controller driver maintains an instance of struct mmc_host for each p= hysical bus interface (typically referred to as a 'slot' in the drivers) it= has. When a card is detected in a given slot by the driver, the driver cre= ates an mmc bus instance and attaches the struct mmc_host corresponding to t= hat slot to provide the ivar values. So let's say struct mmc_host gets a ne= w member 'slot_number', and a new ivar MMC_IVAR_SLOT_NUMBER is defined. The= slot number in each instance of struct mmc_host a driver maintains gets set= to a controller-relative index of the corresponding physical interface - th= e controller will do this the same way every time, because it is tied to the= register layout of the controller. >>=20 >> After the mmc bus instance is created and its ivars are set, probe-and-at= tach is run on that bus, and an mmcsd device instance is created for each ca= rd that is found. At the point where the mmcsd device instance is created, o= ne knows the parent bus for that new mmcsd device, and thus one can get the v= alue of MMC_IVAR_SLOT_NUMBER for that bus, as well as the name of the contro= ller device instance that is the parent of the parent bus. It thus possible= at that point to=20 >>=20 >> devctl_notify("MMC", "DEVICE", "ATTACH", "... controller=3D slot=3D ") >>=20 >> Because the controller attachment order is the same on every boot, as is t= he slot number ivar for a given bus interface on each controller hardware in= stance, an identical attach message will be generated every time a card is d= iscovered in that physical location in the system. For a given system, ther= e will thus be a fixed mapping between {controller_instance,slot} tuples tha= t appear in these messages and the physical MMC/SD device locations. >=20 > I=E2=80=99m curious how that=E2=80=99s materially different than the paren= t=E2=80=99s mmc instance number. That too is invariant between boots. There=E2= =80=99s a 1:1 - onto mapping between this instance number and any controller= /slot tuple that would be created. >=20 Controller instance (unit) numbers are the same across boots. The mmc insta= nce (unit) number for the mmc instance created for a given bus interface on a= given controller is not, because the instance is created dynamically in res= ponse to card detection and thus depends on the ordering of card insertions.= Sure, there's a one-to-one and onto mapping at any given moment between mm= c instance numbers and the tuples I'm talking about, but the mapping is subj= ect to change with card insertions and removals. The material difference be= tween the two sets of labels is that a given tuple value will *always* refer= to the same physical device location in the system, whereas a given mmc uni= t number could refer to any physical device location in the system depending= on the time order of insertions in the various card slots. > Also, there doesn=E2=80=99t need to be a special MMC message for this. If w= e do create the notion of a slot number per controller, that would be part o= f the location information that is in the location string for the normal att= ach message Ah, so I can just append more variable definitions to the location string, w= hich is already fed through to the existing generic devctl notification? Wo= rks for me. >> In the above, I've left out the value of rca from the discussion because u= pon further reflection, it cannot be stably tied to a physical location. If= there is a multidrop MMC bus in a system, the physical card locations on th= at bus will not be able to be referred to with stable names. This is the on= e area where a new property in the FDT could be useful to convey multidrop-o= r-not for each bus interface on a controller. The new property could be 'fr= eebsd,max-devices' and would be an array of cells that indicates the maximum= number of MMC/SD devices that can be connected to the controller bus interf= ace corresponding to that cell index. The devctl notification could then in= clude a multidrop indicator in the message. >=20 > rca is more of a serial number than a location number. Useful for other re= asons. >=20 > I=E2=80=99m not sure how =E2=80=98freebsd,max-devices=E2=80=99 would solve= the problem. The controller already knows that. If we really want to tie th= ings to a physical location/ description, I=E2=80=99d opt for something more= like =E2=80=98freebsd,slot-names =3D =E2=80=9CSlot 0=E2=80=9D, =E2=80=9CSlo= t 1=E2=80=9D;=E2=80=99 type of thing, where you could just as easily have =E2= =80=9CTop Card=E2=80=9D =E2=80=9Cbottom card=E2=80=9D or =E2=80=9Cboot card=E2= =80=9D and =E2=80=9Ccustomer card=E2=80=9D if you wanted. Then the controlle= r could query this property to get the names to populate somewhere in the PN= P info for this device. The mmcsd driver would then be free to also create a= /dev/Blah alias as well for the disk, but I don=E2=80=99t know if that woul= d cause aliases to get created for all the geom children or not... >=20 freebsd,max-devices is not already known by the controller. The controller k= nows how many bus interfaces it has, but it doesn't know how many devices ca= n be attached to that bus, as that depends on the board design. freebsd,max= -devices informs us whether the board design is multidrop or not for each bu= s interface on each controller. Passing through a multidrop indication in t= he devctl notification informs the devctl consumer as to whether or not a un= ique stable name can be assigned to the mmcsd instance based on the tuple (i= f multidrop, then no). Not essential, but would be thorough. I disagree with 'freebsd,slot-names' because meaningful/descriptive slot nam= es are going to be something that are often defined at the product level, so= I think it's better to just let them be defined via a devd action script. O= therwise we build in an invitation to the experience of having board-level s= lot names and product-level slot names from the same namespace, which is in m= y experience awful. "Oh, wait, does this bug report refer to board-'top slo= t' or front-panel-'top slot'?" In other words, I think it's handy to have u= p until the board goes into an enclosure, then it could be trouble from then= on. Plus it could also encourage further knee-jerk, inappropriate .dts pat= ching of the sort I started out with here :) "Why make a devd script when I c= an just edit the names in the .dts file?" Agreed geom children are an open question. -Patrick= From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 03:53:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22735E23 for ; Thu, 6 Mar 2014 03:53:08 +0000 (UTC) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB21A770 for ; Thu, 6 Mar 2014 03:53:07 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id fa1so2061086pad.28 for ; Wed, 05 Mar 2014 19:53:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=tiIANlcRjuRuB95hHe5CQhbKfLDg1t4mKn9lwSaGQKU=; b=OuPZpMRjrJzEPd79NdftSyK8UeFPkYBuBnxm5bCOiJ3fQuMTCO7g9+L1R8/+uuSiIl 9E5JQV9B11moG7rw/n/KaBx8P4cJWz7azWMC+6L7vKJQuP/f1FaeoLEJaUyXpSj/Ysba J4cwFlLCGWtg7/Gc8mFCPGW9sbJx1CRwZgCvDV5vmc2T/h/gSpNsCiXGijmisyhZwJAz 2PXyQEkxAAWqvPsNLFaK2nWPAf+uy+g7EdNvr9Wmqkcge6Uw86iDCuuYMBpxAUHhhKSO zrYBH8Tb0mVWI8senTUhVK2MI5Mfl/M8FC647BnrSAdpeFDF8yKb2mt5J2aIbV6nxZh9 cpYQ== X-Gm-Message-State: ALoCoQnxrzUfSxRRNe5YIe4mpKKCKwsRyDBRIq13hzG57U2wwY1XoFpSB34s+VOVKz2fuWvCaQ/m X-Received: by 10.66.141.165 with SMTP id rp5mr11713909pab.90.1394077981033; Wed, 05 Mar 2014 19:53:01 -0800 (PST) Received: from lglt-rottaway.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id yo9sm27484830pab.16.2014.03.05.19.52.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 19:53:00 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> Date: Wed, 5 Mar 2014 20:52:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F5BD549-6A25-48F5-989A-F2D43C241CFF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 03:53:08 -0000 On Mar 5, 2014, at 7:48 PM, Patrick Kelsey wrote: >=20 >=20 > On Mar 5, 2014, at 8:02 PM, Warner Losh wrote: >=20 >>=20 >> On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: >>>=20 >>> On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: >>>>=20 >>>> On Mar 5, 2014, at 11:55 AM, Patrick Kelsey = wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh = wrote: >>>>>=20 >>>>> On Mar 4, 2014, at 11:53 PM, Patrick Kelsey = wrote: >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore = wrote: >>>>>>=20 >>>>>> There's a standard property for mmc/sd devices, "non-removable" = whose >>>>>> presence denotes things like soldered-on eMMC parts. Only one of = our >>>>>> many sdhci drivers supports it right now (imx). In general the = core >>>>>> part of the driver (dev/sdhci) doesn't have good support for >>>>>> insert/remove/presence detection that's handled off to the side = (whether >>>>>> it's non-removable or a gpio pin). >>>>>>=20 >>>>>> That alone doesn't solve the wider problem, though, which I think = breaks >>>>>> down into two pieces. Let's say you've got two slots, call them = left >>>>>> and right. You end up with these two problems... >>>>>>=20 >>>>>> * Sometimes the right slot is mmcsd0, but it turns into = mmcsd1 if >>>>>> there's a card in the left slot when I boot; I don't want = it to >>>>>> change. >>>>>>=20 >>>>>> And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. >>>>>>=20 >>>>>> * I want the slot on the left to be named '1' and the right = to be >>>>>> '0'. >>>>>>=20 >>>>>> The first problem is easily solved without impacting dts in any = way. We >>>>>> just wire down the relationship controllerN -> mmcN -> mmcsdN. = This is >>>>>> exactly equivelent to the old ATA_STATIC_ID option in its effect = -- you >>>>>> don't get to choose the names, but you know they won't change = based on >>>>>> which devices are present. It could be controlled with a = tunable. >>>>>>=20 >>>>>> It's harder to envision the fix for the second part without = adding an >>>>>> ad-hoc property for the devices. Even with a property I'm not = sure how >>>>>> easy it would be. >>>>>>=20 >>>>>> We should be able to assign a geographic address = (controllerX:slotY) to each mmcsd device in a given system (let's ignore = for now the theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. >>>>>=20 >>>>> There=92s already a chance to run a script when a device is = attached that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. >>>>>=20 >>>>> Why is mmc so different it needs its own mechanism? >>>>>=20 >>>>> I'm laying out my view of the information that would be needed and = the types of actions that would have to be taken based on that = information to solve the issue. I'm not saying devd can't be the piece = that is used to implement the actions (indeed, I noted devd as a = potential building block for a solution in my initial response). I'm = also not saying mmc needs its own mechanism, I'm saying it needs /a/ = mechanism, and so far there still seems to be something missing (because = it's not there, or I'm still ignorant of it). >>>>>=20 >>>>> What seems to be missing is geographical addressing for mmc = devices. >>>>>=20 >>>>> I think what you might be saying is that the existing mmcsd = add/remove code could be augmented to send devctl notifications, along = the lines of: >>>>>=20 >>>>> devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") >>>>>=20 >>>>> and then I and the fine author of devctl and devd would be = pleased. >>>>=20 >>>> MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: >>>>=20 >>>> at91_mci0 >>>> mmc0 >>>> mmcsd0 at rca=3D0xb368 >>>>=20 >>>> So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which = is ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 >>>>=20 >>>>=20 >>>> The reason you need something extra here is that what is there now = breaks down whenever you don't have a one-to-one mapping between = controllers and buses. Any controller with more than one slot can yield = something of the form: >>>>=20 >>>> sdhci0 >>>> mmc0 >>>> mmcsd0 at rca=3D0xabcd >>>> mmc1 >>>> mmcsd1 at rca=3D0x1234 >>>>=20 >>>> and you have no idea what physical slot in the system mmcsd0 and = mmcsd1 are in. >>>=20 >>> The driver isn=92t going to be able to help you, because it reports = mmc0 based on the data it gets from slot 0 status registers, and mmc1 = based on slot 1 status registers. Since there=92s no notion of how that = maps to physical hardware, the driver can=92t do anything automatically. = And since mmc on down is populated by FreeSBD, there=92s no hints in the = FDT tree for them. >>>=20 >>>=20 >>>> For my immediate use case, sure, I can rely on the one-to-one = relationship between controllers and buses. At this point, though, = rather than skate by on that happy coincidence, I'd rather invest what = now seems to be a rather small amount of effort adding mmcsd devctl = notifications that would cover the multiple-slots-per-controller case as = well, and then build the rest of what I want on top of that information = coming out of ddvd. >>>=20 >>> Trouble is, how do we know what to send with this new notification. = That=92s the part I=92m having trouble with. Where does that data come = from? And how is it different than what=92s in the device tree? >>>=20 >>>=20 >>> Each controller driver maintains an instance of struct mmc_host for = each physical bus interface (typically referred to as a 'slot' in the = drivers) it has. When a card is detected in a given slot by the driver, = the driver creates an mmc bus instance and attaches the struct mmc_host = corresponding to that slot to provide the ivar values. So let's say = struct mmc_host gets a new member 'slot_number', and a new ivar = MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of = struct mmc_host a driver maintains gets set to a controller-relative = index of the corresponding physical interface - the controller will do = this the same way every time, because it is tied to the register layout = of the controller. >>>=20 >>> After the mmc bus instance is created and its ivars are set, = probe-and-attach is run on that bus, and an mmcsd device instance is = created for each card that is found. At the point where the mmcsd = device instance is created, one knows the parent bus for that new mmcsd = device, and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that = bus, as well as the name of the controller device instance that is the = parent of the parent bus. It thus possible at that point to=20 >>>=20 >>> devctl_notify("MMC", "DEVICE", "ATTACH", "... = controller=3D = slot=3D ") >>>=20 >>> Because the controller attachment order is the same on every boot, = as is the slot number ivar for a given bus interface on each controller = hardware instance, an identical attach message will be generated every = time a card is discovered in that physical location in the system. For = a given system, there will thus be a fixed mapping between = {controller_instance,slot} tuples that appear in these messages and the = physical MMC/SD device locations. >>=20 >> I=92m curious how that=92s materially different than the parent=92s = mmc instance number. That too is invariant between boots. There=92s a = 1:1 - onto mapping between this instance number and any controller/slot = tuple that would be created. >>=20 >=20 > Controller instance (unit) numbers are the same across boots. The mmc = instance (unit) number for the mmc instance created for a given bus = interface on a given controller is not, because the instance is created = dynamically in response to card detection and thus depends on the = ordering of card insertions. That=92s the problem right there. The should always be the same from = boot to boot. sdhci must be doing things wrong. I=92ll have to take a = look. That=92s the real problem here. That=92s certainly how it is = supposed to be working. We always attach PCI busses to PCI bridges, = regardless of what=92s on the bus. mmc should be the same thing. I=92ll = work up some patches for that. > Sure, there's a one-to-one and onto mapping at any given moment = between mmc instance numbers and the tuples I'm talking about, but the = mapping is subject to change with card insertions and removals. The = material difference between the two sets of labels is that a given tuple = value will *always* refer to the same physical device location in the = system, whereas a given mmc unit number could refer to any physical = device location in the system depending on the time order of insertions = in the various card slots. I understand better now... >> Also, there doesn=92t need to be a special MMC message for this. If = we do create the notion of a slot number per controller, that would be = part of the location information that is in the location string for the = normal attach message >=20 > Ah, so I can just append more variable definitions to the location = string, which is already fed through to the existing generic devctl = notification? Works for me. Sure. >>> In the above, I've left out the value of rca from the discussion = because upon further reflection, it cannot be stably tied to a physical = location. If there is a multidrop MMC bus in a system, the physical card = locations on that bus will not be able to be referred to with stable = names. This is the one area where a new property in the FDT could be = useful to convey multidrop-or-not for each bus interface on a = controller. The new property could be 'freebsd,max-devices' and would = be an array of cells that indicates the maximum number of MMC/SD devices = that can be connected to the controller bus interface corresponding to = that cell index. The devctl notification could then include a multidrop = indicator in the message. >>=20 >> rca is more of a serial number than a location number. Useful for = other reasons. >>=20 >> I=92m not sure how =91freebsd,max-devices=92 would solve the problem. = The controller already knows that. If we really want to tie things to a = physical location/ description, I=92d opt for something more like = =91freebsd,slot-names =3D =93Slot 0=94, =93Slot 1=94;=92 type of thing, = where you could just as easily have =93Top Card=94 =93bottom card=94 or = =93boot card=94 and =93customer card=94 if you wanted. Then the = controller could query this property to get the names to populate = somewhere in the PNP info for this device. The mmcsd driver would then = be free to also create a /dev/Blah alias as well for the disk, but I = don=92t know if that would cause aliases to get created for all the geom = children or not... >>=20 >=20 > freebsd,max-devices is not already known by the controller. The = controller knows how many bus interfaces it has, but it doesn't know how = many devices can be attached to that bus, as that depends on the board = design. freebsd,max-devices informs us whether the board design is = multidrop or not for each bus interface on each controller. Passing = through a multidrop indication in the devctl notification informs the = devctl consumer as to whether or not a unique stable name can be = assigned to the mmcsd instance based on the tuple (if multidrop, then = no). Not essential, but would be thorough. Hmmm, this sure sounds like something that should already be in the FDT = file. I=92ll have to do a survey. > I disagree with 'freebsd,slot-names' because meaningful/descriptive = slot names are going to be something that are often defined at the = product level, so I think it's better to just let them be defined via a = devd action script. Otherwise we build in an invitation to the = experience of having board-level slot names and product-level slot names = from the same namespace, which is in my experience awful. "Oh, wait, = does this bug report refer to board-'top slot' or front-panel-'top = slot'?" In other words, I think it's handy to have up until the board = goes into an enclosure, then it could be trouble from then on. Plus it = could also encourage further knee-jerk, inappropriate .dts patching of = the sort I started out with here :) "Why make a devd script when I can = just edit the names in the .dts file?=94 Good points. > Agreed geom children are an open question. >=20 > -Patrick Warner From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 04:17:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41C433A5; Thu, 6 Mar 2014 04:17:20 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6EEA8F9; Thu, 6 Mar 2014 04:17:18 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id mc6so1344335lab.41 for ; Wed, 05 Mar 2014 20:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hkOQBHNASLYrEFplC3Gb8JbQ3Yi8Za76kbshZSBEO1o=; b=LDdV6LclMQGNvCJ9cKpREOtZlcI2TvowrsPQAzWx6c6KFpiEe/TwqcZPrdfpxJumMe ML0c9IzknHhRk7BDFM7+ARQnNfdbcpF3oNzo/gXHCnqaSusmUJ0mLxhTLE5GyX+XVIie csguAJOK3gmoUvRLqnb6MvDS1gDQWEROZhO6RhclvCbM3IRxoiRcGc7x+V2cYSoIz3DD D9ffMv8ttSSS5Ku+QpwGkA1Eqa7xAKsEFPnnE+iACCvrUy/PsvNDPFIAE7vze+tMwp4T Ugvqf4/Cu5QgIwux+816a6pqI8+9eN5UWX385Tk4s70gCbqid6e/3/hQ/79FWYVgYPmY ZbPg== MIME-Version: 1.0 X-Received: by 10.152.43.47 with SMTP id t15mr29450lal.38.1394079436185; Wed, 05 Mar 2014 20:17:16 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 20:17:16 -0800 (PST) In-Reply-To: <7F5BD549-6A25-48F5-989A-F2D43C241CFF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> <7F5BD549-6A25-48F5-989A-F2D43C241CFF@bsdimp.com> Date: Wed, 5 Mar 2014 23:17:16 -0500 X-Google-Sender-Auth: gpLx7WI8-H7OzRN9jECszCw8tB0 Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 04:17:20 -0000 On Wed, Mar 5, 2014 at 10:52 PM, Warner Losh wrote: > > On Mar 5, 2014, at 7:48 PM, Patrick Kelsey wrote: > > > > > > > On Mar 5, 2014, at 8:02 PM, Warner Losh wrote: > > > >> > >> On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: > >> > >>> > >>> > >>> > >>> On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: > >>> > >>> On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: > >>> > >>>> > >>>> > >>>> > >>>> On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > >>>> > >>>> On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > >>>>> > >>>>> On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > >>>>>> > >>>>>> There's a standard property for mmc/sd devices, "non-removable" > whose > >>>>>> presence denotes things like soldered-on eMMC parts. Only one of > our > >>>>>> many sdhci drivers supports it right now (imx). In general the core > >>>>>> part of the driver (dev/sdhci) doesn't have good support for > >>>>>> insert/remove/presence detection that's handled off to the side > (whether > >>>>>> it's non-removable or a gpio pin). > >>>>>> > >>>>>> That alone doesn't solve the wider problem, though, which I think > breaks > >>>>>> down into two pieces. Let's say you've got two slots, call them > left > >>>>>> and right. You end up with these two problems... > >>>>>> > >>>>>> * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 > if > >>>>>> there's a card in the left slot when I boot; I don't want it > to > >>>>>> change. > >>>>>> > >>>>>> And not just a boot-time issue, of course. If you were to remove > those two cards and then reinsert them in the opposite time-order, their > device names would swap. > >>>>>> > >>>>>> * I want the slot on the left to be named '1' and the right to > be > >>>>>> '0'. > >>>>>> > >>>>>> The first problem is easily solved without impacting dts in any > way. We > >>>>>> just wire down the relationship controllerN -> mmcN -> mmcsdN. > This is > >>>>>> exactly equivelent to the old ATA_STATIC_ID option in its effect -- > you > >>>>>> don't get to choose the names, but you know they won't change based > on > >>>>>> which devices are present. It could be controlled with a tunable. > >>>>>> > >>>>>> It's harder to envision the fix for the second part without adding > an > >>>>>> ad-hoc property for the devices. Even with a property I'm not sure > how > >>>>>> easy it would be. > >>>>>> > >>>>>> We should be able to assign a geographic address > (controllerX:slotY) to each mmcsd device in a given system (let's ignore > for now the theoretical possibility of multiple cards on one bus). The > 'controllerX' part of the address could be the controller's pathname from > the devicetree, or an index assigned by mmcbr machinery at attach time. > The "slotY" part of the address is assigned by the specific controller > device driver using some internally-determined fixed mapping between the > assigned values and its physical slots. This geographic address could be > used to create an additional set of /dev entries with stable names. There > could be a mechanism for user-configurable aliases for the geographical > addresses. > >>>>> > >>>>> There's already a chance to run a script when a device is attached > that can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > >>>>> > >>>>> Why is mmc so different it needs its own mechanism? > >>>>> > >>>>> I'm laying out my view of the information that would be needed and > the types of actions that would have to be taken based on that information > to solve the issue. I'm not saying devd can't be the piece that is used to > implement the actions (indeed, I noted devd as a potential building block > for a solution in my initial response). I'm also not saying mmc needs its > own mechanism, I'm saying it needs /a/ mechanism, and so far there still > seems to be something missing (because it's not there, or I'm still > ignorant of it). > >>>>> > >>>>> What seems to be missing is geographical addressing for mmc devices. > >>>>> > >>>>> I think what you might be saying is that the existing mmcsd > add/remove code could be augmented to send devctl notifications, along the > lines of: > >>>>> > >>>>> devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... > controller= > slot= rca=") > >>>>> > >>>>> and then I and the fine author of devctl and devd would be pleased. > >>>> > >>>> MMC doesn't need anything special here. That's already present. > Looking at the device tree we see on one of the platforms that's handy for > me to access: > >>>> > >>>> at91_mci0 > >>>> mmc0 > >>>> mmcsd0 at rca=0xb368 > >>>> > >>>> So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which > is ultimately the FDT node where things came from. There's not a > user-defined slot associated with this (and we should have a SLOT A vs SLOT > B as a location info for this platform, because we can have two cards on > the one bus in the MMC case), true, but for your use case I don't think > that you need it. We should be attaching the host controller regardless of > whether the or not there's a card in there, so it will be fixed. While some > additional information would be useful to publish, I don't think your use > case requires it... > >>>> > >>>> > >>>> The reason you need something extra here is that what is there now > breaks down whenever you don't have a one-to-one mapping between > controllers and buses. Any controller with more than one slot can yield > something of the form: > >>>> > >>>> sdhci0 > >>>> mmc0 > >>>> mmcsd0 at rca=0xabcd > >>>> mmc1 > >>>> mmcsd1 at rca=0x1234 > >>>> > >>>> and you have no idea what physical slot in the system mmcsd0 and > mmcsd1 are in. > >>> > >>> The driver isn't going to be able to help you, because it reports mmc0 > based on the data it gets from slot 0 status registers, and mmc1 based on > slot 1 status registers. Since there's no notion of how that maps to > physical hardware, the driver can't do anything automatically. And since > mmc on down is populated by FreeSBD, there's no hints in the FDT tree for > them. > >>> > >>> > >>>> For my immediate use case, sure, I can rely on the one-to-one > relationship between controllers and buses. At this point, though, rather > than skate by on that happy coincidence, I'd rather invest what now seems > to be a rather small amount of effort adding mmcsd devctl notifications > that would cover the multiple-slots-per-controller case as well, and then > build the rest of what I want on top of that information coming out of ddvd. > >>> > >>> Trouble is, how do we know what to send with this new notification. > That's the part I'm having trouble with. Where does that data come from? > And how is it different than what's in the device tree? > >>> > >>> > >>> Each controller driver maintains an instance of struct mmc_host for > each physical bus interface (typically referred to as a 'slot' in the > drivers) it has. When a card is detected in a given slot by the driver, > the driver creates an mmc bus instance and attaches the struct mmc_host > corresponding to that slot to provide the ivar values. So let's say struct > mmc_host gets a new member 'slot_number', and a new ivar > MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of > struct mmc_host a driver maintains gets set to a controller-relative index > of the corresponding physical interface - the controller will do this the > same way every time, because it is tied to the register layout of the > controller. > >>> > >>> After the mmc bus instance is created and its ivars are set, > probe-and-attach is run on that bus, and an mmcsd device instance is > created for each card that is found. At the point where the mmcsd device > instance is created, one knows the parent bus for that new mmcsd device, > and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that bus, as > well as the name of the controller device instance that is the parent of > the parent bus. It thus possible at that point to > >>> > >>> devctl_notify("MMC", "DEVICE", "ATTACH", "... > controller= slot= > ") > >>> > >>> Because the controller attachment order is the same on every boot, as > is the slot number ivar for a given bus interface on each controller > hardware instance, an identical attach message will be generated every time > a card is discovered in that physical location in the system. For a given > system, there will thus be a fixed mapping between > {controller_instance,slot} tuples that appear in these messages and the > physical MMC/SD device locations. > >> > >> I'm curious how that's materially different than the parent's mmc > instance number. That too is invariant between boots. There's a 1:1 - onto > mapping between this instance number and any controller/slot tuple that > would be created. > >> > > > > Controller instance (unit) numbers are the same across boots. The mmc > instance (unit) number for the mmc instance created for a given bus > interface on a given controller is not, because the instance is created > dynamically in response to card detection and thus depends on the ordering > of card insertions. > > That's the problem right there. The should always be the same from boot to > boot. sdhci must be doing things wrong. I'll have to take a look. That's > the real problem here. That's certainly how it is supposed to be working. > We always attach PCI busses to PCI bridges, regardless of what's on the > bus. mmc should be the same thing. I'll work up some patches for that. > > > Sure, there's a one-to-one and onto mapping at any given moment between > mmc instance numbers and the tuples I'm talking about, but the mapping is > subject to change with card insertions and removals. The material > difference between the two sets of labels is that a given tuple value will > *always* refer to the same physical device location in the system, whereas > a given mmc unit number could refer to any physical device location in the > system depending on the time order of insertions in the various card slots. > > I understand better now... > Yes, this fully explains the disconnect we were having. I was under the impression that sdhci was doing it that way to make way for reprobe/attach/discovery because it's actually doing card detect. It felt a bit weird at the time, but this is the example I followed when I did the mmcspi driver I posted to the list sometime back, as that also had card detect support. > > >> Also, there doesn't need to be a special MMC message for this. If we do > create the notion of a slot number per controller, that would be part of > the location information that is in the location string for the normal > attach message > > > > Ah, so I can just append more variable definitions to the location > string, which is already fed through to the existing generic devctl > notification? Works for me. > > Sure. > > >>> In the above, I've left out the value of rca from the discussion > because upon further reflection, it cannot be stably tied to a physical > location. If there is a multidrop MMC bus in a system, the physical card > locations on that bus will not be able to be referred to with stable names. > This is the one area where a new property in the FDT could be useful to > convey multidrop-or-not for each bus interface on a controller. The new > property could be 'freebsd,max-devices' and would be an array of cells that > indicates the maximum number of MMC/SD devices that can be connected to the > controller bus interface corresponding to that cell index. The devctl > notification could then include a multidrop indicator in the message. > >> > >> rca is more of a serial number than a location number. Useful for other > reasons. > >> > >> I'm not sure how 'freebsd,max-devices' would solve the problem. The > controller already knows that. If we really want to tie things to a > physical location/ description, I'd opt for something more like > 'freebsd,slot-names = "Slot 0", "Slot 1";' type of thing, where you could > just as easily have "Top Card" "bottom card" or "boot card" and "customer > card" if you wanted. Then the controller could query this property to get > the names to populate somewhere in the PNP info for this device. The mmcsd > driver would then be free to also create a /dev/Blah alias as well for the > disk, but I don't know if that would cause aliases to get created for all > the geom children or not... > >> > > > > freebsd,max-devices is not already known by the controller. The > controller knows how many bus interfaces it has, but it doesn't know how > many devices can be attached to that bus, as that depends on the board > design. freebsd,max-devices informs us whether the board design is > multidrop or not for each bus interface on each controller. Passing > through a multidrop indication in the devctl notification informs the > devctl consumer as to whether or not a unique stable name can be assigned > to the mmcsd instance based on the tuple (if multidrop, then no). Not > essential, but would be thorough. > > Hmmm, this sure sounds like something that should already be in the FDT > file. I'll have to do a survey. > > > I disagree with 'freebsd,slot-names' because meaningful/descriptive slot > names are going to be something that are often defined at the product > level, so I think it's better to just let them be defined via a devd action > script. Otherwise we build in an invitation to the experience of having > board-level slot names and product-level slot names from the same > namespace, which is in my experience awful. "Oh, wait, does this bug > report refer to board-'top slot' or front-panel-'top slot'?" In other > words, I think it's handy to have up until the board goes into an > enclosure, then it could be trouble from then on. Plus it could also > encourage further knee-jerk, inappropriate .dts patching of the sort I > started out with here :) "Why make a devd script when I can just edit the > names in the .dts file?" > > Good points. > > > Agreed geom children are an open question. > > > > -Patrick > > Warner > > From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 04:54:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5CB694C for ; Thu, 6 Mar 2014 04:54:02 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 5B822B78 for ; Thu, 6 Mar 2014 04:54:01 +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-maile13) with ESMTP id s264rnRK024502 for ; Thu, 6 Mar 2014 13:53:49 +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 s264rn309998 for ; Thu, 6 Mar 2014 13:53:49 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi14) id s264rnXR002358 for freebsd-arm@freebsd.org; Thu, 6 Mar 2014 13:53:49 +0900 Received: from [10.229.230.112] by lomi14.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s264rnSQ002335 for ; Thu, 6 Mar 2014 13:53:49 +0900 Date: Thu, 06 Mar 2014 13:53:49 +0900 From: Takashi Komatsu To: freebsd-arm Subject: The arguments of sys_sigreturn Message-Id: <20140306135349.5C75.2910CF64@jp.panasonic.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_5317F256000000005C71_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.64.06 [ja] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 04:54:02 -0000 --------_5317F256000000005C71_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I have a question about the function of sys_sigreturn. [sys/arm/arm/machdep.c] In arm codes, the sys_sigreturn function use sigreturn_args. I think it has to be used for "struct __ucontext". But it use "struct sigframe". In fact, it's called with the argument "sigframe" by other function. (sys/arm/arm/locore.S: L558) On the one hand, it's called by the thread library with "ucontext_t". (lib/libthr/thread/thr_sig.c: L256) There is collision types. I attached my patch. Please review. Best regards, Takashi Komatsu --------_5317F256000000005C71_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="sys_sigreturn.patch" Content-Disposition: attachment; filename="sys_sigreturn.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL2dlbmFzc3ltLmMgYi9zeXMvYXJtL2FybS9nZW5hc3N5 bS5jCmluZGV4IDAyOTUyOWEuLmUzODczM2IgMTAwNjQ0Ci0tLSBhL3N5cy9hcm0vYXJtL2dlbmFz c3ltLmMKKysrIGIvc3lzL2FybS9hcm0vZ2VuYXNzeW0uYwpAQCAtMTA5LDYgKzEwOSw4IEBAIEFT U1lNKFRGX1BDLCBvZmZzZXRvZihzdHJ1Y3QgdHJhcGZyYW1lLCB0Zl9wYykpOwogQVNTWU0oUF9Q SUQsIG9mZnNldG9mKHN0cnVjdCBwcm9jLCBwX3BpZCkpOwogQVNTWU0oUF9GTEFHLCBvZmZzZXRv ZihzdHJ1Y3QgcHJvYywgcF9mbGFnKSk7CiAKK0FTU1lNKFNJR0ZfVUMsIG9mZnNldG9mKHN0cnVj dCBzaWdmcmFtZSwgc2ZfdWMpKTsKKwogI2lmZGVmIEFSTV9UUF9BRERSRVNTCiBBU1NZTShBUk1f VFBfQUREUkVTUywgQVJNX1RQX0FERFJFU1MpOwogQVNTWU0oQVJNX1JBU19TVEFSVCwgQVJNX1JB U19TVEFSVCk7CmRpZmYgLS1naXQgYS9zeXMvYXJtL2FybS9sb2NvcmUuUyBiL3N5cy9hcm0vYXJt L2xvY29yZS5TCmluZGV4IDM2NGQxOWUuLjkwZWVlYWYgMTAwNjQ0Ci0tLSBhL3N5cy9hcm0vYXJt L2xvY29yZS5TCisrKyBiL3N5cy9hcm0vYXJtL2xvY29yZS5TCkBAIC01NTcsNiArNTU3LDcgQEAg RU5EKGFib3J0KQogCiBFTlRSWV9OUChzaWdjb2RlKQogCW1vdglyMCwgc3AKKwlhZGQJcjAsIHIw LCAjU0lHRl9VQwogCiAJLyoKIAkgKiBDYWxsIHRoZSBzaWdyZXR1cm4gc3lzdGVtIGNhbGwuCmRp ZmYgLS1naXQgYS9zeXMvYXJtL2FybS9tYWNoZGVwLmMgYi9zeXMvYXJtL2FybS9tYWNoZGVwLmMK aW5kZXggNjhmNDMxOC4uMzVmMTQzMiAxMDA2NDQKLS0tIGEvc3lzL2FybS9hcm0vbWFjaGRlcC5j CisrKyBiL3N5cy9hcm0vYXJtL21hY2hkZXAuYwpAQCAtNzQyLDI4ICs3NDIsMjYgQEAgc3lzX3Np Z3JldHVybih0ZCwgdWFwKQogCQljb25zdCBzdHJ1Y3QgX191Y29udGV4dCAqc2lnY250eHA7CiAJ fSAqLyAqdWFwOwogewotCXN0cnVjdCBzaWdmcmFtZSBzZjsKLQlzdHJ1Y3QgdHJhcGZyYW1lICp0 ZjsKKwl1Y29udGV4dF90IHVjOwogCWludCBzcHNyOwogCQogCWlmICh1YXAgPT0gTlVMTCkKIAkJ cmV0dXJuIChFRkFVTFQpOwotCWlmIChjb3B5aW4odWFwLT5zaWdjbnR4cCwgJnNmLCBzaXplb2Yo c2YpKSkKKwlpZiAoY29weWluKHVhcC0+c2lnY250eHAsICZ1Yywgc2l6ZW9mKHVjKSkpCiAJCXJl dHVybiAoRUZBVUxUKTsKIAkvKgogCSAqIE1ha2Ugc3VyZSB0aGUgcHJvY2Vzc29yIG1vZGUgaGFz IG5vdCBiZWVuIHRhbXBlcmVkIHdpdGggYW5kCiAJICogaW50ZXJydXB0cyBoYXZlIG5vdCBiZWVu IGRpc2FibGVkLgogCSAqLwotCXNwc3IgPSBzZi5zZl91Yy51Y19tY29udGV4dC5fX2dyZWdzW19S RUdfQ1BTUl07CisJc3BzciA9IHVjLnVjX21jb250ZXh0Ll9fZ3JlZ3NbX1JFR19DUFNSXTsKIAlp ZiAoKHNwc3IgJiBQU1JfTU9ERSkgIT0gUFNSX1VTUjMyX01PREUgfHwKIAkgICAgKHNwc3IgJiAo STMyX2JpdCB8IEYzMl9iaXQpKSAhPSAwKQogCQlyZXR1cm4gKEVJTlZBTCk7CiAJCS8qIFJlc3Rv cmUgcmVnaXN0ZXIgY29udGV4dC4gKi8KLQl0ZiA9IHRkLT50ZF9mcmFtZTsKLQlzZXRfbWNvbnRl eHQodGQsICZzZi5zZl91Yy51Y19tY29udGV4dCk7CisJc2V0X21jb250ZXh0KHRkLCAmdWMudWNf bWNvbnRleHQpOwogCiAJLyogUmVzdG9yZSBzaWduYWwgbWFzay4gKi8KLQlrZXJuX3NpZ3Byb2Nt YXNrKHRkLCBTSUdfU0VUTUFTSywgJnNmLnNmX3VjLnVjX3NpZ21hc2ssIE5VTEwsIDApOworCWtl cm5fc2lncHJvY21hc2sodGQsIFNJR19TRVRNQVNLLCAmdWMudWNfc2lnbWFzaywgTlVMTCwgMCk7 CiAKIAlyZXR1cm4gKEVKVVNUUkVUVVJOKTsKIH0K --------_5317F256000000005C71_MULTIPART_MIXED_-- From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 05:03:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AF36AF5 for ; Thu, 6 Mar 2014 05:03:58 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C706AC22 for ; Thu, 6 Mar 2014 05:03:57 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n16so2105415oag.13 for ; Wed, 05 Mar 2014 21:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=1r8objJR1jrB3hdzyblT/My+uokfwFqCTRNHNAWYL78=; b=0KDyegl19wuY1nCVHHRZ8ZkjWlvwv0UwjKcxCH5MTnucwpY6g1kvGiKX+RGaJFWDPU up50XwQ+7RRhNadaoxJRYKxdqaa2LWwSu/2h8krDDONpIk2WeSAOK7ty1NA0RiV8M3Xk ukOTVRVnbNACzB0BQdNUdrXkjeomYX+Yi8AhPMb2LYHzvJ8ircS/T6aY/evgSCLsZxBD 5oCsseCnJF8OyecC+YxkOpJulmck5/Lhhnd39zurppNn08fUij448F3TynCh04bqtUSh KMWxu4PFDD4VHJt9vV70M7uMXfVqWCdUpeDPSar7RlYD0inXX8O6wQhgdNsi/Czox64s df2A== X-Received: by 10.182.33.6 with SMTP id n6mr234806obi.48.1394082237065; Wed, 05 Mar 2014 21:03:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.194 with HTTP; Wed, 5 Mar 2014 21:03:27 -0800 (PST) In-Reply-To: References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> From: Jia-Shiun Li Date: Thu, 6 Mar 2014 13:03:27 +0800 Message-ID: Subject: Re: TMPFS in kernels To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: George Rosamond , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 05:03:58 -0000 On Tue, Mar 4, 2014 at 10:48 PM, Warner Losh wrote: > > On Mar 4, 2014, at 3:30 AM, Jia-Shiun Li wrote: > >> I remember hacking it a while ago to adopt tmpfs instead on my pxeboot >> test environment. It only requires changing the line mdmfs mounting md t= o >> 'mount -t tmpfs' (plus mount options), and everything else will work as = usual. > > I=E2=80=99ll have to give it a spin on NanoBSD then, at least as an optio= n=E2=80=A6 > The actual patch & result pasted below to save you some time. Only tested on x86 pxeboot though. -----8<----------8<----------8<----- % diff -bu /usr/src/etc/rc.initdiskless /b/tftpboot/FreeBSD/install/etc/rc.initdiskless --- /usr/src/etc/rc.initdiskless 2013-04-11 21:03:31.000000000 +0800 +++ /b/tftpboot/FreeBSD/install/etc/rc.initdiskless 2014-03-06 12:43:47.000000000 +0800 @@ -198,7 +198,10 @@ # Create a generic memory disk # mount_md() { - /sbin/mdmfs -S -i 4096 -s $1 -M md $2 +# /sbin/mdmfs -S -i 4096 -s $1 -M md $2 + local tmpfs_size + tmpfs_size=3D$(($1 * 1024)) + /sbin/mount -t tmpfs -osize=3D$tmpfs_size tmpfs $2 } # Create the memory filesystem if it has not already been created % cat df Filesystem Size Used Avail Capacity Mounted on 192.168.233.1:/b/tftpboot/FreeBSD/install/ 29G 17G 9.8G 63% = / devfs 1.0K 1.0K 0B 100% /dev tmpfs 10M 2.6M 7.4M 26% /etc tmpfs 10M 180K 9.8M 2% /var /dev/md0 19M 24K 17M 0% /tmp % cat mount 192.168.233.1:/b/tftpboot/FreeBSD/install/ on / (nfs, read-only) devfs on /dev (devfs, local, multilabel) tmpfs on /etc (tmpfs, local) tmpfs on /var (tmpfs, local) /dev/md0 on /tmp (ufs, local) -Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 09:31:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1E7944D for ; Thu, 6 Mar 2014 09:31:55 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B358899 for ; Thu, 6 Mar 2014 09:31:55 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u56so2721858wes.9 for ; Thu, 06 Mar 2014 01:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=10w+SqznByfcR1LTa+l3FpRUH7OGmEr4TVyhuynIQZQ=; b=p/CG/eXpYgi/zdgYX6aW4ZaeqhTq+rYzwnM0AFt3K2OJxjqCD63y2N7ObsoL4JmUTw HwiErShVMe7wsSkiTU6elKNiOvvwWt6zoYRMLKcJq0TJRdYT3ViRiM5lnmmUvKhbd5KZ 5BsVHWzw0/gmKs1sDqWdtrfDzfcg/BzC+fEcM45UYJ9lK4poatk5QLWVTAYyxouM3wLj zfTRAlMU2Fa4MJftC7/d5xhivKjImmnyGcWStB5mUUYY3thAvHfbXiRPdSLffpVhG3UG lA8yrrSpMMEDIKUzXxb9SBYQ+Qqya3xRNZ3pffqa1tnNL2mgcCivIO6AXYhppwym8Z0i 1e+A== MIME-Version: 1.0 X-Received: by 10.194.204.199 with SMTP id la7mr4515725wjc.4.1394098313870; Thu, 06 Mar 2014 01:31:53 -0800 (PST) Received: by 10.217.43.69 with HTTP; Thu, 6 Mar 2014 01:31:53 -0800 (PST) In-Reply-To: <5317AF31.8050408@nomadlogic.org> References: <5317AF31.8050408@nomadlogic.org> Date: Thu, 6 Mar 2014 11:31:53 +0200 Message-ID: Subject: Re: CompuLab - FreeScale i.MX6 CPU From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: Pete Wright Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:31:55 -0000 Thank you very much Pete. Do you know a two ethernet arm board that works on freebsd? best regards, On Thu, Mar 6, 2014 at 1:11 AM, Pete Wright wrote: > > > On 03/04/14 23:17, =D6zkan KIRIK wrote: > > Hi, > > > > I am interested with CompuLab Utilite Standart board. ( > > http://utilite-computer.com/web/utilite-models ) > > I saw that over SVN, FreeBSD has i.MX6 cpu support. > > What about drivers of this board? > > > > Does HDMI and NICs works? > > > > Can you suggest a cheap and two ethernet arm board that FreeBSD works. > > > > > hey there Ozkan - I am hacking on getting this working in my minimal > spare time. there are a couple major issues i've run into: > > 1) not really full featured u-boot environment, no usb boot support for > example > > 2) flaky microSD support (had to try out several different cards to find > a working one from sandisk) > > 3) network stack w/in u-boot has been unstable (unable to tftpboot > images due to timeouts) > > the board does have some potential though - but it is not plug-and-play > at this point. having said that - the up side is there is ton's of > opportunity to make an impact on getting support for this device working > in the freebsd-arm community :) > > cheers, > -pete > > -- > Pete Wright > pete@nomadlogic.org > twitter =3D> @nomadlogicLA > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 10:45:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 934318E8 for ; Thu, 6 Mar 2014 10:45:46 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C33CF41 for ; Thu, 6 Mar 2014 10:45:46 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id u57so2761477wes.8 for ; Thu, 06 Mar 2014 02:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=rifxyDMAHvcN4V4J86jRcUFfpwzKuOa0jq4vsLJSmnU=; b=RqDPKmZhBp5gt+qb81K9PBciWefibMnDbKua8nQ4BoS59L+e3zXw6v8RuMf9sSt5nQ QGjzxDmTJE1jCsJzZWDAwHiLFvCFEd9l5cnxprbeMHDVhg7We9xtEmSgERmeGoD49FUa yELBfqhLkok2hEpIfWLXdoVgGLjO2A2sr7y64Fk3Gl/YJWAAIOa0JfJT5pU+oFwPmTsj /Qng+N/tCSaxVzHhLuyQRAdSPQKW4vKkLYlO1Zy7spRsbMVJAZn/wFMoqLE29U0zMz+Z XGTmOk4HlrGnFbLwofDkeTt2YiNYuZCAsIYnnjcCipSX7wk99Du8RbPC5ElqV3kRoqZB lM8Q== X-Received: by 10.194.90.196 with SMTP id by4mr8612317wjb.45.1394102744531; Thu, 06 Mar 2014 02:45:44 -0800 (PST) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id f7sm14951169wjb.7.2014.03.06.02.45.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 02:45:43 -0800 (PST) Sender: Sulev-Madis Silber Message-ID: <531851D6.5060308@hot.ee> Date: Thu, 06 Mar 2014 12:45:42 +0200 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: TI AM335x ADC support (on BeagleBone Black) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:45:46 -0000 Hello. I'm trying to figure out how hard would it be to get ADC working on my BBB. Most of things seem to work (except some content on eMMC seemed to interfere with eMMC / USB - works with clean eMMC). Also 11-CURRENT (at least r262309) is stable on it while running my PERL-POE daemon [1] While I can fix some GPIO "just I/O" related things (like some pins seem to be "lost"), I don't feel comfortable with writing device drivers right now. I read almost all the AM335x related IO code and then TI ADC driver code for Linux but I don't see myself getting anything done here alone (or it takes years). Maybe someone else works on those things already? I can test code to verify correct operation of ADC. Also, should watchdog work? It's in kernel (running "BEAGLEBONE" now) and there is /dev/fido but that can't be used? [1] http://ketas.si.pri.ee/bbb-poe-daemon/ -- ketas From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 13:38:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 489EC986; Thu, 6 Mar 2014 13:38:31 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E93FC386; Thu, 6 Mar 2014 13:38:30 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id w8so2492636qac.12 for ; Thu, 06 Mar 2014 05:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hlcAdSlZwD9HFEuAeiZ/u+FUumXgVtZRJr2ep1jOMmE=; b=G0t62ZT/tXNQIxErT2b4IIw3wEIF/hACfcVm1bqPyCLIB2kIDjMEdD8d6NgrfaW7XU 4yLNk7su6ir16PW/uUVu0kNQghvlLuzQ/DBZRzcI7LCd6229AvnEZ1bFgktYwTXY1+cz /QYLotqH1/EhPZqRWC7IREwMdkFzG5ghYD55AT0y2YiMhrP87Rv8tXo0qNYVk5JzKLJt bFn96Kr6Jvq5gl4s+sTJv73GGLhj822Ms539LiwHNpZDFiYw8ofXguAOqRz0/JrnoUTx ilI3ig+UrL39jyDI2Awnef8RovCvDPcDiKknp70pc6x/mR2FH/4zOpr/o3JOCtxAa3us 7dgQ== MIME-Version: 1.0 X-Received: by 10.140.88.212 with SMTP id t78mr13349671qgd.47.1394113110116; Thu, 06 Mar 2014 05:38:30 -0800 (PST) Received: by 10.140.31.69 with HTTP; Thu, 6 Mar 2014 05:38:30 -0800 (PST) In-Reply-To: <1393977031.1149.325.camel@revolution.hippie.lan> References: <1393977031.1149.325.camel@revolution.hippie.lan> Date: Thu, 6 Mar 2014 14:38:30 +0100 Message-ID: Subject: Re: Pandaboard ES and SD card From: Svatopluk Kraus To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:38:31 -0000 On Wed, Mar 5, 2014 at 12:50 AM, Ian Lepore wrote: > On Mon, 2014-03-03 at 17:12 +0100, Svatopluk Kraus wrote: > > Hi, > > > > I finally have found time to install FreeBSD 11.0-CURRENT on Pandaboard > ES > > on my table. It's been installed to SD card. When I boot to multiuser, > > it's very very slow. It looks that SD card write performance is very > poor. > > When I boot to singleuser, it's OK. However, when I make root filesystem > > read-write by one command and immediately readonly by second one, the > > second one takes a few minutes to finish. > > > > When I've digged in arm/ti/ti_mmchs.s, I've got following times for READ > > and WRITE commands: > > > > typical read times (start & duration & command), > > ... > > [1393858258.909d4fb4650dcb70] [0.002f97afec8ba994] READ > > [1393858258.929795e2f7db5ec0] [0.002f90d496ec7d4c] READ > > [1393858258.9492673f18af4ec0] [0.002f9d607a66e41c] READ > > [1393858258.968d155674da0d5e] [0.002f937e2ea37cca] READ > > [1393858258.988790d78e6fd5a2] [0.002f9eb09b235414] READ > > [1393858258.9a78744ecab1413e] [0.002f90dded2a9cda] READ > > [1393858258.9c735a3cec62b616] [0.002f97cbef46083e] READ > > [1393858258.9e6ee0b8064ec2aa] [0.002f933cd2f09fe8] READ > > [1393858258.a069e2838966634a] [0.002f959262788368] READ > > [1393858258.a26467518add9a00] [0.002f8f9722ac4c70] READ > > [1393858258.a45e59f14fb6c986] [0.002f9d31cb304656] READ > > [1393858258.a659525d3e70bc98] [0.002f8ae2ad5e65e2] READ > > [1393858258.a853df0c0452931e] [0.002f9cd46cc30aca] READ > > ... > > > > typical write times (start & duration & command). > > ... > > [1393856255.8be604dff29d07a0] [0.00d9cf712d331d58] WRITE > > [1393856255.8e9100859c4fedd2] [0.00da3f856cebe4e6] WRITE > > [1393856255.913c1530607b6288] [0.00da8f1a826cd93a] WRITE > > [1393856255.93e7b97bcc483d9a] [0.00dad6ced3832dbe] WRITE > > [1393856255.9693e68c8a1752c0] [0.2276ea0a1d732724] WRITE <- > > [1393856255.badca6f90c5564ea] [0.22df71f44f623e3e] WRITE <- > > [1393856255.df8e42a6890234a4] [0.24ae2f1172203ed0] WRITE <- > > [1393856256.060e4c7acd0c290a] [0.00e76cb09c67c3ba] WRITE > > [1393856256.08c68da8b0554498] [0.00e7b1d75881776a] WRITE > > [1393856256.0b7f57d3eb15578e] [0.00e83c08cdfa8020] WRITE > > [1393856256.0e36d38be88f1e08] [0.00e882dd093ddf54] WRITE > > [1393856256.10f0762d8d8cbe10] [0.00e8c0f06a43a968] WRITE > > [1393856256.13aa6a2dc9ef5c9a] [0.00e938916637f4c8] WRITE > > [1393856256.1664fc08109773d4] [0.22b74fce5c0401e2] WRITE <- > > [1393856256.3aedb9baa4273c8e] [0.2305517892cef37c] WRITE <- > > [1393856256.5fc52a62081f2238] [0.24aaf338d2067a84] WRITE <- > > [1393856256.8641d9129fd99066] [0.00e770cfadd3b168] WRITE > > [1393856256.88fae819e4c25a9c] [0.04d7472f5f571cbc] WRITE > > ... > > > > Times are struct bintime printed in %lld.%016llx (sec.frac) format. > > > > Writing times have got really big variation. > > Any idea or experience? > > > > Svatopluk Kraus > > > > PS. Of course, I don't mention occasional "Spurious interrupt detected" > > print. > > The ti_mmchs driver does all IO one sector at a time, and single-sector > writes are the worst case for sdcard performance. I've seen > single-sector writes go as slow as 20K/sec. > Well, at least I'm not alone. Thanks for sharing your experience. > Try switching to the ti_sdhci driver (switch the entry in files.omap4). > I don't know for sure that ti_sdhci will work with pandaboard, it's only > been tested on beaglebone that I know of. But if it works you should > see read speeds around 16MB/sec and writes at about 7MB/sec. > I've tried to switch to it. However, it does not work. Inserted card is not detected and when it's hacked, the card is not recognized. % mmc0: on sdhci_ti0 % mmc0: SD probe: failed % mmc0: MMC probe: failed % mmc0: Current OCR: 0x00000000 % mmc0: No compatible cards found on bus When ti_sdhci.c and sdhci.c are compared with ti_mmchs.c, there are many things implemented differently. HW initialization is more complex in ti_mmchs.c and some things are even missing in ti_shdci.c (and its MI part sdhci.c). I'm not sure what is better to start with. To implement multi-block mode into ti_mmchs.c or to fix ti_shdci.c. The first looks easier for me. The second can lead to either fixing MI sdhci.c and/or bypassing it in large. > The "mount -uw / ; mount -ur /" is a completely separate thing. That > takes about 30 seconds on every sdcard-based system I have. I don't > know why, but it's really annoying. I don't think it's a driver thing, > it happens with several different drivers. > > -- Ian Hmmm, so in my case it's only much worse. Svatopluk Kraus From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 14:02:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD45F452 for ; Thu, 6 Mar 2014 14:02:57 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 59A5386F for ; Thu, 6 Mar 2014 14:02:57 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id q58so3115214wes.6 for ; Thu, 06 Mar 2014 06:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sPUFbrEuCag7OkCiYjNkXBckXdO70EguC9aR64J2n2k=; b=pbmkjMddH47X9I9BwUH1LV+7fexzJGluvfRGFnoWWK1M22J2SdA2VTUzzs3n0AQ/N5 CllgzE+FQeRHMK7oAx7R739AzjOVCv6YOv6xOj2jc9in68ShwT8fu16vR7/Za79tIxIN TD4FEXvC8mGA/jAkkB1fsB93lD2Cib/toLw906cZqZQOiEZQgjsm/L/9B0v1TcyxEZI2 FZFFkxzUuWg/NBTgakGw+dxoX0cMcm6JDAHmVUqx7fv8v36+PU4d2oLkAgdLQSyavbye kPiFlneUuUnE+GM4iOibLk5s524ynjuboE/XRKArk0q5DIBcDXdQV2jbXBR/zxTVALD5 SH+Q== MIME-Version: 1.0 X-Received: by 10.194.178.135 with SMTP id cy7mr10349688wjc.21.1394114575761; Thu, 06 Mar 2014 06:02:55 -0800 (PST) Received: by 10.216.40.72 with HTTP; Thu, 6 Mar 2014 06:02:55 -0800 (PST) In-Reply-To: <531851D6.5060308@hot.ee> References: <531851D6.5060308@hot.ee> Date: Thu, 6 Mar 2014 11:02:55 -0300 Message-ID: Subject: Re: TI AM335x ADC support (on BeagleBone Black) From: Luiz Otavio O Souza To: "Sulev-Madis Silber (ketas)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:02:57 -0000 On 6 March 2014 07:45, Sulev-Madis Silber (ketas) wrote: > Hello. > > I'm trying to figure out how hard would it be to get ADC working on my BBB. > > Most of things seem to work (except some content on eMMC seemed to > interfere with eMMC / USB - works with clean eMMC). Also 11-CURRENT (at > least r262309) is stable on it while running my PERL-POE daemon [1] > > While I can fix some GPIO "just I/O" related things (like some pins seem > to be "lost"), I don't feel comfortable with writing device drivers > right now. I read almost all the AM335x related IO code and then TI ADC > driver code for Linux but I don't see myself getting anything done here > alone (or it takes years). Maybe someone else works on those things > already? I can test code to verify correct operation of ADC. > > Also, should watchdog work? It's in kernel (running "BEAGLEBONE" now) > and there is /dev/fido but that can't be used? > > > [1] http://ketas.si.pri.ee/bbb-poe-daemon/ > > > -- > ketas Hello Ketas, I've started read the ADC chapter on TRM a couple of times but i'm yet to finish it. It is on my plans write a driver for the ADC unless someone beat me here. Looks like there is no watchdog driver for am335x, another good chance for practice a little bit. Cheers, Luiz From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 14:10:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CFE2F64 for ; Thu, 6 Mar 2014 14:10:28 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C69D6907 for ; Thu, 6 Mar 2014 14:10:27 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id y10so3204099wgg.13 for ; Thu, 06 Mar 2014 06:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jxpohfDHmyFfQtvk1UPVdqA8PM1/IqaNGg5zmdv7KYo=; b=t7c6T/ZHP+/bRCD5IhUED6cedD44+2Tgtkq5DtjRcUclbBTbrGFHMZDNJcXDrOrtAW pnl4uroJR9vZmMziyRzMrJnCXQjKt/X3uVGGEOEcrySr2qOO3EzqyQ3wT9FE0k8QWpRN 1tzG2ZsL2MGW1zOmo7iZ3hZD2hzMUbCG1iNufMzqeIBqhi1TVyb225bjI46/ySLN9u/k qngap3zrhtfU6bNOCD8rBwlHd0Eijouj5W5oPCjzWqjqxFNklaYUW6laf4lqrnmj9Wlf lw+Sn+sJC7GT7YCLImPi/WkDsXVuwLNJNUfgmoVnOxxeoJEQ0mrsgkHPQytmNkhX+sRR vxSw== X-Received: by 10.194.82.69 with SMTP id g5mr10163128wjy.85.1394115026209; Thu, 06 Mar 2014 06:10:26 -0800 (PST) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id h13sm17592837wjr.22.2014.03.06.06.10.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 06:10:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: TI AM335x ADC support (on BeagleBone Black) From: fabiodive In-Reply-To: Date: Thu, 6 Mar 2014 14:10:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <64573951-E47F-4384-A016-8F65FCD72B56@gmail.com> References: <531851D6.5060308@hot.ee> To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1510) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:10:28 -0000 ADC support would be a great feature! I hope to contribute as well, Luiz, in case you write some code I can try it, I will also try to read the documentation to see if I can achieve some results. Thank you f. On Mar 6, 2014, at 14:02 , Luiz Otavio O Souza = wrote: > On 6 March 2014 07:45, Sulev-Madis Silber (ketas) wrote: >> Hello. >>=20 >> I'm trying to figure out how hard would it be to get ADC working on = my BBB. >>=20 >> Most of things seem to work (except some content on eMMC seemed to >> interfere with eMMC / USB - works with clean eMMC). Also 11-CURRENT = (at >> least r262309) is stable on it while running my PERL-POE daemon [1] >>=20 >> While I can fix some GPIO "just I/O" related things (like some pins = seem >> to be "lost"), I don't feel comfortable with writing device drivers >> right now. I read almost all the AM335x related IO code and then TI = ADC >> driver code for Linux but I don't see myself getting anything done = here >> alone (or it takes years). Maybe someone else works on those things >> already? I can test code to verify correct operation of ADC. >>=20 >> Also, should watchdog work? It's in kernel (running "BEAGLEBONE" now) >> and there is /dev/fido but that can't be used? >>=20 >>=20 >> [1] http://ketas.si.pri.ee/bbb-poe-daemon/ >>=20 >>=20 >> -- >> ketas >=20 > Hello Ketas, >=20 > I've started read the ADC chapter on TRM a couple of times but i'm yet > to finish it. >=20 > It is on my plans write a driver for the ADC unless someone beat me = here. >=20 > Looks like there is no watchdog driver for am335x, another good chance > for practice a little bit. >=20 > Cheers, > Luiz > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 17:50:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF1FEA96 for ; Thu, 6 Mar 2014 17:50:51 +0000 (UTC) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D43A12C2 for ; Thu, 6 Mar 2014 17:50:51 +0000 (UTC) Received: from mail.nomadlogic.org (localhost [127.0.0.1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPS id 4D8F9125EC7; Thu, 6 Mar 2014 09:50:51 -0800 (PST) Received: from pop.rubicorp.com (unknown [72.34.113.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPSA id 438DA125EAD; Thu, 6 Mar 2014 09:50:51 -0800 (PST) Message-ID: <5318B57B.5030905@nomadlogic.org> Date: Thu, 06 Mar 2014 09:50:51 -0800 From: Pete Wright User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D6zkan_KIRIK?= Subject: Re: CompuLab - FreeScale i.MX6 CPU References: <5317AF31.8050408@nomadlogic.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:50:52 -0000 On 03/06/14 01:31, zkan KIRIK wrote: > Thank you very much Pete. > > Do you know a two ethernet arm board that works on freebsd? > this was the only one i was able to find when i was searching in late 2013. hopefully other people will make the jump i made and purchase these guys. i'm unfortunately rather pressed for time resources to give this platform much love at the moment. cheers, -p -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 19:10:55 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 106E9CD9 for ; Thu, 6 Mar 2014 19:10:55 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D8F71DAD for ; Thu, 6 Mar 2014 19:10:54 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WLdgs-0002eW-Su; Thu, 06 Mar 2014 19:10:47 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s26JAhmG051132; Thu, 6 Mar 2014 12:10:44 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/QbNDxPv/T3k+bqRJ8/JF6 Subject: Re: CompuLab - FreeScale i.MX6 CPU From: Ian Lepore To: Pete Wright In-Reply-To: <5317AF31.8050408@nomadlogic.org> References: <5317AF31.8050408@nomadlogic.org> Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 06 Mar 2014 12:10:43 -0700 Message-ID: <1394133043.1149.337.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s26JAhmG051132 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:10:55 -0000 On Wed, 2014-03-05 at 15:11 -0800, Pete Wright wrote: >=20 > On 03/04/14 23:17, =D6zkan KIRIK wrote: > > Hi, > >=20 > > I am interested with CompuLab Utilite Standart board. ( > > http://utilite-computer.com/web/utilite-models ) > > I saw that over SVN, FreeBSD has i.MX6 cpu support. > > What about drivers of this board? > >=20 > > Does HDMI and NICs works? > >=20 > > Can you suggest a cheap and two ethernet arm board that FreeBSD works. > >=20 >=20 >=20 > hey there Ozkan - I am hacking on getting this working in my minimal > spare time. there are a couple major issues i've run into: >=20 > 1) not really full featured u-boot environment, no usb boot support for > example >=20 > 2) flaky microSD support (had to try out several different cards to fin= d > a working one from sandisk) >=20 > 3) network stack w/in u-boot has been unstable (unable to tftpboot > images due to timeouts) >=20 > the board does have some potential though - but it is not plug-and-play > at this point. having said that - the up side is there is ton's of > opportunity to make an impact on getting support for this device workin= g > in the freebsd-arm community :) >=20 > cheers, > -pete >=20 It's really strange that you should have such problems with u-boot. I don't experience anything like that with the Wanboards, the network and sdcard support seems solid. That's both in the u-boot that came with the boards and in the ones I build myself from source. The Utilite u-boot should be using all the same code as the Wandboards for that stuff, it's all generic imx6 support code with just a few lines of board-specific stuff in u-boot. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 20:57:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5181279C; Thu, 6 Mar 2014 20:57:41 +0000 (UTC) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36AF8A86; Thu, 6 Mar 2014 20:57:41 +0000 (UTC) Received: from mail.nomadlogic.org (localhost [127.0.0.1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPS id 33AA2125EC7; Thu, 6 Mar 2014 12:57:40 -0800 (PST) Received: from pop.rubicorp.com (unknown [72.34.113.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPSA id 22D5A125EAD; Thu, 6 Mar 2014 12:57:40 -0800 (PST) Message-ID: <5318E143.7080602@nomadlogic.org> Date: Thu, 06 Mar 2014 12:57:39 -0800 From: Pete Wright User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: CompuLab - FreeScale i.MX6 CPU References: <5317AF31.8050408@nomadlogic.org> <1394133043.1149.337.camel@revolution.hippie.lan> In-Reply-To: <1394133043.1149.337.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 20:57:41 -0000 On 03/06/14 11:10, Ian Lepore wrote: > On Wed, 2014-03-05 at 15:11 -0800, Pete Wright wrote: >> >> On 03/04/14 23:17, zkan KIRIK wrote: >>> Hi, >>> >>> I am interested with CompuLab Utilite Standart board. ( >>> http://utilite-computer.com/web/utilite-models ) >>> I saw that over SVN, FreeBSD has i.MX6 cpu support. >>> What about drivers of this board? >>> >>> Does HDMI and NICs works? >>> >>> Can you suggest a cheap and two ethernet arm board that FreeBSD works. >>> >> >> >> hey there Ozkan - I am hacking on getting this working in my minimal >> spare time. there are a couple major issues i've run into: >> >> 1) not really full featured u-boot environment, no usb boot support for >> example >> >> 2) flaky microSD support (had to try out several different cards to find >> a working one from sandisk) >> >> 3) network stack w/in u-boot has been unstable (unable to tftpboot >> images due to timeouts) >> >> the board does have some potential though - but it is not plug-and-play >> at this point. having said that - the up side is there is ton's of >> opportunity to make an impact on getting support for this device working >> in the freebsd-arm community :) >> >> cheers, >> -pete >> > > It's really strange that you should have such problems with u-boot. I > don't experience anything like that with the Wanboards, the network and > sdcard support seems solid. That's both in the u-boot that came with > the boards and in the ones I build myself from source. The Utilite > u-boot should be using all the same code as the Wandboards for that > stuff, it's all generic imx6 support code with just a few lines of > board-specific stuff in u-boot. > it is certainly possible that my network instability may be due to pebkac - i hope it is. once linux boots on the device the interfaces seem to work as expected, no error counts on the interfaces when doing tests. i am blocking some time out tomorrow to get back hacking on this and will hopefully be able to post some notes to the wiki. -pete -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 21:32:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5585E253 for ; Thu, 6 Mar 2014 21:32:14 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD7D8DFE for ; Thu, 6 Mar 2014 21:32: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 s26LVx4M064348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 22:31:59 +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 s26LVvWN020798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2014 22:31:57 +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 s26LVv3s053843; Thu, 6 Mar 2014 22:31:57 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s26LVuko053842; Thu, 6 Mar 2014 22:31:56 +0100 (CET) (envelope-from ticso) Date: Thu, 6 Mar 2014 22:31:56 +0100 From: Bernd Walter To: Pete Wright Subject: Re: CompuLab - FreeScale i.MX6 CPU Message-ID: <20140306213156.GB45833@cicely7.cicely.de> References: <5317AF31.8050408@nomadlogic.org> <5318B57B.5030905@nomadlogic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5318B57B.5030905@nomadlogic.org> 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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 21:32:14 -0000 On Thu, Mar 06, 2014 at 09:50:51AM -0800, Pete Wright wrote: > > > On 03/06/14 01:31, zkan KIRIK wrote: > > Thank you very much Pete. > > > > Do you know a two ethernet arm board that works on freebsd? > > > > this was the only one i was able to find when i was searching in late > 2013. hopefully other people will make the jump i made and purchase > these guys. i'm unfortunately rather pressed for time resources to give > this platform much love at the moment. The iMX6 only has one ethernet interface. Some boards I've seen have onboard USB ones. In that case you also can easily use an external USB ethernet interface instead. The iMX6 has a single PCIe Interface, which is useable on wandboard with Fairy baseboard in form of an Mini-PCIe slot. Not sure how easy it is to get a Min-PCIe NIC however. If you are capable of soldering you can use SATA cables to wire PCIe, sounds strange, but physical SATA transport is very similar to PCIe. With original wandboard carrier the PCIe pins are reachable under the CPU module as round solderable pads. In MIPS world however there are many more options because they are popular is serveral kind of plasticrouters, you can as well reuse many of those cheap devices under FreeBSD. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Mar 6 22:40:02 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6488F32C for ; Thu, 6 Mar 2014 22:40:02 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5261165B for ; Thu, 6 Mar 2014 22:40:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s26Me2bF057754 for ; Thu, 6 Mar 2014 22:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s26Me2Tn057753; Thu, 6 Mar 2014 22:40:02 GMT (envelope-from gnats) Date: Thu, 6 Mar 2014 22:40:02 GMT Message-Id: <201403062240.s26Me2Tn057753@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: arm/187223: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dfilter service List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 22:40:02 -0000 The following reply was made to PR arm/187223; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/187223: commit references a PR Date: Thu, 6 Mar 2014 22:32:18 +0000 (UTC) Author: cognet Date: Thu Mar 6 21:07:13 2014 New Revision: 262870 URL: http://svnweb.freebsd.org/changeset/base/262870 Log: When calculating the MPU freq, make sure not to overflow by using a uint64_t. PR: arm/187223 Submitted by: Svatopluk Kraus Modified: head/sys/arm/ti/omap4/omap4_prcm_clks.c Modified: head/sys/arm/ti/omap4/omap4_prcm_clks.c ============================================================================== --- head/sys/arm/ti/omap4/omap4_prcm_clks.c Thu Mar 6 21:02:16 2014 (r262869) +++ head/sys/arm/ti/omap4/omap4_prcm_clks.c Thu Mar 6 21:07:13 2014 (r262870) @@ -990,7 +990,7 @@ omap4_clk_get_arm_fclk_freq(struct ti_cl /* Calculate the MPU freq */ - mpuclk = (sysclk * pll_mult) / pll_div; + mpuclk = ((uint64_t)sysclk * pll_mult) / pll_div; /* Return the value */ if (freq) _______________________________________________ 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 Thu Mar 6 23:33:32 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06FA332F for ; Thu, 6 Mar 2014 23:33:32 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C840DB5C for ; Thu, 6 Mar 2014 23:33:31 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WLhn1-0001kF-OV; Thu, 06 Mar 2014 23:33:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s26NXJce051300; Thu, 6 Mar 2014 16:33:19 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/lY5GzpWNEixorpX6/3p5x Subject: Re: TMPFS in kernels From: Ian Lepore To: Jia-Shiun Li In-Reply-To: References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset="windows-1251" Date: Thu, 06 Mar 2014 16:33:19 -0700 Message-ID: <1394148799.1149.354.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s26NXJce051300 Cc: George Rosamond , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 23:33:32 -0000 On Thu, 2014-03-06 at 13:03 +0800, Jia-Shiun Li wrote: > On Tue, Mar 4, 2014 at 10:48 PM, Warner Losh wrote: > > > > On Mar 4, 2014, at 3:30 AM, Jia-Shiun Li wrote: > > > >> I remember hacking it a while ago to adopt tmpfs instead on my pxebo= ot > >> test environment. It only requires changing the line mdmfs mounting = md to > >> 'mount -t tmpfs' (plus mount options), and everything else will work= as usual. > > > > I=92ll have to give it a spin on NanoBSD then, at least as an option=85 > > >=20 > The actual patch & result pasted below to save you some time. > Only tested on x86 pxeboot though. >=20 > -----8<----------8<----------8<----- >=20 > % diff -bu /usr/src/etc/rc.initdiskless > /b/tftpboot/FreeBSD/install/etc/rc.initdiskless > --- /usr/src/etc/rc.initdiskless 2013-04-11 21:03:31.000000000 += 0800 > +++ /b/tftpboot/FreeBSD/install/etc/rc.initdiskless 2014-03-06 > 12:43:47.000000000 +0800 > @@ -198,7 +198,10 @@ > # Create a generic memory disk > # > mount_md() { > - /sbin/mdmfs -S -i 4096 -s $1 -M md $2 > +# /sbin/mdmfs -S -i 4096 -s $1 -M md $2 > + local tmpfs_size > + tmpfs_size=3D$(($1 * 1024)) > + /sbin/mount -t tmpfs -osize=3D$tmpfs_size tmpfs $2 > } >=20 > # Create the memory filesystem if it has not already been created >=20 > % cat df > Filesystem Size Used Avail > Capacity Mounted on > 192.168.233.1:/b/tftpboot/FreeBSD/install/ 29G 17G 9.8G 6= 3% / > devfs 1.0K 1.0K 0B > 100% /dev > tmpfs 10M 2.6M 7.4M > 26% /etc > tmpfs 10M 180K 9.8M > 2% /var > /dev/md0 19M 24K 17M > 0% /tmp > % cat mount > 192.168.233.1:/b/tftpboot/FreeBSD/install/ on / (nfs, read-only) > devfs on /dev (devfs, local, multilabel) > tmpfs on /etc (tmpfs, local) > tmpfs on /var (tmpfs, local) > /dev/md0 on /tmp (ufs, local) >=20 >=20 > -Jia-Shiun. FYI, I just posted a patchset to freebsd-arch@ and freebsd-rc@ to address this in a slightly different way.=20 http://lists.freebsd.org/pipermail/freebsd-arch/2014-March/015141.html Basically I updated the mdmfs program to automatically use tmpfs if it's available in the kernel and the device name is "auto", along with changes to rc.initdiskless and defaults/rc.conf to set the device name to "auto" by default. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:14:30 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 769F2B6F; Fri, 7 Mar 2014 00:14:30 +0000 (UTC) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 319C6ED3; Fri, 7 Mar 2014 00:14:29 +0000 (UTC) Received: from 127.0.0.1 (tor-exit-node.cs.washington.edu [128.208.2.233]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id s270EEvs086818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Mar 2014 19:14:18 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <53190F52.7030605@ceetonetechnology.com> Date: Thu, 06 Mar 2014 19:14:10 -0500 From: George Rosamond MIME-Version: 1.0 To: Ian Lepore , Jia-Shiun Li Subject: Re: TMPFS in kernels References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> <1394148799.1149.354.camel@revolution.hippie.lan> In-Reply-To: <1394148799.1149.354.camel@revolution.hippie.lan> Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:14:30 -0000 Ian Lepore: > On Thu, 2014-03-06 at 13:03 +0800, Jia-Shiun Li wrote: >> On Tue, Mar 4, 2014 at 10:48 PM, Warner Losh wrote: >>> >>> On Mar 4, 2014, at 3:30 AM, Jia-Shiun Li wrote: >>> >>>> I remember hacking it a while ago to adopt tmpfs instead on my pxeboot >>>> test environment. It only requires changing the line mdmfs mounting md to >>>> 'mount -t tmpfs' (plus mount options), and everything else will work as usual. >>> >>> Ill have to give it a spin on NanoBSD then, at least as an option >>> >> >> The actual patch & result pasted below to save you some time. >> Only tested on x86 pxeboot though. >> >> -----8<----------8<----------8<----- >> >> % diff -bu /usr/src/etc/rc.initdiskless >> /b/tftpboot/FreeBSD/install/etc/rc.initdiskless >> --- /usr/src/etc/rc.initdiskless 2013-04-11 21:03:31.000000000 +0800 >> +++ /b/tftpboot/FreeBSD/install/etc/rc.initdiskless 2014-03-06 >> 12:43:47.000000000 +0800 >> @@ -198,7 +198,10 @@ >> # Create a generic memory disk >> # >> mount_md() { >> - /sbin/mdmfs -S -i 4096 -s $1 -M md $2 >> +# /sbin/mdmfs -S -i 4096 -s $1 -M md $2 >> + local tmpfs_size >> + tmpfs_size=$(($1 * 1024)) >> + /sbin/mount -t tmpfs -osize=$tmpfs_size tmpfs $2 >> } >> >> # Create the memory filesystem if it has not already been created >> >> % cat df >> Filesystem Size Used Avail >> Capacity Mounted on >> 192.168.233.1:/b/tftpboot/FreeBSD/install/ 29G 17G 9.8G 63% / >> devfs 1.0K 1.0K 0B >> 100% /dev >> tmpfs 10M 2.6M 7.4M >> 26% /etc >> tmpfs 10M 180K 9.8M >> 2% /var >> /dev/md0 19M 24K 17M >> 0% /tmp >> % cat mount >> 192.168.233.1:/b/tftpboot/FreeBSD/install/ on / (nfs, read-only) >> devfs on /dev (devfs, local, multilabel) >> tmpfs on /etc (tmpfs, local) >> tmpfs on /var (tmpfs, local) >> /dev/md0 on /tmp (ufs, local) >> >> >> -Jia-Shiun. > > FYI, I just posted a patchset to freebsd-arch@ and freebsd-rc@ to > address this in a slightly different way. > > http://lists.freebsd.org/pipermail/freebsd-arch/2014-March/015141.html > > Basically I updated the mdmfs program to automatically use tmpfs if it's > available in the kernel and the device name is "auto", along with > changes to rc.initdiskless and defaults/rc.conf to set the device name > to "auto" by default. > Cool. So assume it would then be added to the (new) RPI-B and ALIX kernels. Am I correct? g From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:20:32 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EB7CC5D for ; Fri, 7 Mar 2014 00:20:32 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD72DF15 for ; Fri, 7 Mar 2014 00:20:31 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WLiWc-0000iI-IS; Fri, 07 Mar 2014 00:20:30 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s270KS6A051357; Thu, 6 Mar 2014 17:20:28 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/+qMZtEVrNLrEw+OtZ87kW Subject: Re: TMPFS in kernels From: Ian Lepore To: George Rosamond In-Reply-To: <53190F52.7030605@ceetonetechnology.com> References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> <1394148799.1149.354.camel@revolution.hippie.lan> <53190F52.7030605@ceetonetechnology.com> Content-Type: text/plain; charset="windows-1251" Date: Thu, 06 Mar 2014 17:20:27 -0700 Message-ID: <1394151627.1149.357.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s270KS6A051357 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:20:32 -0000 On Thu, 2014-03-06 at 19:14 -0500, George Rosamond wrote: > Ian Lepore: > > On Thu, 2014-03-06 at 13:03 +0800, Jia-Shiun Li wrote: > >> On Tue, Mar 4, 2014 at 10:48 PM, Warner Losh wrote: > >>> > >>> On Mar 4, 2014, at 3:30 AM, Jia-Shiun Li wrote= : > >>> > >>>> I remember hacking it a while ago to adopt tmpfs instead on my pxe= boot > >>>> test environment. It only requires changing the line mdmfs mountin= g md to > >>>> 'mount -t tmpfs' (plus mount options), and everything else will wo= rk as usual. > >>> > >>> I=92ll have to give it a spin on NanoBSD then, at least as an optio= n=85 > >>> > >> > >> The actual patch & result pasted below to save you some time. > >> Only tested on x86 pxeboot though. > >> > >> -----8<----------8<----------8<----- > >> > >> % diff -bu /usr/src/etc/rc.initdiskless > >> /b/tftpboot/FreeBSD/install/etc/rc.initdiskless > >> --- /usr/src/etc/rc.initdiskless 2013-04-11 21:03:31.00000000= 0 +0800 > >> +++ /b/tftpboot/FreeBSD/install/etc/rc.initdiskless 2014-03-06 > >> 12:43:47.000000000 +0800 > >> @@ -198,7 +198,10 @@ > >> # Create a generic memory disk > >> # > >> mount_md() { > >> - /sbin/mdmfs -S -i 4096 -s $1 -M md $2 > >> +# /sbin/mdmfs -S -i 4096 -s $1 -M md $2 > >> + local tmpfs_size > >> + tmpfs_size=3D$(($1 * 1024)) > >> + /sbin/mount -t tmpfs -osize=3D$tmpfs_size tmpfs $2 > >> } > >> > >> # Create the memory filesystem if it has not already been created > >> > >> % cat df > >> Filesystem Size Used Avail > >> Capacity Mounted on > >> 192.168.233.1:/b/tftpboot/FreeBSD/install/ 29G 17G 9.8G = 63% / > >> devfs 1.0K 1.0K 0B > >> 100% /dev > >> tmpfs 10M 2.6M 7.4M > >> 26% /etc > >> tmpfs 10M 180K 9.8M > >> 2% /var > >> /dev/md0 19M 24K 17M > >> 0% /tmp > >> % cat mount > >> 192.168.233.1:/b/tftpboot/FreeBSD/install/ on / (nfs, read-only) > >> devfs on /dev (devfs, local, multilabel) > >> tmpfs on /etc (tmpfs, local) > >> tmpfs on /var (tmpfs, local) > >> /dev/md0 on /tmp (ufs, local) > >> > >> > >> -Jia-Shiun. > >=20 > > FYI, I just posted a patchset to freebsd-arch@ and freebsd-rc@ to > > address this in a slightly different way.=20 > >=20 > > http://lists.freebsd.org/pipermail/freebsd-arch/2014-March/015141.htm= l > >=20 > > Basically I updated the mdmfs program to automatically use tmpfs if i= t's > > available in the kernel and the device name is "auto", along with > > changes to rc.initdiskless and defaults/rc.conf to set the device nam= e > > to "auto" by default. > >=20 >=20 > Cool. So assume it would then be added to the (new) RPI-B and ALIX > kernels. Am I correct? >=20 > g >=20 Yeah, for the kernel side of it, I'm just adding TMPFS to arm/conf/DEFAULTS since the concensus seems to be that we want it in all kernels. I'm waiting for a universe-kernels build to finish and if it's clean I'll commit that tonight. For the other part of it, we'll see what feedback comes from the review on the other lists, it may not get committed for a few days. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:25:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42BA8D28 for ; Fri, 7 Mar 2014 00:25:12 +0000 (UTC) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0FBE8FB0 for ; Fri, 7 Mar 2014 00:25:11 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id md12so3360400pbc.35 for ; Thu, 06 Mar 2014 16:25:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=uf1BGtfHEQOFbMXyRVO0/Z1PcVnPOggMWdPLNRiXIgU=; b=S9C1K3AUQpiMMIdwXf0UWs4HjiIslt3JZJQm3GBiTaIhwNI/Q1TKFlHaQDCXdJMaqw nX0yYwzJRhNfAZfdnBhYcdB6Sj+BPWUfuqVfEJmh12+pLNxb6MnyVAiFtG/bpCEmt9Bw 2CNr9NoJPBCU0Hd4ruA9/HVUV3aLUhV9UYTEnL+7parA/k7oHHBIdTTYiMzRdsfeg/Cg mlGUXUm4vvY+RDbJ83AVCbZUzEEHxUOD7cDBKyJQeTDUiVtSyL5EwqcqHyMZqd93fodd m/9XXzIFapUOZc6WSYMP4vazA1ho8wegD99jLdFPHm7lKW1qVGDUBLe4y6ty0abXGbtY RxLQ== X-Gm-Message-State: ALoCoQmO9oUe1BdJ0JT5QkEAtReZJ4DxNIND4Z9vMahmLf6E1NlqsyYSdpt+iCZZZ3XUzrOP24Gv X-Received: by 10.69.31.43 with SMTP id kj11mr17809282pbd.67.1394151911095; Thu, 06 Mar 2014 16:25:11 -0800 (PST) Received: from lglt-nvaradarajan.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id tu3sm48151209pab.1.2014.03.06.16.25.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 16:25:10 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: TMPFS in kernels From: Warner Losh In-Reply-To: <1394151627.1149.357.camel@revolution.hippie.lan> Date: Thu, 6 Mar 2014 17:25:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> <1394148799.1149.354.camel@revolution.hippie.lan> <53190F52.7030605@ceetonetechnology.com> <1394151627.1149.357.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: George Rosamond , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:25:12 -0000 On Mar 6, 2014, at 5:20 PM, Ian Lepore wrote: > On Thu, 2014-03-06 at 19:14 -0500, George Rosamond wrote: >> Ian Lepore: >>> On Thu, 2014-03-06 at 13:03 +0800, Jia-Shiun Li wrote: >>>> On Tue, Mar 4, 2014 at 10:48 PM, Warner Losh = wrote: >>>>>=20 >>>>> On Mar 4, 2014, at 3:30 AM, Jia-Shiun Li = wrote: >>>>>=20 >>>>>> I remember hacking it a while ago to adopt tmpfs instead on my = pxeboot >>>>>> test environment. It only requires changing the line mdmfs = mounting md to >>>>>> 'mount -t tmpfs' (plus mount options), and everything else will = work as usual. >>>>>=20 >>>>> I=92ll have to give it a spin on NanoBSD then, at least as an = option=85 >>>>>=20 >>>>=20 >>>> The actual patch & result pasted below to save you some time. >>>> Only tested on x86 pxeboot though. >>>>=20 >>>> -----8<----------8<----------8<----- >>>>=20 >>>> % diff -bu /usr/src/etc/rc.initdiskless >>>> /b/tftpboot/FreeBSD/install/etc/rc.initdiskless >>>> --- /usr/src/etc/rc.initdiskless 2013-04-11 = 21:03:31.000000000 +0800 >>>> +++ /b/tftpboot/FreeBSD/install/etc/rc.initdiskless 2014-03-06 >>>> 12:43:47.000000000 +0800 >>>> @@ -198,7 +198,10 @@ >>>> # Create a generic memory disk >>>> # >>>> mount_md() { >>>> - /sbin/mdmfs -S -i 4096 -s $1 -M md $2 >>>> +# /sbin/mdmfs -S -i 4096 -s $1 -M md $2 >>>> + local tmpfs_size >>>> + tmpfs_size=3D$(($1 * 1024)) >>>> + /sbin/mount -t tmpfs -osize=3D$tmpfs_size tmpfs $2 >>>> } >>>>=20 >>>> # Create the memory filesystem if it has not already been created >>>>=20 >>>> % cat df >>>> Filesystem Size Used Avail >>>> Capacity Mounted on >>>> 192.168.233.1:/b/tftpboot/FreeBSD/install/ 29G 17G 9.8G = 63% / >>>> devfs 1.0K 1.0K 0B >>>> 100% /dev >>>> tmpfs 10M 2.6M 7.4M >>>> 26% /etc >>>> tmpfs 10M 180K 9.8M >>>> 2% /var >>>> /dev/md0 19M 24K 17M >>>> 0% /tmp >>>> % cat mount >>>> 192.168.233.1:/b/tftpboot/FreeBSD/install/ on / (nfs, read-only) >>>> devfs on /dev (devfs, local, multilabel) >>>> tmpfs on /etc (tmpfs, local) >>>> tmpfs on /var (tmpfs, local) >>>> /dev/md0 on /tmp (ufs, local) >>>>=20 >>>>=20 >>>> -Jia-Shiun. >>>=20 >>> FYI, I just posted a patchset to freebsd-arch@ and freebsd-rc@ to >>> address this in a slightly different way.=20 >>>=20 >>> = http://lists.freebsd.org/pipermail/freebsd-arch/2014-March/015141.html >>>=20 >>> Basically I updated the mdmfs program to automatically use tmpfs if = it's >>> available in the kernel and the device name is "auto", along with >>> changes to rc.initdiskless and defaults/rc.conf to set the device = name >>> to "auto" by default. >>>=20 >>=20 >> Cool. So assume it would then be added to the (new) RPI-B and ALIX >> kernels. Am I correct? >>=20 >> g >>=20 >=20 > Yeah, for the kernel side of it, I'm just adding TMPFS to > arm/conf/DEFAULTS since the concensus seems to be that we want it in = all > kernels. I'm waiting for a universe-kernels build to finish and if = it's > clean I'll commit that tonight. DEFAULTS was never intended for something like this.. Only for things = that must be mandatory or very nearly mandatory for the system to operate. = While useful, this isn=92t mandatory by any stretch of the imagination. I = strongly object to putting it there, so please don=92t commit it to DEFAULTS. > For the other part of it, we'll see what feedback comes from the = review > on the other lists, it may not get committed for a few days. Those looked good to me. Warner= From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:29:39 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F1961A2 for ; Fri, 7 Mar 2014 00:29:39 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D0EFA70 for ; Fri, 7 Mar 2014 00:29:38 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WLifR-0004ye-PF; Fri, 07 Mar 2014 00:29:37 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s270TZpa051378; Thu, 6 Mar 2014 17:29:35 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+NIb1WS7mavsdSHRQyQ4rY Subject: Re: TMPFS in kernels From: Ian Lepore To: Warner Losh In-Reply-To: References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> <1394148799.1149.354.camel@revolution.hippie.lan> <53190F52.7030605@ceetonetechnology.com> <1394151627.1149.357.camel@revolution.hippie.lan> Content-Type: text/plain; charset="iso-8859-7" Date: Thu, 06 Mar 2014 17:29:35 -0700 Message-ID: <1394152175.1149.360.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s270TZpa051378 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:29:39 -0000 On Thu, 2014-03-06 at 17:25 -0700, Warner Losh wrote: > On Mar 6, 2014, at 5:20 PM, Ian Lepore wrote: >=20 [...] > > Yeah, for the kernel side of it, I'm just adding TMPFS to > > arm/conf/DEFAULTS since the concensus seems to be that we want it in = all > > kernels. I'm waiting for a universe-kernels build to finish and if i= t's > > clean I'll commit that tonight. >=20 > DEFAULTS was never intended for something like this.. Only for things t= hat > must be mandatory or very nearly mandatory for the system to operate. W= hile > useful, this isn=A2t mandatory by any stretch of the imagination. I str= ongly object > to putting it there, so please don=A2t commit it to DEFAULTS. Ooops, your email and the commit passed each other on the wires. But... really? An option we want in every kernel we should paste into 70+ files instead of into the one file that they all include? -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:36:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EB45289; Fri, 7 Mar 2014 00:36:14 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EFD6F157; Fri, 7 Mar 2014 00:36:13 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 6F073BD61; Fri, 7 Mar 2014 00:36:12 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 6F073BD61 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 6 Mar 2014 19:36:10 -0500 From: Glen Barber To: Ian Lepore Subject: Re: TMPFS in kernels Message-ID: <20140307003610.GE87036@glenbarber.us> References: <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> <1394148799.1149.354.camel@revolution.hippie.lan> <53190F52.7030605@ceetonetechnology.com> <1394151627.1149.357.camel@revolution.hippie.lan> <1394152175.1149.360.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8M+gQFKLhTGBxzRu" Content-Disposition: inline In-Reply-To: <1394152175.1149.360.camel@revolution.hippie.lan> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:36:14 -0000 --8M+gQFKLhTGBxzRu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 06, 2014 at 05:29:35PM -0700, Ian Lepore wrote: > On Thu, 2014-03-06 at 17:25 -0700, Warner Losh wrote: > > On Mar 6, 2014, at 5:20 PM, Ian Lepore wrote: > >=20 > [...] > > > Yeah, for the kernel side of it, I'm just adding TMPFS to > > > arm/conf/DEFAULTS since the concensus seems to be that we want it in = all > > > kernels. I'm waiting for a universe-kernels build to finish and if i= t's > > > clean I'll commit that tonight. > >=20 > > DEFAULTS was never intended for something like this.. Only for things t= hat > > must be mandatory or very nearly mandatory for the system to operate. W= hile > > useful, this isn=E2=80=99t mandatory by any stretch of the imagination.= I strongly object > > to putting it there, so please don=E2=80=99t commit it to DEFAULTS. >=20 >=20 > Ooops, your email and the commit passed each other on the wires. >=20 > But... really? An option we want in every kernel we should paste into > 70+ files instead of into the one file that they all include? >=20 Why not include it by default, and exclude it where not needed/wanted? Glen --8M+gQFKLhTGBxzRu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTGRR6AAoJELls3eqvi17QQmwQAL/KOU7PyMFKNiW3L27Ft5cB j187delfGtPKgb070cmQqB/At2jOhHF6yJPVWimHN7Qh2SISe/1INEpEZJBk7HH3 QjLW0v/RNMObTvYye6aPEJujrGfZGPwesxyBiEHzfZbC9FNAzoGu9IsKN+hrUsy2 tLhfAoRgud0OuRA3tpk+sv/Zyzhk6nbWkIfIJQGs1X7vaIVbAbysrMctlB+0V4sU r4cnFxooZHDRmeEWECa7kLNImzuYMTL0b2sihk+8Jo1K9+y+7D70/WpOhR+ruFkZ 23zINdBamMsVbXYqkMjloV4fQ1DZkCZazJrUuiVnE++xsaDLxP182gwM9Q76jJg0 vYlKexbUuglY/TF8Fjbq+p4G79R7BC2KYU2SjwUiO3T3A5Wmx+rqXcXszv09hPMj MEW4lNDBGU236CP/sTdix9I4Xeeo9fbFSNVYbcmB7QK8Ru+kgi26s/0VhyzNtQkH Sqvo4V5igC+B32E1Inhx5/TafX7Ui/DH6EET52fKDOYhCpkTxJ1i+fev2YifbyLa sDjC9oMqCQqhstMb9xYWXfiI8y1IWy/fsy/4ociLPbzCV0Bxd0QSpAXCHmOWnNUT ErAbvJozhD3NO5eXdfOKm7QjbT1iSSBbf9ijIpDhTsg1zjW0jXyzBtbkhTpOjQC1 TjyuogZ9c9412pKfOplo =EnjV -----END PGP SIGNATURE----- --8M+gQFKLhTGBxzRu-- From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:43:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1DDF5E5 for ; Fri, 7 Mar 2014 00:43:25 +0000 (UTC) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F325217 for ; Fri, 7 Mar 2014 00:43:25 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id lj1so3381820pab.6 for ; Thu, 06 Mar 2014 16:43:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=tcHW8U4mUAEG4eBExkwch8w3yn70bpYiiRNHe+XTr9Q=; b=UN6/dbHh95oSHi4NvyTYaFRXX8Su9dTLi+wBHX8x4O685ntM9ML3GwWERoz97mbX6J wBbowUc5DpxU0hVImiqFoJv64ysaxKkjvQ0xMKztmIKe1/KBkpTz356lUQ/v07ol3kly IBEVLM4COn26GaLpIXLwli4AXMvQxMzxX+khrvlUE9steHZtVdBb8vdjSR+laiZhqj+C KEBogbMy1tU6EoYl6wzsncgGhw9p9piFt4QQleH7nrD8h6KIgHktTn7Wlrn6apgdxhbE axjKg7KNn3YWEcuNPIuW8vwRLCgXpMNTMFyT0ekUDhoZ4SkuRz6UTj51cs6B7vBgR0us QC9g== X-Gm-Message-State: ALoCoQldjjwH+t9RKVzR3FCGVo7GxzZ/DWFEztzA6YGz7p52mHRqFYI4n6nX8VNM+UwexYy8Cp52 X-Received: by 10.66.161.138 with SMTP id xs10mr4017173pab.126.1394152998229; Thu, 06 Mar 2014 16:43:18 -0800 (PST) Received: from lglt-nvaradarajan.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id vb7sm24075264pbc.13.2014.03.06.16.43.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 16:43:17 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: TMPFS in kernels From: Warner Losh In-Reply-To: <1394152175.1149.360.camel@revolution.hippie.lan> Date: Thu, 6 Mar 2014 17:43:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C2098DE-762E-49BF-8C00-D6D7AB588669@bsdimp.com> References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> <1394148799.1149.354.camel@revolution.hippie.lan> <53190F52.7030605@ceetonetechnology.com> <1394151627.1149.357.camel@revolution.hippie.lan> <1394152175.1149.360.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:43:25 -0000 On Mar 6, 2014, at 5:29 PM, Ian Lepore wrote: > On Thu, 2014-03-06 at 17:25 -0700, Warner Losh wrote: >> On Mar 6, 2014, at 5:20 PM, Ian Lepore wrote: >>=20 > [...] >>> Yeah, for the kernel side of it, I'm just adding TMPFS to >>> arm/conf/DEFAULTS since the concensus seems to be that we want it in = all >>> kernels. I'm waiting for a universe-kernels build to finish and if = it's >>> clean I'll commit that tonight. >>=20 >> DEFAULTS was never intended for something like this.. Only for things = that >> must be mandatory or very nearly mandatory for the system to operate. = While >> useful, this isn=A2t mandatory by any stretch of the imagination. I = strongly object >> to putting it there, so please don=A2t commit it to DEFAULTS. >=20 >=20 > Ooops, your email and the commit passed each other on the wires. >=20 > But... really? An option we want in every kernel we should paste into > 70+ files instead of into the one file that they all include? Yes. Otherwise we=A2d have large parts of GENERIC in there. Warner From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:43:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 491AD624 for ; Fri, 7 Mar 2014 00:43:43 +0000 (UTC) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1597021C for ; Fri, 7 Mar 2014 00:43:42 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id y13so3261922pdi.19 for ; Thu, 06 Mar 2014 16:43:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=a8jgxV8pBMDlgB6Qx5opVfeu/BkRzHevV3OoRUrm8qQ=; b=WPxHxkkQmBFpjKnwL10YTUQZvKngFwIZDXzd2w6ui4L6q64/oHOQsOwO5MwtvXU3Zv 6CGG/AgYPP3yyBkC1/bDrmUC2cvkh1H0fW+cu/JF1CNCswGGlKAZiA7wIClpA7Kg6yGD zA0Fnz6kO0zjtEGCsctblSvn3wBh/5ZBv6/1zjbCXOXB5ieRICHVBgRvvEW/LTTI9dmF RtYydTKWEE7RiHZBWMoktMx+9BuKCSCHs6EmMjRAHZDfTIIxvBIqk1QAukH9IO/TTYJP pZN7X3ZRenkr78rsTmUj9zGyIZo2sGG43NcLw0V1pjEhQ/Sf1hwuhiH6n/YBRCcJY99l YDug== X-Gm-Message-State: ALoCoQkS6F78T4/ZhhTBGCJoDX2wfNjUVafJ2BrBRVmSdHaty5zMCi9h8EQAaBFcRKM1MylBlBw8 X-Received: by 10.66.141.197 with SMTP id rq5mr18427693pab.64.1394153022509; Thu, 06 Mar 2014 16:43:42 -0800 (PST) Received: from lglt-nvaradarajan.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id vb7sm24075264pbc.13.2014.03.06.16.43.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 16:43:41 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: TMPFS in kernels From: Warner Losh In-Reply-To: <20140307003610.GE87036@glenbarber.us> Date: Thu, 6 Mar 2014 17:43:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> <1394148799.1149.354.camel@revolution.hippie.lan> <53190F52.7030605@ceetonetechnology.com> <1394151627.1149.357.camel@revolution.hippie.lan> <1394152175.1149.360.camel@revolution.hippie.lan> <20140307003610.GE87036@glenbarber.us> To: Glen Barber X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:43:43 -0000 On Mar 6, 2014, at 5:36 PM, Glen Barber wrote: > On Thu, Mar 06, 2014 at 05:29:35PM -0700, Ian Lepore wrote: >> On Thu, 2014-03-06 at 17:25 -0700, Warner Losh wrote: >>> On Mar 6, 2014, at 5:20 PM, Ian Lepore wrote: >>>=20 >> [...] >>>> Yeah, for the kernel side of it, I'm just adding TMPFS to >>>> arm/conf/DEFAULTS since the concensus seems to be that we want it = in all >>>> kernels. I'm waiting for a universe-kernels build to finish and if = it's >>>> clean I'll commit that tonight. >>>=20 >>> DEFAULTS was never intended for something like this.. Only for = things that >>> must be mandatory or very nearly mandatory for the system to = operate. While >>> useful, this isn=92t mandatory by any stretch of the imagination. I = strongly object >>> to putting it there, so please don=92t commit it to DEFAULTS. >>=20 >>=20 >> Ooops, your email and the commit passed each other on the wires. >>=20 >> But... really? An option we want in every kernel we should paste = into >> 70+ files instead of into the one file that they all include? >>=20 >=20 > Why not include it by default, and exclude it where not needed/wanted? DEFAULTS isn=92t the place for this. Warner From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:45:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FF81675 for ; Fri, 7 Mar 2014 00:45:05 +0000 (UTC) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1D4225 for ; Fri, 7 Mar 2014 00:45:05 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id jt11so3365189pbb.36 for ; Thu, 06 Mar 2014 16:44:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Pc67K9a60+6XD+20xiM0ppw3Z6pEiCiqnnDVY632L7I=; b=LHsLnVLdaS+40ZuRo+PkmzQ+J9pdPgEXL/UFXaSzxVSb5kB2fItkH7ylZEC8/nmKGO 4owonIIytT/qAAGKzYhOtZefpKoYjQ+Dkui2RhUE7HmHir/6PmILfmS9qURhYuZ7d/LL p9b7sn0b/72RA4Czh3FNtyNOKwjN1L/WFn1Sus8bY0zI9DHsnHI+tolHHohv6yyb6yZq t/x9FxfKUJqQGjBb82wgh+Qf/rWeZiqqcEtqOeFdPCMyaUWT4Uw59x8ht3kr6OnNvxKh ttLeBBc1tW53BjxwFCWeaU11NXuCCZHXkMS7+xCtlB3r3Haoca8llYBfYz0pmGS8aQEf QBIg== X-Gm-Message-State: ALoCoQlyWTmFhgGJrj3mLUV/ZOrFqQ1D3DHriZisLFtPidFFOhKXgcHASr6+iTt/4fWmv0EhHqX9 X-Received: by 10.68.102.34 with SMTP id fl2mr18233813pbb.2.1394153099869; Thu, 06 Mar 2014 16:44:59 -0800 (PST) Received: from lglt-nvaradarajan.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id qw8sm24114058pbb.27.2014.03.06.16.44.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 16:44:59 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: TMPFS in kernels From: Warner Losh In-Reply-To: <1394152175.1149.360.camel@revolution.hippie.lan> Date: Thu, 6 Mar 2014 17:44:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <36334438-6D08-4E4A-AC6F-1E4359717A2F@bsdimp.com> References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> <1394148799.1149.354.camel@revolution.hippie.lan> <53190F52.7030605@ceetonetechnology.com> <1394151627.1149.357.camel@revolution.hippie.lan> <1394152175.1149.360.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:45:05 -0000 On Mar 6, 2014, at 5:29 PM, Ian Lepore wrote: > On Thu, 2014-03-06 at 17:25 -0700, Warner Losh wrote: >> On Mar 6, 2014, at 5:20 PM, Ian Lepore wrote: >>=20 > [...] >>> Yeah, for the kernel side of it, I'm just adding TMPFS to >>> arm/conf/DEFAULTS since the concensus seems to be that we want it in = all >>> kernels. I'm waiting for a universe-kernels build to finish and if = it's >>> clean I'll commit that tonight. >>=20 >> DEFAULTS was never intended for something like this.. Only for things = that >> must be mandatory or very nearly mandatory for the system to operate. = While >> useful, this isn=A2t mandatory by any stretch of the imagination. I = strongly object >> to putting it there, so please don=A2t commit it to DEFAULTS. >=20 >=20 > Ooops, your email and the commit passed each other on the wires. >=20 > But... really? An option we want in every kernel we should paste into > 70+ files instead of into the one file that they all include? I=A2ll fix it later tonight. Warner From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:46:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD4406CD for ; Fri, 7 Mar 2014 00:46:42 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 991B8232 for ; Fri, 7 Mar 2014 00:46:41 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WLivw-000Dlm-9s; Fri, 07 Mar 2014 00:46:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s270kb9U051435; Thu, 6 Mar 2014 17:46:37 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+UCf15Dx8lZ7gfB+dahQFz Subject: Re: TMPFS in kernels From: Ian Lepore To: Warner Losh In-Reply-To: <3C2098DE-762E-49BF-8C00-D6D7AB588669@bsdimp.com> References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> <1394148799.1149.354.camel@revolution.hippie.lan> <53190F52.7030605@ceetonetechnology.com> <1394151627.1149.357.camel@revolution.hippie.lan> <1394152175.1149.360.camel@revolution.hippie.lan> <3C2098DE-762E-49BF-8C00-D6D7AB588669@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" Date: Thu, 06 Mar 2014 17:46:37 -0700 Message-ID: <1394153197.1149.363.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s270kb9U051435 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:46:42 -0000 On Thu, 2014-03-06 at 17:43 -0700, Warner Losh wrote: > On Mar 6, 2014, at 5:29 PM, Ian Lepore wrote: >=20 > > On Thu, 2014-03-06 at 17:25 -0700, Warner Losh wrote: > >> On Mar 6, 2014, at 5:20 PM, Ian Lepore wrote: > >>=20 > > [...] > >>> Yeah, for the kernel side of it, I'm just adding TMPFS to > >>> arm/conf/DEFAULTS since the concensus seems to be that we want it i= n all > >>> kernels. I'm waiting for a universe-kernels build to finish and if= it's > >>> clean I'll commit that tonight. > >>=20 > >> DEFAULTS was never intended for something like this.. Only for thing= s that > >> must be mandatory or very nearly mandatory for the system to operate= . While > >> useful, this isn=A2t mandatory by any stretch of the imagination. I = strongly object > >> to putting it there, so please don=A2t commit it to DEFAULTS. > >=20 > >=20 > > Ooops, your email and the commit passed each other on the wires. > >=20 > > But... really? An option we want in every kernel we should paste int= o > > 70+ files instead of into the one file that they all include? >=20 > Yes. Otherwise we=A2d have large parts of GENERIC in there. >=20 > Warner Alright, then if that's the case I'm taking GEOM_PART_BSD and GEOM_PART_MBR out of there and pasting them into every kernel as well, because they certainly aren't mandatory (or even necessary if you use GPT). That will leave just "device mem" in there. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:48:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E81C8721 for ; Fri, 7 Mar 2014 00:48:46 +0000 (UTC) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B3D9A23D for ; Fri, 7 Mar 2014 00:48:46 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id uo5so3367146pbc.24 for ; Thu, 06 Mar 2014 16:48:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=adbdfBWZOaHOLSjWh1xnin3fz2XGeR6GXofcXjGOxy0=; b=jCEtInMaj7w/+gwbUQjdJEFO90Lx0PVCsRTc2tFCqu3XwB4X2KY3519+eO5O3BJsML rR3TAUHIO00vAoDUE6WmESHbTWnT6S8XUZaJMfs4K8NEXqMZ5sefxWm26YzgZdhmHB4y EAe3sUwfZbsjpQomiIk5zL/fKlVMSsezOrE56MzmOll5qsrTqsbTXErjpKA0ZUzSO2tu LECRJdqg0jmyG0whcAGwFCETaQKyMlVdszp/IEfjEuirlflNO+weoljh/AmYZKmv8auP 3yG1hhGRmCvrNlsYKhUeKo3vbSfWwN7ma/UE3Z5BQzujMkw5KzOrcepa1vC3OXCWxRTg vQUQ== X-Gm-Message-State: ALoCoQnp2vs6l5acSVGHWl5vqmSexuTZMVGWRosIL99gFpK1hF5eLozsnS4yc8NXXdQUQbnEwqo+ X-Received: by 10.66.158.132 with SMTP id wu4mr18416329pab.66.1394153326221; Thu, 06 Mar 2014 16:48:46 -0800 (PST) Received: from lgmac-cvenus.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ja8sm24089340pbd.3.2014.03.06.16.48.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 16:48:45 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1253 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: TMPFS in kernels From: Warner Losh In-Reply-To: <1394153197.1149.363.camel@revolution.hippie.lan> Date: Thu, 6 Mar 2014 17:48:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5313D0FE.8010008@ceetonetechnology.com> <1393818974.1149.270.camel@revolution.hippie.lan> <5314016B.1000107@ceetonetechnology.com> <20140303061136.GB85204@zibbi.meraka.csir.co.za> <1394148799.1149.354.camel@revolution.hippie.lan> <53190F52.7030605@ceetonetechnology.com> <1394151627.1149.357.camel@revolution.hippie.lan> <1394152175.1149.360.camel@revolution.hippie.lan> <3C2098DE-762E-49BF-8C00-D6D7AB588669@bsdimp.com> <1394153197.1149.363.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:48:47 -0000 On Mar 6, 2014, at 5:46 PM, Ian Lepore wrote: > On Thu, 2014-03-06 at 17:43 -0700, Warner Losh wrote: >> On Mar 6, 2014, at 5:29 PM, Ian Lepore wrote: >>=20 >>> On Thu, 2014-03-06 at 17:25 -0700, Warner Losh wrote: >>>> On Mar 6, 2014, at 5:20 PM, Ian Lepore wrote: >>>>=20 >>> [...] >>>>> Yeah, for the kernel side of it, I'm just adding TMPFS to >>>>> arm/conf/DEFAULTS since the concensus seems to be that we want it = in all >>>>> kernels. I'm waiting for a universe-kernels build to finish and = if it's >>>>> clean I'll commit that tonight. >>>>=20 >>>> DEFAULTS was never intended for something like this.. Only for = things that >>>> must be mandatory or very nearly mandatory for the system to = operate. While >>>> useful, this isn=92t mandatory by any stretch of the imagination. I = strongly object >>>> to putting it there, so please don=92t commit it to DEFAULTS. >>>=20 >>>=20 >>> Ooops, your email and the commit passed each other on the wires. >>>=20 >>> But... really? An option we want in every kernel we should paste = into >>> 70+ files instead of into the one file that they all include? >>=20 >> Yes. Otherwise we=92d have large parts of GENERIC in there. >>=20 >> Warner >=20 > Alright, then if that's the case I'm taking GEOM_PART_BSD and > GEOM_PART_MBR out of there and pasting them into every kernel as well, > because they certainly aren't mandatory (or even necessary if you use > GPT). That will leave just "device mem" in there. That should have happened a long time ago=85 Warner From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 00:53:44 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7CCB99C; Fri, 7 Mar 2014 00:53:44 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83C53359; Fri, 7 Mar 2014 00:53:44 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 9E3E6BF2A; Fri, 7 Mar 2014 00:53:42 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 9E3E6BF2A Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 6 Mar 2014 19:53:40 -0500 From: Glen Barber To: Warner Losh Subject: Re: TMPFS in kernels Message-ID: <20140307005340.GF87036@glenbarber.us> References: <1394148799.1149.354.camel@revolution.hippie.lan> <53190F52.7030605@ceetonetechnology.com> <1394151627.1149.357.camel@revolution.hippie.lan> <1394152175.1149.360.camel@revolution.hippie.lan> <20140307003610.GE87036@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TUvp6TiFcfhGC84w" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:53:44 -0000 --TUvp6TiFcfhGC84w Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 06, 2014 at 05:43:42PM -0700, Warner Losh wrote: > On Mar 6, 2014, at 5:36 PM, Glen Barber wrote: > > Why not include it by default, and exclude it where not needed/wanted? >=20 > DEFAULTS isn=E2=80=99t the place for this. >=20 I'm certainly not disputing that. Not that I want to advocate "Just Another Kernel Config", maybe another kernel config to include TMPFS is needed. Glen --TUvp6TiFcfhGC84w Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTGRiUAAoJELls3eqvi17QLpQQAJZgrUp1UrhyfiqknFcndLsd hnfNNm+1THe7xQNzkQ4cj/yzCYsWQ8YFtzmc+T08GvmZr5Di7U3lWcnk5YLmxCDQ NGaXE9zdus4pxePqY4mhSdzip7fTD6K2WLj2dtax+JKopgDxmaE8QM7oTGvB9CzR 7WVI3Xx1pzy6WzPeGJWZgxfAgARQnvDdVj7afpbF7qJ7cLsaUEoC5sTH2EE9fk1C BBi0V1bzEw+IAQx1iYCv/7/VzYJdkzvLWq9Hvos2Dy+rnonifilK4Wwl3TB9dnpT TOpmv3w/PyDiwSzDoYDJDb3MDmGpzWfodK2JyNOBDeHpEn57SBX42455Fby2aHbY SJhcd23k6NaBXL0V7Re7tTQokqoi7QZvFwfzJ9FHEIDqQMxc+ywMUmlGS/ytlli7 xt5uMcZtsOK+EXhW/T6ev57XBrzPU4bfekgFMNUCG242mxolXCTJtZMZjVkscBkp DwwsjudFZcjMELUy4EJ5uaYQfVLdy1YvNG7gi3iCqdSq25q3vyEEJyaqPzJkhwX6 3w+BE8GjVT7GoljhGA4AWqMxfMAn6utpSXQi94vnIcLfPnBOZxJkvotEG4iwLXtp pcXMyOELVAhPq0JL9mHJqb1x69VTViof/N6QN8mt7JHF26FfH5K3Zc6TQJiVshn2 4Y1xLo/2uq50UxctEgpJ =7Z+L -----END PGP SIGNATURE----- --TUvp6TiFcfhGC84w-- From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 13:52:19 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B94EC88A; Fri, 7 Mar 2014 13:52:19 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FC501D8; Fri, 7 Mar 2014 13:52:19 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WLvCE-000A1z-7N; Fri, 07 Mar 2014 13:52:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s27DqFrK052142; Fri, 7 Mar 2014 06:52:15 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18B/tGzgsguymLLGEZx/nOf Subject: option NEW_PCIB From: Ian Lepore To: freebsd-arch , freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Fri, 07 Mar 2014 06:52:15 -0700 Message-ID: <1394200335.1149.370.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 13:52:19 -0000 Every architecture has "option NEW_PCIB" in its conf/DEFAULTS except arm and mips. Is that on purpose? What are the implications of adding it? Or maybe more importantly, what are the implications of it not being there? -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 14:15:54 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 975E6ED3 for ; Fri, 7 Mar 2014 14:15:54 +0000 (UTC) Received: from mail.machdep.com (mail.machdep.com [195.91.211.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 517DC39D for ; Fri, 7 Mar 2014 14:15:53 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=machdep.com) by mail.machdep.com with smtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WLvXK-000KeF-Ad for freebsd-arm@FreeBSD.org; Fri, 07 Mar 2014 18:14:06 +0400 Received: by machdep.com (nbSMTP-1.00) for uid 1001 br@machdep.com; Fri, 7 Mar 2014 18:14:06 +0400 (MSK) Date: Fri, 7 Mar 2014 18:14:06 +0400 From: Ruslan Bukin To: freebsd-arm Subject: ULE on ARM Message-ID: <20140307141406.GA79223@machdep.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 14:15:54 -0000 I discovered just a couple of ARM kernel configs uses SCHED_ULE, but all other uses SCHED_4BSD any disadvantages to use ULE scheduler on ARM? or it is just because of historical reasons? I enabled ULE on Freescale Vybrid and running it for a long time just fine. according to my subjective impressions ULE works better on ARM in sound applications -Ruslan From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 14:25:08 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD2F521A; Fri, 7 Mar 2014 14:25:08 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B225B662; Fri, 7 Mar 2014 14:25:08 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WLvhz-0004fT-F4; Fri, 07 Mar 2014 14:25:07 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s27EP48G052159; Fri, 7 Mar 2014 07:25:04 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19C92n1TDVjjWU9nzGh4IIB Subject: Re: ULE on ARM From: Ian Lepore To: Ruslan Bukin In-Reply-To: <20140307141406.GA79223@machdep.com> References: <20140307141406.GA79223@machdep.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 07 Mar 2014 07:25:04 -0700 Message-ID: <1394202304.1149.373.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 14:25:08 -0000 On Fri, 2014-03-07 at 18:14 +0400, Ruslan Bukin wrote: > I discovered just a couple of ARM kernel configs > uses SCHED_ULE, but all other uses SCHED_4BSD > > any disadvantages to use ULE scheduler on ARM? > or it is just because of historical reasons? > > I enabled ULE on Freescale Vybrid and running > it for a long time just fine. > > according to my subjective impressions ULE > works better on ARM in sound applications > > -Ruslan The widespread advice from a few years ago was that ULE was better for SMP and 4BSD was better for UP. I don't know whether that's still true (or whether it was ever true). I do know that there are fewer responses on mailing lists of "try switching the scheduler to 4BSD" as a way of fixing problems these days. I switched imx6 to ULE when adding SMP support for it. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 14:26:21 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EB01266; Fri, 7 Mar 2014 14:26:21 +0000 (UTC) Received: from kanar.ci0.org (kanar.ci0.org [IPv6:2001:bc8:35e6::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 20306670; Fri, 7 Mar 2014 14:26:20 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.8/8.14.8) with ESMTP id s27EPoB7043655; Fri, 7 Mar 2014 15:25:50 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.8/8.14.8/Submit) id s27EPocn043654; Fri, 7 Mar 2014 15:25:50 +0100 (CET) (envelope-from mlfbsd) Date: Fri, 7 Mar 2014 15:25:50 +0100 From: Olivier Houchard To: Ruslan Bukin Subject: Re: ULE on ARM Message-ID: <20140307142550.GA43639@ci0.org> References: <20140307141406.GA79223@machdep.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140307141406.GA79223@machdep.com> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 14:26:21 -0000 Hi Ruslan, On Fri, Mar 07, 2014 at 06:14:06PM +0400, Ruslan Bukin wrote: > I discovered just a couple of ARM kernel configs > uses SCHED_ULE, but all other uses SCHED_4BSD > > any disadvantages to use ULE scheduler on ARM? > or it is just because of historical reasons? > > I enabled ULE on Freescale Vybrid and running > it for a long time just fine. > > according to my subjective impressions ULE > works better on ARM in sound applications > > -Ruslan I think that's this way mostly for historical reason, because I had issues with ULE around 2004/2005 or so. Switching to ULE is probably fine by now, I just remember there's a probably issue with ULE and SMP in swtch.S, I'll check this. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 14:32:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52EC24B1 for ; Fri, 7 Mar 2014 14:32:40 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2623577F for ; Fri, 7 Mar 2014 14:32:39 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id lf10so4270566pab.27 for ; Fri, 07 Mar 2014 06:32:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=pzW5RET2Kj0AtxZZ6K0nwVr+w20ru+zQ2jomWCvyVJg=; b=Rg1j1Mw1NCshqPXSi/PVi04RqGQGW4OjKmepQeNev8er72r5BsaYVw1LmV0dMcZLRK 7Vp1r9ghPLr+SKUgRrqQJEGslafsv75o6hBGUA0PdabvNilf/jtggXoxKZ8Gu52ZRGqR 5g7QOiyjnzHQXDXWMe5x6ynb+UAsr+z/uBCJ1nS+++Ji3lGTMKDGV2B92rqRc2bVlt41 Tc01gfKgCJePuMglY4k+3sromOn/QWrbFmqL5G5QAUEIQaKIZ+u6XLfd66bdeVOF5XKo InRith6LYXguybPTZVX4Zjchez7WyUiZLlYdgcSiP8hRyTKjmNiIFjFp47YvMKzp9wlk 6WeA== X-Gm-Message-State: ALoCoQnLOCHiaeATFsOaiZQ6mIYuraCwuCd9WL7eBQeY39OjPAPzLxIqEKv23Of1WhAELO4CpN4V X-Received: by 10.66.66.66 with SMTP id d2mr22389528pat.80.1394202759338; Fri, 07 Mar 2014 06:32:39 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id g6sm8585105pat.2.2014.03.07.06.32.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 06:32:38 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: ULE on ARM From: Warner Losh In-Reply-To: <1394202304.1149.373.camel@revolution.hippie.lan> Date: Fri, 7 Mar 2014 07:32:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: <3BE23B6A-900C-4104-A398-30D5B2A282DB@bsdimp.com> References: <20140307141406.GA79223@machdep.com> <1394202304.1149.373.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm , Ruslan Bukin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 14:32:40 -0000 On Mar 7, 2014, at 7:25 AM, Ian Lepore wrote: > On Fri, 2014-03-07 at 18:14 +0400, Ruslan Bukin wrote: >> I discovered just a couple of ARM kernel configs >> uses SCHED_ULE, but all other uses SCHED_4BSD >> >> any disadvantages to use ULE scheduler on ARM? >> or it is just because of historical reasons? >> >> I enabled ULE on Freescale Vybrid and running >> it for a long time just fine. >> >> according to my subjective impressions ULE >> works better on ARM in sound applications >> >> -Ruslan > > The widespread advice from a few years ago was that ULE was better for > SMP and 4BSD was better for UP. I don't know whether that's still true > (or whether it was ever true). I do know that there are fewer responses > on mailing lists of "try switching the scheduler to 4BSD" as a way of > fixing problems these days. I switched imx6 to ULE when adding SMP > support for it. It all depends on the workload. 4BSD is better for some SMP workloads, while ULE is better for others. But as a general rule, Ian is right: 4BSD tends to be better at UP interactive workloads, while ULE tends to be better at MP work loads that have a larger compute element to them (complex transactions). Warner From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 14:38:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E0DCB9C for ; Fri, 7 Mar 2014 14:38:37 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 08B0A7CB for ; Fri, 7 Mar 2014 14:38:36 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so4457987iec.30 for ; Fri, 07 Mar 2014 06:38:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=W27fH1I87Ha8zkZSOY93njfGatefchgF18HihHKw/H8=; b=iuOaQXeaEYDezSDmCDtR9hobKI1/+Dqh5FQGf9Z4sfrtBgfbps7WmmsA8z2arRuASk R4U0nMpueODE3KVI6SdK+dv0F1Ib1MS9DYqmQcTo4K9VSyip8bjm2OuR7VA0edJFJGlo 47UfWQGklUuNkLCkWEKnBGA068gCm71oiJmzzvG2dtlFm14jbiGMaSG0e3N+kjV6YF5A K8dYG3Cewt+pDGYjQZAx8I5smqgMAiVMRpSWkjZbKct6gNxVH8Qnj+5nHVF1AeT7OBwQ 92dwjmyoQEjOW9s/OJNhBDOWJ7vmH5LUxPc4xBzEZmwsYRs26hCv8eOYLQ0+Wp3SDLLe 3TGA== X-Gm-Message-State: ALoCoQkuVlcjaRqwMm6u8P4JxP9o+CvAVXR/hT77q6jzJG/ang1P13/OpYUy+/llUXBDDh2lvXZQ X-Received: by 10.50.137.100 with SMTP id qh4mr3212252igb.34.1394203115760; Fri, 07 Mar 2014 06:38:35 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f1sm4531995igy.2.2014.03.07.06.38.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 06:38:35 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: option NEW_PCIB From: Warner Losh In-Reply-To: <1394200335.1149.370.camel@revolution.hippie.lan> Date: Fri, 7 Mar 2014 07:38:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <58AB4C66-4267-414D-80D4-B97FF86A94A5@bsdimp.com> References: <1394200335.1149.370.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm , freebsd-arch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 14:38:37 -0000 On Mar 7, 2014, at 6:52 AM, Ian Lepore wrote: > Every architecture has "option NEW_PCIB" in its conf/DEFAULTS except = arm > and mips. Is that on purpose? What are the implications of adding = it? > Or maybe more importantly, what are the implications of it not being > there? This is John Baldwin=92s option for his reworked PCI bridge code. He did = that as a fallback in case he really messed up something. It introduces = renumbering of busses that don=92t already have numbers assigned. It should be = enabled on ARM, but the required resource isn=92t defined on arm, and some of the = other required glue doesn=92t seem to be implemented for arm yet, which is why = things are the way they are at the moment. I think John intends for the option = to go away, and everything it covers will be =91standard=92. Warner From owner-freebsd-arm@FreeBSD.ORG Fri Mar 7 20:36:19 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 313F8B65 for ; Fri, 7 Mar 2014 20:36:19 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 05DBABEF for ; Fri, 7 Mar 2014 20:36:18 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WM1VB-000Enh-Jw; Fri, 07 Mar 2014 20:36:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s27KaC8g052513; Fri, 7 Mar 2014 13:36:13 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Qq51mlnszyvEMhkTYycaL Subject: Re: The arguments of sys_sigreturn From: Ian Lepore To: Takashi Komatsu In-Reply-To: <20140306135349.5C75.2910CF64@jp.panasonic.com> References: <20140306135349.5C75.2910CF64@jp.panasonic.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 07 Mar 2014 13:36:12 -0700 Message-ID: <1394224572.1149.379.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 20:36:19 -0000 On Thu, 2014-03-06 at 13:53 +0900, Takashi Komatsu wrote: > Hi, > > > I have a question about the function of sys_sigreturn. > [sys/arm/arm/machdep.c] > > In arm codes, the sys_sigreturn function use sigreturn_args. > I think it has to be used for "struct __ucontext". > > But it use "struct sigframe". > In fact, it's called with the argument "sigframe" by other function. > (sys/arm/arm/locore.S: L558) > > On the one hand, it's called by the thread library with "ucontext_t". > (lib/libthr/thread/thr_sig.c: L256) > > There is collision types. > > I attached my patch. > Please review. > Best regards, > Takashi Komatsu Yep, you are correct and that patch looks good, committed as r262903. It took me a while to figure out how sigcode() in locore.S ever gets called. The way the arm does the trampoline in/out of the userland signal handler is harder to understand than how the trampoline code on other architectures works. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 08:48:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 351C8F40 for ; Sat, 8 Mar 2014 08:48:43 +0000 (UTC) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0DA6FB2F for ; Sat, 8 Mar 2014 08:48:43 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id jt11so5169268pbb.36 for ; Sat, 08 Mar 2014 00:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=VhrsRfO6Ca40RDMK5I6Ika7CafKjjOY/mapssBShTeM=; b=n/h9uWRppsmFwHw9UnycSwp44dEYCF0eAOgpL5zAlNN/iCQnYEJJzpzkyHCc0QoUZw k5lSxTmUK4pszn/EUjjyZSSSw063McpSlhfWXlMYbrMWbLKjMlFgAps//kTC8rEf9/7S PKJscKvJuQ5BSknksc6pabUhwPXptxzje/ucz0Y7A8J34/hyFYkGNTyd9S2EALRktf0N ymZfhvnX9C89GWf05K0SGVFm+Pkob1hiORMG0VgQBJI09Xd6HIYvKEiMJArxbQBqHUKW TsH6Cp5E32kzVBOZedxOV1ktw3mtGJMbWc09Q24qdg3ygdwauOLLabkeQ4LPd5F+HKHh 9csw== X-Received: by 10.66.102.39 with SMTP id fl7mr27165932pab.43.1394268522212; Sat, 08 Mar 2014 00:48:42 -0800 (PST) Received: from [172.16.1.21] ([202.89.38.236]) by mx.google.com with ESMTPSA id vf7sm44413765pbc.5.2014.03.08.00.48.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Mar 2014 00:48:40 -0800 (PST) From: Stephen Woolerton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: building ICU port on arm Message-Id: Date: Sat, 8 Mar 2014 21:48:38 +1300 To: freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 08:48:43 -0000 Hi everyone, Just wondering if anyone has successfully built the ICU port or an ICU = package, on an arm device on FreeBSD 10. (Problem report 186823) The reason is I need to run some code which requires GNUstep-base, for = which ICU is a dependency. (I'm hoping to do this project on FreeBSD = rather than Linux.) Thanks Stephen From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 08:50:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB592F83 for ; Sat, 8 Mar 2014 08:50:09 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88AC7B3B for ; Sat, 8 Mar 2014 08:50:09 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id w5so5023074qac.6 for ; Sat, 08 Mar 2014 00:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=72TCNWDC7ljqg35iJwya9xzyK564paExQLSjgQA6a0Y=; b=VmAdlgr3LVw1rAAB0Ptp41NlEp6bbPcHxLhf9HI6nzjVoOC4BEJfYdm5CzFKxTf+KI VPdM+h8wsJF9AQStA1NRv/Z0ePK3ih7hEj/ruuHyHKHzOqWv14LZE3I+6QcoZk+Yf4Ym 3HjYZRaLhxm/ImkmPbPtd46gGAOyIgfm48yekZy85mgjl4QV+qtnX0yyY70ZD1ng32B5 PbaKsrjJWFt4CKGaqGheJ/hDbFnlsUk24i2eQ4ZaNXuVYK5wnF1lm8MwxIOYaVLxhfys 3b4D/HdGBQQhDTZx+IL8w2CqS0UBkVyz1TBYSX1kA+/UKP/6Vo++kxv/4zXwyGNkJYKN 3fIw== MIME-Version: 1.0 X-Received: by 10.224.125.4 with SMTP id w4mr27920916qar.68.1394268608660; Sat, 08 Mar 2014 00:50:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Sat, 8 Mar 2014 00:50:08 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Mar 2014 00:50:08 -0800 X-Google-Sender-Auth: EDa4worudEVvE8ApxTMTeyJEZH4 Message-ID: Subject: Re: building ICU port on arm From: Adrian Chadd To: Stephen Woolerton Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 08:50:09 -0000 On 8 March 2014 00:48, Stephen Woolerton wrote: > Hi everyone, > > Just wondering if anyone has successfully built the ICU port or an ICU package, on an arm device on FreeBSD 10. (Problem report 186823) > > The reason is I need to run some code which requires GNUstep-base, for which ICU is a dependency. (I'm hoping to do this project on FreeBSD rather than Linux.) What happens when you try? -a From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 09:02:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 703A43E6; Sat, 8 Mar 2014 09:02:24 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3C01CC5D; Sat, 8 Mar 2014 09:02:24 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id x10so5039102pdj.37 for ; Sat, 08 Mar 2014 01:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=D0j7oIekKwIuI1jq7N9jGAe7XQAuX3YMikz1MZsIxOE=; b=CRHW/tvwQ49L5A1u9Q+HMd2Pmr1EzfEurXn9RsntsL+/RpJ7RKR7qRoL8r/Vmp0kVZ FAgd9CryqaIJqw0WIs/RM3kkY2O6afSRllF6eyUvceJt6fO+ngyjucQ0M4piPZGplKKE TE1BQjl7QOpOH9wbFPEdH59nwZwP/E15McpnrDON64UULavRIkQ0wnnvDmz2FBoV5/n7 dZBb14qfGOMhLEuBTT9o7/CB+Fy3irsbDlfGU1H6LMfkvRUXjoOfj1FCL4fqEajER/RB fc2ecjm1YAqy9h4wn/axq0qE4I24b4RMybq2IiLImRqyfqI7biMwLEv4j+9IdxX5kFXy 0FMw== X-Received: by 10.68.105.36 with SMTP id gj4mr27710716pbb.64.1394269343774; Sat, 08 Mar 2014 01:02:23 -0800 (PST) Received: from [172.16.1.21] ([202.89.38.236]) by mx.google.com with ESMTPSA id sy2sm45094965pbc.28.2014.03.08.01.02.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Mar 2014 01:02:22 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: building ICU port on arm From: Stephen Woolerton In-Reply-To: Date: Sat, 8 Mar 2014 22:02:20 +1300 Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 09:02:24 -0000 At some point in the port compile, it crashes with a core dump... .... compiling the ICU port on a Raspberry Pi Model B... ... pkgdata: cd ../lib/ && rm -f libicudata.so.52 && ln -s = libicudata.so.52.1 libicudata.so.52 pkgdata: cd ../lib/ && rm -f libicudata.so && ln -s libicudata.so.52.1 = libicudata.so gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source/data' gmake[2]: Making `all' in `extra' gmake[3]: Entering directory = `/usr/ports/devel/icu/work/icu/source/extra' gmake[3]: Making `all' in `uconv' gmake[4]: Entering directory = `/usr/ports/devel/icu/work/icu/source/extra/uconv' mkdir uconvmsg c++ -D_REENTRANT -DU_HAVE_ELF_H=3D1 -DU_HAVE_ATOMIC=3D1 = -DU_HAVE_TIMEZONE=3D0 -I../../common -I../../i18n -I./../toolutil = -DU_ATTRIBUTE_DEPRECATED=3D -DUCONVMSG_LINK=3Duconvmsg -O -pipe -W -Wall = -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long --std=3Dc++0x = -c -o uconv.o uconv.cpp cc -D_REENTRANT -DU_HAVE_ELF_H=3D1 -DU_HAVE_ATOMIC=3D1 = -DU_HAVE_TIMEZONE=3D0 -I../../common -I../../i18n -I./../toolutil = -DU_ATTRIBUTE_DEPRECATED=3D -DUCONVMSG_LINK=3Duconvmsg -O -pipe -std=3Dc99= -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes = -Wwrite-strings -c -o uwmsg.o uwmsg.c = LD_LIBRARY_PATH=3D../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY= _PATH ../../bin/genrb -e UTF-8 -s resources -d uconvmsg root.txt = LD_LIBRARY_PATH=3D../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY= _PATH ../../bin/genrb -e UTF-8 -s resources -d uconvmsg fr.txt gmake -f pkgdataMakefile gmake[5]: Entering directory = `/usr/ports/devel/icu/work/icu/source/extra/uconv' rm -rf pkgdata.inc gmake[5]: Leaving directory = `/usr/ports/devel/icu/work/icu/source/extra/uconv' = LD_LIBRARY_PATH=3D../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY= _PATH ../../bin/pkgdata -p uconvmsg -O pkgdata.inc -m static -s uconvmsg = -d uconvmsg -T uconvmsg uconvmsg/uconvmsg.lst pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=3D1 -DU_HAVE_ATOMIC=3D1 = -DU_HAVE_TIMEZONE=3D0 -DU_ATTRIBUTE_DEPRECATED=3D -O -pipe -std=3Dc99 = -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes = -Wwrite-strings -c -I../../common -I../../common -DPIC -fPIC -o = uconvmsg/uconvmsg_dat.o uconvmsg/uconvmsg_dat.c pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=3D1 -DU_HAVE_ATOMIC=3D1 = -DU_HAVE_TIMEZONE=3D0 -DU_ATTRIBUTE_DEPRECATED=3D -O -pipe -std=3Dc99 = -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes = -Wwrite-strings -c -I../../common -I../../common -DPIC -fPIC -o = uconvmsg/root_res.o uconvmsg/root_res.c pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=3D1 -DU_HAVE_ATOMIC=3D1 = -DU_HAVE_TIMEZONE=3D0 -DU_ATTRIBUTE_DEPRECATED=3D -O -pipe -std=3Dc99 = -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes = -Wwrite-strings -c -I../../common -I../../common -DPIC -fPIC -o = uconvmsg/fr_res.o uconvmsg/fr_res.c pkgdata: ar r uconvmsg/libuconvmsg.a uconvmsg/uconvmsg_dat.o = uconvmsg/root_res.o uconvmsg/fr_res.o ar: warning: creating uconvmsg/libuconvmsg.a pkgdata: ranlib uconvmsg/libuconvmsg.a c++ -O -pipe -W -Wall -pedantic -Wpointer-arith -Wwrite-strings = -Wno-long-long --std=3Dc++0x -o ../../bin/uconv uconv.o uwmsg.o = -L../../lib -licui18n -L../../lib -licuuc -L../../stubdata -licudata -lm = uconvmsg/libuconvmsg.a cd ../.. \ && CONFIG_FILES=3Dextra/uconv/uconv.1 CONFIG_HEADERS=3D /bin/sh = ./config.status config.status: creating extra/uconv/uconv.1 gmake[4]: Leaving directory = `/usr/ports/devel/icu/work/icu/source/extra/uconv' gmake[4]: Entering directory = `/usr/ports/devel/icu/work/icu/source/extra' gmake[4]: Nothing to be done for `all-local'. gmake[4]: Leaving directory `/usr/ports/devel/icu/work/icu/source/extra' gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source/extra' gmake[2]: Making `all' in `test' gmake[3]: Entering directory `/usr/ports/devel/icu/work/icu/source/test' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source/test' gmake[3]: Entering directory `/usr/ports/devel/icu/work/icu/source' Note: rebuild with "gmake VERBOSE=3D1 all-local" to show all compiler = parameters. gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source' gmake[2]: Leaving directory `/usr/ports/devel/icu/work/icu/source' Segmentation fault (core dumped) =3D=3D=3D>>> make failed for devel/icu =3D=3D=3D>>> Aborting update =3D=3D=3D>>> Update for devel/icu failed =3D=3D=3D>>> Aborting update =3D=3D=3D>>> Killing background jobs Terminated ---- Problem report is here... http://www.freebsd.org/cgi/query-pr.cgi?pr=3D186823&cat=3D Thanks for asking Stephen On 8/03/2014, at 9:50 pm, Adrian Chadd wrote: > On 8 March 2014 00:48, Stephen Woolerton wrote: >> Hi everyone, >>=20 >> Just wondering if anyone has successfully built the ICU port or an = ICU package, on an arm device on FreeBSD 10. (Problem report 186823) >>=20 >> The reason is I need to run some code which requires GNUstep-base, = for which ICU is a dependency. (I'm hoping to do this project on FreeBSD = rather than Linux.) >=20 > What happens when you try? >=20 >=20 > -a From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 15:41:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FA2FCDD for ; Sat, 8 Mar 2014 15:41:46 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF09DD0C for ; Sat, 8 Mar 2014 15:41:45 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id w7so5966969qcr.22 for ; Sat, 08 Mar 2014 07:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Dp6yb3ZI98Zh2IynNbsjjuVMXSO4/O1wzmmvw56KjVY=; b=UbRj8ms5B4/jIoUcj76mwjbzHLDpfaHXAb2r7OKWAbvK/aZhZAvOjNEkOH5Ia6c+cc EcfDxsqGGM8x7enJGNQbjn1z8caoV3FWgbj02zXVFoRkLG8TI4b8/a7KYaSGPKlxv4YY InkR/k8RIpI/TSK6hQpLRHprqRpjx0Patgoe4KKCWDIcHRoj9toxpNmbYDsrAmhDzwEQ PxFjF1H15sXCWO7fbjcDWNuW15Ehsk7vsVnJEyWaNqutXzckE8q+o5sjswZYTyGP3BgW SV8RZVeu2bBl8cx2bN6Q3TOP/H3RwSYoJHnmoruaDryX42P2L4+D+jgZGlkkmCzB+6Fe EWSw== MIME-Version: 1.0 X-Received: by 10.224.13.142 with SMTP id c14mr12029280qaa.76.1394293304999; Sat, 08 Mar 2014 07:41:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Sat, 8 Mar 2014 07:41:44 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Mar 2014 07:41:44 -0800 X-Google-Sender-Auth: 3XcdcDJI5EEFxdUvlcDz_Kb9Dv8 Message-ID: Subject: Re: building ICU port on arm From: Adrian Chadd To: Stephen Woolerton Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 15:41:46 -0000 What process is segfaulting? What's in the coredump? -a On 8 March 2014 01:02, Stephen Woolerton wrote: > At some point in the port compile, it crashes with a core dump... > > .... compiling the ICU port on a Raspberry Pi Model B... > ... > pkgdata: cd ../lib/ && rm -f libicudata.so.52 && ln -s libicudata.so.52.1 > libicudata.so.52 > pkgdata: cd ../lib/ && rm -f libicudata.so && ln -s libicudata.so.52.1 > libicudata.so > gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source/data' > gmake[2]: Making `all' in `extra' > gmake[3]: Entering directory `/usr/ports/devel/icu/work/icu/source/extra' > gmake[3]: Making `all' in `uconv' > gmake[4]: Entering directory > `/usr/ports/devel/icu/work/icu/source/extra/uconv' > mkdir uconvmsg > c++ -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -DU_HAVE_TIMEZONE=0 > -I../../common -I../../i18n -I./../toolutil -DU_ATTRIBUTE_DEPRECATED= > -DUCONVMSG_LINK=uconvmsg -O -pipe -W -Wall -pedantic -Wpointer-arith > -Wwrite-strings -Wno-long-long --std=c++0x -c -o uconv.o uconv.cpp > cc -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -DU_HAVE_TIMEZONE=0 > -I../../common -I../../i18n -I./../toolutil -DU_ATTRIBUTE_DEPRECATED= > -DUCONVMSG_LINK=uconvmsg -O -pipe -std=c99 -Wall -pedantic -Wshadow > -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -c -o uwmsg.o uwmsg.c > LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH > ../../bin/genrb -e UTF-8 -s resources -d uconvmsg root.txt > LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH > ../../bin/genrb -e UTF-8 -s resources -d uconvmsg fr.txt > gmake -f pkgdataMakefile > gmake[5]: Entering directory > `/usr/ports/devel/icu/work/icu/source/extra/uconv' > rm -rf pkgdata.inc > gmake[5]: Leaving directory > `/usr/ports/devel/icu/work/icu/source/extra/uconv' > LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH > ../../bin/pkgdata -p uconvmsg -O pkgdata.inc -m static -s uconvmsg -d > uconvmsg -T uconvmsg uconvmsg/uconvmsg.lst > pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 > -DU_HAVE_TIMEZONE=0 -DU_ATTRIBUTE_DEPRECATED= -O -pipe -std=c99 -Wall > -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -c > -I../../common -I../../common -DPIC -fPIC -o uconvmsg/uconvmsg_dat.o > uconvmsg/uconvmsg_dat.c > pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 > -DU_HAVE_TIMEZONE=0 -DU_ATTRIBUTE_DEPRECATED= -O -pipe -std=c99 -Wall > -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -c > -I../../common -I../../common -DPIC -fPIC -o uconvmsg/root_res.o > uconvmsg/root_res.c > pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 > -DU_HAVE_TIMEZONE=0 -DU_ATTRIBUTE_DEPRECATED= -O -pipe -std=c99 -Wall > -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -c > -I../../common -I../../common -DPIC -fPIC -o uconvmsg/fr_res.o > uconvmsg/fr_res.c > pkgdata: ar r uconvmsg/libuconvmsg.a uconvmsg/uconvmsg_dat.o > uconvmsg/root_res.o uconvmsg/fr_res.o > ar: warning: creating uconvmsg/libuconvmsg.a > pkgdata: ranlib uconvmsg/libuconvmsg.a > c++ -O -pipe -W -Wall -pedantic -Wpointer-arith -Wwrite-strings > -Wno-long-long --std=c++0x -o ../../bin/uconv uconv.o uwmsg.o -L../../lib > -licui18n -L../../lib -licuuc -L../../stubdata -licudata -lm > uconvmsg/libuconvmsg.a > cd ../.. \ > && CONFIG_FILES=extra/uconv/uconv.1 CONFIG_HEADERS= /bin/sh ./config.status > config.status: creating extra/uconv/uconv.1 > gmake[4]: Leaving directory > `/usr/ports/devel/icu/work/icu/source/extra/uconv' > gmake[4]: Entering directory `/usr/ports/devel/icu/work/icu/source/extra' > gmake[4]: Nothing to be done for `all-local'. > gmake[4]: Leaving directory `/usr/ports/devel/icu/work/icu/source/extra' > gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source/extra' > gmake[2]: Making `all' in `test' > gmake[3]: Entering directory `/usr/ports/devel/icu/work/icu/source/test' > gmake[3]: Nothing to be done for `all'. > gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source/test' > gmake[3]: Entering directory `/usr/ports/devel/icu/work/icu/source' > Note: rebuild with "gmake VERBOSE=1 all-local" to show all compiler > parameters. > gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source' > gmake[2]: Leaving directory `/usr/ports/devel/icu/work/icu/source' > Segmentation fault (core dumped) > > ===>>> make failed for devel/icu > ===>>> Aborting update > > ===>>> Update for devel/icu failed > ===>>> Aborting update > > ===>>> Killing background jobs > Terminated > > ---- Problem report is here... > > http://www.freebsd.org/cgi/query-pr.cgi?pr=186823&cat= > > > Thanks for asking > > Stephen > > On 8/03/2014, at 9:50 pm, Adrian Chadd wrote: > > On 8 March 2014 00:48, Stephen Woolerton wrote: > > Hi everyone, > > Just wondering if anyone has successfully built the ICU port or an ICU > package, on an arm device on FreeBSD 10. (Problem report 186823) > > The reason is I need to run some code which requires GNUstep-base, for which > ICU is a dependency. (I'm hoping to do this project on FreeBSD rather than > Linux.) > > > What happens when you try? > > > -a > > From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 16:57:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29CF0266; Sat, 8 Mar 2014 16:57:44 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB3C735F; Sat, 8 Mar 2014 16:57:43 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id r10so5325532pdi.30 for ; Sat, 08 Mar 2014 08:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p2SjIqmskGKRMEkq/yu9BaS/6qdt09ijcb/EGCgb2Xc=; b=pal7aqpFjb+UGZc1tPJWXEnnKgOMIlGd/xQD+Baghp1sEx48ZMrChP01AvnPYT6C3d zEVKlFVOGauQnw1u1NOhMYoWcYXLOCY/YELt37Q54rLWDkIjdVvZRaNCVhd8dsAqcciB zQr1A7YWNdnYAGUH/xOhrjJztSr4CbMfmyUG1Bh/vsdrfX8odNzP+MviTAMYES4QFwxf ifyOM5RZpFhWFKjiJBeanCD0vq/kWUpEGHW4icKpyzm0KI8u0L45ZHNFw0yOrZV8aaVB Wo2M8FOKx68A7IZAoF5WwBQyCsTakN+rHJ6JDH1WTl4Ao0mJcV7Blo8jMYOJby8zvExG TTmA== X-Received: by 10.66.66.135 with SMTP id f7mr29686523pat.22.1394297863494; Sat, 08 Mar 2014 08:57:43 -0800 (PST) Received: from [172.16.1.21] ([202.89.38.236]) by mx.google.com with ESMTPSA id ac5sm49044488pbc.37.2014.03.08.08.57.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Mar 2014 08:57:42 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: building ICU port on arm From: Stephen Woolerton In-Reply-To: Date: Sun, 9 Mar 2014 05:57:36 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <8F7E10D7-94C0-4822-998F-B1283505E1DA@gmail.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 16:57:44 -0000 I started the icu compile again and it completed successfully this time. = I can only assume a recent update in ports has occurred. Thanks Adrian. I'll close the problem report. Regards Stephen On 9/03/2014, at 4:41 am, Adrian Chadd wrote: > What process is segfaulting? What's in the coredump? >=20 >=20 > -a >=20 >=20 > On 8 March 2014 01:02, Stephen Woolerton wrote: >> At some point in the port compile, it crashes with a core dump... >>=20 >> .... compiling the ICU port on a Raspberry Pi Model B... >> ... >> pkgdata: cd ../lib/ && rm -f libicudata.so.52 && ln -s = libicudata.so.52.1 >> libicudata.so.52 >> pkgdata: cd ../lib/ && rm -f libicudata.so && ln -s = libicudata.so.52.1 >> libicudata.so >> gmake[3]: Leaving directory = `/usr/ports/devel/icu/work/icu/source/data' >> gmake[2]: Making `all' in `extra' >> gmake[3]: Entering directory = `/usr/ports/devel/icu/work/icu/source/extra' >> gmake[3]: Making `all' in `uconv' >> gmake[4]: Entering directory >> `/usr/ports/devel/icu/work/icu/source/extra/uconv' >> mkdir uconvmsg >> c++ -D_REENTRANT -DU_HAVE_ELF_H=3D1 -DU_HAVE_ATOMIC=3D1 = -DU_HAVE_TIMEZONE=3D0 >> -I../../common -I../../i18n -I./../toolutil -DU_ATTRIBUTE_DEPRECATED=3D= >> -DUCONVMSG_LINK=3Duconvmsg -O -pipe -W -Wall -pedantic = -Wpointer-arith >> -Wwrite-strings -Wno-long-long --std=3Dc++0x -c -o uconv.o uconv.cpp >> cc -D_REENTRANT -DU_HAVE_ELF_H=3D1 -DU_HAVE_ATOMIC=3D1 = -DU_HAVE_TIMEZONE=3D0 >> -I../../common -I../../i18n -I./../toolutil -DU_ATTRIBUTE_DEPRECATED=3D= >> -DUCONVMSG_LINK=3Duconvmsg -O -pipe -std=3Dc99 -Wall -pedantic = -Wshadow >> -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -c -o uwmsg.o = uwmsg.c >> = LD_LIBRARY_PATH=3D../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY= _PATH >> ../../bin/genrb -e UTF-8 -s resources -d uconvmsg root.txt >> = LD_LIBRARY_PATH=3D../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY= _PATH >> ../../bin/genrb -e UTF-8 -s resources -d uconvmsg fr.txt >> gmake -f pkgdataMakefile >> gmake[5]: Entering directory >> `/usr/ports/devel/icu/work/icu/source/extra/uconv' >> rm -rf pkgdata.inc >> gmake[5]: Leaving directory >> `/usr/ports/devel/icu/work/icu/source/extra/uconv' >> = LD_LIBRARY_PATH=3D../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY= _PATH >> ../../bin/pkgdata -p uconvmsg -O pkgdata.inc -m static -s uconvmsg -d >> uconvmsg -T uconvmsg uconvmsg/uconvmsg.lst >> pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=3D1 -DU_HAVE_ATOMIC=3D1 >> -DU_HAVE_TIMEZONE=3D0 -DU_ATTRIBUTE_DEPRECATED=3D -O -pipe -std=3Dc99 = -Wall >> -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes = -Wwrite-strings -c >> -I../../common -I../../common -DPIC -fPIC -o uconvmsg/uconvmsg_dat.o >> uconvmsg/uconvmsg_dat.c >> pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=3D1 -DU_HAVE_ATOMIC=3D1 >> -DU_HAVE_TIMEZONE=3D0 -DU_ATTRIBUTE_DEPRECATED=3D -O -pipe -std=3Dc99 = -Wall >> -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes = -Wwrite-strings -c >> -I../../common -I../../common -DPIC -fPIC -o uconvmsg/root_res.o >> uconvmsg/root_res.c >> pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=3D1 -DU_HAVE_ATOMIC=3D1 >> -DU_HAVE_TIMEZONE=3D0 -DU_ATTRIBUTE_DEPRECATED=3D -O -pipe -std=3Dc99 = -Wall >> -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes = -Wwrite-strings -c >> -I../../common -I../../common -DPIC -fPIC -o uconvmsg/fr_res.o >> uconvmsg/fr_res.c >> pkgdata: ar r uconvmsg/libuconvmsg.a uconvmsg/uconvmsg_dat.o >> uconvmsg/root_res.o uconvmsg/fr_res.o >> ar: warning: creating uconvmsg/libuconvmsg.a >> pkgdata: ranlib uconvmsg/libuconvmsg.a >> c++ -O -pipe -W -Wall -pedantic -Wpointer-arith -Wwrite-strings >> -Wno-long-long --std=3Dc++0x -o ../../bin/uconv uconv.o uwmsg.o = -L../../lib >> -licui18n -L../../lib -licuuc -L../../stubdata -licudata -lm >> uconvmsg/libuconvmsg.a >> cd ../.. \ >> && CONFIG_FILES=3Dextra/uconv/uconv.1 CONFIG_HEADERS=3D /bin/sh = ./config.status >> config.status: creating extra/uconv/uconv.1 >> gmake[4]: Leaving directory >> `/usr/ports/devel/icu/work/icu/source/extra/uconv' >> gmake[4]: Entering directory = `/usr/ports/devel/icu/work/icu/source/extra' >> gmake[4]: Nothing to be done for `all-local'. >> gmake[4]: Leaving directory = `/usr/ports/devel/icu/work/icu/source/extra' >> gmake[3]: Leaving directory = `/usr/ports/devel/icu/work/icu/source/extra' >> gmake[2]: Making `all' in `test' >> gmake[3]: Entering directory = `/usr/ports/devel/icu/work/icu/source/test' >> gmake[3]: Nothing to be done for `all'. >> gmake[3]: Leaving directory = `/usr/ports/devel/icu/work/icu/source/test' >> gmake[3]: Entering directory `/usr/ports/devel/icu/work/icu/source' >> Note: rebuild with "gmake VERBOSE=3D1 all-local" to show all compiler >> parameters. >> gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source' >> gmake[2]: Leaving directory `/usr/ports/devel/icu/work/icu/source' >> Segmentation fault (core dumped) >>=20 >> =3D=3D=3D>>> make failed for devel/icu >> =3D=3D=3D>>> Aborting update >>=20 >> =3D=3D=3D>>> Update for devel/icu failed >> =3D=3D=3D>>> Aborting update >>=20 >> =3D=3D=3D>>> Killing background jobs >> Terminated >>=20 >> ---- Problem report is here... >>=20 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D186823&cat=3D >>=20 >>=20 >> Thanks for asking >>=20 >> Stephen >>=20 >> On 8/03/2014, at 9:50 pm, Adrian Chadd wrote: >>=20 >> On 8 March 2014 00:48, Stephen Woolerton wrote: >>=20 >> Hi everyone, >>=20 >> Just wondering if anyone has successfully built the ICU port or an = ICU >> package, on an arm device on FreeBSD 10. (Problem report 186823) >>=20 >> The reason is I need to run some code which requires GNUstep-base, = for which >> ICU is a dependency. (I'm hoping to do this project on FreeBSD rather = than >> Linux.) >>=20 >>=20 >> What happens when you try? >>=20 >>=20 >> -a >>=20 >>=20 From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 18:23:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC69C5AA; Sat, 8 Mar 2014 18:23:00 +0000 (UTC) Received: from mailgate-01.zdv.uni-mainz.de (mailgate-01.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f1]) by mx1.freebsd.org (Postfix) with ESMTP id D655EC49; Sat, 8 Mar 2014 18:22:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1394302979; x=1425838979; h=from:to:cc:subject:date:message-id:mime-version; bh=BynOBDH4znqTAXQbXltv+MOYlCU8mHu+2UmQddFOKqs=; b=E+OpvNsl5O/FRpQKkFC3rx60umnidVLRNFmOkYVwazSmXWe2Wh7vJHCe ++dbY+fvjEXO+z8ue8f1lz6VQ+WtjCPfnlEZbvv0GN+tImtOxTM4upgew SSNU62DI9iBhPJAgG4SLhB79o4Yh1oE9wnxAhWL7DghLEC+XL2Et0DtwF 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEACJfG1MKXgZQ/2dsb2JhbABagmWBM8EygSF0gix5EgFQMCYBBA4NBg2HXgHPdheOW4Q/BIkZhzeBNI0Ii2aDLYIr X-IPAS-Result: AqAEACJfG1MKXgZQ/2dsb2JhbABagmWBM8EygSF0gix5EgFQMCYBBA4NBg2HXgHPdheOW4Q/BIkZhzeBNI0Ii2aDLYIr Received: from e14hub-01.zdv.uni-mainz.de ([10.94.6.80]) by mailgate-01.zdv.uni-mainz.de with ESMTP; 08 Mar 2014 19:22:55 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9239) by E14HUB-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c5f) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 8 Mar 2014 19:21:46 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9239) with Microsoft SMTP Server (TLS) id 15.0.847.32; Sat, 8 Mar 2014 19:22:55 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090]) by e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090%15]) with mapi id 15.00.0847.030; Sat, 8 Mar 2014 19:21:46 +0100 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'freebsd-arm' Subject: Crashes on arm caused by stack corruption Thread-Topic: Crashes on arm caused by stack corruption Thread-Index: Ac86Vip8+Gk0bpQGQU2Uug03niWG0Q== Date: Sat, 8 Mar 2014 18:21:46 +0000 Message-ID: <1caa439fc6a34c06b1667708306fd558@e15be-01.zdv.Uni-Mainz.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: multipart/mixed; boundary="_002_1caa439fc6a34c06b1667708306fd558e15be01zdvUniMainzDE_" MIME-Version: 1.0 Cc: "'Ian Lepore \(ian@FreeBSD.org\)'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 18:23:00 -0000 --_002_1caa439fc6a34c06b1667708306fd558e15be01zdvUniMainzDE_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For quite a while I observe random or not so random crashes on i.mx6.=20 The svc stack grows into the undefined instruction exception stack, as can be seen here. And there is corruption around the address in the und_sp register. db> show reg spsr 0x600001d3 r0 0 r1 0xc246f3c0 __pcpu r2 0xc2438100 pcpup r3 0xc2379039 r4 0xc6460000 r5 0xc23789e2 r6 0xc23733b4 r7 0xc6460000 r8 0 r9 0x1 r10 0 r11 0xbfffe388 r12 0 usr_sp 0xbfffdf68 usr_lr 0x21e04 svc_sp 0xf183afe8 svc_lr 0xc216add8 mi_switch+0x2b8 pc 0x4278f500 und_sp 0xf183aff0 abt_sp 0xc2565000 irq_sp 0xc2561000 The strange thing is, that there is an undefined instruction exception stack undstack allocated for each core in initarm and assigned to und_sp.=20 But later on in cpu_switch, und_sp is loaded=20 ldr sp, [r9, #(PCB_UND_SP)] from un_32.pcb32_und_sp. Which is intialized to=20 #define USPACE_UNDEF_STACK_TOP (USPACE_SVC_STACK_BOTTOM - 0x10) which comes from #define USPACE_SVC_STACK_BOTTOM (USPACE_SVC_STACK_TOP - 0x1000) and effectively halves the svc stack. The undefined instruction exception stack is almost not used, besides a few words right at the beginning of the exception handling. The exception frame is actually build on the svc stack.=20 Now undefined instruction exceptions should only happen in user mode (VFP). Then the used part of svc stack should be small enough, so that no harm should result. But in cpu_throw the code for manipulating the und_sp is actually missing. So sometimes undefined instruction=20 exceptions write on the kernel stack of the wrong process/thread. So seem to be two solutions. If I do not miss anything, I would suggest to just drop the code, which switches the undefined=20 instruction exception stack. The other is to add the missing part to cpu_throw. See attached patch for both possibilities. With any of both solutions the crashes on my system are gone.=20 I think this problem affects all arm systems. There is another problem with the handling of undefined instructions. The first few instructions of the undefined instruction exception handler use static variables and are definitively not SMP save. I wonder why the code is not similar to the prefetch abort handler or the data abort handler. Regards Juergen --_002_1caa439fc6a34c06b1667708306fd558e15be01zdvUniMainzDE_ Content-Type: application/octet-stream; name="und_stack.diff" Content-Description: und_stack.diff Content-Disposition: attachment; filename="und_stack.diff"; size=1652; creation-date="Sat, 08 Mar 2014 18:01:16 GMT"; modification-date="Sat, 08 Mar 2014 17:53:05 GMT" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL3N3dGNoLlMgYi9zeXMvYXJtL2FybS9zd3RjaC5TCmlu ZGV4IDEzM2IwZDkuLmQ5ZDYwOTcgMTAwNjQ0Ci0tLSBhL3N5cy9hcm0vYXJtL3N3dGNoLlMKKysr IGIvc3lzL2FybS9hcm0vc3d0Y2guUwpAQCAtMTg0LDYgKzE4NCwyMCBAQCBFTlRSWShjcHVfdGhy b3cpCiAJbW92CWxyLCBwYwogCWxkcglwYywgW3I5LCAjQ0ZfQ09OVEVYVF9TV0lUQ0hdCiAKKyNp ZmRlZglVTkRfU1RBQ0tfSU5fS1NUQUNLCisgICAgICAgIG1ycwlyMywgY3BzcgorCS8qCisJICog V2UgY2FuIGRvIHRoYXQsIHNpbmNlCisJICogUFNSX1NWQzMyX01PREV8UFNSX1VORDMyX01PREUg PT0gTVNSX1VORDMyX01PREUKKwkgKi8KKwlvcnIJcjIsIHIzLCAjKFBTUl9VTkQzMl9NT0RFKQor CW1zcgljcHNyX2MsIHIyCisKKwlsZHIJc3AsIFtyNywgIyhQQ0JfVU5EX1NQKV0KKworICAgICAg ICBtc3IJY3Bzcl9jLCByMwkJLyogUmVzdG9yZSB0aGUgb2xkIG1vZGUgKi8KKyNlbmRpZgorCiAJ LyogUmVzdG9yZSBhbGwgdGhlIHNhdmUgcmVnaXN0ZXJzICovCiAjaWZuZGVmIF9BUk1fQVJDSF81 RQogCWFkZAlyMSwgcjcsICNQQ0JfUjgKQEAgLTMwMyw2ICszMTcsNyBAQCBFTlRSWShjcHVfc3dp dGNoKQogCS8qIEdldCB0aGUgdXNlciBzdHJ1Y3R1cmUgZm9yIHRoZSBuZXcgcHJvY2VzcyBpbiBy OSAqLwogCWxkcglyOSwgW3IxLCAjKFREX1BDQildCiAKKyNpZmRlZglVTkRfU1RBQ0tfSU5fS1NU QUNLCiAgICAgICAgIG1ycwlyMywgY3BzcgogCS8qCiAJICogV2UgY2FuIGRvIHRoYXQsIHNpbmNl CkBAIC0zMTQsNiArMzI5LDggQEAgRU5UUlkoY3B1X3N3aXRjaCkKIAlzdHIJc3AsIFtyMiwgIyhQ Q0JfVU5EX1NQKV0KIAogICAgICAgICBtc3IJY3Bzcl9jLCByMwkJLyogUmVzdG9yZSB0aGUgb2xk IG1vZGUgKi8KKyNlbmRpZgorCiAJLyogcmVtOiByMiA9IG9sZCBQQ0IgKi8KIAkvKiByZW06IHI5 ID0gbmV3IFBDQiAqLwogCS8qIHJlbTogaW50ZXJydXB0cyBhcmUgZW5hYmxlZCAqLwpAQCAtNDM4 LDEwICs0NTUsNiBAQCBFTlRSWShjcHVfc3dpdGNoKQogCW1vdm5lCXIwLCAjMAkJCS8qIFdlICpr bm93KiB2ZWN0b3JfcGFnZSdzIFZBIGlzIDB4MCAqLwogCW1vdm5lCWxyLCBwYwogCWxkcm5lCXBj LCBbcjEwLCAjQ0ZfVExCX0ZMVVNISURfU0VdCi0JLyoKLQkgKiBXZSBjYW4gZG8gdGhhdCwgc2lu Y2UKLQkgKiBQU1JfU1ZDMzJfTU9ERXxQU1JfVU5EMzJfTU9ERSA9PSBNU1JfVU5EMzJfTU9ERQot CSAqLwogCiAuTGNzX2NvbnRleHRfc3dpdGNoZWQ6CiAKQEAgLTQ2MCw2ICs0NzMsNyBAQCBFTlRS WShjcHVfc3dpdGNoKQogCiAJLyogcmVtOiByOSA9IG5ldyBQQ0IgKi8KIAorI2lmZGVmCVVORF9T VEFDS19JTl9LU1RBQ0sKICAgICAgICAgbXJzCXIzLCBjcHNyCiAJLyoKIAkgKiBXZSBjYW4gZG8g dGhhdCwgc2luY2UKQEAgLTQ3MSw2ICs0ODUsOCBAQCBFTlRSWShjcHVfc3dpdGNoKQogCWxkcglz cCwgW3I5LCAjKFBDQl9VTkRfU1ApXQogCiAgICAgICAgIG1zcgljcHNyX2MsIHIzCQkvKiBSZXN0 b3JlIHRoZSBvbGQgbW9kZSAqLworI2VuZGlmCisKIAkvKiBSZXN0b3JlIGFsbCB0aGUgc2F2ZSBy ZWdpc3RlcnMgKi8KICNpZm5kZWYgX0FSTV9BUkNIXzVFCiAJYWRkCXI3LCByOSwgI1BDQl9SOAo= --_002_1caa439fc6a34c06b1667708306fd558e15be01zdvUniMainzDE_-- From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 19:29:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A778DC0 for ; Sat, 8 Mar 2014 19:29:29 +0000 (UTC) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 632DAC9 for ; Sat, 8 Mar 2014 19:29:28 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id m1so5548566oag.21 for ; Sat, 08 Mar 2014 11:29:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=styr00g1IbSsG9gjWv/MfyFjHo3NEEbNW1lBMxekIhk=; b=TEeDu20mp2xbv3N0iVWw2JyRrZlJfh4RdqXZPw1mAFTLTrZaqR0q2XWbX36lcvr9IY H3aPWo3IAK0hyuZhnSdw2KMDHBZ6Q5rY7yC2/dbb+5SL8vVKew6zZaid4VQKaKgugpE6 eNy0u9WbdAphC9RGVmhBzawkQVOBBReVIo/yWvwx0OmDC/zJ1EYIAF0/Kcz7eh4idapD 3rdynqhl5IjS8u8hQt9ZMsVc/JL3SfvE+ZQvIumF9yZ/sSU87YWlb1jkkOwFNRRRXqmJ 7LH84DsdOXQct2TcDUwH6aYOSViEJ0MulFV2/ipf3hsdt2hDPQ5yP+pzSwM0568XX5jx pl8A== X-Gm-Message-State: ALoCoQkB9buB+/D0Izg+76igwT/FgnkmUc4+qLNGc/9OmSVTqhj/lrnO3MjyELbjaBSzFKZVczfx MIME-Version: 1.0 X-Received: by 10.60.132.12 with SMTP id oq12mr17142193oeb.42.1394306962717; Sat, 08 Mar 2014 11:29:22 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sat, 8 Mar 2014 11:29:22 -0800 (PST) Date: Sat, 8 Mar 2014 12:29:22 -0700 Message-ID: Subject: crash starting wandboard-quad with latest code From: Tom Everett To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:29:29 -0000 I've done a build of the wandboard-quad with svn version r262929 Strangely, it now just stops, with no serial console output during the boot. The complete boot log is below. My previous build with source revision r262820 worked perfectly. Any suggestions about what might be happening? .. U-Boot 2013.10 (Mar 08 2014 - 11:53:29) CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: POR Board: Wandboard DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 5 ... 4 ... 3 ... 2 ... 1 ... 0 mmc0 is current device reading boot.scr 157 bytes read in 10 ms (14.6 KiB/s) Running bootscript from mmc ... ## Executing script at 12000000 reading ubldr 253278 bytes read in 28 ms (8.6 MiB/s) ## Starting application at 0x88000054 ... Consoles: U-Boot console Compatible API signature found @8f5756f8 MMC: no card present MMC Device 2 not found MMC Device 3 not found Number of U-Boot devices: 2 FreeBSD/armv6 U-Boot loader, Revision 1.2 (tom@bernice, Sat Mar 8 11:53:22 MST 2014) DRAM: 2048MB Probing for bootable devices... Bootable device: disk Bootable device: net Current device: disk |./.-.\.|./.-.\.|./.-.\.|./.-. \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-./boot/kernel/kernel data=3D0x4dc0c8+0x2ff38 \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|= ./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.= -.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\= .|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|.= /.-.\.|./.-.\.syms=3D[0x4+0x7e6e0|./.-.\.|./.-.\.|./.-.\.|./.-.\.+0x4+0x4e0= a1|./.-.\.|./.-.\.|.] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Booting [/boot/kernel/kernel] in 8 seconds... Booting [/boot/kernel/kernel] in 7 seconds... Booting [/boot/kernel/kernel] in 6 seconds... Booting [/boot/kernel/kernel] in 5 seconds... Booting [/boot/kernel/kernel] in 4 seconds... Booting [/boot/kernel/kernel] in 3 seconds... Booting [/boot/kernel/kernel] in 2 seconds... Booting [/boot/kernel/kernel] in 1 second... Booting [/boot/kernel/kernel]... /.-.\.|./.-.\.|./.-.\.|./.-.\.|./.Loaded DTB from file 'wandboard-quad.dtb'= . -.\.|./.-.\.|.Kernel entry at 0x12000100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #0 r262929: Sat Mar 8 11:47:07 MST 2014 tom@bernice:/storage/home/tom/crochet/crochet-freebsd/work/obj/arm.armv= 6/storage/home/tom/crochet/src/FreeBSDHead/head/sys/IMX6 arm FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 CPU: Cortex A9-r2 rev 10 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:1 LoUIS:2 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Alloc real memory =3D 2147483648 (2048 MB) avail memory =3D 2093953024 (1996 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random device not loaded; using insecure entropy random: initialized ofwbus0: simplebus0: on ofwbus0 gic0: mem 0xa01000-0xa01fff,0xa00100-0xa001ff on simplebus0 gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b sc->nirqs 160 l2cache0: mem 0xa02000-0xa02fff irq 124 on simplebus0 l2cache0: Part number: 0x3, release: 0x7 l2cache0: L2 Cache: 1024KB/32B 16 ways l2cache0: L2 Cache enabled simplebus1: mem 0x2000000-0x20fffff on simplebus0 ccm0: mem 0x20c4000-0x20c7fff irq 119,120 on simplebus1 imx6_anatop0: mem 0x20c8000-0x20c8fff irq 49 on simplebus1 imx6_anatop0: voltage set to 1225 imx6_anatop0: CPU frequency 984MHz imx_gpt0: mem 0x2098000-0x209bfff irq 87 on simplebus1 Event timer "iMXGPT" frequency 11000000 Hz quality 800 Timecounter "iMXGPT" frequency 11000000 Hz quality 1000 uart0: mem 0x2020000-0x2023fff irq 58 on simplebus1 uart0: console (0,n,8,1) usbphy0: mem 0x20c9000-0x20c9fff irq 44 on simplebus1 usbphy1: mem 0x20ca000-0x20cafff irq 45 on simplebus1 simplebus2: mem 0x2100000-0x21fffff on simplebus0 ffec0: mem 0x2188000-0x218bfff irq 150,151 on simplebus2 miibus0: on ffec0 atphy0: PHY 1 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ffec0: Ethernet address: 00:1f:7b:b4:06:7f ehci0: mem 0x2184000-0x21841ff irq 75 on simplebus2 ehci0: [GIANT-LOCKED] usbus0: EHCI version 1.0 usbus0 on ehci0 ehci1: mem 0x2184200-0x21843ff irq 72 on simplebus2 ehci1: [GIANT-LOCKED] usbus1: EHCI version 1.0 usbus1 on ehci1 sdhci_imx0: mem 0x2190000-0x2193fff irq 54 on simplebus2 mmc0: on sdhci_imx0 sdhci_imx1: mem 0x2198000-0x219bfff irq 56 on simplebus2 mmc1: on sdhci_imx1 ocotp0: mem 0x21bc000-0x21bffff on simplebus2 Timecounters tick every 4.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus= 0 ugen1.1: at usbus1 uhub1: on usbus= 1 mmc0: No compatible cards found on bus mmcsd0: 16GB at mmc1 50.0MHz/4bit/65535-block random: unblocking device. Release APs uhub0: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered Spurious interrupt detected [0x000003ff] ugen1.2: at usbus1 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... warning: no time-of-day clock registered, system time will not be set accurately --=20 A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 19:36:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6B8EF75 for ; Sat, 8 Mar 2014 19:36:51 +0000 (UTC) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A754119C for ; Sat, 8 Mar 2014 19:36:51 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id uo5so5613790pbc.10 for ; Sat, 08 Mar 2014 11:36:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=0OJAzWytBLMtmRE0+nxKc83s78i5NyRYGpMvIo0257E=; b=O7fWlnuG+2JZ79oF98uQMGq/lnNa0eV8017Dh60tvWeypcprfuCfAQmCA9cYm6PeAW GThpmNSLQW4Q/gWPpMYQDzqqOOQnWGIB1k9g2GXAIM6NH7x0W9R5RnRKWyy5/K/B8fpo wyoND5Qkr9OdJpdebk5yPmRCetxAzIOCeYXiCIij8KSUErPzMUDTW2O1picHmWSFCndL BCcmoH44TvVGU0KwlIko1++3xuDBgMAJGyNYaaF3PzYML7kW7qjR0PP/QIVjzKWul+Uu 2+RapuHIy6j0zOhdqHzTv3fkHluxHWVxcQKytTW+1bpoSvUuUkg2DXWYQ55ybOlAcVbE dUhQ== X-Gm-Message-State: ALoCoQnAA0amuZdT8G8kD183Xbkzc7e2VC+1mVQUssm2w/6VcNAp+KysgsNG6Mxiej5ybE0cFgOO X-Received: by 10.66.232.40 with SMTP id tl8mr30345704pac.137.1394307410741; Sat, 08 Mar 2014 11:36:50 -0800 (PST) Received: from [10.64.27.94] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ha2sm49171494pbb.8.2014.03.08.11.36.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Mar 2014 11:36:50 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: crash starting wandboard-quad with latest code From: Warner Losh In-Reply-To: Date: Sat, 8 Mar 2014 12:36:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Everett X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:36:52 -0000 On Mar 8, 2014, at 12:29 PM, Tom Everett wrote: > I've done a build of the wandboard-quad with svn version r262929 >=20 > Strangely, it now just stops, with no serial console output during the > boot. The complete boot log is below. My previous build with source > revision r262820 worked perfectly. >=20 > Any suggestions about what might be happening? No idea, but perhaps you could bisect? I did a change to the serial code last night that shouldn=92t have been a problem. Try r2626919 = maybe? Warner >=20 > .. >=20 >=20 > U-Boot 2013.10 (Mar 08 2014 - 11:53:29) >=20 >=20 > CPU: Freescale i.MX6Q rev1.2 at 792 MHz >=20 > Reset cause: POR >=20 > Board: Wandboard >=20 > DRAM: 2 GiB >=20 > MMC: FSL_SDHC: 0, FSL_SDHC: 1 >=20 > *** Warning - bad CRC, using default environment >=20 >=20 > In: serial >=20 > Out: serial >=20 > Err: serial >=20 > Net: FEC [PRIME] >=20 > Hit any key to stop autoboot: 5 ... 4 ... 3 ... 2 ... 1 ... 0 >=20 > mmc0 is current device >=20 > reading boot.scr >=20 > 157 bytes read in 10 ms (14.6 KiB/s) >=20 > Running bootscript from mmc ... >=20 > ## Executing script at 12000000 >=20 > reading ubldr >=20 > 253278 bytes read in 28 ms (8.6 MiB/s) >=20 > ## Starting application at 0x88000054 ... >=20 > Consoles: U-Boot console >=20 >=20 > Compatible API signature found @8f5756f8 >=20 >=20 > MMC: no card present >=20 > MMC Device 2 not found >=20 > MMC Device 3 not found >=20 > Number of U-Boot devices: 2 >=20 >=20 >=20 >=20 >=20 > FreeBSD/armv6 U-Boot loader, Revision 1.2 >=20 >=20 > (tom@bernice, Sat Mar 8 11:53:22 MST 2014) >=20 >=20 > DRAM: 2048MB >=20 >=20 > Probing for bootable devices... >=20 >=20 > Bootable device: disk >=20 >=20 > Bootable device: net >=20 >=20 > Current device: disk >=20 >=20 > |./.-.\.|./.-.\.|./.-.\.|./.-. >=20 >=20 > \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-./boot/kernel/kernel > data=3D0x4dc0c8+0x2ff38 > = \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.= |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|.= /.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.= -.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.= \.|./.-.\.|./.-.\.syms=3D[0x4+0x7e6e0|./.-.\.|./.-.\.|./.-.\.|./.-.\.+0x4+= 0x4e0a1|./.-.\.|./.-.\.|.] >=20 >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. >=20 >=20 >=20 > Booting [/boot/kernel/kernel] in 9 seconds... > Booting [/boot/kernel/kernel] in 8 seconds... > Booting [/boot/kernel/kernel] in 7 seconds... > Booting [/boot/kernel/kernel] in 6 seconds... > Booting [/boot/kernel/kernel] in 5 seconds... > Booting [/boot/kernel/kernel] in 4 seconds... > Booting [/boot/kernel/kernel] in 3 seconds... > Booting [/boot/kernel/kernel] in 2 seconds... > Booting [/boot/kernel/kernel] in 1 second... > Booting [/boot/kernel/kernel]... >=20 >=20 > /.-.\.|./.-.\.|./.-.\.|./.-.\.|./.Loaded DTB from file = 'wandboard-quad.dtb'. >=20 >=20 > -.\.|./.-.\.|.Kernel entry at 0x12000100... >=20 >=20 > Kernel args: (null) >=20 >=20 > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2014 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 11.0-CURRENT #0 r262929: Sat Mar 8 11:47:07 MST 2014 > = tom@bernice:/storage/home/tom/crochet/crochet-freebsd/work/obj/arm.armv6/s= torage/home/tom/crochet/src/FreeBSDHead/head/sys/IMX6 > arm > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > CPU: Cortex A9-r2 rev 10 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:1 LoUIS:2 > Cache level 1: > 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc > 32KB/32B 4-way instruction cache Read-Alloc > real memory =3D 2147483648 (2048 MB) > avail memory =3D 2093953024 (1996 MB) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random device not loaded; using insecure entropy > random: initialized > ofwbus0: > simplebus0: on ofwbus0 > gic0: mem > 0xa01000-0xa01fff,0xa00100-0xa001ff on simplebus0 > gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b sc->nirqs 160 > l2cache0: mem 0xa02000-0xa02fff irq 124 on > simplebus0 > l2cache0: Part number: 0x3, release: 0x7 > l2cache0: L2 Cache: 1024KB/32B 16 ways > l2cache0: L2 Cache enabled > simplebus1: mem 0x2000000-0x20fffff = on > simplebus0 > ccm0: mem 0x20c4000-0x20c7fff = irq > 119,120 on simplebus1 > imx6_anatop0: mem > 0x20c8000-0x20c8fff irq 49 on simplebus1 > imx6_anatop0: voltage set to 1225 > imx6_anatop0: CPU frequency 984MHz > imx_gpt0: mem 0x2098000-0x209bfff irq 87 on > simplebus1 > Event timer "iMXGPT" frequency 11000000 Hz quality 800 > Timecounter "iMXGPT" frequency 11000000 Hz quality 1000 > uart0: mem 0x2020000-0x2023fff irq 58 on simplebus1 > uart0: console (0,n,8,1) > usbphy0: mem 0x20c9000-0x20c9fff irq 44 on > simplebus1 > usbphy1: mem 0x20ca000-0x20cafff irq 45 on > simplebus1 > simplebus2: mem 0x2100000-0x21fffff = on > simplebus0 > ffec0: mem 0x2188000-0x218bfff = irq > 150,151 on simplebus2 > miibus0: on ffec0 > atphy0: PHY 1 on miibus0 > atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseSX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > ffec0: Ethernet address: 00:1f:7b:b4:06:7f > ehci0: mem = 0x2184000-0x21841ff > irq 75 on simplebus2 > ehci0: [GIANT-LOCKED] > usbus0: EHCI version 1.0 > usbus0 on ehci0 > ehci1: mem = 0x2184200-0x21843ff > irq 72 on simplebus2 > ehci1: [GIANT-LOCKED] > usbus1: EHCI version 1.0 > usbus1 on ehci1 > sdhci_imx0: mem 0x2190000-0x2193fff irq = 54 on > simplebus2 > mmc0: on sdhci_imx0 > sdhci_imx1: mem 0x2198000-0x219bfff irq = 56 on > simplebus2 > mmc1: on sdhci_imx1 > ocotp0: mem > 0x21bc000-0x21bffff on simplebus2 > Timecounters tick every 4.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on = usbus0 > ugen1.1: at usbus1 > uhub1: on = usbus1 > mmc0: No compatible cards found on bus > mmcsd0: 16GB at mmc1 > 50.0MHz/4bit/65535-block > random: unblocking device. > Release APs > uhub0: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > Spurious interrupt detected [0x000003ff] > ugen1.2: at usbus1 > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > warning: no time-of-day clock registered, system time will not be set > accurately >=20 >=20 >=20 >=20 > --=20 > A better world shall emerge based on faith and understanding - = Douglas > MacArthur > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 19:41:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C1BEF3 for ; Sat, 8 Mar 2014 19:41:28 +0000 (UTC) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 217CF238 for ; Sat, 8 Mar 2014 19:41:27 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id g12so5522265oah.36 for ; Sat, 08 Mar 2014 11:41:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ak8+//iDusafgqxGZXM5MNV3OCsWYYZNhv4XxfrpY6s=; b=lZXAQuLzbCPb3sEu6G3mav7mrDICoJnpMYgoiSCNFy+hkWebsZIgdOfIzGOWNxdOih 6/FlHkXGhkG8hy0C/sszJ8CcNKram5LpzqQPPPbvxtKqXP7ZEOE78pSJ7iG3M4wxG8xO Lk3xrtL015bAELPwyRX0Zj3uTIbUJxby7iuD6ZOi7Fjg13N2QGPoB7zYCvdcj6MpEiIS OwXWm53Ngh1g5AqoKjmWnXar3tSpFXAO/Y3JoFHz422Ncn/ZW708qcK8ZPhiDdffySwz 2cWKwHUpWsvB2pMzFji7fvLC6CQmoSA6tCNoWnGW7vuQsnt8QUsO/sKS0DAJrpWns6tN Egow== X-Gm-Message-State: ALoCoQnh993km5A2swaYvF0GGB57woDX2hMBfHh9SuQ8DpbxRPbnNkyLXz2ydeqAQb2EwuTEY0kv MIME-Version: 1.0 X-Received: by 10.182.24.69 with SMTP id s5mr21378654obf.35.1394307681688; Sat, 08 Mar 2014 11:41:21 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sat, 8 Mar 2014 11:41:21 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Mar 2014 12:41:21 -0700 Message-ID: Subject: Re: crash starting wandboard-quad with latest code From: Tom Everett To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:41:28 -0000 I'll give that a try and let you know. On Sat, Mar 8, 2014 at 12:36 PM, Warner Losh wrote: > > On Mar 8, 2014, at 12:29 PM, Tom Everett wrote: > > > I've done a build of the wandboard-quad with svn version r262929 > > > > Strangely, it now just stops, with no serial console output during the > > boot. The complete boot log is below. My previous build with source > > revision r262820 worked perfectly. > > > > Any suggestions about what might be happening? > > > No idea, but perhaps you could bisect? I did a change to the serial > code last night that shouldn't have been a problem. Try r2626919 maybe? > > Warner > > > > > > > .. > > > > > > U-Boot 2013.10 (Mar 08 2014 - 11:53:29) > > > > > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > > > > Reset cause: POR > > > > Board: Wandboard > > > > DRAM: 2 GiB > > > > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > > > > *** Warning - bad CRC, using default environment > > > > > > In: serial > > > > Out: serial > > > > Err: serial > > > > Net: FEC [PRIME] > > > > Hit any key to stop autoboot: 5 ... 4 ... 3 ... 2 ... 1 ... 0 > > > > mmc0 is current device > > > > reading boot.scr > > > > 157 bytes read in 10 ms (14.6 KiB/s) > > > > Running bootscript from mmc ... > > > > ## Executing script at 12000000 > > > > reading ubldr > > > > 253278 bytes read in 28 ms (8.6 MiB/s) > > > > ## Starting application at 0x88000054 ... > > > > Consoles: U-Boot console > > > > > > Compatible API signature found @8f5756f8 > > > > > > MMC: no card present > > > > MMC Device 2 not found > > > > MMC Device 3 not found > > > > Number of U-Boot devices: 2 > > > > > > > > > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > > > > > (tom@bernice, Sat Mar 8 11:53:22 MST 2014) > > > > > > DRAM: 2048MB > > > > > > Probing for bootable devices... > > > > > > Bootable device: disk > > > > > > Bootable device: net > > > > > > Current device: disk > > > > > > |./.-.\.|./.-.\.|./.-.\.|./.-. > > > > > > \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-./boot/kernel/kernel > > data=3D0x4dc0c8+0x2ff38 > > > \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\= .|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|.= /.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-= .\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.= |./.-.\.|./.-.\.syms=3D[0x4+0x7e6e0|./.-.\.|./.-.\.|./.-.\.|./.-.\.+0x4+0x4= e0a1|./.-.\.|./.-.\.|.] > > > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > > > > > > Booting [/boot/kernel/kernel] in 9 seconds... > > Booting [/boot/kernel/kernel] in 8 seconds... > > Booting [/boot/kernel/kernel] in 7 seconds... > > Booting [/boot/kernel/kernel] in 6 seconds... > > Booting [/boot/kernel/kernel] in 5 seconds... > > Booting [/boot/kernel/kernel] in 4 seconds... > > Booting [/boot/kernel/kernel] in 3 seconds... > > Booting [/boot/kernel/kernel] in 2 seconds... > > Booting [/boot/kernel/kernel] in 1 second... > > Booting [/boot/kernel/kernel]... > > > > > > /.-.\.|./.-.\.|./.-.\.|./.-.\.|./.Loaded DTB from file > 'wandboard-quad.dtb'. > > > > > > -.\.|./.-.\.|.Kernel entry at 0x12000100... > > > > > > Kernel args: (null) > > > > > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2014 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 11.0-CURRENT #0 r262929: Sat Mar 8 11:47:07 MST 2014 > > tom@bernice > :/storage/home/tom/crochet/crochet-freebsd/work/obj/arm.armv6/storage/hom= e/tom/crochet/src/FreeBSDHead/head/sys/IMX6 > > arm > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > > CPU: Cortex A9-r2 rev 10 (Cortex-A core) > > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > > WB disabled EABT branch prediction enabled > > LoUU:2 LoC:1 LoUIS:2 > > Cache level 1: > > 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc > > 32KB/32B 4-way instruction cache Read-Alloc > > real memory =3D 2147483648 (2048 MB) > > avail memory =3D 2093953024 (1996 MB) > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > random device not loaded; using insecure entropy > > random: initialized > > ofwbus0: > > simplebus0: on ofwbus0 > > gic0: mem > > 0xa01000-0xa01fff,0xa00100-0xa001ff on simplebus0 > > gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b sc->nirqs 160 > > l2cache0: mem 0xa02000-0xa02fff irq 124 on > > simplebus0 > > l2cache0: Part number: 0x3, release: 0x7 > > l2cache0: L2 Cache: 1024KB/32B 16 ways > > l2cache0: L2 Cache enabled > > simplebus1: mem 0x2000000-0x20fffff = on > > simplebus0 > > ccm0: mem 0x20c4000-0x20c7fff ir= q > > 119,120 on simplebus1 > > imx6_anatop0: mem > > 0x20c8000-0x20c8fff irq 49 on simplebus1 > > imx6_anatop0: voltage set to 1225 > > imx6_anatop0: CPU frequency 984MHz > > imx_gpt0: mem 0x2098000-0x209bfff irq 87 on > > simplebus1 > > Event timer "iMXGPT" frequency 11000000 Hz quality 800 > > Timecounter "iMXGPT" frequency 11000000 Hz quality 1000 > > uart0: mem 0x2020000-0x2023fff irq 58 on simplebus1 > > uart0: console (0,n,8,1) > > usbphy0: mem 0x20c9000-0x20c9fff irq 44 on > > simplebus1 > > usbphy1: mem 0x20ca000-0x20cafff irq 45 on > > simplebus1 > > simplebus2: mem 0x2100000-0x21fffff = on > > simplebus0 > > ffec0: mem 0x2188000-0x218bfff > irq > > 150,151 on simplebus2 > > miibus0: on ffec0 > > atphy0: PHY 1 on miibus0 > > atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > 1000baseSX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > > ffec0: Ethernet address: 00:1f:7b:b4:06:7f > > ehci0: mem 0x2184000-0x21841= ff > > irq 75 on simplebus2 > > ehci0: [GIANT-LOCKED] > > usbus0: EHCI version 1.0 > > usbus0 on ehci0 > > ehci1: mem 0x2184200-0x21843= ff > > irq 72 on simplebus2 > > ehci1: [GIANT-LOCKED] > > usbus1: EHCI version 1.0 > > usbus1 on ehci1 > > sdhci_imx0: mem 0x2190000-0x2193fff irq 54 > on > > simplebus2 > > mmc0: on sdhci_imx0 > > sdhci_imx1: mem 0x2198000-0x219bfff irq 56 > on > > simplebus2 > > mmc1: on sdhci_imx1 > > ocotp0: mem > > 0x21bc000-0x21bffff on simplebus2 > > Timecounters tick every 4.000 msec > > usbus0: 480Mbps High Speed USB v2.0 > > usbus1: 480Mbps High Speed USB v2.0 > > ugen0.1: at usbus0 > > uhub0: on > usbus0 > > ugen1.1: at usbus1 > > uhub1: on > usbus1 > > mmc0: No compatible cards found on bus > > mmcsd0: 16GB at mmc1 > > 50.0MHz/4bit/65535-block > > random: unblocking device. > > Release APs > > uhub0: 1 port with 1 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > Spurious interrupt detected [0x000003ff] > > ugen1.2: at usbus1 > > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > > warning: no time-of-day clock registered, system time will not be set > > accurately > > > > > > > > > > -- > > A better world shall emerge based on faith and understanding - Douglas > > MacArthur > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > --=20 A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 19:54:37 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A36E3620 for ; Sat, 8 Mar 2014 19:54:37 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 754BE360 for ; Sat, 8 Mar 2014 19:54:36 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WMNKN-000I6V-Ux; Sat, 08 Mar 2014 19:54:36 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s28JsXae053722; Sat, 8 Mar 2014 12:54:33 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/ymUwFGO3mKkTx/zcWS9ty Subject: Re: crash starting wandboard-quad with latest code From: Ian Lepore To: Warner Losh In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-7" Date: Sat, 08 Mar 2014 12:54:33 -0700 Message-ID: <1394308473.1149.419.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s28JsXae053722 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:54:37 -0000 On Sat, 2014-03-08 at 12:36 -0700, Warner Losh wrote: > On Mar 8, 2014, at 12:29 PM, Tom Everett wrote: >=20 > > I've done a build of the wandboard-quad with svn version r262929 > >=20 > > Strangely, it now just stops, with no serial console output during th= e > > boot. The complete boot log is below. My previous build with source > > revision r262820 worked perfectly. > >=20 > > Any suggestions about what might be happening? >=20 >=20 > No idea, but perhaps you could bisect? I did a change to the serial > code last night that shouldn=A2t have been a problem. Try r2626919 mayb= e? >=20 > Warner >=20 It's good at r262920, hangs at r262921. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 19:55:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9DEB66B for ; Sat, 8 Mar 2014 19:55:25 +0000 (UTC) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B970936C for ; Sat, 8 Mar 2014 19:55:25 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id p10so5445426pdj.3 for ; Sat, 08 Mar 2014 11:55:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gZaaaqvSpbcjCH9twCJ/1iJJWFKQnb7sMYSUvl7iG8k=; b=O+/YY364h+rqkTM68ML4Xo9OhHDE97plSxCJe89j1itrsBWlnGFb2eU3lCLemjV3He pkmci7RjzCLIpKx15676I1yAzDkzkzZcwamJ+SfU7YL4xcMyFxv+yUR2IGBUO5RuD/E0 ql+WEklR3VYmmohfTY9JdCsgq3A/9v3rK3inedHaTf93y0RbMCE7HEI2ERJWhgF3TG67 h2H4WEzUqmHEjSdJ5wbPjs32cf+tfaOQ8fzpxlsJpET/J4RW5tnCNoFYQAIFYF592qqI eM3pyypfD+olo91s0uiFKjFEKmxc0UbZGIVXfiHpNH9Z6R1gtq7jxWAp66PCOJprVUFV PITg== X-Gm-Message-State: ALoCoQkC5mupNboPbd1kPT4EOLeHN47tDNFWziHKEWheQug7+QqQopNWPdk44ygpvadMt3Nj9yzi X-Received: by 10.66.250.202 with SMTP id ze10mr30615178pac.153.1394308519140; Sat, 08 Mar 2014 11:55:19 -0800 (PST) Received: from [10.64.27.94] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id sm5sm38548675pab.19.2014.03.08.11.55.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Mar 2014 11:55:18 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: crash starting wandboard-quad with latest code From: Warner Losh In-Reply-To: <1394308473.1149.419.camel@revolution.hippie.lan> Date: Sat, 8 Mar 2014 12:55:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44E28B95-4DE4-4682-B027-40337E918BCD@bsdimp.com> References: <1394308473.1149.419.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:55:26 -0000 On Mar 8, 2014, at 12:54 PM, Ian Lepore wrote: > On Sat, 2014-03-08 at 12:36 -0700, Warner Losh wrote: >> On Mar 8, 2014, at 12:29 PM, Tom Everett wrote: >>=20 >>> I've done a build of the wandboard-quad with svn version r262929 >>>=20 >>> Strangely, it now just stops, with no serial console output during = the >>> boot. The complete boot log is below. My previous build with = source >>> revision r262820 worked perfectly. >>>=20 >>> Any suggestions about what might be happening? >>=20 >>=20 >> No idea, but perhaps you could bisect? I did a change to the serial >> code last night that shouldn=A2t have been a problem. Try r2626919 = maybe? >>=20 >> Warner >>=20 >=20 > It's good at r262920, hangs at r262921. Crap. That=A2s one of mine from last night. Will revert. Warner From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 19:58:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF73B6BD for ; Sat, 8 Mar 2014 19:58:18 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0E2237D for ; Sat, 8 Mar 2014 19:58:18 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id ld10so5572852pab.12 for ; Sat, 08 Mar 2014 11:58:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3qgkoJ7qJEAPYjAV+gV0+bwKz/uazvY0rkUJ52af8qw=; b=V8Lxu5W693wTraZGGHwlhyGIrwdGbMe2mB665d/hFVtviPsrbFjbJc4w5yfZUQGqqd U8US9NFGydZbkRactnznn22GcfEOJGnm4LP6L7g/4HzMA/JVrrStyR8lfxNjsUs6f5KX /6nSgQZo7LPUJSTRXCAL0v+PLq7lfQMLYEEF2xHMZQWmia9JSZN1snhVYElf+XRbDE+q /DvqHPkDbEpllYmisleXqkusUw8S4XjiCYd6tpoylKd7EDkGftgaf6eJp6EIeokYkNG+ NYkPeue0Xhnp+EHvQaSxPNxAArKm0B6tOvY1xDd4HQwsjLKrRh6ny1ImPFxn3ZBnflUb j+8Q== X-Gm-Message-State: ALoCoQlIj8E45lIVjG/RiQGYy4rrapivnVoPN1qlkdNf+nvYcLWSxmjno823FU+ipSaHgsFDlP/o X-Received: by 10.68.44.71 with SMTP id c7mr30410317pbm.24.1394308692645; Sat, 08 Mar 2014 11:58:12 -0800 (PST) Received: from [10.64.27.94] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id vf7sm49225374pbc.5.2014.03.08.11.58.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Mar 2014 11:58:11 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: crash starting wandboard-quad with latest code From: Warner Losh In-Reply-To: <1394308473.1149.419.camel@revolution.hippie.lan> Date: Sat, 8 Mar 2014 12:58:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <643A74ED-5CBE-486F-8A85-22CF40DA68AF@bsdimp.com> References: <1394308473.1149.419.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:58:18 -0000 On Mar 8, 2014, at 12:54 PM, Ian Lepore wrote: > On Sat, 2014-03-08 at 12:36 -0700, Warner Losh wrote: >> On Mar 8, 2014, at 12:29 PM, Tom Everett wrote: >>=20 >>> I've done a build of the wandboard-quad with svn version r262929 >>>=20 >>> Strangely, it now just stops, with no serial console output during = the >>> boot. The complete boot log is below. My previous build with = source >>> revision r262820 worked perfectly. >>>=20 >>> Any suggestions about what might be happening? >>=20 >>=20 >> No idea, but perhaps you could bisect? I did a change to the serial >> code last night that shouldn=A2t have been a problem. Try r2626919 = maybe? >>=20 >> Warner >>=20 >=20 > It's good at r262920, hangs at r262921. Yea, my change is actually lame. Warner From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 20:00:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AC05845 for ; Sat, 8 Mar 2014 20:00:48 +0000 (UTC) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0724390 for ; Sat, 8 Mar 2014 20:00:47 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id rp16so5630961pbb.3 for ; Sat, 08 Mar 2014 12:00:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cvodv4p++iU+Zm0fu9gjhZ8c+DR5lB1e98Aj3cR02d4=; b=l27WfpEiXyc6xaFFVUYyelurOuaTlImTaHxQXbQhtrzBd9URHAnnCix9Z+vGBazcE5 B3BpDcjmCuHw7LBEKI9WxOXSaXT69LZwKgLXyKOkUW8D8wQrVn9emSvTzZ9YiM4U8aIW /eLHsgdYnlqSwIiMVsRlisB0OvJRpVjgvGqJhHjVyx025jn8UbZ075rEkA/1yAZSaP6F /nLpnPgvzy0BFbXSPEwapzn0UO8bddYoLAhWk25hG7GD4v0m8OR+1YYljzPoV28z8Sy+ x1kRmf0g4XOZWmwNzCeeAiInP7P9FUKzO9aEilD5ic5EyITugnmhLO6ZwqbGBxAHyMCq ul1g== X-Gm-Message-State: ALoCoQk6810rjAWHarNfHSBFb6N/oRR1xR2AXk/cvrVR1tWD+/RpGK3jdT5GWTE8XgEedNR+u8eo X-Received: by 10.66.164.36 with SMTP id yn4mr20889691pab.25.1394308847341; Sat, 08 Mar 2014 12:00:47 -0800 (PST) Received: from [10.64.27.94] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id iv2sm49525360pbc.19.2014.03.08.12.00.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Mar 2014 12:00:46 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: crash starting wandboard-quad with latest code From: Warner Losh In-Reply-To: <1394308473.1149.419.camel@revolution.hippie.lan> Date: Sat, 8 Mar 2014 13:00:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A44ABDF-33E4-42BF-97BC-1575220CF176@bsdimp.com> References: <1394308473.1149.419.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 20:00:48 -0000 On Mar 8, 2014, at 12:54 PM, Ian Lepore wrote: > On Sat, 2014-03-08 at 12:36 -0700, Warner Losh wrote: >> On Mar 8, 2014, at 12:29 PM, Tom Everett wrote: >>=20 >>> I've done a build of the wandboard-quad with svn version r262929 >>>=20 >>> Strangely, it now just stops, with no serial console output during = the >>> boot. The complete boot log is below. My previous build with = source >>> revision r262820 worked perfectly. >>>=20 >>> Any suggestions about what might be happening? >>=20 >>=20 >> No idea, but perhaps you could bisect? I did a change to the serial >> code last night that shouldn=A2t have been a problem. Try r2626919 = maybe? >>=20 >> Warner >>=20 >=20 > It's good at r262920, hangs at r262921. Try r262932. I don=A2t know what I was thinking with r262921 now that I = look at the code closely... Warner From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 20:04:22 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9D8989B for ; Sat, 8 Mar 2014 20:04:22 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC6EF5FB for ; Sat, 8 Mar 2014 20:04:22 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WMNTk-00041W-6G; Sat, 08 Mar 2014 20:04:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s28K4D0g053752; Sat, 8 Mar 2014 13:04:13 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX192RiaBzkMBxZhRadYOkkmd Subject: Re: crash starting wandboard-quad with latest code From: Ian Lepore To: Warner Losh In-Reply-To: <5A44ABDF-33E4-42BF-97BC-1575220CF176@bsdimp.com> References: <1394308473.1149.419.camel@revolution.hippie.lan> <5A44ABDF-33E4-42BF-97BC-1575220CF176@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" Date: Sat, 08 Mar 2014 13:04:13 -0700 Message-ID: <1394309053.1149.420.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s28K4D0g053752 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 20:04:23 -0000 On Sat, 2014-03-08 at 13:00 -0700, Warner Losh wrote: > On Mar 8, 2014, at 12:54 PM, Ian Lepore wrote: >=20 > > On Sat, 2014-03-08 at 12:36 -0700, Warner Losh wrote: > >> On Mar 8, 2014, at 12:29 PM, Tom Everett wrote: > >>=20 > >>> I've done a build of the wandboard-quad with svn version r262929 > >>>=20 > >>> Strangely, it now just stops, with no serial console output during = the > >>> boot. The complete boot log is below. My previous build with sour= ce > >>> revision r262820 worked perfectly. > >>>=20 > >>> Any suggestions about what might be happening? > >>=20 > >>=20 > >> No idea, but perhaps you could bisect? I did a change to the serial > >> code last night that shouldn=A2t have been a problem. Try r2626919 m= aybe? > >>=20 > >> Warner > >>=20 > >=20 > > It's good at r262920, hangs at r262921. >=20 >=20 > Try r262932. I don=A2t know what I was thinking with r262921 now that I= look at the code closely... >=20 > Warner Yep, that fixed it. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 22:30:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0FEAE3E for ; Sat, 8 Mar 2014 22:30:46 +0000 (UTC) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86A7710F for ; Sat, 8 Mar 2014 22:30:46 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id va2so5616903obc.38 for ; Sat, 08 Mar 2014 14:30:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8lYU5C2rzkIuSODI1/rf1ZS9EgO+7uHH7KqEKTnZRfY=; b=UO9nzfvmTCw2/YPer1L5c3EC5yZqZF8/UilyM8facau1Yl5Ljw1T3YBj4plHxt3CTa Jlp7mEhXBF4dbNUvB+Uk7umxciW4FvSHH6vEeY7h2Le/w2twmS5ddGZ9tI/34f5D94Ye M5FTraCDbKdpzmn153jzfDtEMA6z02kZ4oQtU8cnBDLCiOsQmjCoExQgwoj/b4EL7MTC EByNy8MTVncHmUodyJ0FHixGdKYbcgQFgi0XFa+WgLvfNoj/fR2XPahtaaKNnnmXcqRn e+8Qlxb3MMZ5aWFc0mCMcaq6+iut1RBBRFXmYb2woEfR3kJP7N0k5GmZSV3fPTcFLqrq caMg== X-Gm-Message-State: ALoCoQmLVuphXLyzYHsTInNz580SVtrOcEP9m4lj5fCEfo+pR2vnBvY/qzfH/qzgbL2BG+pe3M32 MIME-Version: 1.0 X-Received: by 10.60.132.12 with SMTP id oq12mr17646543oeb.42.1394317840274; Sat, 08 Mar 2014 14:30:40 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sat, 8 Mar 2014 14:30:40 -0800 (PST) In-Reply-To: <1394309053.1149.420.camel@revolution.hippie.lan> References: <1394308473.1149.419.camel@revolution.hippie.lan> <5A44ABDF-33E4-42BF-97BC-1575220CF176@bsdimp.com> <1394309053.1149.420.camel@revolution.hippie.lan> Date: Sat, 8 Mar 2014 15:30:40 -0700 Message-ID: Subject: Re: crash starting wandboard-quad with latest code From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 22:30:46 -0000 Works nicely, version 262832 http://files.khubla.com/freebsd-wandboard/FreeBSD-armv6-11.0-IMX6-r262932.txt On Sat, Mar 8, 2014 at 1:04 PM, Ian Lepore wrote: > On Sat, 2014-03-08 at 13:00 -0700, Warner Losh wrote: > > On Mar 8, 2014, at 12:54 PM, Ian Lepore wrote: > > > > > On Sat, 2014-03-08 at 12:36 -0700, Warner Losh wrote: > > >> On Mar 8, 2014, at 12:29 PM, Tom Everett wrote: > > >> > > >>> I've done a build of the wandboard-quad with svn version r262929 > > >>> > > >>> Strangely, it now just stops, with no serial console output during > the > > >>> boot. The complete boot log is below. My previous build with source > > >>> revision r262820 worked perfectly. > > >>> > > >>> Any suggestions about what might be happening? > > >> > > >> > > >> No idea, but perhaps you could bisect? I did a change to the serial > > >> code last night that shouldn't have been a problem. Try r2626919 > maybe? > > >> > > >> Warner > > >> > > > > > > It's good at r262920, hangs at r262921. > > > > > > Try r262932. I don't know what I was thinking with r262921 now that I > look at the code closely... > > > > Warner > > Yep, that fixed it. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sat Mar 8 22:50:01 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E18B1BC for ; Sat, 8 Mar 2014 22:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 39837297 for ; Sat, 8 Mar 2014 22:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s28Mo1FG018466 for ; Sat, 8 Mar 2014 22:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s28Mo08u018439; Sat, 8 Mar 2014 22:50:00 GMT (envelope-from gnats) Date: Sat, 8 Mar 2014 22:50:00 GMT Message-Id: <201403082250.s28Mo08u018439@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Mats Erik Andersson Subject: Re: arm/181601: Sporadic failure of root mount on ARM/Raspberry X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Mats Erik Andersson List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 22:50:01 -0000 The following reply was made to PR arm/181601; it has been noted by GNATS. From: Mats Erik Andersson To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/181601: Sporadic failure of root mount on ARM/Raspberry Date: Sat, 8 Mar 2014 23:48:56 +0100 --f46d043bdf9ce8e17504f4202ca5 Content-Type: multipart/alternative; boundary=f46d043bdf9ce8e17204f4202ca3 --f46d043bdf9ce8e17204f4202ca3 Content-Type: text/plain; charset=ISO-8859-1 Most probably this issue is caused by the clock frequency chosen by mmcsd(4) during setup. Success happens only with 25.0 MHz, while timeouts and failures are legio happen with 50.0 MHz. The appended text gives more details. Regards, Mats Erik Andersson --f46d043bdf9ce8e17204f4202ca3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Most probably this issue is cause= d by the clock frequency chosen
by mmcsd(4) during setup. Success = happens only with 25.0 MHz,
while timeouts and failures are legio = happen with 50.0 MHz.
The appended text gives more details.

Regards,
= =A0=A0 Mats Erik Andersson
--f46d043bdf9ce8e17204f4202ca3-- --f46d043bdf9ce8e17504f4202ca5 Content-Type: text/plain; charset=US-ASCII; name="arm_sdhc.txt" Content-Disposition: attachment; filename="arm_sdhc.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsjhkf4n0 CkkgaGF2ZSBzb21lIHJlbGV2YW50IG9ic2VydmF0aW9ucyBvbiB0aGlzIGlzc3VlLgpUb2RheSBJ IGhhdmUgdHJpZWQgdG8gZ2V0IHRoZSBzbmFwc2hvdHMKCiAgIDExLjAtQ1VSUkVOVC1hcm0tYXJt djYtUlBJLUItMjAxNDAyMDktcjI2MTY0MgoKICAgMTEuMC1DVVJSRU5ULWFybS1hcm12Ni1SUEkt Qi0yMDE0MDIyMi1yMjYyMzM2Cgpnb2luZy4gQm90aCBmYWlsZWQgdG8gbW91bnQgdGhlIHJvb3Qg ZmlsZSBzeXN0ZW0sIGluc3BpdGUgb2YKcmVwZWF0ZWQgZWZmb3J0cy4gSG93ZXZlciwKCiAgIDEw LjAtU1RBQkxFLWFybS1hcm12Ni1SUEktQi0yMDE0MDMwMS1yMjYyNjU3CgppcyBzb21ldGltZXMg YWJsZSB0byBib290LCBidXQgbm90IGFsd2F5cy4gVW5mb3J0dW5hdGVseSB0aGUgbWFjaGluZQpu ZXZlciBzdWNjZWVkcyBhZnRlciByZWJvb3QuIChCeSB0aGUgd2F5LCBjb250cmFyeSB0byBteSBl eHBlY3RhdGlvbiwKdGhpcyAxMC4wLVNUQUJMRSBpbWFnZSBydW5zIGEgY3VycmVudCBrZXJuZWwg MTEuMC1DVVJSRU5ULCByMjYyMzM2LikKCkl0IGlzIHJlbGV2YW50IHRvIHJlY2FsbCB0aGUga2Vy bmVsIG1lc3NhZ2VzIGNvbnRhaW5lZCBpbiB0aGUgcHJldmlvdXNseQptZXNzYWdlcyB0byB0aGlz IFBSOgoKICBtbWNzZDA6IDhHQiA8U0RIQyBOQ2FyZCAxLjAgU04gMTA3NTgzOTM4NCBNRkcgMDUv MjAxMyBieSAxMzAgSlQ+CiAgICBhdCBtbWMwIDUwLjBNSHovNGJpdC82NTUzNS1ibG9jawoKICBt bWNzZDA6IDE2R0IgPFNESEMgU0QxNkcgMy4wIFNOIDEyMTMyMTk1NTcgTUZHIDAyLzIwMTMgYnkg MTMwIEpUPgogICAgYXQgbW1jMCA1MC4wTUh6LzRiaXQvNjU1MzUtYmxvY2sKClNpbWlsYXJseSwg bXkgY2FyZCwgYSBLaW5nc3RvbiBTREhDIDhHQiwgY2xhc3MgU0Q0LCBtb2RlbCBTRC1LMDhHLApn ZW5lcmF0ZXMgdGhlIGZvbGxvd2luZyBtZXNzYWdlIHdoZW4gdGhlIHJvb3QgbW91bnQgZmFpbHM6 CgogIG1tY3NkMDogOEdCIDxTREhDIFNBMDhHIDEuMSBTTiAxMTI0MTE1NTgyIE1GRyAwNy8yMDEz IGJ5IDIgVE0+CiAgICBhdCBtbWMwIDUwLjBNSHovNGJpdC82NTUzNS1ibG9jawoKSW4gY29udHJh c3QsIHRoZSBtZXNzYWdlIG9uIHN1Y2Nlc3NmdWwgYm9vdCBpcyB0aGlzOgoKICBtbWNzZDA6IDhH QiA8U0RIQyBTQTA4RyAxLjEgU04gMTEyNDExNTU4MiBNRkcgMDcvMjAxMyBieSAyIFRNPgogICAg YXQgbW1jMCAyNS4wTUh6LzRiaXQvNjU1MzUtYmxvY2sKClRoZSBkaWZmZXJlbmNlIGlzIG1pbnV0 ZTogMjUuME1IeiBpbnN0ZWFkIG9mIDUwLk1IeiEKCkkgaW50ZXJwcmV0IHRoaXMgaW4gdGhlIHdh eSB0aGF0IHRoZSBjYXJkIGlzIGZ1bmN0aW9uYWwsIGFzIGxvbmcKYXMgdGhlIGRyaXZlciBtbWNz ZCg0KSBzZWVzIGEgcmVhc29uIHRvIGFzc2lnbiB0aGUgU0QgZGVmYXVsdApzcGVlZCwgaS5lLiwg MjUuME1Ieiwgd2hpbGUgdGhlIGNhcmQgc2VlbWluZ2x5IGZhaWxzIGZyZXF1ZW50bHksCnNob3Vs ZCB0aGUgZHJpdmVyIHJlcXVlc3QgdGhlIG5leHQgcmF0ZSA1MC4wTUh6LiBQcm9iYWJseSB0aGUK aXNzdWUgY291bGQgYmUgcmVzb2x2ZWQgYnkgcmVmaW5pbmcgdGhlIGRldGVjdGlvbiBhbGdvcml0 aG0KZm9yIGNhbGN1bGF0aW5nIGNsb2NrIGZyZXF1ZW5jeS4K --f46d043bdf9ce8e17504f4202ca5-- From owner-freebsd-arm@FreeBSD.ORG Sun Mar 9 01:36:17 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEE6AC06 for ; Sun, 9 Mar 2014 01:36:17 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 70360A1 for ; Sun, 9 Mar 2014 01:36:17 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WMSf2-000N03-BI; Sun, 09 Mar 2014 01:36:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s291aDkm056686; Sat, 8 Mar 2014 18:36:13 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/44JzXLOxalsN7ROlOlVME Subject: Re: Crashes on arm caused by stack corruption From: Ian Lepore To: =?ISO-8859-1?Q?Wei=DF=2C_J=FCrgen?= In-Reply-To: <1caa439fc6a34c06b1667708306fd558@e15be-01.zdv.Uni-Mainz.DE> References: <1caa439fc6a34c06b1667708306fd558@e15be-01.zdv.Uni-Mainz.DE> Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 08 Mar 2014 18:36:13 -0700 Message-ID: <1394328973.1149.425.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s291aDkm056686 Cc: 'freebsd-arm' X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 01:36:17 -0000 On Sat, 2014-03-08 at 18:21 +0000, Wei=DF, J=FCrgen wrote: > For quite a while I observe random or not so random crashes on i.mx6.=20 >=20 > The svc stack grows into the undefined instruction exception stack, > as can be seen here. And there is corruption around the address in > the und_sp register. >=20 > db> show reg > spsr 0x600001d3 > r0 0 > r1 0xc246f3c0 __pcpu > r2 0xc2438100 pcpup > r3 0xc2379039 > r4 0xc6460000 > r5 0xc23789e2 > r6 0xc23733b4 > r7 0xc6460000 > r8 0 > r9 0x1 > r10 0 > r11 0xbfffe388 > r12 0 > usr_sp 0xbfffdf68 > usr_lr 0x21e04 > svc_sp 0xf183afe8 > svc_lr 0xc216add8 mi_switch+0x2b8 > pc 0x4278f500 > und_sp 0xf183aff0 > abt_sp 0xc2565000 > irq_sp 0xc2561000 >=20 >=20 > The strange thing is, that there is an undefined instruction > exception stack undstack allocated for each core in initarm and > assigned to und_sp.=20 >=20 > But later on in cpu_switch, und_sp is loaded=20 > ldr sp, [r9, #(PCB_UND_SP)] > from un_32.pcb32_und_sp. Which is intialized to=20 > #define USPACE_UNDEF_STACK_TOP (USPACE_SVC_STACK_BOTTOM - 0x10= ) > which comes from > #define USPACE_SVC_STACK_BOTTOM (USPACE_SVC_STACK_TOP - 0x1000) > and effectively halves the svc stack. >=20 > The undefined instruction exception stack is almost not used, besides > a few words right at the beginning of the exception handling. The > exception frame is actually build on the svc stack.=20 >=20 > Now undefined instruction exceptions should only happen in user mode > (VFP). Then the used part of svc stack should be small enough, so that > no harm should result. But in cpu_throw the code for manipulating > the und_sp is actually missing. So sometimes undefined instruction=20 > exceptions write on the kernel stack of the wrong process/thread. >=20 > So seem to be two solutions. If I do not miss anything, I would > suggest to just drop the code, which switches the undefined=20 > instruction exception stack. The other is to add the missing > part to cpu_throw. See attached patch for both possibilities. >=20 > With any of both solutions the crashes on my system are gone.=20 >=20 > I think this problem affects all arm systems. >=20 > There is another problem with the handling of undefined > instructions. The first few instructions of the undefined instruction > exception handler use static variables and are definitively > not SMP save. I wonder why the code is not similar to the > prefetch abort handler or the data abort handler. >=20 > Regards >=20 > Juergen After some spelunking in old cvs history and talking to Olivier, it appears that both of these things -- per-thread undef stack and the strange undef exception entry code -- are left over from years ago when there were hooks in the undef entry for a debugger which needed some stack space. The debugger code was removed, leaving just the oddball remnants of the old entry code, but the stack stuff never got removed. I'm going to clean it all up by removing what's left and simplifying the entry routines. Thanks for debugging this. The best part of the news for me is that an application crash I've been chasing all week is fixed by the rewritten entry code for undefined exceptions. -- Ian =20 From owner-freebsd-arm@FreeBSD.ORG Sun Mar 9 16:17:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D624E94E for ; Sun, 9 Mar 2014 16:17:03 +0000 (UTC) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0E91A71 for ; Sun, 9 Mar 2014 16:17:03 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id i4so6064329oah.38 for ; Sun, 09 Mar 2014 09:16:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=KkFnuO80QO9FUevGmD+CwZ2QcHC5cHYCZuNji3Um0OE=; b=g6duNzG77Tf5huY76E9B4ZFQR8d8YnkHTkPaWUvENrr8e2UUhO86wIcvW0LXJI0YAy vKCvQHjTGGVn1c132rqlzllQ3Y6k5SVNlvwDFtcQgx75oo54s1OgtwFyKA2sUTIqU2M5 Ogp+RPYwW2NUT/oVBXX8eT9y3cawNtHwf8d3TkbrFboX8tAL9FmeFMBxwgsLDvkAQ6Ax OJ4/AJ84l4fGFJ9smp/7RJqwwoevAtqUnpVgLYlpljRz0zlo0RKNvFhstLBgEDUgKWwZ ZOWdHyhSWXzr3QJ5Fs7hs/ShOelrH2mhs09nIyRDrDZpltbGDlEgCytv/Uk3zssUePja 9TJA== X-Gm-Message-State: ALoCoQmWKTGH/nb6ERqf1pyM5kquwtrLqXPSt2r+uQVZy6APvHCGmRq2DpsdVQtiCWB9zuRjsR0H MIME-Version: 1.0 X-Received: by 10.60.233.202 with SMTP id ty10mr20622915oec.25.1394381817760; Sun, 09 Mar 2014 09:16:57 -0700 (PDT) Received: by 10.182.104.169 with HTTP; Sun, 9 Mar 2014 09:16:57 -0700 (PDT) Date: Sun, 9 Mar 2014 10:16:57 -0600 Message-ID: Subject: problem compiling pkgng From: Tom Everett To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 16:17:03 -0000 Hello, I'm running into the below error compiling pkgng on wandboard. My source revision is r262932. root@wandboard:/usr/home/tom/pkg-1.1 # make make: "/usr/home/tom/pkg-1.1/Makefile" line 13: warning: Couldn't read shell's output for "( which atf-version ) 2>&1 || true" ===> external (all) ===> external/sqlite (all) Warning: Object directory not changed from original /usr/home/tom/pkg-1.1/external/sqlite ===> external/libyaml (all) Warning: Object directory not changed from original /usr/home/tom/pkg-1.1/external/libyaml ===> libpkg (all) Warning: Object directory not changed from original /usr/home/tom/pkg-1.1/libpkg ===> pkg (all) Warning: Object directory not changed from original /usr/home/tom/pkg-1.1/pkg ===> scripts (all) ===> scripts/periodic (all) ===> scripts/completion (all) ===> scripts/sbin (all) ===> pkg-static (all) Warning: Object directory not changed from original /usr/home/tom/pkg-1.1/pkg-static cc -O -pipe -I/usr/home/tom/pkg-1.1/pkg-static/../libpkg -I/usr/home/tom/pkg-1.1/pkg-static/../external/uthash -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -static -o pkg-static add.o annotate.o audit.o autoremove.o backup.o check.o clean.o convert.o create.o delete.o event.o info.o install.o lock.o main.o plugins.o progressmeter.o query.o register.o repo.o rquery.o update.o upgrade.o search.o set.o shlib.o updating.o utils.o version.o which.o fetch.o shell.o stats.o ssh.o -L/usr/home/tom/pkg-1.1/pkg-static/../libpkg -lpkg -larchive -lutil -lpthread -lsbuf -lfetch -lssl -lcrypto -lmd -lz -lbz2 -llzma -lbsdxml -L/usr/home/tom/pkg-1.1/pkg-static/../external/sqlite -L/usr/home/tom/pkg-1.1/pkg-static/../external/libyaml -lyaml -lsqlite3 -larchive -lsbuf -lfetch -lpthread -lelf -lssl -lcrypto -lmd -lz -lbz2 -llzma -ledit -lncursesw -ljail /usr/lib/libarchive.a: could not read symbols: Malformed archive cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[1]: stopped in /usr/home/tom/pkg-1.1/pkg-static *** Error code 1 Stop. make: stopped in /usr/home/tom/pkg-1.1 -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sun Mar 9 16:52:21 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 730A1587 for ; Sun, 9 Mar 2014 16:52:21 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35FBFD75 for ; Sun, 9 Mar 2014 16:52:20 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WMgxX-000DGF-R8; Sun, 09 Mar 2014 16:52:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s29GqH2Q057945; Sun, 9 Mar 2014 10:52:17 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/0hpB8ej3mo6CUqCslfCn4 Subject: Re: problem compiling pkgng From: Ian Lepore To: Tom Everett In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sun, 09 Mar 2014 10:52:17 -0600 Message-ID: <1394383937.1149.440.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 16:52:21 -0000 On Sun, 2014-03-09 at 10:16 -0600, Tom Everett wrote: > Hello, I'm running into the below error compiling pkgng on wandboard. My > source revision is r262932. > > root@wandboard:/usr/home/tom/pkg-1.1 # make > > make: "/usr/home/tom/pkg-1.1/Makefile" line 13: warning: Couldn't read > shell's output for "( which atf-version ) 2>&1 || true" > > ===> external (all) > > ===> external/sqlite (all) > > Warning: Object directory not changed from original > /usr/home/tom/pkg-1.1/external/sqlite > > ===> external/libyaml (all) > > Warning: Object directory not changed from original > /usr/home/tom/pkg-1.1/external/libyaml > > ===> libpkg (all) > > Warning: Object directory not changed from original > /usr/home/tom/pkg-1.1/libpkg > > ===> pkg (all) > > Warning: Object directory not changed from original > /usr/home/tom/pkg-1.1/pkg > > ===> scripts (all) > > ===> scripts/periodic (all) > > ===> scripts/completion (all) > > ===> scripts/sbin (all) > > ===> pkg-static (all) > > Warning: Object directory not changed from original > /usr/home/tom/pkg-1.1/pkg-static > > cc -O -pipe -I/usr/home/tom/pkg-1.1/pkg-static/../libpkg > -I/usr/home/tom/pkg-1.1/pkg-static/../external/uthash -std=gnu99 > -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -static -o pkg-static add.o annotate.o audit.o > autoremove.o backup.o check.o clean.o convert.o create.o delete.o event.o > info.o install.o lock.o main.o plugins.o progressmeter.o query.o register.o > repo.o rquery.o update.o upgrade.o search.o set.o shlib.o updating.o > utils.o version.o which.o fetch.o shell.o stats.o ssh.o > -L/usr/home/tom/pkg-1.1/pkg-static/../libpkg -lpkg -larchive -lutil > -lpthread -lsbuf -lfetch -lssl -lcrypto -lmd -lz -lbz2 -llzma > -lbsdxml -L/usr/home/tom/pkg-1.1/pkg-static/../external/sqlite > -L/usr/home/tom/pkg-1.1/pkg-static/../external/libyaml -lyaml -lsqlite3 > -larchive -lsbuf -lfetch -lpthread -lelf -lssl -lcrypto -lmd -lz > -lbz2 -llzma -ledit -lncursesw -ljail > > /usr/lib/libarchive.a: could not read symbols: Malformed archive > > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > *** Error code 1 > > > Stop. > > make[1]: stopped in /usr/home/tom/pkg-1.1/pkg-static > > *** Error code 1 > > > Stop. > > make: stopped in /usr/home/tom/pkg-1.1 If it's like the ports building problems I ran into last week, if you reboot and build again it'll either work or die in a different place. I don't really have even a theory yet on what could be wrong, but I've been fixing everything I can find hoping that it'll just get better. I'm running out of things I know are a problem, so if it's not fixed by all the changes between r262941-950 then I'll have to start hunting specifically for this problem, which appears to be that sometimes data read from sdcard is corrupted (but I've yet to see corruption get onto the card, it seems to be during a read). Another problem I've run into in the past couple days is that event timers just stop running. You see this is an apparent lockup of anything periodic (such as a top display) or timeout-based, but you can still enter commands and get responses. Doing "sysctl kern.eventtimer.periodic=1" appears to work around it. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Mar 9 23:21:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0307281A for ; Sun, 9 Mar 2014 23:21:46 +0000 (UTC) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE2FA22F for ; Sun, 9 Mar 2014 23:21:45 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id uz6so6374483obc.27 for ; Sun, 09 Mar 2014 16:21:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jaedlU9gF+buCceNBOQDVy827t4lNyAjL8/GOruDdbg=; b=S5bXLp4WghvTEwfG7p9BjK61lpLgRftmiTvfXopLGr5W9y0YCL4rjm8jTkVB7F5vET jYa765dBQLJEMvlFSPBV2HPO5uU4kb9QKEy+U3M2/d/oAmMgmD/SYC5awE26K70wsQa4 Q0IcWZvi6DO2Ms1O9yz0dyM2Ib1LxcAZ9vTl3U9XlJ+ORHsWq6ekqRUKUsZsOFzGeTT7 CCIT6vvtkhdBujj/oYheV2lMcovR/MDWVxx7XsvhhLSAFm5n1rzvjcBCtNWh+B6chx64 +S4oQcQoW7CWTeaE1R3J+P3YXqtvxA2ivk9HUv+36TZfEkaTe915tWcEfaSkK8033Fcx 0uCw== X-Gm-Message-State: ALoCoQmsE5ibcfHyEzQ+Pmrsm6joLV3A5u/WfmE6wmmqYJBXOLu4WzWYzBXnzpvMBx3c9iRW52GX MIME-Version: 1.0 X-Received: by 10.60.115.68 with SMTP id jm4mr3828624oeb.45.1394407303675; Sun, 09 Mar 2014 16:21:43 -0700 (PDT) Received: by 10.182.104.169 with HTTP; Sun, 9 Mar 2014 16:21:43 -0700 (PDT) In-Reply-To: <1394383937.1149.440.camel@revolution.hippie.lan> References: <1394383937.1149.440.camel@revolution.hippie.lan> Date: Sun, 9 Mar 2014 17:21:43 -0600 Message-ID: Subject: Re: problem compiling pkgng From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 23:21:46 -0000 After a reboot it did indeed continue on building. I'm building an image for 262958 now, and I'll try that once it's built. On Sun, Mar 9, 2014 at 10:52 AM, Ian Lepore wrote: > On Sun, 2014-03-09 at 10:16 -0600, Tom Everett wrote: > > Hello, I'm running into the below error compiling pkgng on wandboard. My > > source revision is r262932. > > > > root@wandboard:/usr/home/tom/pkg-1.1 # make > > > > make: "/usr/home/tom/pkg-1.1/Makefile" line 13: warning: Couldn't read > > shell's output for "( which atf-version ) 2>&1 || true" > > > > ===> external (all) > > > > ===> external/sqlite (all) > > > > Warning: Object directory not changed from original > > /usr/home/tom/pkg-1.1/external/sqlite > > > > ===> external/libyaml (all) > > > > Warning: Object directory not changed from original > > /usr/home/tom/pkg-1.1/external/libyaml > > > > ===> libpkg (all) > > > > Warning: Object directory not changed from original > > /usr/home/tom/pkg-1.1/libpkg > > > > ===> pkg (all) > > > > Warning: Object directory not changed from original > > /usr/home/tom/pkg-1.1/pkg > > > > ===> scripts (all) > > > > ===> scripts/periodic (all) > > > > ===> scripts/completion (all) > > > > ===> scripts/sbin (all) > > > > ===> pkg-static (all) > > > > Warning: Object directory not changed from original > > /usr/home/tom/pkg-1.1/pkg-static > > > > cc -O -pipe -I/usr/home/tom/pkg-1.1/pkg-static/../libpkg > > -I/usr/home/tom/pkg-1.1/pkg-static/../external/uthash -std=gnu99 > > -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > -Wshadow > > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > -Wnested-externs > > -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations > > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > > -Wno-unused-const-variable -static -o pkg-static add.o annotate.o > audit.o > > autoremove.o backup.o check.o clean.o convert.o create.o delete.o event.o > > info.o install.o lock.o main.o plugins.o progressmeter.o query.o > register.o > > repo.o rquery.o update.o upgrade.o search.o set.o shlib.o updating.o > > utils.o version.o which.o fetch.o shell.o stats.o ssh.o > > -L/usr/home/tom/pkg-1.1/pkg-static/../libpkg -lpkg -larchive -lutil > > -lpthread -lsbuf -lfetch -lssl -lcrypto -lmd -lz -lbz2 -llzma > > -lbsdxml -L/usr/home/tom/pkg-1.1/pkg-static/../external/sqlite > > -L/usr/home/tom/pkg-1.1/pkg-static/../external/libyaml -lyaml -lsqlite3 > > -larchive -lsbuf -lfetch -lpthread -lelf -lssl -lcrypto -lmd -lz > > -lbz2 -llzma -ledit -lncursesw -ljail > > > > /usr/lib/libarchive.a: could not read symbols: Malformed archive > > > > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > > > > *** Error code 1 > > > > > > Stop. > > > > make[1]: stopped in /usr/home/tom/pkg-1.1/pkg-static > > > > *** Error code 1 > > > > > > Stop. > > > > make: stopped in /usr/home/tom/pkg-1.1 > > If it's like the ports building problems I ran into last week, if you > reboot and build again it'll either work or die in a different place. I > don't really have even a theory yet on what could be wrong, but I've > been fixing everything I can find hoping that it'll just get better. > > I'm running out of things I know are a problem, so if it's not fixed by > all the changes between r262941-950 then I'll have to start hunting > specifically for this problem, which appears to be that sometimes data > read from sdcard is corrupted (but I've yet to see corruption get onto > the card, it seems to be during a read). > > Another problem I've run into in the past couple days is that event > timers just stop running. You see this is an apparent lockup of > anything periodic (such as a top display) or timeout-based, but you can > still enter commands and get responses. Doing "sysctl > kern.eventtimer.periodic=1" appears to work around it. > > -- Ian > > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 02:08:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 332376D6 for ; Mon, 10 Mar 2014 02:08:32 +0000 (UTC) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC4E0209 for ; Mon, 10 Mar 2014 02:08:31 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id va2so6402987obc.38 for ; Sun, 09 Mar 2014 19:08:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Pn+DsoEkzcXPGfSJ/rRifFHoDQ1hNDKwopFsPTEWyHQ=; b=Fsf8oyEvXCEOQCPCGjppNd5bv5LblDouz8tdC0OM/7bJV1mU57n1I6w7OB9fYKTbOU pcZL3oU5BySTkrUltx9dO+2VKUo58sw/j2AgPZre3axWDJ+zV4fKaht0ZgQaXwQOHZVA QwdSy2t2Bfmsdxncvg+3DtWas1DyOlPBoPATlDiT+RLtRxhAkJ1s34FHu5i1HnBtDKzD 7hO71Jqx6GJjydAq2lXwY5evODgqRmJMqtFzgPtcwdNWEHQU3uozO73Hf3RlfSDzV1Gp +TGbJLRSqEbzLgwD+OhYCGCmi3aypKlGSPk0VEa/HhHif/B9PeoCKZJ29RKwBPj/rPkv fKaQ== X-Gm-Message-State: ALoCoQlhg5hEj+e7CbNH1adMObUExDxQSHjvCPtO6uRYmHbkkyeKgDE09C8ffU04v42ajN/8imv1 MIME-Version: 1.0 X-Received: by 10.60.15.131 with SMTP id x3mr22138062oec.15.1394417304891; Sun, 09 Mar 2014 19:08:24 -0700 (PDT) Received: by 10.182.104.169 with HTTP; Sun, 9 Mar 2014 19:08:24 -0700 (PDT) In-Reply-To: References: <1394383937.1149.440.camel@revolution.hippie.lan> Date: Sun, 9 Mar 2014 20:08:24 -0600 Message-ID: Subject: Re: problem compiling pkgng From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 02:08:32 -0000 Ok with 262963, I have a repeatable crash on boot. U-Boot 2013.10 (Mar 09 2014 - 19:41:42) CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: POR Board: Wandboard DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 5 ... 4 ... 3 ... 2 ... 1 ... 0 mmc0 is current device reading boot.scr 157 bytes read in 10 ms (14.6 KiB/s) Running bootscript from mmc ... ## Executing script at 12000000 reading ubldr 253278 bytes read in 28 ms (8.6 MiB/s) ## Starting application at 0x88000054 ... Consoles: U-Boot console Compatible API signature found @8f5756f8 MMC: no card present MMC Device 2 not found MMC Device 3 not found Number of U-Boot devices: 2 FreeBSD/armv6 U-Boot loader, Revision 1.2 (tom@bernice, Sun Mar 9 19:41:36 MDT 2014) DRAM: 2048MB Probing for bootable devices... Bootable device: disk Bootable device: net Current device: disk |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./= .-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.Loading /boot/defaults/loader.conf |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./= .-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./boot/kernel/kernel data=3D0x4dba48+0x2c5b8 /.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-= .\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.= |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./= .-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.= \.|./.-.\.|./.syms=3D[0x4+0x7e640-.\.|./.-.\.|./.-.\.|./.-.\.|./.+0x4+0x4e0= 0f-.\.|./.-.\.|./.-.] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Booting [/boot/kernel/kernel] in 8 seconds... Booting [/boot/kernel/kernel]... \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.Loaded DTB from file 'wandboard-quad.dtb'= . |./.-.\.|./.-.Kernel entry at 0x12000100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #0 r262963: Sun Mar 9 19:35:22 MDT 2014 tom@bernice:/storage/home/tom/crochet/crochet-freebsd/work/obj/arm.armv= 6/storage/home/tom/crochet/src/FreeBSDHead/head/sys/IMX6 arm FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 CPU: Cortex A9-r2 rev 10 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:1 LoUIS:2 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Alloc real memory =3D 2147483648 (2048 MB) avail memory =3D 2093969408 (1996 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random device not loaded; using insecure entropy random: initialized ofwbus0: simplebus0: on ofwbus0 gic0: mem 0xa01000-0xa01fff,0xa00100-0xa001ff on simplebus0 gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b sc->nirqs 160 l2cache0: mem 0xa02000-0xa02fff irq 124 on simplebus0 l2cache0: Part number: 0x3, release: 0x7 l2cache0: L2 Cache: 1024KB/32B 16 ways l2cache0: L2 Cache enabled simplebus1: mem 0x2000000-0x20fffff on simplebus0 ccm0: mem 0x20c4000-0x20c7fff irq 119,120 on simplebus1 imx6_anatop0: mem 0x20c8000-0x20c8fff irq 49 on simplebus1 imx6_anatop0: voltage set to 1225 imx6_anatop0: CPU frequency 984MHz imx_gpt0: mem 0x2098000-0x209bfff irq 87 on simplebus1 Event timer "iMXGPT" frequency 11000000 Hz quality 800 Timecounter "iMXGPT" frequency 11000000 Hz quality 1000 uart0: mem 0x2020000-0x2023fff irq 58 on simplebus1 uart0: console (115200,n,8,1) usbphy0: mem 0x20c9000-0x20c9fff irq 44 on simplebus1 usbphy1: mem 0x20ca000-0x20cafff irq 45 on simplebus1 simplebus2: mem 0x2100000-0x21fffff on simplebus0 ffec0: mem 0x2188000-0x218bfff irq 150,151 on simplebus2 miibus0: on ffec0 atphy0: PHY 1 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ffec0: Ethernet address: 00:1f:7b:b4:06:7f ehci0: mem 0x2184000-0x21841ff irq 75 on simplebus2 ehci0: [GIANT-LOCKED] usbus0: EHCI version 1.0 usbus0 on ehci0 ehci1: mem 0x2184200-0x21843ff irq 72 on simplebus2 ehci1: [GIANT-LOCKED] usbus1: EHCI version 1.0 usbus1 on ehci1 sdhci_imx0: mem 0x2190000-0x2193fff irq 54 on simplebus2 mmc0: on sdhci_imx0 sdhci_imx1: mem 0x2198000-0x219bfff irq 56 on simplebus2 mmc1: on sdhci_imx1 ocotp0: mem 0x21bc000-0x21bffff on simplebus2 Timecounters tick every 4.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus= 0 ugen1.1: at usbus1 uhub1: on usbus= 1 mmc0: No compatible cards found on bus mmcsd0: 16GB at mmc1 50.0MHz/4bit/65535-block random: unblocking device. Release APs Root mount waiting for: usbus1 usbus0 uhub0: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered Spurious interrupt detected [0x000003ff] ugen1.2: at usbus1 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... warning: no time-of-day clock registered, system time will not be set accurately panic: abortdata cpuid =3D 1 KDB: enter: panic [ thread pid 1 tid 100001 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 1 tid 100001 td 0xc6e4c640 db_trace_self() at db_trace_self pc =3D 0xc23d0d00 lr =3D 0xc203eb40 (db_stack_trace+0xf4) sp =3D 0xc50ffa30 fp =3D 0xc50ffa48 r10 =3D 0xc24fbd98 db_stack_trace() at db_stack_trace+0xf4 pc =3D 0xc203eb40 lr =3D 0xc203e4f4 (db_command+0x270) sp =3D 0xc50ffa50 fp =3D 0xc50ffaf0 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000000 db_command() at db_command+0x270 pc =3D 0xc203e4f4 lr =3D 0xc203e258 (db_command_loop+0x60) sp =3D 0xc50ffaf8 fp =3D 0xc50ffb08 r4 =3D 0xc2415698 r5 =3D 0xc24265e4 r6 =3D 0xc24fbd84 r7 =3D 0xc50ffcf0 r8 =3D 0x00000000 r9 =3D 0xc24b09a0 r10 =3D 0xc24f1fb4 db_command_loop() at db_command_loop+0x60 pc =3D 0xc203e258 lr =3D 0xc2040cd8 (db_trap+0xd8) sp =3D 0xc50ffb10 fp =3D 0xc50ffc30 --More-- r4 =3D 0x00000000 r5 =3D 0xc24fbd90 r6 =3D 0xc24f1fe0 db_trap() at db_trap+0xd8 pc =3D 0xc2040cd8 lr =3D 0xc21d82f4 (kdb_trap+0x168) sp =3D 0xc50ffc38 fp =3D 0xc50ffc58 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0xc24f1fe0 r7 =3D 0xc50ffcf0 kdb_trap() at kdb_trap+0x168 pc =3D 0xc21d82f4 lr =3D 0xc23e9710 (undefinedinstruction+0x304) sp =3D 0xc50ffc60 fp =3D 0xc50ffce8 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xc23e935c r7 =3D 0xe7ffffff r8 =3D 0xc6e4c640 r9 =3D 0xc21d7a54 r10 =3D 0xc50ffcf0 undefinedinstruction() at undefinedinstruction+0x304 pc =3D 0xc23e9710 lr =3D 0xc23d2a1c (exception_exit) sp =3D 0xc50ffcf0 fp =3D 0xc50ffd48 r4 =3D 0xc242663e r5 =3D 0xc24e3d10 r6 =3D 0x00000001 r7 =3D 0xc24e3d88 r8 =3D 0xc50ffd7c r9 =3D 0xc24fd8e0 --More-- r10 =3D 0xc6e4c640 exception_exit() at exception_exit pc =3D 0xc23d2a1c lr =3D 0xc21d7a48 (kdb_enter+0x40) sp =3D 0xc50ffd40 fp =3D 0xc50ffd48 r0 =3D 0xc24f1fc4 r1 =3D 0x00000000 r2 =3D 0x00000001 r3 =3D 0x00000001 r4 =3D 0xc242663e r5 =3D 0xc24e3d10 r6 =3D 0x00000001 r7 =3D 0xc24e3d88 r8 =3D 0xc50ffd7c r9 =3D 0xc24fd8e0 r10 =3D 0xc6e4c640 r12 =3D 0x00000000 $a() at $a pc =3D 0xc21d7a58 lr =3D 0xc21967d0 (panic+0x140) sp =3D 0xc50ffd50 fp =3D 0xc50ffd70 r4 =3D 0x00000100 panic() at panic+0x140 pc =3D 0xc21967d0 lr =3D 0xc23d2a1c (exception_exit) sp =3D 0xc50ffd88 fp =3D 0xc50ffe40 r4 =3D 0x00000000 r5 =3D 0xc24fd6e4 r6 =3D 0xc0000000 r7 =3D 0xc24bb434 r8 =3D 0xc50ffe68 r9 =3D 0xc24bb43e --More-- r10 =3D 0xc6e49640 exception_exit() at exception_exit pc =3D 0xc23d2a1c lr =3D 0xc212e3e8 (start_init+0x1c0) sp =3D 0xc50ffdd8 fp =3D 0xc50ffe40 r0 =3D 0xbfffffff r1 =3D 0x00000000 r2 =3D 0xc50ffeb8 r3 =3D 0xc23d2ee8 r4 =3D 0x00000000 r5 =3D 0xc24fd6e4 r6 =3D 0xc0000000 r7 =3D 0xc24bb434 r8 =3D 0xc50ffe68 r9 =3D 0xc24bb43e r10 =3D 0xc6e49640 r12 =3D 0xc6d20ec0 subyte() at subyte+0x14 pc =3D 0xc23d2fac lr =3D 0xc212e3e8 (start_init+0x1c0) sp =3D 0xc50ffdd8 fp =3D 0xc50ffe40 Unwind failure (no registers changed) db> reboot On Sun, Mar 9, 2014 at 5:21 PM, Tom Everett wrote: > After a reboot it did indeed continue on building. I'm building an image > for 262958 now, and I'll try that once it's built. > > > > On Sun, Mar 9, 2014 at 10:52 AM, Ian Lepore wrote: > >> On Sun, 2014-03-09 at 10:16 -0600, Tom Everett wrote: >> > Hello, I'm running into the below error compiling pkgng on wandboard. >> My >> > source revision is r262932. >> > >> > root@wandboard:/usr/home/tom/pkg-1.1 # make >> > >> > make: "/usr/home/tom/pkg-1.1/Makefile" line 13: warning: Couldn't read >> > shell's output for "( which atf-version ) 2>&1 || true" >> > >> > =3D=3D=3D> external (all) >> > >> > =3D=3D=3D> external/sqlite (all) >> > >> > Warning: Object directory not changed from original >> > /usr/home/tom/pkg-1.1/external/sqlite >> > >> > =3D=3D=3D> external/libyaml (all) >> > >> > Warning: Object directory not changed from original >> > /usr/home/tom/pkg-1.1/external/libyaml >> > >> > =3D=3D=3D> libpkg (all) >> > >> > Warning: Object directory not changed from original >> > /usr/home/tom/pkg-1.1/libpkg >> > >> > =3D=3D=3D> pkg (all) >> > >> > Warning: Object directory not changed from original >> > /usr/home/tom/pkg-1.1/pkg >> > >> > =3D=3D=3D> scripts (all) >> > >> > =3D=3D=3D> scripts/periodic (all) >> > >> > =3D=3D=3D> scripts/completion (all) >> > >> > =3D=3D=3D> scripts/sbin (all) >> > >> > =3D=3D=3D> pkg-static (all) >> > >> > Warning: Object directory not changed from original >> > /usr/home/tom/pkg-1.1/pkg-static >> > >> > cc -O -pipe -I/usr/home/tom/pkg-1.1/pkg-static/../libpkg >> > -I/usr/home/tom/pkg-1.1/pkg-static/../external/uthash -std=3Dgnu99 >> > -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W >> > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >> > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch >> -Wshadow >> > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline >> -Wnested-externs >> > -Wredundant-decls -Wold-style-definition -Wmissing-variable-declaratio= ns >> > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int >> > -Wno-unused-const-variable -static -o pkg-static add.o annotate.o >> audit.o >> > autoremove.o backup.o check.o clean.o convert.o create.o delete.o >> event.o >> > info.o install.o lock.o main.o plugins.o progressmeter.o query.o >> register.o >> > repo.o rquery.o update.o upgrade.o search.o set.o shlib.o updating.o >> > utils.o version.o which.o fetch.o shell.o stats.o ssh.o >> > -L/usr/home/tom/pkg-1.1/pkg-static/../libpkg -lpkg -larchive -lutil >> > -lpthread -lsbuf -lfetch -lssl -lcrypto -lmd -lz -lbz2 -llzma >> > -lbsdxml -L/usr/home/tom/pkg-1.1/pkg-static/../external/sqlite >> > -L/usr/home/tom/pkg-1.1/pkg-static/../external/libyaml -lyaml -lsqlit= e3 >> > -larchive -lsbuf -lfetch -lpthread -lelf -lssl -lcrypto -lmd -= lz >> > -lbz2 -llzma -ledit -lncursesw -ljail >> > >> > /usr/lib/libarchive.a: could not read symbols: Malformed archive >> > >> > cc: error: linker command failed with exit code 1 (use -v to see >> invocation) >> > >> > *** Error code 1 >> > >> > >> > Stop. >> > >> > make[1]: stopped in /usr/home/tom/pkg-1.1/pkg-static >> > >> > *** Error code 1 >> > >> > >> > Stop. >> > >> > make: stopped in /usr/home/tom/pkg-1.1 >> >> If it's like the ports building problems I ran into last week, if you >> reboot and build again it'll either work or die in a different place. I >> don't really have even a theory yet on what could be wrong, but I've >> been fixing everything I can find hoping that it'll just get better. >> >> I'm running out of things I know are a problem, so if it's not fixed by >> all the changes between r262941-950 then I'll have to start hunting >> specifically for this problem, which appears to be that sometimes data >> read from sdcard is corrupted (but I've yet to see corruption get onto >> the card, it seems to be during a read). >> >> Another problem I've run into in the past couple days is that event >> timers just stop running. You see this is an apparent lockup of >> anything periodic (such as a top display) or timeout-based, but you can >> still enter commands and get responses. Doing "sysctl >> kern.eventtimer.periodic=3D1" appears to work around it. >> >> -- Ian >> >> >> > > > -- > A better world shall emerge based on faith and understanding - Douglas > MacArthur > --=20 A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 02:23:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A207E88C; Mon, 10 Mar 2014 02:23:25 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6273C345; Mon, 10 Mar 2014 02:23:25 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id lx4so6659109iec.38 for ; Sun, 09 Mar 2014 19:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MSzr53nak0SkSyAcHcV/xQgiE12+jY4dWwP4FIkAd8k=; b=QVo153mNMdqV5Pb4hLYoeopi5aWlSl0Yel3TDjxpycQrROT/rUeBeXCVFMeZeGanl1 kXRMbfHhV9/D/WiaVu3SRTWzK9qKlq2YbV8GtlPue0B/MV7cCoFuKPO1nWiAZAqmhnyZ ro1092JRYVUD1EPyhHg4BHhaqYjKhMitS25de+eLavT1PwVJZAxOsLDRdvq5pSnypqpP qc84vs0f+GVbcLB80b+LWT8ll/p9gxKHzaE8qKGcFBdcLRVhMvR81g0KQB3h0PGOA28m VqzDch96VMzBmYp2Msw6005XXYR8J7EOZ4wmaJE2axDbVAePpCmNk2sArXVRDrE4BRGT CSZw== MIME-Version: 1.0 X-Received: by 10.42.176.131 with SMTP id be3mr25018094icb.2.1394418204754; Sun, 09 Mar 2014 19:23:24 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Sun, 9 Mar 2014 19:23:24 -0700 (PDT) In-Reply-To: References: <1394383937.1149.440.camel@revolution.hippie.lan> Date: Mon, 10 Mar 2014 10:23:24 +0800 Message-ID: Subject: Re: problem compiling pkgng From: Ganbold Tsagaankhuu To: Tom Everett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 02:23:25 -0000 On Mon, Mar 10, 2014 at 10:08 AM, Tom Everett wrote: > Ok with 262963, I have a repeatable crash on boot. > > > > U-Boot 2013.10 (Mar 09 2014 - 19:41:42) > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > Reset cause: POR > Board: Wandboard > DRAM: 2 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > Net: FEC [PRIME] > Hit any key to stop autoboot: 5 ... 4 ... 3 ... 2 ... 1 ... 0 > mmc0 is current device > reading boot.scr > 157 bytes read in 10 ms (14.6 KiB/s) > Running bootscript from mmc ... > ## Executing script at 12000000 > reading ubldr > 253278 bytes read in 28 ms (8.6 MiB/s) > ## Starting application at 0x88000054 ... > Consoles: U-Boot console > > > Compatible API signature found @8f5756f8 > > > MMC: no card present > MMC Device 2 not found > MMC Device 3 not found > Number of U-Boot devices: 2 > > > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > > (tom@bernice, Sun Mar 9 19:41:36 MDT 2014) > > > DRAM: 2048MB > > > Probing for bootable devices... > > > Bootable device: disk > > > Bootable device: net > > > Current device: disk > > > > |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|= ./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.Loading > /boot/defaults/loader.conf > > > > |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|= ./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./boot/kernel/kernel > data=3D0x4dba48+0x2c5b8 > > /.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./= .-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.= \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|= ./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.= -.\.|./.-.\.|./.syms=3D[0x4+0x7e640-.\.|./.-.\.|./.-.\.|./.-.\.|./.+0x4+0x4= e00f-.\.|./.-.\.|./.-.] > > > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > > Booting [/boot/kernel/kernel] in 9 seconds... > Booting [/boot/kernel/kernel] in 8 seconds... > Booting [/boot/kernel/kernel]... > > > \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.Loaded DTB from file > 'wandboard-quad.dtb'. > > > |./.-.\.|./.-.Kernel entry at 0x12000100... > > > Kernel args: (null) > > > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2014 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 11.0-CURRENT #0 r262963: Sun Mar 9 19:35:22 MDT 2014 > tom@bernice > :/storage/home/tom/crochet/crochet-freebsd/work/obj/arm.armv6/storage/hom= e/tom/crochet/src/FreeBSDHead/head/sys/IMX6 > arm > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > CPU: Cortex A9-r2 rev 10 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:1 LoUIS:2 > Cache level 1: > 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc > 32KB/32B 4-way instruction cache Read-Alloc > real memory =3D 2147483648 (2048 MB) > avail memory =3D 2093969408 (1996 MB) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random device not loaded; using insecure entropy > random: initialized > ofwbus0: > simplebus0: on ofwbus0 > gic0: mem > 0xa01000-0xa01fff,0xa00100-0xa001ff on simplebus0 > gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b sc->nirqs 160 > l2cache0: mem 0xa02000-0xa02fff irq 124 on > simplebus0 > l2cache0: Part number: 0x3, release: 0x7 > l2cache0: L2 Cache: 1024KB/32B 16 ways > l2cache0: L2 Cache enabled > simplebus1: mem 0x2000000-0x20fffff on > simplebus0 > ccm0: mem 0x20c4000-0x20c7fff irq > 119,120 on simplebus1 > imx6_anatop0: mem > 0x20c8000-0x20c8fff irq 49 on simplebus1 > imx6_anatop0: voltage set to 1225 > imx6_anatop0: CPU frequency 984MHz > imx_gpt0: mem 0x2098000-0x209bfff irq 87 on > simplebus1 > Event timer "iMXGPT" frequency 11000000 Hz quality 800 > Timecounter "iMXGPT" frequency 11000000 Hz quality 1000 > uart0: mem 0x2020000-0x2023fff irq 58 on simplebus1 > uart0: console (115200,n,8,1) > usbphy0: mem 0x20c9000-0x20c9fff irq 44 on > simplebus1 > usbphy1: mem 0x20ca000-0x20cafff irq 45 on > simplebus1 > simplebus2: mem 0x2100000-0x21fffff on > simplebus0 > ffec0: mem 0x2188000-0x218bfff ir= q > 150,151 on simplebus2 > miibus0: on ffec0 > atphy0: PHY 1 on miibus0 > atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseSX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > ffec0: Ethernet address: 00:1f:7b:b4:06:7f > ehci0: mem 0x2184000-0x21841ff > irq 75 on simplebus2 > ehci0: [GIANT-LOCKED] > usbus0: EHCI version 1.0 > usbus0 on ehci0 > ehci1: mem 0x2184200-0x21843ff > irq 72 on simplebus2 > ehci1: [GIANT-LOCKED] > usbus1: EHCI version 1.0 > usbus1 on ehci1 > sdhci_imx0: mem 0x2190000-0x2193fff irq 54 o= n > simplebus2 > mmc0: on sdhci_imx0 > sdhci_imx1: mem 0x2198000-0x219bfff irq 56 o= n > simplebus2 > mmc1: on sdhci_imx1 > ocotp0: mem > 0x21bc000-0x21bffff on simplebus2 > Timecounters tick every 4.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on > usbus0 > ugen1.1: at usbus1 > uhub1: on > usbus1 > mmc0: No compatible cards found on bus > mmcsd0: 16GB at mmc1 > 50.0MHz/4bit/65535-block > random: unblocking device. > Release APs > Root mount waiting for: usbus1 usbus0 > uhub0: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > Spurious interrupt detected [0x000003ff] > ugen1.2: at usbus1 > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > warning: no time-of-day clock registered, system time will not be set > accurately > panic: abortdata > please update to latest src. ian@ is fixed it in latest rev. Ganbold > cpuid =3D 1 > KDB: enter: panic > [ thread pid 1 tid 100001 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 1 tid 100001 td 0xc6e4c640 > db_trace_self() at db_trace_self > pc =3D 0xc23d0d00 lr =3D 0xc203eb40 (db_stack_trace+0xf4) > sp =3D 0xc50ffa30 fp =3D 0xc50ffa48 > r10 =3D 0xc24fbd98 > db_stack_trace() at db_stack_trace+0xf4 > pc =3D 0xc203eb40 lr =3D 0xc203e4f4 (db_command+0x270) > sp =3D 0xc50ffa50 fp =3D 0xc50ffaf0 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0x00000000 > db_command() at db_command+0x270 > pc =3D 0xc203e4f4 lr =3D 0xc203e258 (db_command_loop+0x60) > sp =3D 0xc50ffaf8 fp =3D 0xc50ffb08 > r4 =3D 0xc2415698 r5 =3D 0xc24265e4 > r6 =3D 0xc24fbd84 r7 =3D 0xc50ffcf0 > r8 =3D 0x00000000 r9 =3D 0xc24b09a0 > r10 =3D 0xc24f1fb4 > db_command_loop() at db_command_loop+0x60 > pc =3D 0xc203e258 lr =3D 0xc2040cd8 (db_trap+0xd8) > sp =3D 0xc50ffb10 fp =3D 0xc50ffc30 > --More-- > > r4 =3D 0x00000000 r5 =3D 0xc24fbd90 > r6 =3D 0xc24f1fe0 > db_trap() at db_trap+0xd8 > pc =3D 0xc2040cd8 lr =3D 0xc21d82f4 (kdb_trap+0x168) > sp =3D 0xc50ffc38 fp =3D 0xc50ffc58 > r4 =3D 0x00000000 r5 =3D 0x00000001 > r6 =3D 0xc24f1fe0 r7 =3D 0xc50ffcf0 > kdb_trap() at kdb_trap+0x168 > pc =3D 0xc21d82f4 lr =3D 0xc23e9710 (undefinedinstruction+0x304= ) > sp =3D 0xc50ffc60 fp =3D 0xc50ffce8 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xc23e935c r7 =3D 0xe7ffffff > r8 =3D 0xc6e4c640 r9 =3D 0xc21d7a54 > r10 =3D 0xc50ffcf0 > undefinedinstruction() at undefinedinstruction+0x304 > pc =3D 0xc23e9710 lr =3D 0xc23d2a1c (exception_exit) > sp =3D 0xc50ffcf0 fp =3D 0xc50ffd48 > r4 =3D 0xc242663e r5 =3D 0xc24e3d10 > r6 =3D 0x00000001 r7 =3D 0xc24e3d88 > r8 =3D 0xc50ffd7c r9 =3D 0xc24fd8e0 > --More-- > > r10 =3D 0xc6e4c640 > exception_exit() at exception_exit > pc =3D 0xc23d2a1c lr =3D 0xc21d7a48 (kdb_enter+0x40) > sp =3D 0xc50ffd40 fp =3D 0xc50ffd48 > r0 =3D 0xc24f1fc4 r1 =3D 0x00000000 > r2 =3D 0x00000001 r3 =3D 0x00000001 > r4 =3D 0xc242663e r5 =3D 0xc24e3d10 > r6 =3D 0x00000001 r7 =3D 0xc24e3d88 > r8 =3D 0xc50ffd7c r9 =3D 0xc24fd8e0 > r10 =3D 0xc6e4c640 r12 =3D 0x00000000 > $a() at $a > pc =3D 0xc21d7a58 lr =3D 0xc21967d0 (panic+0x140) > sp =3D 0xc50ffd50 fp =3D 0xc50ffd70 > r4 =3D 0x00000100 > panic() at panic+0x140 > pc =3D 0xc21967d0 lr =3D 0xc23d2a1c (exception_exit) > sp =3D 0xc50ffd88 fp =3D 0xc50ffe40 > r4 =3D 0x00000000 r5 =3D 0xc24fd6e4 > r6 =3D 0xc0000000 r7 =3D 0xc24bb434 > r8 =3D 0xc50ffe68 r9 =3D 0xc24bb43e > --More-- > > r10 =3D 0xc6e49640 > exception_exit() at exception_exit > pc =3D 0xc23d2a1c lr =3D 0xc212e3e8 (start_init+0x1c0) > sp =3D 0xc50ffdd8 fp =3D 0xc50ffe40 > r0 =3D 0xbfffffff r1 =3D 0x00000000 > r2 =3D 0xc50ffeb8 r3 =3D 0xc23d2ee8 > r4 =3D 0x00000000 r5 =3D 0xc24fd6e4 > r6 =3D 0xc0000000 r7 =3D 0xc24bb434 > r8 =3D 0xc50ffe68 r9 =3D 0xc24bb43e > r10 =3D 0xc6e49640 r12 =3D 0xc6d20ec0 > subyte() at subyte+0x14 > pc =3D 0xc23d2fac lr =3D 0xc212e3e8 (start_init+0x1c0) > sp =3D 0xc50ffdd8 fp =3D 0xc50ffe40 > Unwind failure (no registers changed) > db> reboot > > > > > On Sun, Mar 9, 2014 at 5:21 PM, Tom Everett wrote: > > > After a reboot it did indeed continue on building. I'm building an ima= ge > > for 262958 now, and I'll try that once it's built. > > > > > > > > On Sun, Mar 9, 2014 at 10:52 AM, Ian Lepore wrote: > > > >> On Sun, 2014-03-09 at 10:16 -0600, Tom Everett wrote: > >> > Hello, I'm running into the below error compiling pkgng on wandboard= . > >> My > >> > source revision is r262932. > >> > > >> > root@wandboard:/usr/home/tom/pkg-1.1 # make > >> > > >> > make: "/usr/home/tom/pkg-1.1/Makefile" line 13: warning: Couldn't re= ad > >> > shell's output for "( which atf-version ) 2>&1 || true" > >> > > >> > =3D=3D=3D> external (all) > >> > > >> > =3D=3D=3D> external/sqlite (all) > >> > > >> > Warning: Object directory not changed from original > >> > /usr/home/tom/pkg-1.1/external/sqlite > >> > > >> > =3D=3D=3D> external/libyaml (all) > >> > > >> > Warning: Object directory not changed from original > >> > /usr/home/tom/pkg-1.1/external/libyaml > >> > > >> > =3D=3D=3D> libpkg (all) > >> > > >> > Warning: Object directory not changed from original > >> > /usr/home/tom/pkg-1.1/libpkg > >> > > >> > =3D=3D=3D> pkg (all) > >> > > >> > Warning: Object directory not changed from original > >> > /usr/home/tom/pkg-1.1/pkg > >> > > >> > =3D=3D=3D> scripts (all) > >> > > >> > =3D=3D=3D> scripts/periodic (all) > >> > > >> > =3D=3D=3D> scripts/completion (all) > >> > > >> > =3D=3D=3D> scripts/sbin (all) > >> > > >> > =3D=3D=3D> pkg-static (all) > >> > > >> > Warning: Object directory not changed from original > >> > /usr/home/tom/pkg-1.1/pkg-static > >> > > >> > cc -O -pipe -I/usr/home/tom/pkg-1.1/pkg-static/../libpkg > >> > -I/usr/home/tom/pkg-1.1/pkg-static/../external/uthash -std=3Dgnu99 > >> > -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -= W > >> > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > >> > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > >> -Wshadow > >> > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > >> -Wnested-externs > >> > -Wredundant-decls -Wold-style-definition > -Wmissing-variable-declarations > >> > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > >> > -Wno-unused-const-variable -static -o pkg-static add.o annotate.o > >> audit.o > >> > autoremove.o backup.o check.o clean.o convert.o create.o delete.o > >> event.o > >> > info.o install.o lock.o main.o plugins.o progressmeter.o query.o > >> register.o > >> > repo.o rquery.o update.o upgrade.o search.o set.o shlib.o updating.o > >> > utils.o version.o which.o fetch.o shell.o stats.o ssh.o > >> > -L/usr/home/tom/pkg-1.1/pkg-static/../libpkg -lpkg -larchive -lut= il > >> > -lpthread -lsbuf -lfetch -lssl -lcrypto -lmd -lz -lbz2 -llzm= a > >> > -lbsdxml -L/usr/home/tom/pkg-1.1/pkg-static/../external/sqlite > >> > -L/usr/home/tom/pkg-1.1/pkg-static/../external/libyaml -lyaml > -lsqlite3 > >> > -larchive -lsbuf -lfetch -lpthread -lelf -lssl -lcrypto -lmd > -lz > >> > -lbz2 -llzma -ledit -lncursesw -ljail > >> > > >> > /usr/lib/libarchive.a: could not read symbols: Malformed archive > >> > > >> > cc: error: linker command failed with exit code 1 (use -v to see > >> invocation) > >> > > >> > *** Error code 1 > >> > > >> > > >> > Stop. > >> > > >> > make[1]: stopped in /usr/home/tom/pkg-1.1/pkg-static > >> > > >> > *** Error code 1 > >> > > >> > > >> > Stop. > >> > > >> > make: stopped in /usr/home/tom/pkg-1.1 > >> > >> If it's like the ports building problems I ran into last week, if you > >> reboot and build again it'll either work or die in a different place. = I > >> don't really have even a theory yet on what could be wrong, but I've > >> been fixing everything I can find hoping that it'll just get better. > >> > >> I'm running out of things I know are a problem, so if it's not fixed b= y > >> all the changes between r262941-950 then I'll have to start hunting > >> specifically for this problem, which appears to be that sometimes data > >> read from sdcard is corrupted (but I've yet to see corruption get onto > >> the card, it seems to be during a read). > >> > >> Another problem I've run into in the past couple days is that event > >> timers just stop running. You see this is an apparent lockup of > >> anything periodic (such as a top display) or timeout-based, but you ca= n > >> still enter commands and get responses. Doing "sysctl > >> kern.eventtimer.periodic=3D1" appears to work around it. > >> > >> -- Ian > >> > >> > >> > > > > > > -- > > A better world shall emerge based on faith and understanding - Douglas > > MacArthur > > > > > > -- > A better world shall emerge based on faith and understanding - Douglas > MacArthur > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 02:29:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 077A4906 for ; Mon, 10 Mar 2014 02:29:13 +0000 (UTC) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BEB1C366 for ; Mon, 10 Mar 2014 02:29:12 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n16so6552291oag.27 for ; Sun, 09 Mar 2014 19:29:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7+mWa1tIlCayUJp3YzuMUb519CaMaZbhCflX4EKcVXo=; b=MMEa+BtQFUJPD2BrqzKGy+Xx4lWsHgOxONh42+QEb3Me42hHj4wsUNcqrSvBl6P8LH AD+4k/laWfvTXhEysWbbTjQIKpIofwWyxjVjIAE+wxPJXkSsTs0kSGCHH2sOWe8pBKGR R4QItsAissxe4fF+R2XgvuvU5Tid888+HtgMcbbwKfw0WEv6fLpJw/98aFLmG0QHYlLY 1oE3I0Jv8d+iJg7iscYlvLWAtErUdAOYXznZLtgK3JxcVQEsjfQOA1VDZbRv1fPn4vhH GHS0m4gO6hlYx9c3u9nRHwIYLImh46IjNSDZTnzIfHsNKndYC9hH3TmOjbXnDL1z9q9k AuKw== X-Gm-Message-State: ALoCoQmDiYsU6Gdj0k/QYgFKf+I5GMSUWKKMWkSO9vpPbI8JiOrUzb0+NARUozHnrJmc7/dcSWNf MIME-Version: 1.0 X-Received: by 10.182.117.195 with SMTP id kg3mr26028409obb.17.1394418546208; Sun, 09 Mar 2014 19:29:06 -0700 (PDT) Received: by 10.182.104.169 with HTTP; Sun, 9 Mar 2014 19:29:06 -0700 (PDT) In-Reply-To: References: <1394383937.1149.440.camel@revolution.hippie.lan> Date: Sun, 9 Mar 2014 20:29:06 -0600 Message-ID: Subject: Re: problem compiling pkgng From: Tom Everett To: Ganbold Tsagaankhuu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 02:29:13 -0000 Building 262966 now. On Sun, Mar 9, 2014 at 8:23 PM, Ganbold Tsagaankhuu wrot= e: > > > > On Mon, Mar 10, 2014 at 10:08 AM, Tom Everett wrote: > >> Ok with 262963, I have a repeatable crash on boot. >> >> >> >> U-Boot 2013.10 (Mar 09 2014 - 19:41:42) >> >> CPU: Freescale i.MX6Q rev1.2 at 792 MHz >> Reset cause: POR >> Board: Wandboard >> DRAM: 2 GiB >> MMC: FSL_SDHC: 0, FSL_SDHC: 1 >> *** Warning - bad CRC, using default environment >> >> In: serial >> Out: serial >> Err: serial >> Net: FEC [PRIME] >> Hit any key to stop autoboot: 5 ... 4 ... 3 ... 2 ... 1 ... 0 >> >> mmc0 is current device >> reading boot.scr >> 157 bytes read in 10 ms (14.6 KiB/s) >> Running bootscript from mmc ... >> >> ## Executing script at 12000000 >> reading ubldr >> 253278 bytes read in 28 ms (8.6 MiB/s) >> ## Starting application at 0x88000054 ... >> >> Consoles: U-Boot console >> >> >> Compatible API signature found @8f5756f8 >> >> >> MMC: no card present >> MMC Device 2 not found >> MMC Device 3 not found >> Number of U-Boot devices: 2 >> >> >> >> >> >> FreeBSD/armv6 U-Boot loader, Revision 1.2 >> >> >> (tom@bernice, Sun Mar 9 19:41:36 MDT 2014) >> >> >> DRAM: 2048MB >> >> >> Probing for bootable devices... >> >> >> >> Bootable device: disk >> >> >> Bootable device: net >> >> >> Current device: disk >> >> >> >> |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.= |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.Loading >> /boot/defaults/loader.conf >> >> >> >> |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.= |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./boot/kernel/kernel >> data=3D0x4dba48+0x2c5b8 >> >> /.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|.= /.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-= .\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.= |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./= .-.\.|./.-.\.|./.syms=3D[0x4+0x7e640-.\.|./.-.\.|./.-.\.|./.-.\.|./.+0x4+0x= 4e00f-.\.|./.-.\.|./.-.] >> >> >> >> >> >> Hit [Enter] to boot immediately, or any other key for command prompt. >> >> >> >> Booting [/boot/kernel/kernel] in 9 seconds... >> Booting [/boot/kernel/kernel] in 8 seconds... >> Booting [/boot/kernel/kernel]... >> >> >> >> \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.Loaded DTB from file >> 'wandboard-quad.dtb'. >> >> >> |./.-.\.|./.-.Kernel entry at 0x12000100... >> >> >> >> Kernel args: (null) >> >> >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2014 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 11.0-CURRENT #0 r262963: Sun Mar 9 19:35:22 MDT 2014 >> tom@bernice >> :/storage/home/tom/crochet/crochet-freebsd/work/obj/arm.armv6/storage/ho= me/tom/crochet/src/FreeBSDHead/head/sys/IMX6 >> arm >> FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 >> CPU: Cortex A9-r2 rev 10 (Cortex-A core) >> Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext >> WB disabled EABT branch prediction enabled >> LoUU:2 LoC:1 LoUIS:2 >> Cache level 1: >> 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc >> 32KB/32B 4-way instruction cache Read-Alloc >> real memory =3D 2147483648 (2048 MB) >> avail memory =3D 2093969408 (1996 MB) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> random device not loaded; using insecure entropy >> random: initialized >> ofwbus0: >> simplebus0: on ofwbus0 >> gic0: mem >> 0xa01000-0xa01fff,0xa00100-0xa001ff on simplebus0 >> gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b sc->nirqs 160 >> l2cache0: mem 0xa02000-0xa02fff irq 124 on >> simplebus0 >> l2cache0: Part number: 0x3, release: 0x7 >> l2cache0: L2 Cache: 1024KB/32B 16 ways >> l2cache0: L2 Cache enabled >> simplebus1: mem 0x2000000-0x20fffff o= n >> simplebus0 >> ccm0: mem 0x20c4000-0x20c7fff irq >> 119,120 on simplebus1 >> imx6_anatop0: mem >> 0x20c8000-0x20c8fff irq 49 on simplebus1 >> imx6_anatop0: voltage set to 1225 >> imx6_anatop0: CPU frequency 984MHz >> imx_gpt0: mem 0x2098000-0x209bfff irq 87 on >> simplebus1 >> Event timer "iMXGPT" frequency 11000000 Hz quality 800 >> Timecounter "iMXGPT" frequency 11000000 Hz quality 1000 >> uart0: mem 0x2020000-0x2023fff irq 58 on simplebus1 >> uart0: console (115200,n,8,1) >> usbphy0: mem 0x20c9000-0x20c9fff irq 44 on >> simplebus1 >> usbphy1: mem 0x20ca000-0x20cafff irq 45 on >> simplebus1 >> simplebus2: mem 0x2100000-0x21fffff o= n >> simplebus0 >> ffec0: mem 0x2188000-0x218bfff i= rq >> 150,151 on simplebus2 >> miibus0: on ffec0 >> atphy0: PHY 1 on miibus0 >> atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseSX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto >> ffec0: Ethernet address: 00:1f:7b:b4:06:7f >> ehci0: mem 0x2184000-0x21841f= f >> irq 75 on simplebus2 >> ehci0: [GIANT-LOCKED] >> usbus0: EHCI version 1.0 >> usbus0 on ehci0 >> ehci1: mem 0x2184200-0x21843f= f >> irq 72 on simplebus2 >> ehci1: [GIANT-LOCKED] >> usbus1: EHCI version 1.0 >> usbus1 on ehci1 >> sdhci_imx0: mem 0x2190000-0x2193fff irq 54 = on >> simplebus2 >> mmc0: on sdhci_imx0 >> sdhci_imx1: mem 0x2198000-0x219bfff irq 56 = on >> simplebus2 >> mmc1: on sdhci_imx1 >> ocotp0: mem >> 0x21bc000-0x21bffff on simplebus2 >> Timecounters tick every 4.000 msec >> usbus0: 480Mbps High Speed USB v2.0 >> usbus1: 480Mbps High Speed USB v2.0 >> ugen0.1: at usbus0 >> uhub0: on >> usbus0 >> ugen1.1: at usbus1 >> uhub1: on >> usbus1 >> mmc0: No compatible cards found on bus >> mmcsd0: 16GB at mmc1 >> 50.0MHz/4bit/65535-block >> random: unblocking device. >> Release APs >> Root mount waiting for: usbus1 usbus0 >> uhub0: 1 port with 1 removable, self powered >> uhub1: 1 port with 1 removable, self powered >> Spurious interrupt detected [0x000003ff] >> ugen1.2: at usbus1 >> Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... >> >> warning: no time-of-day clock registered, system time will not be set >> accurately >> panic: abortdata >> > > please update to latest src. > ian@ is fixed it in latest rev. > > Ganbold > > >> cpuid =3D 1 >> KDB: enter: panic >> [ thread pid 1 tid 100001 ] >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >> db> bt >> Tracing pid 1 tid 100001 td 0xc6e4c640 >> db_trace_self() at db_trace_self >> pc =3D 0xc23d0d00 lr =3D 0xc203eb40 (db_stack_trace+0xf4) >> sp =3D 0xc50ffa30 fp =3D 0xc50ffa48 >> r10 =3D 0xc24fbd98 >> db_stack_trace() at db_stack_trace+0xf4 >> pc =3D 0xc203eb40 lr =3D 0xc203e4f4 (db_command+0x270) >> sp =3D 0xc50ffa50 fp =3D 0xc50ffaf0 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0x00000000 >> db_command() at db_command+0x270 >> pc =3D 0xc203e4f4 lr =3D 0xc203e258 (db_command_loop+0x60) >> sp =3D 0xc50ffaf8 fp =3D 0xc50ffb08 >> r4 =3D 0xc2415698 r5 =3D 0xc24265e4 >> r6 =3D 0xc24fbd84 r7 =3D 0xc50ffcf0 >> r8 =3D 0x00000000 r9 =3D 0xc24b09a0 >> r10 =3D 0xc24f1fb4 >> db_command_loop() at db_command_loop+0x60 >> pc =3D 0xc203e258 lr =3D 0xc2040cd8 (db_trap+0xd8) >> sp =3D 0xc50ffb10 fp =3D 0xc50ffc30 >> --More-- >> >> >> r4 =3D 0x00000000 r5 =3D 0xc24fbd90 >> r6 =3D 0xc24f1fe0 >> db_trap() at db_trap+0xd8 >> pc =3D 0xc2040cd8 lr =3D 0xc21d82f4 (kdb_trap+0x168) >> sp =3D 0xc50ffc38 fp =3D 0xc50ffc58 >> r4 =3D 0x00000000 r5 =3D 0x00000001 >> r6 =3D 0xc24f1fe0 r7 =3D 0xc50ffcf0 >> kdb_trap() at kdb_trap+0x168 >> pc =3D 0xc21d82f4 lr =3D 0xc23e9710 (undefinedinstruction+0x30= 4) >> sp =3D 0xc50ffc60 fp =3D 0xc50ffce8 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0xc23e935c r7 =3D 0xe7ffffff >> r8 =3D 0xc6e4c640 r9 =3D 0xc21d7a54 >> r10 =3D 0xc50ffcf0 >> undefinedinstruction() at undefinedinstruction+0x304 >> pc =3D 0xc23e9710 lr =3D 0xc23d2a1c (exception_exit) >> sp =3D 0xc50ffcf0 fp =3D 0xc50ffd48 >> r4 =3D 0xc242663e r5 =3D 0xc24e3d10 >> r6 =3D 0x00000001 r7 =3D 0xc24e3d88 >> r8 =3D 0xc50ffd7c r9 =3D 0xc24fd8e0 >> --More-- >> >> >> r10 =3D 0xc6e4c640 >> exception_exit() at exception_exit >> pc =3D 0xc23d2a1c lr =3D 0xc21d7a48 (kdb_enter+0x40) >> sp =3D 0xc50ffd40 fp =3D 0xc50ffd48 >> r0 =3D 0xc24f1fc4 r1 =3D 0x00000000 >> r2 =3D 0x00000001 r3 =3D 0x00000001 >> r4 =3D 0xc242663e r5 =3D 0xc24e3d10 >> r6 =3D 0x00000001 r7 =3D 0xc24e3d88 >> r8 =3D 0xc50ffd7c r9 =3D 0xc24fd8e0 >> r10 =3D 0xc6e4c640 r12 =3D 0x00000000 >> $a() at $a >> pc =3D 0xc21d7a58 lr =3D 0xc21967d0 (panic+0x140) >> sp =3D 0xc50ffd50 fp =3D 0xc50ffd70 >> r4 =3D 0x00000100 >> panic() at panic+0x140 >> pc =3D 0xc21967d0 lr =3D 0xc23d2a1c (exception_exit) >> sp =3D 0xc50ffd88 fp =3D 0xc50ffe40 >> r4 =3D 0x00000000 r5 =3D 0xc24fd6e4 >> r6 =3D 0xc0000000 r7 =3D 0xc24bb434 >> r8 =3D 0xc50ffe68 r9 =3D 0xc24bb43e >> --More-- >> >> >> r10 =3D 0xc6e49640 >> exception_exit() at exception_exit >> pc =3D 0xc23d2a1c lr =3D 0xc212e3e8 (start_init+0x1c0) >> sp =3D 0xc50ffdd8 fp =3D 0xc50ffe40 >> r0 =3D 0xbfffffff r1 =3D 0x00000000 >> r2 =3D 0xc50ffeb8 r3 =3D 0xc23d2ee8 >> r4 =3D 0x00000000 r5 =3D 0xc24fd6e4 >> r6 =3D 0xc0000000 r7 =3D 0xc24bb434 >> r8 =3D 0xc50ffe68 r9 =3D 0xc24bb43e >> r10 =3D 0xc6e49640 r12 =3D 0xc6d20ec0 >> subyte() at subyte+0x14 >> pc =3D 0xc23d2fac lr =3D 0xc212e3e8 (start_init+0x1c0) >> sp =3D 0xc50ffdd8 fp =3D 0xc50ffe40 >> Unwind failure (no registers changed) >> db> reboot >> >> >> >> >> On Sun, Mar 9, 2014 at 5:21 PM, Tom Everett wrote: >> >> > After a reboot it did indeed continue on building. I'm building an >> image >> > for 262958 now, and I'll try that once it's built. >> > >> > >> > >> > On Sun, Mar 9, 2014 at 10:52 AM, Ian Lepore wrote: >> > >> >> On Sun, 2014-03-09 at 10:16 -0600, Tom Everett wrote: >> >> > Hello, I'm running into the below error compiling pkgng on wandboar= d. >> >> My >> >> > source revision is r262932. >> >> > >> >> > root@wandboard:/usr/home/tom/pkg-1.1 # make >> >> > >> >> > make: "/usr/home/tom/pkg-1.1/Makefile" line 13: warning: Couldn't >> read >> >> > shell's output for "( which atf-version ) 2>&1 || true" >> >> > >> >> > =3D=3D=3D> external (all) >> >> > >> >> > =3D=3D=3D> external/sqlite (all) >> >> > >> >> > Warning: Object directory not changed from original >> >> > /usr/home/tom/pkg-1.1/external/sqlite >> >> > >> >> > =3D=3D=3D> external/libyaml (all) >> >> > >> >> > Warning: Object directory not changed from original >> >> > /usr/home/tom/pkg-1.1/external/libyaml >> >> > >> >> > =3D=3D=3D> libpkg (all) >> >> > >> >> > Warning: Object directory not changed from original >> >> > /usr/home/tom/pkg-1.1/libpkg >> >> > >> >> > =3D=3D=3D> pkg (all) >> >> > >> >> > Warning: Object directory not changed from original >> >> > /usr/home/tom/pkg-1.1/pkg >> >> > >> >> > =3D=3D=3D> scripts (all) >> >> > >> >> > =3D=3D=3D> scripts/periodic (all) >> >> > >> >> > =3D=3D=3D> scripts/completion (all) >> >> > >> >> > =3D=3D=3D> scripts/sbin (all) >> >> > >> >> > =3D=3D=3D> pkg-static (all) >> >> > >> >> > Warning: Object directory not changed from original >> >> > /usr/home/tom/pkg-1.1/pkg-static >> >> > >> >> > cc -O -pipe -I/usr/home/tom/pkg-1.1/pkg-static/../libpkg >> >> > -I/usr/home/tom/pkg-1.1/pkg-static/../external/uthash -std=3Dgnu99 >> >> > -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k = -W >> >> > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >> >> > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch >> >> -Wshadow >> >> > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline >> >> -Wnested-externs >> >> > -Wredundant-decls -Wold-style-definition >> -Wmissing-variable-declarations >> >> > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int >> >> > -Wno-unused-const-variable -static -o pkg-static add.o annotate.o >> >> audit.o >> >> > autoremove.o backup.o check.o clean.o convert.o create.o delete.o >> >> event.o >> >> > info.o install.o lock.o main.o plugins.o progressmeter.o query.o >> >> register.o >> >> > repo.o rquery.o update.o upgrade.o search.o set.o shlib.o updating.= o >> >> > utils.o version.o which.o fetch.o shell.o stats.o ssh.o >> >> > -L/usr/home/tom/pkg-1.1/pkg-static/../libpkg -lpkg -larchive >> -lutil >> >> > -lpthread -lsbuf -lfetch -lssl -lcrypto -lmd -lz -lbz2 -llz= ma >> >> > -lbsdxml -L/usr/home/tom/pkg-1.1/pkg-static/../external/sqlite >> >> > -L/usr/home/tom/pkg-1.1/pkg-static/../external/libyaml -lyaml >> -lsqlite3 >> >> > -larchive -lsbuf -lfetch -lpthread -lelf -lssl -lcrypto -lmd >> -lz >> >> > -lbz2 -llzma -ledit -lncursesw -ljail >> >> > >> >> > /usr/lib/libarchive.a: could not read symbols: Malformed archive >> >> > >> >> > cc: error: linker command failed with exit code 1 (use -v to see >> >> invocation) >> >> > >> >> > *** Error code 1 >> >> > >> >> > >> >> > Stop. >> >> > >> >> > make[1]: stopped in /usr/home/tom/pkg-1.1/pkg-static >> >> > >> >> > *** Error code 1 >> >> > >> >> > >> >> > Stop. >> >> > >> >> > make: stopped in /usr/home/tom/pkg-1.1 >> >> >> >> If it's like the ports building problems I ran into last week, if you >> >> reboot and build again it'll either work or die in a different place. >> I >> >> don't really have even a theory yet on what could be wrong, but I've >> >> been fixing everything I can find hoping that it'll just get better. >> >> >> >> I'm running out of things I know are a problem, so if it's not fixed = by >> >> all the changes between r262941-950 then I'll have to start hunting >> >> specifically for this problem, which appears to be that sometimes dat= a >> >> read from sdcard is corrupted (but I've yet to see corruption get ont= o >> >> the card, it seems to be during a read). >> >> >> >> Another problem I've run into in the past couple days is that event >> >> timers just stop running. You see this is an apparent lockup of >> >> anything periodic (such as a top display) or timeout-based, but you c= an >> >> still enter commands and get responses. Doing "sysctl >> >> kern.eventtimer.periodic=3D1" appears to work around it. >> >> >> >> -- Ian >> >> >> >> >> >> >> > >> > >> > -- >> > A better world shall emerge based on faith and understanding - Dougla= s >> > MacArthur >> > >> >> >> >> -- >> A better world shall emerge based on faith and understanding - Douglas >> MacArthur >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > > --=20 A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 02:39:54 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 818C4C26 for ; Mon, 10 Mar 2014 02:39:54 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 580F561A for ; Mon, 10 Mar 2014 02:39:54 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WMq83-000BDJ-28 for freebsd-arm@FreeBSD.org; Mon, 10 Mar 2014 02:39:47 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2A2dig0058200 for ; Sun, 9 Mar 2014 20:39:44 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18fseYdAvKd7isiVUYub12b Subject: -current broken for arm between r262958 and r262966 From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Sun, 09 Mar 2014 20:39:44 -0600 Message-ID: <1394419184.1149.445.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 02:39:54 -0000 Just a quick heads-up... I broke -current today with r262958 and fixed it again with r262966. Sorry for the inconvenience. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 04:34:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B6D9C14 for ; Mon, 10 Mar 2014 04:34:00 +0000 (UTC) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CFD0FCE for ; Mon, 10 Mar 2014 04:33:59 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n16so6634127oag.27 for ; Sun, 09 Mar 2014 21:33:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZUHh8lj0Hn0eae//AMqOE8UCNKrnl48o5GLU1ElJfgs=; b=M4SjDiorTLAzQA+pfA7soL5thqy22S35XGGgJ3Vq4nRTTcPnGV++hByubeOAGhaFfg GrkC/KLj+RH+Zs8vHm3SPQJOlK43nCDaKTRTHySqSTq6kFS0kNS02a0/Ad5yFC40YFY7 z//0rcMNarzJWiNKG2ZQI+34RMSxwvKyYfDgNFL36pVznnh8HIGEMlcV08p6yQio7frS tNaokMDfJ/nybuGetn41aW6yjOtUukDK9SOTjOSz+2/oNy+ew5QMMU2Qikq2wTbhkomS P8cC/eh4HdCx6JxbBJVRlQP/d+x0/DyE2QyHQ7uPqdw0KO0duDkWNCxxivHgeqslxp5p XC2w== X-Gm-Message-State: ALoCoQnen4ZLKP2iNZcVWKQXFoI8GgSkuujY4tX49Obj7v6D1S2zAfxd4KtDzn/4F1gGYJ/yxugz MIME-Version: 1.0 X-Received: by 10.182.29.98 with SMTP id j2mr26537469obh.30.1394426038907; Sun, 09 Mar 2014 21:33:58 -0700 (PDT) Received: by 10.182.104.169 with HTTP; Sun, 9 Mar 2014 21:33:58 -0700 (PDT) In-Reply-To: References: <1394383937.1149.440.camel@revolution.hippie.lan> Date: Sun, 9 Mar 2014 22:33:58 -0600 Message-ID: Subject: Re: problem compiling pkgng From: Tom Everett To: Ganbold Tsagaankhuu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 04:34:00 -0000 ok with r262966, I get the very same libarchive issue. Also in this case I'm compiling on the tmpfs filesystem, to avoid the possibility that problems with mmc are to blame. cc -O -pipe -I/mnt/tmpfs/pkg-1.1/pkg-static/../libpkg -I/mnt/tmpfs/pkg-1.1/pkg-static/../external/uthash -std=3Dgnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -static -o pkg-static add.o annotate.o audit.o autoremove.o backup.o check.o clean.o convert.o create.o delete.o event.o info.o install.o lock.o main.o plugins.o progressmeter.o query.o register.o repo.o rquery.o update.o upgrade.o search.o set.o shlib.o updating.o utils.o version.o which.o fetch.o shell.o stats.o ssh.o -L/mnt/tmpfs/pkg-1.1/pkg-static/../libpkg -lpkg -larchive -lutil -lpthread -lsbuf -lfetch -lssl -lcrypto -lmd -lz -lbz2 -llzma -lbsdxml -L/mnt/tmpfs/pkg-1.1/pkg-static/../external/sqlite -L/mnt/tmpfs/pkg-1.1/pkg-static/../external/libyaml -lyaml -lsqlite3 -larchive -lsbuf -lfetch -lpthread -lelf -lssl -lcrypto -lmd -lz -lbz2 -llzma -ledit -lncursesw -ljail /usr/lib/libarchive.a: could not read symbols: Malformed archive cc: error: linker command failed with exit code 1 (use -v to see invocation= ) *** Error code 1 Stop. make[1]: stopped in /mnt/tmpfs/pkg-1.1/pkg-static *** Error code 1 Stop. On Sun, Mar 9, 2014 at 8:29 PM, Tom Everett wrote: > Building 262966 now. > > > > On Sun, Mar 9, 2014 at 8:23 PM, Ganbold Tsagaankhuu wr= ote: > >> >> >> >> On Mon, Mar 10, 2014 at 10:08 AM, Tom Everett wrote: >> >>> Ok with 262963, I have a repeatable crash on boot. >>> >>> >>> >>> U-Boot 2013.10 (Mar 09 2014 - 19:41:42) >>> >>> CPU: Freescale i.MX6Q rev1.2 at 792 MHz >>> Reset cause: POR >>> Board: Wandboard >>> DRAM: 2 GiB >>> MMC: FSL_SDHC: 0, FSL_SDHC: 1 >>> *** Warning - bad CRC, using default environment >>> >>> In: serial >>> Out: serial >>> Err: serial >>> Net: FEC [PRIME] >>> Hit any key to stop autoboot: 5 ... 4 ... 3 ... 2 ... 1 ... 0 >>> >>> mmc0 is current device >>> reading boot.scr >>> 157 bytes read in 10 ms (14.6 KiB/s) >>> Running bootscript from mmc ... >>> >>> ## Executing script at 12000000 >>> reading ubldr >>> 253278 bytes read in 28 ms (8.6 MiB/s) >>> ## Starting application at 0x88000054 ... >>> >>> Consoles: U-Boot console >>> >>> >>> Compatible API signature found @8f5756f8 >>> >>> >>> MMC: no card present >>> MMC Device 2 not found >>> MMC Device 3 not found >>> Number of U-Boot devices: 2 >>> >>> >>> >>> >>> >>> FreeBSD/armv6 U-Boot loader, Revision 1.2 >>> >>> >>> (tom@bernice, Sun Mar 9 19:41:36 MDT 2014) >>> >>> >>> DRAM: 2048MB >>> >>> >>> Probing for bootable devices... >>> >>> >>> >>> Bootable device: disk >>> >>> >>> Bootable device: net >>> >>> >>> Current device: disk >>> >>> >>> >>> |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\= .|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.Loading >>> /boot/defaults/loader.conf >>> >>> >>> >>> |./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\= .|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./boot/kernel/kernel >>> data=3D0x4dba48+0x2c5b8 >>> >>> /.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|= ./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.= -.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\= .|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|./.-.\.|.= /.-.\.|./.-.\.|./.syms=3D[0x4+0x7e640-.\.|./.-.\.|./.-.\.|./.-.\.|./.+0x4+0= x4e00f-.\.|./.-.\.|./.-.] >>> >>> >>> >>> >>> >>> Hit [Enter] to boot immediately, or any other key for command prompt. >>> >>> >>> >>> Booting [/boot/kernel/kernel] in 9 seconds... >>> Booting [/boot/kernel/kernel] in 8 seconds... >>> Booting [/boot/kernel/kernel]... >>> >>> >>> >>> \.|./.-.\.|./.-.\.|./.-.\.|./.-.\.Loaded DTB from file >>> 'wandboard-quad.dtb'. >>> >>> >>> |./.-.\.|./.-.Kernel entry at 0x12000100... >>> >>> >>> >>> Kernel args: (null) >>> >>> >>> KDB: debugger backends: ddb >>> KDB: current backend: ddb >>> Copyright (c) 1992-2014 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 >>> The Regents of the University of California. All rights reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 11.0-CURRENT #0 r262963: Sun Mar 9 19:35:22 MDT 2014 >>> tom@bernice >>> :/storage/home/tom/crochet/crochet-freebsd/work/obj/arm.armv6/storage/h= ome/tom/crochet/src/FreeBSDHead/head/sys/IMX6 >>> arm >>> FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 >>> CPU: Cortex A9-r2 rev 10 (Cortex-A core) >>> Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext >>> WB disabled EABT branch prediction enabled >>> LoUU:2 LoC:1 LoUIS:2 >>> Cache level 1: >>> 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc >>> 32KB/32B 4-way instruction cache Read-Alloc >>> real memory =3D 2147483648 (2048 MB) >>> avail memory =3D 2093969408 (1996 MB) >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> random device not loaded; using insecure entropy >>> random: initialized >>> ofwbus0: >>> simplebus0: on ofwbus0 >>> gic0: mem >>> 0xa01000-0xa01fff,0xa00100-0xa001ff on simplebus0 >>> gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b sc->nirqs 160 >>> l2cache0: mem 0xa02000-0xa02fff irq 124 on >>> simplebus0 >>> l2cache0: Part number: 0x3, release: 0x7 >>> l2cache0: L2 Cache: 1024KB/32B 16 ways >>> l2cache0: L2 Cache enabled >>> simplebus1: mem 0x2000000-0x20fffff = on >>> simplebus0 >>> ccm0: mem 0x20c4000-0x20c7fff ir= q >>> 119,120 on simplebus1 >>> imx6_anatop0: mem >>> 0x20c8000-0x20c8fff irq 49 on simplebus1 >>> imx6_anatop0: voltage set to 1225 >>> imx6_anatop0: CPU frequency 984MHz >>> imx_gpt0: mem 0x2098000-0x209bfff irq 87 on >>> simplebus1 >>> Event timer "iMXGPT" frequency 11000000 Hz quality 800 >>> Timecounter "iMXGPT" frequency 11000000 Hz quality 1000 >>> uart0: mem 0x2020000-0x2023fff irq 58 on simplebus1 >>> uart0: console (115200,n,8,1) >>> usbphy0: mem 0x20c9000-0x20c9fff irq 44 on >>> simplebus1 >>> usbphy1: mem 0x20ca000-0x20cafff irq 45 on >>> simplebus1 >>> simplebus2: mem 0x2100000-0x21fffff = on >>> simplebus0 >>> ffec0: mem 0x2188000-0x218bfff >>> irq >>> 150,151 on simplebus2 >>> miibus0: on ffec0 >>> atphy0: PHY 1 on miibus0 >>> atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >>> 1000baseSX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto >>> ffec0: Ethernet address: 00:1f:7b:b4:06:7f >>> ehci0: mem 0x2184000-0x21841= ff >>> irq 75 on simplebus2 >>> ehci0: [GIANT-LOCKED] >>> usbus0: EHCI version 1.0 >>> usbus0 on ehci0 >>> ehci1: mem 0x2184200-0x21843= ff >>> irq 72 on simplebus2 >>> ehci1: [GIANT-LOCKED] >>> usbus1: EHCI version 1.0 >>> usbus1 on ehci1 >>> sdhci_imx0: mem 0x2190000-0x2193fff irq 54 >>> on >>> simplebus2 >>> mmc0: on sdhci_imx0 >>> sdhci_imx1: mem 0x2198000-0x219bfff irq 56 >>> on >>> simplebus2 >>> mmc1: on sdhci_imx1 >>> ocotp0: mem >>> 0x21bc000-0x21bffff on simplebus2 >>> Timecounters tick every 4.000 msec >>> usbus0: 480Mbps High Speed USB v2.0 >>> usbus1: 480Mbps High Speed USB v2.0 >>> ugen0.1: at usbus0 >>> uhub0: on >>> usbus0 >>> ugen1.1: at usbus1 >>> uhub1: on >>> usbus1 >>> mmc0: No compatible cards found on bus >>> mmcsd0: 16GB at mmc1 >>> 50.0MHz/4bit/65535-block >>> random: unblocking device. >>> Release APs >>> Root mount waiting for: usbus1 usbus0 >>> uhub0: 1 port with 1 removable, self powered >>> uhub1: 1 port with 1 removable, self powered >>> Spurious interrupt detected [0x000003ff] >>> ugen1.2: at usbus1 >>> Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... >>> >>> warning: no time-of-day clock registered, system time will not be set >>> accurately >>> panic: abortdata >>> >> >> please update to latest src. >> ian@ is fixed it in latest rev. >> >> Ganbold >> >> >>> cpuid =3D 1 >>> KDB: enter: panic >>> [ thread pid 1 tid 100001 ] >>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>> db> bt >>> Tracing pid 1 tid 100001 td 0xc6e4c640 >>> db_trace_self() at db_trace_self >>> pc =3D 0xc23d0d00 lr =3D 0xc203eb40 (db_stack_trace+0xf4) >>> sp =3D 0xc50ffa30 fp =3D 0xc50ffa48 >>> r10 =3D 0xc24fbd98 >>> db_stack_trace() at db_stack_trace+0xf4 >>> pc =3D 0xc203eb40 lr =3D 0xc203e4f4 (db_command+0x270) >>> sp =3D 0xc50ffa50 fp =3D 0xc50ffaf0 >>> r4 =3D 0x00000000 r5 =3D 0x00000000 >>> r6 =3D 0x00000000 >>> db_command() at db_command+0x270 >>> pc =3D 0xc203e4f4 lr =3D 0xc203e258 (db_command_loop+0x60) >>> sp =3D 0xc50ffaf8 fp =3D 0xc50ffb08 >>> r4 =3D 0xc2415698 r5 =3D 0xc24265e4 >>> r6 =3D 0xc24fbd84 r7 =3D 0xc50ffcf0 >>> r8 =3D 0x00000000 r9 =3D 0xc24b09a0 >>> r10 =3D 0xc24f1fb4 >>> db_command_loop() at db_command_loop+0x60 >>> pc =3D 0xc203e258 lr =3D 0xc2040cd8 (db_trap+0xd8) >>> sp =3D 0xc50ffb10 fp =3D 0xc50ffc30 >>> --More-- >>> >>> >>> r4 =3D 0x00000000 r5 =3D 0xc24fbd90 >>> r6 =3D 0xc24f1fe0 >>> db_trap() at db_trap+0xd8 >>> pc =3D 0xc2040cd8 lr =3D 0xc21d82f4 (kdb_trap+0x168) >>> sp =3D 0xc50ffc38 fp =3D 0xc50ffc58 >>> r4 =3D 0x00000000 r5 =3D 0x00000001 >>> r6 =3D 0xc24f1fe0 r7 =3D 0xc50ffcf0 >>> kdb_trap() at kdb_trap+0x168 >>> pc =3D 0xc21d82f4 lr =3D 0xc23e9710 (undefinedinstruction+0x3= 04) >>> sp =3D 0xc50ffc60 fp =3D 0xc50ffce8 >>> r4 =3D 0x00000000 r5 =3D 0x00000000 >>> r6 =3D 0xc23e935c r7 =3D 0xe7ffffff >>> r8 =3D 0xc6e4c640 r9 =3D 0xc21d7a54 >>> r10 =3D 0xc50ffcf0 >>> undefinedinstruction() at undefinedinstruction+0x304 >>> pc =3D 0xc23e9710 lr =3D 0xc23d2a1c (exception_exit) >>> sp =3D 0xc50ffcf0 fp =3D 0xc50ffd48 >>> r4 =3D 0xc242663e r5 =3D 0xc24e3d10 >>> r6 =3D 0x00000001 r7 =3D 0xc24e3d88 >>> r8 =3D 0xc50ffd7c r9 =3D 0xc24fd8e0 >>> --More-- >>> >>> >>> r10 =3D 0xc6e4c640 >>> exception_exit() at exception_exit >>> pc =3D 0xc23d2a1c lr =3D 0xc21d7a48 (kdb_enter+0x40) >>> sp =3D 0xc50ffd40 fp =3D 0xc50ffd48 >>> r0 =3D 0xc24f1fc4 r1 =3D 0x00000000 >>> r2 =3D 0x00000001 r3 =3D 0x00000001 >>> r4 =3D 0xc242663e r5 =3D 0xc24e3d10 >>> r6 =3D 0x00000001 r7 =3D 0xc24e3d88 >>> r8 =3D 0xc50ffd7c r9 =3D 0xc24fd8e0 >>> r10 =3D 0xc6e4c640 r12 =3D 0x00000000 >>> $a() at $a >>> pc =3D 0xc21d7a58 lr =3D 0xc21967d0 (panic+0x140) >>> sp =3D 0xc50ffd50 fp =3D 0xc50ffd70 >>> r4 =3D 0x00000100 >>> panic() at panic+0x140 >>> pc =3D 0xc21967d0 lr =3D 0xc23d2a1c (exception_exit) >>> sp =3D 0xc50ffd88 fp =3D 0xc50ffe40 >>> r4 =3D 0x00000000 r5 =3D 0xc24fd6e4 >>> r6 =3D 0xc0000000 r7 =3D 0xc24bb434 >>> r8 =3D 0xc50ffe68 r9 =3D 0xc24bb43e >>> --More-- >>> >>> >>> r10 =3D 0xc6e49640 >>> exception_exit() at exception_exit >>> pc =3D 0xc23d2a1c lr =3D 0xc212e3e8 (start_init+0x1c0) >>> sp =3D 0xc50ffdd8 fp =3D 0xc50ffe40 >>> r0 =3D 0xbfffffff r1 =3D 0x00000000 >>> r2 =3D 0xc50ffeb8 r3 =3D 0xc23d2ee8 >>> r4 =3D 0x00000000 r5 =3D 0xc24fd6e4 >>> r6 =3D 0xc0000000 r7 =3D 0xc24bb434 >>> r8 =3D 0xc50ffe68 r9 =3D 0xc24bb43e >>> r10 =3D 0xc6e49640 r12 =3D 0xc6d20ec0 >>> subyte() at subyte+0x14 >>> pc =3D 0xc23d2fac lr =3D 0xc212e3e8 (start_init+0x1c0) >>> sp =3D 0xc50ffdd8 fp =3D 0xc50ffe40 >>> Unwind failure (no registers changed) >>> db> reboot >>> >>> >>> >>> >>> On Sun, Mar 9, 2014 at 5:21 PM, Tom Everett wrote: >>> >>> > After a reboot it did indeed continue on building. I'm building an >>> image >>> > for 262958 now, and I'll try that once it's built. >>> > >>> > >>> > >>> > On Sun, Mar 9, 2014 at 10:52 AM, Ian Lepore wrote: >>> > >>> >> On Sun, 2014-03-09 at 10:16 -0600, Tom Everett wrote: >>> >> > Hello, I'm running into the below error compiling pkgng on >>> wandboard. >>> >> My >>> >> > source revision is r262932. >>> >> > >>> >> > root@wandboard:/usr/home/tom/pkg-1.1 # make >>> >> > >>> >> > make: "/usr/home/tom/pkg-1.1/Makefile" line 13: warning: Couldn't >>> read >>> >> > shell's output for "( which atf-version ) 2>&1 || true" >>> >> > >>> >> > =3D=3D=3D> external (all) >>> >> > >>> >> > =3D=3D=3D> external/sqlite (all) >>> >> > >>> >> > Warning: Object directory not changed from original >>> >> > /usr/home/tom/pkg-1.1/external/sqlite >>> >> > >>> >> > =3D=3D=3D> external/libyaml (all) >>> >> > >>> >> > Warning: Object directory not changed from original >>> >> > /usr/home/tom/pkg-1.1/external/libyaml >>> >> > >>> >> > =3D=3D=3D> libpkg (all) >>> >> > >>> >> > Warning: Object directory not changed from original >>> >> > /usr/home/tom/pkg-1.1/libpkg >>> >> > >>> >> > =3D=3D=3D> pkg (all) >>> >> > >>> >> > Warning: Object directory not changed from original >>> >> > /usr/home/tom/pkg-1.1/pkg >>> >> > >>> >> > =3D=3D=3D> scripts (all) >>> >> > >>> >> > =3D=3D=3D> scripts/periodic (all) >>> >> > >>> >> > =3D=3D=3D> scripts/completion (all) >>> >> > >>> >> > =3D=3D=3D> scripts/sbin (all) >>> >> > >>> >> > =3D=3D=3D> pkg-static (all) >>> >> > >>> >> > Warning: Object directory not changed from original >>> >> > /usr/home/tom/pkg-1.1/pkg-static >>> >> > >>> >> > cc -O -pipe -I/usr/home/tom/pkg-1.1/pkg-static/../libpkg >>> >> > -I/usr/home/tom/pkg-1.1/pkg-static/../external/uthash -std=3Dgnu99 >>> >> > -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k >>> -W >>> >> > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >>> >> > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch >>> >> -Wshadow >>> >> > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline >>> >> -Wnested-externs >>> >> > -Wredundant-decls -Wold-style-definition >>> -Wmissing-variable-declarations >>> >> > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int >>> >> > -Wno-unused-const-variable -static -o pkg-static add.o annotate.o >>> >> audit.o >>> >> > autoremove.o backup.o check.o clean.o convert.o create.o delete.o >>> >> event.o >>> >> > info.o install.o lock.o main.o plugins.o progressmeter.o query.o >>> >> register.o >>> >> > repo.o rquery.o update.o upgrade.o search.o set.o shlib.o updating= .o >>> >> > utils.o version.o which.o fetch.o shell.o stats.o ssh.o >>> >> > -L/usr/home/tom/pkg-1.1/pkg-static/../libpkg -lpkg -larchive >>> -lutil >>> >> > -lpthread -lsbuf -lfetch -lssl -lcrypto -lmd -lz -lbz2 >>> -llzma >>> >> > -lbsdxml -L/usr/home/tom/pkg-1.1/pkg-static/../external/sqlite >>> >> > -L/usr/home/tom/pkg-1.1/pkg-static/../external/libyaml -lyaml >>> -lsqlite3 >>> >> > -larchive -lsbuf -lfetch -lpthread -lelf -lssl -lcrypto -lm= d >>> -lz >>> >> > -lbz2 -llzma -ledit -lncursesw -ljail >>> >> > >>> >> > /usr/lib/libarchive.a: could not read symbols: Malformed archive >>> >> > >>> >> > cc: error: linker command failed with exit code 1 (use -v to see >>> >> invocation) >>> >> > >>> >> > *** Error code 1 >>> >> > >>> >> > >>> >> > Stop. >>> >> > >>> >> > make[1]: stopped in /usr/home/tom/pkg-1.1/pkg-static >>> >> > >>> >> > *** Error code 1 >>> >> > >>> >> > >>> >> > Stop. >>> >> > >>> >> > make: stopped in /usr/home/tom/pkg-1.1 >>> >> >>> >> If it's like the ports building problems I ran into last week, if yo= u >>> >> reboot and build again it'll either work or die in a different place= . >>> I >>> >> don't really have even a theory yet on what could be wrong, but I've >>> >> been fixing everything I can find hoping that it'll just get better. >>> >> >>> >> I'm running out of things I know are a problem, so if it's not fixed >>> by >>> >> all the changes between r262941-950 then I'll have to start hunting >>> >> specifically for this problem, which appears to be that sometimes da= ta >>> >> read from sdcard is corrupted (but I've yet to see corruption get on= to >>> >> the card, it seems to be during a read). >>> >> >>> >> Another problem I've run into in the past couple days is that event >>> >> timers just stop running. You see this is an apparent lockup of >>> >> anything periodic (such as a top display) or timeout-based, but you >>> can >>> >> still enter commands and get responses. Doing "sysctl >>> >> kern.eventtimer.periodic=3D1" appears to work around it. >>> >> >>> >> -- Ian >>> >> >>> >> >>> >> >>> > >>> > >>> > -- >>> > A better world shall emerge based on faith and understanding - Dougl= as >>> > MacArthur >>> > >>> >>> >>> >>> -- >>> A better world shall emerge based on faith and understanding - Douglas >>> MacArthur >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >>> >> >> > > > -- > A better world shall emerge based on faith and understanding - Douglas > MacArthur > --=20 A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 11:06:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1C76FE5 for ; Mon, 10 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C26E27FE for ; Mon, 10 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2AB6f9L043123 for ; Mon, 10 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2AB6f7W043121 for freebsd-arm@FreeBSD.org; Mon, 10 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Mar 2014 11:06:41 GMT Message-Id: <201403101106.s2AB6f7W043121@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 11:06:42 -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/187223 arm omap4 clock frequency computation overflow o arm/186823 arm icu port won't compile on Raspberry Pi o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o ports/175605 arm please fix build binutils-2.23.1 in raspberry pi 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 ports/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) 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 33 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 14:59:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE753C42 for ; Mon, 10 Mar 2014 14:59:14 +0000 (UTC) Received: from mail.sloane.cz (zimbra2.cust.sloane.cz [77.48.244.12]) by mx1.freebsd.org (Postfix) with ESMTP id 7F78D2AD for ; Mon, 10 Mar 2014 14:59:13 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sloane.cz (Postfix) with ESMTP id 6DDDDCA4020 for ; Mon, 10 Mar 2014 15:50:47 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sloane.cz Received: from mail.sloane.cz ([127.0.0.1]) by localhost (mail.sloane.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FADpEQNe-K2z for ; Mon, 10 Mar 2014 15:50:46 +0100 (CET) Received: from [10.255.255.136] (ip-86-49-134-206.net.upcbroadband.cz [86.49.134.206]) by mail.sloane.cz (Postfix) with ESMTPSA id A6569CA4017 for ; Mon, 10 Mar 2014 15:50:46 +0100 (CET) From: Miroslav Chlastak Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: ARM platform for network router Message-Id: Date: Mon, 10 Mar 2014 15:50:31 +0100 To: freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 14:59:14 -0000 Hello, is there any box like =E2=80=9Calix/wrap boards=E2=80=9D, that can be = uset as router with ARM CPU? We are looking for a new platform with more = power instead of Alix board. But every i386 platform is too expensive = (when comparing to eg. routerboard). --=20 Miroslav Chlastak AntHill s.r.o. | http://www.anthill.cz mobil: +420 777 898 383 hotline: +420 246 024 246 From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 15:05:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25DB6F75 for ; Mon, 10 Mar 2014 15:05:28 +0000 (UTC) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E02C237B for ; Mon, 10 Mar 2014 15:05:27 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i4so7162341oah.29 for ; Mon, 10 Mar 2014 08:05:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yB/EcKPc727Yy/QwWsFd3iQjFOeY0kNq+OlvnwMR48o=; b=EYZTsL4ChDV29Q7CHtgqODstpps0KRb6/gNWrqAUiGvFYU4u2UsuZ4AYYs4iA3tItP AXewioJ0Wl7fsqnokAHuHyh2ONxsfbOVvZJUSqdVvG3cTsrVlanfpOA+Pv9W+1tmiPaY 1IeXSmJhQzBv59Dp5NSnnSTeg+HYZb/iXaKdYrYuNGM8zQcG6PdvgNJ0LCZEEjetD1Y1 6U6U74r+c9DXKNEMcpZesK/IOmQOpkdRKhyQfDnuV3fkQrBIbmh38rZlabGvtqspuCYI OoO8E/f2XNkL3LsjhOVOWjHrb1cxs/NwNO92peFAPMM9eeo6NySxtvPdwfRmyYU2c+kD /BRQ== X-Gm-Message-State: ALoCoQngVzqgQNFeoqUBtK+NERBNi9aBd+kI5+McitmZU53YFuy8Lifgse/603lR4c46NK60AEQh MIME-Version: 1.0 X-Received: by 10.182.47.100 with SMTP id c4mr29118863obn.38.1394463926684; Mon, 10 Mar 2014 08:05:26 -0700 (PDT) Received: by 10.182.104.169 with HTTP; Mon, 10 Mar 2014 08:05:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Mar 2014 09:05:26 -0600 Message-ID: Subject: Re: ARM platform for network router From: Tom Everett To: Miroslav Chlastak Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 15:05:28 -0000 I've been experimenting with using a Wandboard with a USB wifi stick as a wireless router. The wandboard does have Wifi onboard, but it's currently not supported by FreeBSD. I can say, however, that my experience with the Wandboard has been quite positive. The price point is about the same as Alix, however. On Mon, Mar 10, 2014 at 8:50 AM, Miroslav Chlastak < miroslav.chlastak@anthill.cz> wrote: > Hello, > > is there any box like "alix/wrap boards", that can be uset as router with > ARM CPU? We are looking for a new platform with more power instead of Alix > board. But every i386 platform is too expensive (when comparing to eg. > routerboard). > > -- > Miroslav Chlastak > AntHill s.r.o. | http://www.anthill.cz > > mobil: +420 777 898 383 > hotline: +420 246 024 246 > > > > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 15:43:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4659F60; Mon, 10 Mar 2014 15:43:52 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B7199AD; Mon, 10 Mar 2014 15:43:52 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D3814B926; Mon, 10 Mar 2014 11:43:48 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: option NEW_PCIB Date: Mon, 10 Mar 2014 09:45:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1394200335.1149.370.camel@revolution.hippie.lan> <58AB4C66-4267-414D-80D4-B97FF86A94A5@bsdimp.com> In-Reply-To: <58AB4C66-4267-414D-80D4-B97FF86A94A5@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201403100945.20298.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 10 Mar 2014 11:43:48 -0400 (EDT) Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 15:43:52 -0000 On Friday, March 07, 2014 9:38:33 am Warner Losh wrote: >=20 > On Mar 7, 2014, at 6:52 AM, Ian Lepore wrote: >=20 > > Every architecture has "option NEW_PCIB" in its conf/DEFAULTS except arm > > and mips. Is that on purpose? What are the implications of adding it? > > Or maybe more importantly, what are the implications of it not being > > there? >=20 > This is John Baldwin=92s option for his reworked PCI bridge code. He did = that as > a fallback in case he really messed up something. It introduces renumberi= ng > of busses that don=92t already have numbers assigned. It should be enable= d on > ARM, but the required resource isn=92t defined on arm, and some of the ot= her > required glue doesn=92t seem to be implemented for arm yet, which is why = things > are the way they are at the moment. I think John intends for the option t= o go > away, and everything it covers will be =91standard=92. Yes. I just added a page on the wiki about NEW_PCIB explaining the changes each platform needs for it in a bit more detail on Friday: https://wiki.freebsd.org/NEW_PCIB I have posted patches in the past to arm@ to handle step 2 in the NEW_PCIB base requirements for arm@ but haven't been able to get folks to test them. I just recently made a new pass through sys/arm in a p4 tree to refresh thi= s. I haven't even compiled these yet, but you can find the patch here: http://people.freebsd.org/~jhb/patches/arm_activate2.patch I don't know how best to think about fixing i80321_pci to work with NEW_PCI= B. It has some hack that I don't fully understand. I think it uses an alternate mapping of the same resource range to use a different base address for the mapping. Longer term I think the bus_map_resource() think I suggest at the bottom is how to handle that, but even then there would still need to be a way to know which base address a given resource wanted to use. It may be that we need to implement that differently (bus-specific rman flag?) =2D-=20 John Baldwin From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 16:20:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91294F7D for ; Mon, 10 Mar 2014 16:20:11 +0000 (UTC) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 639BBCF8 for ; Mon, 10 Mar 2014 16:20:11 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id r10so7241475pdi.21 for ; Mon, 10 Mar 2014 09:20:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=y3de8dFHuByGitLfgxttDdBSNrutbxKFQEbGTTC6OBY=; b=HmxqfVqZIgdbDrjfBOYnXzVgVle1PzM1sQOBIGHWxkj5+N80w6TOLDMRTiiF2UCqQR U+xvyLv/RPhc3Rw7QnUvCU5ZyxT+/WYGzs4W32fTaKXxM8pESR4G6Xr5WOFbVodR83dE r6fzp/hq1lbhKoHI/oQchMZCiMf4LqCHzEatklngFu87LUqTEVUl3K1TxjtrBc/LUFrf t6s6YBjcqFUmmOE7od90vJWc4/pDZZSjGvbwsALdC0R8M/v0pYsTHzZiryVZAaNiZB0c rU+joDgGBGrPXKwviaInfg87YRkM/Kn28FeJBdA+hwIQbW6+27WyY48y+qS1CAeh92fo Qs+A== X-Gm-Message-State: ALoCoQnaAQKdmxfLMZnSCVQ5Edbi2FEgv586UCR0p98H2IVNiWb7pe+NnySQvDAQHEbzi1VTlJ8v X-Received: by 10.68.229.106 with SMTP id sp10mr41460628pbc.23.1394468404764; Mon, 10 Mar 2014 09:20:04 -0700 (PDT) Received: from [10.64.26.252] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id bc4sm65919122pbb.2.2014.03.10.09.20.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 09:20:04 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: option NEW_PCIB From: Warner Losh In-Reply-To: <201403100945.20298.jhb@freebsd.org> Date: Mon, 10 Mar 2014 10:20:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <51AC226F-7516-48EA-BC9D-B67F6508BCBF@bsdimp.com> References: <1394200335.1149.370.camel@revolution.hippie.lan> <58AB4C66-4267-414D-80D4-B97FF86A94A5@bsdimp.com> <201403100945.20298.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm , Ian Lepore , freebsd-arch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:20:11 -0000 On Mar 10, 2014, at 7:45 AM, John Baldwin wrote: > On Friday, March 07, 2014 9:38:33 am Warner Losh wrote: >>=20 >> On Mar 7, 2014, at 6:52 AM, Ian Lepore wrote: >>=20 >>> Every architecture has "option NEW_PCIB" in its conf/DEFAULTS except = arm >>> and mips. Is that on purpose? What are the implications of adding = it? >>> Or maybe more importantly, what are the implications of it not being >>> there? >>=20 >> This is John Baldwin=92s option for his reworked PCI bridge code. He = did that as >> a fallback in case he really messed up something. It introduces = renumbering >> of busses that don=92t already have numbers assigned. It should be = enabled on >> ARM, but the required resource isn=92t defined on arm, and some of = the other >> required glue doesn=92t seem to be implemented for arm yet, which is = why things >> are the way they are at the moment. I think John intends for the = option to go >> away, and everything it covers will be =91standard=92. >=20 > Yes. I just added a page on the wiki about NEW_PCIB explaining the = changes > each platform needs for it in a bit more detail on Friday: >=20 > https://wiki.freebsd.org/NEW_PCIB >=20 > I have posted patches in the past to arm@ to handle step 2 in the = NEW_PCIB > base requirements for arm@ but haven't been able to get folks to test = them. > I just recently made a new pass through sys/arm in a p4 tree to = refresh this. > I haven't even compiled these yet, but you can find the patch here: >=20 > http://people.freebsd.org/~jhb/patches/arm_activate2.patch I=92ll take a look=85 Thanks for putting these together... > I don't know how best to think about fixing i80321_pci to work with = NEW_PCIB. > It has some hack that I don't fully understand. I think it uses an > alternate mapping of the same resource range to use a different base = address > for the mapping. Longer term I think the bus_map_resource() think I = suggest > at the bottom is how to handle that, but even then there would still = need to > be a way to know which base address a given resource wanted to use. = It may > be that we need to implement that differently (bus-specific rman = flag?) While I=92m not normally a big fan of retiring code, I think in this = case it may be easier to just retire the i80321 support. It is really old, released in 2002. = There=92s not too many boards that had this on it, and I think all the ones that ever ran = FreeBSD are in cognet@=91s lab. On the whole, it is yet another machine to update that slows down = any modernization processes we have... Warner From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 17:52:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3676E490; Mon, 10 Mar 2014 17:52:57 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CECD29A7; Mon, 10 Mar 2014 17:52:56 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2AHqnIY071921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2014 10:52:50 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2AHqn1u071920; Mon, 10 Mar 2014 10:52:49 -0700 (PDT) (envelope-from jmg) Date: Mon, 10 Mar 2014 10:52:49 -0700 From: John-Mark Gurney To: John Baldwin Subject: Re: option NEW_PCIB Message-ID: <20140310175249.GH32089@funkthat.com> Mail-Followup-To: John Baldwin , freebsd-arch@freebsd.org, freebsd-arm , Ian Lepore References: <1394200335.1149.370.camel@revolution.hippie.lan> <58AB4C66-4267-414D-80D4-B97FF86A94A5@bsdimp.com> <201403100945.20298.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201403100945.20298.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 10 Mar 2014 10:52:50 -0700 (PDT) Cc: freebsd-arm , Ian Lepore , freebsd-arch@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:52:57 -0000 John Baldwin wrote this message on Mon, Mar 10, 2014 at 09:45 -0400: > On Friday, March 07, 2014 9:38:33 am Warner Losh wrote: > > > > On Mar 7, 2014, at 6:52 AM, Ian Lepore wrote: > > > > > Every architecture has "option NEW_PCIB" in its conf/DEFAULTS except arm > > > and mips. Is that on purpose? What are the implications of adding it? > > > Or maybe more importantly, what are the implications of it not being > > > there? > > > > This is John Baldwin?s option for his reworked PCI bridge code. He did that as > > a fallback in case he really messed up something. It introduces renumbering > > of busses that don?t already have numbers assigned. It should be enabled on > > ARM, but the required resource isn?t defined on arm, and some of the other > > required glue doesn?t seem to be implemented for arm yet, which is why things > > are the way they are at the moment. I think John intends for the option to go > > away, and everything it covers will be ?standard?. > > Yes. I just added a page on the wiki about NEW_PCIB explaining the changes > each platform needs for it in a bit more detail on Friday: > > https://wiki.freebsd.org/NEW_PCIB > > I have posted patches in the past to arm@ to handle step 2 in the NEW_PCIB > base requirements for arm@ but haven't been able to get folks to test them. > I just recently made a new pass through sys/arm in a p4 tree to refresh this. > I haven't even compiled these yet, but you can find the patch here: > > http://people.freebsd.org/~jhb/patches/arm_activate2.patch Do you need a fully work system, or is booting fine? If you need a fully working system, then I need some help figure out my panic.. I sent email to alc and kib a few days ago about it, but I haven't heard anything back.. it's a problem w/ vm_page... If booting is fine, I can test on my AVILA board I have now.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 19:01:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA1D1E39; Mon, 10 Mar 2014 19:01:55 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E2089B; Mon, 10 Mar 2014 19:01:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2E41AB9A0; Mon, 10 Mar 2014 15:01:53 -0400 (EDT) From: John Baldwin To: "John-Mark Gurney" Subject: Re: option NEW_PCIB Date: Mon, 10 Mar 2014 14:20:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1394200335.1149.370.camel@revolution.hippie.lan> <201403100945.20298.jhb@freebsd.org> <20140310175249.GH32089@funkthat.com> In-Reply-To: <20140310175249.GH32089@funkthat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403101420.16117.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 10 Mar 2014 15:01:53 -0400 (EDT) Cc: freebsd-arm , Ian Lepore , freebsd-arch@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:01:55 -0000 On Monday, March 10, 2014 1:52:49 pm John-Mark Gurney wrote: > John Baldwin wrote this message on Mon, Mar 10, 2014 at 09:45 -0400: > > On Friday, March 07, 2014 9:38:33 am Warner Losh wrote: > > > > > > On Mar 7, 2014, at 6:52 AM, Ian Lepore wrote: > > > > > > > Every architecture has "option NEW_PCIB" in its conf/DEFAULTS except arm > > > > and mips. Is that on purpose? What are the implications of adding it? > > > > Or maybe more importantly, what are the implications of it not being > > > > there? > > > > > > This is John Baldwin?s option for his reworked PCI bridge code. He did that as > > > a fallback in case he really messed up something. It introduces renumbering > > > of busses that don?t already have numbers assigned. It should be enabled on > > > ARM, but the required resource isn?t defined on arm, and some of the other > > > required glue doesn?t seem to be implemented for arm yet, which is why things > > > are the way they are at the moment. I think John intends for the option to go > > > away, and everything it covers will be ?standard?. > > > > Yes. I just added a page on the wiki about NEW_PCIB explaining the changes > > each platform needs for it in a bit more detail on Friday: > > > > https://wiki.freebsd.org/NEW_PCIB > > > > I have posted patches in the past to arm@ to handle step 2 in the NEW_PCIB > > base requirements for arm@ but haven't been able to get folks to test them. > > I just recently made a new pass through sys/arm in a p4 tree to refresh this. > > I haven't even compiled these yet, but you can find the patch here: > > > > http://people.freebsd.org/~jhb/patches/arm_activate2.patch > > Do you need a fully work system, or is booting fine? If you need a > fully working system, then I need some help figure out my panic.. I sent > email to alc and kib a few days ago about it, but I haven't heard anything > back.. it's a problem w/ vm_page... > > If booting is fine, I can test on my AVILA board I have now.. Well, the system needs to boot far enough to actually use memory and I/O port resources for PCI devices. That probably means getting to at least single user and being able to pass a network packet, etc. -- John Baldwin From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 19:16:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61985DBE for ; Mon, 10 Mar 2014 19:16:47 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD55A242 for ; Mon, 10 Mar 2014 19:16:46 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s2AJGRV3018423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Mar 2014 20:16:27 +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 s2AJGMbJ086203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2014 20:16:22 +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 s2AJGMOq079363; Mon, 10 Mar 2014 20:16:22 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s2AJGLUt079362; Mon, 10 Mar 2014 20:16:21 +0100 (CET) (envelope-from ticso) Date: Mon, 10 Mar 2014 20:16:21 +0100 From: Bernd Walter To: Miroslav Chlastak Subject: Re: ARM platform for network router Message-ID: <20140310191621.GB65259@cicely7.cicely.de> References: 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.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:16:47 -0000 On Mon, Mar 10, 2014 at 03:50:31PM +0100, Miroslav Chlastak wrote: > Hello, > > is there any box like ???alix/wrap boards???, that can be uset as router with ARM CPU? We are looking for a new platform with more power instead of Alix board. But every i386 platform is too expensive (when comparing to eg. routerboard). Take a look at the MIPS mailinglist. IIRC some people have FreeBSD running on routerboard hardware. And some even cheaper TP-Link (and noname) (mostly) Atheros based router hardware works fine. Most of them have small flash based filesystem space, but as many have USB you can run a full featured FreeBSD by using USB drives. Beside having an USB port you wan to look for at least 32MB or 64MB RAM. For example the carambola 2 using AR9331 with 64MB RAM runs fine, but unfortunately 8devices only wired 2 ethernet ports from the internal switch. The Atheros chip itself has 2 NIC, with one connected to an internal 5-port VLAN capable switch. Last time I've checked however FreeBSD had no support to configure the internal switch however. But you can get countless boards using this and other supported Atrheros chips, just watch out for RAM, as there are boards with 8 and 16MB RAM only. Even without support to configure the switch you have 2 individual NIC. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 19:49:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33A1C7E5 for ; Mon, 10 Mar 2014 19:49:23 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E7FFA787 for ; Mon, 10 Mar 2014 19:49:22 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id m5so7358167qaj.7 for ; Mon, 10 Mar 2014 12:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cIWGEWKm6voEBkPib4K1bdbb2gL+CXklsmI4OuOGtr0=; b=WpDPvtVwKifyzhwZDKvrluE3IgWfrGDfezwk5jmJXKfwxQoeZCXvyMX3H4gMiguUyG sdLQp96fXL/LvbuoPenh7KnVwjuITW+uKNLOqXJUa/0rhqS0+BLGEo4Ar7Y75p1U3sdR YPNF9Q8yyJtULEKPl6Quq4Yr5BqVG4v0WoABLFr4McTMnrEi1KzTMSjRzp/Le2BMqhMj pLmN7+BCRgyGYeet0SJIduNlf8jeHunv41kBq/p0n61PgaJ8newDwGicBtkprc7wdRYX Nn2k25wsb21vyZCObap/snsu1wW6Wkh/HdoRdyG2RA28eZeSsk8oPE/MBwz2XzmHnbHj /rEg== MIME-Version: 1.0 X-Received: by 10.140.50.169 with SMTP id s38mr27788211qga.12.1394480962092; Mon, 10 Mar 2014 12:49:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Mon, 10 Mar 2014 12:49:22 -0700 (PDT) In-Reply-To: <20140310191621.GB65259@cicely7.cicely.de> References: <20140310191621.GB65259@cicely7.cicely.de> Date: Mon, 10 Mar 2014 12:49:22 -0700 X-Google-Sender-Auth: ZIq6SguK9uQ18iwUf3IhWJto0M4 Message-ID: Subject: Re: ARM platform for network router From: Adrian Chadd To: ticso@cicely.de Content-Type: text/plain; charset=ISO-8859-1 Cc: Miroslav Chlastak , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:49:23 -0000 On 10 March 2014 12:16, Bernd Walter wrote: > On Mon, Mar 10, 2014 at 03:50:31PM +0100, Miroslav Chlastak wrote: >> Hello, >> >> is there any box like ???alix/wrap boards???, that can be uset as router with ARM CPU? We are looking for a new platform with more power instead of Alix board. But every i386 platform is too expensive (when comparing to eg. routerboard). > > Take a look at the MIPS mailinglist. > IIRC some people have FreeBSD running on routerboard hardware. > And some even cheaper TP-Link (and noname) (mostly) Atheros based > router hardware works fine. > Most of them have small flash based filesystem space, but as many > have USB you can run a full featured FreeBSD by using USB drives. > Beside having an USB port you wan to look for at least 32MB or 64MB RAM. > For example the carambola 2 using AR9331 with 64MB RAM runs fine, but > unfortunately 8devices only wired 2 ethernet ports from the internal switch. > The Atheros chip itself has 2 NIC, with one connected to an internal > 5-port VLAN capable switch. > Last time I've checked however FreeBSD had no support to configure the > internal switch however. We can configure the internal switch now. I haven't tested vlangroup support on arswitch but it is supposed to work. > But you can get countless boards using this and other supported Atrheros > chips, just watch out for RAM, as there are boards with 8 and 16MB RAM > only. > Even without support to configure the switch you have 2 individual NIC. .. and I'll fix the arswitch problems if I can get hardware to test it out with. -a From owner-freebsd-arm@FreeBSD.ORG Mon Mar 10 20:46:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 297A3781 for ; Mon, 10 Mar 2014 20:46:11 +0000 (UTC) Received: from mail.sloane.cz (zimbra2.cust.sloane.cz [77.48.244.12]) by mx1.freebsd.org (Postfix) with ESMTP id B451DCEE for ; Mon, 10 Mar 2014 20:46:10 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sloane.cz (Postfix) with ESMTP id DAA06CA4076; Mon, 10 Mar 2014 21:46:20 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sloane.cz Received: from mail.sloane.cz ([127.0.0.1]) by localhost (mail.sloane.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1PP3gSLSl9p; Mon, 10 Mar 2014 21:46:20 +0100 (CET) Received: from [192.168.200.55] (unknown [82.100.53.18]) by mail.sloane.cz (Postfix) with ESMTPSA id F1752CA4020; Mon, 10 Mar 2014 21:46:19 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: ARM platform for network router From: Miroslav Chlastak In-Reply-To: <20140310191621.GB65259@cicely7.cicely.de> Date: Mon, 10 Mar 2014 21:46:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140310191621.GB65259@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 20:46:11 -0000 I know, that there are users runing freebsd on routerboard 450. But this = model is end of life, and this board is booting only from tftp (not for = CF or NAND). Some box like TP-Link/Noname has no more performance like alix (with = i386 geode cpu). Box with better performance (compared to eg. ARM/MIPS routerboard) on = i386 is bigger and more expensive (like arm/mips hw). --=20 Miroslav Chlastak AntHill s.r.o. | http://www.anthill.cz mobil: +420 777 898 383 hotline: +420 246 024 246 10. 3. 2014 v 20:16, Bernd Walter : > On Mon, Mar 10, 2014 at 03:50:31PM +0100, Miroslav Chlastak wrote: >> Hello, >>=20 >> is there any box like ???alix/wrap boards???, that can be uset as = router with ARM CPU? We are looking for a new platform with more power = instead of Alix board. But every i386 platform is too expensive (when = comparing to eg. routerboard). >=20 > Take a look at the MIPS mailinglist. > IIRC some people have FreeBSD running on routerboard hardware. > And some even cheaper TP-Link (and noname) (mostly) Atheros based > router hardware works fine. > Most of them have small flash based filesystem space, but as many > have USB you can run a full featured FreeBSD by using USB drives. > Beside having an USB port you wan to look for at least 32MB or 64MB = RAM. > For example the carambola 2 using AR9331 with 64MB RAM runs fine, but > unfortunately 8devices only wired 2 ethernet ports from the internal = switch. > The Atheros chip itself has 2 NIC, with one connected to an internal > 5-port VLAN capable switch. > Last time I've checked however FreeBSD had no support to configure the > internal switch however. > But you can get countless boards using this and other supported = Atrheros > chips, just watch out for RAM, as there are boards with 8 and 16MB RAM > only. > Even without support to configure the switch you have 2 individual = NIC. >=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 Tue Mar 11 00:26:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 525AEEE for ; Tue, 11 Mar 2014 00:26:10 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 38C275F9 for ; Tue, 11 Mar 2014 00:26:10 +0000 (UTC) Received: from bender (222-154-130-182.jetstream.xtra.co.nz [222.154.130.182]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 749BE5C682 for ; Tue, 11 Mar 2014 00:19:49 +0000 (UTC) Date: Tue, 11 Mar 2014 13:19:45 +1300 From: Andrew Turner To: freebsd-arm@freebsd.org Subject: Updating the minimum armv6 requirement Message-ID: <20140311131945.01f4c9b2@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 00:26:10 -0000 I've been looking at code that uses 64-bit C++ atomic operations on armv6. These require the ldrexd and strexd instructions that are present on armv6k. The problem is there is a mismatch between clang and binutils. Clang thinks armv6k is an arm1136jf-s and sets the cpu in the asm output as one. Binutils will see the cpu and think clang means an earlier armv6 instruction set that lacks the above instructions. In this case both are correct as prior to the r1p0 release of the arm1136jf-s core it was an armv6 core, and as of the r1p0 release it became an armv6k core. All of this is uninteresting for FreeBSD as the only ARMv6 SoC we run on appears to be the bcm2835, and maybe some Marvell parts. As the bcm2835 is an arm1176jzf-s and we are unlikely to get a new ARMv6 port I am suggesting we make this the minimum requirement. It appears NetBSD has the same requirement as clang will set the cpu to arm1176jzf-s when building for NetBSD and armv6. My proposal is to have the same CPU requirement as NetBSD for armv6. Is anyone working on an SoC that would be affected by this? Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Mar 11 01:24:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F652C08 for ; Tue, 11 Mar 2014 01:24:29 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 300ABB71 for ; Tue, 11 Mar 2014 01:24:29 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id h18so10236525igc.0 for ; Mon, 10 Mar 2014 18:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ith902wSA2A4jCBtZo8YKCrlOEqXdzH/ow2Qg63QrMc=; b=DJsn78ZOLfktJwKApTOHl1OsUEUw4uKuA2ZrAcI65GT4wh9TJoamZ5OqQp4Oy7JZmq VRnwvi8DwV3/5N2D5eU2pAh0CKbDoRRoU5hGic72CNy3awDj3U6QaEnGsBh5MoMpO+ED uLHy4BizZi3gMR1XX5XlwVMInP1aRv6SBGfpnHlrK6QGlQGzupTDp2mrWYvPlAC6BLpd crtQlbMeVUPQmNMVpF3ZmTIM5Zwa5HZGezFJCpL1LWe1cd/Htf1nTowvDJvskVpNkuWq fB9sH9jdEb0y1WfzeeDozU5YN8tDScd8wFqd7DP1usRbqf014Upy35RFWxg1fnbnt/9P JY3w== MIME-Version: 1.0 X-Received: by 10.50.25.138 with SMTP id c10mr16515989igg.15.1394501068598; Mon, 10 Mar 2014 18:24:28 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Mon, 10 Mar 2014 18:24:28 -0700 (PDT) Date: Tue, 11 Mar 2014 09:24:28 +0800 Message-ID: Subject: Enabling second core on A20 (Dual core Cortex A7) From: Ganbold Tsagaankhuu To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 01:24:29 -0000 Hi, I'm trying to enable SMP on cubieboard2 which has A20 SoC, dual core Cortex A7. However it boots with "WARNING: Some AP's failed to start" msg. The code is at: https://github.com/tsgan/allwinner_a10/blob/master/a20/a20_mp.c Linux code is at: https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/arch/arm/mach-sun7i/platsmp.c https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/arch/arm/mach-sun7i/headsmp.S My asm foo is not good so I thought I'd better ask if it could be related to locore.S or early initialization codes for enabling SMP. ARM Cortex A7 MPCore Tech ref manual says (page 40): "To power up the processor, apply the following sequence: 1. Assert nCOREPORESET LOW and hold L1RSTDISABLE LOW. Ensure DBGPWRDUP is held LOW to prevent any external debug access to the processor. 2. Apply power to the Vcore power domain. Keep the state of the signals nCOREPORESET, L1RSTDISABLE and DBGPWRDUP LOW. 3. When the power domain has stabilized and reset has been asserted for four or more cycles, release the processor output clamps. 4. De-assert resets. 5. Assert DBGPWRDUP HIGH to allow external debug access to the processor. 6. If required use software to restore the state of the processor prior to power-down. 7. Assert ACTLR.SMP bit HIGH for SMP mode. Continue a normal power-on reset sequence." It seems setting ACTLR smp bit is taken place in cortexa_setup() of cpufunc.c which seems to be called before platform_mp_start_ap(). But I maybe overlooked this, or the problem could be somewhere else, so correct me if I'm wrong here. Also it seems atomic_add_rel_32(&mp_naps, 1) doesn't increase mp_naps and cpu_mp_start() of mp_machdep.c complaines with "WARNING: Some AP's failed to start" msg at boot. It could be related maybe because ACTLR smp bit is not set, since A20 CPU0/CPU1 status register reading says SMP mode is still not set. A20 doc is not good so I had to look for linux codes. Sysctl reading says: root@arm:~ # sysctl -a|grep cpu kern.sched.cpusetsize: 4 kern.ccpu: 1948 kern.smp.maxcpus: 4 kern.smp.cpus: 1 net.inet.tcp.per_cpu_timers: 0 debug.cpufreq.lowest: 0 debug.cpufreq.verbose: 0 hw.ncpu: 2 So am I missing something in my code or are there some places where I should put debug printf checking for variables, register values etc. ? I appreciate if someone can point me to the right direction. Boot log at: https://github.com/tsgan/allwinner_a10/blob/master/a20/dmesg_smp.txt thanks a lot, Ganbold From owner-freebsd-arm@FreeBSD.ORG Tue Mar 11 02:42:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D02DE980 for ; Tue, 11 Mar 2014 02:42:41 +0000 (UTC) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B75B239 for ; Tue, 11 Mar 2014 02:42:41 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id t19so10083531igi.0 for ; Mon, 10 Mar 2014 19:42:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Quox1TwWHSQF2A2JcOXrjFwgw6c4Wty35iRdCEfYwqY=; b=GmAqA43fUKfZrSXnGXmqB6gYazhrxn2baWHYrioaDcjrKGLQteHW74cv/FOWH8Cmtp U9tI6JQylXOP7e9WmCEhiA39TWsBtOwdLTAiOP3/q3Ae7//5D5F4nTb9+pm8sMFbqIyt rR/g/ysplOH8jbAosHA6NQcXvTu/9bNGAXP9ayz2vGfR7ULE3SLjLzMJp++8Tkt9/hgG Zcud2/knkw3eXVX2vStZIQ0xukqrN79Yxe3IfSisNvONIXDBfPgyuE+0WpfQsSc1oNGW vt29QlTBhv6p/jsfuPt73a/M3LAzTlsgPqUiqErGN74xjn/q4w7oHw9DpOy+4ApN31mz WrQA== X-Gm-Message-State: ALoCoQl2OF9tK5nvjJA8nwmV2cBQvYl0FNJ2bsxHZkbgw65V6CL2bERDamIVwaX9amYZQT5eQdbq X-Received: by 10.42.131.197 with SMTP id a5mr7279651ict.8.1394505760308; Mon, 10 Mar 2014 19:42:40 -0700 (PDT) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id sc8sm42372371igb.0.2014.03.10.19.42.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 19:42:39 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Updating the minimum armv6 requirement From: Warner Losh In-Reply-To: <20140311131945.01f4c9b2@bender> Date: Mon, 10 Mar 2014 20:42:38 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <20140311131945.01f4c9b2@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 02:42:41 -0000 On Mar 10, 2014, at 6:19 PM, Andrew Turner wrote: > I've been looking at code that uses 64-bit C++ atomic operations on > armv6. These require the ldrexd and strexd instructions that are > present on armv6k. > > The problem is there is a mismatch between clang and binutils. Clang > thinks armv6k is an arm1136jf-s and sets the cpu in the asm output as > one. Binutils will see the cpu and think clang means an earlier armv6 > instruction set that lacks the above instructions. > > In this case both are correct as prior to the r1p0 release of the > arm1136jf-s core it was an armv6 core, and as of the r1p0 release it > became an armv6k core. > > All of this is uninteresting for FreeBSD as the only ARMv6 SoC we run > on appears to be the bcm2835, and maybe some Marvell parts. As the > bcm2835 is an arm1176jzf-s and we are unlikely to get a new ARMv6 port I > am suggesting we make this the minimum requirement. It appears NetBSD > has the same requirement as clang will set the cpu to arm1176jzf-s when > building for NetBSD and armv6. > > My proposal is to have the same CPU requirement as NetBSD for armv6. Is > anyone working on an SoC that would be affected by this? I think this is OK. Is there some way to make the new requirement a compile time error, or kernel-time panic? Warner From owner-freebsd-arm@FreeBSD.ORG Tue Mar 11 04:20:01 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93A3D992 for ; Tue, 11 Mar 2014 04:20:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 656C7C8B for ; Tue, 11 Mar 2014 04:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2B4K12K079140 for ; Tue, 11 Mar 2014 04:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2B4K1fG079139; Tue, 11 Mar 2014 04:20:01 GMT (envelope-from gnats) Date: Tue, 11 Mar 2014 04:20:01 GMT Message-Id: <201403110420.s2B4K1fG079139@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Stephen Woolerton Subject: Fixed: Re: arm/186823: icu port won't compile on Raspberry Pi X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Stephen Woolerton List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 04:20:01 -0000 The following reply was made to PR arm/186823; it has been noted by GNATS. From: Stephen Woolerton To: bug-followup@FreeBSD.org, direct727@gmail.com Cc: Subject: Fixed: Re: arm/186823: icu port won't compile on Raspberry Pi Date: Tue, 11 Mar 2014 17:16:28 +1300 This problem report can be closed. icu is compiling now (the port must have been updated) Thanks Stephen From owner-freebsd-arm@FreeBSD.ORG Tue Mar 11 07:50:01 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40B3AE90; Tue, 11 Mar 2014 07:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 17AC1EBA; Tue, 11 Mar 2014 07:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2B7o09g064650; Tue, 11 Mar 2014 07:50:00 GMT (envelope-from jmg@freefall.freebsd.org) Received: (from jmg@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2B7o0uE064629; Tue, 11 Mar 2014 07:50:00 GMT (envelope-from jmg) Date: Tue, 11 Mar 2014 07:50:00 GMT Message-Id: <201403110750.s2B7o0uE064629@freefall.freebsd.org> To: direct727@gmail.com, jmg@FreeBSD.org, freebsd-arm@FreeBSD.org From: jmg@FreeBSD.org Subject: Re: arm/186823: icu port won't compile on Raspberry Pi X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 07:50:01 -0000 Synopsis: icu port won't compile on Raspberry Pi State-Changed-From-To: open->closed State-Changed-By: jmg State-Changed-When: Tue Mar 11 07:49:29 UTC 2014 State-Changed-Why: closed per request http://www.freebsd.org/cgi/query-pr.cgi?pr=186823 From owner-freebsd-arm@FreeBSD.ORG Tue Mar 11 09:02:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6B00225 for ; Tue, 11 Mar 2014 09:02:49 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A50F4937 for ; Tue, 11 Mar 2014 09:02:49 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so8560281ieb.12 for ; Tue, 11 Mar 2014 02:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=s2ju3/pmne2VVRyzA7VGGKUVeO09u2GGixhTxqhYbTc=; b=fmCzUSPHHNUXAjZn1E4AFLAPimTV33meWzvPc2dQkRqYk4GydJKjJk+HJIGn6/J0l9 klAmxVwb2WISxMvvl7AvOOwTiFuyQ70xBXOirckqcO7yaQkX2ckBJLtGpA6kcENLxVrt fOMqbBqaR7/Yi5d4GN/3Anx0mo7XLOOMf8iEWRi+h7v2RaBbQNN9qf4VhrBNDzYnSHBe Ud1LmKMK7mLcI81Qojb55BRuzKx4VEk60WUDmhE4A7iBzeN8teSCOUkj9ML3oZgHvkiz jHnO5yRImPKIqq0lUKv7gjfQ7H5V39S28AButg4kp50m8/yOH3pE+pGbmTfPBfjRhEGR BqvA== MIME-Version: 1.0 X-Received: by 10.50.61.180 with SMTP id q20mr5018852igr.38.1394528569105; Tue, 11 Mar 2014 02:02:49 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Tue, 11 Mar 2014 02:02:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 17:02:49 +0800 Message-ID: Subject: Re: Enabling second core on A20 (Dual core Cortex A7) From: Ganbold Tsagaankhuu To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 09:02:49 -0000 On Tue, Mar 11, 2014 at 9:24 AM, Ganbold Tsagaankhuu wrote: > Hi, > > I'm trying to enable SMP on cubieboard2 which has A20 SoC, dual core > Cortex A7. > However it boots with "WARNING: Some AP's failed to start" msg. > > The code is at: > > https://github.com/tsgan/allwinner_a10/blob/master/a20/a20_mp.c > Replying to myself. It was my fault, I should be using physical address for the register instead of virtual. Now I've got second core enabled :) However there happens spurious interrupt detected [0x000003ff] from time to time. Ganbold > > > Linux code is at: > > > https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/arch/arm/mach-sun7i/platsmp.c > > https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/arch/arm/mach-sun7i/headsmp.S > > My asm foo is not good so I thought I'd better ask if it could be related > to > locore.S or early initialization codes for enabling SMP. > > ARM Cortex A7 MPCore Tech ref manual says (page 40): > > "To power up the processor, apply the following sequence: > 1. Assert nCOREPORESET LOW and hold L1RSTDISABLE LOW. Ensure > DBGPWRDUP is held LOW to prevent any external debug access to the > processor. > 2. Apply power to the Vcore power domain. Keep the state of the signals > nCOREPORESET, L1RSTDISABLE and DBGPWRDUP LOW. > 3. When the power domain has stabilized and reset has been asserted for > four or > more cycles, > release the processor output clamps. > 4. De-assert resets. > 5. Assert DBGPWRDUP HIGH to allow external debug access to the processor. > 6. If required use software to restore the state of the processor prior to > power-down. > 7. Assert ACTLR.SMP bit HIGH for SMP mode. Continue a normal power-on reset > sequence." > > It seems setting ACTLR smp bit is taken place in cortexa_setup() of > cpufunc.c > which seems to be called before platform_mp_start_ap(). > But I maybe overlooked this, or the problem could be somewhere else, so > correct me if I'm wrong here. > > Also it seems atomic_add_rel_32(&mp_naps, 1) doesn't increase mp_naps and > cpu_mp_start() of mp_machdep.c complaines with "WARNING: Some AP's failed > to > start" msg at boot. > It could be related maybe because ACTLR smp bit is not set, since A20 > CPU0/CPU1 > status register reading says SMP mode is still not set. A20 doc is not > good so I > had to look for linux codes. > > Sysctl reading says: > > root@arm:~ # sysctl -a|grep cpu > kern.sched.cpusetsize: 4 > kern.ccpu: 1948 > kern.smp.maxcpus: 4 > kern.smp.cpus: 1 > net.inet.tcp.per_cpu_timers: 0 > debug.cpufreq.lowest: 0 > debug.cpufreq.verbose: 0 > hw.ncpu: 2 > > So am I missing something in my code or are there some places where I > should put > debug printf checking for variables, register values etc. ? > I appreciate if someone can point me to the right direction. > > Boot log at: > > https://github.com/tsgan/allwinner_a10/blob/master/a20/dmesg_smp.txt > > thanks a lot, > > Ganbold > From owner-freebsd-arm@FreeBSD.ORG Tue Mar 11 12:09:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 068C6714 for ; Tue, 11 Mar 2014 12:09:25 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id DE852C64 for ; Tue, 11 Mar 2014 12:09:24 +0000 (UTC) Received: from bender (222-154-130-182.jetstream.xtra.co.nz [222.154.130.182]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 8FBB05C682; Tue, 11 Mar 2014 12:09:22 +0000 (UTC) Date: Wed, 12 Mar 2014 01:09:19 +1300 From: Andrew Turner To: Warner Losh Subject: Re: Updating the minimum armv6 requirement Message-ID: <20140312010919.30e90f96@bender> In-Reply-To: References: <20140311131945.01f4c9b2@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 12:09:25 -0000 On Mon, 10 Mar 2014 20:42:38 -0600 Warner Losh wrote: > > On Mar 10, 2014, at 6:19 PM, Andrew Turner > wrote: > > > I've been looking at code that uses 64-bit C++ atomic operations on > > armv6. These require the ldrexd and strexd instructions that are > > present on armv6k. > > > > The problem is there is a mismatch between clang and binutils. Clang > > thinks armv6k is an arm1136jf-s and sets the cpu in the asm output > > as one. Binutils will see the cpu and think clang means an earlier > > armv6 instruction set that lacks the above instructions. > > > > In this case both are correct as prior to the r1p0 release of the > > arm1136jf-s core it was an armv6 core, and as of the r1p0 release it > > became an armv6k core. > > > > All of this is uninteresting for FreeBSD as the only ARMv6 SoC we > > run on appears to be the bcm2835, and maybe some Marvell parts. As > > the bcm2835 is an arm1176jzf-s and we are unlikely to get a new > > ARMv6 port I am suggesting we make this the minimum requirement. It > > appears NetBSD has the same requirement as clang will set the cpu > > to arm1176jzf-s when building for NetBSD and armv6. > > > > My proposal is to have the same CPU requirement as NetBSD for > > armv6. Is anyone working on an SoC that would be affected by this? > > I think this is OK. Is there some way to make the new requirement a > compile time error, or kernel-time panic? I don't think there is any way. On further investigation it appears all this would change is to update clang to generate for the same architecture variant as gcc. As far as I can tell there are no instruction differences between the arm1136 r1p0 and the arm1176, they are both armv6k cores. The additions the arm1176 bring are in other areas, e.g. adding TrustZone. In gcc we target armv6k as the base instruction set. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Mar 11 14:40:03 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94CA0EB0 for ; Tue, 11 Mar 2014 14:40:03 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A3D8D6F for ; Tue, 11 Mar 2014 14:40:03 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WNNqc-0005Ev-1b; Tue, 11 Mar 2014 14:40:02 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2BEdxWD060316; Tue, 11 Mar 2014 08:39:59 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+S1mo39IQYeSCpdktiv5xP Subject: Re: Updating the minimum armv6 requirement From: Ian Lepore To: Andrew Turner In-Reply-To: <20140311131945.01f4c9b2@bender> References: <20140311131945.01f4c9b2@bender> Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Mar 2014 08:39:58 -0600 Message-ID: <1394548798.1149.488.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 14:40:03 -0000 On Tue, 2014-03-11 at 13:19 +1300, Andrew Turner wrote: > I've been looking at code that uses 64-bit C++ atomic operations on > armv6. These require the ldrexd and strexd instructions that are > present on armv6k. > > The problem is there is a mismatch between clang and binutils. Clang > thinks armv6k is an arm1136jf-s and sets the cpu in the asm output as > one. Binutils will see the cpu and think clang means an earlier armv6 > instruction set that lacks the above instructions. > > In this case both are correct as prior to the r1p0 release of the > arm1136jf-s core it was an armv6 core, and as of the r1p0 release it > became an armv6k core. > > All of this is uninteresting for FreeBSD as the only ARMv6 SoC we run > on appears to be the bcm2835, and maybe some Marvell parts. As the > bcm2835 is an arm1176jzf-s and we are unlikely to get a new ARMv6 port I > am suggesting we make this the minimum requirement. It appears NetBSD > has the same requirement as clang will set the cpu to arm1176jzf-s when > building for NetBSD and armv6. > > My proposal is to have the same CPU requirement as NetBSD for armv6. Is > anyone working on an SoC that would be affected by this? > > Andrew I think this is fine. I thought we already had a rule that armv6k was the minimum. If we just need the compiler to emit a different .cpu directive to keep the assembler happy, that should be fine. Since we don't support the pre-'k' variants of armv6, there should be no conflicts. -- Ia From owner-freebsd-arm@FreeBSD.ORG Tue Mar 11 20:43:38 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6B0C3A9; Tue, 11 Mar 2014 20:43:38 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86D5CE50; Tue, 11 Mar 2014 20:43:38 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id s2BKhbhm083996; Tue, 11 Mar 2014 20:43:37 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id s2BKhbuu083995; Tue, 11 Mar 2014 20:43:37 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Mar 2014 20:43:37 GMT Message-Id: <201403112043.s2BKhbuu083995@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 20:43:38 -0000 TB --- 2014-03-11 20:40:22 - tinderbox 2.20 running on freebsd-stable.sentex.ca TB --- 2014-03-11 20:40:22 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2014-03-11 20:40:22 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-03-11 20:40:22 - cleaning the object tree TB --- 2014-03-11 20:40:22 - /usr/local/bin/svn stat /src TB --- 2014-03-11 20:40:27 - At svn revision 263045 TB --- 2014-03-11 20:40:28 - building world TB --- 2014-03-11 20:40:28 - CROSS_BUILD_TESTING=YES TB --- 2014-03-11 20:40:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-11 20:40:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-11 20:40:28 - SRCCONF=/dev/null TB --- 2014-03-11 20:40:28 - TARGET=arm TB --- 2014-03-11 20:40:28 - TARGET_ARCH=arm TB --- 2014-03-11 20:40:28 - TZ=UTC TB --- 2014-03-11 20:40:28 - __MAKE_CONF=/dev/null TB --- 2014-03-11 20:40:28 - cd /src TB --- 2014-03-11 20:40:28 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 11 20:40:31 UTC 2014 >>> 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 [...] rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.sbin/zic/zdump (cleandir) rm -f zdump zdump.o ialloc.o scheck.o zdump.8.gz zdump.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> etc (cleandir) "Makefile", line 231: Malformed conditional (${MK_PKGBOOTSTRAP} != "no") "Makefile", line 233: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2014-03-11 20:43:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-11 20:43:37 - ERROR: failed to build world TB --- 2014-03-11 20:43:37 - 116.73 user 19.80 system 194.84 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Mar 11 20:58:18 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E81953E2; Tue, 11 Mar 2014 20:58:18 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 93DB47B; Tue, 11 Mar 2014 20:58:18 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id s2BKwHM3084251; Tue, 11 Mar 2014 20:58:17 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id s2BKwHOG084250; Tue, 11 Mar 2014 20:58:17 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Mar 2014 20:58:17 GMT Message-Id: <201403112058.s2BKwHOG084250@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 20:58:19 -0000 TB --- 2014-03-11 20:55:14 - tinderbox 2.20 running on freebsd-stable.sentex.ca TB --- 2014-03-11 20:55:14 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2014-03-11 20:55:14 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-03-11 20:55:14 - cleaning the object tree TB --- 2014-03-11 20:55:19 - /usr/local/bin/svn stat /src TB --- 2014-03-11 20:55:25 - At svn revision 263046 TB --- 2014-03-11 20:55:26 - building world TB --- 2014-03-11 20:55:26 - CROSS_BUILD_TESTING=YES TB --- 2014-03-11 20:55:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-11 20:55:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-11 20:55:26 - SRCCONF=/dev/null TB --- 2014-03-11 20:55:26 - TARGET=arm TB --- 2014-03-11 20:55:26 - TARGET_ARCH=arm TB --- 2014-03-11 20:55:26 - TZ=UTC TB --- 2014-03-11 20:55:26 - __MAKE_CONF=/dev/null TB --- 2014-03-11 20:55:26 - cd /src TB --- 2014-03-11 20:55:26 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 11 20:55:26 UTC 2014 >>> 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 [...] rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.sbin/zic/zdump (cleandir) rm -f zdump zdump.o ialloc.o scheck.o zdump.8.gz zdump.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> etc (cleandir) "Makefile", line 231: Malformed conditional (${MK_PKGBOOTSTRAP} != "no") "Makefile", line 233: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2014-03-11 20:58:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-11 20:58:17 - ERROR: failed to build world TB --- 2014-03-11 20:58:17 - 112.04 user 18.95 system 182.91 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Mar 11 23:12:48 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F243BF0D; Tue, 11 Mar 2014 23:12:47 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C20DF90; Tue, 11 Mar 2014 23:12:46 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s2BNCf8Q032072; Wed, 12 Mar 2014 01:12:41 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s2BNCfiL032055; Tue, 11 Mar 2014 23:12:41 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Mar 2014 23:12:41 GMT Message-Id: <201403112312.s2BNCfiL032055@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 23:12:48 -0000 TB --- 2014-03-11 21:20:45 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-11 21:20:45 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-11 21:20:45 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-11 21:20:45 - cleaning the object tree TB --- 2014-03-11 21:20:45 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-11 21:21:37 - At svn revision 263048 TB --- 2014-03-11 21:21:38 - building world TB --- 2014-03-11 21:21:38 - CROSS_BUILD_TESTING=YES TB --- 2014-03-11 21:21:38 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-11 21:21:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-11 21:21:38 - SRCCONF=/dev/null TB --- 2014-03-11 21:21:38 - TARGET=arm TB --- 2014-03-11 21:21:38 - TARGET_ARCH=arm TB --- 2014-03-11 21:21:38 - TZ=UTC TB --- 2014-03-11 21:21:38 - __MAKE_CONF=/dev/null TB --- 2014-03-11 21:21:38 - cd /src TB --- 2014-03-11 21:21:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Mar 11 21:21:48 UTC 2014 >>> 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 [...] In file included from /obj/arm.arm/src/tmp/usr/include/sys/counter.h:34: /obj/arm.arm/src/tmp/usr/include/machine/counter.h:90:2: error: use of undeclared identifier 'curthread' counter_u64_add_protected(c, inc); ^ /obj/arm.arm/src/tmp/usr/include/machine/counter.h:81:18: note: expanded from macro 'counter_u64_add_protected' CRITICAL_ASSERT(curthread); \ ^ 1 error generated. *** Error code 1 Stop. bmake[4]: stopped in /src/lib/libpcap *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-11 23:12:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-11 23:12:40 - ERROR: failed to build world TB --- 2014-03-11 23:12:40 - 5254.82 user 1486.62 system 6715.73 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 12 06:32:46 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B1F1385; Wed, 12 Mar 2014 06:32:46 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56F9BC0A; Wed, 12 Mar 2014 06:32:44 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s2C6Wa6u000689; Wed, 12 Mar 2014 08:32:36 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s2C6Waa9000660; Wed, 12 Mar 2014 06:32:36 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 12 Mar 2014 06:32:36 GMT Message-Id: <201403120632.s2C6Waa9000660@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 06:32:46 -0000 TB --- 2014-03-12 04:40:32 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-12 04:40:32 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-12 04:40:32 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-12 04:40:32 - cleaning the object tree TB --- 2014-03-12 04:41:08 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-12 04:41:41 - At svn revision 263062 TB --- 2014-03-12 04:41:42 - building world TB --- 2014-03-12 04:41:42 - CROSS_BUILD_TESTING=YES TB --- 2014-03-12 04:41:42 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-12 04:41:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-12 04:41:42 - SRCCONF=/dev/null TB --- 2014-03-12 04:41:42 - TARGET=arm TB --- 2014-03-12 04:41:42 - TARGET_ARCH=arm TB --- 2014-03-12 04:41:42 - TZ=UTC TB --- 2014-03-12 04:41:42 - __MAKE_CONF=/dev/null TB --- 2014-03-12 04:41:42 - cd /src TB --- 2014-03-12 04:41:42 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Mar 12 04:41:53 UTC 2014 >>> 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 [...] In file included from /obj/arm.arm/src/tmp/usr/include/sys/counter.h:34: /obj/arm.arm/src/tmp/usr/include/machine/counter.h:90:2: error: use of undeclared identifier 'curthread' counter_u64_add_protected(c, inc); ^ /obj/arm.arm/src/tmp/usr/include/machine/counter.h:81:18: note: expanded from macro 'counter_u64_add_protected' CRITICAL_ASSERT(curthread); \ ^ 1 error generated. *** Error code 1 Stop. bmake[4]: stopped in /src/lib/libpcap *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-12 06:32:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-12 06:32:35 - ERROR: failed to build world TB --- 2014-03-12 06:32:35 - 5243.91 user 1503.74 system 6722.81 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 15 03:33:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEDCE271 for ; Sat, 15 Mar 2014 03:33:50 +0000 (UTC) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 489B63F6 for ; Sat, 15 Mar 2014 03:33:49 +0000 (UTC) Received: from [199.165.180.42] (dhcp12.beta.com [199.165.180.42]) by spoon.beta.com (8.14.5/8.14.5) with ESMTP id s2F3Zmkf044275 for ; Fri, 14 Mar 2014 23:35:48 -0400 (EDT) (envelope-from mcgovern@beta.com) Subject: Beaglebone black: are the AIN pins available with gpioctl From: "Brian J. McGovern" To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="us-ascii" Organization: B.E.T.A. Date: Fri, 14 Mar 2014 23:09:36 -0400 Message-ID: <1394852976.1369.3.camel@fbsd-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.6 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on spoon.beta.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mcgovern@beta.com List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 03:33:50 -0000 I'm trying to read through all the details in the Beaglebone Black System Reference manual, but I don't think I've seen this particular piece yet... Are the AIN pins available via gpioctl or another interface in 10.0-RELEASE? From owner-freebsd-arm@FreeBSD.ORG Sat Mar 15 05:23:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 658315C6 for ; Sat, 15 Mar 2014 05:23:38 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01922E5A for ; Sat, 15 Mar 2014 05:23:37 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id x13so2824342wgg.26 for ; Fri, 14 Mar 2014 22:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=soLQdmsSertqJAYBv7ebgGy3HmQ2FGpdbwqn9aSP0qU=; b=n2DaEzmMUZoWjSl7vAx1PvzmxqBfe7zffkL9gWfVR8qIFdSf+eQyIC/baMzcUjap3M Pc6IGixGkHZNESd+6cgN3ewMQDVXcsI1z33epGcj3JMIfiH8e8Ibcu07c0Pldba0wNN5 AMJzrHY5aaA33Iy80xgJBckT3F/e62uwCueVCTOEBBmoBY++sqGico4b/k9nkBbtpXmX 5EhRsrxE4eEQlzSXgCjp+U6dtaWAcF5dI4AQT+hULGBb0KDJ+5d3vRHpnxQaT1ZiHQy9 NXXMy8rBB6utDaVpPkJPFCo4yUKraP4CXTH3tDU5X9dl7AoH+5ufWFdmIEa7JDG+uiu8 F/RQ== MIME-Version: 1.0 X-Received: by 10.180.94.196 with SMTP id de4mr1314681wib.16.1394861015113; Fri, 14 Mar 2014 22:23:35 -0700 (PDT) Received: by 10.216.40.72 with HTTP; Fri, 14 Mar 2014 22:23:35 -0700 (PDT) In-Reply-To: <1394852976.1369.3.camel@fbsd-laptop> References: <1394852976.1369.3.camel@fbsd-laptop> Date: Sat, 15 Mar 2014 02:23:35 -0300 Message-ID: Subject: Re: Beaglebone black: are the AIN pins available with gpioctl From: Luiz Otavio O Souza To: mcgovern@beta.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 05:23:38 -0000 On 15 March 2014 00:09, Brian J. McGovern wrote: > I'm trying to read through all the details in the Beaglebone Black > System Reference manual, but I don't think I've seen this particular > piece yet... Are the AIN pins available via gpioctl or another interface > in 10.0-RELEASE? No, there is no support for the ADC on 10.0-RELEASE. I've just tested a driver for the BBB ADC, now i need to write a man page and publish the code (on this ML). If everything is fine, it will be available on -head and on 10-stable soon. Luiz From owner-freebsd-arm@FreeBSD.ORG Sat Mar 15 08:58:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8B2F9E2 for ; Sat, 15 Mar 2014 08:58:20 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4CC14F9A for ; Sat, 15 Mar 2014 08:58:20 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id b13so3001606wgh.29 for ; Sat, 15 Mar 2014 01:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lkAiS3jyyKTS3ejeH175J2nAUeA26/JoAuC1ru4XYYI=; b=oTbwi1j/KipKQpXataM2NiRQFsD0Z0iRAcs2rhdbeJPaMrg4TMzsJWRICWnjfUIWLz Ah5iLl6V/csoP9Y+NSTeEngL2YhvZQbN8BFmE19p5SG8uyobpLbC4A4eLeazaf67V/Qu /5D68uNel5O2pVldg1r1oQ00dBtJzJqN/Nb45XUMtNSracyjjuAxEqb6j1M0IeCmuQ/j faCBs+zoTJpFaQPkRKfuKwwOHl+Syf4o6tpxE7jwdaxJeSfvi+wVfNAXGjhQ/6kVkmFw SpPMmJ1QrXlGxnh1TIWEeLxSRbOzeyblv2oElKzTpzx8Ce+e80c1mgqHLtApWpgggtxr hREQ== X-Received: by 10.194.90.107 with SMTP id bv11mr10284024wjb.11.1394873898662; Sat, 15 Mar 2014 01:58:18 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id fb6sm4575623wib.2.2014.03.15.01.58.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Mar 2014 01:58:17 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53241620.8000907@hot.ee> Date: Sat, 15 Mar 2014 10:58:08 +0200 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Luiz Otavio O Souza Subject: Re: Beaglebone black: are the AIN pins available with gpioctl References: <1394852976.1369.3.camel@fbsd-laptop> In-Reply-To: X-TagToolbar-Keys: D20140315105806501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mcgovern@beta.com, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 08:58:20 -0000 I already use that loos's ADC code and it works so well (on CURRENT). I happily added this to my home automation system. Now I have to think what to do with all that massive IO... Unsure if anybody else needs that. Written in Perl + POE, all SSL cert auth connections, nicely connects all devices and forwards events :) I'm open to ideas what kind of other devices I should look. BBB is surely something I need more than one (when they manage to produce more :P). -- ketas From owner-freebsd-arm@FreeBSD.ORG Sat Mar 15 13:50:00 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A97E5EC5 for ; Sat, 15 Mar 2014 13:50:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83E6DB52 for ; Sat, 15 Mar 2014 13:50:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2FDo0dr073819 for ; Sat, 15 Mar 2014 13:50:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2FDo0xD073818; Sat, 15 Mar 2014 13:50:00 GMT (envelope-from gnats) Resent-Date: Sat, 15 Mar 2014 13:50:00 GMT Resent-Message-Id: <201403151350.s2FDo0xD073818@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, Takanori Sawada Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12ECFEAB for ; Sat, 15 Mar 2014 13:47:11 +0000 (UTC) Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00326B43 for ; Sat, 15 Mar 2014 13:47:11 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s2FDlAZK069651 for ; Sat, 15 Mar 2014 13:47:10 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s2FDlA2u069650; Sat, 15 Mar 2014 13:47:10 GMT (envelope-from nobody) Message-Id: <201403151347.s2FDlA2u069650@cgiserv.freebsd.org> Date: Sat, 15 Mar 2014 13:47:10 GMT From: Takanori Sawada To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/187606: Wandboard cannot mount root file system X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 13:50:00 -0000 >Number: 187606 >Category: arm >Synopsis: Wandboard cannot mount root file system >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: Sat Mar 15 13:50:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Takanori Sawada >Release: FreeBSD 11.0-CURRENT >Organization: >Environment: FreeBSD 11.0-CURRENT #0 91c1883(master): Sat Mar 15 18:19:48 JST 2014 tak@localhost.localdomain:/usr/home/tak/github/freebsd-objs/arm.armv6/usr/home/tak/github/freebsd/sys/WANDBOARD-DUAL arm >Description: Wandboard cannot mount root file system. r262905 http://svnweb.freebsd.org/base?view=revision&revision=262905 Wandboard related change is nothing. GEOM_PART_BSD and GEOM_PART_MBR are missing. >How-To-Repeat: >Fix: Patch file attached. (r262905 same change) Patch attached with submission follows: diff --git sys/arm/conf/WANDBOARD.common sys/arm/conf/WANDBOARD.common index ab0337d..a9d4f83 100644 --- sys/arm/conf/WANDBOARD.common +++ sys/arm/conf/WANDBOARD.common @@ -35,10 +35,13 @@ options NFSCL # New Network Filesystem Client #options NFSD # New Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCL +options TMPFS # Efficient memory filesystem options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem #options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework +options GEOM_PART_BSD # BSD partition scheme +options GEOM_PART_MBR # MBR partition scheme options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options KTRACE # ktrace(1) support >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Sat Mar 15 13:50:01 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10A7BEC7 for ; Sat, 15 Mar 2014 13:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C86E9B54 for ; Sat, 15 Mar 2014 13:50:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2FDo0dS073887 for ; Sat, 15 Mar 2014 13:50:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2FDo0px073876; Sat, 15 Mar 2014 13:50:00 GMT (envelope-from gnats) Resent-Date: Sat, 15 Mar 2014 13:50:00 GMT Resent-Message-Id: <201403151350.s2FDo0px073876@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, Takanori Sawada Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88D0EE5B for ; Sat, 15 Mar 2014 13:43:31 +0000 (UTC) Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 758FBB25 for ; Sat, 15 Mar 2014 13:43:31 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s2FDhVcW055143 for ; Sat, 15 Mar 2014 13:43:31 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s2FDhVcL055139; Sat, 15 Mar 2014 13:43:31 GMT (envelope-from nobody) Message-Id: <201403151343.s2FDhVcL055139@cgiserv.freebsd.org> Date: Sat, 15 Mar 2014 13:43:31 GMT From: Takanori Sawada To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/187607: Wandboard cannot mount root file system X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 13:50:01 -0000 >Number: 187607 >Category: arm >Synopsis: Wandboard cannot mount root file system >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: Sat Mar 15 13:50:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Takanori Sawada >Release: FreeBSD 11.0-CURRENT >Organization: >Environment: FreeBSD 11.0-CURRENT #0 91c1883(master): Sat Mar 15 18:19:48 JST 2014 tak@localhost.localdomain:/usr/home/tak/github/freebsd-objs/arm.armv6/usr/home/tak/github/freebsd/sys/WANDBOARD-DUAL arm >Description: Wandboard cannot mount root file system. r262905 http://svnweb.freebsd.org/base?view=revision&revision=262905 Wandboard related change is nothing. GEOM_PART_BSD and GEOM_PART_MBR are missing. >How-To-Repeat: >Fix: Patch file attached. (r262905 same change) >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Sat Mar 15 14:00:02 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D4C4119 for ; Sat, 15 Mar 2014 14:00:02 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 71B17C00 for ; Sat, 15 Mar 2014 14:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2FE02Qx076812 for ; Sat, 15 Mar 2014 14:00:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2FE02os076811; Sat, 15 Mar 2014 14:00:02 GMT (envelope-from gnats) Date: Sat, 15 Mar 2014 14:00:02 GMT Message-Id: <201403151400.s2FE02os076811@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Takanori Sawada Subject: Re: arm/187607: Wandboard cannot mount root file system X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Takanori Sawada List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 14:00:02 -0000 The following reply was made to PR arm/187607; it has been noted by GNATS. From: Takanori Sawada To: bug-followup@FreeBSD.org,tak.swd@gmail.com Cc: Subject: Re: arm/187607: Wandboard cannot mount root file system Date: Sat, 15 Mar 2014 22:57:36 +0900 I'm sorry(submit twice). please see PR187606. http://www.freebsd.org/cgi/query-pr.cgi?pr=187606 -- Takanori Sawad From owner-freebsd-arm@FreeBSD.ORG Sat Mar 15 17:00:36 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B805AB4; Sat, 15 Mar 2014 17:00:36 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4181DDD4; Sat, 15 Mar 2014 17:00:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2FH0aT9034566; Sat, 15 Mar 2014 17:00:36 GMT (envelope-from imp@freefall.freebsd.org) Received: (from imp@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2FH0aDC034565; Sat, 15 Mar 2014 11:00:36 -0600 (MDT) (envelope-from imp) Date: Sat, 15 Mar 2014 11:00:36 -0600 (MDT) Message-Id: <201403151700.s2FH0aDC034565@freefall.freebsd.org> To: tak.swd@gmail.com, imp@FreeBSD.org, freebsd-arm@FreeBSD.org From: imp@FreeBSD.org Subject: Re: arm/187607: Wandboard cannot mount root file system X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 17:00:36 -0000 Synopsis: Wandboard cannot mount root file system State-Changed-From-To: open->closed State-Changed-By: imp State-Changed-When: Sat Mar 15 11:00:27 MDT 2014 State-Changed-Why: Duplicate. http://www.freebsd.org/cgi/query-pr.cgi?pr=187607 From owner-freebsd-arm@FreeBSD.ORG Sat Mar 15 17:00:51 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AEF2AF1; Sat, 15 Mar 2014 17:00:51 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3EC75DD8; Sat, 15 Mar 2014 17:00:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2FH0pG4034613; Sat, 15 Mar 2014 17:00:51 GMT (envelope-from imp@freefall.freebsd.org) Received: (from imp@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2FH0p0Z034612; Sat, 15 Mar 2014 11:00:51 -0600 (MDT) (envelope-from imp) Date: Sat, 15 Mar 2014 11:00:51 -0600 (MDT) Message-Id: <201403151700.s2FH0p0Z034612@freefall.freebsd.org> To: tak.swd@gmail.com, imp@FreeBSD.org, freebsd-arm@FreeBSD.org From: imp@FreeBSD.org Subject: Re: arm/187606: Wandboard cannot mount root file system X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 17:00:51 -0000 Synopsis: Wandboard cannot mount root file system State-Changed-From-To: open->closed State-Changed-By: imp State-Changed-When: Sat Mar 15 11:00:38 MDT 2014 State-Changed-Why: Just committed the fix. Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=187606 From owner-freebsd-arm@FreeBSD.ORG Sat Mar 15 17:10:01 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D683C9A for ; Sat, 15 Mar 2014 17:10:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 896AFE2D for ; Sat, 15 Mar 2014 17:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2FHA1rD035112 for ; Sat, 15 Mar 2014 17:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2FHA1wI035111; Sat, 15 Mar 2014 17:10:01 GMT (envelope-from gnats) Date: Sat, 15 Mar 2014 17:10:01 GMT Message-Id: <201403151710.s2FHA1wI035111@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: arm/187606: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dfilter service List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 17:10:01 -0000 The following reply was made to PR arm/187606; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/187606: commit references a PR Date: Sat, 15 Mar 2014 17:00:00 +0000 (UTC) Author: imp Date: Sat Mar 15 16:59:57 2014 New Revision: 263207 URL: http://svnweb.freebsd.org/changeset/base/263207 Log: Fix wandboard to include tmpfs, mbr and bsd labels. PR: 187606 Submitted by: Takanori Sawada Modified: head/sys/arm/conf/WANDBOARD.common Modified: head/sys/arm/conf/WANDBOARD.common ============================================================================== --- head/sys/arm/conf/WANDBOARD.common Sat Mar 15 14:58:48 2014 (r263206) +++ head/sys/arm/conf/WANDBOARD.common Sat Mar 15 16:59:57 2014 (r263207) @@ -35,10 +35,13 @@ options NFSCL # New Network Filesyst #options NFSD # New Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCL +options TMPFS # Efficient memory filesystem options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem #options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework +options GEOM_PART_BSD # BSD partition scheme +options GEOM_PART_MBR # MBR partition scheme options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options KTRACE # ktrace(1) support _______________________________________________ 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 Mar 16 15:13:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A55694C9 for ; Sun, 16 Mar 2014 15:13:20 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5EC3827F for ; Sun, 16 Mar 2014 15:13:20 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s2GFDCUd075023 for ; Sun, 16 Mar 2014 11:13:18 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5325BF88.60309@m5p.com> Date: Sun, 16 Mar 2014 11:13:12 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Debugging cupsd 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]); Sun, 16 Mar 2014 11:13:18 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 15:13:20 -0000 So I decided to try to find out why cupsd core dumps on my RP. I built it WITH_DEBUG=yes and embarked on the following session: root@pi:/usr/ports/print/cups-base # gdb `find . -name cupsd` GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "armv6-marcel-freebsd"... (gdb) set args -C /usr/local/etc/cups/cupsd.conf (gdb) l 147 /* Idle exit on select timeout? */ 148 #endif /* HAVE_LAUNCHD */ 149 150 151 #ifdef HAVE_GETEUID 152 /* 153 * Check for setuid invocation, which we do not support! 154 */ 155 156 if (getuid() != geteuid()) (gdb) r Starting program: /usr/ports/print/cups-base/work/cups-1.5.4/scheduler/cupsd -C /usr/local/etc/cups/cupsd.conf User signal 1 root@pi:/usr/ports/print/cups-base # Huh? -- George From owner-freebsd-arm@FreeBSD.ORG Sun Mar 16 15:17:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6F5D54B for ; Sun, 16 Mar 2014 15:17:54 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5FD3929C for ; Sun, 16 Mar 2014 15:17:54 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s2GFHmIX075059 for ; Sun, 16 Mar 2014 11:17:53 -0400 (EDT) (envelope-from george@m5p.com) Message-ID: <5325C09C.4080008@m5p.com> Date: Sun, 16 Mar 2014 11:17:48 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Debugging cupsd References: <5325BF88.60309@m5p.com> In-Reply-To: <5325BF88.60309@m5p.com> 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]); Sun, 16 Mar 2014 11:17:53 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 15:17:54 -0000 On 03/16/14 11:13, George Mitchell wrote: > So I decided to try to find out why cupsd core dumps on my RP. I > built it WITH_DEBUG=yes and embarked on the following session: > [...] Perhaps too terse. uname -a: FreeBSD pi.m5p.com 10.0-PRERELEASE FreeBSD 10.0-PRERELEASE #0 r260564M: Fri Jan 17 10:14:31 EST 2014 george@parkstreet.m5p.com:/usr/local/home/george/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/RPI-B arm /etc/src.conf (on the system where I ran crochet to cross-build and also on the RPi): MALLOC_PRODUCTION="yes" /etc/make.conf (on the RPi): WITH_PKGNG=yes MALLOC_PRODUCTION=yes # added by use.perl 2013-09-26 09:10:12 PERL_VERSION=5.14.4 -- George From owner-freebsd-arm@FreeBSD.ORG Sun Mar 16 21:33:59 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF5C964A for ; Sun, 16 Mar 2014 21:33:59 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A66580D for ; Sun, 16 Mar 2014 21:33:59 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s2GKv0Fq026665 for ; Sun, 16 Mar 2014 15:57:46 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1jmtm9r8tq-1 for ; Sun, 16 Mar 2014 15:57:46 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id DC6BA46024D for ; Sun, 16 Mar 2014 15:57:45 -0500 (CDT) Message-ID: <53261049.50709@rice.edu> Date: Sun, 16 Mar 2014 15:57:45 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "arm@freebsd.org" Subject: "procstat -x" output X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.713890987064109 urlsuspect_oldscore=0.713890987064109 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.713890987064109 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403160151 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 21:33:59 -0000 Folks, Could someone please run "procstat -x" on any process, and cut-and-paste the output into a reply message. I'm trying to debug a crash that occurs on arm for a patch that I'm developing. Thanks, Alan From owner-freebsd-arm@FreeBSD.ORG Sun Mar 16 21:50:16 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 112FBA45 for ; Sun, 16 Mar 2014 21:50:16 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D7149906 for ; Sun, 16 Mar 2014 21:50:12 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WPIwY-000FJe-Eb; Sun, 16 Mar 2014 21:50:06 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2GLo3Qj066535; Sun, 16 Mar 2014 15:50:03 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19qqKjVjSEQXl4/AkdwVVpF Subject: Re: "procstat -x" output From: Ian Lepore To: Alan Cox In-Reply-To: <53261049.50709@rice.edu> References: <53261049.50709@rice.edu> Content-Type: text/plain; charset="us-ascii" Date: Sun, 16 Mar 2014 15:50:03 -0600 Message-ID: <1395006603.1149.559.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 21:50:16 -0000 On Sun, 2014-03-16 at 15:57 -0500, Alan Cox wrote: > Folks, > > Could someone please run "procstat -x" on any process, and cut-and-paste > the output into a reply message. I'm trying to debug a crash that > occurs on arm for a patch that I'm developing. > > Thanks, > Alan cpsim# procstat -x 720 PID COMM AUXV VALUE 720 cpsim AT_PHDR 0x8034 720 cpsim AT_PHENT 32 720 cpsim AT_PHNUM 7 720 cpsim AT_PAGESZ 4096 720 cpsim AT_FLAGS 0 720 cpsim AT_ENTRY 0xf1c0 720 cpsim AT_BASE 0x2015b000 720 cpsim AT_EXECPATH 0xbfffffb9 720 cpsim AT_OSRELDATE 1100011 720 cpsim AT_CANARY 0xbfffff99 720 cpsim AT_CANARYLEN 32 720 cpsim AT_NCPUS 4 720 cpsim AT_PAGESIZES 0xbfffff91 720 cpsim AT_PAGESIZESLEN 8 720 cpsim AT_STACKPROT NONEXECUTABLE -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Mar 16 21:59:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB9C6CF8 for ; Sun, 16 Mar 2014 21:59:58 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 609799B5 for ; Sun, 16 Mar 2014 21:59:58 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id c11so3080380lbj.26 for ; Sun, 16 Mar 2014 14:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=eSj1MOKdfEnpJGRjrQAFFYu7B8fMnvnQNpevS9sNSiw=; b=TeiHnhdass/mGhfEq8c6aCH4fVYELWdggEZTuAyV36hcy0wYLd7HUoUL48LpxXOwVs Iw8HogmvXuYsSjjCbeC01nIuwMv/Dk6i7gKEeiV8tihSwqCsiQqjVb8M42deGLet+8CZ cGxMkPERD9lDQy3CSMppy3cM2ugklcrIqn2PO8nM/Oj+i28ogy4GcVx/ma9YX6I1M+WK 6YTEIEKr21h+93OQkWUwJK8bh4U7Syc9xkO8LifCELGIApT3R/7izQ4LMPzldru3rhlm giXW7dIrxJH4vNq/FxruXh+CIHxCUhE9QE1xo9d1XqcW5WY3L1Y1J/EiSXytyeni7qjb DU9g== MIME-Version: 1.0 X-Received: by 10.152.170.137 with SMTP id am9mr14489206lac.15.1395007196275; Sun, 16 Mar 2014 14:59:56 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.142.10 with HTTP; Sun, 16 Mar 2014 14:59:56 -0700 (PDT) Date: Sun, 16 Mar 2014 17:59:56 -0400 X-Google-Sender-Auth: 14-oO_aQvZGuNnKhqqkOxDdoq3Q Message-ID: Subject: Booting FreeBSD from eMMC on BeagleBone Black From: Patrick Kelsey To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 21:59:59 -0000 I've had some changes integrated recently to crochet-freebsd, and to ubldr in -current, that enable booting FreeBSD from the onboard eMMC on BeagleBone Black. The changes to crochet-freebsd include (as of 3412b48a0a): - Additional patches for u-boot-2013.04 that fix device enumeration bugs, provide for enumeration of all MMC devices in the presence of empty card slots, and ensure that when booting from an MMC device, MLO loads BB-uboot.img and BB-uboot.img in turn loads BBubldr from the same device MLO was loaded from. - Improvements to the crochet disk partitioning support so multiple partitions of any type can be created, and their sizes and labels can be specified. Even if you aren't interested in having multiple UFS partitions in your image, the disk label support is handy for writing /etc/fstabs that don't rely on the unstable /dev/mmcsdN device names. The changes to ubldr include (as of r263124): - Improved disk probing support that will now by default find and use the first suitable partition among the available storage devices. - Support for an environment variable 'loaderdev' that can be used to specify a specific load device, or to constrain the disk probe. For example, adding a line "loaderdev=mmc1:2.0" to BB-uEnv.txt will cause ubldr to try to load a kernel from the first UFS partition on the eMMC (if you are using the typical crochet partitioning approach of one FAT partition followed by a UFS partition). If you don't define loaderdev, a kernel won't be loaded from the eMMC unless the SD card slot is empty, or otherwise has a card in it that won't produce anything of interest during the disk probe, because the disk probe visits the SD card slot first. The partitioning and /etc/fstab customization routines at the end of https://github.com/pkelsey/crochet-configs/blob/master/BBB-multi-install-config.shmay be of interest. If you add these to your config, an image with one FAT boot partition and two equal-sized, world-installed UFS partitions will be created. The filesystems in the image will be labeled either: SDBOOT, sdfreebsd1, sdfreebsd2 or EMMCBOOT, emmcfreebsd1, emmcfreebsd2 depending on whether or not BEAGLEBONE_BOOT_EMMC is set to "y" when crochet is run, and the contents of /etc/fstab will be constructed accordingly. If you only want one world-installed UFS partition, change NUM_INSTALLS=2 to NUM_INSTALLS=1 in beaglebone_multiinstall_partition_image(). The functionality in these routines may be canned as a configurable board default or option in the future. Also, when making an image for the eMMC, take care to limit the image size to its usable capacity: option ImageSize 1832mb # maximal eMMC image To install an image on the eMMC, I usually do something along the lines of: 1. sudo sh crochet.sh -c 2. dd the resulting image to an sd card and boot from that sd card 3. sudo BEAGLEBONE_BOOT_EMMC=y sh crochet.sh -c 4. scp a bzipped image down, then bzcat | dd it to the eMMC, or ssh -C "cat " | dd it to the eMMC. -Patrick From owner-freebsd-arm@FreeBSD.ORG Sun Mar 16 22:17:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B19DEFD for ; Sun, 16 Mar 2014 22:17:10 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D84EBB1B for ; Sun, 16 Mar 2014 22:17:09 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id q8so3240630lbi.28 for ; Sun, 16 Mar 2014 15:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=vjo/wONYQnusPMmBHBklKg44WInQNld4DzHLbmSgUvQ=; b=Ynloe6d4Vy1/fFrv0xe0DpDjuAHb77wCXFvq4rf5i/FLBkrtwg4Km3xJWDMtZxW2AK zaTS7d8mRwMdtKh7KapWwfGK24lHQ04LceUq5eq6swbcNqH3Cs0ThO+jFFfKlL3D3p53 EpGcdu0Is7NElKTtcNrCEyT51u/C31qsPyt0k20naoky/iso5W52WauDIxc6H8edry79 n5f55pmdktIpYziuQOvCjytXe1iZK7bhXbCae+uqzj8hZdQL6jUFNVlCTaT9pCZWHPyi 3Iw+wuypZJFedJrmMjdHx5cCOoSApUKlDzqBfvXRpJA8u0ecNzG4KOp2+jcRVwTDK+3X gc6w== MIME-Version: 1.0 X-Received: by 10.112.173.169 with SMTP id bl9mr13512383lbc.1.1395008228020; Sun, 16 Mar 2014 15:17:08 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.142.10 with HTTP; Sun, 16 Mar 2014 15:17:07 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Mar 2014 18:17:07 -0400 X-Google-Sender-Auth: -bI_HAxE28LrwFyGMSkiHMGqAow Message-ID: Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black From: Patrick Kelsey To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 22:17:10 -0000 On Sun, Mar 16, 2014 at 5:59 PM, Patrick Kelsey wrote: > ... > > The partitioning and /etc/fstab customization routines at the end of > https://github.com/pkelsey/crochet-configs/blob/master/BBB-multi-install-config.shmay be of interest. If you add these to your config, an image with one FAT > boot partition and two equal-sized, world-installed UFS partitions will be > created. The filesystems in the image will be labeled either: > > Gmail has apparently done something with the whitespace around the above link that it isn't showing me on my end. The above link is https://github.com/pkelsey/crochet-configs/blob/master/BBB-multi-install-config.sh -Patrick From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 00:39:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3946795; Mon, 17 Mar 2014 00:39:25 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C75C847; Mon, 17 Mar 2014 00:39:25 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id as1so4805373iec.3 for ; Sun, 16 Mar 2014 17:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pz7o/xAC3GBZiuQxYgzRlvmAsyGfXVCmDlI/nKqQrrg=; b=VSuFS/9Opzz3OuXfMg2YjmhhwLgdYuFchGte1kRncEkyABMzTM2PrE6LWmGASrF2Ig GXWRoH+Ooy4Pj3GDT9EnDQwQfzmnsOpjOn7woRZWfDNfYteykDNdKw9QiONRSPROiHdn oJhwj4wfMxwT9JU1umyEzQnOKTcjZ7BA3IwgWFOIFHP6xyw5IbvOgA0pZhXlSI9CiZfk Ya72FgOX/VNuRbmgEHz2kjid/1VsE80IyzibDiIT7OJ7ZP2/bqqGQOPnB2paxXRuqBZD ZWU7dVbkRYbOJrodIMh+tu4uiwSTL6fQdXP0BEtsrPdH5T4kWTM3UJk9wfmTtDrBJBH5 J19Q== MIME-Version: 1.0 X-Received: by 10.42.214.80 with SMTP id gz16mr16946249icb.6.1395016764851; Sun, 16 Mar 2014 17:39:24 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Sun, 16 Mar 2014 17:39:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Mar 2014 08:39:24 +0800 Message-ID: Subject: Re: [GSoC 2014] Interested in ARM bringup tasks From: Ganbold Tsagaankhuu To: Alexander Tarasikov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , "Wojciech A. Koszek" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 00:39:25 -0000 Alexander, On Mon, Mar 17, 2014 at 7:19 AM, Alexander Tarasikov < alexander.tarasikov@gmail.com> wrote: > Hello, FreeBSD community! > > I am interested in participating in GSoC this year and I'd like to > pick up one of the tasks related to porting FreeBSD to new > architectures. I'm now doing my master's degree in software > engineering at the "Higher School of Economics" in Moscow. > > Since I love ARM and smartphones, I've chosen the project to port > FreeBSD to a smartphone. If that task is already occupied (which > doesn't seem so), I would be happy to pick up another task suggested > by the community. > > I want to port FreeBSD to the Sony Xperia Z phone. This phone has the > Qualcomm APQ8064 SoC which is used in a large number of smartphones, > including Google Nexus 4. Besides, Qualcomm SoCs are developed > incrementally so there's a high chance that the code for current > generation of chips will benefit future revisions as well. > Interesting. I'm not quite sure how accessible is some pins like uart in Experia Z. I have it here, but I still didn't try to open it yet to see the pins etc. Probably you meant here some embedded boards like ifc6410. Plus ifc6410 has docs so that could be useful too. > > It is known that debugging like JTAG and flash recovery is not > available on consumer devices because of DRM and general love for > obfuscation among the vendors. Therefore, to prevent bricking the > device, That is the hell, it seems Qualcomm uses lauterbach jtag adapter in that case. I and my friend and also some people have tried some adapters like flyswatter2 with ifc6410, still no luck. I suggest using the chainloading approach, that is using the > bootloader that ships with the device and pretend to be a linux image. > That can be done. Their bootloader like maybe LK in case of ifc6410 can boot freebsd kernel. Actually I did that for ifc6410. > > For the mid-term I want to port the u-boot bootloader and add the > support for accessing the microSD card from it. The u-boot will be > flashed to the device instead of the linux kernel. > That could be cool. > > Since the proprietary bootloader already initializes the display (we > can also port linux driver to u-boot), it should be possible, at least > during the initial stage, to use a simple driver in FreeBSD that would > write to the framebuffer allocated by the bootloader or only write the > framebuffer address to the display controller. > That is nice. However first we need uart driver, then either usb ehci, mmc or sata driver needs to mount rootfs in order to boot freebsd to multiuser mode. I already have timer driver and minimal console driver so it makes booting little bit easier. > > In the past I've successfully ported linux to an Intel XScale-based > Asus P525 smartphone, ported Android with all hardware working to boot > from NAND on the Sony Xperia X1 phone and have ported various boards > from OEM to vanilla kernel trees. Recently I've experimented with the > XNU kernel (the one which is used in the fruity operating system) and > ported it to the OMAP5 board. So I think I'll be able to pull it off. > Cool. In case of android or linux there are many people working on various stuffs so in most case drivers are either written or somebody has got started working on particular driver already. For FreeBSD case it is different. You maybe know that very few people are working in case of ARM platform bringup, so we need more developers and I'm happy that you decided to work on this direction. Ganbold > > Have a nice day! > > -- > Regards, Alexander > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 01:13:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCACAB21; Mon, 17 Mar 2014 01:13:56 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87A83AC5; Mon, 17 Mar 2014 01:13:56 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so4863776iec.30 for ; Sun, 16 Mar 2014 18:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UiJzGyCzhB1gC77ZWuapIgE0jLUtu8JAVtq/6SISQHc=; b=WheK5W2LC9a2ULur5y4/jE7Dj/BjKKYX/5LWd5AbLCa7zClUBteQXwPKucbrVxvBqH +DR1fPE2vcDLEM8CK2EFLzpHhZCPSIBmO9Pqr0txoWfUZ/VCqfhlSdFMdzIQIEThKv/I xE12mm3wlZ3u3TU+i8qD1C97FA/dXClXVg77bXC/V64trqKiO5f1bsVpha6mhT42KywG de5q5D17lsDyHr+f/OrQwM0wsdMD4aMgjGGmOqfRHA4HCJUOCPrzim2Pl4f2qIVpsapl bFFFnbPl/oSuqtbgiG1jZwfHThSiyRpRqcmFFTKf6ttpB9p3wbkyw7jnRpCK8RioAOrl VhKQ== MIME-Version: 1.0 X-Received: by 10.50.25.138 with SMTP id c10mr9975572igg.15.1395018836083; Sun, 16 Mar 2014 18:13:56 -0700 (PDT) Received: by 10.64.69.201 with HTTP; Sun, 16 Mar 2014 18:13:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Mar 2014 05:13:55 +0400 Message-ID: Subject: Re: [GSoC 2014] Interested in ARM bringup tasks From: Alexander Tarasikov To: Ganbold Tsagaankhuu Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , "Wojciech A. Koszek" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 01:13:57 -0000 On Mon, Mar 17, 2014 at 4:39 AM, Ganbold Tsagaankhuu wrote: > Alexander, > > > On Mon, Mar 17, 2014 at 7:19 AM, Alexander Tarasikov > wrote: >> >> Hello, FreeBSD community! >> >> I am interested in participating in GSoC this year and I'd like to >> pick up one of the tasks related to porting FreeBSD to new >> architectures. I'm now doing my master's degree in software >> engineering at the "Higher School of Economics" in Moscow. >> >> Since I love ARM and smartphones, I've chosen the project to port >> FreeBSD to a smartphone. If that task is already occupied (which >> doesn't seem so), I would be happy to pick up another task suggested >> by the community. >> >> I want to port FreeBSD to the Sony Xperia Z phone. This phone has the >> Qualcomm APQ8064 SoC which is used in a large number of smartphones, >> including Google Nexus 4. Besides, Qualcomm SoCs are developed >> incrementally so there's a high chance that the code for current >> generation of chips will benefit future revisions as well. > > > Interesting. I'm not quite sure how accessible is some pins like uart in > Experia Z. > I have it here, but I still didn't try to open it yet to see the pins etc. > Probably you meant here some embedded boards like ifc6410. > Plus ifc6410 has docs so that could be useful too. > Yes, that's the trouble with mobile phones - getting UART is hard. On the other hand, having pre-initialized framebuffer also helps in most cases. The problem with ifc6410 board is that I don't have one and even if someone wants to send me one, I may have huge trouble with customs. I personally have the Xperia Z phone, and I don't really want to *buy* another one (because it looks like I have far more hardware than I have time to play with it) I may be able get my hands on an OMAP4-based Galaxy Nexus. Maybe someone from Moscow could lend me some hardware. If I get stuck with Xperia, I may exchange it for a Nexus 5 on a local craiglist since it's also qcom but has UART. > >> >> >> It is known that debugging like JTAG and flash recovery is not >> available on consumer devices because of DRM and general love for >> obfuscation among the vendors. Therefore, to prevent bricking the >> device, > > > That is the hell, it seems Qualcomm uses lauterbach jtag adapter in that > case. > I and my friend and also some people have tried some adapters like > flyswatter2 with ifc6410, still no luck. > >> I suggest using the chainloading approach, that is using the >> bootloader that ships with the device and pretend to be a linux image. > > > That can be done. Their bootloader like maybe LK in case of ifc6410 can boot > freebsd kernel. > Actually I did that for ifc6410. I have not investigated how FreeBSD boots yet, but iirc LK only supports linux (at least it did 3 years ago when I ported it to msm7200A). Since you have a working kernel for ifc6410, I could try using it first. If it at least boots, we can ignore the UART and go straight into writing mmc block drivers. > >> >> >> For the mid-term I want to port the u-boot bootloader and add the >> support for accessing the microSD card from it. The u-boot will be >> flashed to the device instead of the linux kernel. > > > > That could be cool. > >> >> >> Since the proprietary bootloader already initializes the display (we >> can also port linux driver to u-boot), it should be possible, at least >> during the initial stage, to use a simple driver in FreeBSD that would >> write to the framebuffer allocated by the bootloader or only write the >> framebuffer address to the display controller. > > > > That is nice. However first we need uart driver, then either usb ehci, mmc > or sata driver needs to mount rootfs in order to boot freebsd to multiuser > mode. I already have timer driver and minimal console driver so it makes > booting little bit easier. Well, since GSoC wiki clearly states the task to port to a phone, the only acceptable route is mmc (usb is complex and anyway it is unacceptable to have a phone tethered to the laptop all the time). I think a phone is a good target from the marketing point of view, though it is not much different from a development board. > >> >> >> In the past I've successfully ported linux to an Intel XScale-based >> Asus P525 smartphone, ported Android with all hardware working to boot >> from NAND on the Sony Xperia X1 phone and have ported various boards >> from OEM to vanilla kernel trees. Recently I've experimented with the >> XNU kernel (the one which is used in the fruity operating system) and >> ported it to the OMAP5 board. So I think I'll be able to pull it off. > > > Cool. In case of android or linux there are many people working on various > stuffs so in most case drivers are either written or somebody has got > started working on particular driver already. For FreeBSD case it is > different. You maybe know that very few people are working in case of ARM > platform bringup, so we need more developers and I'm happy that you decided > to work on this direction. So I'm waiting for an opinion from the community. What is more desired - a phone port or a new SoC/board support? I have OMAP5432 development board, but as you may know there are no phones with that CPU and there will never be. On the other hand, this board is 1) Similiar to OMAP4 2) Has SATA and USB 3.0 So if this hardware is supported it can potentially be interesting to evaluate the performance of a server-like installation on ARM A15 SoC. > > Ganbold > > >> >> >> Have a nice day! >> >> -- >> Regards, Alexander >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > -- Regards, Alexander From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 01:25:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B79CCD4E; Mon, 17 Mar 2014 01:25:43 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6EBD4B85; Mon, 17 Mar 2014 01:25:43 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id rl12so4807900iec.36 for ; Sun, 16 Mar 2014 18:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LaQGuQZeGLGR3Vm/JCtx5N45c7WW1W2jEQ043PWIuRs=; b=hlF7cTke6Gx/90VU5/E/ZQYeOjyes5+Dp65M96S64aXQU8mwFLU36znXNWavgjPbPX fgF3unWfWtjj11bxuGx5pj32n0Si0D8NbU/jZxpmZG0cbw7WlH9gfPZveX4HPfHVQBCO bXK4MyCKDzEbGRVUA4a5Dj9uitWaShptzDQL+v5JQgMQ0QDV4pUSnYPcgSyTHtZgHoCt KXpQZoySbk8rub7DiSndV2yo+RnwWwNsuBqpwlth8xF0Zry5nRGj0VgxnZ29gLSs+rJ0 qQiCq1eBOVL+APMKqO/xqZ1ZP/AWsQjczdPd0oQP8thmPm1hFsukjFt4UexWu+wftGel Blag== MIME-Version: 1.0 X-Received: by 10.42.20.6 with SMTP id e6mr16575287icb.29.1395019542860; Sun, 16 Mar 2014 18:25:42 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Sun, 16 Mar 2014 18:25:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Mar 2014 09:25:42 +0800 Message-ID: Subject: Re: [GSoC 2014] Interested in ARM bringup tasks From: Ganbold Tsagaankhuu To: Alexander Tarasikov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , "Wojciech A. Koszek" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 01:25:43 -0000 Alexander, On Mon, Mar 17, 2014 at 9:13 AM, Alexander Tarasikov < alexander.tarasikov@gmail.com> wrote: > On Mon, Mar 17, 2014 at 4:39 AM, Ganbold Tsagaankhuu > wrote: > > Alexander, > > > > > > On Mon, Mar 17, 2014 at 7:19 AM, Alexander Tarasikov > > wrote: > >> > >> Hello, FreeBSD community! > >> > >> I am interested in participating in GSoC this year and I'd like to > >> pick up one of the tasks related to porting FreeBSD to new > >> architectures. I'm now doing my master's degree in software > >> engineering at the "Higher School of Economics" in Moscow. > >> > >> Since I love ARM and smartphones, I've chosen the project to port > >> FreeBSD to a smartphone. If that task is already occupied (which > >> doesn't seem so), I would be happy to pick up another task suggested > >> by the community. > >> > >> I want to port FreeBSD to the Sony Xperia Z phone. This phone has the > >> Qualcomm APQ8064 SoC which is used in a large number of smartphones, > >> including Google Nexus 4. Besides, Qualcomm SoCs are developed > >> incrementally so there's a high chance that the code for current > >> generation of chips will benefit future revisions as well. > > > > > > Interesting. I'm not quite sure how accessible is some pins like uart in > > Experia Z. > > I have it here, but I still didn't try to open it yet to see the pins > etc. > > Probably you meant here some embedded boards like ifc6410. > > Plus ifc6410 has docs so that could be useful too. > > > > Yes, that's the trouble with mobile phones - getting UART is hard. On > the other hand, > having pre-initialized framebuffer also helps in most cases. The problem > with > ifc6410 board is that I don't have one and even if someone wants to send > me one, I may have huge trouble with customs. > > I personally have the Xperia Z phone, and I don't really want to *buy* > another one > (because it looks like I have far more hardware than I have time to > play with it) > I may be able get my hands on an OMAP4-based Galaxy Nexus. Maybe someone > from Moscow could lend me some hardware. If I get stuck with Xperia, I may > exchange it for a Nexus 5 on a local craiglist since it's also qcom > but has UART. > > > > >> > >> > >> It is known that debugging like JTAG and flash recovery is not > >> available on consumer devices because of DRM and general love for > >> obfuscation among the vendors. Therefore, to prevent bricking the > >> device, > > > > > > That is the hell, it seems Qualcomm uses lauterbach jtag adapter in that > > case. > > I and my friend and also some people have tried some adapters like > > flyswatter2 with ifc6410, still no luck. > > > >> I suggest using the chainloading approach, that is using the > >> bootloader that ships with the device and pretend to be a linux image. > > > > > > That can be done. Their bootloader like maybe LK in case of ifc6410 can > boot > > freebsd kernel. > > Actually I did that for ifc6410. > > I have not investigated how FreeBSD boots yet, but iirc LK only supports > linux > (at least it did 3 years ago when I ported it to msm7200A). Since you > have a working > kernel for ifc6410, I could try using it first. If it at least boots, > we can ignore the > UART and go straight into writing mmc block drivers. > > Even if you write mmc driver you still need full functioning uart driver (kernel+userland), that makes debugging easier at least and yet it allows to see all the boot messages and you know for sure you get login prompt :) Ganbold > > > >> > >> > >> For the mid-term I want to port the u-boot bootloader and add the > >> support for accessing the microSD card from it. The u-boot will be > >> flashed to the device instead of the linux kernel. > > > > > > > > That could be cool. > > > >> > >> > >> Since the proprietary bootloader already initializes the display (we > >> can also port linux driver to u-boot), it should be possible, at least > >> during the initial stage, to use a simple driver in FreeBSD that would > >> write to the framebuffer allocated by the bootloader or only write the > >> framebuffer address to the display controller. > > > > > > > > That is nice. However first we need uart driver, then either usb ehci, > mmc > > or sata driver needs to mount rootfs in order to boot freebsd to > multiuser > > mode. I already have timer driver and minimal console driver so it makes > > booting little bit easier. > > Well, since GSoC wiki clearly states the task to port to a phone, the > only acceptable > route is mmc (usb is complex and anyway it is unacceptable to have a phone > tethered to the laptop all the time). I think a phone is a good target from > the marketing point of view, though it is not much different from a > development board. > > > > >> > >> > >> In the past I've successfully ported linux to an Intel XScale-based > >> Asus P525 smartphone, ported Android with all hardware working to boot > >> from NAND on the Sony Xperia X1 phone and have ported various boards > >> from OEM to vanilla kernel trees. Recently I've experimented with the > >> XNU kernel (the one which is used in the fruity operating system) and > >> ported it to the OMAP5 board. So I think I'll be able to pull it off. > > > > > > Cool. In case of android or linux there are many people working on > various > > stuffs so in most case drivers are either written or somebody has got > > started working on particular driver already. For FreeBSD case it is > > different. You maybe know that very few people are working in case of ARM > > platform bringup, so we need more developers and I'm happy that you > decided > > to work on this direction. > > So I'm waiting for an opinion from the community. What is more desired - a > phone > port or a new SoC/board support? I have OMAP5432 development board, but > as you may know there are no phones with that CPU and there will never > be. On the > other hand, this board is > 1) Similiar to OMAP4 > 2) Has SATA and USB 3.0 > So if this hardware is supported it can potentially be interesting to > evaluate the performance > of a server-like installation on ARM A15 SoC. > > > > > Ganbold > > > > > >> > >> > >> Have a nice day! > >> > >> -- > >> Regards, Alexander > >> _______________________________________________ > >> freebsd-hackers@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > > > > > > -- > Regards, Alexander > From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 01:33:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C833EAE for ; Mon, 17 Mar 2014 01:33:15 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 473C6C20 for ; Mon, 17 Mar 2014 01:33:15 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 21FD039841; Sun, 16 Mar 2014 18:33:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black From: Rui Paulo In-Reply-To: Date: Sun, 16 Mar 2014 18:33:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 01:33:15 -0000 On 16 Mar 2014, at 14:59, Patrick Kelsey wrote: > - Improved disk probing support that will now by default find and use = the > first suitable partition among the available storage devices. I think this introduced a bug where, if you have a non-responsive boot = device, ubldr will stop and won't try network booting: ## Starting application at 0x01000054 ... Consoles: U-Boot console =20 Compatible API signature found @1d800a8 Number of U-Boot devices: 2 FreeBSD/armv6 U-Boot loader, Revision 1.2 (rpaulo@zedfs.local, Fri Mar 14 22:35:47 PDT 2014) DRAM: 256MB Unknown device type '' <------------ this is new Found U-Boot device: disk Probing all storage devices... Checking unit=3D0 slice=3D0 partition=3D-1...disk0: read failed, error=3D1= Checking unit=3D1 slice=3D0 partition=3D-1... Checking unit=3D2 slice=3D0 partition=3D-1... Checking unit=3D3 slice=3D0 partition=3D-1... Checking unit=3D4 slice=3D0 partition=3D-1... Checking unit=3D5 slice=3D0 partition=3D-1... can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. loader>=20 It stops here and doesn't try net0 booting. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 02:16:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16CEC600; Mon, 17 Mar 2014 02:16:48 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52B7AEF8; Mon, 17 Mar 2014 02:16:47 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id y1so3245706lam.37 for ; Sun, 16 Mar 2014 19:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uzq1Bn+U489aDslWo7Xgvxt7jr3kghUnU3z6m/cGOx4=; b=l0pxrjgp7g8Zg0kPOnbm7+nB8Us2VuLn0psPlPqrqeGF2gqP4TgmS6EMBv4RKIh90x DUYeBpECpp+zm86vW8tQBcLLWA1oRIUWv3Zm3S8nPrNj47xLG6N9gvj5mh3yI+5IUcS1 y6Zlfma6inagfBVt+jOQsSQBSmk55Y62wiAZRtEFsg6KwZJl+EN1q0aV5TPmfoCuWnaC L9QyqStsQj1+REBSoJY3xQ4T5a9ypN9xn2dX5lpbdQiQxagFRvwieTTj7EXEvsrQasvO yrB6SBMaJV98N+5JyT5j2sZEp6K3nxFnnGcDns0boihka4WBGZRpPCkzdCDS0KDIw784 mVhQ== MIME-Version: 1.0 X-Received: by 10.112.94.229 with SMTP id df5mr6547lbb.36.1395022604794; Sun, 16 Mar 2014 19:16:44 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.142.10 with HTTP; Sun, 16 Mar 2014 19:16:44 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Mar 2014 22:16:44 -0400 X-Google-Sender-Auth: wKizg1qUeRKVSOrovzvs2qt1seY Message-ID: Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black From: Patrick Kelsey To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 02:16:48 -0000 On Sun, Mar 16, 2014 at 9:33 PM, Rui Paulo wrote: > On 16 Mar 2014, at 14:59, Patrick Kelsey wrote: > > > - Improved disk probing support that will now by default find and use the > > first suitable partition among the available storage devices. > > I think this introduced a bug where, if you have a non-responsive boot > device, ubldr will stop and won't try network booting: > > ## Starting application at 0x01000054 ... > Consoles: U-Boot console > Compatible API signature found @1d800a8 > Number of U-Boot devices: 2 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (rpaulo@zedfs.local, Fri Mar 14 22:35:47 PDT 2014) > DRAM: 256MB > Unknown device type '' <------------ this is new > Found U-Boot device: disk > Probing all storage devices... > Checking unit=0 slice=0 partition=-1...disk0: read failed, error=1 > > Checking unit=1 slice=0 partition=-1... > Checking unit=2 slice=0 partition=-1... > Checking unit=3 slice=0 partition=-1... > Checking unit=4 slice=0 partition=-1... > Checking unit=5 slice=0 partition=-1... > > can't load 'kernel' > > Type '?' for a list of commands, 'help' for more detailed help. > loader> > > It stops here and doesn't try net0 booting. > > I think the problem is that some of the conditionals in sys/boot/uboot/common/main.c:main() are broken. I believe I sowed the seed for this in the original patch I sent to Ian, which appears to have had an out-of-order set of tests in the disk conditional, which in hindsight turned out to work due to a friendly coincidence (namely disk appearing before net in the devsw). That bad-pattern conditional seems to have gotten munged a bit further and propagated in some of the refactoring Ian did when integrating my patch. I believe sys/boot/uboot/common/main.c, starting around line 442, should look like this: if (strcmp(devsw[i]->dv_name, "disk") == 0 && (load_type == -1 || (load_type & DEV_TYP_STOR))) { if (probe_disks(i, load_type, load_unit, load_slice, load_partition) == 0) break; } if (strcmp(devsw[i]->dv_name, "net") == 0 && (load_type == -1 || (load_type & DEV_TYP_NET))) break; Can you give that a try? -Patrick From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 02:30:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F7687AA for ; Mon, 17 Mar 2014 02:30:49 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 49AEE7B for ; Mon, 17 Mar 2014 02:30:49 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 502FC39841; Sun, 16 Mar 2014 19:30:48 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black From: Rui Paulo In-Reply-To: Date: Sun, 16 Mar 2014 19:30:50 -0700 Content-Transfer-Encoding: 7bit Message-Id: <9D033E95-7F95-4EC2-A3EF-B4B0E2355699@FreeBSD.org> References: To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 02:30:49 -0000 On 16 Mar 2014, at 19:16, Patrick Kelsey wrote: > Can you give that a try? It works, thanks! -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 02:36:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A04B8F8 for ; Mon, 17 Mar 2014 02:36:35 +0000 (UTC) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D4228AC for ; Mon, 17 Mar 2014 02:36:34 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id lx4so4902723iec.9 for ; Sun, 16 Mar 2014 19:36:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=N0IOoEo/Iguq4k/0qY0smXzpyKKR89UwyWNxJs520NM=; b=k/96/vMsrAroIzStBNLWlrWppmuQZq7znwgjOBUNPvyqDa8Qf6pEkQI0VhYvO6wz4z uMnR+Dbbt6RPuYAHLxxH5Y3OUHs1uPDXzK0ZuL46U9LGxdYSCWo9de10UwcuUylaI/Y5 l0yCl54YqaHhipOYW0+RsMNmJ3IouUElEw2DlwW14jMPPQhbYa4+IO/27kFG2VICKXJ5 WUbjnywXDdYaRuCpiaW1xgo37P8BzWSGQn2wzDitgSGtoR0Bmk7hsZqQNsjIWj0DJ5xT slInj0LFwJxuUzziBdwTvFMO4kFNHdi4WVsz5uO0tXj6usJvXF47/KuKVWedkbQK01FN HdzQ== X-Gm-Message-State: ALoCoQmjDrjJBdXWyLNFO+GCEepX3GLhLM7xb2eEh7C6xq7nKyyj4h/sthVoYW+7ni+Ch0+FvV9AAZVl0pn5mapGlgsUzl5z5J9rjQ4L/khjSRQhI1WE3xc= X-Received: by 10.50.4.74 with SMTP id i10mr10421298igi.43.1395023316736; Sun, 16 Mar 2014 19:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.128.200 with HTTP; Sun, 16 Mar 2014 19:28:20 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Mon, 17 Mar 2014 11:28:20 +0900 Message-ID: Subject: Re: [GSoC 2014] Interested in ARM bringup tasks To: Ganbold Tsagaankhuu Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "Wojciech A. Koszek" , freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , Alexander Tarasikov X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 02:36:35 -0000 Hi I would love to see a porting effort to the new Tegra K1 board. Release is set to Q2 this year but I don't know if it will be in time for GSoC... With the powerful GPU on the K1 I see lots of uses in image processing device in cars, surveillance etc, gaming consoles, tablet, smartphones etc. http://www.nvidia.com/object/tegra-k1-processor.html Thanks! -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Mon, Mar 17, 2014 at 10:25 AM, Ganbold Tsagaankhuu wrote: > Alexander, > > > On Mon, Mar 17, 2014 at 9:13 AM, Alexander Tarasikov < > alexander.tarasikov@gmail.com> wrote: > > > On Mon, Mar 17, 2014 at 4:39 AM, Ganbold Tsagaankhuu > > wrote: > > > Alexander, > > > > > > > > > On Mon, Mar 17, 2014 at 7:19 AM, Alexander Tarasikov > > > wrote: > > >> > > >> Hello, FreeBSD community! > > >> > > >> I am interested in participating in GSoC this year and I'd like to > > >> pick up one of the tasks related to porting FreeBSD to new > > >> architectures. I'm now doing my master's degree in software > > >> engineering at the "Higher School of Economics" in Moscow. > > >> > > >> Since I love ARM and smartphones, I've chosen the project to port > > >> FreeBSD to a smartphone. If that task is already occupied (which > > >> doesn't seem so), I would be happy to pick up another task suggested > > >> by the community. > > >> > > >> I want to port FreeBSD to the Sony Xperia Z phone. This phone has the > > >> Qualcomm APQ8064 SoC which is used in a large number of smartphones, > > >> including Google Nexus 4. Besides, Qualcomm SoCs are developed > > >> incrementally so there's a high chance that the code for current > > >> generation of chips will benefit future revisions as well. > > > > > > > > > Interesting. I'm not quite sure how accessible is some pins like uart > in > > > Experia Z. > > > I have it here, but I still didn't try to open it yet to see the pins > > etc. > > > Probably you meant here some embedded boards like ifc6410. > > > Plus ifc6410 has docs so that could be useful too. > > > > > > > Yes, that's the trouble with mobile phones - getting UART is hard. On > > the other hand, > > having pre-initialized framebuffer also helps in most cases. The problem > > with > > ifc6410 board is that I don't have one and even if someone wants to send > > me one, I may have huge trouble with customs. > > > > I personally have the Xperia Z phone, and I don't really want to *buy* > > another one > > (because it looks like I have far more hardware than I have time to > > play with it) > > I may be able get my hands on an OMAP4-based Galaxy Nexus. Maybe someone > > from Moscow could lend me some hardware. If I get stuck with Xperia, I > may > > exchange it for a Nexus 5 on a local craiglist since it's also qcom > > but has UART. > > > > > > > >> > > >> > > >> It is known that debugging like JTAG and flash recovery is not > > >> available on consumer devices because of DRM and general love for > > >> obfuscation among the vendors. Therefore, to prevent bricking the > > >> device, > > > > > > > > > That is the hell, it seems Qualcomm uses lauterbach jtag adapter in > that > > > case. > > > I and my friend and also some people have tried some adapters like > > > flyswatter2 with ifc6410, still no luck. > > > > > >> I suggest using the chainloading approach, that is using the > > >> bootloader that ships with the device and pretend to be a linux image. > > > > > > > > > That can be done. Their bootloader like maybe LK in case of ifc6410 can > > boot > > > freebsd kernel. > > > Actually I did that for ifc6410. > > > > I have not investigated how FreeBSD boots yet, but iirc LK only supports > > linux > > (at least it did 3 years ago when I ported it to msm7200A). Since you > > have a working > > kernel for ifc6410, I could try using it first. If it at least boots, > > we can ignore the > > UART and go straight into writing mmc block drivers. > > > > > Even if you write mmc driver you still need full functioning uart driver > (kernel+userland), that makes debugging easier at least and yet it allows > to see all the boot messages and you know for sure you get login prompt :) > > Ganbold > > > > > > > >> > > >> > > >> For the mid-term I want to port the u-boot bootloader and add the > > >> support for accessing the microSD card from it. The u-boot will be > > >> flashed to the device instead of the linux kernel. > > > > > > > > > > > > That could be cool. > > > > > >> > > >> > > >> Since the proprietary bootloader already initializes the display (we > > >> can also port linux driver to u-boot), it should be possible, at least > > >> during the initial stage, to use a simple driver in FreeBSD that would > > >> write to the framebuffer allocated by the bootloader or only write the > > >> framebuffer address to the display controller. > > > > > > > > > > > > That is nice. However first we need uart driver, then either usb ehci, > > mmc > > > or sata driver needs to mount rootfs in order to boot freebsd to > > multiuser > > > mode. I already have timer driver and minimal console driver so it > makes > > > booting little bit easier. > > > > Well, since GSoC wiki clearly states the task to port to a phone, the > > only acceptable > > route is mmc (usb is complex and anyway it is unacceptable to have a > phone > > tethered to the laptop all the time). I think a phone is a good target > from > > the marketing point of view, though it is not much different from a > > development board. > > > > > > > >> > > >> > > >> In the past I've successfully ported linux to an Intel XScale-based > > >> Asus P525 smartphone, ported Android with all hardware working to boot > > >> from NAND on the Sony Xperia X1 phone and have ported various boards > > >> from OEM to vanilla kernel trees. Recently I've experimented with the > > >> XNU kernel (the one which is used in the fruity operating system) and > > >> ported it to the OMAP5 board. So I think I'll be able to pull it off. > > > > > > > > > Cool. In case of android or linux there are many people working on > > various > > > stuffs so in most case drivers are either written or somebody has got > > > started working on particular driver already. For FreeBSD case it is > > > different. You maybe know that very few people are working in case of > ARM > > > platform bringup, so we need more developers and I'm happy that you > > decided > > > to work on this direction. > > > > So I'm waiting for an opinion from the community. What is more desired - > a > > phone > > port or a new SoC/board support? I have OMAP5432 development board, but > > as you may know there are no phones with that CPU and there will never > > be. On the > > other hand, this board is > > 1) Similiar to OMAP4 > > 2) Has SATA and USB 3.0 > > So if this hardware is supported it can potentially be interesting to > > evaluate the performance > > of a server-like installation on ARM A15 SoC. > > > > > > > > Ganbold > > > > > > > > >> > > >> > > >> Have a nice day! > > >> > > >> -- > > >> Regards, Alexander > > >> _______________________________________________ > > >> freebsd-hackers@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > >> To unsubscribe, send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org" > > > > > > > > > > > > > > -- > > Regards, Alexander > > > _______________________________________________ > 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" > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 10:03:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ED017A4 for ; Mon, 17 Mar 2014 10:03:46 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E3FB0C9E for ; Mon, 17 Mar 2014 10:03:45 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id t19so5027235igi.0 for ; Mon, 17 Mar 2014 03:03:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Iotg4JsiPcL01V7S5j8PcMgqq56vF4FjDq3NZ1LYyP4=; b=HILFHIrV4nZVNx23/qgyGtNmLKNpfRmvAgWqtUWcMdBZOVDmSMKaSnqXNP1XQ4k07y h1TqL4GcgBUNxVezswE7vvHrIzR6NqJD9rMrteXxKIPT5hNiWMbC2RMnq3v/ZGmyE8bj 0YyLyV7Qe9Md1Whqsb79TP9D3bdrpxVSAfEqew62nz3C7ZI0hXJtrRab+0xvimVQaKsO /0qcFKF5D+Y7hw6dh/pH2nbHBoU0cGmyaoqe0oDejvBYUGvhEY0QcWbfFcTYjK6FU3Lz Cn30VHzi2tQOPLpjuClxh7TJWp6z5t/3vZl6cV4fQN5HaE03k4zoXL1Pq7JJrr52v/as LpFw== X-Gm-Message-State: ALoCoQkjr6+wl2PQNru3rHXMEr5CZv/Zo0X+KP8ypho/zAWwSCKFRZmmi8uIt/6+xbzFr9UJYcHdzV/L12NPz0ZNMn7F57VNpYqQ1J0GwiLfAi5m8WFP/rI= X-Received: by 10.50.28.101 with SMTP id a5mr12182452igh.46.1395050624773; Mon, 17 Mar 2014 03:03:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.128.200 with HTTP; Mon, 17 Mar 2014 03:03:28 -0700 (PDT) From: "Lundberg, Johannes" Date: Mon, 17 Mar 2014 19:03:28 +0900 Message-ID: Subject: crochet and dependencies To: freebsd-ports@freebsd.org, "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 10:03:46 -0000 Hi A new version of the crochet script told me I could install u-boot from ports. Trying but keep getting error. First error: Can't find gcc Fixed by installing gcc47 and creating a symbolink link /usr/local/bin/gcc47 /usr/local/bin/gcc Next error: mkenvimage.c: In function 'main': mkenvimage.c:137:35: error: 'PLAIN_VERSION' undeclared (first use in this function) mkenvimage.c:137:35: note: each undeclared identifier is reported only once for each function it appears in gmake[2]: *** [mkenvimage.o] Error 1 gmake[2]: Leaving directory `/usr/ports/sysutils/u-boot-beaglebone-eabi/work/u-boot-2013.04/tools' gmake[1]: *** [tools] Error 2 gmake[1]: Leaving directory `/usr/ports/sysutils/u-boot-beaglebone-eabi/work/u-boot-2013.04' *** Error code 2 What am I doing wrong? On 11-current amd64. -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 10:16:17 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 595A6C0F for ; Mon, 17 Mar 2014 10:16:17 +0000 (UTC) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13BA6DB4 for ; Mon, 17 Mar 2014 10:16:16 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id jz11so5330257veb.39 for ; Mon, 17 Mar 2014 03:16:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=HHJXEuaOk5zKBW3LT1+NZXA2LfPc7/JNi0Sbi1IO9qU=; b=Opp0v3U/t3mYGlLjXU9UxWnpQ/K3EIlnfUQJ1BM1lLkQEC+HB1ytIRJoWwfkGO5VDm 3hSU6eI+IIIAYBOZlT4CYpFZS7f5v+AKs+vzMXJPIqoqCVs7U6xF3OrMV8Z6uhJbuNEm yn5aT+ctssUEr6j1X5tHH27lO39vEql3bLaquy2LUL7HpaLGgoXdefRvoU+tVQ+ou2f/ XY0D/IiAuY0hUVBgmjPnF98M0J/fY3iAK2WRXQOwERIR/wPSbfB8nSf3fnUjrJo9oOnQ K+vMNC9bHFYvwKU29yd/Q9dB285Og/m5zPoci2sUJDO81oEDCBZG7Js51S/VnEiEDAAn zU7w== X-Gm-Message-State: ALoCoQmpnLAA0o172T7ZN35y0AT336qNm0UgKlL6IOS79o16erS6U4PwvIZyPAgQAB7Unshx/I8o MIME-Version: 1.0 X-Received: by 10.52.165.105 with SMTP id yx9mr15810421vdb.22.1395044952185; Mon, 17 Mar 2014 01:29:12 -0700 (PDT) Received: by 10.220.209.135 with HTTP; Mon, 17 Mar 2014 01:29:12 -0700 (PDT) In-Reply-To: <20131222123636.GA61193@ci0.org> References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> Date: Mon, 17 Mar 2014 09:29:12 +0100 Message-ID: Subject: Re: arm SMP on Cortex-A15 From: Wojciech Macek To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 10:16:17 -0000 Hi, Finally I've found some time to continue SMP hacking. It seems that I isolated the tlb/pmam failures and developed two simple patches that help. There are still some pmap changes and TEX remap left, but I don't want to use them now. https://drive.google.com/folderview?id=0B-7yTLrPxaWtSzZPUGgtM3pnUjg&usp=sharing * 01 - ensure that TTB is set before TLB invalidation and flush BTB to comply the specs * 02 - add missing TLB invalidations to pmap and fix invalidation order I chose buildworld -j4 as a stresstest, and run it on Arndale (USB rootfs) and a different 4-core a15 chip (SATA rootfs). On both setups test passed and was significantly faster than the one with previous patchset. I'd like to submit these changes to FreeBSD tree (with some help from our local committers), so any comments and testing are really appreciated. Best regards, Wojtek 2013-12-22 13:36 GMT+01:00 Olivier Houchard : > On Sun, Dec 22, 2013 at 11:53:47AM +0100, Wojciech Macek wrote: > > Thanks, so it seems that there is still something wrong... > > From what I observed, the place where you got the panic was the most > likely > > to fail if there are issues with TLB cache. I guess your case can also > have > > the same root case. Nevertheless, I'll try to reproduce your setup and > > debug it futher. > > > > Regards, > > Wojtek > > I'm quite sure Ruslan's panic happens because the VFP code isn't completely > smp-safe, and I have patches that hopefully fixes this. > > Regards, > > Olivier > > > From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 11:06:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A868788D for ; Mon, 17 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7C3A7287 for ; Mon, 17 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2HB6fu8011164 for ; Mon, 17 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2HB6f4w011162 for freebsd-arm@FreeBSD.org; Mon, 17 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Mar 2014 11:06:41 GMT Message-Id: <201403171106.s2HB6f4w011162@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 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/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o ports/175605 arm please fix build binutils-2.23.1 in raspberry pi 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 ports/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) 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 32 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 12:55:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54643ADC; Mon, 17 Mar 2014 12:55:48 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ABD23FB2; Mon, 17 Mar 2014 12:55:47 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id t60so4555313wes.33 for ; Mon, 17 Mar 2014 05:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8MqxqFoUZPkJWLgDlwifomYwlNQyvGECRCbNKZ0zex0=; b=qPq5BXdME9+Tt14cjxPzD+Dptv4M6s3suTkmXVusVa7/FQIfAUbxcWDn4ZFfPoGKl0 hnrX1s41OqKvfs+oaItZYTqlen0Fv2EYNyhDinwESf4yRW1TkbEH5RMHpmt5nIZ2hSey z/KTbhAkiHyTw/DvB61anZc8yIzztD929rN3WEtz0G6zbM33zbWxRFTgeVQh9BX43jk1 S7nSGd3I076ALeo9PQMIJrd8C+8p7K8RQJwFJXQLlTAeyjfDxU1sXGzf2eUTyzAROBTr ZWm5uh/KA3tBIv34AZnjMBA7i42cEwoq4fs4f1rb7d32XCraryAGH0tU+FEe/Yv/uL1Y zPDw== MIME-Version: 1.0 X-Received: by 10.180.87.162 with SMTP id az2mr9338371wib.23.1395060946092; Mon, 17 Mar 2014 05:55:46 -0700 (PDT) Received: by 10.216.79.132 with HTTP; Mon, 17 Mar 2014 05:55:45 -0700 (PDT) In-Reply-To: References: <2D5F2707-FD55-46BB-A44F-8870B48E2BB1@gmail.com> Date: Mon, 17 Mar 2014 09:55:45 -0300 Message-ID: Subject: Re: FDT/OFW GPIO bus From: Luiz Otavio O Souza To: Warner Losh Content-Type: multipart/mixed; boundary=f46d0444ecaf21df5704f4ccf00f Cc: freebsd-arm@freebsd.org, "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 12:55:48 -0000 --f46d0444ecaf21df5704f4ccf00f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Feb 7, 2014 at 1:21 AM, Warner Losh wrote: > > On Feb 6, 2014, at 11:53 AM, Luiz Otavio O Souza wrote: > >> Hello guys, >> >> Last call for alcohol^Wtest and reviews. >> >> I've finally managed to test these changes on a some FDT and non FDT sys= tems, so now it is all cleared to commit. >> >> I plan to commit these changes on the weekend unless someone objects. > > This is cool. > >> They add support to describe GPIO connections on the DTS files. It also = add the support to the in tree GPIO devices (gpioiic(4), gpioled(4)). >> >> The last patch (005-bbb-gpioled.diff) sets the gpioled(4) for the 4 on b= oard LEDs on BBB (beaglebone-black). The RPi led is already set and just ne= ed the first patch (001-ofw-gpiobus.diff) to work. >> >> The tests were done on RPi and BBB using I2C devices (two lm75 on the sa= me bus), LEDs (for gpioled(4)) and even with some non committed ethernet ov= er SPI. The I2C tests are conducted using the hardware I2C controller (when= available) and also the software big bang controller - gpioiic(4). >> >> I used the RSPRO (MIPS/ar71xx) to check for regressions without any visi= ble problem. >> >> gpioiic(4) devices can be described in DTS as follow: >> >> gpio { >> >> gpioiic { >> compatible =3D "gpioiic"; > > Linux uses 'i2c-gpio' here. Can we follow that standard rather than inven= t our own? Or at least support both? > >> gpios =3D <&gpio 17 2 0 >> &gpio 21 2 0>; >> scl =3D <0>; >> sda =3D <1>; > > Linux doesn't have these at all, it seems, since they are implicit in the= gpios property. It would be ideal if the scl and sda properties were optio= nal... > > In addition, you'll often see things like: > > i2c-gpio,sda-open-drain; > i2c-gpio,scl-open-drain; > i2c-gpio,delay-us =3D <2>; > > as well. These should be easy enough to add and shouldn't gate things. > > There's also many DTS files that don't have this as a direct child of gpi= o... But that's not strictly required. I'll cope with adding support for th= at when I get the Atmel stuff working... The first attached adds the ability to attach nodes compatible with 'i2c-gpio' and also nodes that are not direct childs of gpio controllers (tested with parts of an Atmel dts). The second patch changes the string identification for gpioiic(4) and gpioled(4) from 'gpioiic'/'gpioled' to 'freebsd,gpioiic' and 'freebsd,gpioled'. Did they look fine ? Thanks, Luiz --f46d0444ecaf21df5704f4ccf00f Content-Type: text/plain; charset=US-ASCII; name="gpioiic-linux-dts.diff" Content-Disposition: attachment; filename="gpioiic-linux-dts.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvr22830 SW5kZXg6IHN5cy9kZXYvZ3Bpby9ncGlvaWljLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9ncGlv L2dwaW9paWMuYwkocmV2aXNpb24gMjYyMTMxKQorKysgc3lzL2Rldi9ncGlvL2dwaW9paWMuYwko d29ya2luZyBjb3B5KQpAQCAtNDEsOSArNDEsOSBAQAogI2luY2x1ZGUgImdwaW9idXNfaWYuaCIK IAogI2lmZGVmIEZEVAotI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgorI2luY2x1ZGUgPGRl di9mZHQvZmR0X2NvbW1vbi5oPgorI2luY2x1ZGUgPGRldi9ncGlvL2dwaW9idXN2YXIuaD4KICNp bmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgotI2luY2x1ZGUgPGRldi9mZHQvZmR0X2Nv bW1vbi5oPgogI2VuZGlmCiAKICNpbmNsdWRlIDxkZXYvaWljYnVzL2lpY29uZi5oPgpAQCAtNTQs NiArNTQsMTggQEAKICNkZWZpbmUJU0NMX1BJTl9ERUZBVUxUCTAJLyogZGVmYXVsdCBpbmRleCBv ZiBTQ0wgcGluIG9uIGdwaW9idXMgKi8KICNkZWZpbmUJU0RBX1BJTl9ERUZBVUxUCTEKIAorI2lm ZGVmIEZEVAorI2RlZmluZQlBVFRBQ0hfTk9ORQkwCisjZGVmaW5lCUFUVEFDSF9HUElPSUlDCTEK KyNkZWZpbmUJQVRUQUNIX0kyQ0dQSU8JMgorCitzdGF0aWMgc3RydWN0IG9md19jb21wYXRfZGF0 YSBjb21wYXRfZGF0YVtdID0geworCXsgImdwaW9paWMiLAkJQVRUQUNIX0dQSU9JSUMgfSwKKwl7 ICJpMmMtZ3BpbyIsCQlBVFRBQ0hfSTJDR1BJTyB9LAorCXsgTlVMTCwJCQlBVFRBQ0hfTk9ORSB9 LAorfTsKKyNlbmRpZgorCiBzdHJ1Y3QgZ3Bpb2lpY19zb2Z0YyAKIHsKIAlkZXZpY2VfdAlzY19k ZXY7CkBAIC03NCwxNCArODYsNDIgQEAKIHN0YXRpYyBpbnQgZ3Bpb2lpY19nZXRzY2woZGV2aWNl X3QpOwogc3RhdGljIGludCBncGlvaWljX3Jlc2V0KGRldmljZV90LCB1X2NoYXIsIHVfY2hhciwg dV9jaGFyICopOwogCisjaWZkZWYgRkRUCisvKgorICogVGhlIGlkZW50aWZ5KCkgbWV0aG9kIGlz IHVzZWQgaGVyZSB0byBnaXZlIGEgY2hhbmNlIHRvIGdwaW9paWMgdG8gdHJhdmVyc2UKKyAqIHRo ZSB3aG9sZSBEVEIgZGF0YSB0byBmaW5kIHRoZSBjb21wYXRpYmxlIG5vZGVzIHdoaWNoIGFyZSBu b3QgZGlyZWN0CisgKiBkZWNlbmRhbnRzIGZyb20gdGhlIGdwaW9idXMoNCkuICBUaGlzIGZvbGxv d3MgdGhlIGxpbnV4IHN0YW5kYXJkLgorICovCitzdGF0aWMgdm9pZAorZ3Bpb2lpY19pZGVudGlm eShkcml2ZXJfdCAqZHJpdmVyLCBkZXZpY2VfdCBidXMpCit7CisJcGhhbmRsZV90IGNoaWxkLCBy b290OwogCisJcm9vdCA9IE9GX2ZpbmRkZXZpY2UoIi8iKTsKKwlpZiAocm9vdCA9PSAwKQorCQly ZXR1cm47CisKKwkvKgorCSAqIFRyYXZlcnNlIGFsbCBjaGlsZHJlbiBvZiAncm9vdCcgbm9kZSwg ZmluZCB0aGUgb25lcyBjb21wYXRpYmxlCisJICogd2l0aCAnaTJjLWdwaW8nLgorICAgICAgICAg Ki8KKwlmb3IgKGNoaWxkID0gT0ZfY2hpbGQocm9vdCk7IGNoaWxkICE9IDA7IGNoaWxkID0gT0Zf cGVlcihjaGlsZCkpCisJCWlmIChmZHRfaXNfY29tcGF0aWJsZShjaGlsZCwgImkyYy1ncGlvIikg JiYKKwkJICAgIGZkdF9pc19jb21wYXRpYmxlX3N0cmljdChjaGlsZCwgImkyYy1ncGlvIikpCisJ CQlpZiAob2Z3X2dwaW9idXNfYWRkX2ZkdF9jaGlsZChidXMsIGNoaWxkKSA9PSBOVUxMKQorCQkJ CWNvbnRpbnVlOworfQorI2VuZGlmCisKIHN0YXRpYyBpbnQKIGdwaW9paWNfcHJvYmUoZGV2aWNl X3QgZGV2KQogeworI2lmZGVmIEZEVAorCWludCBtYXRjaDsKIAotI2lmZGVmIEZEVAotCWlmICgh b2Z3X2J1c19pc19jb21wYXRpYmxlKGRldiwgImdwaW9paWMiKSkKLQkJcmV0dXJuIChFTlhJTyk7 CisJbWF0Y2ggPSBvZndfYnVzX3NlYXJjaF9jb21wYXRpYmxlKGRldiwgY29tcGF0X2RhdGEpLT5v Y2RfZGF0YTsKKyAgICAgICAgaWYgKG1hdGNoID09IEFUVEFDSF9OT05FKQorICAgICAgICAgICAg ICAgIHJldHVybiAoRU5YSU8pOwogI2VuZGlmCiAJZGV2aWNlX3NldF9kZXNjKGRldiwgIkdQSU8g STJDIGJpdC1iYW5naW5nIGRyaXZlciIpOwogCkBAIC0yNjEsNiArMzAxLDkgQEAKIAlERVZNRVRI T0QoaWljYmJfcmVzZXQsCQlncGlvaWljX3Jlc2V0KSwKIAogI2lmZGVmIEZEVAorCS8qIERldmlj ZSBpbnRlcmZhY2UgKi8KKwlERVZNRVRIT0QoZGV2aWNlX2lkZW50aWZ5LAlncGlvaWljX2lkZW50 aWZ5KSwKKwogCS8qIE9GVyBidXMgaW50ZXJmYWNlICovCiAJREVWTUVUSE9EKG9md19idXNfZ2V0 X25vZGUsCWdwaW9paWNfZ2V0X25vZGUpLAogI2VuZGlmCkluZGV4OiBzaGFyZS9tYW4vbWFuNC9n cGlvaWljLjQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWFuL21hbjQvZ3Bpb2lpYy40CShyZXZpc2lv biAyNjIxMzEpCisrKyBzaGFyZS9tYW4vbWFuNC9ncGlvaWljLjQJKHdvcmtpbmcgY29weSkKQEAg LTI0LDcgKzI0LDcgQEAKIC5cIgogLlwiICRGcmVlQlNEJAogLlwiCi0uRGQgRmVicnVhcnkgMTMs IDIwMTQKKy5EZCBNYXJjaCAxMSwgMjAxNAogLkR0IEdQSU9JSUMgNAogLk9zCiAuU2ggTkFNRQpA QCAtMTE0LDEwICsxMTQsMzQgQEAKIH07CiAuRWQKIC5QcAorT3B0aW9uYWxseSB0aGUKKy5ObQor bm9kZSBjYW4gYmUgZGVzY3JpYmVkIHVuZGVyIHRoZSByb290IG5vZGUgd2l0aG91dCBiZWluZyBh IGRpcmVjdGx5IGRlc2NlbmRhbnQgb2YgYW55CisuWHIgZ3BpbyA0Citjb250cm9sbGVyOgorLkJk IC1saXRlcmFsCitzaW1wbGVidXMwIHsKKworCS4uLgorCisJaTJjQDAgeworCQljb21wYXRpYmxl ID0gImkyYy1ncGlvIjsKKwkJZ3Bpb3MgPSA8JkdQSU8gMyAxIDAKKyAgICAgICAgICAgICAgICAg ICAgICAgICAmR1BJTyAyIDEgMD47CisKKwkJLyogVGhpcyBpcyBhbm90aGVyIGV4YW1wbGUgb2Yg YSBncGlvaWljIGNoaWxkLiAqLworCQlncGlvaWljLWNoaWxkMCB7CisJCQljb21wYXRpYmxlID0g ImxtNzUiOworCQkJaTJjLWFkZHJlc3MgPSA8MHg0Zj47CisJCX07CisJfTsKK307CisuRWQKKy5Q cAogV2hlcmU6CiAuQmwgLXRhZyAtd2lkdGggIi5WYSBjb21wYXRpYmxlIgogLkl0IFZhIGNvbXBh dGlibGUKLVNob3VsZCBhbHdheXMgYmUgc2V0IHRvICJncGlvaWljIi4KK1Nob3VsZCBiZSBzZXQg dG8gImdwaW9paWMiIG9yICJpMmMtZ3BpbyIuCiAuSXQgVmEgZ3Bpb3MKIFRoZQogLlZhIGdwaW9z Cg== --f46d0444ecaf21df5704f4ccf00f Content-Type: text/plain; charset=US-ASCII; name="gpioiic-gpioled-freebsd-specific.diff" Content-Disposition: attachment; filename="gpioiic-gpioled-freebsd-specific.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvr29wf1 SW5kZXg6IHN5cy9kZXYvZ3Bpby9ncGlvbGVkLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9ncGlv L2dwaW9sZWQuYwkocmV2aXNpb24gMjYyMTMxKQorKysgc3lzL2Rldi9ncGlvL2dwaW9sZWQuYwko d29ya2luZyBjb3B5KQpAQCAtMTI4LDcgKzEyOCw3IEBACiAJICogbGVkcyBub2RlcyBvbiB0aGUg ZHRzLgogCSAqLwogCW1hdGNoID0gMDsKLQlpZiAob2Z3X2J1c19pc19jb21wYXRpYmxlKGRldiwg ImdwaW9sZWQiKSkKKwlpZiAob2Z3X2J1c19pc19jb21wYXRpYmxlKGRldiwgImZyZWVic2QsZ3Bp b2xlZCIpKQogCQltYXRjaCA9IDE7CiAKIAlpZiAobWF0Y2ggPT0gMCkgewotLS0gc3lzL2Rldi9n cGlvL2dwaW9paWMuYy5vcmlnCTIwMTQtMDMtMTEgMTU6MjI6MzMuMjkxOTc4OTc1IC0wMzAwCisr KyBzeXMvZGV2L2dwaW8vZ3Bpb2lpYy5jCTIwMTQtMDMtMTEgMTU6MjM6MTAuODA5OTc2MDYzIC0w MzAwCkBAIC02MCw3ICs2MCw3IEBACiAjZGVmaW5lCUFUVEFDSF9JMkNHUElPCTIKIAogc3RhdGlj IHN0cnVjdCBvZndfY29tcGF0X2RhdGEgY29tcGF0X2RhdGFbXSA9IHsKLQl7ICJncGlvaWljIiwJ CUFUVEFDSF9HUElPSUlDIH0sCisJeyAiZnJlZWJzZCxncGlvaWljIiwJQVRUQUNIX0dQSU9JSUMg fSwKIAl7ICJpMmMtZ3BpbyIsCQlBVFRBQ0hfSTJDR1BJTyB9LAogCXsgTlVMTCwJCQlBVFRBQ0hf Tk9ORSB9LAogfTsKSW5kZXg6IHNoYXJlL21hbi9tYW40L2dwaW9sZWQuNAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBzaGFyZS9tYW4vbWFuNC9ncGlvbGVkLjQJKHJldmlzaW9uIDI2MjEzMSkKKysrIHNoYXJlL21h bi9tYW40L2dwaW9sZWQuNAkod29ya2luZyBjb3B5KQpAQCAtMjQsNyArMjQsNyBAQAogLlwiCiAu XCIgJEZyZWVCU0QkCiAuXCIKLS5EZCBGZWJydWFyeSAxMywgMjAxNAorLkRkIE1hcmNoIDExLCAy MDE0CiAuRHQgR1BJT0xFRCA0CiAuT3MKIC5TaCBOQU1FCkBAIC04MiwxMyArODIsMTMgQEAKIAku Li4KIAogCWxlZDAgewotCQljb21wYXRpYmxlID0gImdwaW9sZWQiOworCQljb21wYXRpYmxlID0g ImZyZWVic2QsZ3Bpb2xlZCI7CiAJCWdwaW9zID0gPCZncGlvIDE2IDIgMD47CQkvKiBHUElPIHBp biAxNi4gKi8KIAkJbmFtZSA9ICJvayI7CiAJfTsKIAogCWxlZDEgewotCQljb21wYXRpYmxlID0g ImdwaW9sZWQiOworCQljb21wYXRpYmxlID0gImZyZWVic2QsZ3Bpb2xlZCI7CiAJCWdwaW9zID0g PCZncGlvIDE3IDIgMD47CQkvKiBHUElPIHBpbiAxNy4gKi8KIAkJbmFtZSA9ICJ1c2VyLWxlZDEi OwogCX07Ci0tLSBzaGFyZS9tYW4vbWFuNC9ncGlvaWljLjQub3JpZwkyMDE0LTAzLTE2IDEwOjQ2 OjQxLjU4MjQ4NDE3OSAtMDMwMAorKysgc2hhcmUvbWFuL21hbjQvZ3Bpb2lpYy40CTIwMTQtMDMt MTYgMTA6NDY6MTguNTU3NDg0NDUzIC0wMzAwCkBAIC05NSw3ICs5NSw3IEBACiAJLi4uCiAKIAln cGlvaWljMCB7Ci0JCWNvbXBhdGlibGUgPSAiZ3Bpb2lpYyI7CisJCWNvbXBhdGlibGUgPSAiZnJl ZWJzZCxncGlvaWljIjsKIAkJLyoKIAkJICogQXR0YWNoIHRvIEdQSU8gcGlucyAyMSBhbmQgMjIu ICBTZXQgdGhlbQogCQkgKiBpbml0aWFsbHkgYXMgaW5wdXRzLgpAQCAtMTA3LDcgKzEwNyw3IEBA CiAKIAkJLyogVGhpcyBpcyBhbiBleGFtcGxlIG9mIGEgZ3Bpb2lpYyBjaGlsZC4gKi8KIAkJZ3Bp b2lpYy1jaGlsZDAgewotCQkJY29tcGF0aWJsZSA9ICJsbTc1IjsKKwkJCWNvbXBhdGlibGUgPSAi ZnJlZWJzZCxsbTc1IjsKIAkJCWkyYy1hZGRyZXNzID0gPDB4NGY+OwogCQl9OwogCX07CkBAIC0x MzEsNyArMTMxLDcgQEAKIAogCQkvKiBUaGlzIGlzIGFub3RoZXIgZXhhbXBsZSBvZiBhIGdwaW9p aWMgY2hpbGQuICovCiAJCWdwaW9paWMtY2hpbGQwIHsKLQkJCWNvbXBhdGlibGUgPSAibG03NSI7 CisJCQljb21wYXRpYmxlID0gImZyZWVic2QsbG03NSI7CiAJCQlpMmMtYWRkcmVzcyA9IDwweDRm PjsKIAkJfTsKIAl9OwpAQCAtMTQxLDcgKzE0MSw3IEBACiBXaGVyZToKIC5CbCAtdGFnIC13aWR0 aCAiLlZhIGNvbXBhdGlibGUiCiAuSXQgVmEgY29tcGF0aWJsZQotU2hvdWxkIGJlIHNldCB0byAi Z3Bpb2lpYyIgb3IgImkyYy1ncGlvIi4KK1Nob3VsZCBiZSBzZXQgdG8gImZyZWVic2QsZ3Bpb2lp YyIgb3IgImkyYy1ncGlvIi4KIC5JdCBWYSBncGlvcwogVGhlCiAuVmEgZ3Bpb3MK --f46d0444ecaf21df5704f4ccf00f-- From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 13:31:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74509318; Mon, 17 Mar 2014 13:31:57 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0701368; Mon, 17 Mar 2014 13:31:56 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id cc10so2152779wib.4 for ; Mon, 17 Mar 2014 06:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aRoczenZ3BV+5U6wqvyC8hIzYvNtMrcV5cCmZWyy/7A=; b=d8D7kgntvMLQYDsP5Biq/BI+fI9Lad83SguZDxD+DDOlxZv/09bd5nHhWf+yM5A6/b oGwe41Y4BdTsbytljsAjZFHkmgu30x7CNSeww002LxQUot7OFbWXARZvqoWr/pDq0brU B4i7NZWl/eKAepoSzOfAJvwW9ltVqMEXCojb3lnyw43dVdJSBJZVNJNzVT26cw6swGTc gIBjYX85zaObYTxJuX+gOg7+WgapO2xf31OJ7ZcazV1QQf4ZruRbvA4viQenoa5k0Gpa PLVZgfpJlYrxd4robq74OPC/A2wU7KNg5yVqApBkshI3wtR0LhxP0h6OEzah+bs0fBmA rN8Q== MIME-Version: 1.0 X-Received: by 10.180.21.225 with SMTP id y1mr9602005wie.24.1395063115145; Mon, 17 Mar 2014 06:31:55 -0700 (PDT) Received: by 10.216.79.132 with HTTP; Mon, 17 Mar 2014 06:31:54 -0700 (PDT) Date: Mon, 17 Mar 2014 10:31:54 -0300 Message-ID: Subject: [RFC] AM335x (Beaglebone-black) ADC driver From: Luiz Otavio O Souza To: freebsd-arm@freebsd.org, "freebsd-embedded@freebsd.org" Content-Type: multipart/mixed; boundary=047d7bb709886b3cc004f4cd7118 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 13:31:57 -0000 --047d7bb709886b3cc004f4cd7118 Content-Type: text/plain; charset=ISO-8859-1 Hi, I've written a driver for the am335x ADC module (AIN inputs on BBB). It works from the sysctl(8) interface, each input can be individually enabled/disabled. When all the inputs are disabled, the ADC is turned off. The sysctl(8) interface also allows the selection of the number of the samples average for each input (none, 2, 4, 8, 16) and the setting of the ADC prescaler value (low clock speeds gives far stable readings with the cost of loading - sometimes too much - the input circuit as conversions can take a long time). The converted values are exported as raw values (12 bits - 0 ~ 4095). The ADC module can also work as a touchscreen sensor, but i have no idea how to program the module as TSC sensor neither have the hardware to test it, so this driver only works for reading the AIN converted values. Here is the output of the sysctl(8) for this driver: # sysctl dev.am335x_adc.0 dev.am335x_adc.0.%desc: AM335x ADC controller dev.am335x_adc.0.%driver: am335x_adc dev.am335x_adc.0.%pnpinfo: name=adc@44E0D000 compat=ti,am335x-adc dev.am335x_adc.0.%parent: simplebus0 dev.am335x_adc.0.clockdiv: 30000 dev.am335x_adc.0.ain.0.enable: 0 dev.am335x_adc.0.ain.0.samples_avg: 0 dev.am335x_adc.0.ain.0.input: 0 dev.am335x_adc.0.ain.1.enable: 0 dev.am335x_adc.0.ain.1.samples_avg: 0 dev.am335x_adc.0.ain.1.input: 0 dev.am335x_adc.0.ain.2.enable: 0 dev.am335x_adc.0.ain.2.samples_avg: 0 dev.am335x_adc.0.ain.2.input: 0 dev.am335x_adc.0.ain.3.enable: 0 dev.am335x_adc.0.ain.3.samples_avg: 0 dev.am335x_adc.0.ain.3.input: 0 dev.am335x_adc.0.ain.4.enable: 0 dev.am335x_adc.0.ain.4.samples_avg: 0 dev.am335x_adc.0.ain.4.input: 0 dev.am335x_adc.0.ain.5.enable: 0 dev.am335x_adc.0.ain.5.samples_avg: 0 dev.am335x_adc.0.ain.5.input: 0 dev.am335x_adc.0.ain.6.enable: 1 dev.am335x_adc.0.ain.6.samples_avg: 0 dev.am335x_adc.0.ain.6.input: 2176 I've checked the 7 AINs with a potentiometer connected to them (and using VDD_ADC and GNDA_ADC). I am now writing the man page so i can ask for a approval to commit it. Comments ? Regards, Luiz --047d7bb709886b3cc004f4cd7118 Content-Type: text/plain; charset=US-ASCII; name="am335x_adc.diff" Content-Disposition: attachment; filename="am335x_adc.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvse87w0 SW5kZXg6IHN5cy9hcm0vdGkvYW0zMzV4L2FtMzM1eF9wcmNtLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lz L2FybS90aS9hbTMzNXgvYW0zMzV4X3ByY20uYwkocmV2aXNpb24gMjYyMTMxKQorKysgc3lzL2Fy bS90aS9hbTMzNXgvYW0zMzV4X3ByY20uYwkod29ya2luZyBjb3B5KQpAQCAtMTA3LDYgKzEwNyw3 IEBACiAjZGVmaW5lIENNX1dLVVBfQ01fQ0xLRENPTERPX0RQTExfUEVSCShDTV9XS1VQICsgMHgw N0MpCiAjZGVmaW5lIENNX1dLVVBfQ01fQ0xLTU9ERV9EUExMX0RJU1AJKENNX1dLVVAgKyAweDA5 OCkKICNkZWZpbmUgQ01fV0tVUF9JMkMwX0NMS0NUUkwJCShDTV9XS1VQICsgMHgwQjgpCisjZGVm aW5lIENNX1dLVVBfQURDX1RTQ19DTEtDVFJMCQkoQ01fV0tVUCArIDB4MEJDKQogCiAjZGVmaW5l IENNX0RQTEwJCQkJMHg1MDAKICNkZWZpbmUgQ0xLU0VMX1RJTUVSN19DTEsJCShDTV9EUExMICsg MHgwMDQpCkBAIC0yNjAsNiArMjYxLDkgQEAKIAlBTTMzNVhfR0VORVJJQ19DTE9DS19ERVYoSTJD MV9DTEspLAogCUFNMzM1WF9HRU5FUklDX0NMT0NLX0RFVihJMkMyX0NMSyksCiAKKwkvKiBUU0Nf QURDICovCisJQU0zMzVYX0dFTkVSSUNfQ0xPQ0tfREVWKFRTQ19BRENfQ0xLKSwKKwogCS8qIEVE TUEgKi8KIAlBTTMzNVhfR0VORVJJQ19DTE9DS19ERVYoRURNQV9UUENDX0NMSyksCiAJQU0zMzVY X0dFTkVSSUNfQ0xPQ0tfREVWKEVETUFfVFBUQzBfQ0xLKSwKQEAgLTMzNyw2ICszNDEsOSBAQAog CV9DTEtfREVUQUlMKEkyQzFfQ0xLLCBDTV9QRVJfSTJDMV9DTEtDVFJMLCAwKSwKIAlfQ0xLX0RF VEFJTChJMkMyX0NMSywgQ01fUEVSX0kyQzJfQ0xLQ1RSTCwgMCksCiAKKwkvKiBUU0NfQURDIG1v ZHVsZSAqLworCV9DTEtfREVUQUlMKFRTQ19BRENfQ0xLLCBDTV9XS1VQX0FEQ19UU0NfQ0xLQ1RS TCwgMCksCisKIAkvKiBFRE1BIG1vZHVsZXMgKi8KIAlfQ0xLX0RFVEFJTChFRE1BX1RQQ0NfQ0xL LCBDTV9QRVJfVFBDQ19DTEtDVFJMLCAwKSwKIAlfQ0xLX0RFVEFJTChFRE1BX1RQVEMwX0NMSywg Q01fUEVSX1RQVEMwX0NMS0NUUkwsIDApLApJbmRleDogc3lzL2FybS90aS9hbTMzNXgvZmlsZXMu YmVhZ2xlYm9uZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYXJtL3RpL2FtMzM1eC9maWxlcy5iZWFnbGVi b25lCShyZXZpc2lvbiAyNjIxMzEpCisrKyBzeXMvYXJtL3RpL2FtMzM1eC9maWxlcy5iZWFnbGVi b25lCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsNCBAQAogIyRGcmVlQlNEJAogCithcm0vdGkv YW0zMzV4L2FtMzM1eF9hZGMuYwkJCW9wdGlvbmFsCWFtMzM1eF9hZGMKIGFybS90aS9hbTMzNXgv YW0zMzV4X3BtaWMuYwkJCW9wdGlvbmFsCWFtMzM1eF9wbWljCkluZGV4OiBzeXMvYXJtL3RpL3Rp X3ByY20uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYXJtL3RpL3RpX3ByY20uaAkocmV2aXNpb24gMjYy MTMxKQorKysgc3lzL2FybS90aS90aV9wcmNtLmgJKHdvcmtpbmcgY29weSkKQEAgLTE2Miw2ICsx NjIsOCBAQAogCiAJUFJVU1NfQ0xLID0gMTcwMCwKIAorCVRTQ19BRENfQ0xLID0gMTgwMCwKKwog CUlOVkFMSURfQ0xLX0lERU5UCiAKIH0gY2xrX2lkZW50X3Q7Ci0tLSAvZGV2L251bGwJMjAxNC0w My0xNiAxMTowMDowMC4wMDAwMDAwMDAgLTAzMDAKKysrIHN5cy9hcm0vdGkvYW0zMzV4L2FtMzM1 eF9hZGMuYwkyMDE0LTAzLTE1IDIzOjQ4OjM3LjA5OTIwNTgwMyAtMDMwMApAQCAtMCwwICsxLDQ5 NyBAQAorLyotCisgKiBDb3B5cmlnaHQgMjAxNCBMdWl6IE90YXZpbyBPIFNvdXphIDxsb29zQGZy ZWVic2Qub3JnPgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlv biBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAq IG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcg Y29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2Ug Y29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMg bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBS ZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNv cHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZv bGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3Ro ZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElT IFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFT IElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElO RywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJD SEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUg RElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JT IEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVD SUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywg QlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBP UiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElO VEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJ TElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQg KElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisg KiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhF IFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2Nk ZWZzLmg+CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4K KyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvYnVzLmg+CisKKyNpbmNsdWRl IDxzeXMva2VybmVsLmg+CisjaW5jbHVkZSA8c3lzL2xvY2suaD4KKyNpbmNsdWRlIDxzeXMvbW9k dWxlLmg+CisjaW5jbHVkZSA8c3lzL211dGV4Lmg+CisjaW5jbHVkZSA8c3lzL3Jlc291cmNlLmg+ CisjaW5jbHVkZSA8c3lzL3JtYW4uaD4KKyNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CisKKyNpbmNs dWRlIDxtYWNoaW5lL2J1cy5oPgorCisjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgorI2lu Y2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJy Lmg+CisKKyNpbmNsdWRlIDxhcm0vdGkvdGlfcHJjbS5oPgorI2luY2x1ZGUgPGFybS90aS9hbTMz NXgvYW0zMzV4X2FkY3JlZy5oPgorI2luY2x1ZGUgPGFybS90aS9hbTMzNXgvYW0zMzV4X2FkY3Zh ci5oPgorCisvKiBEZWZpbmUgb3VyIDcgc3RlcHMsIG9uZSBmb3IgZWFjaCBpbnB1dCBjaGFubmVs LiAqLworc3RhdGljIHN0cnVjdCBhbTMzNXhfYWRjX2lucHV0IGFtMzM1eF9hZGNfaW5wdXRzW0FN MzM1WF9BRENfTlBJTlNdID0geworCXsgLnN0ZXByZWcgPSBBRENfU1RFUENGRzEsIH0sCisJeyAu c3RlcHJlZyA9IEFEQ19TVEVQQ0ZHMiwgfSwKKwl7IC5zdGVwcmVnID0gQURDX1NURVBDRkczLCB9 LAorCXsgLnN0ZXByZWcgPSBBRENfU1RFUENGRzQsIH0sCisJeyAuc3RlcHJlZyA9IEFEQ19TVEVQ Q0ZHNSwgfSwKKwl7IC5zdGVwcmVnID0gQURDX1NURVBDRkc2LCB9LAorCXsgLnN0ZXByZWcgPSBB RENfU1RFUENGRzcsIH0sCit9OworCitzdGF0aWMgaW50IGFtMzM1eF9hZGNfc2FtcGxlc1s1XSA9 IHsgMCwgMiwgNCwgOCwgMTYgfTsKKworc3RhdGljIHZvaWQKK2FtMzM1eF9hZGNfZW5hYmxlKHN0 cnVjdCBhbTMzNXhfYWRjX3NvZnRjICpzYykKK3sKKwl1aW50MzJfdCB2YWw7CisKKwlBTTMzNVhf QURDX0xPQ0tfQVNTRVJUKHNjKTsKKworCS8qIEVuYWJsZSB0aGUgRklGTzAgdGhyZXNob2xkIGlu dGVycnVwdC4gKi8KKwlBRENfV1JJVEU0KHNjLCBBRENfSVJRRU5BQkxFX1NFVCwgQURDX0lSUV9G SUZPMF9USFJFUyk7CisKKwkvKiBFbmFibGUgdGhlIEFEQy4gIFJ1biB0aHJ1IGVuYWJsZWQgc3Rl cHMsIHN0YXJ0IHRoZSBjb252ZXJ0aW9ucy4gKi8KKwl2YWwgPSBBRENfUkVBRDQoc2MsIEFEQ19D VFJMKTsKKwlBRENfV1JJVEU0KHNjLCBBRENfQ1RSTCwgdmFsIHwgQURDX0NUUkxfRU5BQkxFKTsK K30KKworc3RhdGljIHZvaWQKK2FtMzM1eF9hZGNfZGlzYWJsZShzdHJ1Y3QgYW0zMzV4X2FkY19z b2Z0YyAqc2MpCit7CisJdWludDMyX3QgdmFsOworCisJQU0zMzVYX0FEQ19MT0NLX0FTU0VSVChz Yyk7CisKKwkvKiBEaXNhYmxlIHRoZSBGSUZPMCB0aHJlc2hvbGQgaW50ZXJydXB0LiAqLworCUFE Q19XUklURTQoc2MsIEFEQ19JUlFFTkFCTEVfQ0xSLCBBRENfSVJRX0ZJRk8wX1RIUkVTKTsKKwor CS8qIERpc2FibGUgdGhlIEFEQy4gKi8KKwl2YWwgPSBBRENfUkVBRDQoc2MsIEFEQ19DVFJMKTsK Kwl2YWwgJj0gfkFEQ19DVFJMX0VOQUJMRTsKKwlBRENfV1JJVEU0KHNjLCBBRENfQ1RSTCwgdmFs KTsKK30KKworc3RhdGljIHZvaWQKK2FtMzM1eF9hZGNfZW5hYmxlX2lucHV0KHN0cnVjdCBhbTMz NXhfYWRjX3NvZnRjICpzYywgaW50MzJfdCBpbnB1dCkKK3sKKwl1aW50MzJfdCByZWcsIHZhbDsK KworCUFNMzM1WF9BRENfTE9DS19BU1NFUlQoc2MpOworCisJcmVnID0gYW0zMzV4X2FkY19pbnB1 dHNbaW5wdXRdLnN0ZXByZWc7CisJdmFsID0gQURDX1JFQUQ0KHNjLCByZWcpOworCisJLyogU2V0 IHRoZSBuZWdhdGl2ZSB2b2x0YWdlIHJlZmVyZW5jZS4gKi8KKwl2YWwgJj0gfkFEQ19TVEVQX1JG TV9NU0s7CisJdmFsIHw9IEFEQ19TVEVQX1JGTV9WUkVGTiA8PCBBRENfU1RFUF9SRk1fU0hJRlQ7 CisKKwkvKiBTZXQgdGhlIHBvc2l0aXZlIHZvbHRhZ2UgcmVmZXJlbmNlLiAqLworCXZhbCAmPSB+ QURDX1NURVBfUkZQX01TSzsKKwl2YWwgfD0gQURDX1NURVBfUkZQX1ZSRUZQIDw8IEFEQ19TVEVQ X1JGUF9TSElGVDsKKworCS8qIFNldCB0aGUgc2FtcGxlcyBhdmVyYWdlLiAqLworCXZhbCAmPSB+ QURDX1NURVBfQVZHX01TSzsKKwl2YWwgfD0gYW0zMzV4X2FkY19pbnB1dHNbaW5wdXRdLnNhbXBs ZXMgPDwgQURDX1NURVBfQVZHX1NISUZUOworCisJLyogU2VsZWN0IHRoZSBkZXNpcmVkIGlucHV0 LiAqLworCXZhbCAmPSB+QURDX1NURVBfSU5QX01TSzsKKwl2YWwgfD0gaW5wdXQgPDwgQURDX1NU RVBfSU5QX1NISUZUOworCisJLyogU2V0IHRoZSBBREMgdG8gY29udGludW91cyBtb2RlLiAqLwor CXZhbCAmPSB+QURDX1NURVBfTU9ERV9NU0s7CisJdmFsIHw9IEFEQ19TVEVQX01PREVfQ09OVElO VU9VUzsKKworCUFEQ19XUklURTQoc2MsIHJlZywgdmFsKTsKK30KKworc3RhdGljIHZvaWQKK2Ft MzM1eF9hZGNfZGlzYWJsZV9pbnB1dChzdHJ1Y3QgYW0zMzV4X2FkY19zb2Z0YyAqc2MsIGludDMy X3QgaW5wdXQpCit7CisJdWludDMyX3QgcmVnLCB2YWw7CisKKwlBTTMzNVhfQURDX0xPQ0tfQVNT RVJUKHNjKTsKKworCS8qIFJlc2V0IHRoZSBpbnB1dCByZWFkIGRhdGEuICovCisJYW0zMzV4X2Fk Y19pbnB1dHNbaW5wdXRdLnZhbHVlID0gMDsKKworCXJlZyA9IGFtMzM1eF9hZGNfaW5wdXRzW2lu cHV0XS5zdGVwcmVnOworCXZhbCA9IEFEQ19SRUFENChzYywgcmVnKTsKKworCS8qIFJlc2V0IHRo ZSBBREMgb3BlcmF0aW9uIG1vZGUuICovCisJdmFsICY9IH5BRENfU1RFUF9NT0RFX01TSzsKKwor CS8qIFJlc2V0IHRoZSBpbnB1dCBwaW4gc2VsZWN0aW9uLiAqLworCXZhbCAmPSB+QURDX1NURVBf SU5QX01TSzsKKworCS8qIFJlc2V0IHRoZSBzYW1wbGVzIGF2ZXJhZ2UuICovCisJdmFsICY9IH5B RENfU1RFUF9BVkdfTVNLOworCisJLyogUmVzZXQgdGhlIHBvc2l0aXZlIHZvbHRhZ2UgcmVmZXJl bmNlLiAqLworCXZhbCAmPSB+QURDX1NURVBfUkZQX01TSzsKKworCS8qIFJlc2V0IHRoZSBuZWdh dGl2ZSB2b2x0YWdlIHJlZmVyZW5jZS4gKi8KKwl2YWwgJj0gfkFEQ19TVEVQX1JGTV9NU0s7CisK KwlBRENfV1JJVEU0KHNjLCByZWcsIHZhbCk7Cit9CisKK3N0YXRpYyB2b2lkCithbTMzNXhfYWRj X3Jlc2V0KHN0cnVjdCBhbTMzNXhfYWRjX3NvZnRjICpzYykKK3sKKwlpbnQgaTsKKworCUFNMzM1 WF9BRENfTE9DS19BU1NFUlQoc2MpOworCisJLyogRGlzYWJsZSBhbGwgdGhlIGlucHV0cy4gKi8K Kwlmb3IgKGkgPSAwOyBpIDwgQU0zMzVYX0FEQ19OUElOUzsgaSsrKQorCQlhbTMzNXhfYWRjX2lu cHV0c1tpXS5lbmFibGUgPSAwOworfQorCitzdGF0aWMgaW50CithbTMzNXhfYWRjX3NldHVwKHN0 cnVjdCBhbTMzNXhfYWRjX3NvZnRjICpzYykKK3sKKwlpbnQgZW5hYmxlZCwgaTsKKworCUFNMzM1 WF9BRENfTE9DS19BU1NFUlQoc2MpOworCisJLyogQ2hlY2sgaWYgd2UgaGF2ZSBhbnkgaW5wdXQg ZW5hYmxlZC4gKi8KKwllbmFibGVkID0gMDsKKwlmb3IgKGkgPSAwOyBpIDwgQU0zMzVYX0FEQ19O UElOUzsgaSsrKSB7CisJCWlmIChhbTMzNXhfYWRjX2lucHV0c1tpXS5lbmFibGUpIHsKKwkJCWVu YWJsZWQgfD0gKDFVIDw8IChpICsgMSkpOworCQkJYW0zMzV4X2FkY19lbmFibGVfaW5wdXQoc2Ms IGkpOworCQl9IGVsc2UKKwkJCWFtMzM1eF9hZGNfZGlzYWJsZV9pbnB1dChzYywgaSk7CisJfQor CisJLyogRW5hYmxlIHRoZSBzZWxlY3RlZCBzdGVwcy4gKi8KKwlBRENfV1JJVEU0KHNjLCBBRENf U1RFUEVOQUJMRSwgZW5hYmxlZCk7CisKKwkvKiBTZXQgdGhlIGdsb2JhbCBBREMgc3RhdHVzLiAq LworCWlmIChlbmFibGVkICE9IDApCisJCWFtMzM1eF9hZGNfZW5hYmxlKHNjKTsKKwllbHNlCisJ CWFtMzM1eF9hZGNfZGlzYWJsZShzYyk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50 CithbTMzNXhfYWRjX2Nsb2NrZGl2X3Byb2MoU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwlpbnQg ZXJyb3IsIHJlZzsKKwlzdHJ1Y3QgYW0zMzV4X2FkY19zb2Z0YyAqc2M7CisKKwlzYyA9IChzdHJ1 Y3QgYW0zMzV4X2FkY19zb2Z0YyAqKWFyZzE7CisKKwlBTTMzNVhfQURDX0xPQ0soc2MpOworCXJl ZyA9IChpbnQpQURDX1JFQUQ0KHNjLCBBRENfQ0xLRElWKSArIDE7CisJQU0zMzVYX0FEQ19VTkxP Q0soc2MpOworCisJZXJyb3IgPSBzeXNjdGxfaGFuZGxlX2ludChvaWRwLCAmcmVnLCBzaXplb2Yo cmVnKSwgcmVxKTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5ld3B0ciA9PSBOVUxMKQorCQly ZXR1cm4gKGVycm9yKTsKKworCS8qIFRoZSBhY3R1YWwgd3JpdHRlbiB2YWx1ZSBpcyB0aGUgcHJl c2NhbGVyIHNldHRpbmcgLSAxLiAqLworCXJlZy0tOworCWlmIChyZWcgPCAwKQorCQlyZWcgPSAw OworCWlmIChyZWcgPiA2NTUzNSkKKwkJcmVnID0gNjU1MzU7CisKKwlBTTMzNVhfQURDX0xPQ0so c2MpOworCS8qIERpc2FibGUgdGhlIEFEQy4gKi8KKwlhbTMzNXhfYWRjX2Rpc2FibGUoc2MpOwor CS8qIFVwZGF0ZSB0aGUgQURDIHByZXNjYWxlciBzZXR0aW5nLiAqLworCUFEQ19XUklURTQoc2Ms IEFEQ19DTEtESVYsIHJlZyk7CisJLyogRW5hYmxlIHRoZSBBREMgYWdhaW4uICovCisJYW0zMzV4 X2FkY19zZXR1cChzYyk7CisJQU0zMzVYX0FEQ19VTkxPQ0soc2MpOworCisJcmV0dXJuICgwKTsK K30KKworc3RhdGljIGludAorYW0zMzV4X2FkY19lbmFibGVfcHJvYyhTWVNDVExfSEFORExFUl9B UkdTKQoreworCWludCBlcnJvcjsKKwlpbnQzMl90IGVuYWJsZTsKKwlzdHJ1Y3QgYW0zMzV4X2Fk Y19zb2Z0YyAqc2M7CisJc3RydWN0IGFtMzM1eF9hZGNfaW5wdXQgKmlucHV0OworCisJaW5wdXQg PSAoc3RydWN0IGFtMzM1eF9hZGNfaW5wdXQgKilhcmcxOworCXNjID0gaW5wdXQtPnNjOworCisJ ZW5hYmxlID0gaW5wdXQtPmVuYWJsZTsKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVfaW50KG9pZHAs ICZlbmFibGUsIHNpemVvZihlbmFibGUpLAorCSAgICByZXEpOworCWlmIChlcnJvciAhPSAwIHx8 IHJlcS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVybiAoZXJyb3IpOworCisJaWYgKGVuYWJsZSkK KwkJZW5hYmxlID0gMTsKKworCUFNMzM1WF9BRENfTE9DSyhzYyk7CisJLyogU2V0dXAgdGhlIEFE QyBhcyBuZWVkZWQuICovCisJaWYgKGlucHV0LT5lbmFibGUgIT0gZW5hYmxlKSB7CisJCWlucHV0 LT5lbmFibGUgPSBlbmFibGU7CisJCWFtMzM1eF9hZGNfc2V0dXAoc2MpOworCX0KKwlBTTMzNVhf QURDX1VOTE9DSyhzYyk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CithbTMzNXhf YWRjX3NhbXBsZXNfYXZnX3Byb2MoU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwlpbnQgZXJyb3Is IHNhbXBsZXMsIGk7CisJc3RydWN0IGFtMzM1eF9hZGNfc29mdGMgKnNjOworCXN0cnVjdCBhbTMz NXhfYWRjX2lucHV0ICppbnB1dDsKKworCWlucHV0ID0gKHN0cnVjdCBhbTMzNXhfYWRjX2lucHV0 ICopYXJnMTsKKwlzYyA9IGlucHV0LT5zYzsKKworCWlmIChpbnB1dC0+c2FtcGxlcyA+IG5pdGVt cyhhbTMzNXhfYWRjX3NhbXBsZXMpKQorCQlpbnB1dC0+c2FtcGxlcyA9IG5pdGVtcyhhbTMzNXhf YWRjX3NhbXBsZXMpOworCXNhbXBsZXMgPSBhbTMzNXhfYWRjX3NhbXBsZXNbaW5wdXQtPnNhbXBs ZXNdOworCisJZXJyb3IgPSBzeXNjdGxfaGFuZGxlX2ludChvaWRwLCAmc2FtcGxlcywgMCwgcmVx KTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5ld3B0ciA9PSBOVUxMKQorCQlyZXR1cm4gKGVy cm9yKTsKKworCWlmIChzYW1wbGVzICE9IGFtMzM1eF9hZGNfc2FtcGxlc1tpbnB1dC0+c2FtcGxl c10pIHsKKwkJQU0zMzVYX0FEQ19MT0NLKHNjKTsKKwkJYW0zMzV4X2FkY19kaXNhYmxlKHNjKTsK KwkJaW5wdXQtPnNhbXBsZXMgPSAwOworCQlmb3IgKGkgPSAwOyBpIDwgbml0ZW1zKGFtMzM1eF9h ZGNfc2FtcGxlcyk7IGkrKykKKwkJCWlmIChzYW1wbGVzID49IGFtMzM1eF9hZGNfc2FtcGxlc1tp XSkKKwkJCQlpbnB1dC0+c2FtcGxlcyA9IGk7CisKKwkJLyogVXBkYXRlIHRoZSBBREMgc2V0dXAg YXMgbmVlZGVkLiAqLworCQlhbTMzNXhfYWRjX3NldHVwKHNjKTsKKwkJQU0zMzVYX0FEQ19VTkxP Q0soc2MpOworCX0KKworCXJldHVybiAoZXJyb3IpOworfQorCitzdGF0aWMgdm9pZAorYW0zMzV4 X2FkY19pbnRyKHZvaWQgKmFyZykKK3sKKwlpbnQgY291bnQsIGlucHV0OworCXN0cnVjdCBhbTMz NXhfYWRjX3NvZnRjICpzYzsKKwl1aW50MzJfdCBkYXRhLCBzdGF0dXM7CisKKwlzYyA9IChzdHJ1 Y3QgYW0zMzV4X2FkY19zb2Z0YyAqKWFyZzsKKworCXN0YXR1cyA9IEFEQ19SRUFENChzYywgQURD X0lSUVNUQVRVUyk7CisJaWYgKHN0YXR1cyAmIH5BRENfSVJRX0ZJRk8wX1RIUkVTKQorCQlkZXZp Y2VfcHJpbnRmKHNjLT5zY19kZXYsICJzdHJheSBpbnRlcnJ1cHQ6ICUjeFxuIiwgc3RhdHVzKTsK KworCS8qIENsZWFyIHRoZSBpbnRlcnJ1cHQuICovCisJQURDX1dSSVRFNChzYywgQURDX0lSUVNU QVRVUywgQURDX0lSUV9GSUZPMF9USFJFUyk7CisKKwkvKiBSZWFkIHRoZSBhdmFpbGFibGUgZGF0 YS4gKi8KKwljb3VudCA9IEFEQ19SRUFENChzYywgQURDX0ZJRk8wQ09VTlQpICYgQURDX0ZJRk9f Q09VTlRfTVNLOworCXdoaWxlIChjb3VudC0tID4gMCkgeworCQlkYXRhID0gQURDX1JFQUQ0KHNj LCBBRENfRklGTzBEQVRBKTsKKwkJaW5wdXQgPSAoZGF0YSAmIEFEQ19GSUZPX1NURVBfSURfTVNL KSA+PiBBRENfRklGT19TVEVQX0lEX1NISUZUOworCQlhbTMzNXhfYWRjX2lucHV0c1tpbnB1dF0u dmFsdWUgPSBkYXRhICYgQURDX0ZJRk9fREFUQV9NU0s7CisJfQorfQorCitzdGF0aWMgdm9pZAor YW0zMzV4X2FkY19zeXNjdGxfaW5pdChzdHJ1Y3QgYW0zMzV4X2FkY19zb2Z0YyAqc2MpCit7CisJ Y2hhciBwaW5idWZbM107CisJc3RydWN0IHN5c2N0bF9jdHhfbGlzdCAqY3R4OworCXN0cnVjdCBz eXNjdGxfb2lkICp0cmVlX25vZGUsICppbnBfbm9kZSwgKmlucE5fbm9kZTsKKwlzdHJ1Y3Qgc3lz Y3RsX29pZF9saXN0ICp0cmVlLCAqaW5wX3RyZWUsICppbnBOX3RyZWU7CisJaW50IGk7CisKKwkv KgorCSAqIEFkZCBwZXItcGluIHN5c2N0bCB0cmVlL2hhbmRsZXJzLgorCSAqLworCWN0eCA9IGRl dmljZV9nZXRfc3lzY3RsX2N0eChzYy0+c2NfZGV2KTsKKwl0cmVlX25vZGUgPSBkZXZpY2VfZ2V0 X3N5c2N0bF90cmVlKHNjLT5zY19kZXYpOworCXRyZWUgPSBTWVNDVExfQ0hJTERSRU4odHJlZV9u b2RlKTsKKwlTWVNDVExfQUREX1BST0MoY3R4LCB0cmVlLCBPSURfQVVUTywgImNsb2NrZGl2IiwK KwkgICAgQ1RMRkxBR19SVyB8IENUTFRZUEVfVUlOVCwgIHNjLCAwLAorCSAgICBhbTMzNXhfYWRj X2Nsb2NrZGl2X3Byb2MsICJJVSIsICJBREMgY2xvY2sgcHJlc2NhbGVyIik7CisJaW5wX25vZGUg PSBTWVNDVExfQUREX05PREUoY3R4LCB0cmVlLCBPSURfQVVUTywgImFpbiIsCisJICAgIENUTEZM QUdfUkQsIE5VTEwsICJBREMgaW5wdXRzIik7CisJaW5wX3RyZWUgPSBTWVNDVExfQ0hJTERSRU4o aW5wX25vZGUpOworCisJZm9yIChpID0gMDsgaSA8IEFNMzM1WF9BRENfTlBJTlM7IGkrKykgewor CisJCXNucHJpbnRmKHBpbmJ1Ziwgc2l6ZW9mKHBpbmJ1ZiksICIlZCIsIGkpOworCQlpbnBOX25v ZGUgPSBTWVNDVExfQUREX05PREUoY3R4LCBpbnBfdHJlZSwgT0lEX0FVVE8sIHBpbmJ1ZiwKKwkJ ICAgIENUTEZMQUdfUkQsIE5VTEwsICJBREMgaW5wdXQiKTsKKwkJaW5wTl90cmVlID0gU1lTQ1RM X0NISUxEUkVOKGlucE5fbm9kZSk7CisKKwkJYW0zMzV4X2FkY19pbnB1dHNbaV0uc2MgPSBzYzsK KwkJYW0zMzV4X2FkY19pbnB1dHNbaV0uaW5wdXQgPSBpOworCQlhbTMzNXhfYWRjX2lucHV0c1tp XS52YWx1ZSA9IDA7CisJCWFtMzM1eF9hZGNfaW5wdXRzW2ldLmVuYWJsZSA9IDA7CisJCWFtMzM1 eF9hZGNfaW5wdXRzW2ldLnNhbXBsZXMgPSAwOworCQlTWVNDVExfQUREX1BST0MoY3R4LCBpbnBO X3RyZWUsIE9JRF9BVVRPLCAiZW5hYmxlIiwKKwkJICAgIENUTEZMQUdfUlcgfCBDVExUWVBFX1VJ TlQsICZhbTMzNXhfYWRjX2lucHV0c1tpXSwgMCwKKwkJICAgIGFtMzM1eF9hZGNfZW5hYmxlX3By b2MsICJJVSIsICJFbmFibGUgQURDIGlucHV0Iik7CisJCVNZU0NUTF9BRERfUFJPQyhjdHgsIGlu cE5fdHJlZSwgT0lEX0FVVE8sICJzYW1wbGVzX2F2ZyIsCisJCSAgICBDVExGTEFHX1JXIHwgQ1RM VFlQRV9VSU5ULCAgJmFtMzM1eF9hZGNfaW5wdXRzW2ldLCAwLAorCQkgICAgYW0zMzV4X2FkY19z YW1wbGVzX2F2Z19wcm9jLCAiSVUiLCAiQURDIHNhbXBsZXMgYXZlcmFnZSIpOworCQlTWVNDVExf QUREX0lOVChjdHgsIGlucE5fdHJlZSwgT0lEX0FVVE8sICJpbnB1dCIsCisJCSAgICBDVExGTEFH X1JELCAmYW0zMzV4X2FkY19pbnB1dHNbaV0udmFsdWUsIDAsCisJCSAgICAiQ29udmVydGVkIHZh bHVlIGZvciB0aGUgQURDIGlucHV0Iik7CisJfQorfQorCitzdGF0aWMgaW50CithbTMzNXhfYWRj X3Byb2JlKGRldmljZV90IGRldikKK3sKKworCWlmICghb2Z3X2J1c19pc19jb21wYXRpYmxlKGRl diwgInRpLGFtMzM1eC1hZGMiKSkKKwkJcmV0dXJuIChFTlhJTyk7CisJZGV2aWNlX3NldF9kZXNj KGRldiwgIkFNMzM1eCBBREMgY29udHJvbGxlciIpOworCisJcmV0dXJuIChCVVNfUFJPQkVfREVG QVVMVCk7Cit9CisKK3N0YXRpYyBpbnQKK2FtMzM1eF9hZGNfYXR0YWNoKGRldmljZV90IGRldikK K3sKKwlpbnQgZXJyLCByaWQ7CisJc3RydWN0IGFtMzM1eF9hZGNfc29mdGMgKnNjOworCXVpbnQz Ml90IHJlZywgcmV2OworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJc2MtPnNjX2Rl diA9IGRldjsKKworCXJpZCA9IDA7CisJc2MtPnNjX21lbV9yZXMgPSBidXNfYWxsb2NfcmVzb3Vy Y2VfYW55KGRldiwgU1lTX1JFU19NRU1PUlksICZyaWQsCisJICAgIFJGX0FDVElWRSk7CisJaWYg KCFzYy0+c2NfbWVtX3JlcykgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgImNhbm5vdCBhbGxvY2F0 ZSBtZW1vcnkgd2luZG93XG4iKTsKKwkJcmV0dXJuIChFTlhJTyk7CisJfQorCisJcmlkID0gMDsK KwlzYy0+c2NfaXJxX3JlcyA9IGJ1c19hbGxvY19yZXNvdXJjZV9hbnkoZGV2LCBTWVNfUkVTX0lS USwgJnJpZCwKKwkgICAgUkZfQUNUSVZFKTsKKwlpZiAoIXNjLT5zY19pcnFfcmVzKSB7CisJCWJ1 c19yZWxlYXNlX3Jlc291cmNlKGRldiwgU1lTX1JFU19NRU1PUlksIDAsIHNjLT5zY19tZW1fcmVz KTsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJjYW5ub3QgYWxsb2NhdGUgaW50ZXJydXB0XG4iKTsK KwkJcmV0dXJuIChFTlhJTyk7CisJfQorCisJaWYgKGJ1c19zZXR1cF9pbnRyKGRldiwgc2MtPnNj X2lycV9yZXMsIElOVFJfVFlQRV9NSVNDIHwgSU5UUl9NUFNBRkUsCisJICAgIE5VTEwsIGFtMzM1 eF9hZGNfaW50ciwgc2MsICZzYy0+c2NfaW50cmhhbmQpICE9IDApIHsKKwkJYnVzX3JlbGVhc2Vf cmVzb3VyY2UoZGV2LCBTWVNfUkVTX0lSUSwgMCwgc2MtPnNjX2lycV9yZXMpOworCQlidXNfcmVs ZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNfTUVNT1JZLCAwLCBzYy0+c2NfbWVtX3Jlcyk7CisJ CWRldmljZV9wcmludGYoZGV2LCAiVW5hYmxlIHRvIHNldHVwIHRoZSBpcnEgaGFuZGxlci5cbiIp OworCQlyZXR1cm4gKEVOWElPKTsKKwl9CisKKwkvKiBBY3RpdmF0ZSB0aGUgQURDX1RTQyBtb2R1 bGUuICovCisJZXJyID0gdGlfcHJjbV9jbGtfZW5hYmxlKFRTQ19BRENfQ0xLKTsKKwlpZiAoZXJy KQorCQlyZXR1cm4gKGVycik7CisKKwkvKiBDaGVjayB0aGUgQURDIHJldmlzaW9uLiAqLworCXJl diA9IEFEQ19SRUFENChzYywgQURDX1JFVklTSU9OKTsKKwlkZXZpY2VfcHJpbnRmKGRldiwKKwkg ICAgInNjaGVtZTogJSN4IGZ1bmM6ICUjeCBydGw6ICVkIHJldjogJWQuJWQgY3VzdG9tIHJldjog JWRcbiIsCisJICAgIChyZXYgJiBBRENfUkVWX1NDSEVNRV9NU0spID4+IEFEQ19SRVZfU0NIRU1F X1NISUZULAorCSAgICAocmV2ICYgQURDX1JFVl9GVU5DX01TSykgPj4gQURDX1JFVl9GVU5DX1NI SUZULAorCSAgICAocmV2ICYgQURDX1JFVl9SVExfTVNLKSA+PiBBRENfUkVWX1JUTF9TSElGVCwK KwkgICAgKHJldiAmIEFEQ19SRVZfTUFKT1JfTVNLKSA+PiBBRENfUkVWX01BSk9SX1NISUZULAor CSAgICByZXYgJiBBRENfUkVWX01JTk9SX01TSywKKwkgICAgKHJldiAmIEFEQ19SRVZfQ1VTVE9N X01TSykgPj4gQURDX1JFVl9DVVNUT01fU0hJRlQpOworCisJLyoKKwkgKiBEaXNhYmxlIHRoZSBz dGVwIHdyaXRlIHByb3RlY3QgYW5kIG1ha2UgaXQgc3RvcmUgdGhlIHN0ZXAgSUQgZm9yCisJICog dGhlIGNhcHR1cmVkIGRhdGEgb24gRklGTy4KKwkgKi8KKwlyZWcgPSBBRENfUkVBRDQoc2MsIEFE Q19DVFJMKTsKKwlBRENfV1JJVEU0KHNjLCBBRENfQ1RSTCwgcmVnIHwgQURDX0NUUkxfU1RFUF9X UCB8IEFEQ19DVFJMX1NURVBfSUQpOworCisJLyoKKwkgKiBTZXQgdGhlIEFEQyBwcmVzY2FsZXIg dG8gMjAwMCAoeWVzLCB0aGUgYWN0dWFsIHZhbHVlIHdyaXR0ZW4gaGVyZQorCSAqIGlzIDIwMDAg LSAxKS4KKwkgKi8KKwlBRENfV1JJVEU0KHNjLCBBRENfQ0xLRElWLCAxOTk5KTsKKworCUFNMzM1 WF9BRENfTE9DS19JTklUKHNjKTsKKworCWFtMzM1eF9hZGNfc3lzY3RsX2luaXQoc2MpOworCisJ cmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAorYW0zMzV4X2FkY19kZXRhY2goZGV2aWNlX3Qg ZGV2KQoreworCXN0cnVjdCBhbTMzNXhfYWRjX3NvZnRjICpzYzsKKworCXNjID0gZGV2aWNlX2dl dF9zb2Z0YyhkZXYpOworCisJLyogVHVybiBvZmYgdGhlIEFEQy4gKi8KKwlBTTMzNVhfQURDX0xP Q0soc2MpOworCWFtMzM1eF9hZGNfcmVzZXQoc2MpOworCWFtMzM1eF9hZGNfc2V0dXAoc2MpOwor CUFNMzM1WF9BRENfVU5MT0NLKHNjKTsKKworCUFNMzM1WF9BRENfTE9DS19ERVNUUk9ZKHNjKTsK KworCWlmIChzYy0+c2NfaW50cmhhbmQpCisJCWJ1c190ZWFyZG93bl9pbnRyKGRldiwgc2MtPnNj X2lycV9yZXMsIHNjLT5zY19pbnRyaGFuZCk7CisJaWYgKHNjLT5zY19pcnFfcmVzKQorCQlidXNf cmVsZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNfSVJRLCAwLCBzYy0+c2NfaXJxX3Jlcyk7CisJ aWYgKHNjLT5zY19tZW1fcmVzKQorCQlidXNfcmVsZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNf TUVNT1JZLCAwLCBzYy0+c2NfbWVtX3Jlcyk7CisKKwlyZXR1cm4gKGJ1c19nZW5lcmljX2RldGFj aChkZXYpKTsKK30KKworc3RhdGljIGRldmljZV9tZXRob2RfdCBhbTMzNXhfYWRjX21ldGhvZHNb XSA9IHsKKwlERVZNRVRIT0QoZGV2aWNlX3Byb2JlLAkJYW0zMzV4X2FkY19wcm9iZSksCisJREVW TUVUSE9EKGRldmljZV9hdHRhY2gsCWFtMzM1eF9hZGNfYXR0YWNoKSwKKwlERVZNRVRIT0QoZGV2 aWNlX2RldGFjaCwJYW0zMzV4X2FkY19kZXRhY2gpLAorCisJREVWTUVUSE9EX0VORAorfTsKKwor c3RhdGljIGRyaXZlcl90IGFtMzM1eF9hZGNfZHJpdmVyID0geworCSJhbTMzNXhfYWRjIiwKKwlh bTMzNXhfYWRjX21ldGhvZHMsCisJc2l6ZW9mKHN0cnVjdCBhbTMzNXhfYWRjX3NvZnRjKSwKK307 CisKK3N0YXRpYyBkZXZjbGFzc190IGFtMzM1eF9hZGNfZGV2Y2xhc3M7CisKK0RSSVZFUl9NT0RV TEUoYW0zMzV4X2FkYywgc2ltcGxlYnVzLCBhbTMzNXhfYWRjX2RyaXZlciwgYW0zMzV4X2FkY19k ZXZjbGFzcywgMCwgMCk7CitNT0RVTEVfVkVSU0lPTihhbTMzNXhfYWRjLCAxKTsKK01PRFVMRV9E RVBFTkQoYW0zMzV4X2FkYywgc2ltcGxlYnVzLCAxLCAxLCAxKTsKLS0tIC9kZXYvbnVsbAkyMDE0 LTAzLTE2IDExOjAwOjAwLjAwMDAwMDAwMCAtMDMwMAorKysgc3lzL2FybS90aS9hbTMzNXgvYW0z MzV4X2FkY3JlZy5oCTIwMTQtMDMtMTYgMTE6MDc6NDcuMjA0Mzk2OTcwIC0wMzAwCkBAIC0wLDAg KzEsMTA1IEBACisvKi0KKyAqIENvcHlyaWdodCAyMDE0IEx1aXogT3RhdmlvIE8gU291emEgPGxv b3NAZnJlZWJzZC5vcmc+CisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJp YnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91 dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxv d2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNv dXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwg dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAq IDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJv dmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9v ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAq IFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JT IGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5D TFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElFRCBXQVJSQU5USUVTIE9G IE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAq IEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklC VVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws IFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVE SU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMK KyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5F U1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0Yg TElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1Ig VE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBX QVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBP RiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICoKKyAqICRGcmVlQlNEJAor ICovCisKKyNpZm5kZWYgX0FNMzM1WF9BRENSRUdfSF8KKyNkZWZpbmUgX0FNMzM1WF9BRENSRUdf SF8KKworI2RlZmluZQlBRENfUkVWSVNJT04JCTB4MDAwCisjZGVmaW5lCUFEQ19SRVZfU0NIRU1F X01TSwkJMHhjMDAwMDAwMAorI2RlZmluZQlBRENfUkVWX1NDSEVNRV9TSElGVAkJMzAKKyNkZWZp bmUJQURDX1JFVl9GVU5DX01TSwkJMHgwZmZmMDAwMAorI2RlZmluZQlBRENfUkVWX0ZVTkNfU0hJ RlQJCTE2CisjZGVmaW5lCUFEQ19SRVZfUlRMX01TSwkJCTB4MDAwMGY4MDAKKyNkZWZpbmUJQURD X1JFVl9SVExfU0hJRlQJCTExCisjZGVmaW5lCUFEQ19SRVZfTUFKT1JfTVNLCQkweDAwMDAwNzAw CisjZGVmaW5lCUFEQ19SRVZfTUFKT1JfU0hJRlQJCTgKKyNkZWZpbmUJQURDX1JFVl9DVVNUT01f TVNLCQkweDAwMDAwMGMwCisjZGVmaW5lCUFEQ19SRVZfQ1VTVE9NX1NISUZUCQk2CisjZGVmaW5l CUFEQ19SRVZfTUlOT1JfTVNLCQkweDAwMDAwMDNmCisjZGVmaW5lCUFEQ19TWVNDRkcJCTB4MDEw CisjZGVmaW5lCUFEQ19TWVNDRkdfSURMRV9NU0sJCTB4MDAwMDAwYzAKKyNkZWZpbmUJQURDX1NZ U0NGR19JRExFX1NISUZUCQkyCisjZGVmaW5lCUFEQ19JUlFTVEFUVVNfUkFXCTB4MDI0CisjZGVm aW5lCUFEQ19JUlFTVEFUVVMJCTB4MDI4CisjZGVmaW5lCUFEQ19JUlFFTkFCTEVfU0VUCTB4MDJj CisjZGVmaW5lCUFEQ19JUlFFTkFCTEVfQ0xSCTB4MDMwCisjZGVmaW5lCUFEQ19JUlFfSFdfUEVO X1NZTkMJCSgxIDw8IDEwKQorI2RlZmluZQlBRENfSVJRX1BFTl9VUAkJCSgxIDw8IDkpCisjZGVm aW5lCUFEQ19JUlFfT1VUX1JBTkdFCQkoMSA8PCA4KQorI2RlZmluZQlBRENfSVJRX0ZJRk8xX1VO RFIJCSgxIDw8IDcpCisjZGVmaW5lCUFEQ19JUlFfRklGTzFfT1ZFUlIJCSgxIDw8IDYpCisjZGVm aW5lCUFEQ19JUlFfRklGTzFfVEhSRVMJCSgxIDw8IDUpCisjZGVmaW5lCUFEQ19JUlFfRklGTzBf VU5EUgkJKDEgPDwgNCkKKyNkZWZpbmUJQURDX0lSUV9GSUZPMF9PVkVSUgkJKDEgPDwgMykKKyNk ZWZpbmUJQURDX0lSUV9GSUZPMF9USFJFUwkJKDEgPDwgMikKKyNkZWZpbmUJQURDX0lSUV9FTkRf T0ZfU0VRCQkoMSA8PCAxKQorI2RlZmluZQlBRENfSVJRX0hXX1BFTl9BU1lOQwkJKDEgPDwgMCkK KyNkZWZpbmUJQURDX0NUUkwJCTB4MDQwCisjZGVmaW5lCUFEQ19DVFJMX1NURVBfV1AJCTB4MDAw MDAwMDQKKyNkZWZpbmUJQURDX0NUUkxfU1RFUF9JRAkJMHgwMDAwMDAwMgorI2RlZmluZQlBRENf Q1RSTF9FTkFCTEUJCQkweDAwMDAwMDAxCisjZGVmaW5lCUFEQ19DTEtESVYJCTB4MDRjCisjZGVm aW5lCUFEQ19TVEVQRU5BQkxFCQkweDA1NAorI2RlZmluZQlBRENfU1RFUENGRzEJCTB4MDY0Cisj ZGVmaW5lCUFEQ19TVEVQQ0ZHMgkJMHgwNmMKKyNkZWZpbmUJQURDX1NURVBDRkczCQkweDA3NAor I2RlZmluZQlBRENfU1RFUENGRzQJCTB4MDdjCisjZGVmaW5lCUFEQ19TVEVQQ0ZHNQkJMHgwODQK KyNkZWZpbmUJQURDX1NURVBDRkc2CQkweDA4YworI2RlZmluZQlBRENfU1RFUENGRzcJCTB4MDk0 CisjZGVmaW5lCUFEQ19TVEVQX1JGTV9NU0sJCTB4MDE4MDAwMDAKKyNkZWZpbmUJQURDX1NURVBf UkZNX1NISUZUCQkyMworI2RlZmluZQlBRENfU1RFUF9SRk1fVlNTQQkJMAorI2RlZmluZQlBRENf U1RFUF9SRk1fWE5VUgkJMQorI2RlZmluZQlBRENfU1RFUF9SRk1fWU5MUgkJMgorI2RlZmluZQlB RENfU1RFUF9SRk1fVlJFRk4JCTMKKyNkZWZpbmUJQURDX1NURVBfSU5QX01TSwkJMHgwMDc4MDAw MAorI2RlZmluZQlBRENfU1RFUF9JTlBfU0hJRlQJCTE5CisjZGVmaW5lCUFEQ19TVEVQX0lOTV9N U0sJCTB4MDAwNzgwMDAKKyNkZWZpbmUJQURDX1NURVBfSU5NX1NISUZUCQkxNQorI2RlZmluZQlB RENfU1RFUF9SRlBfTVNLCQkweDAwMDA3MDAwCisjZGVmaW5lCUFEQ19TVEVQX1JGUF9TSElGVAkJ MTIKKyNkZWZpbmUJQURDX1NURVBfUkZQX1ZEREEJCTAKKyNkZWZpbmUJQURDX1NURVBfUkZQX1hQ VUwJCTEKKyNkZWZpbmUJQURDX1NURVBfUkZQX1lQTEwJCTIKKyNkZWZpbmUJQURDX1NURVBfUkZQ X1ZSRUZQCQkzCisjZGVmaW5lCUFEQ19TVEVQX1JGUF9JTlRSRUYJCTQKKyNkZWZpbmUJQURDX1NU RVBfQVZHX01TSwkJMHgwMDAwMDAxYworI2RlZmluZQlBRENfU1RFUF9BVkdfU0hJRlQJCTIKKyNk ZWZpbmUJQURDX1NURVBfTU9ERV9NU0sJCTB4MDAwMDAwMDMKKyNkZWZpbmUJQURDX1NURVBfTU9E RV9PTkVTSE9UCQkweDAwMDAwMDAwCisjZGVmaW5lCUFEQ19TVEVQX01PREVfQ09OVElOVU9VUwkw eDAwMDAwMDAxCisjZGVmaW5lCUFEQ19GSUZPMENPVU5UCQkweDBlNAorI2RlZmluZQlBRENfRklG TzBUSFJFU0hPTEQJMHgwZTgKKyNkZWZpbmUJQURDX0ZJRk8wREFUQQkJMHgxMDAKKyNkZWZpbmUJ QURDX0ZJRk9fQ09VTlRfTVNLCQkweDAwMDAwMDdmCisjZGVmaW5lCUFEQ19GSUZPX1NURVBfSURf TVNLCQkweDAwMGYwMDAwCisjZGVmaW5lCUFEQ19GSUZPX1NURVBfSURfU0hJRlQJCTE2CisjZGVm aW5lCUFEQ19GSUZPX0RBVEFfTVNLCQkweDAwMDAwZmZmCisKKyNlbmRpZiAvKiBfQU0zMzVYX0FE Q1JFR19IXyAqLwotLS0gL2Rldi9udWxsCTIwMTQtMDMtMTYgMTE6MDA6MDAuMDAwMDAwMDAwIC0w MzAwCisrKyBzeXMvYXJtL3RpL2FtMzM1eC9hbTMzNXhfYWRjdmFyLmgJMjAxNC0wMy0xNSAyMjoy Njo0Ny4zMTM1NDI5NTkgLTAzMDAKQEAgLTAsMCArMSw2NyBAQAorLyotCisgKiBDb3B5cmlnaHQg MjAxNCBMdWl6IE90YXZpbyBPIFNvdXphIDxsb29zQGZyZWVic2Qub3JnPgorICogQWxsIHJpZ2h0 cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQg YmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1p dHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoK KyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJv dmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5 IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0 aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRo ZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdp dGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZ IFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVT UyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBU SEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5U IFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBE SVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNF UVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9D VVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0Us IERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIg Q0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFD VCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9S IE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElT IFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNI IERBTUFHRS4KKyAqCisgKiAkRnJlZUJTRCQKKyAqLworCisjaWZuZGVmIF9BTTMzNVhfQURDVkFS X0hfCisjZGVmaW5lIF9BTTMzNVhfQURDVkFSX0hfCisKKyNkZWZpbmUJQU0zMzVYX0FEQ19OUElO Uwk3CisKKyNkZWZpbmUJQURDX1JFQUQ0KF9zYywgcmVnKQlidXNfcmVhZF80KChfc2MpLT5zY19t ZW1fcmVzLCByZWcpCisjZGVmaW5lCUFEQ19XUklURTQoX3NjLCByZWcsIHZhbHVlKQlcCisJYnVz X3dyaXRlXzQoKF9zYyktPnNjX21lbV9yZXMsIHJlZywgdmFsdWUpCisKK3N0cnVjdCBhbTMzNXhf YWRjX3NvZnRjIHsKKwlkZXZpY2VfdAkJc2NfZGV2OworCXN0cnVjdCBtdHgJCXNjX210eDsKKwlz dHJ1Y3QgcmVzb3VyY2UJCSpzY19tZW1fcmVzOworCXN0cnVjdCByZXNvdXJjZQkJKnNjX2lycV9y ZXM7CisJdm9pZAkJCSpzY19pbnRyaGFuZDsKK307CisKK3N0cnVjdCBhbTMzNXhfYWRjX2lucHV0 IHsKKwlpbnQzMl90CQkJZW5hYmxlOwkJLyogaW5wdXQgZW5hYmxlZCAqLworCWludDMyX3QJCQlz YW1wbGVzOwkvKiBzYW1wbGVzIGF2ZXJhZ2UgKi8KKwlpbnQzMl90CQkJaW5wdXQ7CQkvKiBpbnB1 dCBudW1iZXIgKi8KKwlpbnQzMl90CQkJdmFsdWU7CQkvKiByYXcgY29udmVydGVkIHZhbHVlICov CisJdWludDMyX3QJCXN0ZXByZWc7CS8qIHN0ZXAgcmVnaXN0ZXIgKi8KKwlzdHJ1Y3QgYW0zMzV4 X2FkY19zb2Z0Ywkqc2M7CQkvKiBwb2ludGVyIHRvIGFkYyBzb2Z0YyAqLworfTsKKworI2RlZmlu ZQlBTTMzNVhfQURDX0xPQ0soX3NjKQkJXAorCW10eF9sb2NrKCYoX3NjKS0+c2NfbXR4KQorI2Rl ZmluZQlBTTMzNVhfQURDX1VOTE9DSyhfc2MpCQlcCisJbXR4X3VubG9jaygmKF9zYyktPnNjX210 eCkKKyNkZWZpbmUJQU0zMzVYX0FEQ19MT0NLX0lOSVQoX3NjKQlcCisJbXR4X2luaXQoJl9zYy0+ c2NfbXR4LCBkZXZpY2VfZ2V0X25hbWV1bml0KF9zYy0+c2NfZGV2KSwgXAorCSAgICAiYW0zMzV4 X2FkYyIsIE1UWF9ERUYpCisjZGVmaW5lCUFNMzM1WF9BRENfTE9DS19ERVNUUk9ZKF9zYykJXAor CW10eF9kZXN0cm95KCZfc2MtPnNjX210eCk7CisjZGVmaW5lCUFNMzM1WF9BRENfTE9DS19BU1NF UlQoX3NjKQlcCisJbXR4X2Fzc2VydCgmKF9zYyktPnNjX210eCwgTUFfT1dORUQpCisKKyNlbmRp ZiAvKiBfQU0zMzVYX0FEQ1ZBUl9IXyAqLwpJbmRleDogc3lzL2Jvb3QvZmR0L2R0cy9hbTMzNXgu ZHRzaQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBzeXMvYm9vdC9mZHQvZHRzL2FtMzM1eC5kdHNpCShyZXZpc2lv biAyNjIxMzEpCisrKyBzeXMvYm9vdC9mZHQvZHRzL2FtMzM1eC5kdHNpCSh3b3JraW5nIGNvcHkp CkBAIC03NSw2ICs3NSwxMyBAQAogCQkJaW50ZXJydXB0LXBhcmVudCA9IDwmQUlOVEM+OwogCQl9 OwogCisJCWFkYzA6IGFkY0A0NEUwRDAwMCB7CisJCQljb21wYXRpYmxlID0gInRpLGFtMzM1eC1h ZGMiOworCQkJcmVnID0gPDB4NDRFMEQwMDAgMHgyMDAwPjsKKwkJCWludGVycnVwdHMgPSA8IDE2 ID47CisJCQlpbnRlcnJ1cHQtcGFyZW50ID0gPCZBSU5UQz47CisgCQl9OworIAkJCiAJCUdQSU86 IGdwaW8gewogCQkJI2dwaW8tY2VsbHMgPSA8Mz47CiAJCQljb21wYXRpYmxlID0gInRpLGdwaW8i OwpJbmRleDogc3lzL2FybS9jb25mL0JFQUdMRUJPTkUKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2FybS9j b25mL0JFQUdMRUJPTkUJKHJldmlzaW9uIDI2MjEzMSkKKysrIHN5cy9hcm0vY29uZi9CRUFHTEVC T05FCSh3b3JraW5nIGNvcHkpCkBAIC0xMDMsNiArMTAzLDkgQEAKIGRldmljZQkJZ3BpbwogZGV2 aWNlCQlncGlvbGVkCiAKKyMgQURDIHN1cHBvcnQKK2RldmljZQkJYW0zMzV4X2FkYworCiAjIFVT QiBzdXBwb3J0CiBkZXZpY2UJCXVzYgogb3B0aW9ucyAJVVNCX0hPU1RfQUxJR049NjQJIyBDYWNo ZWxpbmUgc2l6ZSBpcyA2NCBvbiBBTTMzNXguCg== --047d7bb709886b3cc004f4cd7118-- From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 13:57:47 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3D53C0E; Mon, 17 Mar 2014 13:57:46 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B72037E3; Mon, 17 Mar 2014 13:57:46 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WPY2z-000LXm-Dn; Mon, 17 Mar 2014 13:57:45 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2HDvfic067355; Mon, 17 Mar 2014 07:57:41 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX180l+kc8HTYDJmFX3zlWIZz Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black From: Ian Lepore To: Patrick Kelsey In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Mar 2014 07:57:41 -0600 Message-ID: <1395064661.1149.565.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 13:57:47 -0000 On Sun, 2014-03-16 at 22:16 -0400, Patrick Kelsey wrote: > On Sun, Mar 16, 2014 at 9:33 PM, Rui Paulo wrote: > > > On 16 Mar 2014, at 14:59, Patrick Kelsey wrote: > > > > > - Improved disk probing support that will now by default find and use the > > > first suitable partition among the available storage devices. > > > > I think this introduced a bug where, if you have a non-responsive boot > > device, ubldr will stop and won't try network booting: > > > > ## Starting application at 0x01000054 ... > > Consoles: U-Boot console > > Compatible API signature found @1d800a8 > > Number of U-Boot devices: 2 > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > (rpaulo@zedfs.local, Fri Mar 14 22:35:47 PDT 2014) > > DRAM: 256MB > > Unknown device type '' <------------ this is new > > Found U-Boot device: disk > > Probing all storage devices... > > Checking unit=0 slice=0 partition=-1...disk0: read failed, error=1 > > > > Checking unit=1 slice=0 partition=-1... > > Checking unit=2 slice=0 partition=-1... > > Checking unit=3 slice=0 partition=-1... > > Checking unit=4 slice=0 partition=-1... > > Checking unit=5 slice=0 partition=-1... > > > > can't load 'kernel' > > > > Type '?' for a list of commands, 'help' for more detailed help. > > loader> > > > > It stops here and doesn't try net0 booting. > > > > > I think the problem is that some of the conditionals in > sys/boot/uboot/common/main.c:main() are broken. I believe I sowed the seed > for this in the original patch I sent to Ian, which appears to have had an > out-of-order set of tests in the disk conditional, which in hindsight > turned out to work due to a friendly coincidence (namely disk appearing > before net in the devsw). That bad-pattern conditional seems to have > gotten munged a bit further and propagated in some of the refactoring Ian > did when integrating my patch. > > I believe sys/boot/uboot/common/main.c, starting around line 442, should > look like this: > > if (strcmp(devsw[i]->dv_name, "disk") == 0 && > (load_type == -1 || (load_type & DEV_TYP_STOR))) { > if (probe_disks(i, load_type, load_unit, load_slice, > load_partition) == 0) > break; > } > > if (strcmp(devsw[i]->dv_name, "net") == 0 && > (load_type == -1 || (load_type & DEV_TYP_NET))) > break; > > > Can you give that a try? > > -Patrick This was my bad. I think I was so enmeshed in whether the strange original strncmp() calls were really just a silly form of strcmp() (they were) that I didn't even notice I screwed up the overall logic. Rather than putting the strcmp() first as shown above, I just adjusted the parens in the network if() to be what I should have done originally. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 14:21:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3154435; Mon, 17 Mar 2014 14:21:30 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F398AA5C; Mon, 17 Mar 2014 14:21:29 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id c6so3385258lan.38 for ; Mon, 17 Mar 2014 07:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+ontWEXjaCzV9ase3aN1ZAxi9BBHPDMrK+fi7kFVDmY=; b=tBIMf0mv/mhk964pDsPkwpJwp3CoZwYdgA/bINqMTVqHQdYoDtYyY+otpftLNlx9hC LE63Yu3xfq5I9/Txu7rydGHZ6Ybbv+MZOOoh+qFSBKqsKotuoYvyFHpi4dAb7eslKYOU Z3mRkquWZVDBNu/N2KmZQrn3++wcUhSIPCl9AT0iMpI8z5XKWx0tcuiNW1TTMVySnn/e qIOevDHkRiseBMqkF1RJf1eOq7KCaneJt0Avwpi3D6UhJSIoGhZvYEHkAKEg/zhj2I5V yPuWqPMvKdA02fA4nwPHO356fjcE13XiYLlmXsxFBmpApqV3rtPuhpBUxm9d2PqsJNty 50yQ== MIME-Version: 1.0 X-Received: by 10.112.94.229 with SMTP id df5mr1672473lbb.36.1395066088095; Mon, 17 Mar 2014 07:21:28 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.142.10 with HTTP; Mon, 17 Mar 2014 07:21:28 -0700 (PDT) In-Reply-To: <1395064661.1149.565.camel@revolution.hippie.lan> References: <1395064661.1149.565.camel@revolution.hippie.lan> Date: Mon, 17 Mar 2014 10:21:28 -0400 X-Google-Sender-Auth: BHDbd8w1qyu3QxG5f9fGzDnd8R0 Message-ID: Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black From: Patrick Kelsey To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 14:21:31 -0000 On Mon, Mar 17, 2014 at 9:57 AM, Ian Lepore wrote: > On Sun, 2014-03-16 at 22:16 -0400, Patrick Kelsey wrote: > > On Sun, Mar 16, 2014 at 9:33 PM, Rui Paulo wrote: > > > > > On 16 Mar 2014, at 14:59, Patrick Kelsey wrote: > > > > > > > - Improved disk probing support that will now by default find and > use the > > > > first suitable partition among the available storage devices. > > > > > > I think this introduced a bug where, if you have a non-responsive boot > > > device, ubldr will stop and won't try network booting: > > > > > > ## Starting application at 0x01000054 ... > > > Consoles: U-Boot console > > > Compatible API signature found @1d800a8 > > > Number of U-Boot devices: 2 > > > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > > (rpaulo@zedfs.local, Fri Mar 14 22:35:47 PDT 2014) > > > DRAM: 256MB > > > Unknown device type '' <------------ this is new > > > Found U-Boot device: disk > > > Probing all storage devices... > > > Checking unit=0 slice=0 partition=-1...disk0: read failed, error=1 > > > > > > Checking unit=1 slice=0 partition=-1... > > > Checking unit=2 slice=0 partition=-1... > > > Checking unit=3 slice=0 partition=-1... > > > Checking unit=4 slice=0 partition=-1... > > > Checking unit=5 slice=0 partition=-1... > > > > > > can't load 'kernel' > > > > > > Type '?' for a list of commands, 'help' for more detailed help. > > > loader> > > > > > > It stops here and doesn't try net0 booting. > > > > > > > > I think the problem is that some of the conditionals in > > sys/boot/uboot/common/main.c:main() are broken. I believe I sowed the > seed > > for this in the original patch I sent to Ian, which appears to have had > an > > out-of-order set of tests in the disk conditional, which in hindsight > > turned out to work due to a friendly coincidence (namely disk appearing > > before net in the devsw). That bad-pattern conditional seems to have > > gotten munged a bit further and propagated in some of the refactoring Ian > > did when integrating my patch. > > > > I believe sys/boot/uboot/common/main.c, starting around line 442, should > > look like this: > > > > if (strcmp(devsw[i]->dv_name, "disk") == 0 && > > (load_type == -1 || (load_type & DEV_TYP_STOR))) { > > if (probe_disks(i, load_type, load_unit, > load_slice, > > load_partition) == 0) > > break; > > } > > > > if (strcmp(devsw[i]->dv_name, "net") == 0 && > > (load_type == -1 || (load_type & DEV_TYP_NET))) > > break; > > > > > > Can you give that a try? > > > > -Patrick > > This was my bad. I think I was so enmeshed in whether the strange > original strncmp() calls were really just a silly form of strcmp() (they > were) that I didn't even notice I screwed up the overall logic. > > Rather than putting the strcmp() first as shown above, I just adjusted > the parens in the network if() to be what I should have done originally. > > I don't believe that approach will fix it. It's not just the parens in the "net" conditional that are the issue - I had the order of the tests in the "disk" conditional backwards to begin with. To get the desired behavior (proper fallback to net), the test of devsw[]->dv_name needs to be first so that a load_type of -1 cannot short circuit it in a loop iteration that is for another type. Otherwise, when load_type is -1, coming out of an unsuccessful probe_disks() will result in an exit from the loop via the "net" conditional, and you will wind up out of the loop, but without currdev set up properly for the net device (it will still be set up for "disk", and with a possibly non-zero unit number). Putting the test of devsw[]->dv_name first ensures that the loop won't be exited on behalf of a given type without currdev being set up for that type. -Patrick From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 14:40:23 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0662C7AC; Mon, 17 Mar 2014 14:40:23 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB899BC7; Mon, 17 Mar 2014 14:40:22 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WPYiD-000OjJ-Jr; Mon, 17 Mar 2014 14:40:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2HEeItd067389; Mon, 17 Mar 2014 08:40:18 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+e0pPy4851OM+DZ7V+Rwbo Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black From: Ian Lepore To: Patrick Kelsey In-Reply-To: References: <1395064661.1149.565.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Mar 2014 08:40:18 -0600 Message-ID: <1395067218.1149.570.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 14:40:23 -0000 On Mon, 2014-03-17 at 10:21 -0400, Patrick Kelsey wrote: > On Mon, Mar 17, 2014 at 9:57 AM, Ian Lepore wrote: > > > On Sun, 2014-03-16 at 22:16 -0400, Patrick Kelsey wrote: > > > On Sun, Mar 16, 2014 at 9:33 PM, Rui Paulo wrote: > > > > > > > On 16 Mar 2014, at 14:59, Patrick Kelsey wrote: > > > > > > > > > - Improved disk probing support that will now by default find and > > use the > > > > > first suitable partition among the available storage devices. > > > > > > > > I think this introduced a bug where, if you have a non-responsive boot > > > > device, ubldr will stop and won't try network booting: > > > > > > > > ## Starting application at 0x01000054 ... > > > > Consoles: U-Boot console > > > > Compatible API signature found @1d800a8 > > > > Number of U-Boot devices: 2 > > > > > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > > > (rpaulo@zedfs.local, Fri Mar 14 22:35:47 PDT 2014) > > > > DRAM: 256MB > > > > Unknown device type '' <------------ this is new > > > > Found U-Boot device: disk > > > > Probing all storage devices... > > > > Checking unit=0 slice=0 partition=-1...disk0: read failed, error=1 > > > > > > > > Checking unit=1 slice=0 partition=-1... > > > > Checking unit=2 slice=0 partition=-1... > > > > Checking unit=3 slice=0 partition=-1... > > > > Checking unit=4 slice=0 partition=-1... > > > > Checking unit=5 slice=0 partition=-1... > > > > > > > > can't load 'kernel' > > > > > > > > Type '?' for a list of commands, 'help' for more detailed help. > > > > loader> > > > > > > > > It stops here and doesn't try net0 booting. > > > > > > > > > > > I think the problem is that some of the conditionals in > > > sys/boot/uboot/common/main.c:main() are broken. I believe I sowed the > > seed > > > for this in the original patch I sent to Ian, which appears to have had > > an > > > out-of-order set of tests in the disk conditional, which in hindsight > > > turned out to work due to a friendly coincidence (namely disk appearing > > > before net in the devsw). That bad-pattern conditional seems to have > > > gotten munged a bit further and propagated in some of the refactoring Ian > > > did when integrating my patch. > > > > > > I believe sys/boot/uboot/common/main.c, starting around line 442, should > > > look like this: > > > > > > if (strcmp(devsw[i]->dv_name, "disk") == 0 && > > > (load_type == -1 || (load_type & DEV_TYP_STOR))) { > > > if (probe_disks(i, load_type, load_unit, > > load_slice, > > > load_partition) == 0) > > > break; > > > } > > > > > > if (strcmp(devsw[i]->dv_name, "net") == 0 && > > > (load_type == -1 || (load_type & DEV_TYP_NET))) > > > break; > > > > > > > > > Can you give that a try? > > > > > > -Patrick > > > > This was my bad. I think I was so enmeshed in whether the strange > > original strncmp() calls were really just a silly form of strcmp() (they > > were) that I didn't even notice I screwed up the overall logic. > > > > Rather than putting the strcmp() first as shown above, I just adjusted > > the parens in the network if() to be what I should have done originally. > > > > > I don't believe that approach will fix it. It's not just the parens in the > "net" conditional that are the issue - I had the order of the tests in the > "disk" conditional backwards to begin with. To get the desired behavior > (proper fallback to net), the test of devsw[]->dv_name needs to be first so > that a load_type of -1 cannot short circuit it in a loop iteration that is > for another type. Otherwise, when load_type is -1, coming out of an > unsuccessful probe_disks() will result in an exit from the loop via the > "net" conditional, and you will wind up out of the loop, but without > currdev set up properly for the net device (it will still be set up for > "disk", and with a possibly non-zero unit number). Putting the test of > devsw[]->dv_name first ensures that the loop won't be exited on behalf of a > given type without currdev being set up for that type. > > -Patrick I don't think so. With the parens nested correctly now, there's no difference between if ((condition A) && (condition B)) versus if ((condition B) && (condition A)) I've just always had a prejudice for testing the simple local-var conditions first with && conditions (even when performance doesn't matter, as in this case). Plus I've done something radical and actually tested it. :) MMC: no card present Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=...disk0: real size != size Checking unit=1 slice= partition=... Checking unit=2 slice= partition=... Checking unit=3 slice= partition=... Checking unit=4 slice= partition=... Checking unit=5 slice= partition=... Found U-Boot device: net | /boot/kernel/kernel data=0x4e3a08+0x305f8 syms=[0x4+0x7ee30+0x4+0x4e3d9] Hit [Enter] to boot immediately, or any other key for command prompt. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 15:25:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B086672; Mon, 17 Mar 2014 15:25:44 +0000 (UTC) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C609E160; Mon, 17 Mar 2014 15:25:43 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id 63so547827qgz.6 for ; Mon, 17 Mar 2014 08:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=CDx8H3VpNT6cP9DdgPN60/O2KSUq3Ih2eR5hYirtKJs=; b=jypqfRIfocYGUAwuLcaXt/V0UYn4D5Vi4qk4dXtw08DVSv+YJd8ehjRz2sJeYhuCo8 L4pUU3UjU7fNi3sa1Aa6TPmGHhCNlMqpOfdhiiGJNNrYq5sxCdbMbyACdE94bigyVceF YhPsN8tzxz/ZPY/7eE1LmM3ERoBTC0E7mMVhNdnZobSZ6cTIcKXneyyHiQ5/B1PbEMrl /2YYoaPlT1/z83jj+onFddeBbHNAjyWx8dr2JqdBU9z7spVYxHelfadwKg4+WZRNEW/A cE+yvufl4pPkQDkMou0XYq41HmgblsTs1qihtNGKydjzXJTYrqm3EdSZYfl9UEk/psKU uWrQ== X-Received: by 10.140.102.215 with SMTP id w81mr2529996qge.109.1395069942330; Mon, 17 Mar 2014 08:25:42 -0700 (PDT) Received: from [172.16.0.103] (c-174-54-20-106.hsd1.pa.comcast.net. [174.54.20.106]) by mx.google.com with ESMTPSA id 30sm21497537qgt.4.2014.03.17.08.25.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 08:25:40 -0700 (PDT) Sender: Patrick Kelsey References: <1395064661.1149.565.camel@revolution.hippie.lan> <1395067218.1149.570.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <1395067218.1149.570.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <80EF2F0E-B4E3-4E06-933A-685F78F2EBD7@ieee.org> X-Mailer: iPhone Mail (10B329) From: Patrick Kelsey Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black Date: Mon, 17 Mar 2014 11:25:37 -0400 To: Ian Lepore Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:25:44 -0000 On Mar 17, 2014, at 10:40 AM, Ian Lepore wrote: > On Mon, 2014-03-17 at 10:21 -0400, Patrick Kelsey wrote: >> On Mon, Mar 17, 2014 at 9:57 AM, Ian Lepore wrote: >>=20 >>> On Sun, 2014-03-16 at 22:16 -0400, Patrick Kelsey wrote: >>>> On Sun, Mar 16, 2014 at 9:33 PM, Rui Paulo wrote: >>>>=20 >>>>> On 16 Mar 2014, at 14:59, Patrick Kelsey wrote: >>>>>=20 >>>>>> - Improved disk probing support that will now by default find and >>> use the >>>>>> first suitable partition among the available storage devices. >>>>>=20 >>>>> I think this introduced a bug where, if you have a non-responsive boot= >>>>> device, ubldr will stop and won't try network booting: >>>>>=20 >>>>> ## Starting application at 0x01000054 ... >>>>> Consoles: U-Boot console >>>>> Compatible API signature found @1d800a8 >>>>> Number of U-Boot devices: 2 >>>>>=20 >>>>> FreeBSD/armv6 U-Boot loader, Revision 1.2 >>>>> (rpaulo@zedfs.local, Fri Mar 14 22:35:47 PDT 2014) >>>>> DRAM: 256MB >>>>> Unknown device type '' <------------ this is new >>>>> Found U-Boot device: disk >>>>> Probing all storage devices... >>>>> Checking unit=3D0 slice=3D0 partition=3D-1...disk0: read failed, error= =3D1 >>>>>=20 >>>>> Checking unit=3D1 slice=3D0 partition=3D-1... >>>>> Checking unit=3D2 slice=3D0 partition=3D-1... >>>>> Checking unit=3D3 slice=3D0 partition=3D-1... >>>>> Checking unit=3D4 slice=3D0 partition=3D-1... >>>>> Checking unit=3D5 slice=3D0 partition=3D-1... >>>>>=20 >>>>> can't load 'kernel' >>>>>=20 >>>>> Type '?' for a list of commands, 'help' for more detailed help. >>>>> loader> >>>>>=20 >>>>> It stops here and doesn't try net0 booting. >>>> I think the problem is that some of the conditionals in >>>> sys/boot/uboot/common/main.c:main() are broken. I believe I sowed the >>> seed >>>> for this in the original patch I sent to Ian, which appears to have had= >>> an >>>> out-of-order set of tests in the disk conditional, which in hindsight >>>> turned out to work due to a friendly coincidence (namely disk appearing= >>>> before net in the devsw). That bad-pattern conditional seems to have >>>> gotten munged a bit further and propagated in some of the refactoring I= an >>>> did when integrating my patch. >>>>=20 >>>> I believe sys/boot/uboot/common/main.c, starting around line 442, shoul= d >>>> look like this: >>>>=20 >>>> if (strcmp(devsw[i]->dv_name, "disk") =3D=3D 0 && >>>> (load_type =3D=3D -1 || (load_type & DEV_TYP_STOR))) {= >>>> if (probe_disks(i, load_type, load_unit, >>> load_slice, >>>> load_partition) =3D=3D 0) >>>> break; >>>> } >>>>=20 >>>> if (strcmp(devsw[i]->dv_name, "net") =3D=3D 0 && >>>> (load_type =3D=3D -1 || (load_type & DEV_TYP_NET))) >>>> break; >>>>=20 >>>>=20 >>>> Can you give that a try? >>>>=20 >>>> -Patrick >>>=20 >>> This was my bad. I think I was so enmeshed in whether the strange >>> original strncmp() calls were really just a silly form of strcmp() (they= >>> were) that I didn't even notice I screwed up the overall logic. >>>=20 >>> Rather than putting the strcmp() first as shown above, I just adjusted >>> the parens in the network if() to be what I should have done originally.= >> I don't believe that approach will fix it. It's not just the parens in t= he >> "net" conditional that are the issue - I had the order of the tests in th= e >> "disk" conditional backwards to begin with. To get the desired behavior >> (proper fallback to net), the test of devsw[]->dv_name needs to be first s= o >> that a load_type of -1 cannot short circuit it in a loop iteration that i= s >> for another type. Otherwise, when load_type is -1, coming out of an >> unsuccessful probe_disks() will result in an exit from the loop via the >> "net" conditional, and you will wind up out of the loop, but without >> currdev set up properly for the net device (it will still be set up for >> "disk", and with a possibly non-zero unit number). Putting the test of >> devsw[]->dv_name first ensures that the loop won't be exited on behalf of= a >> given type without currdev being set up for that type. >>=20 >> -Patrick >=20 > I don't think so. With the parens nested correctly now, there's no > difference between >=20 > if ((condition A) && (condition B)) versus=20 > if ((condition B) && (condition A)) >=20 > I've just always had a prejudice for testing the simple local-var > conditions first with && conditions (even when performance doesn't > matter, as in this case). >=20 > Plus I've done something radical and actually tested it. :) >=20 > MMC: no card present > Number of U-Boot devices: 2 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=3D0 slice=3D partition=3D...disk0: real size !=3D= size >=20 > Checking unit=3D1 slice=3D partition=3D... > Checking unit=3D2 slice=3D partition=3D... > Checking unit=3D3 slice=3D partition=3D... > Checking unit=3D4 slice=3D partition=3D... > Checking unit=3D5 slice=3D partition=3D... > Found U-Boot device: net > | > /boot/kernel/kernel data=3D0x4e3a08+0x305f8 syms=3D[0x4+0x7ee30+0x4+0x4e3d= 9] > Hit [Enter] to boot immediately, or any other key for command prompt. >=20 Speaking of short-circuit... I'm with you (and moving bedtime up a couple of= hours tonight). The saving grace is that I was wrong about my being wrong?= I guess I should have just thrown you under the bus alone :)= From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 17:10:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF14BB36 for ; Mon, 17 Mar 2014 17:10:05 +0000 (UTC) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 10785DE0 for ; Mon, 17 Mar 2014 17:10:04 +0000 (UTC) Received: (qmail 16513 invoked from network); 17 Mar 2014 18:03:22 +0100 Received: from udp003908uds.hawaiiantel.net (HELO ?192.168.1.16?) (72.234.77.86) by newton.metanet.ch with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 17 Mar 2014 18:03:22 +0100 Message-ID: <53272ACA.3080000@thieprojects.ch> Date: Mon, 17 Mar 2014 07:03:06 -1000 From: Werner Thie Organization: Thie & Co Projects User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Lundberg, Johannes" , freebsd-ports@freebsd.org, "freebsd-arm@freebsd.org" Subject: Re: crochet and dependencies References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: werner@thieprojects.ch List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 17:10:05 -0000 Hi Johannes as per Tim Kientzle the uboot port is not in a working condition, the project is open to be taken over, Tim is looking for somebody to maintain it. Werner On 3/17/14 12:03 AM, Lundberg, Johannes wrote: > Hi > > A new version of the crochet script told me I could install u-boot from > ports. Trying but keep getting error. > > First error: Can't find gcc > Fixed by installing gcc47 and creating a symbolink link > /usr/local/bin/gcc47 /usr/local/bin/gcc > > Next error: > > mkenvimage.c: In function 'main': > mkenvimage.c:137:35: error: 'PLAIN_VERSION' undeclared (first use in this > function) > mkenvimage.c:137:35: note: each undeclared identifier is reported only once > for each function it appears in > gmake[2]: *** [mkenvimage.o] Error 1 > gmake[2]: Leaving directory > `/usr/ports/sysutils/u-boot-beaglebone-eabi/work/u-boot-2013.04/tools' > gmake[1]: *** [tools] Error 2 > gmake[1]: Leaving directory > `/usr/ports/sysutils/u-boot-beaglebone-eabi/work/u-boot-2013.04' > *** Error code 2 > > What am I doing wrong? > > On 11-current amd64. > > -- > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 18:04:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B43FDFAB; Mon, 17 Mar 2014 18:04:26 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2601604; Mon, 17 Mar 2014 18:04:25 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s2HI2hgo076101; Mon, 17 Mar 2014 18:02:43 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s2HI2h6u076100; Mon, 17 Mar 2014 18:02:43 GMT (envelope-from wkoszek) Date: Mon, 17 Mar 2014 18:02:42 +0000 From: "Wojciech A. Koszek" To: Ganbold Tsagaankhuu Subject: Re: [GSoC 2014] Interested in ARM bringup tasks Message-ID: <20140317180242.GJ37327@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Mon, 17 Mar 2014 18:02:48 +0000 (UTC) Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , Alexander Tarasikov X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:04:26 -0000 On Mon, Mar 17, 2014 at 08:39:24AM +0800, Ganbold Tsagaankhuu wrote: > Alexander, > > > On Mon, Mar 17, 2014 at 7:19 AM, Alexander Tarasikov < > alexander.tarasikov@gmail.com> wrote: > > > Hello, FreeBSD community! > > > > I am interested in participating in GSoC this year and I'd like to > > pick up one of the tasks related to porting FreeBSD to new > > architectures. I'm now doing my master's degree in software > > engineering at the "Higher School of Economics" in Moscow. > > > > Since I love ARM and smartphones, I've chosen the project to port > > FreeBSD to a smartphone. If that task is already occupied (which > > doesn't seem so), I would be happy to pick up another task suggested > > by the community. > > > > I want to port FreeBSD to the Sony Xperia Z phone. This phone has the > > Qualcomm APQ8064 SoC which is used in a large number of smartphones, > > including Google Nexus 4. Besides, Qualcomm SoCs are developed > > incrementally so there's a high chance that the code for current > > generation of chips will benefit future revisions as well. > > > > Interesting. I'm not quite sure how accessible is some pins like uart in > Experia Z. > I have it here, but I still didn't try to open it yet to see the pins etc. > Probably you meant here some embedded boards like ifc6410. > Plus ifc6410 has docs so that could be useful too. Alexander, Ganbold, To get an access to UART in modern phones you typically get it via phone jack. By building/buying special adapter, you make your microphone jack become a serial cable. There are schematics online. For Nexus 4 the cable looked really simple. > > It is known that debugging like JTAG and flash recovery is not > > available on consumer devices because of DRM and general love for > > obfuscation among the vendors. Therefore, to prevent bricking the > > device, > > > That is the hell, it seems Qualcomm uses lauterbach jtag adapter in that > case. > I and my friend and also some people have tried some adapters like > flyswatter2 with ifc6410, still no luck. > I suggest using the chainloading approach, that is using the > > bootloader that ships with the device and pretend to be a linux image. > > > > That can be done. Their bootloader like maybe LK in case of ifc6410 can > boot freebsd kernel. > Actually I did that for ifc6410. > > > > > > For the mid-term I want to port the u-boot bootloader and add the > > support for accessing the microSD card from it. The u-boot will be > > flashed to the device instead of the linux kernel. If this project was to be attacked, I'd try to check if there's a way to re-use existing bootloader (on the phone) and just try to boot different kernel. Otherwise (if you have to work on U-boot) it's no longer a FreeBSD project. So I'd say: try to research the platform accessibility first. If U-boot work is absolutely necessary, it's probably fine to do something there, but if it's lots of time working on some other stuff, I'm not convinced. Can modern phones netboot/USB boot somehow? > > That could be cool. > > > > > > Since the proprietary bootloader already initializes the display (we > > can also port linux driver to u-boot), it should be possible, at least > > during the initial stage, to use a simple driver in FreeBSD that would > > write to the framebuffer allocated by the bootloader or only write the > > framebuffer address to the display controller. > > > > > That is nice. However first we need uart driver, then either usb ehci, mmc > or sata driver needs to mount rootfs in order to boot freebsd to multiuser > mode. I already have timer driver and minimal console driver so it makes > booting little bit easier. > > > > > > In the past I've successfully ported linux to an Intel XScale-based > > Asus P525 smartphone, ported Android with all hardware working to boot > > from NAND on the Sony Xperia X1 phone and have ported various boards > > from OEM to vanilla kernel trees. Recently I've experimented with the > > XNU kernel (the one which is used in the fruity operating system) and > > ported it to the OMAP5 board. So I think I'll be able to pull it off. > > > > Cool. In case of android or linux there are many people working on various > stuffs so in most case drivers are either written or somebody has got > started working on particular driver already. For FreeBSD case it is > different. You maybe know that very few people are working in case of ARM > platform bringup, so we need more developers and I'm happy that you decided > to work on this direction. > I wonder if SDK shipped by Google could be used to emulate given smartphone. They already ship with the emulator, and pre-defined profiles for devices. I wonder if Android kernel developers know more about running emulated kernels. -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 19:48:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30A398CE for ; Mon, 17 Mar 2014 19:48:40 +0000 (UTC) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E065FFDB for ; Mon, 17 Mar 2014 19:48:39 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id gq1so6102200obb.32 for ; Mon, 17 Mar 2014 12:48:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mSDSkKLiBbJMpXBvqrUy03Eqb1SKdc9rngbWfogR7Nk=; b=YJm0gX8A4lwiFY1bp7L5bN1hvXhfvoOn40csm0IlEKbbGf/Qysl/g/PiPBZgvolexG mBRnLzfGjJ0y0bxDvnLBuRSrg0zs7wlNVUiIQHCOsIGDlvFLDbgG8tU7tYSPv9ymrD5V K8hgSJc3tCHILCZcz0xodBso49xU1srzsYrBzSj11KRZRSQk+VtPFMBSzA9YV/1h3khz IjS6oVL+wRTstZvlGfcQpZfNO7VxRaFpUj7RsA6bxWKiU5UW3/SP5O3txFFHlzWH8lND OTiq1slZhpMNpmcjlqZ7w7E9jqS7w10mKt+LB/Fxupu4vXwMw2sCju27lkkRktFGNAD0 MGAg== X-Gm-Message-State: ALoCoQnX0fpnOn9KSsPvaFpXg8NLaQRkWz/CeW0QwnyUIkgIuv4Mcrpg1PPRaIQNwymnN1bVNMaO MIME-Version: 1.0 X-Received: by 10.182.142.37 with SMTP id rt5mr1217626obb.76.1395071573737; Mon, 17 Mar 2014 08:52:53 -0700 (PDT) Received: by 10.182.104.169 with HTTP; Mon, 17 Mar 2014 08:52:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Mar 2014 09:52:53 -0600 Message-ID: Subject: Re: crochet and dependencies From: Tom Everett To: "Lundberg, Johannes" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" , freebsd-ports@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 19:48:40 -0000 The change to use mkimage was my change. The intent to was to simplify the patchsets required for uboot. Interestingly, I'm compiling on AMD64 too. Here is what I have for gcc. Is this what you have (other than that I have 4.6) [root@bernice /storage/home/tom/crochet/crochet-freebsd]# gcc --version gcc (FreeBSD Ports Collection) 4.6.4 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [root@bernice /storage/home/tom/crochet/crochet-freebsd]# ls -lat /usr/local/bin/gcc lrwxr-xr-x 1 root wheel 20 Feb 2 18:51 /usr/local/bin/gcc -> /usr/local/bin/gcc46 On Mon, Mar 17, 2014 at 4:03 AM, Lundberg, Johannes < johannes@brilliantservice.co.jp> wrote: > Hi > > A new version of the crochet script told me I could install u-boot from > ports. Trying but keep getting error. > > First error: Can't find gcc > Fixed by installing gcc47 and creating a symbolink link > /usr/local/bin/gcc47 /usr/local/bin/gcc > > Next error: > > mkenvimage.c: In function 'main': > mkenvimage.c:137:35: error: 'PLAIN_VERSION' undeclared (first use in this > function) > mkenvimage.c:137:35: note: each undeclared identifier is reported only once > for each function it appears in > gmake[2]: *** [mkenvimage.o] Error 1 > gmake[2]: Leaving directory > `/usr/ports/sysutils/u-boot-beaglebone-eabi/work/u-boot-2013.04/tools' > gmake[1]: *** [tools] Error 2 > gmake[1]: Leaving directory > `/usr/ports/sysutils/u-boot-beaglebone-eabi/work/u-boot-2013.04' > *** Error code 2 > > What am I doing wrong? > > On 11-current amd64. > > -- > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B > $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B > $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B > --- > CONFIDENTIALITY NOTE: The information in this email is confidential > and intended solely for the addressee. > Disclosure, copying, distribution or any other action of use of this > email by person other than intended recipient, is prohibited. > If you are not the intended recipient and have received this email in > error, please destroy the original message. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Tue Mar 18 13:25:57 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A6F04A4 for ; Tue, 18 Mar 2014 13:25:57 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DD648FCA for ; Tue, 18 Mar 2014 13:25:56 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WPu1e-000Jhu-HE; Tue, 18 Mar 2014 13:25:50 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2IDPkqe068474; Tue, 18 Mar 2014 07:25:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19JtA+998agMY/eYKX7VlxV Subject: Re: arm SMP on Cortex-A15 From: Ian Lepore To: Wojciech Macek In-Reply-To: References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> Content-Type: multipart/mixed; boundary="=-n06oNHLaZG3WXWB+YZ+r" Date: Tue, 18 Mar 2014 07:25:46 -0600 Message-ID: <1395149146.1149.586.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 13:25:57 -0000 --=-n06oNHLaZG3WXWB+YZ+r Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, 2014-03-17 at 09:29 +0100, Wojciech Macek wrote: > Hi, > > Finally I've found some time to continue SMP hacking. It seems that I > isolated the tlb/pmam failures and developed two simple patches that help. > There are still some pmap changes and TEX remap left, but I don't want to > use them now. > https://drive.google.com/folderview?id=0B-7yTLrPxaWtSzZPUGgtM3pnUjg&usp=sharing > * 01 - ensure that TTB is set before TLB invalidation and flush BTB to > comply the specs > * 02 - add missing TLB invalidations to pmap and fix invalidation order > > I chose buildworld -j4 as a stresstest, and run it on Arndale (USB rootfs) > and a different 4-core a15 chip (SATA rootfs). On both setups test passed > and was significantly faster than the one with previous patchset. > > I'd like to submit these changes to FreeBSD tree (with some help from our > local committers), so any comments and testing are really appreciated. > > Best regards, > Wojtek The first patch looks fine and is working without any problems for me. For the second patch, I propose the attached similar patch which combines your changes with some I got from Olivier. The main differences are moving the tlb flush outside the loop when propagating a change to all L1s, and moving the tlb flush (rather than adding another) in pmap_kenter_internal(). I believe even with the second patch there may still be some missing tlb flushes. -- Ian --=-n06oNHLaZG3WXWB+YZ+r Content-Disposition: inline; filename="smp_patch_02a.patch" Content-Type: text/x-patch; name="smp_patch_02a.patch"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/pmap-v6.c =================================================================== --- sys/arm/arm/pmap-v6.c (revision 263054) +++ sys/arm/arm/pmap-v6.c (working copy) @@ -2130,6 +2130,8 @@ pmap_grow_l2_bucket(pmap_t pmap, vm_offset_t va) L1_C_PROTO; PTE_SYNC(pl1pd); } + cpu_tlb_flushID_SE(va); + cpu_cpwait(); return (l2b); } @@ -2387,14 +2389,6 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p ptep = &l2b->l2b_kva[l2pte_index(va)]; opte = *ptep; - if (l2pte_valid(opte)) { - cpu_tlb_flushD_SE(va); - cpu_cpwait(); - } else { - if (opte == 0) - l2b->l2b_occupancy++; - } - if (flags & KENTER_CACHE) { *ptep = L2_S_PROTO | pa | pte_l2_s_cache_mode | L2_S_REF; pmap_set_prot(ptep, VM_PROT_READ | VM_PROT_WRITE, @@ -2405,10 +2399,17 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p 0); } + PTE_SYNC(ptep); + if (l2pte_valid(opte)) { + cpu_tlb_flushD_SE(va); + } else { + if (opte == 0) + l2b->l2b_occupancy++; + } + cpu_cpwait(); + PDEBUG(1, printf("pmap_kenter: pte = %08x, opte = %08x, npte = %08x\n", (uint32_t) ptep, opte, *ptep)); - PTE_SYNC(ptep); - cpu_cpwait(); } void @@ -2474,10 +2475,10 @@ pmap_kremove(vm_offset_t va) opte = *ptep; if (l2pte_valid(opte)) { va = va & ~PAGE_MASK; + *ptep = 0; + PTE_SYNC(ptep); cpu_tlb_flushD_SE(va); cpu_cpwait(); - *ptep = 0; - PTE_SYNC(ptep); } } @@ -4380,6 +4381,8 @@ pmap_remove(pmap_t pmap, vm_offset_t sva, vm_offse } } + *ptep = 0; + PTE_SYNC(ptep); if (pmap_is_current(pmap)) { total++; if (total < PMAP_REMOVE_CLEAN_LIST_SIZE) { @@ -4390,8 +4393,6 @@ pmap_remove(pmap_t pmap, vm_offset_t sva, vm_offse } else if (total == PMAP_REMOVE_CLEAN_LIST_SIZE) flushall = 1; } - *ptep = 0; - PTE_SYNC(ptep); sva += PAGE_SIZE; ptep++; --=-n06oNHLaZG3WXWB+YZ+r-- From owner-freebsd-arm@FreeBSD.ORG Tue Mar 18 13:32:36 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23A74892 for ; Tue, 18 Mar 2014 13:32:36 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB94C129 for ; Tue, 18 Mar 2014 13:32:35 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WPu85-0002LT-CZ; Tue, 18 Mar 2014 13:32:29 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2IDWRLO068507; Tue, 18 Mar 2014 07:32:27 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+U1qKdD9vRpFg6QSwsM7Oi Subject: Re: arm SMP on Cortex-A15 From: Ian Lepore To: Wojciech Macek In-Reply-To: References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Mar 2014 07:32:26 -0600 Message-ID: <1395149546.1149.589.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 13:32:36 -0000 On Mon, 2014-03-17 at 09:29 +0100, Wojciech Macek wrote: > Hi, > > Finally I've found some time to continue SMP hacking. It seems that I > isolated the tlb/pmam failures and developed two simple patches that help. > There are still some pmap changes and TEX remap left, but I don't want to > use them now. > https://drive.google.com/folderview?id=0B-7yTLrPxaWtSzZPUGgtM3pnUjg&usp=sharing > * 01 - ensure that TTB is set before TLB invalidation and flush BTB to > comply the specs > * 02 - add missing TLB invalidations to pmap and fix invalidation order > > I chose buildworld -j4 as a stresstest, and run it on Arndale (USB rootfs) > and a different 4-core a15 chip (SATA rootfs). On both setups test passed > and was significantly faster than the one with previous patchset. > > I'd like to submit these changes to FreeBSD tree (with some help from our > local committers), so any comments and testing are really appreciated. > > Best regards, > Wojtek BTW, on line 1561 of pmap-v6.c there's an #ifdef DEBUG. If you change that to #if 1 you'll find that sometimes the problem that code is looking for happens: fixup: pmap 0xc72c10bc, va 0x203f7000, ftype 1 - nothing to do! fixup: l2 0xc781e0c4, l2b 0xc781e0ec, ptep 0xc76c83dc, pl1pd 0xe1ce680c fixup: pte 0x11a2c67e, l1pd 0x670c8021, last code 0x0 I just noticed this last night and haven't dug into it yet. I'm running on a quad-core cortex-a9 (imx6), BTW. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Mar 19 18:48:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C8EC4DC for ; Wed, 19 Mar 2014 18:48:41 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B591DD0 for ; Wed, 19 Mar 2014 18:48:40 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WQLXW-000MWP-Iq; Wed, 19 Mar 2014 18:48:34 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2JImWuv069872; Wed, 19 Mar 2014 12:48:32 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/N58it+YG3YlyyZlkfhiZL Subject: Re: arm SMP on Cortex-A15 From: Ian Lepore To: Wojciech Macek In-Reply-To: <1395149146.1149.586.camel@revolution.hippie.lan> References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="=-YwiFRevDQYDNGbo/Gkof" Date: Wed, 19 Mar 2014 12:48:31 -0600 Message-ID: <1395254911.80941.9.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 18:48:41 -0000 --=-YwiFRevDQYDNGbo/Gkof Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, 2014-03-18 at 07:25 -0600, Ian Lepore wrote: > On Mon, 2014-03-17 at 09:29 +0100, Wojciech Macek wrote: > > Hi, > > > > Finally I've found some time to continue SMP hacking. It seems that I > > isolated the tlb/pmam failures and developed two simple patches that help. > > There are still some pmap changes and TEX remap left, but I don't want to > > use them now. > > https://drive.google.com/folderview?id=0B-7yTLrPxaWtSzZPUGgtM3pnUjg&usp=sharing > > * 01 - ensure that TTB is set before TLB invalidation and flush BTB to > > comply the specs > > * 02 - add missing TLB invalidations to pmap and fix invalidation order > > > > I chose buildworld -j4 as a stresstest, and run it on Arndale (USB rootfs) > > and a different 4-core a15 chip (SATA rootfs). On both setups test passed > > and was significantly faster than the one with previous patchset. > > > > I'd like to submit these changes to FreeBSD tree (with some help from our > > local committers), so any comments and testing are really appreciated. > > > > Best regards, > > Wojtek > > The first patch looks fine and is working without any problems for me. > > For the second patch, I propose the attached similar patch which > combines your changes with some I got from Olivier. The main > differences are moving the tlb flush outside the loop when propagating a > change to all L1s, and moving the tlb flush (rather than adding another) > in pmap_kenter_internal(). > > I believe even with the second patch there may still be some missing tlb > flushes. > > -- Ian Following up with a third version of the pmap-v6.c patch. On top of the previous versions, this: * ensures that cpu_cpwait() is consistantly used after every tlb flush (sometimes it's a single wait after flushes that happen in a loop). * adds a tlb flush to pmap_free_l2_bucket() * adds a tlb flush to pmap_bootstrap() * adds a tlb flush to pmap_grow_map() * adds a tlb flush to pmap_grow_l2_bucket() * adds a tlb flush to pmap_kenter_section() I'm not sure there's any armv6/7 platform that needs the cpu_cpwait(), but if it's going to appear in the code at all, it should at least be consisant. :) -- Ian --=-YwiFRevDQYDNGbo/Gkof Content-Disposition: inline; filename="smp_patch_02b.patch" Content-Type: text/x-patch; name="smp_patch_02b.patch"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/pmap-v6.c =================================================================== --- sys/arm/arm/pmap-v6.c (revision 263112) +++ sys/arm/arm/pmap-v6.c (working copy) @@ -844,6 +844,8 @@ pmap_free_l2_bucket(pmap_t pmap, struct l2_bucket if (l1pd == (L1_C_DOM(pmap->pm_domain) | L1_TYPE_C)) { *pl1pd = 0; PTE_SYNC(pl1pd); + cpu_tlb_flushD_SE((vm_offset_t)ptep); + cpu_cpwait(); } /* @@ -1047,6 +1049,7 @@ small_mappings: cpu_tlb_flushID_SE(pv->pv_va); else if (PTE_BEEN_REFD(opte)) cpu_tlb_flushD_SE(pv->pv_va); + cpu_cpwait(); } PMAP_UNLOCK(pmap); @@ -1644,7 +1647,7 @@ pmap_postinit(void) *ptep = pte; PTE_SYNC(ptep); cpu_tlb_flushD_SE(va); - + cpu_cpwait(); va += PAGE_SIZE; } pmap_init_l1(l1, pl1pt); @@ -1948,6 +1951,8 @@ pmap_bootstrap(vm_offset_t firstaddr, struct pv_ad pmap_init_l1(l1, kernel_l1pt); cpu_dcache_wbinv_all(); cpu_l2cache_wbinv_all(); + cpu_tlb_flushID(); + cpu_cpwait(); virtual_avail = round_page(virtual_avail); virtual_end = vm_max_kernel_address; @@ -2034,7 +2039,8 @@ pmap_grow_map(vm_offset_t va, pt_entry_t cache_mod *ptep = L2_S_PROTO | pa | cache_mode | L2_S_REF; pmap_set_prot(ptep, VM_PROT_READ | VM_PROT_WRITE, 0); PTE_SYNC(ptep); - + cpu_tlb_flushD_SE(va); + cpu_cpwait(); return (0); } @@ -2130,6 +2136,8 @@ pmap_grow_l2_bucket(pmap_t pmap, vm_offset_t va) L1_C_PROTO; PTE_SYNC(pl1pd); } + cpu_tlb_flushID_SE(va); + cpu_cpwait(); return (l2b); } @@ -2348,6 +2356,8 @@ pmap_kenter_section(vm_offset_t va, vm_offset_t pa l1->l1_kva[L1_IDX(va)] = pd; PTE_SYNC(&l1->l1_kva[L1_IDX(va)]); } + cpu_tlb_flushD_SE(va); + cpu_cpwait(); } /* @@ -2387,14 +2397,6 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p ptep = &l2b->l2b_kva[l2pte_index(va)]; opte = *ptep; - if (l2pte_valid(opte)) { - cpu_tlb_flushD_SE(va); - cpu_cpwait(); - } else { - if (opte == 0) - l2b->l2b_occupancy++; - } - if (flags & KENTER_CACHE) { *ptep = L2_S_PROTO | pa | pte_l2_s_cache_mode | L2_S_REF; pmap_set_prot(ptep, VM_PROT_READ | VM_PROT_WRITE, @@ -2405,10 +2407,17 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p 0); } + PTE_SYNC(ptep); + if (l2pte_valid(opte)) { + cpu_tlb_flushD_SE(va); + } else { + if (opte == 0) + l2b->l2b_occupancy++; + } + cpu_cpwait(); + PDEBUG(1, printf("pmap_kenter: pte = %08x, opte = %08x, npte = %08x\n", (uint32_t) ptep, opte, *ptep)); - PTE_SYNC(ptep); - cpu_cpwait(); } void @@ -2474,10 +2483,10 @@ pmap_kremove(vm_offset_t va) opte = *ptep; if (l2pte_valid(opte)) { va = va & ~PAGE_MASK; + *ptep = 0; + PTE_SYNC(ptep); cpu_tlb_flushD_SE(va); cpu_cpwait(); - *ptep = 0; - PTE_SYNC(ptep); } } @@ -2710,6 +2719,7 @@ small_mappings: cpu_tlb_flushID(); else cpu_tlb_flushD(); + cpu_cpwait(); } vm_page_aflag_clear(m, PGA_WRITEABLE); rw_wunlock(&pvh_global_lock); @@ -2763,6 +2773,7 @@ pmap_change_attr(vm_offset_t sva, vm_size_t len, i pmap_l2cache_wbinv_range(tmpva, pte & L2_S_FRAME, PAGE_SIZE); *ptep = pte; cpu_tlb_flushID_SE(tmpva); + cpu_cpwait(); dprintf("%s: for va:%x ptep:%x pte:%x\n", __func__, tmpva, (uint32_t)ptep, pte); @@ -2900,6 +2911,7 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, vm_offs else if (is_refd) cpu_tlb_flushD(); + cpu_cpwait(); } rw_wunlock(&pvh_global_lock); @@ -3166,6 +3178,7 @@ validate: cpu_tlb_flushID_SE(va); else if (is_refd) cpu_tlb_flushD_SE(va); + cpu_cpwait(); } if ((pmap != pmap_kernel()) && (pmap == &curproc->p_vmspace->vm_pmap)) @@ -3713,6 +3726,7 @@ pmap_remove_section(pmap_t pmap, vm_offset_t sva) cpu_tlb_flushID_SE(sva); else cpu_tlb_flushD_SE(sva); + cpu_cpwait(); } /* @@ -3885,6 +3899,7 @@ pmap_promote_section(pmap_t pmap, vm_offset_t va) cpu_tlb_flushID(); else cpu_tlb_flushD(); + cpu_cpwait(); pmap_section_promotions++; CTR2(KTR_PMAP, "pmap_promote_section: success for va %#x" @@ -4009,6 +4024,7 @@ pmap_demote_section(pmap_t pmap, vm_offset_t va) cpu_tlb_flushID_SE(va); else if (L1_S_REFERENCED(l1pd)) cpu_tlb_flushD_SE(va); + cpu_cpwait(); pmap_section_demotions++; CTR2(KTR_PMAP, "pmap_demote_section: success for va %#x" @@ -4380,6 +4396,8 @@ pmap_remove(pmap_t pmap, vm_offset_t sva, vm_offse } } + *ptep = 0; + PTE_SYNC(ptep); if (pmap_is_current(pmap)) { total++; if (total < PMAP_REMOVE_CLEAN_LIST_SIZE) { @@ -4390,8 +4408,6 @@ pmap_remove(pmap_t pmap, vm_offset_t sva, vm_offse } else if (total == PMAP_REMOVE_CLEAN_LIST_SIZE) flushall = 1; } - *ptep = 0; - PTE_SYNC(ptep); sva += PAGE_SIZE; ptep++; @@ -4404,6 +4420,7 @@ pmap_remove(pmap_t pmap, vm_offset_t sva, vm_offse rw_wunlock(&pvh_global_lock); if (flushall) cpu_tlb_flushID(); + cpu_cpwait(); PMAP_UNLOCK(pmap); } @@ -4923,6 +4940,7 @@ pmap_advise(pmap_t pmap, vm_offset_t sva, vm_offse } } } + cpu_cpwait(); rw_wunlock(&pvh_global_lock); PMAP_UNLOCK(pmap); } --=-YwiFRevDQYDNGbo/Gkof-- From owner-freebsd-arm@FreeBSD.ORG Thu Mar 20 01:46:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A465884 for ; Thu, 20 Mar 2014 01:46:59 +0000 (UTC) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 43405CD8 for ; Thu, 20 Mar 2014 01:46:58 +0000 (UTC) Received: from [199.165.180.42] (dhcp12.beta.com [199.165.180.42]) by spoon.beta.com (8.14.5/8.14.5) with ESMTP id s2K2Cw4f078618; Wed, 19 Mar 2014 22:12:58 -0400 (EDT) (envelope-from mcgovern@beta.com) Subject: Re: Beaglebone black: are the AIN pins available with gpioctl From: "Brian J. McGovern" To: Luiz Otavio O Souza In-Reply-To: References: <1394852976.1369.3.camel@fbsd-laptop> Content-Type: text/plain; charset="us-ascii" Organization: B.E.T.A. Date: Wed, 19 Mar 2014 21:46:42 -0400 Message-ID: <1395280002.1367.5.camel@fbsd-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.6 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on spoon.beta.com Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mcgovern@beta.com List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 01:46:59 -0000 On Sat, 2014-03-15 at 02:23 -0300, Luiz Otavio O Souza wrote: > On 15 March 2014 00:09, Brian J. McGovern wrote: > > I'm trying to read through all the details in the Beaglebone Black > > System Reference manual, but I don't think I've seen this particular > > piece yet... Are the AIN pins available via gpioctl or another interface > > in 10.0-RELEASE? > > No, there is no support for the ADC on 10.0-RELEASE. > > I've just tested a driver for the BBB ADC, now i need to write a man > page and publish the code (on this ML). > > If everything is fine, it will be available on -head and on 10-stable soon. > > Luiz > Luiz, I grabbed your patches that you posted on 17 March, and patched them in to FreeBSD 10. Overall, the driver seems to work fine. The only issue that I'm having is that after some period of time (it has varied from a few minutes to over a half hour), the analog input freezes up, continuing to provide the last reading, despite changes on the analog input - verified via a voltage meter. The only way I've been able to recover is to reboot. Obviously, I need to do some more testing and try to figure out why its locking up, but I thought you'd like to know. -B From owner-freebsd-arm@FreeBSD.ORG Thu Mar 20 01:49:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 722BB8E1; Thu, 20 Mar 2014 01:49:50 +0000 (UTC) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D159FCEA; Thu, 20 Mar 2014 01:49:49 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id d17so101779eek.4 for ; Wed, 19 Mar 2014 18:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=F1v4TbTudjWyOgjnwXZ1DgHq37r5FWTDMRCjYAKQ2fk=; b=es0cBmLgfNi2voHOO1gMj4aE1TyFqM4IbBRCmVU1nbVJaLnb50KL8f2qBcW5w7IFzI S5ochgz9v2sZzOvEcxpeP9rl1e1YkR5oopbcLtESezY8yTl4INqOVJ2NP/o6uiTVHzdX mQ27STGfFvedRD1Bk2XqpJBzua8GOzAe7sAWjtZ74UgdRznQxHT8iLjhLZ7eN+MhdUfO FRbrHVI3iM3LRZuOCIddG9qaxWCZvnnNfNWxdm1jz/AFO/z8RNjZY09fM6+nLAw0Ffuk hxXl5RnCF9kNHhFJYJCR4TOyvl9NgoHnKo1Dq/8cPq+SHkWOffCmcegFiG0aOssRPeFx N1Iw== X-Received: by 10.15.60.199 with SMTP id g47mr39154068eex.37.1395280188346; Wed, 19 Mar 2014 18:49:48 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id cb5sm761489eeb.18.2014.03.19.18.49.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 18:49:46 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <532A4938.8030003@hot.ee> Date: Thu, 20 Mar 2014 03:49:44 +0200 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Patrick Kelsey Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black References: <1395064661.1149.565.camel@revolution.hippie.lan> <1395067218.1149.570.camel@revolution.hippie.lan> <80EF2F0E-B4E3-4E06-933A-685F78F2EBD7@ieee.org> In-Reply-To: <80EF2F0E-B4E3-4E06-933A-685F78F2EBD7@ieee.org> X-TagToolbar-Keys: D20140320034943952 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 01:49:50 -0000 I now have this weirdness of "double 2": ## Starting application at 0x88000054 ... Consoles: U-Boot console Compatible U-Boot API signature found @9f242240 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@rack0, Wed Mar 19 03:10:06 EET 2014) DRAM: 512MB MMC Device 2 not found MMC Device 3 not found MMC Device 2 not found Number of U-Boot devices: 3 U-Boot env: loaderdev='mmc0:2.0' Found U-Boot device: disk Checking unit=0 slice=2 partition=... good. -- ketas From owner-freebsd-arm@FreeBSD.ORG Thu Mar 20 03:42:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64B5CB9; Thu, 20 Mar 2014 03:42:10 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0AAD9B6; Thu, 20 Mar 2014 03:42:09 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id pv20so172040lab.24 for ; Wed, 19 Mar 2014 20:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uc/vtDQXIEE8XwhM0AVrkduFaqmCjuPL/v5af+1TVWM=; b=X//M+cuBrDbbR06tBeHJjMfIZCG5zaiLZHP/rmTciSCj+ykShXMP4uPKFFFtL1OccA 8wX3jyPgCnVoEziZJU00g7V3oP0zJ4Ydb8xPC/6X+/UWM3wJelxwUT+cFC9wwAx2dFR/ mpBOGUJbzXSX43y2P+05bN54GPbfv7u/a8ZCc9/JtBlWdiqFxJdlowrm+q2Z3P26+F6+ /7XNNJdaxre2NVE4Gt+DTQxn6uHGA1CIbmMG+60+YjxX4Haf+2tntj+YqxBZTD2F/VRA beXAEcQnKJAUmS84BkJ8Ss0kRNT1MSyZMH8FuDgu+aT+cA03fEYTfSB49uqnNRgZMMAq Kjhg== MIME-Version: 1.0 X-Received: by 10.153.4.134 with SMTP id ce6mr28192420lad.21.1395286927705; Wed, 19 Mar 2014 20:42:07 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.141.196 with HTTP; Wed, 19 Mar 2014 20:42:07 -0700 (PDT) In-Reply-To: <532A4938.8030003@hot.ee> References: <1395064661.1149.565.camel@revolution.hippie.lan> <1395067218.1149.570.camel@revolution.hippie.lan> <80EF2F0E-B4E3-4E06-933A-685F78F2EBD7@ieee.org> <532A4938.8030003@hot.ee> Date: Wed, 19 Mar 2014 23:42:07 -0400 X-Google-Sender-Auth: GmICVgTuqdYG39VtPAMZWzlkQ1U Message-ID: Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black From: Patrick Kelsey To: "Sulev-Madis Silber (ketas)" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 03:42:10 -0000 On Wed, Mar 19, 2014 at 9:49 PM, Sulev-Madis Silber (ketas) wrote: > I now have this weirdness of "double 2": > > > ## Starting application at 0x88000054 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @9f242240 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@rack0, Wed Mar 19 03:10:06 EET 2014) > > DRAM: 512MB > MMC Device 2 not found > MMC Device 3 not found > MMC Device 2 not found > Number of U-Boot devices: 3 > U-Boot env: loaderdev='mmc0:2.0' > Found U-Boot device: disk > Checking unit=0 slice=2 partition=... good. > > > -- > ketas > The short story is that this is a side effect of the terribly brute-force u-boot storage device enumeration code and does not represent a functional fault. I won't even attempt to render into text the way that this code works in detail. Suffice it to say that it will call the routine that checks if a given MMC device exists *a lot* from different places. One of those places is in a loop that tries to determine if the last enumerated device is of a given type. When enumeration of the MMC devices begins, this routine is called and it will check to see if every one of the configured maximum possible number of MMC devices exists. The routine that checks if a given MMC device exists prints the "MMC Device not found" message if that device doesn't exist. Since the configured maximum possible number of MMC devices is four and two of them (0 and 1) actually exist on this platform, this action is what results in the first two messages: MMC Device 2 not found MMC Device 3 not found Then, the enumeration of MMC devices will start at the first possible device and proceed until the routine that checks whether a given MMC device exists returns false. That last call is what is responsible for the third message (the seeming duplicate): MMC Device 2 not found Just to give you an idea of how brute-force this process is, on this platform, the routine that checks to see if a given MMC device exists is called a total of *ten* times to detect two existing devices out of a possible four. -Patrick From owner-freebsd-arm@FreeBSD.ORG Thu Mar 20 07:42:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9A249D for ; Thu, 20 Mar 2014 07:42:36 +0000 (UTC) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 635A2E8A for ; Thu, 20 Mar 2014 07:42:35 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id cz12so477410veb.7 for ; Thu, 20 Mar 2014 00:42:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ngaoguk+nvNoxrxKzD3bIG2dzy3EweWyA+SDJr0K0ZU=; b=ihvV5mG5+4Yfp0xGXAKUaIT+7hMfGKYTndaMSexouXbQUJ8wddyc1+KQhOXu68kE/Q xKj+sJNfSOofaei8KTgFWhnaCgCaUCeXhRu0JwSESuic1KtbofC3Q7KfeUJa0GhdyTzU 8ebxTCXp0B8cvVyE4WcYGIQonuoHjKV3Mx6l1hINkiz21I9b2GhAbr4Gce/fbNN/3Nov OhhsTCcrn7v/ZJ9rbz551ix/sPjbuzuyDfOi+wm8kRoIvMdyBZEYZmQw4Bz6l/FwAfRp pcdPOPr1gtqIqVTaODBU/Bcs6e6JWWT210VQlwCLlVAIBONzD7rwjF00CcaqIpVTWLkO FNaw== X-Gm-Message-State: ALoCoQkViJK907cWjCkkqD/Bbc6FOGLgQmUP5V3Ybz6e4GepHuifva105/nfxx+gH2yMqXDBviTI MIME-Version: 1.0 X-Received: by 10.52.18.70 with SMTP id u6mr28424353vdd.11.1395301348049; Thu, 20 Mar 2014 00:42:28 -0700 (PDT) Received: by 10.220.209.135 with HTTP; Thu, 20 Mar 2014 00:42:27 -0700 (PDT) In-Reply-To: <1395254911.80941.9.camel@revolution.hippie.lan> References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> Date: Thu, 20 Mar 2014 08:42:27 +0100 Message-ID: Subject: Re: arm SMP on Cortex-A15 From: Wojciech Macek To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 07:42:36 -0000 Hi Ian, Thanks, I looked at your patch and tried to run it. Unfortunatelly, it is still something wrong on A15 core. Your changes in pmap_kenter_internal do cause panics during startup. Apparently we still need to do cpu_tlb_flushID_SE(va) at the end of that function... but that is weird. I made this small "fix" and I'm able to boot the system. I'm going to run stress tests now to see if it is stable. Regarding DEBUG, that is really interesting. It you see that on A9 that seems to be even worse, because suggests a flaw in pmap logic... Wojtek 2014-03-19 19:48 GMT+01:00 Ian Lepore : > On Tue, 2014-03-18 at 07:25 -0600, Ian Lepore wrote: > > On Mon, 2014-03-17 at 09:29 +0100, Wojciech Macek wrote: > > > Hi, > > > > > > Finally I've found some time to continue SMP hacking. It seems that I > > > isolated the tlb/pmam failures and developed two simple patches that > help. > > > There are still some pmap changes and TEX remap left, but I don't want > to > > > use them now. > > > > https://drive.google.com/folderview?id=0B-7yTLrPxaWtSzZPUGgtM3pnUjg&usp=sharing > > > * 01 - ensure that TTB is set before TLB invalidation and flush BTB to > > > comply the specs > > > * 02 - add missing TLB invalidations to pmap and fix invalidation order > > > > > > I chose buildworld -j4 as a stresstest, and run it on Arndale (USB > rootfs) > > > and a different 4-core a15 chip (SATA rootfs). On both setups test > passed > > > and was significantly faster than the one with previous patchset. > > > > > > I'd like to submit these changes to FreeBSD tree (with some help from > our > > > local committers), so any comments and testing are really appreciated. > > > > > > Best regards, > > > Wojtek > > > > The first patch looks fine and is working without any problems for me. > > > > For the second patch, I propose the attached similar patch which > > combines your changes with some I got from Olivier. The main > > differences are moving the tlb flush outside the loop when propagating a > > change to all L1s, and moving the tlb flush (rather than adding another) > > in pmap_kenter_internal(). > > > > I believe even with the second patch there may still be some missing tlb > > flushes. > > > > -- Ian > > Following up with a third version of the pmap-v6.c patch. On top of the > previous versions, this: > > * ensures that cpu_cpwait() is consistantly used after every tlb > flush (sometimes it's a single wait after flushes that happen in > a loop). > * adds a tlb flush to pmap_free_l2_bucket() > * adds a tlb flush to pmap_bootstrap() > * adds a tlb flush to pmap_grow_map() > * adds a tlb flush to pmap_grow_l2_bucket() > * adds a tlb flush to pmap_kenter_section() > > I'm not sure there's any armv6/7 platform that needs the cpu_cpwait(), > but if it's going to appear in the code at all, it should at least be > consisant. :) > > -- Ian > > From owner-freebsd-arm@FreeBSD.ORG Thu Mar 20 13:02:47 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D1E0483 for ; Thu, 20 Mar 2014 13:02:47 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0DC97165 for ; Thu, 20 Mar 2014 13:02:46 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WQccP-000EGd-9V; Thu, 20 Mar 2014 13:02:45 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2KD2gKF070775; Thu, 20 Mar 2014 07:02:42 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX181SOgwFLWkBpLB2Uhjq9M6 Subject: Re: arm SMP on Cortex-A15 From: Ian Lepore To: Wojciech Macek In-Reply-To: References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 2014 07:02:41 -0600 Message-ID: <1395320561.80941.13.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 13:02:47 -0000 On Thu, 2014-03-20 at 08:42 +0100, Wojciech Macek wrote: > Hi Ian, > > Thanks, I looked at your patch and tried to run it. Unfortunatelly, it is > still something wrong on A15 core. Your changes in pmap_kenter_internal do > cause panics during startup. Apparently we still need to do > cpu_tlb_flushID_SE(va) at the end of that function... but that is weird. I > made this small "fix" and I'm able to boot the system. I'm going to run > stress tests now to see if it is stable. > > Regarding DEBUG, that is really interesting. It you see that on A9 that > seems to be even worse, because suggests a flaw in pmap logic... > > Wojtek Hmmm, do you have r263251? I just noticed that my version of the change to pmap_kenter_internal uses cpu_tlb_flushD_SE(), yours uses cpu_tlb_flushID_SE(). I wonder if changing mine to ID is all it takes to make your system boot? -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Mar 20 20:10:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8495CB5C for ; Thu, 20 Mar 2014 20:10:47 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D01FBF4 for ; Thu, 20 Mar 2014 20:10:46 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id d1so6663309wiv.1 for ; Thu, 20 Mar 2014 13:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=99Dred2I2Anp6fCvVD79UmxkOeS7miKVrAmq7QyPV+M=; b=Q3L9wqr2omlU1vVU71zqX+YvPOLCI/zxeI7/Oi79rGEiV3P5Ks/h1i03AWOrE9sDKT SKDJtRswnjZf2amEd/r51bvoVvN6bai5Yb3kuVOzX3v2tLFQIHFiJF1hXKWniMGiLAqu p7eGAM2PbuGLlR3Cm2IQDr+w2PpsGA3xQrVvXp53JZJ+76JViK0zn9EVUCD7A+49AVsK wUE3KgDetgqTuk0pNeC4lIZH3bhFaqqVAbJGXiNQ2UIL016MVr/Hi7Iz0uvrWFWmyG1m Uf27HXeQ2bmXFzkBnsbT+5luz8o5MGnqiwN3T8oMLaxgwe25E2P43x0ofl+BCzE7r0cs Ephw== MIME-Version: 1.0 X-Received: by 10.180.100.72 with SMTP id ew8mr5057404wib.16.1395346245489; Thu, 20 Mar 2014 13:10:45 -0700 (PDT) Received: by 10.216.40.72 with HTTP; Thu, 20 Mar 2014 13:10:45 -0700 (PDT) In-Reply-To: <1395280002.1367.5.camel@fbsd-laptop> References: <1394852976.1369.3.camel@fbsd-laptop> <1395280002.1367.5.camel@fbsd-laptop> Date: Thu, 20 Mar 2014 17:10:45 -0300 Message-ID: Subject: Re: Beaglebone black: are the AIN pins available with gpioctl From: Luiz Otavio O Souza To: Brian McGovern Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 20:10:47 -0000 On 19 March 2014 22:46, Brian J. McGovern wrote: > > On Sat, 2014-03-15 at 02:23 -0300, Luiz Otavio O Souza wrote: >> On 15 March 2014 00:09, Brian J. McGovern wrote: >> > I'm trying to read through all the details in the Beaglebone Black >> > System Reference manual, but I don't think I've seen this particular >> > piece yet... Are the AIN pins available via gpioctl or another interface >> > in 10.0-RELEASE? >> >> No, there is no support for the ADC on 10.0-RELEASE. >> >> I've just tested a driver for the BBB ADC, now i need to write a man >> page and publish the code (on this ML). >> >> If everything is fine, it will be available on -head and on 10-stable soon. >> >> Luiz >> > > Luiz, > I grabbed your patches that you posted on 17 March, and patched them > in to FreeBSD 10. Overall, the driver seems to work fine. The only issue > that I'm having is that after some period of time (it has varied from a > few minutes to over a half hour), the analog input freezes up, > continuing to provide the last reading, despite changes on the analog > input - verified via a voltage meter. The only way I've been able to > recover is to reboot. > > Obviously, I need to do some more testing and try to figure out why > its locking up, but I thought you'd like to know. Yes, i have seen it here too (and a few other issues). The code wasn't too clever and it was upsetting the ADC in various situations. It was running in continuos mode which was overflowing the FIFO counter, generating spurious interrupts. If you set the prescaler clockdiv to a low value a few other problems show up (the FIFO wasn't being drained at ADC shutdown, etc.). I think i have fixed all the issues and now i can push it to almost 100% of CPU in the interrupt handler without upsetting it. I'll run a 24 hour test and if everything is fine i'll post the updated code. Thanks for the report. Luiz From owner-freebsd-arm@FreeBSD.ORG Fri Mar 21 06:21:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4415DBF5 for ; Fri, 21 Mar 2014 06:21:05 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0223D5B for ; Fri, 21 Mar 2014 06:21:04 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id id10so2175546vcb.12 for ; Thu, 20 Mar 2014 23:20:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PnE5BC+VsuiQ8lVldsCeQs+wZLwT9On0nF8vvZqJKic=; b=Y1NYTsKsci0vr96NWgintokz+wD4M3/uMR8EvP49jxJysXv0KSdLN8dbexvDcoU8u9 Rm+HduBuSdy1xt/vUcQQ0Acv3VdkoVOI4AyWE0XBZunNSnqWiKr4TB+4AcFfssmyiHQ0 tDuLdIq6xP+x6YxijkZaYepWOZPhe8PRir/Ks2a9qWcVbj70ACRiWY0LXZ4k8PSdPbVg 5cBKRpk+0yRV35IH5XoNCL9NozzEaybqe2q8swc5Ki1n15EgkbdWlkmov2G9IcvfgKhd chpEglb1JDjMI4JE00vruXmPY87eSvk4O4/RoEF7EBQ6+Icdd9UnQ0Df9O1U7z3PvLNS eTqw== X-Gm-Message-State: ALoCoQkf364KUCNcnew90G8VNLgYS/zXv7gJPuLhBGM9/3wlOilBSBX4ruJoh/eOdbO+ytuWe9mV MIME-Version: 1.0 X-Received: by 10.58.1.97 with SMTP id 1mr1092755vel.23.1395382858399; Thu, 20 Mar 2014 23:20:58 -0700 (PDT) Received: by 10.220.209.135 with HTTP; Thu, 20 Mar 2014 23:20:58 -0700 (PDT) In-Reply-To: <1395320561.80941.13.camel@revolution.hippie.lan> References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> Date: Fri, 21 Mar 2014 07:20:58 +0100 Message-ID: Subject: Re: arm SMP on Cortex-A15 From: Wojciech Macek To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 06:21:05 -0000 No, changing flushD to flushID did not make any difference, but I think it should be there - D-only flushing might not be sufficient. Currently, I'm running pmap_kernel_internal attached below. It is doing unconditional flushID at the end, just like the old comment was saying :) SMP seems to be stable. /* * add a wired page to the kva * note that in order for the mapping to take effect -- you * should do a invltlb after doing the pmap_kenter... */ static PMAP_INLINE void pmap_kenter_internal(vm_offset_t va, vm_offset_t pa, int flags) { struct l2_bucket *l2b; pt_entry_t *ptep; pt_entry_t opte; PDEBUG(1, printf("pmap_kenter: va = %08x, pa = %08x\n", (uint32_t) va, (uint32_t) pa)); l2b = pmap_get_l2_bucket(pmap_kernel(), va); if (l2b == NULL) l2b = pmap_grow_l2_bucket(pmap_kernel(), va); KASSERT(l2b != NULL, ("No L2 Bucket")); ptep = &l2b->l2b_kva[l2pte_index(va)]; opte = *ptep; if (flags & KENTER_CACHE) { *ptep = L2_S_PROTO | pa | pte_l2_s_cache_mode | L2_S_REF; pmap_set_prot(ptep, VM_PROT_READ | VM_PROT_WRITE, flags & KENTER_USER); } else { *ptep = L2_S_PROTO | pa | L2_S_REF; pmap_set_prot(ptep, VM_PROT_READ|VM_PROT_WRITE|VM_PROT_EXECUTE, 0); } PDEBUG(1, printf("pmap_kenter: pte = %08x, opte = %08x, npte = %08x\n", (uint32_t) ptep, opte, *ptep)); if (!l2pte_valid(opte) && (opte == 0)) { l2b->l2b_occupancy++; } PTE_SYNC(ptep); cpu_tlb_flushID_SE(va); cpu_cpwait(); } 2014-03-20 14:02 GMT+01:00 Ian Lepore : > On Thu, 2014-03-20 at 08:42 +0100, Wojciech Macek wrote: > > Hi Ian, > > > > Thanks, I looked at your patch and tried to run it. Unfortunatelly, it is > > still something wrong on A15 core. Your changes in pmap_kenter_internal > do > > cause panics during startup. Apparently we still need to do > > cpu_tlb_flushID_SE(va) at the end of that function... but that is weird. > I > > made this small "fix" and I'm able to boot the system. I'm going to run > > stress tests now to see if it is stable. > > > > Regarding DEBUG, that is really interesting. It you see that on A9 that > > seems to be even worse, because suggests a flaw in pmap logic... > > > > Wojtek > > Hmmm, do you have r263251? > > I just noticed that my version of the change to pmap_kenter_internal > uses cpu_tlb_flushD_SE(), yours uses cpu_tlb_flushID_SE(). I wonder if > changing mine to ID is all it takes to make your system boot? > > -- Ian > > > From owner-freebsd-arm@FreeBSD.ORG Fri Mar 21 16:22:52 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B68CC78; Fri, 21 Mar 2014 16:22:52 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E20C4F79; Fri, 21 Mar 2014 16:22:51 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s2LGMh2W032019; Fri, 21 Mar 2014 11:22:44 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1jr67f0erq-1; Fri, 21 Mar 2014 11:22:43 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 759084602EB; Fri, 21 Mar 2014 11:22:43 -0500 (CDT) Message-ID: <532C6751.4000201@rice.edu> Date: Fri, 21 Mar 2014 11:22:41 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: "procstat -x" output References: <53261049.50709@rice.edu> <1395006603.1149.559.camel@revolution.hippie.lan> In-Reply-To: <1395006603.1149.559.camel@revolution.hippie.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.713890987064109 urlsuspect_oldscore=0.713890987064109 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.713890987064109 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1403210085 Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:22:52 -0000 On 03/16/2014 16:50, Ian Lepore wrote: > On Sun, 2014-03-16 at 15:57 -0500, Alan Cox wrote: >> Folks, >> >> Could someone please run "procstat -x" on any process, and cut-and-paste >> the output into a reply message. I'm trying to debug a crash that >> occurs on arm for a patch that I'm developing. >> >> Thanks, >> Alan > cpsim# procstat -x 720 > PID COMM AUXV VALUE > 720 cpsim AT_PHDR 0x8034 > 720 cpsim AT_PHENT 32 > 720 cpsim AT_PHNUM 7 > 720 cpsim AT_PAGESZ 4096 > 720 cpsim AT_FLAGS 0 > 720 cpsim AT_ENTRY 0xf1c0 > 720 cpsim AT_BASE 0x2015b000 > 720 cpsim AT_EXECPATH 0xbfffffb9 > 720 cpsim AT_OSRELDATE 1100011 > 720 cpsim AT_CANARY 0xbfffff99 > 720 cpsim AT_CANARYLEN 32 > 720 cpsim AT_NCPUS 4 > 720 cpsim AT_PAGESIZES 0xbfffff91 > 720 cpsim AT_PAGESIZESLEN 8 > 720 cpsim AT_STACKPROT NONEXECUTABLE > Thanks, again. A couple of days ago, kib@ committed a patch, r263349, that should result in AT_PAGESIZES now having a 4-byte aligned address on arm. This misalignment caused problems for a patch that I'm developing. If/when anyone here updates to a newer kernel than r263349, can you please rerun "procstat -x" and report the results. I want to verify that the alignment problem is really fixed on arm. Thanks, Alan From owner-freebsd-arm@FreeBSD.ORG Fri Mar 21 22:46:22 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43BE6A47 for ; Fri, 21 Mar 2014 22:46:22 +0000 (UTC) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 087D3C79 for ; Fri, 21 Mar 2014 22:46:21 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1WR8Cc-006LC4-1d; Fri, 21 Mar 2014 23:46:14 +0100 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Ralf Wenk To: Alan Cox Subject: Re: "procstat -x" output In-reply-to: <532C6751.4000201@rice.edu> References: <53261049.50709@rice.edu> <1395006603.1149.559.camel@revolution.hippie.lan> <532C6751.4000201@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 2014 23:46:13 +0100 Message-Id: Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 22:46:22 -0000 On Fri, 21 Mar 2014 11:22:41 -0500, Alan Cox wrote: > On 03/16/2014 16:50, Ian Lepore wrote: > > On Sun, 2014-03-16 at 15:57 -0500, Alan Cox wrote: > >> Folks, > >> > >> Could someone please run "procstat -x" on any process, and cut-and-paste > >> the output into a reply message. I'm trying to debug a crash that > >> occurs on arm for a patch that I'm developing. > >> > >> Thanks, > >> Alan > > cpsim# procstat -x 720 > > PID COMM AUXV VALUE > > 720 cpsim AT_PHDR 0x8034 > > 720 cpsim AT_PHENT 32 > > 720 cpsim AT_PHNUM 7 > > 720 cpsim AT_PAGESZ 4096 > > 720 cpsim AT_FLAGS 0 > > 720 cpsim AT_ENTRY 0xf1c0 > > 720 cpsim AT_BASE 0x2015b000 > > 720 cpsim AT_EXECPATH 0xbfffffb9 > > 720 cpsim AT_OSRELDATE 1100011 > > 720 cpsim AT_CANARY 0xbfffff99 > > 720 cpsim AT_CANARYLEN 32 > > 720 cpsim AT_NCPUS 4 > > 720 cpsim AT_PAGESIZES 0xbfffff91 > > 720 cpsim AT_PAGESIZESLEN 8 > > 720 cpsim AT_STACKPROT NONEXECUTABLE > > > > Thanks, again. A couple of days ago, kib@ committed a patch, r263349, > that should result in AT_PAGESIZES now having a 4-byte aligned address > on arm. This misalignment caused problems for a patch that I'm > developing. If/when anyone here updates to a newer kernel than r263349, > can you please rerun "procstat -x" and report the results. I want to > verify that the alignment problem is really fixed on arm. 11.0-CURRENT #0 r263476: Fri Mar 21 18:29:48 CET 2014 $ procstat -x 808 PID COMM AUXV VALUE 808 sh AT_PHDR 0x8034 808 sh AT_PHENT 32 808 sh AT_PHNUM 6 808 sh AT_PAGESZ 4096 808 sh AT_FLAGS 0 808 sh AT_ENTRY 0xa5c0 808 sh AT_BASE 0x2002f000 808 sh AT_EXECPATH 0xbfffffc4 808 sh AT_OSRELDATE 1100014 808 sh AT_CANARY 0xbfffffa4 808 sh AT_CANARYLEN 32 808 sh AT_NCPUS 1 808 sh AT_PAGESIZES 0xbfffff9c 808 sh AT_PAGESIZESLEN 8 808 sh AT_STACKPROT NONEXECUTABLE $ Ralf From owner-freebsd-arm@FreeBSD.ORG Fri Mar 21 23:12:16 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB254986; Fri, 21 Mar 2014 23:12:16 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E90E6ECB; Fri, 21 Mar 2014 23:12:15 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s2LNCBGm020822; Sat, 22 Mar 2014 01:12:11 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s2LNCBBO020781; Fri, 21 Mar 2014 23:12:11 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 21 Mar 2014 23:12:11 GMT Message-Id: <201403212312.s2LNCBBO020781@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 23:12:16 -0000 TB --- 2014-03-21 20:21:14 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-21 20:21:14 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-21 20:21:14 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-21 20:21:14 - cleaning the object tree TB --- 2014-03-21 20:21:14 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-21 20:22:07 - At svn revision 263542 TB --- 2014-03-21 20:22:08 - building world TB --- 2014-03-21 20:22:08 - CROSS_BUILD_TESTING=YES TB --- 2014-03-21 20:22:08 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-21 20:22:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-21 20:22:08 - SRCCONF=/dev/null TB --- 2014-03-21 20:22:08 - TARGET=arm TB --- 2014-03-21 20:22:08 - TARGET_ARCH=arm TB --- 2014-03-21 20:22:08 - TZ=UTC TB --- 2014-03-21 20:22:08 - __MAKE_CONF=/dev/null TB --- 2014-03-21 20:22:08 - cd /src TB --- 2014-03-21 20:22:08 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 21 20:22:19 UTC 2014 >>> 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 [...] /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:108:2: error: ARM_NARCH is 0 #error ARM_NARCH is 0 ^ /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:183:2: error: ARM_NMMUS is 0 #error ARM_NMMUS is 0 ^ 2 errors generated. mkdep: compile failed *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/route6d *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-21 23:12:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-21 23:12:10 - ERROR: failed to build world TB --- 2014-03-21 23:12:10 - 8198.53 user 2071.12 system 10255.48 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 22 04:52:50 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0139426A for ; Sat, 22 Mar 2014 04:52:50 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B8819A7 for ; Sat, 22 Mar 2014 04:52:48 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s2M4qlPP028869; Fri, 21 Mar 2014 23:52:47 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1jrv3kg51t-1; Fri, 21 Mar 2014 23:52:47 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id AB5974601A4; Fri, 21 Mar 2014 23:52:46 -0500 (CDT) Message-ID: <532D171E.6070705@rice.edu> Date: Fri, 21 Mar 2014 23:52:46 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ralf Wenk Subject: Re: "procstat -x" output References: <53261049.50709@rice.edu> <1395006603.1149.559.camel@revolution.hippie.lan> <532C6751.4000201@rice.edu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.713890987064109 urlsuspect_oldscore=0.713890987064109 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.713890987064109 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1403210193 Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 04:52:50 -0000 On 03/21/2014 17:46, Ralf Wenk wrote: > On Fri, 21 Mar 2014 11:22:41 -0500, Alan Cox wrote: >> On 03/16/2014 16:50, Ian Lepore wrote: >>> On Sun, 2014-03-16 at 15:57 -0500, Alan Cox wrote: >>>> Folks, >>>> >>>> Could someone please run "procstat -x" on any process, and cut-and-paste >>>> the output into a reply message. I'm trying to debug a crash that >>>> occurs on arm for a patch that I'm developing. >>>> >>>> Thanks, >>>> Alan >>> cpsim# procstat -x 720 >>> PID COMM AUXV VALUE >>> 720 cpsim AT_PHDR 0x8034 >>> 720 cpsim AT_PHENT 32 >>> 720 cpsim AT_PHNUM 7 >>> 720 cpsim AT_PAGESZ 4096 >>> 720 cpsim AT_FLAGS 0 >>> 720 cpsim AT_ENTRY 0xf1c0 >>> 720 cpsim AT_BASE 0x2015b000 >>> 720 cpsim AT_EXECPATH 0xbfffffb9 >>> 720 cpsim AT_OSRELDATE 1100011 >>> 720 cpsim AT_CANARY 0xbfffff99 >>> 720 cpsim AT_CANARYLEN 32 >>> 720 cpsim AT_NCPUS 4 >>> 720 cpsim AT_PAGESIZES 0xbfffff91 >>> 720 cpsim AT_PAGESIZESLEN 8 >>> 720 cpsim AT_STACKPROT NONEXECUTABLE >>> >> Thanks, again. A couple of days ago, kib@ committed a patch, r263349, >> that should result in AT_PAGESIZES now having a 4-byte aligned address >> on arm. This misalignment caused problems for a patch that I'm >> developing. If/when anyone here updates to a newer kernel than r263349, >> can you please rerun "procstat -x" and report the results. I want to >> verify that the alignment problem is really fixed on arm. > 11.0-CURRENT #0 r263476: Fri Mar 21 18:29:48 CET 2014 > > $ procstat -x 808 > PID COMM AUXV VALUE > 808 sh AT_PHDR 0x8034 > 808 sh AT_PHENT 32 > 808 sh AT_PHNUM 6 > 808 sh AT_PAGESZ 4096 > 808 sh AT_FLAGS 0 > 808 sh AT_ENTRY 0xa5c0 > 808 sh AT_BASE 0x2002f000 > 808 sh AT_EXECPATH 0xbfffffc4 > 808 sh AT_OSRELDATE 1100014 > 808 sh AT_CANARY 0xbfffffa4 > 808 sh AT_CANARYLEN 32 > 808 sh AT_NCPUS 1 > 808 sh AT_PAGESIZES 0xbfffff9c > 808 sh AT_PAGESIZESLEN 8 > 808 sh AT_STACKPROT NONEXECUTABLE > $ > Thanks. The output looks good. Alan From owner-freebsd-arm@FreeBSD.ORG Sat Mar 22 07:12:28 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFA366D3; Sat, 22 Mar 2014 07:12:28 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED27AC11; Sat, 22 Mar 2014 07:12:27 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s2M7CL1t071239; Sat, 22 Mar 2014 09:12:21 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s2M7CLb3071226; Sat, 22 Mar 2014 07:12:21 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 22 Mar 2014 07:12:21 GMT Message-Id: <201403220712.s2M7CLb3071226@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 07:12:28 -0000 TB --- 2014-03-22 04:20:34 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-22 04:20:34 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-22 04:20:34 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-22 04:20:34 - cleaning the object tree TB --- 2014-03-22 04:21:21 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-22 04:22:05 - At svn revision 263618 TB --- 2014-03-22 04:22:06 - building world TB --- 2014-03-22 04:22:06 - CROSS_BUILD_TESTING=YES TB --- 2014-03-22 04:22:06 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-22 04:22:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-22 04:22:06 - SRCCONF=/dev/null TB --- 2014-03-22 04:22:06 - TARGET=arm TB --- 2014-03-22 04:22:06 - TARGET_ARCH=arm TB --- 2014-03-22 04:22:06 - TZ=UTC TB --- 2014-03-22 04:22:06 - __MAKE_CONF=/dev/null TB --- 2014-03-22 04:22:06 - cd /src TB --- 2014-03-22 04:22:06 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 22 04:22:16 UTC 2014 >>> 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 [...] /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:108:2: error: ARM_NARCH is 0 #error ARM_NARCH is 0 ^ /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:183:2: error: ARM_NMMUS is 0 #error ARM_NMMUS is 0 ^ 2 errors generated. mkdep: compile failed *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/route6d *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-22 07:12:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-22 07:12:20 - ERROR: failed to build world TB --- 2014-03-22 07:12:20 - 8209.53 user 2099.89 system 10305.66 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 22 13:20:06 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7785780 for ; Sat, 22 Mar 2014 13:20:06 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A9A6C8E for ; Sat, 22 Mar 2014 13:20:06 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WRLqG-0008G2-Vh; Sat, 22 Mar 2014 13:20:05 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2MDK1Gh073284; Sat, 22 Mar 2014 07:20:01 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+m/VtzIUopcIJJ6znVnEov Subject: Re: arm SMP on Cortex-A15 From: Ian Lepore To: Wojciech Macek In-Reply-To: References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 2014 07:20:01 -0600 Message-ID: <1395494401.81853.34.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 13:20:06 -0000 On Fri, 2014-03-21 at 07:20 +0100, Wojciech Macek wrote: > No, changing flushD to flushID did not make any difference, but I think it > should be there - D-only flushing might not be sufficient. > Olivier reminded me right after I posted that: last week I made a change to cpufunc.c that makes flushD and flushID the same. So of course it made no difference. :) It really should be flushID though, in case that ever changes. You didn't say whether you have that change, which was r263251. > Currently, I'm running pmap_kernel_internal attached below. It is doing > unconditional flushID at the end, just like the old comment was saying :) > SMP seems to be stable. > That seems to say that somehow there is a valid TLB entry even though the old pte for that entry is zero. That means there's a problem somewhere else in the code, but I don't see it. It looks to me like we do a TLB flush everywhere that we zero out a pte. You said without the unconditional flush it panics at startup. Where in startup? Early, or after init is launched or what? Where does the panic backtrace to? If we've got some other pte/tlb maintenance problem, I'd hate to hide it with this unconditional flush and have it appear as some other problem later that will be even harder to track down. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 22 15:11:02 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 714AC3A9; Sat, 22 Mar 2014 15:11:02 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9006F7D6; Sat, 22 Mar 2014 15:11:01 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s2MFAwqg086291; Sat, 22 Mar 2014 17:10:58 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s2MFAwNU086290; Sat, 22 Mar 2014 15:10:58 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 22 Mar 2014 15:10:58 GMT Message-Id: <201403221510.s2MFAwNU086290@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 15:11:02 -0000 TB --- 2014-03-22 12:20:38 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-22 12:20:38 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-22 12:20:38 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-22 12:20:38 - cleaning the object tree TB --- 2014-03-22 12:21:11 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-22 12:22:05 - At svn revision 263630 TB --- 2014-03-22 12:22:06 - building world TB --- 2014-03-22 12:22:06 - CROSS_BUILD_TESTING=YES TB --- 2014-03-22 12:22:06 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-22 12:22:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-22 12:22:06 - SRCCONF=/dev/null TB --- 2014-03-22 12:22:06 - TARGET=arm TB --- 2014-03-22 12:22:06 - TARGET_ARCH=arm TB --- 2014-03-22 12:22:06 - TZ=UTC TB --- 2014-03-22 12:22:06 - __MAKE_CONF=/dev/null TB --- 2014-03-22 12:22:06 - cd /src TB --- 2014-03-22 12:22:06 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 22 12:22:16 UTC 2014 >>> 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 [...] /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:108:2: error: ARM_NARCH is 0 #error ARM_NARCH is 0 ^ /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:183:2: error: ARM_NMMUS is 0 #error ARM_NMMUS is 0 ^ 2 errors generated. mkdep: compile failed *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/route6d *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-22 15:10:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-22 15:10:58 - ERROR: failed to build world TB --- 2014-03-22 15:10:58 - 8161.36 user 2060.53 system 10219.73 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 22 23:12:18 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3F8FFD6; Sat, 22 Mar 2014 23:12:18 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 75DD51AC; Sat, 22 Mar 2014 23:12:16 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s2MNC9Vo011283; Sun, 23 Mar 2014 01:12:09 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s2MNC9O2011212; Sat, 22 Mar 2014 23:12:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 22 Mar 2014 23:12:09 GMT Message-Id: <201403222312.s2MNC9O2011212@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 23:12:19 -0000 TB --- 2014-03-22 20:20:45 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-22 20:20:45 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-22 20:20:45 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-22 20:20:45 - cleaning the object tree TB --- 2014-03-22 20:21:14 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-22 20:22:02 - At svn revision 263649 TB --- 2014-03-22 20:22:03 - building world TB --- 2014-03-22 20:22:03 - CROSS_BUILD_TESTING=YES TB --- 2014-03-22 20:22:03 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-22 20:22:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-22 20:22:03 - SRCCONF=/dev/null TB --- 2014-03-22 20:22:03 - TARGET=arm TB --- 2014-03-22 20:22:03 - TARGET_ARCH=arm TB --- 2014-03-22 20:22:03 - TZ=UTC TB --- 2014-03-22 20:22:03 - __MAKE_CONF=/dev/null TB --- 2014-03-22 20:22:03 - cd /src TB --- 2014-03-22 20:22:03 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 22 20:22:13 UTC 2014 >>> 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 [...] /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:108:2: error: ARM_NARCH is 0 #error ARM_NARCH is 0 ^ /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:183:2: error: ARM_NMMUS is 0 #error ARM_NMMUS is 0 ^ 2 errors generated. mkdep: compile failed *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/route6d *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-22 23:12:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-22 23:12:08 - ERROR: failed to build world TB --- 2014-03-22 23:12:08 - 8212.62 user 2071.68 system 10283.35 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Mar 23 07:11:54 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7CB94D5; Sun, 23 Mar 2014 07:11:54 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C7AF89B3; Sun, 23 Mar 2014 07:11:53 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s2N7BoD4061952; Sun, 23 Mar 2014 09:11:50 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s2N7Bo08061951; Sun, 23 Mar 2014 07:11:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Mar 2014 07:11:50 GMT Message-Id: <201403230711.s2N7Bo08061951@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 07:11:54 -0000 TB --- 2014-03-23 04:20:44 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-23 04:20:44 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-23 04:20:44 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-23 04:20:44 - cleaning the object tree TB --- 2014-03-23 04:21:15 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-23 04:21:43 - At svn revision 263655 TB --- 2014-03-23 04:21:44 - building world TB --- 2014-03-23 04:21:44 - CROSS_BUILD_TESTING=YES TB --- 2014-03-23 04:21:44 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-23 04:21:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-23 04:21:44 - SRCCONF=/dev/null TB --- 2014-03-23 04:21:44 - TARGET=arm TB --- 2014-03-23 04:21:44 - TARGET_ARCH=arm TB --- 2014-03-23 04:21:44 - TZ=UTC TB --- 2014-03-23 04:21:44 - __MAKE_CONF=/dev/null TB --- 2014-03-23 04:21:44 - cd /src TB --- 2014-03-23 04:21:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 23 04:21:53 UTC 2014 >>> 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 [...] /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:108:2: error: ARM_NARCH is 0 #error ARM_NARCH is 0 ^ /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:183:2: error: ARM_NMMUS is 0 #error ARM_NMMUS is 0 ^ 2 errors generated. mkdep: compile failed *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/route6d *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-23 07:11:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-23 07:11:50 - ERROR: failed to build world TB --- 2014-03-23 07:11:50 - 8211.06 user 2043.50 system 10266.20 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Mar 23 15:22:19 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E476DD99; Sun, 23 Mar 2014 15:22:19 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0DE7D3D3; Sun, 23 Mar 2014 15:22:18 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s2NFM6AA019230; Sun, 23 Mar 2014 17:22:06 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s2NFM5Kc019213; Sun, 23 Mar 2014 15:22:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Mar 2014 15:22:05 GMT Message-Id: <201403231522.s2NFM5Kc019213@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:22:20 -0000 TB --- 2014-03-23 12:30:45 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-23 12:30:45 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-23 12:30:45 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-23 12:30:45 - cleaning the object tree TB --- 2014-03-23 12:31:16 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-23 12:32:03 - At svn revision 263659 TB --- 2014-03-23 12:32:04 - building world TB --- 2014-03-23 12:32:04 - CROSS_BUILD_TESTING=YES TB --- 2014-03-23 12:32:04 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-23 12:32:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-23 12:32:04 - SRCCONF=/dev/null TB --- 2014-03-23 12:32:04 - TARGET=arm TB --- 2014-03-23 12:32:04 - TARGET_ARCH=arm TB --- 2014-03-23 12:32:04 - TZ=UTC TB --- 2014-03-23 12:32:04 - __MAKE_CONF=/dev/null TB --- 2014-03-23 12:32:04 - cd /src TB --- 2014-03-23 12:32:04 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 23 12:32:13 UTC 2014 >>> 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 [...] /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:108:2: error: ARM_NARCH is 0 #error ARM_NARCH is 0 ^ /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:183:2: error: ARM_NMMUS is 0 #error ARM_NMMUS is 0 ^ 2 errors generated. mkdep: compile failed *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/route6d *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-23 15:22:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-23 15:22:05 - ERROR: failed to build world TB --- 2014-03-23 15:22:05 - 8213.05 user 2072.59 system 10279.23 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Mar 23 16:59:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E30CE269 for ; Sun, 23 Mar 2014 16:59:35 +0000 (UTC) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE7ABD33 for ; Sun, 23 Mar 2014 16:59:35 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id rl12so4479180iec.36 for ; Sun, 23 Mar 2014 09:59:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type :content-transfer-encoding:subject:date:references:to:message-id :mime-version; bh=KLeJPjEeDtNubDReN1o+wAC/TIQHQdjPE3EX47q86AA=; b=DIh2RDr0/41FP2/YUbBjTWKqXHawIUnejWAgDjAO/Pj2rtiL7ufltsvoRDRLjQ6Jid y6S3ou1n6LaN1jwFVW7SKAXxt0tgtVH5GGquVshwu0l1PfHRMkZ4AlwvBKDct3T0QgAV XSOmk88k+xabppmA0HJqJLbugy3sYfOYG7cm+0EDmBUhLONSM+ybLsc1JDcOlTkXdF9I EvKhy11oU/EtcMys8SBED1/g+ZS9feY3F9BRK8XdDkdPDNLG1TClevpBCDVcGbWr8mOs 6+GNbFuCdPJvvwIOxgqeQMC1/LB0uOoYe6xvRKEh1jtteDguhOb4a8dMaAvX1loxBpyD EzUA== X-Gm-Message-State: ALoCoQmQA0KfJWHvJHyD/bZheOB3uSy3eW7jPnfP5g6J/fUxg6MTmVhWRgiiWYjWKtlIvNumEwtO X-Received: by 10.50.56.109 with SMTP id z13mr7416175igp.6.1395593974663; Sun, 23 Mar 2014 09:59:34 -0700 (PDT) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id rj10sm17869855igc.8.2014.03.23.09.59.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Mar 2014 09:59:33 -0700 (PDT) Sender: Warner Losh From: Warner Losh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Fwd: [releng_10 tinderbox] failure on arm/arm Date: Sun, 23 Mar 2014 10:59:32 -0600 References: <201403231522.s2NFM5Kc019213@worker01.tb.des.no> To: freebsd-arm , toolchain@freebsd.org Message-Id: <8EA3BF27-225E-4818-8983-8793FCDF08D9@bsdimp.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 16:59:35 -0000 About the time clang was MFC=92d, this started appearing. It has been = several days now. Did the clang MFC botch something? Was the timing just a coincidence? Warner Begin forwarded message: > From: FreeBSD Tinderbox > Subject: [releng_10 tinderbox] failure on arm/arm > Date: March 23, 2014 at 9:22:05 AM MDT > To: FreeBSD Tinderbox , , = >=20 > TB --- 2014-03-23 12:30:45 - tinderbox 2.20 running on = worker01.tb.des.no > TB --- 2014-03-23 12:30:45 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 = FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2014-03-23 12:30:45 - starting RELENG_10 tinderbox run for = arm/arm > TB --- 2014-03-23 12:30:45 - cleaning the object tree > TB --- 2014-03-23 12:31:16 - /usr/local/bin/svn stat --no-ignore /src > TB --- 2014-03-23 12:32:03 - At svn revision 263659 > TB --- 2014-03-23 12:32:04 - building world > TB --- 2014-03-23 12:32:04 - CROSS_BUILD_TESTING=3DYES > TB --- 2014-03-23 12:32:04 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2014-03-23 12:32:04 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2014-03-23 12:32:04 - SRCCONF=3D/dev/null > TB --- 2014-03-23 12:32:04 - TARGET=3Darm > TB --- 2014-03-23 12:32:04 - TARGET_ARCH=3Darm > TB --- 2014-03-23 12:32:04 - TZ=3DUTC > TB --- 2014-03-23 12:32:04 - __MAKE_CONF=3D/dev/null > TB --- 2014-03-23 12:32:04 - cd /src > TB --- 2014-03-23 12:32:04 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Sun Mar 23 12:32:13 UTC 2014 >>>> 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 > [...] > /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:108:2: error: = ARM_NARCH is 0 > #error ARM_NARCH is 0 > ^ > /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:183:2: error: = ARM_NMMUS is 0 > #error ARM_NMMUS is 0 > ^ > 2 errors generated. > mkdep: compile failed > *** Error code 1 >=20 > Stop. > bmake[3]: stopped in /src/usr.sbin/route6d > *** Error code 1 >=20 > Stop. > bmake[2]: stopped in /src/usr.sbin > *** Error code 1 >=20 > Stop. > bmake[1]: stopped in /src > *** Error code 1 >=20 > Stop. > bmake: stopped in /src > *** [buildworld] Error code 1 >=20 > Stop in /src. > TB --- 2014-03-23 15:22:05 - WARNING: /usr/bin/make returned exit code = 1=20 > TB --- 2014-03-23 15:22:05 - ERROR: failed to build world > TB --- 2014-03-23 15:22:05 - 8213.05 user 2072.59 system 10279.23 real >=20 >=20 > = http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full > _______________________________________________ > 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 Mar 23 21:32:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADDF577E; Sun, 23 Mar 2014 21:32:15 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A7BA92B; Sun, 23 Mar 2014 21:32:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b9f0:3633:d663:add7] (unknown [IPv6:2001:7b8:3a7:0:b9f0:3633:d663:add7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4694F5C43; Sun, 23 Mar 2014 22:32:06 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_706FC58F-004D-4E56-9856-22E4EBAEFCB3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [releng_10 tinderbox] failure on arm/arm From: Dimitry Andric In-Reply-To: <8EA3BF27-225E-4818-8983-8793FCDF08D9@bsdimp.com> Date: Sun, 23 Mar 2014 22:31:58 +0100 Message-Id: References: <201403231522.s2NFM5Kc019213@worker01.tb.des.no> <8EA3BF27-225E-4818-8983-8793FCDF08D9@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1874) Cc: toolchain@freebsd.org, freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 21:32:15 -0000 --Apple-Mail=_706FC58F-004D-4E56-9856-22E4EBAEFCB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 23 Mar 2014, at 17:59, Warner Losh wrote: > About the time clang was MFC=92d, this started appearing. It has been = several days now. >=20 > Did the clang MFC botch something? Was the timing just a coincidence? I hope the latter, but I didn't investigate yet. I do know that I ran a make universe before the clang 3.4 merge, and that worked just fine. That said, at first glance this looks like some sort of scripting problem? Does anybody know off the top of their heads where ARM_NARCH and ARM_NMMUS are coming from? -Dimitry --Apple-Mail=_706FC58F-004D-4E56-9856-22E4EBAEFCB3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMvUtEACgkQsF6jCi4glqNwdQCgx3joabmx/I3AvpyTnLen9RWg 3r8AnRfhvmBqK+RvihvHs2kq7CN4CoOj =KQec -----END PGP SIGNATURE----- --Apple-Mail=_706FC58F-004D-4E56-9856-22E4EBAEFCB3-- From owner-freebsd-arm@FreeBSD.ORG Sun Mar 23 21:57:40 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB02FB40; Sun, 23 Mar 2014 21:57:40 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AAFEDAB0; Sun, 23 Mar 2014 21:57:40 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WRqOh-0000mw-DB; Sun, 23 Mar 2014 21:57:39 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2NLvapd074529; Sun, 23 Mar 2014 15:57:36 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+F5KMVbD0rRY4G9sMml+3P Subject: Re: [releng_10 tinderbox] failure on arm/arm From: Ian Lepore To: Dimitry Andric In-Reply-To: References: <201403231522.s2NFM5Kc019213@worker01.tb.des.no> <8EA3BF27-225E-4818-8983-8793FCDF08D9@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" Date: Sun, 23 Mar 2014 15:57:36 -0600 Message-ID: <1395611856.81853.54.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s2NLvapd074529 Cc: toolchain@FreeBSD.org, freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 21:57:40 -0000 On Sun, 2014-03-23 at 22:31 +0100, Dimitry Andric wrote: > On 23 Mar 2014, at 17:59, Warner Losh wrote: > > About the time clang was MFC=A2d, this started appearing. It has been= several days now. > >=20 > > Did the clang MFC botch something? Was the timing just a coincidence? >=20 > I hope the latter, but I didn't investigate yet. I do know that I ran = a > make universe before the clang 3.4 merge, and that worked just fine. >=20 > That said, at first glance this looks like some sort of scripting > problem? Does anybody know off the top of their heads where ARM_NARCH > and ARM_NMMUS are coming from? >=20 > -Dimitry >=20 from sys/arm/include/cpuconf.h. iirc, they use some compiler predefined macros. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Mar 23 22:51:15 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5A3BA6C; Sun, 23 Mar 2014 22:51:15 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B949F4B; Sun, 23 Mar 2014 22:51:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b9f0:3633:d663:add7] (unknown [IPv6:2001:7b8:3a7:0:b9f0:3633:d663:add7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 71A475C43; Sun, 23 Mar 2014 23:51:06 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_264D24DE-140D-4E8C-B009-5E9D12630A1C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [releng_10 tinderbox] failure on arm/arm From: Dimitry Andric In-Reply-To: <1395611856.81853.54.camel@revolution.hippie.lan> Date: Sun, 23 Mar 2014 23:50:51 +0100 Message-Id: References: <201403231522.s2NFM5Kc019213@worker01.tb.des.no> <8EA3BF27-225E-4818-8983-8793FCDF08D9@bsdimp.com> <1395611856.81853.54.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: toolchain@FreeBSD.org, freebsd-arm , Gleb Smirnoff X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 22:51:16 -0000 --Apple-Mail=_264D24DE-140D-4E8C-B009-5E9D12630A1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-7 On 23 Mar 2014, at 22:57, Ian Lepore wrote: > On Sun, 2014-03-23 at 22:31 +0100, Dimitry Andric wrote: >> On 23 Mar 2014, at 17:59, Warner Losh wrote: >>> About the time clang was MFC=A2d, this started appearing. It has = been several days now. >>>=20 >>> Did the clang MFC botch something? Was the timing just a = coincidence? >>=20 >> I hope the latter, but I didn't investigate yet. I do know that I = ran a >> make universe before the clang 3.4 merge, and that worked just fine. >>=20 >> That said, at first glance this looks like some sort of scripting >> problem? Does anybody know off the top of their heads where = ARM_NARCH >> and ARM_NMMUS are coming from? >>=20 >> -Dimitry >>=20 >=20 > from sys/arm/include/cpuconf.h. iirc, they use some compiler = predefined > macros. I just had a look at the full build log, and it died here: =3D=3D=3D> usr.sbin/route6d (depend) rm -f .depend CC=3D'cc ' mkdep -f .depend -a -DHAVE_POLL_H -std=3Dgnu99 = /src/usr.sbin/route6d/route6d.c In file included from /src/usr.sbin/route6d/route6d.c:68: In file included from /obj/arm.arm/src/tmp/usr/include/net/route.h:36: In file included from /obj/arm.arm/src/tmp/usr/include/sys/counter.h:35: In file included from = /obj/arm.arm/src/tmp/usr/include/machine/counter.h:32: In file included from /obj/arm.arm/src/tmp/usr/include/sys/pcpu.h:48: In file included from = /obj/arm.arm/src/tmp/usr/include/machine/pcpu.h:35: /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:108:2: error: = ARM_NARCH is 0 #error ARM_NARCH is 0 ^ /obj/arm.arm/src/tmp/usr/include/machine/cpuconf.h:183:2: error: = ARM_NMMUS is 0 #error ARM_NMMUS is 0 ^ 2 errors generated. The parts in cpuconf.h that produce this error are: #if ARM_NARCH =3D=3D 0 && !defined(KLD_MODULE) && defined(_KERNEL) #error ARM_NARCH is 0 #endif [...] #if ARM_NMMUS =3D=3D 0 && !defined(KLD_MODULE) && defined(_KERNEL) #error ARM_NMMUS is 0 #endif so this error was most likely caused by route6d.c defining _KERNEL to 1 before including . I expect that Gleb Smirnoff's r263668 (which removes the _KERNEL define again) will fix it. -Dimitry --Apple-Mail=_264D24DE-140D-4E8C-B009-5E9D12630A1C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMvZVcACgkQsF6jCi4glqN3FwCdHaaxoSY1cqhsMYuVwK5Qq90C A4EAoOH3+7Pjhfh+ezYH04vntav4N8ii =3w3y -----END PGP SIGNATURE----- --Apple-Mail=_264D24DE-140D-4E8C-B009-5E9D12630A1C-- From owner-freebsd-arm@FreeBSD.ORG Mon Mar 24 02:34:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E2BB18E for ; Mon, 24 Mar 2014 02:34:48 +0000 (UTC) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 186FC242 for ; Mon, 24 Mar 2014 02:34:47 +0000 (UTC) Received: from [208.184.220.60] (helo=[10.112.201.108]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WRuio-0001Ff-PG for freebsd-arm@freebsd.org; Sun, 23 Mar 2014 19:34:45 -0700 Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: HDMI output on Beaglebone black From: Oleksandr Tymoshenko In-Reply-To: <7C58B233-1E84-47A3-ABB2-0038928BB1B2@bluezbox.com> Date: Sun, 23 Mar 2014 19:34:08 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <536748F0-FE1C-42CD-B33A-D7484282D840@bluezbox.com> References: <7C58B233-1E84-47A3-ABB2-0038928BB1B2@bluezbox.com> X-Mailer: Apple Mail (2.1874) 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 Dec 26, 2013, at 1:18 PM, Oleksandr Tymoshenko wrote: > > On 2013-12-25, at 9:08 PM, "Lundberg, Johannes" wrote: > >> Hi >> >> According to the readme for Beaglebone Black in crochet-freebsd there is no >> support for HMDI output yet (as of Dec 2013). >> >> Does anyone know what is required to make this work? > > You need to write driver for NXP TDA19988 HDMI (LCD to HDMI converter), driver > for LCD controller and vt/syscons wrapper. Also properly pinmux LCD pins in .dts. > > I did some experiments few months back but didn't get far: > http://people.freebsd.org/~gonzo/arm/patches/bbb-tda.diff [...] Content analysis details: (-1.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.0 MISSING_HEADERS Missing To: header -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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 02:34:48 -0000 On Dec 26, 2013, at 1:18 PM, Oleksandr Tymoshenko = wrote: >=20 > On 2013-12-25, at 9:08 PM, "Lundberg, Johannes" = wrote: >=20 >> Hi >>=20 >> According to the readme for Beaglebone Black in crochet-freebsd there = is no >> support for HMDI output yet (as of Dec 2013). >>=20 >> Does anyone know what is required to make this work? >=20 > You need to write driver for NXP TDA19988 HDMI (LCD to HDMI = converter), driver=20 > for LCD controller and vt/syscons wrapper. Also properly pinmux LCD = pins in .dts. >=20 > I did some experiments few months back but didn't get far: > http://people.freebsd.org/~gonzo/arm/patches/bbb-tda.diff I got a little bit further with this and thought I=1B$B!G=1B(Bd better = post my WIP before somebody=20 wastes his/her time fixing things that=1B$B!G=1B(Bs already fixed. Here is diff of my work dir:=20 http://people.freebsd.org/~gonzo/arm/patches/tda19988.diff There are several problems fixed comparing to first patch: - Fixed HDMI controller I2C address - Register write should be one I2C transaction - Current TI I2C driver can=1B$B!G=1B(Bt read more bytes than FIFO = length. I moved read/write=20 handler to ithread, instead of notifying requesting thread with = wakeup. Kernel with this patch can read and parse EDID. I failed to get video output working even with test pattern (part of code commented by "#if = 0=1B$B!I=1B(B).=20 Part of this code is direct copy-paste from linux driver just to get = something=20 working before re-coding it properly.= From owner-freebsd-arm@FreeBSD.ORG Mon Mar 24 11:06:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97C34F29 for ; Mon, 24 Mar 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A0D1166 for ; Mon, 24 Mar 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2OB6gs2013791 for ; Mon, 24 Mar 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2OB6fgh013789 for freebsd-arm@FreeBSD.org; Mon, 24 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Mar 2014 11:06:41 GMT Message-Id: <201403241106.s2OB6fgh013789@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 11:06:42 -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/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o ports/175605 arm please fix build binutils-2.23.1 in raspberry pi 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 ports/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) 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 32 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 24 13:38:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9531910F for ; Mon, 24 Mar 2014 13:38:09 +0000 (UTC) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B83369B for ; Mon, 24 Mar 2014 13:38:09 +0000 (UTC) Received: by mail-ve0-f181.google.com with SMTP id oy12so5793289veb.12 for ; Mon, 24 Mar 2014 06:38:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bA/tRUROyiZvfaG+u6NkgzxNF3UBmhtP15K7CxNwNoc=; b=ZKPOGvrDQIftJehAu8ou/Ox91q2/r8Ky0xexviNnJ09Bz3fwu1KeA4iGgN2NbZxMdt 21/lhHNf15/7qUjPrQzFFZ7oyhI6Ujo2akioMf7f+I+oJ+bCoosSkCIyRyYEGs5F5YxG tAYm2gxjO9pU3/c97nxMCKfKCcq/dlFWyM78y7ttTZmvwMPvlqxdbXBlVL2XoJ1AXpU2 iaqOPEEzQV2xM/7uu5+WdiP6eXLsuT0RplQ9hjP/ELxzbfRjT06mxcXTrliMMJOprdFD bTLnAhM65JRxow6RyGeE/3u8stOFGmG6PdbvstbwbNqIQHHuG+0BW9tc8pJ21nSYeGRo Hxjw== X-Gm-Message-State: ALoCoQkz3A0BITfqTYsPse9Dx7P9FpdihPHnLvuCqRjijEwjnTRpXZ53r7hGtn+i782obI6VZovH MIME-Version: 1.0 X-Received: by 10.58.188.52 with SMTP id fx20mr908145vec.28.1395667870317; Mon, 24 Mar 2014 06:31:10 -0700 (PDT) Received: by 10.220.209.135 with HTTP; Mon, 24 Mar 2014 06:31:10 -0700 (PDT) In-Reply-To: <1395494401.81853.34.camel@revolution.hippie.lan> References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> <1395494401.81853.34.camel@revolution.hippie.lan> Date: Mon, 24 Mar 2014 14:31:10 +0100 Message-ID: Subject: Re: arm SMP on Cortex-A15 From: Wojciech Macek To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 13:38:09 -0000 Without the unconditional invalidation, the panic shows up just at the beginning, after rootfs is mounted and init scripts are running. When a userspace process is exitting, its memory resources are freed - this is the moment pmap_remove_pages fails due to tharanslation fault. It is the "typical" crash I observed when TLB-cache holds an old entry. Below there is a backtrace, but I doubt if it can be helpful. Regarding old pte/tlb, the TLB cache contains entry from old process context, when in-memory-PTE value is already correct - at least this was the scenario when I debugged it last year. So, invalidating after *pte=0 is definitely not our case. The issue shows up only on a15, where the tlb-prefetcher can cache pte entries anytime. I believe I don't have r263251 integrated. I'll give it a try - typically, the tlb-caused crash appears only on pages containing shared libraries code (with executable attr), so there is a chance Olivier's fix help. The fault: vm_fault(0xc5b894f0, 0, 2, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (P)' trapframe: 0xef2cca40 FSR=00000817, FAR=00000030, spsr=60000013 r0 =00000000, r1 =c320a048, r2 =00000000, r3 =c3208074 r4 =c5b7cd08, r5 =c5b7cd04, r6 =c5b05800, r7 =c5b895ac r8 =c320a044, r9 =fffffffe, r10=c5b895ac, r11=ef2ccae0 r12=00000000, ssp=ef2cca90, slr=c0604148, pc =c0628a60 [ thread pid 83 tid 100050 ] Stopped at pmap_remove_pages+0x270: streq r3, [r0, #0x030] db> bt Tracing pid 83 tid 100050 td 0xc5bc4320 db_trace_self() at db_trace_self pc = 0xc061f62c lr = 0xc024ddbc (db_hex2dec+0x498) sp = 0xef2cc738 fp = 0xef2cc750 r10 = 0xc0708270 db_hex2dec() at db_hex2dec+0x498 pc = 0xc024ddbc lr = 0xc024d76c (db_command_loop+0x2f0) sp = 0xef2cc758 fp = 0xef2cc7f8 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0695cf1 db_command_loop() at db_command_loop+0x2f0 pc = 0xc024d76c lr = 0xc024d4dc (db_command_loop+0x60) sp = 0xef2cc800 fp = 0xef2cc810 r4 = 0xc0666f88 r5 = 0xc067b997 r6 = 0xc0752954 r7 = 0xc0748f80 r8 = 0xef2cca40 r9 = 0xc07084e0 r10 = 0xc0748f84 db_command_loop() at db_command_loop+0x60 pc = 0xc024d4dc lr = 0xc024ffb8 (X_db_symbol_values+0x254) sp = 0xef2cc818 fp = 0xef2cc938 r4 = 0x00000000 r5 = 0xef2cc820 r6 = 0xc0748fb0 X_db_symbol_values() at X_db_symbol_values+0x254 pc = 0xc024ffb8 lr = 0xc0430554 (kdb_trap+0x164) sp = 0xef2cc940 fp = 0xef2cc968 r4 = 0x00000000 r5 = 0x00000817 r6 = 0xc0748fb0 r7 = 0xc0748f80 kdb_trap() at kdb_trap+0x164 pc = 0xc0430554 lr = 0xc0632ef0 (data_abort_handler+0x7dc) sp = 0xef2cc970 fp = 0xef2cc988 r4 = 0xef2cca40 r5 = 0x600000d3 r6 = 0x00000030 r7 = 0x00000817 r8 = 0xc5b894f0 r9 = 0x00000001 r10 = 0xef2cca40 data_abort_handler() at data_abort_handler+0x7dc pc = 0xc0632ef0 lr = 0xc0632cc0 (data_abort_handler+0x5ac) sp = 0xef2cc990 fp = 0xef2cca38 r4 = 0x00000817 r5 = 0xc5bc4320 r6 = 0xc5a47a0c r7 = 0x00000004 data_abort_handler() at data_abort_handler+0x5ac pc = 0xc0632cc0 lr = 0xc0621214 (exception_exit) sp = 0xef2cca40 fp = 0xef2ccae0 r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 r6 = 0xc5b05800 r7 = 0xc5b895ac r8 = 0xc320a044 r9 = 0xfffffffe r10 = 0xc5b895ac exception_exit() at exception_exit pc = 0xc0621214 lr = 0xc0604148 (PHYS_TO_VM_PAGE+0x48) sp = 0xef2cca94 fp = 0xef2ccae0 r0 = 0x00000000 r1 = 0xc320a048 r2 = 0x00000000 r3 = 0xc3208074 r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 r6 = 0xc5b05800 r7 = 0xc5b895ac r8 = 0xc320a044 r9 = 0xfffffffe r10 = 0xc5b895ac r12 = 0x00000000 pmap_remove_pages() at pmap_remove_pages+0x270 pc = 0xc0628a60 lr = 0xc05f2d08 (vmspace_exit+0xd8) sp = 0xef2ccae8 fp = 0xef2ccb10 r4 = 0xc5b895a8 r5 = 0xc5bc4320 r6 = 0x00000001 r7 = 0xc5a47960 r8 = 0xc5b895ac r9 = 0xc5b894f0 r10 = 0xc0753be0 vmspace_exit() at vmspace_exit+0xd8 pc = 0xc05f2d08 lr = 0xc03a7348 (exit1+0x930) sp = 0xef2ccb18 fp = 0xef2ccb70 r4 = 0xc5a479fc r5 = 0x00000004 r6 = 0xc583861c r7 = 0x00000001 r8 = 0xc5a47960 r9 = 0xc5bc4320 r10 = 0xc5a47a0c exit1() at exit1+0x930 pc = 0xc03a7348 lr = 0xc03f1604 (sigexit+0x8c4) sp = 0xef2ccb78 fp = 0xef2ccd68 r4 = 0x00000002 r5 = 0xc5bc4320 r6 = 0xc5a47960 r7 = 0xc5a47a0c r8 = 0xc5bc4320 r9 = 0xc5b7a000 r10 = 0x00000002 sigexit() at sigexit+0x8c4 pc = 0xc03f1604 lr = 0xc03f23a0 (postsig+0x39c) sp = 0xef2ccd70 fp = 0xef2cce18 r4 = 0x00000001 r5 = 0xc5bc4320 r6 = 0xc5a47960 r7 = 0xc5b7aab8 r8 = 0xc5a47a0c r9 = 0xc5b7a000 r10 = 0x00000002 postsig() at postsig+0x39c pc = 0xc03f23a0 lr = 0xc044388c (ast+0x4f4) sp = 0xef2cce20 fp = 0xef2cce58 r4 = 0x00000001 r5 = 0xc5bc4320 r6 = 0xc5a47960 r7 = 0xc5a47a0c r8 = 0xc5a47a0c r9 = 0x01020804 r10 = 0x00000ab8 ast() at ast+0x4f4 pc = 0xc044388c lr = 0xc0621080 (swi_entry+0x6c) sp = 0xef2cce60 fp = 0xbfffe438 r4 = 0x40000013 r5 = 0xc5bc4320 r6 = 0x00000001 r7 = 0x00000154 r8 = 0x20037008 r9 = 0xbfffee5c r10 = 0xbfffea10 swi_entry() at swi_entry+0x6c pc = 0xc0621080 lr = 0xc0621080 (swi_entry+0x6c) sp = 0xef2cce60 fp = 0xbfffe438 Unable to unwind further db> 2014-03-22 14:20 GMT+01:00 Ian Lepore : > On Fri, 2014-03-21 at 07:20 +0100, Wojciech Macek wrote: > > No, changing flushD to flushID did not make any difference, but I think > it > > should be there - D-only flushing might not be sufficient. > > > > Olivier reminded me right after I posted that: last week I made a change > to cpufunc.c that makes flushD and flushID the same. So of course it > made no difference. :) It really should be flushID though, in case > that ever changes. > > You didn't say whether you have that change, which was r263251. > > > Currently, I'm running pmap_kernel_internal attached below. It is doing > > unconditional flushID at the end, just like the old comment was saying :) > > SMP seems to be stable. > > > > That seems to say that somehow there is a valid TLB entry even though > the old pte for that entry is zero. That means there's a problem > somewhere else in the code, but I don't see it. It looks to me like we > do a TLB flush everywhere that we zero out a pte. > > You said without the unconditional flush it panics at startup. Where in > startup? Early, or after init is launched or what? Where does the > panic backtrace to? > > If we've got some other pte/tlb maintenance problem, I'd hate to hide it > with this unconditional flush and have it appear as some other problem > later that will be even harder to track down. > > -- Ian > > > From owner-freebsd-arm@FreeBSD.ORG Tue Mar 25 10:14:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9F58576 for ; Tue, 25 Mar 2014 10:14:48 +0000 (UTC) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E6A6691 for ; Tue, 25 Mar 2014 10:14:48 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id lc6so259760vcb.35 for ; Tue, 25 Mar 2014 03:14:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=H8TL4/1jU6CQejCVkDj3Dzx2aSXRI2nzzHjxygxsPMI=; b=BTsQr0VVj9kS/faQt0DCvNLzg4pJXveduDHABsy7DlzV9jOqw1c/u7zBu+EmQXzP3K mL/IFtu/g5esm1G3Z9UNkbjxp3Rc3b1S17ZDnVffdZJ2lW71RGIF4tBPbXS4SjfpHwVp b8/JsOcaJpRjt/SJsL4u21qzh7/2WYVuou9SYbqQCjYyGKv3uhIZhokNRcFpu6gvKUq4 to+KeJ5HaltS8WQ0Ni+yAvxcvhbYfCoJTRNvo4tB6Jf62iVi0X1jLrOOf3J57nSpOKZB wDPj0G5zCCdGDMXrbnzZm2mBfMBSTNEPAGDc9gHL3kbfX3UPSqjlECGUS7kB6/c9RQiV z/Og== X-Gm-Message-State: ALoCoQkKF8Z4kcOAWu9PV2+41uRGvphkM1IWCDuDOUpar4k39oOzrDUi9exrC1kIGRuZRtRvSVLE MIME-Version: 1.0 X-Received: by 10.52.242.167 with SMTP id wr7mr276381vdc.32.1395742487204; Tue, 25 Mar 2014 03:14:47 -0700 (PDT) Received: by 10.220.209.135 with HTTP; Tue, 25 Mar 2014 03:14:47 -0700 (PDT) In-Reply-To: References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> <1395494401.81853.34.camel@revolution.hippie.lan> Date: Tue, 25 Mar 2014 11:14:47 +0100 Message-ID: Subject: Re: arm SMP on Cortex-A15 From: Wojciech Macek To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 10:14:48 -0000 Hi Ian, The r263251 fix helped, thanks! So now, if you don';t have any objections, I will clean up a little the cpufunc.S & pmap-v6 changes and make them ready for submitting. Regards, Wojtek 2014-03-24 14:31 GMT+01:00 Wojciech Macek : > Without the unconditional invalidation, the panic shows up just at the > beginning, after rootfs is mounted and init scripts are running. When a > userspace process is exitting, its memory resources are freed - this is the > moment pmap_remove_pages fails due to tharanslation fault. It is the > "typical" crash I observed when TLB-cache holds an old entry. Below there > is a backtrace, but I doubt if it can be helpful. > > Regarding old pte/tlb, the TLB cache contains entry from old process > context, when in-memory-PTE value is already correct - at least this was > the scenario when I debugged it last year. So, invalidating after *pte=0 is > definitely not our case. The issue shows up only on a15, where the > tlb-prefetcher can cache pte entries anytime. > > I believe I don't have r263251 integrated. I'll give it a try - typically, > the tlb-caused crash appears only on pages containing shared libraries code > (with executable attr), so there is a chance Olivier's fix help. > > > The fault: > > vm_fault(0xc5b894f0, 0, 2, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (P)' > trapframe: 0xef2cca40 > FSR=00000817, FAR=00000030, spsr=60000013 > r0 =00000000, r1 =c320a048, r2 =00000000, r3 =c3208074 > r4 =c5b7cd08, r5 =c5b7cd04, r6 =c5b05800, r7 =c5b895ac > r8 =c320a044, r9 =fffffffe, r10=c5b895ac, r11=ef2ccae0 > r12=00000000, ssp=ef2cca90, slr=c0604148, pc =c0628a60 > > [ thread pid 83 tid 100050 ] > Stopped at pmap_remove_pages+0x270: streq r3, [r0, #0x030] > db> bt > Tracing pid 83 tid 100050 td 0xc5bc4320 > db_trace_self() at db_trace_self > pc = 0xc061f62c lr = 0xc024ddbc (db_hex2dec+0x498) > sp = 0xef2cc738 fp = 0xef2cc750 > r10 = 0xc0708270 > db_hex2dec() at db_hex2dec+0x498 > pc = 0xc024ddbc lr = 0xc024d76c (db_command_loop+0x2f0) > sp = 0xef2cc758 fp = 0xef2cc7f8 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc0695cf1 > db_command_loop() at db_command_loop+0x2f0 > pc = 0xc024d76c lr = 0xc024d4dc (db_command_loop+0x60) > sp = 0xef2cc800 fp = 0xef2cc810 > r4 = 0xc0666f88 r5 = 0xc067b997 > r6 = 0xc0752954 r7 = 0xc0748f80 > r8 = 0xef2cca40 r9 = 0xc07084e0 > r10 = 0xc0748f84 > db_command_loop() at db_command_loop+0x60 > pc = 0xc024d4dc lr = 0xc024ffb8 (X_db_symbol_values+0x254) > sp = 0xef2cc818 fp = 0xef2cc938 > r4 = 0x00000000 r5 = 0xef2cc820 > r6 = 0xc0748fb0 > X_db_symbol_values() at X_db_symbol_values+0x254 > pc = 0xc024ffb8 lr = 0xc0430554 (kdb_trap+0x164) > sp = 0xef2cc940 fp = 0xef2cc968 > r4 = 0x00000000 r5 = 0x00000817 > r6 = 0xc0748fb0 r7 = 0xc0748f80 > kdb_trap() at kdb_trap+0x164 > pc = 0xc0430554 lr = 0xc0632ef0 (data_abort_handler+0x7dc) > sp = 0xef2cc970 fp = 0xef2cc988 > r4 = 0xef2cca40 r5 = 0x600000d3 > r6 = 0x00000030 r7 = 0x00000817 > r8 = 0xc5b894f0 r9 = 0x00000001 > r10 = 0xef2cca40 > data_abort_handler() at data_abort_handler+0x7dc > pc = 0xc0632ef0 lr = 0xc0632cc0 (data_abort_handler+0x5ac) > sp = 0xef2cc990 fp = 0xef2cca38 > r4 = 0x00000817 r5 = 0xc5bc4320 > r6 = 0xc5a47a0c r7 = 0x00000004 > data_abort_handler() at data_abort_handler+0x5ac > pc = 0xc0632cc0 lr = 0xc0621214 (exception_exit) > sp = 0xef2cca40 fp = 0xef2ccae0 > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > r6 = 0xc5b05800 r7 = 0xc5b895ac > r8 = 0xc320a044 r9 = 0xfffffffe > r10 = 0xc5b895ac > exception_exit() at exception_exit > pc = 0xc0621214 lr = 0xc0604148 (PHYS_TO_VM_PAGE+0x48) > sp = 0xef2cca94 fp = 0xef2ccae0 > r0 = 0x00000000 r1 = 0xc320a048 > r2 = 0x00000000 r3 = 0xc3208074 > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > r6 = 0xc5b05800 r7 = 0xc5b895ac > r8 = 0xc320a044 r9 = 0xfffffffe > r10 = 0xc5b895ac r12 = 0x00000000 > pmap_remove_pages() at pmap_remove_pages+0x270 > pc = 0xc0628a60 lr = 0xc05f2d08 (vmspace_exit+0xd8) > sp = 0xef2ccae8 fp = 0xef2ccb10 > r4 = 0xc5b895a8 r5 = 0xc5bc4320 > r6 = 0x00000001 r7 = 0xc5a47960 > r8 = 0xc5b895ac r9 = 0xc5b894f0 > r10 = 0xc0753be0 > vmspace_exit() at vmspace_exit+0xd8 > pc = 0xc05f2d08 lr = 0xc03a7348 (exit1+0x930) > sp = 0xef2ccb18 fp = 0xef2ccb70 > r4 = 0xc5a479fc r5 = 0x00000004 > r6 = 0xc583861c r7 = 0x00000001 > r8 = 0xc5a47960 r9 = 0xc5bc4320 > r10 = 0xc5a47a0c > exit1() at exit1+0x930 > pc = 0xc03a7348 lr = 0xc03f1604 (sigexit+0x8c4) > sp = 0xef2ccb78 fp = 0xef2ccd68 > r4 = 0x00000002 r5 = 0xc5bc4320 > r6 = 0xc5a47960 r7 = 0xc5a47a0c > r8 = 0xc5bc4320 r9 = 0xc5b7a000 > r10 = 0x00000002 > sigexit() at sigexit+0x8c4 > pc = 0xc03f1604 lr = 0xc03f23a0 (postsig+0x39c) > sp = 0xef2ccd70 fp = 0xef2cce18 > r4 = 0x00000001 r5 = 0xc5bc4320 > r6 = 0xc5a47960 r7 = 0xc5b7aab8 > r8 = 0xc5a47a0c r9 = 0xc5b7a000 > r10 = 0x00000002 > postsig() at postsig+0x39c > pc = 0xc03f23a0 lr = 0xc044388c (ast+0x4f4) > sp = 0xef2cce20 fp = 0xef2cce58 > r4 = 0x00000001 r5 = 0xc5bc4320 > r6 = 0xc5a47960 r7 = 0xc5a47a0c > r8 = 0xc5a47a0c r9 = 0x01020804 > r10 = 0x00000ab8 > ast() at ast+0x4f4 > pc = 0xc044388c lr = 0xc0621080 (swi_entry+0x6c) > sp = 0xef2cce60 fp = 0xbfffe438 > r4 = 0x40000013 r5 = 0xc5bc4320 > r6 = 0x00000001 r7 = 0x00000154 > r8 = 0x20037008 r9 = 0xbfffee5c > r10 = 0xbfffea10 > swi_entry() at swi_entry+0x6c > pc = 0xc0621080 lr = 0xc0621080 (swi_entry+0x6c) > sp = 0xef2cce60 fp = 0xbfffe438 > Unable to unwind further > db> > > > > 2014-03-22 14:20 GMT+01:00 Ian Lepore : > > On Fri, 2014-03-21 at 07:20 +0100, Wojciech Macek wrote: >> > No, changing flushD to flushID did not make any difference, but I think >> it >> > should be there - D-only flushing might not be sufficient. >> > >> >> Olivier reminded me right after I posted that: last week I made a change >> to cpufunc.c that makes flushD and flushID the same. So of course it >> made no difference. :) It really should be flushID though, in case >> that ever changes. >> >> You didn't say whether you have that change, which was r263251. >> >> > Currently, I'm running pmap_kernel_internal attached below. It is doing >> > unconditional flushID at the end, just like the old comment was saying >> :) >> > SMP seems to be stable. >> > >> >> That seems to say that somehow there is a valid TLB entry even though >> the old pte for that entry is zero. That means there's a problem >> somewhere else in the code, but I don't see it. It looks to me like we >> do a TLB flush everywhere that we zero out a pte. >> >> You said without the unconditional flush it panics at startup. Where in >> startup? Early, or after init is launched or what? Where does the >> panic backtrace to? >> >> If we've got some other pte/tlb maintenance problem, I'd hate to hide it >> with this unconditional flush and have it appear as some other problem >> later that will be even harder to track down. >> >> -- Ian >> >> >> > From owner-freebsd-arm@FreeBSD.ORG Tue Mar 25 12:30:38 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AD1F7F4 for ; Tue, 25 Mar 2014 12:30:38 +0000 (UTC) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 10ADA3BB for ; Tue, 25 Mar 2014 12:30:37 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1WSQV2-006haE-3I; Tue, 25 Mar 2014 13:30:36 +0100 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Ralf Wenk To: arm@freebsd.org Subject: Experimental TARGET_ARCH armv6hf crashes on my RPi afer some time Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Mar 2014 13:30:35 +0100 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 12:30:38 -0000 Hi, I tried the new experimental TARGET_ARCH armv6hf on my raspberry pi. World and kernel are build with make -j 8 -C =24SRCROOT MALLOC_PRODUCTION=3Dyes buildworld make -j 8 -C =24SRCROOT KERNCONF=3D=24KERNCONF WITH_FDT=3Dyes buildkern= el and installed over a normal armv6 kernel and world. The release used was FreeBSD 11.0-CURRENT =230 r263667M. Within an hour since boot the system panics with an undefined floating po= int instruction in supervisor mode. This happened during a shutdown - but not on every shutdown - and during normal system activity. On every shutdown there is a sleep: nanosleep: Invalid argument message printed in the console. I do not file a bug report because of the experimental state of armv6hf. Gathered information from two panics: panic: undefined floating point instruction in supervisor mode KDB: enter: panic =5B thread pid 509 tid 100056 =5D Stopped at =24d: ldrb r15, =5Br15, r15, ror r15=5D=21 db> bt Tracing pid 509 tid 100056 td 0xc2675320 db_trace_self() at db_trace_self pc =3D 0xc04a38a0 lr =3D 0xc0136184 (db_stack_trace+0xf4) sp =3D 0xdd794668 fp =3D 0xdd794680 r10 =3D 0xc05c29f0 db_stack_trace() at db_stack_trace+0xf4 pc =3D 0xc0136184 lr =3D 0xc0135b3c (db_command+0x270) sp =3D 0xdd794688 fp =3D 0xdd794728 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000000 db_command() at db_command+0x270 pc =3D 0xc0135b3c lr =3D 0xc01358a0 (db_command_loop+0x60) sp =3D 0xdd794730 fp =3D 0xdd794740 r4 =3D 0xc04e1377 r5 =3D 0xc04f5222 r6 =3D 0xc05c29dc r7 =3D 0xdd794928 r8 =3D 0xc05b92f0 r9 =3D 0xc05b92f4 r10 =3D 0xc0577c30 db_command_loop() at db_command_loop+0x60 pc =3D 0xc01358a0 lr =3D 0xc013831c (db_trap+0xd8) sp =3D 0xdd794748 fp =3D 0xdd794868 r4 =3D 0x00000000 r5 =3D 0xc05c29e8 r6 =3D 0xc05b9320 db_trap() at db_trap+0xd8 pc =3D 0xc013831c lr =3D 0xc02c2274 (kdb_trap+0xcc) sp =3D 0xdd794870 fp =3D 0xdd794890 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0xc05b9320 r7 =3D 0xdd794928 kdb_trap() at kdb_trap+0xcc pc =3D 0xc02c2274 lr =3D 0xc04b8eb0 (undefinedinstruction+0x2f8= ) sp =3D 0xdd794898 fp =3D 0xdd794920 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xc04b8b08 r7 =3D 0xe7ffffff r8 =3D 0xc2675320 r9 =3D 0xc02c1b34 r10 =3D 0xdd794928 undefinedinstruction() at undefinedinstruction+0x2f8 pc =3D 0xc04b8eb0 lr =3D 0xc04a5410 (exception_exit) sp =3D 0xdd794928 fp =3D 0xdd794980 r4 =3D 0xc04f527c r5 =3D 0xc050fe47 r6 =3D 0xc05c4460 r7 =3D 0xc05ab848 r8 =3D 0xdd7949b4 r9 =3D 0xc2675320 r10 =3D 0xc05ab7d0 exception_exit() at exception_exit pc =3D 0xc04a5410 lr =3D 0xc02c1b28 (kdb_enter+0x40) sp =3D 0xdd794978 fp =3D 0xdd794980 r0 =3D 0xc05b9304 r1 =3D 0x00000000 r2 =3D 0x00000001 r3 =3D 0x00000001 r4 =3D 0xc04f527c r5 =3D 0xc050fe47 r6 =3D 0xc05c4460 r7 =3D 0xc05ab848 r8 =3D 0xdd7949b4 r9 =3D 0xc2675320 r10 =3D 0xc05ab7d0 r12 =3D 0x00000000 =24a() at =24a pc =3D 0xc02c1b38 lr =3D 0xc0285b54 (panic+0xc4) sp =3D 0xdd794988 fp =3D 0xdd7949a8 r4 =3D 0x00000100 panic() at panic+0xc4 pc =3D 0xc0285b54 lr =3D 0xc04b991c (=24d) sp =3D 0xdd7949c0 fp =3D 0xdd7949c0 r4 =3D 0x00000000 r5 =3D 0xc05c2890 r6 =3D 0xc04b985c r7 =3D 0xeca00b20 r8 =3D 0xc2675320 r9 =3D 0xc04b9940 r10 =3D 0xdd794a58 =24d() at =24d pc =3D 0xc04b991c lr =3D 0xc04b8cac (undefinedinstruction+0xf4)= sp =3D 0xdd7949c8 fp =3D 0xdd794a50 undefinedinstruction() at undefinedinstruction+0xf4 pc =3D 0xc04b8cac lr =3D 0xc04a5410 (exception_exit) sp =3D 0xdd794a58 fp =3D 0xdd794ad0 r4 =3D 0xc2884640 r5 =3D 0xc2675320 r6 =3D 0xc05c4640 r7 =3D 0xc05c7ec0 r8 =3D 0x8791dcd3 r9 =3D 0xdd758eb8 r10 =3D 0xc059e9e0 exception_exit() at exception_exit pc =3D 0xc04a5410 lr =3D 0xc04b6c80 (cpu_switch+0x60) sp =3D 0xdd794aa8 fp =3D 0xdd794ad0 r0 =3D 0xdd794ef0 r1 =3D 0x00000001 r2 =3D 0xdd794eb8 r3 =3D 0x00000000 r4 =3D 0xc2884640 r5 =3D 0xc2675320 r6 =3D 0xc05c4640 r7 =3D 0xc05c7ec0 r8 =3D 0x8791dcd3 r9 =3D 0xdd758eb8 r10 =3D 0xc059e9e0 r12 =3D 0xc0000780 vfp_store() at vfp_store+0x14 pc =3D 0xc04b9940 lr =3D 0xc04b6c80 (cpu_switch+0x60) sp =3D 0xdd794aa8 fp =3D 0xdd794ad0 Unwind failure (no registers changed) db>=20 db> show proc 509 Process 509 (devd) at 0xc25c4640: state: NORMAL uid: 0 gids: 0 parent: pid 1 at 0xc2431640 ABI: FreeBSD ELF32 arguments: /sbin/devd threads: 1 100056 Run CPU 255 devd db> db> show thread 100056 Thread 100056 at 0xc2675320: proc (pid 509): 0xc25c4640 name: devd stack: 0xdd757000-0xdd758fff flags: 0x1000004 pflags: 0 state: RUNNING (CPU 255) priority: 140 container lock: sched lock (0xc05c4640) db>=20 system shutdown time has arrived sleep: nanosleep: Invalid argument panic: undefined floating point instruction in supervisor mode KDB: enter: panic =5B thread pid 11 tid 100005 =5D Stopped at =24d: ldrb r15, =5Br15, r15, ror r15=5D=21 db> bt =20 Tracing pid 11 tid 100005 td 0xc2433960 db_trace_self() at db_trace_self pc =3D 0xc04a38a0 lr =3D 0xc0136184 (db_stack_trace+0xf4) sp =3D 0xdd749360 fp =3D 0xdd749378 r10 =3D 0xc05c29f0 db_stack_trace() at db_stack_trace+0xf4 pc =3D 0xc0136184 lr =3D 0xc0135b3c (db_command+0x270) sp =3D 0xdd749380 fp =3D 0xdd749420 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000000 db_command() at db_command+0x270 pc =3D 0xc0135b3c lr =3D 0xc01358a0 (db_command_loop+0x60) sp =3D 0xdd749428 fp =3D 0xdd749438 r4 =3D 0xc04e1377 r5 =3D 0xc04f5222 r6 =3D 0xc05c29dc r7 =3D 0xdd749620 r8 =3D 0xc05b92f0 r9 =3D 0xc05b92f4 r10 =3D 0xc0577c30 db_command_loop() at db_command_loop+0x60 pc =3D 0xc01358a0 lr =3D 0xc013831c (db_trap+0xd8) sp =3D 0xdd749440 fp =3D 0xdd749560 r4 =3D 0x00000000 r5 =3D 0xc05c29e8 r6 =3D 0xc05b9320 db_trap() at db_trap+0xd8 pc =3D 0xc013831c lr =3D 0xc02c2274 (kdb_trap+0xcc) sp =3D 0xdd749568 fp =3D 0xdd749588 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0xc05b9320 r7 =3D 0xdd749620 kdb_trap() at kdb_trap+0xcc pc =3D 0xc02c2274 lr =3D 0xc04b8eb0 (undefinedinstruction+0x2f8= ) sp =3D 0xdd749590 fp =3D 0xdd749618 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xc04b8b08 r7 =3D 0xe7ffffff r8 =3D 0xc2433960 r9 =3D 0xc02c1b34 r10 =3D 0xdd749620 undefinedinstruction() at undefinedinstruction+0x2f8 pc =3D 0xc04b8eb0 lr =3D 0xc04a5410 (exception_exit) sp =3D 0xdd749620 fp =3D 0xdd749678 r4 =3D 0xc04f527c r5 =3D 0xc050fe47 r6 =3D 0xc05c4460 r7 =3D 0xc05ab848 r8 =3D 0xdd7496ac r9 =3D 0xc2433960 r10 =3D 0xc05ab7d0 exception_exit() at exception_exit pc =3D 0xc04a5410 lr =3D 0xc02c1b28 (kdb_enter+0x40) sp =3D 0xdd749670 fp =3D 0xdd749678 r0 =3D 0xc05b9304 r1 =3D 0x00000000 r2 =3D 0x00000001 r3 =3D 0x00000001 r4 =3D 0xc04f527c r5 =3D 0xc050fe47 r6 =3D 0xc05c4460 r7 =3D 0xc05ab848 r8 =3D 0xdd7496ac r9 =3D 0xc2433960 r10 =3D 0xc05ab7d0 r12 =3D 0x00000000 =24a() at =24a pc =3D 0xc02c1b38 lr =3D 0xc0285b54 (panic+0xc4) sp =3D 0xdd749680 fp =3D 0xdd7496a0 r4 =3D 0x00000100 panic() at panic+0xc4 pc =3D 0xc0285b54 lr =3D 0xc04b991c (=24d) sp =3D 0xdd7496b8 fp =3D 0xdd7496b8 r4 =3D 0x00000000 r5 =3D 0xc05c2890 r6 =3D 0xc04b985c r7 =3D 0xeca00b20 r8 =3D 0xc2433960 r9 =3D 0xc04b9940 r10 =3D 0xdd749750 =24d() at =24d pc =3D 0xc04b991c lr =3D 0xc04b8cac (undefinedinstruction+0xf4)= sp =3D 0xdd7496c0 fp =3D 0xdd749748 undefinedinstruction() at undefinedinstruction+0xf4 pc =3D 0xc04b8cac lr =3D 0xc04a5410 (exception_exit) sp =3D 0xdd749750 fp =3D 0xdd7497c8 r4 =3D 0xc25a8000 r5 =3D 0xc2433960 r6 =3D 0xc05c4640 r7 =3D 0xc05c7ec0 r8 =3D 0x5aee06ac r9 =3D 0xdb3abeb8 r10 =3D 0xc059e9e0 exception_exit() at exception_exit pc =3D 0xc04a5410 lr =3D 0xc04b6c80 (cpu_switch+0x60) sp =3D 0xdd7497a0 fp =3D 0xdd7497c8 r0 =3D 0xdd749ef0 r1 =3D 0x00000001 r2 =3D 0xdd749eb8 r3 =3D 0x00000000 r4 =3D 0xc25a8000 r5 =3D 0xc2433960 r6 =3D 0xc05c4640 r7 =3D 0xc05c7ec0 r8 =3D 0x5aee06ac r9 =3D 0xdb3abeb8 r10 =3D 0xc059e9e0 r12 =3D 0xc0000708 vfp_store() at vfp_store+0x14 pc =3D 0xc04b9940 lr =3D 0xc04b6c80 (cpu_switch+0x60) sp =3D 0xdd7497a0 fp =3D 0xdd7497c8 Unwind failure (no registers changed) db> show proc 11 Process 11 (intr) at 0xc2431000: state: NORMAL uid: 0 gids: 0 parent: pid 0 at 0xc05c3658 ABI: null threads: 24 100034 I =5Bintr17: dwcotg0= =5D 100033 I =5Bswi0: uart=5D 100032 I =5Bintr70: sdhci_bcm= 0=5D 100031 I =5Bintr1: mbox0=5D 100030 I =5Bintr35: bcm_dma0= =5D 100029 I =5Bintr34: bcm_dma0= =5D 100028 I =5Bintr33: bcm_dma0= =5D 100027 I =5Bintr32: bcm_dma0= =5D 100026 I =5Bintr31: bcm_dma0= =5D 100025 I =5Bintr30: bcm_dma0= =5D 100024 I =5Bintr29: bcm_dma0= =5D 100023 I =5Bintr28: bcm_dma0= =5D 100022 I =5Bintr27: bcm_dma0= =5D 100021 I =5Bintr26: bcm_dma0= =5D 100020 I =5Bintr25: bcm_dma0= =5D 100019 I =5Bintr24: bcm_dma0= =5D 100018 I =5Bintr62: spi0=5D 100017 I =5Bintr61: iichb0+= =5D 100015 I =5Bswi6: Giant taskq= =5D 100014 I =5Bswi6: task queue= =5D 100010 I =5Bswi5: fast taskq= =5D 100005 Run CPU 255 =5Bswi4: clock (0)= =5D 100004 I =5Bswi3: vm=5D 100003 I =5Bswi1: netisr 0=5D= db> sh thread 100005 Thread 100005 at 0xc2433960: proc (pid 11): 0xc2431000 name: swi4: clock (0) stack: 0xdb3aa000-0xdb3abfff flags: 0x1000004 pflags: 0x200400 state: RUNNING (CPU 255) priority: 40 container lock: sched lock (0xc05c4640) db>=20 Ralf From owner-freebsd-arm@FreeBSD.ORG Tue Mar 25 13:36:00 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEFD7240 for ; Tue, 25 Mar 2014 13:36:00 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F59DC0D for ; Tue, 25 Mar 2014 13:36:00 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WSRWJ-000GSP-3L; Tue, 25 Mar 2014 13:35:59 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2PDZuRh076214; Tue, 25 Mar 2014 07:35:56 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX180r7RLw+YvBRbA/RquzadI Subject: Re: arm SMP on Cortex-A15 From: Ian Lepore To: Wojciech Macek In-Reply-To: References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> <1395494401.81853.34.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 2014 07:35:55 -0600 Message-ID: <1395754555.81853.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 13:36:00 -0000 Good, that means we can stop searching for the missing tlb flush when a pte is invalidated. :) You guys can commit whenever you're ready (or I can do it if you'd like). -- Ian On Tue, 2014-03-25 at 11:14 +0100, Wojciech Macek wrote: > Hi Ian, > > The r263251 fix helped, thanks! > So now, if you don';t have any objections, I will clean up a little the > cpufunc.S & pmap-v6 changes and make them ready for submitting. > > Regards, > Wojtek > > > 2014-03-24 14:31 GMT+01:00 Wojciech Macek : > > > Without the unconditional invalidation, the panic shows up just at the > > beginning, after rootfs is mounted and init scripts are running. When a > > userspace process is exitting, its memory resources are freed - this is the > > moment pmap_remove_pages fails due to tharanslation fault. It is the > > "typical" crash I observed when TLB-cache holds an old entry. Below there > > is a backtrace, but I doubt if it can be helpful. > > > > Regarding old pte/tlb, the TLB cache contains entry from old process > > context, when in-memory-PTE value is already correct - at least this was > > the scenario when I debugged it last year. So, invalidating after *pte=0 is > > definitely not our case. The issue shows up only on a15, where the > > tlb-prefetcher can cache pte entries anytime. > > > > I believe I don't have r263251 integrated. I'll give it a try - typically, > > the tlb-caused crash appears only on pages containing shared libraries code > > (with executable attr), so there is a chance Olivier's fix help. > > > > > > The fault: > > > > vm_fault(0xc5b894f0, 0, 2, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (P)' > > trapframe: 0xef2cca40 > > FSR=00000817, FAR=00000030, spsr=60000013 > > r0 =00000000, r1 =c320a048, r2 =00000000, r3 =c3208074 > > r4 =c5b7cd08, r5 =c5b7cd04, r6 =c5b05800, r7 =c5b895ac > > r8 =c320a044, r9 =fffffffe, r10=c5b895ac, r11=ef2ccae0 > > r12=00000000, ssp=ef2cca90, slr=c0604148, pc =c0628a60 > > > > [ thread pid 83 tid 100050 ] > > Stopped at pmap_remove_pages+0x270: streq r3, [r0, #0x030] > > db> bt > > Tracing pid 83 tid 100050 td 0xc5bc4320 > > db_trace_self() at db_trace_self > > pc = 0xc061f62c lr = 0xc024ddbc (db_hex2dec+0x498) > > sp = 0xef2cc738 fp = 0xef2cc750 > > r10 = 0xc0708270 > > db_hex2dec() at db_hex2dec+0x498 > > pc = 0xc024ddbc lr = 0xc024d76c (db_command_loop+0x2f0) > > sp = 0xef2cc758 fp = 0xef2cc7f8 > > r4 = 0x00000000 r5 = 0x00000000 > > r6 = 0xc0695cf1 > > db_command_loop() at db_command_loop+0x2f0 > > pc = 0xc024d76c lr = 0xc024d4dc (db_command_loop+0x60) > > sp = 0xef2cc800 fp = 0xef2cc810 > > r4 = 0xc0666f88 r5 = 0xc067b997 > > r6 = 0xc0752954 r7 = 0xc0748f80 > > r8 = 0xef2cca40 r9 = 0xc07084e0 > > r10 = 0xc0748f84 > > db_command_loop() at db_command_loop+0x60 > > pc = 0xc024d4dc lr = 0xc024ffb8 (X_db_symbol_values+0x254) > > sp = 0xef2cc818 fp = 0xef2cc938 > > r4 = 0x00000000 r5 = 0xef2cc820 > > r6 = 0xc0748fb0 > > X_db_symbol_values() at X_db_symbol_values+0x254 > > pc = 0xc024ffb8 lr = 0xc0430554 (kdb_trap+0x164) > > sp = 0xef2cc940 fp = 0xef2cc968 > > r4 = 0x00000000 r5 = 0x00000817 > > r6 = 0xc0748fb0 r7 = 0xc0748f80 > > kdb_trap() at kdb_trap+0x164 > > pc = 0xc0430554 lr = 0xc0632ef0 (data_abort_handler+0x7dc) > > sp = 0xef2cc970 fp = 0xef2cc988 > > r4 = 0xef2cca40 r5 = 0x600000d3 > > r6 = 0x00000030 r7 = 0x00000817 > > r8 = 0xc5b894f0 r9 = 0x00000001 > > r10 = 0xef2cca40 > > data_abort_handler() at data_abort_handler+0x7dc > > pc = 0xc0632ef0 lr = 0xc0632cc0 (data_abort_handler+0x5ac) > > sp = 0xef2cc990 fp = 0xef2cca38 > > r4 = 0x00000817 r5 = 0xc5bc4320 > > r6 = 0xc5a47a0c r7 = 0x00000004 > > data_abort_handler() at data_abort_handler+0x5ac > > pc = 0xc0632cc0 lr = 0xc0621214 (exception_exit) > > sp = 0xef2cca40 fp = 0xef2ccae0 > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > > r6 = 0xc5b05800 r7 = 0xc5b895ac > > r8 = 0xc320a044 r9 = 0xfffffffe > > r10 = 0xc5b895ac > > exception_exit() at exception_exit > > pc = 0xc0621214 lr = 0xc0604148 (PHYS_TO_VM_PAGE+0x48) > > sp = 0xef2cca94 fp = 0xef2ccae0 > > r0 = 0x00000000 r1 = 0xc320a048 > > r2 = 0x00000000 r3 = 0xc3208074 > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > > r6 = 0xc5b05800 r7 = 0xc5b895ac > > r8 = 0xc320a044 r9 = 0xfffffffe > > r10 = 0xc5b895ac r12 = 0x00000000 > > pmap_remove_pages() at pmap_remove_pages+0x270 > > pc = 0xc0628a60 lr = 0xc05f2d08 (vmspace_exit+0xd8) > > sp = 0xef2ccae8 fp = 0xef2ccb10 > > r4 = 0xc5b895a8 r5 = 0xc5bc4320 > > r6 = 0x00000001 r7 = 0xc5a47960 > > r8 = 0xc5b895ac r9 = 0xc5b894f0 > > r10 = 0xc0753be0 > > vmspace_exit() at vmspace_exit+0xd8 > > pc = 0xc05f2d08 lr = 0xc03a7348 (exit1+0x930) > > sp = 0xef2ccb18 fp = 0xef2ccb70 > > r4 = 0xc5a479fc r5 = 0x00000004 > > r6 = 0xc583861c r7 = 0x00000001 > > r8 = 0xc5a47960 r9 = 0xc5bc4320 > > r10 = 0xc5a47a0c > > exit1() at exit1+0x930 > > pc = 0xc03a7348 lr = 0xc03f1604 (sigexit+0x8c4) > > sp = 0xef2ccb78 fp = 0xef2ccd68 > > r4 = 0x00000002 r5 = 0xc5bc4320 > > r6 = 0xc5a47960 r7 = 0xc5a47a0c > > r8 = 0xc5bc4320 r9 = 0xc5b7a000 > > r10 = 0x00000002 > > sigexit() at sigexit+0x8c4 > > pc = 0xc03f1604 lr = 0xc03f23a0 (postsig+0x39c) > > sp = 0xef2ccd70 fp = 0xef2cce18 > > r4 = 0x00000001 r5 = 0xc5bc4320 > > r6 = 0xc5a47960 r7 = 0xc5b7aab8 > > r8 = 0xc5a47a0c r9 = 0xc5b7a000 > > r10 = 0x00000002 > > postsig() at postsig+0x39c > > pc = 0xc03f23a0 lr = 0xc044388c (ast+0x4f4) > > sp = 0xef2cce20 fp = 0xef2cce58 > > r4 = 0x00000001 r5 = 0xc5bc4320 > > r6 = 0xc5a47960 r7 = 0xc5a47a0c > > r8 = 0xc5a47a0c r9 = 0x01020804 > > r10 = 0x00000ab8 > > ast() at ast+0x4f4 > > pc = 0xc044388c lr = 0xc0621080 (swi_entry+0x6c) > > sp = 0xef2cce60 fp = 0xbfffe438 > > r4 = 0x40000013 r5 = 0xc5bc4320 > > r6 = 0x00000001 r7 = 0x00000154 > > r8 = 0x20037008 r9 = 0xbfffee5c > > r10 = 0xbfffea10 > > swi_entry() at swi_entry+0x6c > > pc = 0xc0621080 lr = 0xc0621080 (swi_entry+0x6c) > > sp = 0xef2cce60 fp = 0xbfffe438 > > Unable to unwind further > > db> > > > > > > > > 2014-03-22 14:20 GMT+01:00 Ian Lepore : > > > > On Fri, 2014-03-21 at 07:20 +0100, Wojciech Macek wrote: > >> > No, changing flushD to flushID did not make any difference, but I think > >> it > >> > should be there - D-only flushing might not be sufficient. > >> > > >> > >> Olivier reminded me right after I posted that: last week I made a change > >> to cpufunc.c that makes flushD and flushID the same. So of course it > >> made no difference. :) It really should be flushID though, in case > >> that ever changes. > >> > >> You didn't say whether you have that change, which was r263251. > >> > >> > Currently, I'm running pmap_kernel_internal attached below. It is doing > >> > unconditional flushID at the end, just like the old comment was saying > >> :) > >> > SMP seems to be stable. > >> > > >> > >> That seems to say that somehow there is a valid TLB entry even though > >> the old pte for that entry is zero. That means there's a problem > >> somewhere else in the code, but I don't see it. It looks to me like we > >> do a TLB flush everywhere that we zero out a pte. > >> > >> You said without the unconditional flush it panics at startup. Where in > >> startup? Early, or after init is launched or what? Where does the > >> panic backtrace to? > >> > >> If we've got some other pte/tlb maintenance problem, I'd hate to hide it > >> with this unconditional flush and have it appear as some other problem > >> later that will be even harder to track down. > >> > >> -- Ian > >> > >> > >> > > From owner-freebsd-arm@FreeBSD.ORG Tue Mar 25 14:45:05 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F565DC7; Tue, 25 Mar 2014 14:45:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 06D9A3DA; Tue, 25 Mar 2014 14:45:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s2PEj3N9001236; Tue, 25 Mar 2014 10:45:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s2PEj3Io001230; Tue, 25 Mar 2014 14:45:03 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 25 Mar 2014 14:45:03 GMT Message-Id: <201403251445.s2PEj3Io001230@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:45:05 -0000 TB --- 2014-03-25 14:45:03 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-03-25 14:45:03 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-25 14:45:03 - starting HEAD tinderbox run for arm/arm TB --- 2014-03-25 14:45:03 - cleaning the object tree TB --- 2014-03-25 14:45:03 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-25 14:45:03 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-25 14:45:03 - ERROR: unable to stat source tree TB --- 2014-03-25 14:45:03 - 0.05 user 0.00 system 0.23 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Mar 25 14:55:02 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59590124; Tue, 25 Mar 2014 14:55:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 23525773; Tue, 25 Mar 2014 14:55:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s2PEt1Wo001366; Tue, 25 Mar 2014 10:55:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s2PEt1VA001364; Tue, 25 Mar 2014 14:55:01 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 25 Mar 2014 14:55:01 GMT Message-Id: <201403251455.s2PEt1VA001364@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:55:02 -0000 TB --- 2014-03-25 14:55:01 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-03-25 14:55:01 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-25 14:55:01 - starting HEAD tinderbox run for arm/arm TB --- 2014-03-25 14:55:01 - cleaning the object tree TB --- 2014-03-25 14:55:01 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-25 14:55:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-25 14:55:01 - ERROR: unable to stat source tree TB --- 2014-03-25 14:55:01 - 0.06 user 0.00 system 0.03 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Mar 25 15:05:02 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E9A42DB; Tue, 25 Mar 2014 15:05:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 264C78B3; Tue, 25 Mar 2014 15:05:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s2PF51AN001512; Tue, 25 Mar 2014 11:05:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s2PF51Q4001507; Tue, 25 Mar 2014 15:05:01 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 25 Mar 2014 15:05:01 GMT Message-Id: <201403251505.s2PF51Q4001507@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:05:02 -0000 TB --- 2014-03-25 15:05:01 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-03-25 15:05:01 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-25 15:05:01 - starting HEAD tinderbox run for arm/arm TB --- 2014-03-25 15:05:01 - cleaning the object tree TB --- 2014-03-25 15:05:01 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-25 15:05:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-25 15:05:01 - ERROR: unable to stat source tree TB --- 2014-03-25 15:05:01 - 0.05 user 0.01 system 0.03 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Mar 25 16:43:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E910539 for ; Tue, 25 Mar 2014 16:43:44 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E03353B2 for ; Tue, 25 Mar 2014 16:43:43 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n16so893207oag.41 for ; Tue, 25 Mar 2014 09:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pE/1UyQBvIt+T+0jKdjdG64/XosJWIqCFZm43Tmd2xM=; b=JOB+uw/5PVtbEJX65uC12NYq54vwEmypOnJatWnvNw9ki7FV5O5Vqp3hsl4Bx5L3Qu y/hdGGZ+WfXaUT6upKS8ArGyEapXM/n8dvMeboSsA0nvLl016qZNkDo9uRTipL452McO cEU8byAWKyfeWnmDAARUjj/301GviUEXGP7E7yYJX77krtiuepuHbV6ekKi4A5ECPfEr Hipjcy6sU85mWbhw0UkohhAOz8D94Ag0Mk2Byid1QfYAtYjgHWZzlRTRcCQK22apA+je 9J6BNR2bnT2rkkgkW2I3QksbbHQaQfl/zYc+cfixASjgcYLAoILJEhbf9s3+4USXio3W ItZQ== MIME-Version: 1.0 X-Received: by 10.182.204.41 with SMTP id kv9mr1680678obc.78.1395765823236; Tue, 25 Mar 2014 09:43:43 -0700 (PDT) Received: by 10.182.123.17 with HTTP; Tue, 25 Mar 2014 09:43:43 -0700 (PDT) Date: Tue, 25 Mar 2014 09:43:43 -0700 Message-ID: Subject: Raspberry pi 11 Current panic From: jungleboogie0 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 16:43:44 -0000 Hello All, I grabbed 11-CURRENT for raspberry pi here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 Booted up my pi and I'm trying to run vnstat but this occurs: root@raspberry-pi:~ # vmstat procs memory page disks faults cpu r b w avm fpanic: mutex process lock not owned at /usr/src/sys/kern/kern_sig.c:2874 KDB: enter: panic [ thread pid 747 tid 100063 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! So far I've been able to do this 3 times in a row by simply logging in and typing vmstat. Is this expected behavior? -- ------- inum: 883510009902611 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-arm@FreeBSD.ORG Tue Mar 25 19:35:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D116F858 for ; Tue, 25 Mar 2014 19:35:12 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92EDFB21 for ; Tue, 25 Mar 2014 19:35:12 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id o15so1105164qap.37 for ; Tue, 25 Mar 2014 12:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gq9DgUeAJvA+de3XTwjGlbWSp+41uf4QDvFqND7z3c8=; b=hSNX4KNRiWOIcmnRO44NyQ+I2XFTjtGhwnLwmB6p+AkR+YERSu2xKzoUhc36KOOhW6 L31lmTq0A8hPx8bb9KrUD7/Zoe1iDH/OYpmhLr14mkwAd8xonnb1ZoZU2T5LtvPFIQMI 5ShV6sKsbv4YWPqDABQyR6y60cvFsiGvwG4fxUDZRO4yCH2xNoJ1AIJWc6TtKBj5UXhn 7IGVsLVatUYYyZgTt+N5Y2pxIFDI0xAJWHrsw5+LssQwHvzrssqG3mo8H3Om9MuJSLF3 GfKqEc2uQfpFNWhBOwPThIdeUooQ6NCXqp2UwyVTWAt3pznROs12KhEcCSP/OdxNfqoc hrSQ== MIME-Version: 1.0 X-Received: by 10.140.42.9 with SMTP id b9mr11363768qga.87.1395776111811; Tue, 25 Mar 2014 12:35:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.125.1 with HTTP; Tue, 25 Mar 2014 12:35:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Mar 2014 12:35:10 -0700 X-Google-Sender-Auth: ilzg7AWhJzK9Pd0U9bkG1diBejE Message-ID: Subject: Re: Raspberry pi 11 Current panic From: Adrian Chadd To: jungleboogie0 Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 19:35:12 -0000 Can you type 'bt' in the debugger and paste that? -a On 25 March 2014 09:43, jungleboogie0 wrote: > Hello All, > > > > I grabbed 11-CURRENT for raspberry pi here: > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 > > Booted up my pi and I'm trying to run vnstat but this occurs: > > root@raspberry-pi:~ # vmstat > procs memory page disks faults cpu > r b w avm fpanic: mutex process lock not owned at > /usr/src/sys/kern/kern_sig.c:2874 > KDB: enter: panic > [ thread pid 747 tid 100063 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > So far I've been able to do this 3 times in a row by simply logging in and > typing vmstat. > > Is this expected behavior? > > > > -- > ------- > inum: 883510009902611 > sip: jungleboogie@sip2sip.info > xmpp: jungle-boogie@jit.si > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Tue Mar 25 23:32:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C32E8DB; Tue, 25 Mar 2014 23:32:51 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36E2338C; Tue, 25 Mar 2014 23:32:51 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id i7so1519422oag.5 for ; Tue, 25 Mar 2014 16:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1GaIazvR8RIYDz1Zpxz4O/iBw9vYaW/3grihd4kwcf4=; b=z+S4k7ZZ6yBF7BToaBfCLCmlo97PbnrSj9HfgQL5lb/PB2VvXDFfA4Ur33VXJOFyqT LdsYY1hV9UrqiIahis4OyRiAok2M6FDJFtM37xGtiBqZA5U8yu4Iqe/bsxQoBpl9DkCq uHyHMxPSjMmk6NP+ASMtRI/SIr4BgaZ6EqabyN8ZQT9MQYY4VzbWsbq2+Lcr9j6QSGIL BRJS7BTCD6bnZ2jUsXyvOCieeSy1H2P0mLqNpirVE+BnpOCb23OX3PcPm4Od5DiyYBPk dX2QQ6CEr7uRDCxQpeOjIzivXJZ7yVnPBjD7QfAsQP6CVCwIK92JwQ1t7vjMBSPttDeJ 76Jg== MIME-Version: 1.0 X-Received: by 10.182.1.8 with SMTP id 8mr4203815obi.58.1395790370439; Tue, 25 Mar 2014 16:32:50 -0700 (PDT) Received: by 10.182.123.17 with HTTP; Tue, 25 Mar 2014 16:32:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Mar 2014 16:32:50 -0700 Message-ID: Subject: Re: Raspberry pi 11 Current panic From: jungleboogie0 To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 23:32:51 -0000 And now to the group: U-Boot 2013.01-rc1-svn18531 (Mar 24 2014 - 09:11:00) DRAM: 480 MiB WARNING: Caches not enabled MMC: bcm2835_sdhci: 0 Using default environment In: serial Out: lcd Err: lcd mbox: Timeout waiting for response bcm2835: Could not set USB power state Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 reading uEnv.txt 89 bytes read in 9419 ms (0 Bytes/s) Importing environment from mmc ... reading ubldr 249191 bytes read in 54770 ms (3.9 KiB/s) ## Starting application at 0x02000054 ... Consoles: U-Boot console Compatible U-Boot API signature found @1db682a8 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@grind.freebsd.org, Mon Mar 24 09:10:50 UTC 2014) DRAM: 480MB Number of U-Boot devices: 1 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... good. Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x4b96e4+0x2e91c syms=[0x4+0x86880+0x4+0x50b0b] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x0x100. Kernel entry at 0x100100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #0 r263665: Mon Mar 24 09:05:52 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 CPU: ARM1176JZ-S rev 7 (ARM11J core) Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext WB enabled LABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536866816 (511 MB) avail memory = 483893248 (461 MB) random device not loaded; using insecure entropy random: initialized kbd0 at kbdmux0 ofwbus0: simplebus0: mem 0x20000000-0x20ffffff on ofwbus0 intc0: mem 0xb200-0xb3ff on simplebus0 systimer0: mem 0x3000-0x3fff irq 8,9,10,11 on simplebus0 Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000 Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000 bcmwd0: mem 0x10001c-0x100027 on simplebus0 gpio0: mem 0x200000-0x2000af irq 57,59,58,60 on simplebus0 gpio0: read-only pins: 46,47,48,49,50,51,52,53. gpio0: reserved pins: 48,49,50,51,52,53. gpioc0: on gpio0 gpiobus0: on gpio0 gpioled0: at pin(s) 16 on gpiobus0 iichb0: mem 0x205000-0x20501f irq 61 on simplebus0 iicbus0: on iichb0 iic0: on iicbus0 iichb1: mem 0x804000-0x80401f irq 61 on simplebus0 iicbus1: on iichb1 iic1: on iicbus1 spi0: mem 0x204000-0x20401f irq 62 on simplebus0 spibus0: on spi0 bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 mbox0: mem 0xb880-0xb8bf irq 1 on simplebus0 sdhci_bcm0: mem 0x300000-0x3000ff irq 70 on simplebus0 mmc0: on sdhci_bcm0 uart0: mem 0x201000-0x201fff irq 65 on simplebus0 uart0: console (115200,n,8,1) dwcotg0: mem 0x980000-0x99ffff irq 17 on simplebus0 usbus0 on dwcotg0 fb0: on ofwbus0 simplebus1: on ofwbus0 simplebus1: could not get ranges device_attach: simplebus1 attach returned 6 Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 mmcsd0: 16GB at mmc0 50.0MHz/4bit/65535-block fb0: 656x416(0x0@0,0) 16bpp fb0: pitch 1312, base 0x5e006000, screen_size 545792 fbd0 on fb0 vt_allocate: VT initialize with new VT driver. random: unblocking device. Root mount waiting for: usbus0 uhub0: 1 port with 1 removable, self powered ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled Root mount waiting for: usbus0 uhub1: 3 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0: on usbus0 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... WARNING: /releng/11-armv6-RPI-B-snap/tmp/crochet/work/_.mount.freebsd was not properly dismounted smsc0: chip 0xec00, rev. 0002 warning: no time-of-day clock registered, system time will not be set accurately miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:1c:6a:26 Enlarging root partition mmcsd0s2 resized mmcsd0s2a resized growfs: requested size 15GB is not larger than the current filesystem size 15GB Setting hostuuid: 9e15ff8d-b334-11e3-a379-b827eb1c6a26. Setting hostid: 0x8ff482a8. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point swi. Starting file system checks: ** SU+J Recovering /dev/mmcsd0s2a ** Reading 4194304 byte journal from inode 4. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 17 journal records in 2048 bytes for 26.56% utilization ** Freed 4 inodes (0 dirs) 0 blocks, and 1 frags. ***** FILE SYSTEM MARKED CLEAN ***** Mounting local file systems:. Writing entropy file:. Setting hostname: raspberry-pi. smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN Starting Network: lo0 ue0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 ue0: flags=8843 metric 0 mtu 1500 options=80001 ether b8:27:eb:1c:6a:26 media: Ethernet autoselect (none) status: no carrier nd6 options=29 Starting devd. Starting pflogd: add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Waiting 30s for the default route interface: .....(no carrier) Creating and/or trimming log files. ELF ldconfig path: /lib /usr/lib /usr/lib/compat Starting casperd. Clearing /tmp (X related). Updating motd:. Mounting late file systems:. Configuring syscons: blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting background file system checks in 60 seconds. Mon Mar 24 09:29:41 UTC 2014 FreeBSD/arm (raspberry-pi) (ttyu0) login: root FreeBSD 11.0-CURRENT (RPI-B) #0 r263665: Mon Mar 24 09:05:52 UTC 2014 Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it's updated frequently. o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, along with the mailing lists, can be searched by going to http://www.FreeBSD.org/search/ . If the doc package has been installed (or fetched via pkg install lang-freebsd-doc, where lang is the 2-letter language code, e.g. en), they are also available formatted in /usr/local/share/doc/freebsd. If you still have a question or problem, please take the output of `uname -a', along with any relevant error messages, and email it as a question to the questions@FreeBSD.org mailing list. If you are unfamiliar with FreeBSD's directory layout, please refer to the hier(7) manual page. If you are not familiar with manual pages, type `man man'. Edit /etc/motd to change this login announcement. root@raspberry-pi:~ # vmstat procs memory page disks faults cpu r b w avmpanic: mutex process lock not owned at /usr/src/sys/kern/kern_sig.c:2874 KDB: enter: panic [ thread pid 746 tid 100070 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 746 tid 100070 td 0xc29e2960 db_trace_self() at db_trace_self pc = 0xc048d0bc lr = 0xc0130e18 (db_stack_trace+0xf4) sp = 0xdcefca30 fp = 0xdcefca48 r10 = 0xc05dac10 db_stack_trace() at db_stack_trace+0xf4 pc = 0xc0130e18 lr = 0xc0130788 (db_command+0x270) sp = 0xdcefca50 fp = 0xdcefcaf0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 db_command() at db_command+0x270 pc = 0xc0130788 lr = 0xc01304ec (db_command_loop+0x60) sp = 0xdcefcaf8 fp = 0xdcefcb08 r4 = 0xc04cc6b0 r5 = 0xc04e6743 r6 = 0xc05dabfc r7 = 0xdcefccd8 r8 = 0xc05d14b0 r9 = 0xc05d14b4 r10 = 0xc05832e0 db_command_loop() at db_command_loop+0x60 pc = 0xc01304ec lr = 0xc0132eb4 (db_trap+0xd8) sp = 0xdcefcb10 fp = 0xdcefcc30 r4 = 0x00000000 r5 = 0xc05dac08 r6 = 0xc05d14e0 db_trap() at db_trap+0xd8 pc = 0xc0132eb4 lr = 0xc028c130 (kdb_trap+0xcc) sp = 0xdcefcc38 fp = 0xdcefcc58 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc05d14e0 r7 = 0xdcefccd8 kdb_trap() at kdb_trap+0xcc pc = 0xc028c130 lr = 0xc04a0960 (undefinedinstruction+0x298) sp = 0xdcefcc60 fp = 0xdcefccd0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc04a0618 r7 = 0xe7ffffff r8 = 0xc29e2960 r9 = 0xc028b9f0 r10 = 0xdcefccd8 undefinedinstruction() at undefinedinstruction+0x298 pc = 0xc04a0960 lr = 0xc048ec48 (exception_exit) sp = 0xdcefccd8 fp = 0xdcefcd30 r4 = 0xc04e679d r5 = 0xdcefcd6c r6 = 0xc04e4534 r7 = 0xc05c3a00 r8 = 0xc29e2960 r9 = 0xc05dc660 r10 = 0xc05c3860 exception_exit() at exception_exit pc = 0xc048ec48 lr = 0xc028b9e4 (kdb_enter+0x40) sp = 0xdcefcd28 fp = 0xdcefcd30 r0 = 0xc05d14c4 r1 = 0x00000000 r2 = 0xc04ea00b r3 = 0x000000ab r4 = 0xc04e679d r5 = 0xdcefcd6c r6 = 0xc04e4534 r7 = 0xc05c3a00 r8 = 0xc29e2960 r9 = 0xc05dc660 r10 = 0xc05c3860 r12 = 0x00000000 $a() at $a pc = 0xc028b9f4 lr = 0xc02553d8 (vpanic+0xb4) sp = 0xdcefcd38 fp = 0xdcefcd58 r4 = 0x00000100 vpanic() at vpanic+0xb4 pc = 0xc02553d8 lr = 0xc025543c (kproc_shutdown) sp = 0xdcefcd60 fp = 0xdcefcd64 r4 = 0xc26d9c80 r5 = 0xc0512deb r6 = 0xc04a1318 r7 = 0xec510b10 r8 = 0xc29e2960 r9 = 0x201c2d78 r10 = 0xdcefce68 kproc_shutdown() at kproc_shutdown pc = 0xc025543c lr = 0xc29e2960 (0xc29e2960) sp = 0xdcefcd6c fp = 0xdcefcd78 r4 = 0xc025543c r5 = 0xdcefcd6c Unknown entry: 0 end() at 0xc29e2960 pc = 0xc29e2960 lr = 0xc29e2960 (0xc29e2960) sp = 0xdcefcd6c fp = 0xdcefcd78 Unable to unwind into user mode db> On 25 March 2014 12:35, Adrian Chadd wrote: > Can you type 'bt' in the debugger and paste that? > > > -a > > > On 25 March 2014 09:43, jungleboogie0 wrote: > > Hello All, > > > > > > > > I grabbed 11-CURRENT for raspberry pi here: > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 > > > > Booted up my pi and I'm trying to run vnstat but this occurs: > > > > root@raspberry-pi:~ # vmstat > > procs memory page disks faults > cpu > > r b w avm fpanic: mutex process lock not owned at > > /usr/src/sys/kern/kern_sig.c:2874 > > KDB: enter: panic > > [ thread pid 747 tid 100063 ] > > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > > > So far I've been able to do this 3 times in a row by simply logging in > and > > typing vmstat. > > > > Is this expected behavior? > > > > > > > > -- > > ------- > > inum: 883510009902611 > > sip: jungleboogie@sip2sip.info > > xmpp: jungle-boogie@jit.si > > _______________________________________________ > > 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" > -- ------- inum: 883510009902611 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 09:49:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68C116C1 for ; Wed, 26 Mar 2014 09:49:50 +0000 (UTC) Received: from smtp-newslist-216.md02.com (smtp-newslist-216.md02.com [209.172.40.216]) by mx1.freebsd.org (Postfix) with ESMTP id 38E56F54 for ; Wed, 26 Mar 2014 09:49:50 +0000 (UTC) Received: by smtp-newslist-216.md02.com id h6ahbs19sl8i for ; Wed, 26 Mar 2014 05:39:09 -0400 (envelope-from ) Subject: CCTV From: "Phil" To: freebsd-arm@freebsd.org Tag-id: 208377.3279879.2136996.60.m.240e3802 IP-Address: 209.172.40.216 Interface-id: 443 Parent-id: 93133 Client-id: 208377 MIME-Version: 1.0 Message-Id: <20140326093909.267558BD69@pmta4-1-08> Date: Wed, 26 Mar 2014 05:39:09 -0400 (EDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 09:49:50 -0000 Hi, We can install a CCTV at your house or business for the following price. 1 Camera system =C2=A3399 2 Camera system =C2=A3599 3 Camera system =C2=A3699 4 Camera system =C2=A3899 Would you like me to arrange this for you? You get the following with all our systems. - See the cameras on your mobile. - High quality cameras with wide lens. - High capacity storage. - Infrared night vision. - Includes all parts and labour. - Includes cameras and recorder. - 1 years hardware warranty. We can beat any like for like price. Our engineers can install a system anywhere in the UK* Regards, CCTV Warrington Telephone: 01204 216810 Website: www.cctvwarrington.co.uk Address: 3 Churchbank, Bolton, BL1 1HX * Additional costs for any location which is more than 50 miles from our= offices. Unsubscribe from this mailing list: http://link.mailanimal01.com/u/443/0= e038a683332c8b25b44534781ea8886b6cfa1d05167399e From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 12:20:24 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8235B9A7; Wed, 26 Mar 2014 12:20:24 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D824FBF; Wed, 26 Mar 2014 12:20:24 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.8/8.14.8) with ESMTP id s2QCK2hu001044; Wed, 26 Mar 2014 12:20:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.8/8.14.8/Submit) id s2QCK2Ju001042; Wed, 26 Mar 2014 12:20:02 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 26 Mar 2014 12:20:02 GMT Message-Id: <201403261220.s2QCK2Ju001042@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:20:24 -0000 TB --- 2014-03-26 12:20:02 - tinderbox 2.21 running on freebsd-stable.sentex.ca TB --- 2014-03-26 12:20:02 - FreeBSD freebsd-stable.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263737: Wed Mar 26 08:50:55 UTC 2014 des@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-26 12:20:02 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-03-26 12:20:02 - cleaning the object tree TB --- 2014-03-26 12:20:02 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-26 12:20:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-26 12:20:02 - ERROR: unable to stat source tree TB --- 2014-03-26 12:20:02 - 0.07 user 0.00 system 0.05 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 12:30:20 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 756B38F4; Wed, 26 Mar 2014 12:30:20 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 357E8259; Wed, 26 Mar 2014 12:30:20 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.8/8.14.8) with ESMTP id s2QCU14p001163; Wed, 26 Mar 2014 12:30:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.8/8.14.8/Submit) id s2QCU1Nj001160; Wed, 26 Mar 2014 12:30:01 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 26 Mar 2014 12:30:01 GMT Message-Id: <201403261230.s2QCU1Nj001160@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:30:20 -0000 TB --- 2014-03-26 12:30:01 - tinderbox 2.21 running on freebsd-stable.sentex.ca TB --- 2014-03-26 12:30:01 - FreeBSD freebsd-stable.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263737: Wed Mar 26 08:50:55 UTC 2014 des@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-26 12:30:01 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-03-26 12:30:01 - cleaning the object tree TB --- 2014-03-26 12:30:01 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-26 12:30:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-26 12:30:01 - ERROR: unable to stat source tree TB --- 2014-03-26 12:30:01 - 0.05 user 0.01 system 0.02 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 12:40:17 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7768F592; Wed, 26 Mar 2014 12:40:17 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 41FB5353; Wed, 26 Mar 2014 12:40:17 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.8/8.14.8) with ESMTP id s2QCe1A9001282; Wed, 26 Mar 2014 12:40:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.8/8.14.8/Submit) id s2QCe1hq001280; Wed, 26 Mar 2014 12:40:01 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 26 Mar 2014 12:40:01 GMT Message-Id: <201403261240.s2QCe1hq001280@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:40:17 -0000 TB --- 2014-03-26 12:40:01 - tinderbox 2.21 running on freebsd-stable.sentex.ca TB --- 2014-03-26 12:40:01 - FreeBSD freebsd-stable.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263737: Wed Mar 26 08:50:55 UTC 2014 des@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-26 12:40:01 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-03-26 12:40:01 - cleaning the object tree TB --- 2014-03-26 12:40:01 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-26 12:40:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-26 12:40:01 - ERROR: unable to stat source tree TB --- 2014-03-26 12:40:01 - 0.05 user 0.02 system 0.02 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 12:50:14 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 764A21EB; Wed, 26 Mar 2014 12:50:14 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 40F876C5; Wed, 26 Mar 2014 12:50:14 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.8/8.14.8) with ESMTP id s2QCo1jP001406; Wed, 26 Mar 2014 12:50:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.8/8.14.8/Submit) id s2QCo1nC001402; Wed, 26 Mar 2014 12:50:01 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 26 Mar 2014 12:50:01 GMT Message-Id: <201403261250.s2QCo1nC001402@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:50:14 -0000 TB --- 2014-03-26 12:50:01 - tinderbox 2.21 running on freebsd-stable.sentex.ca TB --- 2014-03-26 12:50:01 - FreeBSD freebsd-stable.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263737: Wed Mar 26 08:50:55 UTC 2014 des@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-26 12:50:01 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-03-26 12:50:01 - cleaning the object tree TB --- 2014-03-26 12:50:01 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-26 12:50:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-26 12:50:01 - ERROR: unable to stat source tree TB --- 2014-03-26 12:50:01 - 0.06 user 0.00 system 0.02 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 13:00:11 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A1A9EA2; Wed, 26 Mar 2014 13:00:11 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D15A979; Wed, 26 Mar 2014 13:00:11 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.8/8.14.8) with ESMTP id s2QD018V001540; Wed, 26 Mar 2014 13:00:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.8/8.14.8/Submit) id s2QD01Qv001534; Wed, 26 Mar 2014 13:00:01 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 26 Mar 2014 13:00:01 GMT Message-Id: <201403261300.s2QD01Qv001534@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:00:11 -0000 TB --- 2014-03-26 13:00:01 - tinderbox 2.21 running on freebsd-stable.sentex.ca TB --- 2014-03-26 13:00:01 - FreeBSD freebsd-stable.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263737: Wed Mar 26 08:50:55 UTC 2014 des@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-26 13:00:01 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-03-26 13:00:01 - cleaning the object tree TB --- 2014-03-26 13:00:01 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-26 13:00:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-26 13:00:01 - ERROR: unable to stat source tree TB --- 2014-03-26 13:00:01 - 0.07 user 0.00 system 0.02 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 13:10:08 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82B41D86; Wed, 26 Mar 2014 13:10:08 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B8ACA8A; Wed, 26 Mar 2014 13:10:08 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.8/8.14.8) with ESMTP id s2QDA1Ni001647; Wed, 26 Mar 2014 13:10:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.8/8.14.8/Submit) id s2QDA1Ef001644; Wed, 26 Mar 2014 13:10:01 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 26 Mar 2014 13:10:01 GMT Message-Id: <201403261310.s2QDA1Ef001644@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:10:08 -0000 TB --- 2014-03-26 13:10:01 - tinderbox 2.21 running on freebsd-stable.sentex.ca TB --- 2014-03-26 13:10:01 - FreeBSD freebsd-stable.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263737: Wed Mar 26 08:50:55 UTC 2014 des@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-26 13:10:01 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-03-26 13:10:01 - cleaning the object tree TB --- 2014-03-26 13:10:01 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-26 13:10:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-26 13:10:01 - ERROR: unable to stat source tree TB --- 2014-03-26 13:10:01 - 0.05 user 0.02 system 0.02 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 13:20:06 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D9B5BBD; Wed, 26 Mar 2014 13:20:06 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 577C0C17; Wed, 26 Mar 2014 13:20:06 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.8/8.14.8) with ESMTP id s2QDK2p4001772; Wed, 26 Mar 2014 13:20:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.8/8.14.8/Submit) id s2QDK2OA001768; Wed, 26 Mar 2014 13:20:02 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 26 Mar 2014 13:20:02 GMT Message-Id: <201403261320.s2QDK2OA001768@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:20:06 -0000 TB --- 2014-03-26 13:20:02 - tinderbox 2.21 running on freebsd-stable.sentex.ca TB --- 2014-03-26 13:20:02 - FreeBSD freebsd-stable.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263737: Wed Mar 26 08:50:55 UTC 2014 des@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-26 13:20:02 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-03-26 13:20:02 - cleaning the object tree TB --- 2014-03-26 13:20:02 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-26 13:20:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-26 13:20:02 - ERROR: unable to stat source tree TB --- 2014-03-26 13:20:02 - 0.05 user 0.02 system 0.03 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 13:30:04 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D7E6904; Wed, 26 Mar 2014 13:30:04 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 084D1DA3; Wed, 26 Mar 2014 13:30:03 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.8/8.14.8) with ESMTP id s2QDU2sM001891; Wed, 26 Mar 2014 13:30:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.8/8.14.8/Submit) id s2QDU2VJ001886; Wed, 26 Mar 2014 13:30:02 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 26 Mar 2014 13:30:02 GMT Message-Id: <201403261330.s2QDU2VJ001886@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:30:04 -0000 TB --- 2014-03-26 13:30:02 - tinderbox 2.21 running on freebsd-stable.sentex.ca TB --- 2014-03-26 13:30:02 - FreeBSD freebsd-stable.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263737: Wed Mar 26 08:50:55 UTC 2014 des@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-26 13:30:02 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-03-26 13:30:02 - cleaning the object tree TB --- 2014-03-26 13:30:02 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-26 13:30:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2014-03-26 13:30:02 - ERROR: unable to stat source tree TB --- 2014-03-26 13:30:02 - 0.06 user 0.01 system 0.02 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 21:26:45 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 830BC636 for ; Wed, 26 Mar 2014 21:26:45 +0000 (UTC) Received: from mailgate-01.zdv.uni-mainz.de (mailgate-01.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f1]) by mx1.freebsd.org (Postfix) with ESMTP id 972D8E6C for ; Wed, 26 Mar 2014 21:26:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1395869204; x=1427405204; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hvOjqEX38txfmc33qNTpwOSW+njaOuPCZjiIHC0FiME=; b=CF2Vwb5EaI6AdcHLRj4MZnX0NfnQmjrIzJtqPofVwn3OS3ipLKD9XXcD nlLGuhiYhyf42gHY15/aTfP1xzj10kSurfLQ9ripGW85NhxXiADxInMgC yeDA9ugM7NeNlDkcvNpEqlytVMjsQ/tA4PT9PRG6T++Z7t6ImCFsYKjb5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAKNFM1MKXgZY/2dsb2JhbABZgmVcV7s+hmRRgTR0giUBAQEEAQEBSyAXBAIBCA4DBAEBKAcnAQkBFAkIAgQBBwcEAQcVBIdYAQzRNBeOIAEBVgaCKIIKBIkajFyECoUVhBKHWYMuboEEOQ X-IPAS-Result: AqYEAKNFM1MKXgZY/2dsb2JhbABZgmVcV7s+hmRRgTR0giUBAQEEAQEBSyAXBAIBCA4DBAEBKAcnAQkBFAkIAgQBBwcEAQcVBIdYAQzRNBeOIAEBVgaCKIIKBIkajFyECoUVhBKHWYMuboEEOQ Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-01.zdv.uni-mainz.de with ESMTP; 26 Mar 2014 22:26:42 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) by E14HUB-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c60) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 26 Mar 2014 22:26:42 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 26 Mar 2014 22:26:40 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090]) by e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090%15]) with mapi id 15.00.0847.030; Wed, 26 Mar 2014 22:26:40 +0100 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'Ralf Wenk' , "'arm@freebsd.org'" Subject: RE: Experimental TARGET_ARCH armv6hf crashes on my RPi afer some time Thread-Topic: Experimental TARGET_ARCH armv6hf crashes on my RPi afer some time Thread-Index: AQHPSCYOc4sJ4cLS2EGHKcqaoizZG5rz4oHA Date: Wed, 26 Mar 2014 21:26:40 +0000 Message-ID: <49f1d8f307f24aa5b5ca2c57748fe9af@e15be-01.zdv.Uni-Mainz.DE> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 21:26:45 -0000 The messages 'sleep: nanosleep: Invalid argument' come from the sleep command. When compiled without optimization, the sleep command seems to work. So this seems to be an error in the clang optimizer. Regards Juergen > -----Original Message----- > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freebsd.org= ] On Behalf Of > Ralf Wenk > Sent: Tuesday, March 25, 2014 1:31 PM > To: arm@freebsd.org > Subject: Experimental TARGET_ARCH armv6hf crashes on my RPi afer some tim= e >=20 > Hi, >=20 > I tried the new experimental TARGET_ARCH armv6hf on my raspberry pi. > World and kernel are build with > make -j 8 -C $SRCROOT MALLOC_PRODUCTION=3Dyes buildworld > make -j 8 -C $SRCROOT KERNCONF=3D$KERNCONF WITH_FDT=3Dyes buildkernel > and installed over a normal armv6 kernel and world. The release used was > FreeBSD 11.0-CURRENT #0 r263667M. >=20 > Within an hour since boot the system panics with an undefined floating po= int > instruction in supervisor mode. > This happened during a shutdown - but not on every shutdown - and during > normal system activity. On every shutdown there is a > sleep: nanosleep: Invalid argument > message printed in the console. >=20 > I do not file a bug report because of the experimental state of armv6hf. >=20 > Gathered information from two panics: > panic: undefined floating point instruction in supervisor mode > KDB: enter: panic > [ thread pid 509 tid 100056 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 509 tid 100056 td 0xc2675320 > db_trace_self() at db_trace_self > pc =3D 0xc04a38a0 lr =3D 0xc0136184 (db_stack_trace+0xf4) > sp =3D 0xdd794668 fp =3D 0xdd794680 > r10 =3D 0xc05c29f0 > db_stack_trace() at db_stack_trace+0xf4 > pc =3D 0xc0136184 lr =3D 0xc0135b3c (db_command+0x270) > sp =3D 0xdd794688 fp =3D 0xdd794728 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0x00000000 > db_command() at db_command+0x270 > pc =3D 0xc0135b3c lr =3D 0xc01358a0 (db_command_loop+0x60) > sp =3D 0xdd794730 fp =3D 0xdd794740 > r4 =3D 0xc04e1377 r5 =3D 0xc04f5222 > r6 =3D 0xc05c29dc r7 =3D 0xdd794928 > r8 =3D 0xc05b92f0 r9 =3D 0xc05b92f4 > r10 =3D 0xc0577c30 > db_command_loop() at db_command_loop+0x60 > pc =3D 0xc01358a0 lr =3D 0xc013831c (db_trap+0xd8) > sp =3D 0xdd794748 fp =3D 0xdd794868 > r4 =3D 0x00000000 r5 =3D 0xc05c29e8 > r6 =3D 0xc05b9320 > db_trap() at db_trap+0xd8 > pc =3D 0xc013831c lr =3D 0xc02c2274 (kdb_trap+0xcc) > sp =3D 0xdd794870 fp =3D 0xdd794890 > r4 =3D 0x00000000 r5 =3D 0x00000001 > r6 =3D 0xc05b9320 r7 =3D 0xdd794928 > kdb_trap() at kdb_trap+0xcc > pc =3D 0xc02c2274 lr =3D 0xc04b8eb0 (undefinedinstruction+0x2f8= ) > sp =3D 0xdd794898 fp =3D 0xdd794920 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xc04b8b08 r7 =3D 0xe7ffffff > r8 =3D 0xc2675320 r9 =3D 0xc02c1b34 > r10 =3D 0xdd794928 > undefinedinstruction() at undefinedinstruction+0x2f8 > pc =3D 0xc04b8eb0 lr =3D 0xc04a5410 (exception_exit) > sp =3D 0xdd794928 fp =3D 0xdd794980 > r4 =3D 0xc04f527c r5 =3D 0xc050fe47 > r6 =3D 0xc05c4460 r7 =3D 0xc05ab848 > r8 =3D 0xdd7949b4 r9 =3D 0xc2675320 > r10 =3D 0xc05ab7d0 > exception_exit() at exception_exit > pc =3D 0xc04a5410 lr =3D 0xc02c1b28 (kdb_enter+0x40) > sp =3D 0xdd794978 fp =3D 0xdd794980 > r0 =3D 0xc05b9304 r1 =3D 0x00000000 > r2 =3D 0x00000001 r3 =3D 0x00000001 > r4 =3D 0xc04f527c r5 =3D 0xc050fe47 > r6 =3D 0xc05c4460 r7 =3D 0xc05ab848 > r8 =3D 0xdd7949b4 r9 =3D 0xc2675320 > r10 =3D 0xc05ab7d0 r12 =3D 0x00000000 > $a() at $a > pc =3D 0xc02c1b38 lr =3D 0xc0285b54 (panic+0xc4) > sp =3D 0xdd794988 fp =3D 0xdd7949a8 > r4 =3D 0x00000100 > panic() at panic+0xc4 > pc =3D 0xc0285b54 lr =3D 0xc04b991c ($d) > sp =3D 0xdd7949c0 fp =3D 0xdd7949c0 > r4 =3D 0x00000000 r5 =3D 0xc05c2890 > r6 =3D 0xc04b985c r7 =3D 0xeca00b20 > r8 =3D 0xc2675320 r9 =3D 0xc04b9940 > r10 =3D 0xdd794a58 > $d() at $d > pc =3D 0xc04b991c lr =3D 0xc04b8cac (undefinedinstruction+0xf4) > sp =3D 0xdd7949c8 fp =3D 0xdd794a50 > undefinedinstruction() at undefinedinstruction+0xf4 > pc =3D 0xc04b8cac lr =3D 0xc04a5410 (exception_exit) > sp =3D 0xdd794a58 fp =3D 0xdd794ad0 > r4 =3D 0xc2884640 r5 =3D 0xc2675320 > r6 =3D 0xc05c4640 r7 =3D 0xc05c7ec0 > r8 =3D 0x8791dcd3 r9 =3D 0xdd758eb8 > r10 =3D 0xc059e9e0 > exception_exit() at exception_exit > pc =3D 0xc04a5410 lr =3D 0xc04b6c80 (cpu_switch+0x60) > sp =3D 0xdd794aa8 fp =3D 0xdd794ad0 > r0 =3D 0xdd794ef0 r1 =3D 0x00000001 > r2 =3D 0xdd794eb8 r3 =3D 0x00000000 > r4 =3D 0xc2884640 r5 =3D 0xc2675320 > r6 =3D 0xc05c4640 r7 =3D 0xc05c7ec0 > r8 =3D 0x8791dcd3 r9 =3D 0xdd758eb8 > r10 =3D 0xc059e9e0 r12 =3D 0xc0000780 > vfp_store() at vfp_store+0x14 > pc =3D 0xc04b9940 lr =3D 0xc04b6c80 (cpu_switch+0x60) > sp =3D 0xdd794aa8 fp =3D 0xdd794ad0 > Unwind failure (no registers changed) > db> > db> show proc 509 > Process 509 (devd) at 0xc25c4640: > state: NORMAL > uid: 0 gids: 0 > parent: pid 1 at 0xc2431640 > ABI: FreeBSD ELF32 > arguments: /sbin/devd > threads: 1 > 100056 Run CPU 255 devd > db> > db> show thread 100056 > Thread 100056 at 0xc2675320: > proc (pid 509): 0xc25c4640 > name: devd > stack: 0xdd757000-0xdd758fff > flags: 0x1000004 pflags: 0 > state: RUNNING (CPU 255) > priority: 140 > container lock: sched lock (0xc05c4640) > db> >=20 >=20 > system shutdown time has arrived > sleep: nanosleep: Invalid argument > panic: undefined floating point instruction in supervisor mode > KDB: enter: panic > [ thread pid 11 tid 100005 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 11 tid 100005 td 0xc2433960 > db_trace_self() at db_trace_self > pc =3D 0xc04a38a0 lr =3D 0xc0136184 (db_stack_trace+0xf4) > sp =3D 0xdd749360 fp =3D 0xdd749378 > r10 =3D 0xc05c29f0 > db_stack_trace() at db_stack_trace+0xf4 > pc =3D 0xc0136184 lr =3D 0xc0135b3c (db_command+0x270) > sp =3D 0xdd749380 fp =3D 0xdd749420 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0x00000000 > db_command() at db_command+0x270 > pc =3D 0xc0135b3c lr =3D 0xc01358a0 (db_command_loop+0x60) > sp =3D 0xdd749428 fp =3D 0xdd749438 > r4 =3D 0xc04e1377 r5 =3D 0xc04f5222 > r6 =3D 0xc05c29dc r7 =3D 0xdd749620 > r8 =3D 0xc05b92f0 r9 =3D 0xc05b92f4 > r10 =3D 0xc0577c30 > db_command_loop() at db_command_loop+0x60 > pc =3D 0xc01358a0 lr =3D 0xc013831c (db_trap+0xd8) > sp =3D 0xdd749440 fp =3D 0xdd749560 > r4 =3D 0x00000000 r5 =3D 0xc05c29e8 > r6 =3D 0xc05b9320 > db_trap() at db_trap+0xd8 > pc =3D 0xc013831c lr =3D 0xc02c2274 (kdb_trap+0xcc) > sp =3D 0xdd749568 fp =3D 0xdd749588 > r4 =3D 0x00000000 r5 =3D 0x00000001 > r6 =3D 0xc05b9320 r7 =3D 0xdd749620 > kdb_trap() at kdb_trap+0xcc > pc =3D 0xc02c2274 lr =3D 0xc04b8eb0 (undefinedinstruction+0x2f8= ) > sp =3D 0xdd749590 fp =3D 0xdd749618 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xc04b8b08 r7 =3D 0xe7ffffff > r8 =3D 0xc2433960 r9 =3D 0xc02c1b34 > r10 =3D 0xdd749620 > undefinedinstruction() at undefinedinstruction+0x2f8 > pc =3D 0xc04b8eb0 lr =3D 0xc04a5410 (exception_exit) > sp =3D 0xdd749620 fp =3D 0xdd749678 > r4 =3D 0xc04f527c r5 =3D 0xc050fe47 > r6 =3D 0xc05c4460 r7 =3D 0xc05ab848 > r8 =3D 0xdd7496ac r9 =3D 0xc2433960 > r10 =3D 0xc05ab7d0 > exception_exit() at exception_exit > pc =3D 0xc04a5410 lr =3D 0xc02c1b28 (kdb_enter+0x40) > sp =3D 0xdd749670 fp =3D 0xdd749678 > r0 =3D 0xc05b9304 r1 =3D 0x00000000 > r2 =3D 0x00000001 r3 =3D 0x00000001 > r4 =3D 0xc04f527c r5 =3D 0xc050fe47 > r6 =3D 0xc05c4460 r7 =3D 0xc05ab848 > r8 =3D 0xdd7496ac r9 =3D 0xc2433960 > r10 =3D 0xc05ab7d0 r12 =3D 0x00000000 > $a() at $a > pc =3D 0xc02c1b38 lr =3D 0xc0285b54 (panic+0xc4) > sp =3D 0xdd749680 fp =3D 0xdd7496a0 > r4 =3D 0x00000100 > panic() at panic+0xc4 > pc =3D 0xc0285b54 lr =3D 0xc04b991c ($d) > sp =3D 0xdd7496b8 fp =3D 0xdd7496b8 > r4 =3D 0x00000000 r5 =3D 0xc05c2890 > r6 =3D 0xc04b985c r7 =3D 0xeca00b20 > r8 =3D 0xc2433960 r9 =3D 0xc04b9940 > r10 =3D 0xdd749750 > $d() at $d > pc =3D 0xc04b991c lr =3D 0xc04b8cac (undefinedinstruction+0xf4) > sp =3D 0xdd7496c0 fp =3D 0xdd749748 > undefinedinstruction() at undefinedinstruction+0xf4 > pc =3D 0xc04b8cac lr =3D 0xc04a5410 (exception_exit) > sp =3D 0xdd749750 fp =3D 0xdd7497c8 > r4 =3D 0xc25a8000 r5 =3D 0xc2433960 > r6 =3D 0xc05c4640 r7 =3D 0xc05c7ec0 > r8 =3D 0x5aee06ac r9 =3D 0xdb3abeb8 > r10 =3D 0xc059e9e0 > exception_exit() at exception_exit > pc =3D 0xc04a5410 lr =3D 0xc04b6c80 (cpu_switch+0x60) > sp =3D 0xdd7497a0 fp =3D 0xdd7497c8 > r0 =3D 0xdd749ef0 r1 =3D 0x00000001 > r2 =3D 0xdd749eb8 r3 =3D 0x00000000 > r4 =3D 0xc25a8000 r5 =3D 0xc2433960 > r6 =3D 0xc05c4640 r7 =3D 0xc05c7ec0 > r8 =3D 0x5aee06ac r9 =3D 0xdb3abeb8 > r10 =3D 0xc059e9e0 r12 =3D 0xc0000708 > vfp_store() at vfp_store+0x14 > pc =3D 0xc04b9940 lr =3D 0xc04b6c80 (cpu_switch+0x60) > sp =3D 0xdd7497a0 fp =3D 0xdd7497c8 > Unwind failure (no registers changed) > db> show proc 11 > Process 11 (intr) at 0xc2431000: > state: NORMAL > uid: 0 gids: 0 > parent: pid 0 at 0xc05c3658 > ABI: null > threads: 24 > 100034 I [intr17: dwcotg0] > 100033 I [swi0: uart] > 100032 I [intr70: sdhci_bcm0] > 100031 I [intr1: mbox0] > 100030 I [intr35: bcm_dma0] > 100029 I [intr34: bcm_dma0] > 100028 I [intr33: bcm_dma0] > 100027 I [intr32: bcm_dma0] > 100026 I [intr31: bcm_dma0] > 100025 I [intr30: bcm_dma0] > 100024 I [intr29: bcm_dma0] > 100023 I [intr28: bcm_dma0] > 100022 I [intr27: bcm_dma0] > 100021 I [intr26: bcm_dma0] > 100020 I [intr25: bcm_dma0] > 100019 I [intr24: bcm_dma0] > 100018 I [intr62: spi0] > 100017 I [intr61: iichb0+] > 100015 I [swi6: Giant taskq] > 100014 I [swi6: task queue] > 100010 I [swi5: fast taskq] > 100005 Run CPU 255 [swi4: clock (0)] > 100004 I [swi3: vm] > 100003 I [swi1: netisr 0] > db> sh thread 100005 > Thread 100005 at 0xc2433960: > proc (pid 11): 0xc2431000 > name: swi4: clock (0) > stack: 0xdb3aa000-0xdb3abfff > flags: 0x1000004 pflags: 0x200400 > state: RUNNING (CPU 255) > priority: 40 > container lock: sched lock (0xc05c4640) > db> >=20 >=20 > Ralf >=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 Mar 26 21:48:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E17F9A4D; Wed, 26 Mar 2014 21:48:11 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93D74B4; Wed, 26 Mar 2014 21:48:11 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id i4so3362289oah.38 for ; Wed, 26 Mar 2014 14:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dhIs9ATkYT7shaF2Jf4GhdTAth5bI+QiKB3sGIOXtR4=; b=m8xOIm3ffKIvHEB5EM/ejMfMzkg4wDHeU/8qeXJ8qmdhK/hcMpqg7TdVIA077YjZSL lWYDSHi2ty6cLV6nelFDRStB1qPJRAV/UdTrtDP1aOJ3mIo0Z2MiIdptlP8x+ZBQd8OH cap6ooqbAw+mPvK2qUArnG7Juv+zb4zeYrxczz3oH8rtJWzdrMvio4XYHKTVrcYietF/ x5HgxqqY39KHC6tfmUFi38ooqCbY8TTXYeBR73M3oGq4Vfd/Rs6Tpm9xIoG2ksqxs/Zi Hw2unKg7kiQG3QTZtjToscJY7hKbAp6EofRsjeDl86puQ/nBi/tN81Ej4EbK9SFsX6Um LOUQ== MIME-Version: 1.0 X-Received: by 10.182.33.6 with SMTP id n6mr18203249obi.48.1395870490992; Wed, 26 Mar 2014 14:48:10 -0700 (PDT) Received: by 10.60.227.194 with HTTP; Wed, 26 Mar 2014 14:48:10 -0700 (PDT) Date: Wed, 26 Mar 2014 18:48:10 -0300 Message-ID: Subject: Cross-compiling a kernel module? From: Martin Galvan To: freebsd-arm@freebsd.org, freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 21:48:12 -0000 Hi everyone! I'm trying to cross-compile a simple Hello World module for the A10 Cubieboard (which is ARM/Allwinner10 based) but I'm not sure of how to write my makefile. What I'm using to test it (on an amd64) is: KMOD=hello SRCS=hello.c .include I've been browsing the mailing list a bit and so far I've found a way but it involves rebuilding the whole kernel, and I just want to compile this module to load/unload in runtime. Also, before you answer this: try and be as specific as you can, since I'm kind of a newbie at this. Stuff like where should I put/look for files, run commands, etc would be appreciated. From owner-freebsd-arm@FreeBSD.ORG Wed Mar 26 22:44:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE049E42; Wed, 26 Mar 2014 22:44:50 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AA0084F; Wed, 26 Mar 2014 22:44:50 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2QMihjj085315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2014 15:44:43 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2QMihw3085314; Wed, 26 Mar 2014 15:44:43 -0700 (PDT) (envelope-from jmg) Date: Wed, 26 Mar 2014 15:44:43 -0700 From: John-Mark Gurney To: Martin Galvan Subject: Re: Cross-compiling a kernel module? Message-ID: <20140326224443.GN60889@funkthat.com> Mail-Followup-To: Martin Galvan , freebsd-arm@freebsd.org, freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 26 Mar 2014 15:44:43 -0700 (PDT) Cc: freebsd-arm@freebsd.org, freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 22:44:50 -0000 Martin Galvan wrote this message on Wed, Mar 26, 2014 at 18:48 -0300: > Hi everyone! I'm trying to cross-compile a simple Hello World module for > the A10 Cubieboard (which is ARM/Allwinner10 based) but I'm not sure of how > to write my makefile. What I'm using to test it (on an amd64) is: > > KMOD=hello > SRCS=hello.c > > .include > > I've been browsing the mailing list a bit and so far I've found a way but > it involves rebuilding the whole kernel, and I just want to compile this > module to load/unload in runtime. > > Also, before you answer this: try and be as specific as you can, since I'm > kind of a newbie at this. Stuff like where should I put/look for files, run > commands, etc would be appreciated. $ cd $SRC $ make kernel-toolchain TARGET_ARCH=armXX $ make buildenv TARGET_ARCH=armXX BUILDENV_SHELL=/usr/local/bin/shell $ cd $ make The buildenv command sets up the new shell with an environment that is the same as if you were running under a buildkernel or buildworld environment.. You can use this to build one off programs like bin/ls too. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu Mar 27 02:48:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65DE72BB for ; Thu, 27 Mar 2014 02:48:27 +0000 (UTC) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 348A5F3A for ; Thu, 27 Mar 2014 02:48:26 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id rl12so2728812iec.22 for ; Wed, 26 Mar 2014 19:48:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Qw2cJDgDN8Ml1k3/7GLIzae94RPnDUzcqjKVdPRrSVA=; b=N7zQEFW2srIqGWRg9D8zfIy0CSC7K7r2pR8SmMrFTURZe+NK/piTdlF7ufU/0LCWc+ mH4SojbKxIqfJ5dysWUxSQ8MfaDBPyLAiwVhDZQOR3ewdueJBS0vkJQSAKP82/pppw+j lIY+0AoGLY7eTiMnXR7pDKVlDcaymlOnwWZpdwfArOZaAapXAW5SHInsfjtkgjYjDyS+ ub/Ff9fIOHdL6IbC6LOd+SMgB4cPtyFlo9jCRvaAmazCt7zPxOSrS7G6boVfASQ0mSKe BD9UqQJcPOPpmpZfLJHbwGDZzlKVTF1HRsVo+H5KDzJnTCCIyNDArhnpcms2t+d0Z6Gb zZiw== X-Gm-Message-State: ALoCoQlC3oLpcFwi2q9Z6SGVHox9I9+bCbaX5wgZ6xTPfX0Xa4Nq1FlezNk5USmZ76vafG7isgiipevMrbMGluzGpMnm245uYMV09GlcYJtvW1Xheo0DgoE= X-Received: by 10.42.10.82 with SMTP id p18mr61724659icp.30.1395888500717; Wed, 26 Mar 2014 19:48:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.128.200 with HTTP; Wed, 26 Mar 2014 19:48:05 -0700 (PDT) From: "Lundberg, Johannes" Date: Thu, 27 Mar 2014 11:48:05 +0900 Message-ID: Subject: Jetson TK1 from nVidia ships in April, pre-order started To: freebsd-embedded@freebsd.org, "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 02:48:27 -0000 Hi Just noticed that K1 development board from nVidia has been publicly announced. https://developer.nvidia.com/jetson-tk1 It would enable some really cool applications if we could achieve two things 1) Get FreeBSD running on TK1 including HDMI graphical output support 2) Get nVidia to add native CUDA support for FreeBSD Think we can make this happen? Best regards -- Johannes Lundberg -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-arm@FreeBSD.ORG Thu Mar 27 04:52:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE954393; Thu, 27 Mar 2014 04:52:49 +0000 (UTC) Received: from mx0.deglitch.com (unknown [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8943AC62; Thu, 27 Mar 2014 04:52:49 +0000 (UTC) Received: from [192.168.11.2] (unknown [98.234.106.231]) by mx0.deglitch.com (Postfix) with ESMTPSA id CB4258FC40; Thu, 27 Mar 2014 08:52:16 +0400 (MSK) Content-Type: multipart/signed; boundary="Apple-Mail=_17B55FD1-4D6A-4AF4-AA36-6FF2ADE37135"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Cross-compiling a kernel module? From: Stanislav Sedov In-Reply-To: <20140326224443.GN60889@funkthat.com> Date: Wed, 26 Mar 2014 21:52:05 -0700 Message-Id: <28B91494-CCBB-4050-8E01-7B2BF0C4ABC9@freebsd.org> References: <20140326224443.GN60889@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org, Martin Galvan , freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 04:52:49 -0000 --Apple-Mail=_17B55FD1-4D6A-4AF4-AA36-6FF2ADE37135 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 26, 2014, at 3:44 PM, John-Mark Gurney wrote: > $ cd $SRC > $ make kernel-toolchain TARGET_ARCH=3DarmXX > $ make buildenv TARGET_ARCH=3DarmXX = BUILDENV_SHELL=3D/usr/local/bin/shell > $ cd > $ make >=20 > The buildenv command sets up the new shell with an environment that is > the same as if you were running under a buildkernel or buildworld > environment.. You can use this to build one off programs like bin/ls > too. Don=92t forget to set the KERNBUILDDIR option as well to point to your kernel object dir so the module will pick up all the right options. -- ST4096-RIPE --Apple-Mail=_17B55FD1-4D6A-4AF4-AA36-6FF2ADE37135 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTM651AAoJEG2OTJ9WF+r7tpsH/2OjyJcF/w2b24ETxVDePTXW U+nvYCU5ZwC2abZfkZ0Y41q3oKgzNp9kcphu4IDzhnSgcaVxDtxl6g/EsmTvaeJs VKq/4PJUL5qpO2HFdnEiVM7xO8ipGk+lp0prRIG2KXEznQfZC8EcYd0lvyC/vcqY hNKX3daGA7L+qPcGrcCeBkYS21MOGKGvRmHJvZ02I7aZVqcKB8HMWXITIjkRmI/0 ryHb27JLLQ88ZezZWrU/csRiDrSsYhJzPOv9eMBwIml2bULQXjhQUX+UixfFtZw8 R9wWmhjUb0i5jdk2clCtnVPkHkyiNON+WMOJrw2qczdJXPUhE/hEyjZF/jBd9q4= =ntF/ -----END PGP SIGNATURE----- --Apple-Mail=_17B55FD1-4D6A-4AF4-AA36-6FF2ADE37135-- From owner-freebsd-arm@FreeBSD.ORG Thu Mar 27 13:10:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A390E52 for ; Thu, 27 Mar 2014 13:10:30 +0000 (UTC) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DB43E18 for ; Thu, 27 Mar 2014 13:10:30 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id hu19so4213586vcb.29 for ; Thu, 27 Mar 2014 06:10:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kEETDd1csQT8Pm5GLCgmY9nL8aCTvBqIaHe+uUouLxk=; b=TS37sgeD+Z5FvXGQOOboNdnKO4f/7l1nSAiQvVnpiC2VRnIE8i/SE0sqjIAl2CQJqI YedCXF4Qp8hOq3pVRixiHv92vvpH0VZmiSTqndnEKrmdGl18owYQHjCEbUkDIfHyei3c S2IBMm3Jd8fYf512i6TUSpzocykuioPiPvKZMKqYP7YwqZkdDXTJKgAEi8XRFptYhgwb yOX7Mu252d1hD7sHHqUFzkfYAQ5FdG71ipbV9FFQujW/lX//CrmPxpsRUgPIpycgPVeH /Enh0PWrAVa19631WU01DZQQO8aTT6fkAvwJ1Y5cdCovTKgXQQa3gi3KogZLxi/jLdqM Xv0Q== X-Gm-Message-State: ALoCoQkhlm5aWkk2QJo7m9oXXnwtsZNlk0au7dKGmm2w2KKmGMnvo3NyVTPWmTBZv+pJ7hTKpWTl MIME-Version: 1.0 X-Received: by 10.52.99.168 with SMTP id er8mr1176398vdb.26.1395925823677; Thu, 27 Mar 2014 06:10:23 -0700 (PDT) Received: by 10.220.209.135 with HTTP; Thu, 27 Mar 2014 06:10:23 -0700 (PDT) In-Reply-To: <1395754555.81853.65.camel@revolution.hippie.lan> References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> <1395494401.81853.34.camel@revolution.hippie.lan> <1395754555.81853.65.camel@revolution.hippie.lan> Date: Thu, 27 Mar 2014 14:10:23 +0100 Message-ID: Subject: Re: arm SMP on Cortex-A15 From: Wojciech Macek To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 13:10:30 -0000 I started cleaning up and have some concerns. Sorry guys, the r263251 still looks like a workaround to me :) The fact that TLB cache issue is seen only on executable pages and that Olivier's fix helps suggests, that we are missing flush-I somewhere (crash appears only when deallocating userspace vm, so my guess is pmap_kremove, where definitely should be flushID). For test purposes I reverted r263251 and added additional flushID/flushD logic to the pmap-v6 in performance-critical sections, or modified flushD to flushID where the speed is not the case. All changes integrated with previous patches can be found here: https://drive.google.com/file/d/0B-7yTLrPxaWtRFRHTUtpZ3VKbG8/edit?usp=sharing With above patch I'm able to run all tests without any problems. Maybe it would be better to fix these suspicious places in pmap instead? Regards, Wojtek 2014-03-25 14:35 GMT+01:00 Ian Lepore : > Good, that means we can stop searching for the missing tlb flush when a > pte is invalidated. :) You guys can commit whenever you're ready (or I > can do it if you'd like). > > -- Ian > > On Tue, 2014-03-25 at 11:14 +0100, Wojciech Macek wrote: > > Hi Ian, > > > > The r263251 fix helped, thanks! > > So now, if you don';t have any objections, I will clean up a little the > > cpufunc.S & pmap-v6 changes and make them ready for submitting. > > > > Regards, > > Wojtek > > > > > > 2014-03-24 14:31 GMT+01:00 Wojciech Macek : > > > > > Without the unconditional invalidation, the panic shows up just at the > > > beginning, after rootfs is mounted and init scripts are running. When a > > > userspace process is exitting, its memory resources are freed - this > is the > > > moment pmap_remove_pages fails due to tharanslation fault. It is the > > > "typical" crash I observed when TLB-cache holds an old entry. Below > there > > > is a backtrace, but I doubt if it can be helpful. > > > > > > Regarding old pte/tlb, the TLB cache contains entry from old process > > > context, when in-memory-PTE value is already correct - at least this > was > > > the scenario when I debugged it last year. So, invalidating after > *pte=0 is > > > definitely not our case. The issue shows up only on a15, where the > > > tlb-prefetcher can cache pte entries anytime. > > > > > > I believe I don't have r263251 integrated. I'll give it a try - > typically, > > > the tlb-caused crash appears only on pages containing shared libraries > code > > > (with executable attr), so there is a chance Olivier's fix help. > > > > > > > > > The fault: > > > > > > vm_fault(0xc5b894f0, 0, 2, 0) -> 1 > > > Fatal kernel mode data abort: 'Translation Fault (P)' > > > trapframe: 0xef2cca40 > > > FSR=00000817, FAR=00000030, spsr=60000013 > > > r0 =00000000, r1 =c320a048, r2 =00000000, r3 =c3208074 > > > r4 =c5b7cd08, r5 =c5b7cd04, r6 =c5b05800, r7 =c5b895ac > > > r8 =c320a044, r9 =fffffffe, r10=c5b895ac, r11=ef2ccae0 > > > r12=00000000, ssp=ef2cca90, slr=c0604148, pc =c0628a60 > > > > > > [ thread pid 83 tid 100050 ] > > > Stopped at pmap_remove_pages+0x270: streq r3, [r0, > #0x030] > > > db> bt > > > Tracing pid 83 tid 100050 td 0xc5bc4320 > > > db_trace_self() at db_trace_self > > > pc = 0xc061f62c lr = 0xc024ddbc (db_hex2dec+0x498) > > > sp = 0xef2cc738 fp = 0xef2cc750 > > > r10 = 0xc0708270 > > > db_hex2dec() at db_hex2dec+0x498 > > > pc = 0xc024ddbc lr = 0xc024d76c (db_command_loop+0x2f0) > > > sp = 0xef2cc758 fp = 0xef2cc7f8 > > > r4 = 0x00000000 r5 = 0x00000000 > > > r6 = 0xc0695cf1 > > > db_command_loop() at db_command_loop+0x2f0 > > > pc = 0xc024d76c lr = 0xc024d4dc (db_command_loop+0x60) > > > sp = 0xef2cc800 fp = 0xef2cc810 > > > r4 = 0xc0666f88 r5 = 0xc067b997 > > > r6 = 0xc0752954 r7 = 0xc0748f80 > > > r8 = 0xef2cca40 r9 = 0xc07084e0 > > > r10 = 0xc0748f84 > > > db_command_loop() at db_command_loop+0x60 > > > pc = 0xc024d4dc lr = 0xc024ffb8 (X_db_symbol_values+0x254) > > > sp = 0xef2cc818 fp = 0xef2cc938 > > > r4 = 0x00000000 r5 = 0xef2cc820 > > > r6 = 0xc0748fb0 > > > X_db_symbol_values() at X_db_symbol_values+0x254 > > > pc = 0xc024ffb8 lr = 0xc0430554 (kdb_trap+0x164) > > > sp = 0xef2cc940 fp = 0xef2cc968 > > > r4 = 0x00000000 r5 = 0x00000817 > > > r6 = 0xc0748fb0 r7 = 0xc0748f80 > > > kdb_trap() at kdb_trap+0x164 > > > pc = 0xc0430554 lr = 0xc0632ef0 (data_abort_handler+0x7dc) > > > sp = 0xef2cc970 fp = 0xef2cc988 > > > r4 = 0xef2cca40 r5 = 0x600000d3 > > > r6 = 0x00000030 r7 = 0x00000817 > > > r8 = 0xc5b894f0 r9 = 0x00000001 > > > r10 = 0xef2cca40 > > > data_abort_handler() at data_abort_handler+0x7dc > > > pc = 0xc0632ef0 lr = 0xc0632cc0 (data_abort_handler+0x5ac) > > > sp = 0xef2cc990 fp = 0xef2cca38 > > > r4 = 0x00000817 r5 = 0xc5bc4320 > > > r6 = 0xc5a47a0c r7 = 0x00000004 > > > data_abort_handler() at data_abort_handler+0x5ac > > > pc = 0xc0632cc0 lr = 0xc0621214 (exception_exit) > > > sp = 0xef2cca40 fp = 0xef2ccae0 > > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > > > r6 = 0xc5b05800 r7 = 0xc5b895ac > > > r8 = 0xc320a044 r9 = 0xfffffffe > > > r10 = 0xc5b895ac > > > exception_exit() at exception_exit > > > pc = 0xc0621214 lr = 0xc0604148 (PHYS_TO_VM_PAGE+0x48) > > > sp = 0xef2cca94 fp = 0xef2ccae0 > > > r0 = 0x00000000 r1 = 0xc320a048 > > > r2 = 0x00000000 r3 = 0xc3208074 > > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > > > r6 = 0xc5b05800 r7 = 0xc5b895ac > > > r8 = 0xc320a044 r9 = 0xfffffffe > > > r10 = 0xc5b895ac r12 = 0x00000000 > > > pmap_remove_pages() at pmap_remove_pages+0x270 > > > pc = 0xc0628a60 lr = 0xc05f2d08 (vmspace_exit+0xd8) > > > sp = 0xef2ccae8 fp = 0xef2ccb10 > > > r4 = 0xc5b895a8 r5 = 0xc5bc4320 > > > r6 = 0x00000001 r7 = 0xc5a47960 > > > r8 = 0xc5b895ac r9 = 0xc5b894f0 > > > r10 = 0xc0753be0 > > > vmspace_exit() at vmspace_exit+0xd8 > > > pc = 0xc05f2d08 lr = 0xc03a7348 (exit1+0x930) > > > sp = 0xef2ccb18 fp = 0xef2ccb70 > > > r4 = 0xc5a479fc r5 = 0x00000004 > > > r6 = 0xc583861c r7 = 0x00000001 > > > r8 = 0xc5a47960 r9 = 0xc5bc4320 > > > r10 = 0xc5a47a0c > > > exit1() at exit1+0x930 > > > pc = 0xc03a7348 lr = 0xc03f1604 (sigexit+0x8c4) > > > sp = 0xef2ccb78 fp = 0xef2ccd68 > > > r4 = 0x00000002 r5 = 0xc5bc4320 > > > r6 = 0xc5a47960 r7 = 0xc5a47a0c > > > r8 = 0xc5bc4320 r9 = 0xc5b7a000 > > > r10 = 0x00000002 > > > sigexit() at sigexit+0x8c4 > > > pc = 0xc03f1604 lr = 0xc03f23a0 (postsig+0x39c) > > > sp = 0xef2ccd70 fp = 0xef2cce18 > > > r4 = 0x00000001 r5 = 0xc5bc4320 > > > r6 = 0xc5a47960 r7 = 0xc5b7aab8 > > > r8 = 0xc5a47a0c r9 = 0xc5b7a000 > > > r10 = 0x00000002 > > > postsig() at postsig+0x39c > > > pc = 0xc03f23a0 lr = 0xc044388c (ast+0x4f4) > > > sp = 0xef2cce20 fp = 0xef2cce58 > > > r4 = 0x00000001 r5 = 0xc5bc4320 > > > r6 = 0xc5a47960 r7 = 0xc5a47a0c > > > r8 = 0xc5a47a0c r9 = 0x01020804 > > > r10 = 0x00000ab8 > > > ast() at ast+0x4f4 > > > pc = 0xc044388c lr = 0xc0621080 (swi_entry+0x6c) > > > sp = 0xef2cce60 fp = 0xbfffe438 > > > r4 = 0x40000013 r5 = 0xc5bc4320 > > > r6 = 0x00000001 r7 = 0x00000154 > > > r8 = 0x20037008 r9 = 0xbfffee5c > > > r10 = 0xbfffea10 > > > swi_entry() at swi_entry+0x6c > > > pc = 0xc0621080 lr = 0xc0621080 (swi_entry+0x6c) > > > sp = 0xef2cce60 fp = 0xbfffe438 > > > Unable to unwind further > > > db> > > > > > > > > > > > > 2014-03-22 14:20 GMT+01:00 Ian Lepore : > > > > > > On Fri, 2014-03-21 at 07:20 +0100, Wojciech Macek wrote: > > >> > No, changing flushD to flushID did not make any difference, but I > think > > >> it > > >> > should be there - D-only flushing might not be sufficient. > > >> > > > >> > > >> Olivier reminded me right after I posted that: last week I made a > change > > >> to cpufunc.c that makes flushD and flushID the same. So of course it > > >> made no difference. :) It really should be flushID though, in case > > >> that ever changes. > > >> > > >> You didn't say whether you have that change, which was r263251. > > >> > > >> > Currently, I'm running pmap_kernel_internal attached below. It is > doing > > >> > unconditional flushID at the end, just like the old comment was > saying > > >> :) > > >> > SMP seems to be stable. > > >> > > > >> > > >> That seems to say that somehow there is a valid TLB entry even though > > >> the old pte for that entry is zero. That means there's a problem > > >> somewhere else in the code, but I don't see it. It looks to me like > we > > >> do a TLB flush everywhere that we zero out a pte. > > >> > > >> You said without the unconditional flush it panics at startup. Where > in > > >> startup? Early, or after init is launched or what? Where does the > > >> panic backtrace to? > > >> > > >> If we've got some other pte/tlb maintenance problem, I'd hate to hide > it > > >> with this unconditional flush and have it appear as some other problem > > >> later that will be even harder to track down. > > >> > > >> -- Ian > > >> > > >> > > >> > > > > > > From owner-freebsd-arm@FreeBSD.ORG Thu Mar 27 13:45:38 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B1A4AE4 for ; Thu, 27 Mar 2014 13:45:38 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0ACF4200 for ; Thu, 27 Mar 2014 13:45:37 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WTAcc-000MUM-VX; Thu, 27 Mar 2014 13:45:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2RDjR9E078726; Thu, 27 Mar 2014 07:45:27 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+dy52zogqqbDKhF/66iHyB Subject: Re: arm SMP on Cortex-A15 From: Ian Lepore To: Wojciech Macek In-Reply-To: References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> <1395494401.81853.34.camel@revolution.hippie.lan> <1395754555.81853.65.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 2014 07:45:27 -0600 Message-ID: <1395927927.81853.92.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 13:45:38 -0000 The r263251 changes are not a workaround, they are a required fix. There are really two things happening in 263251... The first, and absolutely required, part of the change is that the arm11 functions for TLB maintenance won't work on armv7 with MP extensions. The instructions used in the arm11 tlb maintenance are not the new "Inner Sharable" functions that broadcast the TLB operation to the other cores. I think that may be at the root of the problem you're seeing. The second part of the change, the part I'm not quite as sure about, is my interpretation of the ARM ARM in regard to unified versus separate TLBs. The way I read it, "Invalidate unified TLB by MVA Inner Sharable" (TLBIMVAAIS) invalidates both the data and instruction TLB entries if they are separate. My evidence for that is that there are no separate TLB operations that broadcast the maintenance operations through the inner sharable domain, there are only the unified ops. And then there are these two items after the table of operations in section B3.12.34 CP15 c8, TLB maintenance operations: * If an Instruction TLB or Data TLB operation is used on a system that implements a Unified TLB then the operation is performed on the Unified TLB * If a Unified TLB operation is used on a system that implements separate Instruction and Data TLBs then the operation is performed on both the Instruction TLB and the Data TLB. In other words, it looks to me like ARM's intent is to remove the distinction between separate and unified TLBs when it comes to maintenance ops, but for now they've left the old opcodes in place for compatibility with old non-SMP code. But for SMP you have to use the new unified ops, because they haven't provided "Inner Sharable" flavors of the separate-TLB ops. So in r263251 the flushI and flushD and flushID vectors all point to the flushID function, and that means we use the unified-inner-sharable operations for SMP, and I think the only potential downside to doing it that way is that in the flushD case we're also doing a flush of the branch target cache that doesn't really need to happen; that's probably a minor performance hit but not a correctness problem. -- Ian On Thu, 2014-03-27 at 14:10 +0100, Wojciech Macek wrote: > I started cleaning up and have some concerns. Sorry guys, the r263251 still > looks like a workaround to me :) > The fact that TLB cache issue is seen only on executable pages and that > Olivier's fix helps suggests, that we are missing flush-I somewhere (crash > appears only when deallocating userspace vm, so my guess is pmap_kremove, > where definitely should be flushID). For test purposes I reverted r263251 > and added additional flushID/flushD logic to the pmap-v6 in > performance-critical sections, or modified flushD to flushID where the > speed is not the case. All changes integrated with previous patches can be > found here: > https://drive.google.com/file/d/0B-7yTLrPxaWtRFRHTUtpZ3VKbG8/edit?usp=sharing > With above patch I'm able to run all tests without any problems. > > Maybe it would be better to fix these suspicious places in pmap instead? > > Regards, > Wojtek > > > 2014-03-25 14:35 GMT+01:00 Ian Lepore : > > > Good, that means we can stop searching for the missing tlb flush when a > > pte is invalidated. :) You guys can commit whenever you're ready (or I > > can do it if you'd like). > > > > -- Ian > > > > On Tue, 2014-03-25 at 11:14 +0100, Wojciech Macek wrote: > > > Hi Ian, > > > > > > The r263251 fix helped, thanks! > > > So now, if you don';t have any objections, I will clean up a little the > > > cpufunc.S & pmap-v6 changes and make them ready for submitting. > > > > > > Regards, > > > Wojtek > > > > > > > > > 2014-03-24 14:31 GMT+01:00 Wojciech Macek : > > > > > > > Without the unconditional invalidation, the panic shows up just at the > > > > beginning, after rootfs is mounted and init scripts are running. When a > > > > userspace process is exitting, its memory resources are freed - this > > is the > > > > moment pmap_remove_pages fails due to tharanslation fault. It is the > > > > "typical" crash I observed when TLB-cache holds an old entry. Below > > there > > > > is a backtrace, but I doubt if it can be helpful. > > > > > > > > Regarding old pte/tlb, the TLB cache contains entry from old process > > > > context, when in-memory-PTE value is already correct - at least this > > was > > > > the scenario when I debugged it last year. So, invalidating after > > *pte=0 is > > > > definitely not our case. The issue shows up only on a15, where the > > > > tlb-prefetcher can cache pte entries anytime. > > > > > > > > I believe I don't have r263251 integrated. I'll give it a try - > > typically, > > > > the tlb-caused crash appears only on pages containing shared libraries > > code > > > > (with executable attr), so there is a chance Olivier's fix help. > > > > > > > > > > > > The fault: > > > > > > > > vm_fault(0xc5b894f0, 0, 2, 0) -> 1 > > > > Fatal kernel mode data abort: 'Translation Fault (P)' > > > > trapframe: 0xef2cca40 > > > > FSR=00000817, FAR=00000030, spsr=60000013 > > > > r0 =00000000, r1 =c320a048, r2 =00000000, r3 =c3208074 > > > > r4 =c5b7cd08, r5 =c5b7cd04, r6 =c5b05800, r7 =c5b895ac > > > > r8 =c320a044, r9 =fffffffe, r10=c5b895ac, r11=ef2ccae0 > > > > r12=00000000, ssp=ef2cca90, slr=c0604148, pc =c0628a60 > > > > > > > > [ thread pid 83 tid 100050 ] > > > > Stopped at pmap_remove_pages+0x270: streq r3, [r0, > > #0x030] > > > > db> bt > > > > Tracing pid 83 tid 100050 td 0xc5bc4320 > > > > db_trace_self() at db_trace_self > > > > pc = 0xc061f62c lr = 0xc024ddbc (db_hex2dec+0x498) > > > > sp = 0xef2cc738 fp = 0xef2cc750 > > > > r10 = 0xc0708270 > > > > db_hex2dec() at db_hex2dec+0x498 > > > > pc = 0xc024ddbc lr = 0xc024d76c (db_command_loop+0x2f0) > > > > sp = 0xef2cc758 fp = 0xef2cc7f8 > > > > r4 = 0x00000000 r5 = 0x00000000 > > > > r6 = 0xc0695cf1 > > > > db_command_loop() at db_command_loop+0x2f0 > > > > pc = 0xc024d76c lr = 0xc024d4dc (db_command_loop+0x60) > > > > sp = 0xef2cc800 fp = 0xef2cc810 > > > > r4 = 0xc0666f88 r5 = 0xc067b997 > > > > r6 = 0xc0752954 r7 = 0xc0748f80 > > > > r8 = 0xef2cca40 r9 = 0xc07084e0 > > > > r10 = 0xc0748f84 > > > > db_command_loop() at db_command_loop+0x60 > > > > pc = 0xc024d4dc lr = 0xc024ffb8 (X_db_symbol_values+0x254) > > > > sp = 0xef2cc818 fp = 0xef2cc938 > > > > r4 = 0x00000000 r5 = 0xef2cc820 > > > > r6 = 0xc0748fb0 > > > > X_db_symbol_values() at X_db_symbol_values+0x254 > > > > pc = 0xc024ffb8 lr = 0xc0430554 (kdb_trap+0x164) > > > > sp = 0xef2cc940 fp = 0xef2cc968 > > > > r4 = 0x00000000 r5 = 0x00000817 > > > > r6 = 0xc0748fb0 r7 = 0xc0748f80 > > > > kdb_trap() at kdb_trap+0x164 > > > > pc = 0xc0430554 lr = 0xc0632ef0 (data_abort_handler+0x7dc) > > > > sp = 0xef2cc970 fp = 0xef2cc988 > > > > r4 = 0xef2cca40 r5 = 0x600000d3 > > > > r6 = 0x00000030 r7 = 0x00000817 > > > > r8 = 0xc5b894f0 r9 = 0x00000001 > > > > r10 = 0xef2cca40 > > > > data_abort_handler() at data_abort_handler+0x7dc > > > > pc = 0xc0632ef0 lr = 0xc0632cc0 (data_abort_handler+0x5ac) > > > > sp = 0xef2cc990 fp = 0xef2cca38 > > > > r4 = 0x00000817 r5 = 0xc5bc4320 > > > > r6 = 0xc5a47a0c r7 = 0x00000004 > > > > data_abort_handler() at data_abort_handler+0x5ac > > > > pc = 0xc0632cc0 lr = 0xc0621214 (exception_exit) > > > > sp = 0xef2cca40 fp = 0xef2ccae0 > > > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > > > > r6 = 0xc5b05800 r7 = 0xc5b895ac > > > > r8 = 0xc320a044 r9 = 0xfffffffe > > > > r10 = 0xc5b895ac > > > > exception_exit() at exception_exit > > > > pc = 0xc0621214 lr = 0xc0604148 (PHYS_TO_VM_PAGE+0x48) > > > > sp = 0xef2cca94 fp = 0xef2ccae0 > > > > r0 = 0x00000000 r1 = 0xc320a048 > > > > r2 = 0x00000000 r3 = 0xc3208074 > > > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > > > > r6 = 0xc5b05800 r7 = 0xc5b895ac > > > > r8 = 0xc320a044 r9 = 0xfffffffe > > > > r10 = 0xc5b895ac r12 = 0x00000000 > > > > pmap_remove_pages() at pmap_remove_pages+0x270 > > > > pc = 0xc0628a60 lr = 0xc05f2d08 (vmspace_exit+0xd8) > > > > sp = 0xef2ccae8 fp = 0xef2ccb10 > > > > r4 = 0xc5b895a8 r5 = 0xc5bc4320 > > > > r6 = 0x00000001 r7 = 0xc5a47960 > > > > r8 = 0xc5b895ac r9 = 0xc5b894f0 > > > > r10 = 0xc0753be0 > > > > vmspace_exit() at vmspace_exit+0xd8 > > > > pc = 0xc05f2d08 lr = 0xc03a7348 (exit1+0x930) > > > > sp = 0xef2ccb18 fp = 0xef2ccb70 > > > > r4 = 0xc5a479fc r5 = 0x00000004 > > > > r6 = 0xc583861c r7 = 0x00000001 > > > > r8 = 0xc5a47960 r9 = 0xc5bc4320 > > > > r10 = 0xc5a47a0c > > > > exit1() at exit1+0x930 > > > > pc = 0xc03a7348 lr = 0xc03f1604 (sigexit+0x8c4) > > > > sp = 0xef2ccb78 fp = 0xef2ccd68 > > > > r4 = 0x00000002 r5 = 0xc5bc4320 > > > > r6 = 0xc5a47960 r7 = 0xc5a47a0c > > > > r8 = 0xc5bc4320 r9 = 0xc5b7a000 > > > > r10 = 0x00000002 > > > > sigexit() at sigexit+0x8c4 > > > > pc = 0xc03f1604 lr = 0xc03f23a0 (postsig+0x39c) > > > > sp = 0xef2ccd70 fp = 0xef2cce18 > > > > r4 = 0x00000001 r5 = 0xc5bc4320 > > > > r6 = 0xc5a47960 r7 = 0xc5b7aab8 > > > > r8 = 0xc5a47a0c r9 = 0xc5b7a000 > > > > r10 = 0x00000002 > > > > postsig() at postsig+0x39c > > > > pc = 0xc03f23a0 lr = 0xc044388c (ast+0x4f4) > > > > sp = 0xef2cce20 fp = 0xef2cce58 > > > > r4 = 0x00000001 r5 = 0xc5bc4320 > > > > r6 = 0xc5a47960 r7 = 0xc5a47a0c > > > > r8 = 0xc5a47a0c r9 = 0x01020804 > > > > r10 = 0x00000ab8 > > > > ast() at ast+0x4f4 > > > > pc = 0xc044388c lr = 0xc0621080 (swi_entry+0x6c) > > > > sp = 0xef2cce60 fp = 0xbfffe438 > > > > r4 = 0x40000013 r5 = 0xc5bc4320 > > > > r6 = 0x00000001 r7 = 0x00000154 > > > > r8 = 0x20037008 r9 = 0xbfffee5c > > > > r10 = 0xbfffea10 > > > > swi_entry() at swi_entry+0x6c > > > > pc = 0xc0621080 lr = 0xc0621080 (swi_entry+0x6c) > > > > sp = 0xef2cce60 fp = 0xbfffe438 > > > > Unable to unwind further > > > > db> > > > > > > > > > > > > > > > > 2014-03-22 14:20 GMT+01:00 Ian Lepore : > > > > > > > > On Fri, 2014-03-21 at 07:20 +0100, Wojciech Macek wrote: > > > >> > No, changing flushD to flushID did not make any difference, but I > > think > > > >> it > > > >> > should be there - D-only flushing might not be sufficient. > > > >> > > > > >> > > > >> Olivier reminded me right after I posted that: last week I made a > > change > > > >> to cpufunc.c that makes flushD and flushID the same. So of course it > > > >> made no difference. :) It really should be flushID though, in case > > > >> that ever changes. > > > >> > > > >> You didn't say whether you have that change, which was r263251. > > > >> > > > >> > Currently, I'm running pmap_kernel_internal attached below. It is > > doing > > > >> > unconditional flushID at the end, just like the old comment was > > saying > > > >> :) > > > >> > SMP seems to be stable. > > > >> > > > > >> > > > >> That seems to say that somehow there is a valid TLB entry even though > > > >> the old pte for that entry is zero. That means there's a problem > > > >> somewhere else in the code, but I don't see it. It looks to me like > > we > > > >> do a TLB flush everywhere that we zero out a pte. > > > >> > > > >> You said without the unconditional flush it panics at startup. Where > > in > > > >> startup? Early, or after init is launched or what? Where does the > > > >> panic backtrace to? > > > >> > > > >> If we've got some other pte/tlb maintenance problem, I'd hate to hide > > it > > > >> with this unconditional flush and have it appear as some other problem > > > >> later that will be even harder to track down. > > > >> > > > >> -- Ian > > > >> > > > >> > > > >> > > > > > > > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Mar 27 13:54:12 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73D99C6B for ; Thu, 27 Mar 2014 13:54:12 +0000 (UTC) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 394092AF for ; Thu, 27 Mar 2014 13:54:12 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1WTAl0-004Ooa-Au; Thu, 27 Mar 2014 14:54:10 +0100 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Ralf Wenk To: arm@freebsd.org Subject: screen(1) crashes plus weird output for screen -ls Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Mar 2014 14:54:10 +0100 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 13:54:12 -0000 Hi, while working with screen(1) it dumps core very often on arm. Using gdb on the core shows (gdb) bt =230 0x2029bc18 in strlen () from /lib/libc.so.7 =231 0x0001e9a4 in ?? () (gdb) as the last function called every time. Interestingly the output of =22screen -ls=22 is a little bit weird an loo= ks There is a screen on: 814.ttyu0.rpi (Attached) -1073746664 Socket =D0=A0=E1 in =B0=F5=FF=BF8=E8. instead of the expected=20 There is a screen on: 814.ttyu0.rpi (Attached) 1 Socket in /tmp/screens/S-root /tmp is a tmpfs. kernel and world are from a fresh checked-out r263766. screen(1) is newly compiled with clang from that version an pk info shows= =5B...=5D Name : screen Version : 4.0.3_14 Installed on : Wed Mar 26 16:07:57 CET 2014 Origin : sysutils/screen Architecture : freebsd:11:armv6:32:el:eabi:softfp =5B...=5D ktrace/kdump verified that the weird =22Socket=22 line(s) are already in = the write(2) buffer. As screen(1) on i386 does not dump core and =22screen -ls=22 shows the ex= pected output I think this is a arm related problem. Ralf From owner-freebsd-arm@FreeBSD.ORG Thu Mar 27 14:25:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D75382E for ; Thu, 27 Mar 2014 14:25:09 +0000 (UTC) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3691837 for ; Thu, 27 Mar 2014 14:25:08 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id if17so4236063vcb.36 for ; Thu, 27 Mar 2014 07:25:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XZwZGCPusbjS9Fl/M1nJHblKw1Ewr/DxPX9C8ciBgSw=; b=g0YvGJFiBiBIZeqM/zdf6KVdx/CQXSATVAIPdqw22C7wzTh/4Ubw4LiVED7wGYl3ed zYCZZrIANmqG85K3Wpaw0rwkfzIQX5gyiKtiW97vhKMFTi3Zn0ibnCaqDDgPDmQQuTaH +HWYoEIFdCyogVUxVYC9Tt22PdeNuZ+3cHl8WcbUSlaoclX0bz1leVl05Vh4qmeGXOpq BQcQ83FjMVZ3FF65s8eB8hg1NiVEI1KUc1zN3Al8a9U1rzBneHgAWAJ/Ja/aaeqCAFOD zDxU2WB+v6Aa7PxWHTR0N1CGZLlJ9YSPqhEW229o3WBv4PU/hi1UJhbGvPGq7r8AYm/8 ZDZA== X-Gm-Message-State: ALoCoQlGGLWVvjwSz9gZq1PGlIUwc3D1aIUYAfe1r6KGzHCYXd4GCR5IQ3MJaitdSZz1IeasxjJb MIME-Version: 1.0 X-Received: by 10.58.195.202 with SMTP id ig10mr626979vec.33.1395926847479; Thu, 27 Mar 2014 06:27:27 -0700 (PDT) Received: by 10.220.209.135 with HTTP; Thu, 27 Mar 2014 06:27:27 -0700 (PDT) In-Reply-To: References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> <1395494401.81853.34.camel@revolution.hippie.lan> <1395754555.81853.65.camel@revolution.hippie.lan> Date: Thu, 27 Mar 2014 14:27:27 +0100 Message-ID: Subject: Re: arm SMP on Cortex-A15 From: Wojciech Macek To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:25:09 -0000 Sorry, I meant https://drive.google.com/file/d/0B-7yTLrPxaWtRjJvTzJZY3g5akU/edit?usp=sharing W. 2014-03-27 14:10 GMT+01:00 Wojciech Macek : > I started cleaning up and have some concerns. Sorry guys, the r263251 > still looks like a workaround to me :) > The fact that TLB cache issue is seen only on executable pages and that > Olivier's fix helps suggests, that we are missing flush-I somewhere (crash > appears only when deallocating userspace vm, so my guess is pmap_kremove, > where definitely should be flushID). For test purposes I reverted r263251 > and added additional flushID/flushD logic to the pmap-v6 in > performance-critical sections, or modified flushD to flushID where the > speed is not the case. All changes integrated with previous patches can be > found here: > > https://drive.google.com/file/d/0B-7yTLrPxaWtRFRHTUtpZ3VKbG8/edit?usp=sharing > With above patch I'm able to run all tests without any problems. > > Maybe it would be better to fix these suspicious places in pmap instead? > > Regards, > Wojtek > > > 2014-03-25 14:35 GMT+01:00 Ian Lepore : > > Good, that means we can stop searching for the missing tlb flush when a >> pte is invalidated. :) You guys can commit whenever you're ready (or I >> can do it if you'd like). >> >> -- Ian >> >> On Tue, 2014-03-25 at 11:14 +0100, Wojciech Macek wrote: >> > Hi Ian, >> > >> > The r263251 fix helped, thanks! >> > So now, if you don';t have any objections, I will clean up a little the >> > cpufunc.S & pmap-v6 changes and make them ready for submitting. >> > >> > Regards, >> > Wojtek >> > >> > >> > 2014-03-24 14:31 GMT+01:00 Wojciech Macek : >> > >> > > Without the unconditional invalidation, the panic shows up just at the >> > > beginning, after rootfs is mounted and init scripts are running. When >> a >> > > userspace process is exitting, its memory resources are freed - this >> is the >> > > moment pmap_remove_pages fails due to tharanslation fault. It is the >> > > "typical" crash I observed when TLB-cache holds an old entry. Below >> there >> > > is a backtrace, but I doubt if it can be helpful. >> > > >> > > Regarding old pte/tlb, the TLB cache contains entry from old process >> > > context, when in-memory-PTE value is already correct - at least this >> was >> > > the scenario when I debugged it last year. So, invalidating after >> *pte=0 is >> > > definitely not our case. The issue shows up only on a15, where the >> > > tlb-prefetcher can cache pte entries anytime. >> > > >> > > I believe I don't have r263251 integrated. I'll give it a try - >> typically, >> > > the tlb-caused crash appears only on pages containing shared >> libraries code >> > > (with executable attr), so there is a chance Olivier's fix help. >> > > >> > > >> > > The fault: >> > > >> > > vm_fault(0xc5b894f0, 0, 2, 0) -> 1 >> > > Fatal kernel mode data abort: 'Translation Fault (P)' >> > > trapframe: 0xef2cca40 >> > > FSR=00000817, FAR=00000030, spsr=60000013 >> > > r0 =00000000, r1 =c320a048, r2 =00000000, r3 =c3208074 >> > > r4 =c5b7cd08, r5 =c5b7cd04, r6 =c5b05800, r7 =c5b895ac >> > > r8 =c320a044, r9 =fffffffe, r10=c5b895ac, r11=ef2ccae0 >> > > r12=00000000, ssp=ef2cca90, slr=c0604148, pc =c0628a60 >> > > >> > > [ thread pid 83 tid 100050 ] >> > > Stopped at pmap_remove_pages+0x270: streq r3, [r0, >> #0x030] >> > > db> bt >> > > Tracing pid 83 tid 100050 td 0xc5bc4320 >> > > db_trace_self() at db_trace_self >> > > pc = 0xc061f62c lr = 0xc024ddbc (db_hex2dec+0x498) >> > > sp = 0xef2cc738 fp = 0xef2cc750 >> > > r10 = 0xc0708270 >> > > db_hex2dec() at db_hex2dec+0x498 >> > > pc = 0xc024ddbc lr = 0xc024d76c (db_command_loop+0x2f0) >> > > sp = 0xef2cc758 fp = 0xef2cc7f8 >> > > r4 = 0x00000000 r5 = 0x00000000 >> > > r6 = 0xc0695cf1 >> > > db_command_loop() at db_command_loop+0x2f0 >> > > pc = 0xc024d76c lr = 0xc024d4dc (db_command_loop+0x60) >> > > sp = 0xef2cc800 fp = 0xef2cc810 >> > > r4 = 0xc0666f88 r5 = 0xc067b997 >> > > r6 = 0xc0752954 r7 = 0xc0748f80 >> > > r8 = 0xef2cca40 r9 = 0xc07084e0 >> > > r10 = 0xc0748f84 >> > > db_command_loop() at db_command_loop+0x60 >> > > pc = 0xc024d4dc lr = 0xc024ffb8 (X_db_symbol_values+0x254) >> > > sp = 0xef2cc818 fp = 0xef2cc938 >> > > r4 = 0x00000000 r5 = 0xef2cc820 >> > > r6 = 0xc0748fb0 >> > > X_db_symbol_values() at X_db_symbol_values+0x254 >> > > pc = 0xc024ffb8 lr = 0xc0430554 (kdb_trap+0x164) >> > > sp = 0xef2cc940 fp = 0xef2cc968 >> > > r4 = 0x00000000 r5 = 0x00000817 >> > > r6 = 0xc0748fb0 r7 = 0xc0748f80 >> > > kdb_trap() at kdb_trap+0x164 >> > > pc = 0xc0430554 lr = 0xc0632ef0 (data_abort_handler+0x7dc) >> > > sp = 0xef2cc970 fp = 0xef2cc988 >> > > r4 = 0xef2cca40 r5 = 0x600000d3 >> > > r6 = 0x00000030 r7 = 0x00000817 >> > > r8 = 0xc5b894f0 r9 = 0x00000001 >> > > r10 = 0xef2cca40 >> > > data_abort_handler() at data_abort_handler+0x7dc >> > > pc = 0xc0632ef0 lr = 0xc0632cc0 (data_abort_handler+0x5ac) >> > > sp = 0xef2cc990 fp = 0xef2cca38 >> > > r4 = 0x00000817 r5 = 0xc5bc4320 >> > > r6 = 0xc5a47a0c r7 = 0x00000004 >> > > data_abort_handler() at data_abort_handler+0x5ac >> > > pc = 0xc0632cc0 lr = 0xc0621214 (exception_exit) >> > > sp = 0xef2cca40 fp = 0xef2ccae0 >> > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 >> > > r6 = 0xc5b05800 r7 = 0xc5b895ac >> > > r8 = 0xc320a044 r9 = 0xfffffffe >> > > r10 = 0xc5b895ac >> > > exception_exit() at exception_exit >> > > pc = 0xc0621214 lr = 0xc0604148 (PHYS_TO_VM_PAGE+0x48) >> > > sp = 0xef2cca94 fp = 0xef2ccae0 >> > > r0 = 0x00000000 r1 = 0xc320a048 >> > > r2 = 0x00000000 r3 = 0xc3208074 >> > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 >> > > r6 = 0xc5b05800 r7 = 0xc5b895ac >> > > r8 = 0xc320a044 r9 = 0xfffffffe >> > > r10 = 0xc5b895ac r12 = 0x00000000 >> > > pmap_remove_pages() at pmap_remove_pages+0x270 >> > > pc = 0xc0628a60 lr = 0xc05f2d08 (vmspace_exit+0xd8) >> > > sp = 0xef2ccae8 fp = 0xef2ccb10 >> > > r4 = 0xc5b895a8 r5 = 0xc5bc4320 >> > > r6 = 0x00000001 r7 = 0xc5a47960 >> > > r8 = 0xc5b895ac r9 = 0xc5b894f0 >> > > r10 = 0xc0753be0 >> > > vmspace_exit() at vmspace_exit+0xd8 >> > > pc = 0xc05f2d08 lr = 0xc03a7348 (exit1+0x930) >> > > sp = 0xef2ccb18 fp = 0xef2ccb70 >> > > r4 = 0xc5a479fc r5 = 0x00000004 >> > > r6 = 0xc583861c r7 = 0x00000001 >> > > r8 = 0xc5a47960 r9 = 0xc5bc4320 >> > > r10 = 0xc5a47a0c >> > > exit1() at exit1+0x930 >> > > pc = 0xc03a7348 lr = 0xc03f1604 (sigexit+0x8c4) >> > > sp = 0xef2ccb78 fp = 0xef2ccd68 >> > > r4 = 0x00000002 r5 = 0xc5bc4320 >> > > r6 = 0xc5a47960 r7 = 0xc5a47a0c >> > > r8 = 0xc5bc4320 r9 = 0xc5b7a000 >> > > r10 = 0x00000002 >> > > sigexit() at sigexit+0x8c4 >> > > pc = 0xc03f1604 lr = 0xc03f23a0 (postsig+0x39c) >> > > sp = 0xef2ccd70 fp = 0xef2cce18 >> > > r4 = 0x00000001 r5 = 0xc5bc4320 >> > > r6 = 0xc5a47960 r7 = 0xc5b7aab8 >> > > r8 = 0xc5a47a0c r9 = 0xc5b7a000 >> > > r10 = 0x00000002 >> > > postsig() at postsig+0x39c >> > > pc = 0xc03f23a0 lr = 0xc044388c (ast+0x4f4) >> > > sp = 0xef2cce20 fp = 0xef2cce58 >> > > r4 = 0x00000001 r5 = 0xc5bc4320 >> > > r6 = 0xc5a47960 r7 = 0xc5a47a0c >> > > r8 = 0xc5a47a0c r9 = 0x01020804 >> > > r10 = 0x00000ab8 >> > > ast() at ast+0x4f4 >> > > pc = 0xc044388c lr = 0xc0621080 (swi_entry+0x6c) >> > > sp = 0xef2cce60 fp = 0xbfffe438 >> > > r4 = 0x40000013 r5 = 0xc5bc4320 >> > > r6 = 0x00000001 r7 = 0x00000154 >> > > r8 = 0x20037008 r9 = 0xbfffee5c >> > > r10 = 0xbfffea10 >> > > swi_entry() at swi_entry+0x6c >> > > pc = 0xc0621080 lr = 0xc0621080 (swi_entry+0x6c) >> > > sp = 0xef2cce60 fp = 0xbfffe438 >> > > Unable to unwind further >> > > db> >> > > >> > > >> > > >> > > 2014-03-22 14:20 GMT+01:00 Ian Lepore : >> > > >> > > On Fri, 2014-03-21 at 07:20 +0100, Wojciech Macek wrote: >> > >> > No, changing flushD to flushID did not make any difference, but I >> think >> > >> it >> > >> > should be there - D-only flushing might not be sufficient. >> > >> > >> > >> >> > >> Olivier reminded me right after I posted that: last week I made a >> change >> > >> to cpufunc.c that makes flushD and flushID the same. So of course it >> > >> made no difference. :) It really should be flushID though, in case >> > >> that ever changes. >> > >> >> > >> You didn't say whether you have that change, which was r263251. >> > >> >> > >> > Currently, I'm running pmap_kernel_internal attached below. It is >> doing >> > >> > unconditional flushID at the end, just like the old comment was >> saying >> > >> :) >> > >> > SMP seems to be stable. >> > >> > >> > >> >> > >> That seems to say that somehow there is a valid TLB entry even though >> > >> the old pte for that entry is zero. That means there's a problem >> > >> somewhere else in the code, but I don't see it. It looks to me like >> we >> > >> do a TLB flush everywhere that we zero out a pte. >> > >> >> > >> You said without the unconditional flush it panics at startup. >> Where in >> > >> startup? Early, or after init is launched or what? Where does the >> > >> panic backtrace to? >> > >> >> > >> If we've got some other pte/tlb maintenance problem, I'd hate to >> hide it >> > >> with this unconditional flush and have it appear as some other >> problem >> > >> later that will be even harder to track down. >> > >> >> > >> -- Ian >> > >> >> > >> >> > >> >> > > >> >> >> > From owner-freebsd-arm@FreeBSD.ORG Thu Mar 27 15:35:16 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4BCB2A8; Thu, 27 Mar 2014 15:35:16 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D983EEB9; Thu, 27 Mar 2014 15:35:15 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s2RFZ0Yd074443; Thu, 27 Mar 2014 17:35:00 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s2RFZ0fm074322; Thu, 27 Mar 2014 15:35:00 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 27 Mar 2014 15:35:00 GMT Message-Id: <201403271535.s2RFZ0fm074322@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:35:16 -0000 TB --- 2014-03-27 11:10:44 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-03-27 11:10:44 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-27 11:10:44 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-03-27 11:10:44 - cleaning the object tree TB --- 2014-03-27 11:10:44 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-27 11:11:34 - At svn revision 263811 TB --- 2014-03-27 11:11:35 - building world TB --- 2014-03-27 11:11:35 - CROSS_BUILD_TESTING=YES TB --- 2014-03-27 11:11:35 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-27 11:11:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-27 11:11:35 - SRCCONF=/dev/null TB --- 2014-03-27 11:11:35 - TARGET=arm TB --- 2014-03-27 11:11:35 - TARGET_ARCH=arm TB --- 2014-03-27 11:11:35 - TZ=UTC TB --- 2014-03-27 11:11:35 - __MAKE_CONF=/dev/null TB --- 2014-03-27 11:11:35 - cd /src TB --- 2014-03-27 11:11:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 27 11:11:46 UTC 2014 >>> 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 Thu Mar 27 14:50:04 UTC 2014 TB --- 2014-03-27 14:50:04 - generating LINT kernel config TB --- 2014-03-27 14:50:04 - cd /src/sys/arm/conf TB --- 2014-03-27 14:50:04 - /usr/bin/make -B LINT TB --- 2014-03-27 14:50:04 - cd /src/sys/arm/conf TB --- 2014-03-27 14:50:04 - /usr/sbin/config -m LINT TB --- 2014-03-27 14:50:04 - building LINT kernel TB --- 2014-03-27 14:50:04 - CROSS_BUILD_TESTING=YES TB --- 2014-03-27 14:50:04 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-27 14:50:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-27 14:50:04 - SRCCONF=/dev/null TB --- 2014-03-27 14:50:04 - TARGET=arm TB --- 2014-03-27 14:50:04 - TARGET_ARCH=arm TB --- 2014-03-27 14:50:04 - TZ=UTC TB --- 2014-03-27 14:50:04 - __MAKE_CONF=/dev/null TB --- 2014-03-27 14:50:04 - cd /src TB --- 2014-03-27 14:50:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 27 14:50:04 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Mar 27 15:16:24 UTC 2014 TB --- 2014-03-27 15:16:24 - cd /src/sys/arm/conf TB --- 2014-03-27 15:16:24 - /usr/sbin/config -m AC100 TB --- 2014-03-27 15:16:24 - skipping AC100 kernel TB --- 2014-03-27 15:16:24 - cd /src/sys/arm/conf TB --- 2014-03-27 15:16:24 - /usr/sbin/config -m ARMADAXP TB --- 2014-03-27 15:16:24 - skipping ARMADAXP kernel TB --- 2014-03-27 15:16:24 - cd /src/sys/arm/conf TB --- 2014-03-27 15:16:24 - /usr/sbin/config -m ARNDALE TB --- 2014-03-27 15:16:24 - skipping ARNDALE kernel TB --- 2014-03-27 15:16:24 - cd /src/sys/arm/conf TB --- 2014-03-27 15:16:24 - /usr/sbin/config -m ATMEL TB --- 2014-03-27 15:16:24 - building ATMEL kernel TB --- 2014-03-27 15:16:24 - CROSS_BUILD_TESTING=YES TB --- 2014-03-27 15:16:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-27 15:16:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-27 15:16:24 - SRCCONF=/dev/null TB --- 2014-03-27 15:16:24 - TARGET=arm TB --- 2014-03-27 15:16:24 - TARGET_ARCH=arm TB --- 2014-03-27 15:16:24 - TZ=UTC TB --- 2014-03-27 15:16:24 - __MAKE_CONF=/dev/null TB --- 2014-03-27 15:16:24 - cd /src TB --- 2014-03-27 15:16:24 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Thu Mar 27 15:16:24 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Thu Mar 27 15:20:38 UTC 2014 TB --- 2014-03-27 15:20:38 - cd /src/sys/arm/conf TB --- 2014-03-27 15:20:38 - /usr/sbin/config -m AVILA TB --- 2014-03-27 15:20:38 - skipping AVILA kernel TB --- 2014-03-27 15:20:38 - cd /src/sys/arm/conf TB --- 2014-03-27 15:20:38 - /usr/sbin/config -m BEAGLEBONE TB --- 2014-03-27 15:20:38 - skipping BEAGLEBONE kernel TB --- 2014-03-27 15:20:38 - cd /src/sys/arm/conf TB --- 2014-03-27 15:20:38 - /usr/sbin/config -m BWCT TB --- 2014-03-27 15:20:38 - building BWCT kernel TB --- 2014-03-27 15:20:38 - CROSS_BUILD_TESTING=YES TB --- 2014-03-27 15:20:38 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-27 15:20:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-27 15:20:38 - SRCCONF=/dev/null TB --- 2014-03-27 15:20:38 - TARGET=arm TB --- 2014-03-27 15:20:38 - TARGET_ARCH=arm TB --- 2014-03-27 15:20:38 - TZ=UTC TB --- 2014-03-27 15:20:38 - __MAKE_CONF=/dev/null TB --- 2014-03-27 15:20:38 - cd /src TB --- 2014-03-27 15:20:38 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Thu Mar 27 15:20:38 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Thu Mar 27 15:23:33 UTC 2014 TB --- 2014-03-27 15:23:33 - cd /src/sys/arm/conf TB --- 2014-03-27 15:23:33 - /usr/sbin/config -m CAMBRIA TB --- 2014-03-27 15:23:33 - skipping CAMBRIA kernel TB --- 2014-03-27 15:23:33 - cd /src/sys/arm/conf TB --- 2014-03-27 15:23:33 - /usr/sbin/config -m CNS11XXNAS TB --- 2014-03-27 15:23:33 - building CNS11XXNAS kernel TB --- 2014-03-27 15:23:33 - CROSS_BUILD_TESTING=YES TB --- 2014-03-27 15:23:33 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-27 15:23:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-27 15:23:33 - SRCCONF=/dev/null TB --- 2014-03-27 15:23:33 - TARGET=arm TB --- 2014-03-27 15:23:33 - TARGET_ARCH=arm TB --- 2014-03-27 15:23:33 - TZ=UTC TB --- 2014-03-27 15:23:33 - __MAKE_CONF=/dev/null TB --- 2014-03-27 15:23:33 - cd /src TB --- 2014-03-27 15:23:33 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Thu Mar 27 15:23:34 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Thu Mar 27 15:27:42 UTC 2014 TB --- 2014-03-27 15:27:42 - cd /src/sys/arm/conf TB --- 2014-03-27 15:27:42 - /usr/sbin/config -m CRB TB --- 2014-03-27 15:27:42 - skipping CRB kernel TB --- 2014-03-27 15:27:42 - cd /src/sys/arm/conf TB --- 2014-03-27 15:27:42 - /usr/sbin/config -m CUBIEBOARD TB --- 2014-03-27 15:27:42 - skipping CUBIEBOARD kernel TB --- 2014-03-27 15:27:42 - cd /src/sys/arm/conf TB --- 2014-03-27 15:27:42 - /usr/sbin/config -m CUBIEBOARD2 TB --- 2014-03-27 15:27:42 - skipping CUBIEBOARD2 kernel TB --- 2014-03-27 15:27:42 - cd /src/sys/arm/conf TB --- 2014-03-27 15:27:42 - /usr/sbin/config -m DB-78XXX TB --- 2014-03-27 15:27:42 - building DB-78XXX kernel TB --- 2014-03-27 15:27:42 - CROSS_BUILD_TESTING=YES TB --- 2014-03-27 15:27:42 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-27 15:27:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-27 15:27:42 - SRCCONF=/dev/null TB --- 2014-03-27 15:27:42 - TARGET=arm TB --- 2014-03-27 15:27:42 - TARGET_ARCH=arm TB --- 2014-03-27 15:27:42 - TZ=UTC TB --- 2014-03-27 15:27:42 - __MAKE_CONF=/dev/null TB --- 2014-03-27 15:27:42 - cd /src TB --- 2014-03-27 15:27:42 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Thu Mar 27 15:27:42 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Thu Mar 27 15:31:23 UTC 2014 TB --- 2014-03-27 15:31:23 - cd /src/sys/arm/conf TB --- 2014-03-27 15:31:23 - /usr/sbin/config -m DB-88F5XXX TB --- 2014-03-27 15:31:23 - building DB-88F5XXX kernel TB --- 2014-03-27 15:31:23 - CROSS_BUILD_TESTING=YES TB --- 2014-03-27 15:31:23 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-27 15:31:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-27 15:31:23 - SRCCONF=/dev/null TB --- 2014-03-27 15:31:23 - TARGET=arm TB --- 2014-03-27 15:31:23 - TARGET_ARCH=arm TB --- 2014-03-27 15:31:23 - TZ=UTC TB --- 2014-03-27 15:31:23 - __MAKE_CONF=/dev/null TB --- 2014-03-27 15:31:23 - cd /src TB --- 2014-03-27 15:31:23 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Thu Mar 27 15:31:23 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Thu Mar 27 15:34:58 UTC 2014 TB --- 2014-03-27 15:34:58 - cd /src/sys/arm/conf TB --- 2014-03-27 15:34:58 - /usr/sbin/config -m DB-88F6XXX TB --- 2014-03-27 15:34:58 - building DB-88F6XXX kernel TB --- 2014-03-27 15:34:58 - CROSS_BUILD_TESTING=YES TB --- 2014-03-27 15:34:58 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-27 15:34:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-27 15:34:58 - SRCCONF=/dev/null TB --- 2014-03-27 15:34:58 - TARGET=arm TB --- 2014-03-27 15:34:58 - TARGET_ARCH=arm TB --- 2014-03-27 15:34:58 - TZ=UTC TB --- 2014-03-27 15:34:58 - __MAKE_CONF=/dev/null TB --- 2014-03-27 15:34:58 - cd /src TB --- 2014-03-27 15:34:58 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Thu Mar 27 15:34:58 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools [...] yacc -b aicasm_macro_gram -p mm -d -o aicasm_macro_gram.c /src/sys/dev/aic7xxx/aicasm/aicasm_macro_gram.y cc -O2 -pipe -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -c /src/sys/dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -c /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c: In function 'symtable_dump': /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c:461: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/DB-88F6XXX *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-03-27 15:34:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-27 15:34:59 - ERROR: failed to build DB-88F6XXX kernel TB --- 2014-03-27 15:34:59 - 11854.50 user 3938.27 system 15854.46 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Mar 28 01:10:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BAC6998; Fri, 28 Mar 2014 01:10:15 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F387198; Fri, 28 Mar 2014 01:10:15 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id uy17so239698igb.9 for ; Thu, 27 Mar 2014 18:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/afRAZHIg8M3DkTrWGt/xSP9kpVk7081kQ52s4lpfQQ=; b=Elo3rOMlWH9U6bDU8wqFTl9z171qFrTAsKAIOqeydzTHlKUSOKs0kcO4yzkiuhPadB Kr7efqndB24HrSc0R+XyyMiuiBcX6lEzABBJb268i7Co6fCwl8sZQ2IUu3EupFBVpr+q YJzteorNKKAgOaHoocMtTrgUjAIJu9kEzUbPn6Hc8GvCjl1DW/biYgiXFWL+3Wnb+nar cxtZhrdil9Vr984IOe+rVqhqFpyQwhps0WOgSu8fquj7HtJhU4cdDxQwrWuxkhSwDvBr nqp1/MB6EhSVAinGmD3SRKYRbJuwbb4piH7Fu1CGPdtwhLLsUYWXAafZNnkdd52aHFII 2+hw== MIME-Version: 1.0 X-Received: by 10.42.50.3 with SMTP id y3mr5335802icf.12.1395969014690; Thu, 27 Mar 2014 18:10:14 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Thu, 27 Mar 2014 18:10:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Mar 2014 09:10:14 +0800 Message-ID: Subject: Re: Jetson TK1 from nVidia ships in April, pre-order started From: Ganbold Tsagaankhuu To: "Lundberg, Johannes" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" , freebsd-embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 01:10:15 -0000 On Thu, Mar 27, 2014 at 10:48 AM, Lundberg, Johannes < johannes@brilliantservice.co.jp> wrote: > Hi > > Just noticed that K1 development board from nVidia has been publicly > announced. > > https://developer.nvidia.com/jetson-tk1 > > It would enable some really cool applications if we could achieve two > things > > 1) Get FreeBSD running on TK1 including HDMI graphical output support > 2) Get nVidia to add native CUDA support for FreeBSD > > Think we can make this happen? > I'm not sure how good its documentation or how open it is. By reading incomplete doc and looking through linux/android source code makes slower development, sometimes waste of time, at least in my case. In terms of tegra SoC, we have tegra code bits in src tree, however it seems not complete. On the other hand, definitely we should try to bring FreeBSD on newer ARM boards, and it seems this board is fast, which could bring us some nice possibilities like port/package buildings. There may be exist some possibilities to build ports using qemu or some other sort of emulation technics, however that doesn't mean we should stop bringing new SoC/board supports. Last but not least, we lack developers working on ARM platforms. But all above is just my opinion, so correct me if I'm wrong here. regards, Ganbold > > Best regards > -- > Johannes Lundberg > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B > $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B > $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B > --- > CONFIDENTIALITY NOTE: The information in this email is confidential > and intended solely for the addressee. > Disclosure, copying, distribution or any other action of use of this > email by person other than intended recipient, is prohibited. > If you are not the intended recipient and have received this email in > error, please destroy the original message. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Fri Mar 28 01:30:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EE46FBB; Fri, 28 Mar 2014 01:30:32 +0000 (UTC) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E562326; Fri, 28 Mar 2014 01:30:32 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id e89so172578qgf.0 for ; Thu, 27 Mar 2014 18:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zxfXir/SZygnra9HDOu0GSJqyohKyMA2GAd8+5/45UI=; b=Q0herf7XxOZQoW29Uso/kC4MGrJzG65g55m5ACxuhD5/ZA5JkFG2M0d5B9y7tE7vdE U7q7c0J5WqfQ/k4RFmW6oPjpXyeJK6CYz/thl1uIEmyo+UihR0sOgm9GOvnQCIq2hI0L 3u2YzCzaSRXzIDrpEk5b/L7O/W9geLtiAFUCy39InYFAj+2AgMDK7vODv3vqqqTmTyZg g7XtrnErkL9+8c/7Ott8MHdbK3gAnZ8OwQem+3gtRl0AhiXGmfTRAlARgI+t0zwueEPE rARyIDMCX2Pzczi2TOWgU45y7M3nXDRfOdcXV7TnUE1U98fkEYvndRWonQjyBx0xS8mk zLJg== MIME-Version: 1.0 X-Received: by 10.224.74.201 with SMTP id v9mr93137qaj.94.1395970230260; Thu, 27 Mar 2014 18:30:30 -0700 (PDT) Received: by 10.224.50.143 with HTTP; Thu, 27 Mar 2014 18:30:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Mar 2014 18:30:30 -0700 Message-ID: Subject: Re: Jetson TK1 from nVidia ships in April, pre-order started From: Adrian Chadd To: "Lundberg, Johannes" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 01:30:32 -0000 I think the best way to get this going is to get a freebsd ARM developer on contract to just knock this stuff out and commit it to FreeBSD-HEAD. -a On 26 March 2014 19:48, Lundberg, Johannes wrote: > Hi > > Just noticed that K1 development board from nVidia has been publicly > announced. > > https://developer.nvidia.com/jetson-tk1 > > It would enable some really cool applications if we could achieve two things > > 1) Get FreeBSD running on TK1 including HDMI graphical output support > 2) Get nVidia to add native CUDA support for FreeBSD > > Think we can make this happen? > > Best regards > -- > Johannes Lundberg > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B > $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B > $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B > --- > CONFIDENTIALITY NOTE: The information in this email is confidential > and intended solely for the addressee. > Disclosure, copying, distribution or any other action of use of this > email by person other than intended recipient, is prohibited. > If you are not the intended recipient and have received this email in > error, please destroy the original message. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Mar 28 12:07:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED5E058A; Fri, 28 Mar 2014 12:07:42 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 903CF2A6; Fri, 28 Mar 2014 12:07:42 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wn1so5874504obc.30 for ; Fri, 28 Mar 2014 05:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ydhA8mVjtwKMwA5VCqJrFCzR82AXPTcaBE3OyG0A/E8=; b=UwESrqmznh0jR3rE1HDRqEDGmvvCph0Uch6JhT47pozoq3QO9OGSP8g7D0h/Eg9b1x K9SOtgxbE29YVu69yg7quOIz/VmqA++JjF5nvv77ZSQiCZx+TIDl4Liw93Mtd0VgMI/B xPsF8Bk8XqOybTb2OfTQjaoCFCSljfevSjjfUEOaWUD73XMuwviMTQJVMVBPEigCgsHg zP5/tWcYgOQT5QbpcY+ybhAQx7KzeFbFpxAftHPKAOPbA2goxx43cOihjmzpqc3aR0eq 0PSMQpIhrqeWm3l+385KsRLJivv9910Pu73iR7TIuU5C4UhAu7QFCAtSrjrAs3eekW6t 77YQ== MIME-Version: 1.0 X-Received: by 10.60.44.42 with SMTP id b10mr12934oem.70.1396008461868; Fri, 28 Mar 2014 05:07:41 -0700 (PDT) Received: by 10.60.227.194 with HTTP; Fri, 28 Mar 2014 05:07:41 -0700 (PDT) In-Reply-To: <28B91494-CCBB-4050-8E01-7B2BF0C4ABC9@freebsd.org> References: <20140326224443.GN60889@funkthat.com> <28B91494-CCBB-4050-8E01-7B2BF0C4ABC9@freebsd.org> Date: Fri, 28 Mar 2014 09:07:41 -0300 Message-ID: Subject: Re: Cross-compiling a kernel module? From: Martin Galvan To: Stanislav Sedov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org, freebsd-drivers@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 12:07:43 -0000 Works like a charm. Thanks a lot guys! 2014-03-27 1:52 GMT-03:00 Stanislav Sedov : > > On Mar 26, 2014, at 3:44 PM, John-Mark Gurney wrote: > > > $ cd $SRC > > $ make kernel-toolchain TARGET_ARCH=armXX > > $ make buildenv TARGET_ARCH=armXX BUILDENV_SHELL=/usr/local/bin/shell > > $ cd > > $ make > > > > The buildenv command sets up the new shell with an environment that is > > the same as if you were running under a buildkernel or buildworld > > environment.. You can use this to build one off programs like bin/ls > > too. > > Don't forget to set the KERNBUILDDIR option as well to point to your > kernel object dir so the module will pick up all the right options. > > -- > ST4096-RIPE > > > > From owner-freebsd-arm@FreeBSD.ORG Fri Mar 28 16:51:20 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03AB9CAA; Fri, 28 Mar 2014 16:51:20 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB88239E; Fri, 28 Mar 2014 16:51:19 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WTZzy-000ADk-9j; Fri, 28 Mar 2014 16:51:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2SGpG54080154; Fri, 28 Mar 2014 10:51:16 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Xwgxuk55TbEssvL3f1W/s Subject: Re: Raspberry pi 11 Current panic From: Ian Lepore To: jungleboogie0 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 2014 10:51:16 -0600 Message-ID: <1396025476.81853.147.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 16:51:20 -0000 On Tue, 2014-03-25 at 16:32 -0700, jungleboogie0 wrote: > And now to the group: > > > U-Boot 2013.01-rc1-svn18531 (Mar 24 2014 - 09:11:00) [...] > > > > > > I grabbed 11-CURRENT for raspberry pi here: > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 > > > > > > Booted up my pi and I'm trying to run vnstat but this occurs: > > > > > > root@raspberry-pi:~ # vmstat > > > procs memory page disks faults > > cpu > > > r b w avm fpanic: mutex process lock not owned at > > > /usr/src/sys/kern/kern_sig.c:2874 > > > KDB: enter: panic > > > [ thread pid 747 tid 100063 ] > > > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > > > > > So far I've been able to do this 3 times in a row by simply logging in > > and > > > typing vmstat. > > > > > > Is this expected behavior? > > > It took me a while to get around to this, but I can confirm that if you download the r263665 rpi image it behaves exactly as shown. On the other hand, if I build r263665 locally and boot from it I have no problems, but that's with an NFS root filesystem so it's not quite an identical test. The actual problem that causes the panic appears to be secondary fallout from an attempt to kill the process because of a floating point exception in supervisor mode. I think we have another mail thread about a similar problem. The kernel isn't supposed to be using floating point hardware, so I'll look into that. I have a vague suspicion we may be accidentally using an instruction not supported by the vfp version in the rpi while saving/restoring the state or something like that. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Mar 28 23:12:48 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28980F44 for ; Fri, 28 Mar 2014 23:12:48 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAD9E17F for ; Fri, 28 Mar 2014 23:12:47 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WTfx8-000CKf-B4; Fri, 28 Mar 2014 23:12:46 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2SNCh9R080508; Fri, 28 Mar 2014 17:12:43 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19qQYbjzLEFqLEzKgEjj7vX Subject: Re: arm SMP on Cortex-A15 From: Ian Lepore To: Wojciech Macek In-Reply-To: References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> <1395494401.81853.34.camel@revolution.hippie.lan> <1395754555.81853.65.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 2014 17:12:43 -0600 Message-ID: <1396048363.81853.177.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 23:12:48 -0000 I finally got around to looking at your latest patch. Some comments... I think the changes to use ID flush in the following functions can't possibly be needed, because the memory in question is page table entries or other things that cannot be executable: pmap_l2ptp_ctor(), pmap_grow_map(), pmap_growkernel(), pmap_copy_page_generic(), pmap_copy_pages(). The change in vector_page_setprot() is probably unnecessary, but harmless. There is no need for the L2_S_EXECUTABLE() check -- we just forced it to be executable on the previous line. In pmap_postinit() I'm pretty sure an ID flush isn't needed, but harmless since it's only called once at startup In general, since flushD and flushID are the same code none of these changes is bad right now. There may come a day when we want to remove the BTB flush in the the flushD case for performance, and having a bunch of routines calling flushID when flushD is all that's really needed will mean that someone will have to do all this analysis again to actually get any performance benefit. -- Ian On Thu, 2014-03-27 at 14:27 +0100, Wojciech Macek wrote: > Sorry, I meant > https://drive.google.com/file/d/0B-7yTLrPxaWtRjJvTzJZY3g5akU/edit?usp=sharing > > W. > > > 2014-03-27 14:10 GMT+01:00 Wojciech Macek : > > > I started cleaning up and have some concerns. Sorry guys, the r263251 > > still looks like a workaround to me :) > > The fact that TLB cache issue is seen only on executable pages and that > > Olivier's fix helps suggests, that we are missing flush-I somewhere (crash > > appears only when deallocating userspace vm, so my guess is pmap_kremove, > > where definitely should be flushID). For test purposes I reverted r263251 > > and added additional flushID/flushD logic to the pmap-v6 in > > performance-critical sections, or modified flushD to flushID where the > > speed is not the case. All changes integrated with previous patches can be > > found here: > > > > https://drive.google.com/file/d/0B-7yTLrPxaWtRFRHTUtpZ3VKbG8/edit?usp=sharing > > With above patch I'm able to run all tests without any problems. > > > > Maybe it would be better to fix these suspicious places in pmap instead? > > > > Regards, > > Wojtek > > > > > > 2014-03-25 14:35 GMT+01:00 Ian Lepore : > > > > Good, that means we can stop searching for the missing tlb flush when a > >> pte is invalidated. :) You guys can commit whenever you're ready (or I > >> can do it if you'd like). > >> > >> -- Ian > >> > >> On Tue, 2014-03-25 at 11:14 +0100, Wojciech Macek wrote: > >> > Hi Ian, > >> > > >> > The r263251 fix helped, thanks! > >> > So now, if you don';t have any objections, I will clean up a little the > >> > cpufunc.S & pmap-v6 changes and make them ready for submitting. > >> > > >> > Regards, > >> > Wojtek > >> > > >> > > >> > 2014-03-24 14:31 GMT+01:00 Wojciech Macek : > >> > > >> > > Without the unconditional invalidation, the panic shows up just at the > >> > > beginning, after rootfs is mounted and init scripts are running. When > >> a > >> > > userspace process is exitting, its memory resources are freed - this > >> is the > >> > > moment pmap_remove_pages fails due to tharanslation fault. It is the > >> > > "typical" crash I observed when TLB-cache holds an old entry. Below > >> there > >> > > is a backtrace, but I doubt if it can be helpful. > >> > > > >> > > Regarding old pte/tlb, the TLB cache contains entry from old process > >> > > context, when in-memory-PTE value is already correct - at least this > >> was > >> > > the scenario when I debugged it last year. So, invalidating after > >> *pte=0 is > >> > > definitely not our case. The issue shows up only on a15, where the > >> > > tlb-prefetcher can cache pte entries anytime. > >> > > > >> > > I believe I don't have r263251 integrated. I'll give it a try - > >> typically, > >> > > the tlb-caused crash appears only on pages containing shared > >> libraries code > >> > > (with executable attr), so there is a chance Olivier's fix help. > >> > > > >> > > > >> > > The fault: > >> > > > >> > > vm_fault(0xc5b894f0, 0, 2, 0) -> 1 > >> > > Fatal kernel mode data abort: 'Translation Fault (P)' > >> > > trapframe: 0xef2cca40 > >> > > FSR=00000817, FAR=00000030, spsr=60000013 > >> > > r0 =00000000, r1 =c320a048, r2 =00000000, r3 =c3208074 > >> > > r4 =c5b7cd08, r5 =c5b7cd04, r6 =c5b05800, r7 =c5b895ac > >> > > r8 =c320a044, r9 =fffffffe, r10=c5b895ac, r11=ef2ccae0 > >> > > r12=00000000, ssp=ef2cca90, slr=c0604148, pc =c0628a60 > >> > > > >> > > [ thread pid 83 tid 100050 ] > >> > > Stopped at pmap_remove_pages+0x270: streq r3, [r0, > >> #0x030] > >> > > db> bt > >> > > Tracing pid 83 tid 100050 td 0xc5bc4320 > >> > > db_trace_self() at db_trace_self > >> > > pc = 0xc061f62c lr = 0xc024ddbc (db_hex2dec+0x498) > >> > > sp = 0xef2cc738 fp = 0xef2cc750 > >> > > r10 = 0xc0708270 > >> > > db_hex2dec() at db_hex2dec+0x498 > >> > > pc = 0xc024ddbc lr = 0xc024d76c (db_command_loop+0x2f0) > >> > > sp = 0xef2cc758 fp = 0xef2cc7f8 > >> > > r4 = 0x00000000 r5 = 0x00000000 > >> > > r6 = 0xc0695cf1 > >> > > db_command_loop() at db_command_loop+0x2f0 > >> > > pc = 0xc024d76c lr = 0xc024d4dc (db_command_loop+0x60) > >> > > sp = 0xef2cc800 fp = 0xef2cc810 > >> > > r4 = 0xc0666f88 r5 = 0xc067b997 > >> > > r6 = 0xc0752954 r7 = 0xc0748f80 > >> > > r8 = 0xef2cca40 r9 = 0xc07084e0 > >> > > r10 = 0xc0748f84 > >> > > db_command_loop() at db_command_loop+0x60 > >> > > pc = 0xc024d4dc lr = 0xc024ffb8 (X_db_symbol_values+0x254) > >> > > sp = 0xef2cc818 fp = 0xef2cc938 > >> > > r4 = 0x00000000 r5 = 0xef2cc820 > >> > > r6 = 0xc0748fb0 > >> > > X_db_symbol_values() at X_db_symbol_values+0x254 > >> > > pc = 0xc024ffb8 lr = 0xc0430554 (kdb_trap+0x164) > >> > > sp = 0xef2cc940 fp = 0xef2cc968 > >> > > r4 = 0x00000000 r5 = 0x00000817 > >> > > r6 = 0xc0748fb0 r7 = 0xc0748f80 > >> > > kdb_trap() at kdb_trap+0x164 > >> > > pc = 0xc0430554 lr = 0xc0632ef0 (data_abort_handler+0x7dc) > >> > > sp = 0xef2cc970 fp = 0xef2cc988 > >> > > r4 = 0xef2cca40 r5 = 0x600000d3 > >> > > r6 = 0x00000030 r7 = 0x00000817 > >> > > r8 = 0xc5b894f0 r9 = 0x00000001 > >> > > r10 = 0xef2cca40 > >> > > data_abort_handler() at data_abort_handler+0x7dc > >> > > pc = 0xc0632ef0 lr = 0xc0632cc0 (data_abort_handler+0x5ac) > >> > > sp = 0xef2cc990 fp = 0xef2cca38 > >> > > r4 = 0x00000817 r5 = 0xc5bc4320 > >> > > r6 = 0xc5a47a0c r7 = 0x00000004 > >> > > data_abort_handler() at data_abort_handler+0x5ac > >> > > pc = 0xc0632cc0 lr = 0xc0621214 (exception_exit) > >> > > sp = 0xef2cca40 fp = 0xef2ccae0 > >> > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > >> > > r6 = 0xc5b05800 r7 = 0xc5b895ac > >> > > r8 = 0xc320a044 r9 = 0xfffffffe > >> > > r10 = 0xc5b895ac > >> > > exception_exit() at exception_exit > >> > > pc = 0xc0621214 lr = 0xc0604148 (PHYS_TO_VM_PAGE+0x48) > >> > > sp = 0xef2cca94 fp = 0xef2ccae0 > >> > > r0 = 0x00000000 r1 = 0xc320a048 > >> > > r2 = 0x00000000 r3 = 0xc3208074 > >> > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > >> > > r6 = 0xc5b05800 r7 = 0xc5b895ac > >> > > r8 = 0xc320a044 r9 = 0xfffffffe > >> > > r10 = 0xc5b895ac r12 = 0x00000000 > >> > > pmap_remove_pages() at pmap_remove_pages+0x270 > >> > > pc = 0xc0628a60 lr = 0xc05f2d08 (vmspace_exit+0xd8) > >> > > sp = 0xef2ccae8 fp = 0xef2ccb10 > >> > > r4 = 0xc5b895a8 r5 = 0xc5bc4320 > >> > > r6 = 0x00000001 r7 = 0xc5a47960 > >> > > r8 = 0xc5b895ac r9 = 0xc5b894f0 > >> > > r10 = 0xc0753be0 > >> > > vmspace_exit() at vmspace_exit+0xd8 > >> > > pc = 0xc05f2d08 lr = 0xc03a7348 (exit1+0x930) > >> > > sp = 0xef2ccb18 fp = 0xef2ccb70 > >> > > r4 = 0xc5a479fc r5 = 0x00000004 > >> > > r6 = 0xc583861c r7 = 0x00000001 > >> > > r8 = 0xc5a47960 r9 = 0xc5bc4320 > >> > > r10 = 0xc5a47a0c > >> > > exit1() at exit1+0x930 > >> > > pc = 0xc03a7348 lr = 0xc03f1604 (sigexit+0x8c4) > >> > > sp = 0xef2ccb78 fp = 0xef2ccd68 > >> > > r4 = 0x00000002 r5 = 0xc5bc4320 > >> > > r6 = 0xc5a47960 r7 = 0xc5a47a0c > >> > > r8 = 0xc5bc4320 r9 = 0xc5b7a000 > >> > > r10 = 0x00000002 > >> > > sigexit() at sigexit+0x8c4 > >> > > pc = 0xc03f1604 lr = 0xc03f23a0 (postsig+0x39c) > >> > > sp = 0xef2ccd70 fp = 0xef2cce18 > >> > > r4 = 0x00000001 r5 = 0xc5bc4320 > >> > > r6 = 0xc5a47960 r7 = 0xc5b7aab8 > >> > > r8 = 0xc5a47a0c r9 = 0xc5b7a000 > >> > > r10 = 0x00000002 > >> > > postsig() at postsig+0x39c > >> > > pc = 0xc03f23a0 lr = 0xc044388c (ast+0x4f4) > >> > > sp = 0xef2cce20 fp = 0xef2cce58 > >> > > r4 = 0x00000001 r5 = 0xc5bc4320 > >> > > r6 = 0xc5a47960 r7 = 0xc5a47a0c > >> > > r8 = 0xc5a47a0c r9 = 0x01020804 > >> > > r10 = 0x00000ab8 > >> > > ast() at ast+0x4f4 > >> > > pc = 0xc044388c lr = 0xc0621080 (swi_entry+0x6c) > >> > > sp = 0xef2cce60 fp = 0xbfffe438 > >> > > r4 = 0x40000013 r5 = 0xc5bc4320 > >> > > r6 = 0x00000001 r7 = 0x00000154 > >> > > r8 = 0x20037008 r9 = 0xbfffee5c > >> > > r10 = 0xbfffea10 > >> > > swi_entry() at swi_entry+0x6c > >> > > pc = 0xc0621080 lr = 0xc0621080 (swi_entry+0x6c) > >> > > sp = 0xef2cce60 fp = 0xbfffe438 > >> > > Unable to unwind further > >> > > db> > >> > > > >> > > > >> > > > >> > > 2014-03-22 14:20 GMT+01:00 Ian Lepore : > >> > > > >> > > On Fri, 2014-03-21 at 07:20 +0100, Wojciech Macek wrote: > >> > >> > No, changing flushD to flushID did not make any difference, but I > >> think > >> > >> it > >> > >> > should be there - D-only flushing might not be sufficient. > >> > >> > > >> > >> > >> > >> Olivier reminded me right after I posted that: last week I made a > >> change > >> > >> to cpufunc.c that makes flushD and flushID the same. So of course it > >> > >> made no difference. :) It really should be flushID though, in case > >> > >> that ever changes. > >> > >> > >> > >> You didn't say whether you have that change, which was r263251. > >> > >> > >> > >> > Currently, I'm running pmap_kernel_internal attached below. It is > >> doing > >> > >> > unconditional flushID at the end, just like the old comment was > >> saying > >> > >> :) > >> > >> > SMP seems to be stable. > >> > >> > > >> > >> > >> > >> That seems to say that somehow there is a valid TLB entry even though > >> > >> the old pte for that entry is zero. That means there's a problem > >> > >> somewhere else in the code, but I don't see it. It looks to me like > >> we > >> > >> do a TLB flush everywhere that we zero out a pte. > >> > >> > >> > >> You said without the unconditional flush it panics at startup. > >> Where in > >> > >> startup? Early, or after init is launched or what? Where does the > >> > >> panic backtrace to? > >> > >> > >> > >> If we've got some other pte/tlb maintenance problem, I'd hate to > >> hide it > >> > >> with this unconditional flush and have it appear as some other > >> problem > >> > >> later that will be even harder to track down. > >> > >> > >> > >> -- Ian > >> > >> > >> > >> > >> > >> > >> > > > >> > >> > >> > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Mar 29 14:43:27 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 276DEECD; Sat, 29 Mar 2014 14:43:27 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0804D98E; Sat, 29 Mar 2014 14:43:26 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 5ABED5DEBC; Sat, 29 Mar 2014 14:43:19 +0000 (UTC) Date: Sat, 29 Mar 2014 14:43:12 +0000 From: Andrew Turner To: Ian Lepore Subject: Re: Raspberry pi 11 Current panic Message-ID: <20140329144312.47a1372b@bender.Home> In-Reply-To: <1396025476.81853.147.camel@revolution.hippie.lan> References: <1396025476.81853.147.camel@revolution.hippie.lan> 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 14:43:27 -0000 On Fri, 28 Mar 2014 10:51:16 -0600 Ian Lepore wrote: > On Tue, 2014-03-25 at 16:32 -0700, jungleboogie0 wrote: > > And now to the group: > > > > > > U-Boot 2013.01-rc1-svn18531 (Mar 24 2014 - 09:11:00) > [...] > > > > > > > > I grabbed 11-CURRENT for raspberry pi here: > > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 > > > > > > > > Booted up my pi and I'm trying to run vnstat but this occurs: > > > > > > > > root@raspberry-pi:~ # vmstat > > > > procs memory page disks faults > > > cpu > > > > r b w avm fpanic: mutex process lock not owned at > > > > /usr/src/sys/kern/kern_sig.c:2874 > > > > KDB: enter: panic > > > > [ thread pid 747 tid 100063 ] > > > > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > > > > > > > So far I've been able to do this 3 times in a row by simply > > > > logging in > > > and > > > > typing vmstat. > > > > > > > > Is this expected behavior? > > > > > > It took me a while to get around to this, but I can confirm that if > you download the r263665 rpi image it behaves exactly as shown. On > the other hand, if I build r263665 locally and boot from it I have no > problems, but that's with an NFS root filesystem so it's not quite an > identical test. > > The actual problem that causes the panic appears to be secondary > fallout from an attempt to kill the process because of a floating > point exception in supervisor mode. I think we have another mail > thread about a similar problem. The kernel isn't supposed to be > using floating point hardware, so I'll look into that. I have a > vague suspicion we may be accidentally using an instruction not > supported by the vfp version in the rpi while saving/restoring the > state or something like that. The problem is we were not setting the floating point state correctly and should have been emulating a few instructions in the kernel. I've fixed this in r263913 and added a few other fixes for issues I found in r263914. There are 4 floating point instructions in the kernel, the are to save and restore the floating point registers on context switch. In this case the exception bit wasn't being cleared when it should have causing a second exception when we try to perform the context switch. Andrew From owner-freebsd-arm@FreeBSD.ORG Sat Mar 29 14:44:09 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAFDEFE3 for ; Sat, 29 Mar 2014 14:44:09 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id CFBD8999 for ; Sat, 29 Mar 2014 14:44:09 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 8596D5DEE8; Sat, 29 Mar 2014 14:44:08 +0000 (UTC) Date: Sat, 29 Mar 2014 14:44:03 +0000 From: Andrew Turner To: Ralf Wenk Subject: Re: Experimental TARGET_ARCH armv6hf crashes on my RPi afer some time Message-ID: <20140329144403.536295ab@bender.Home> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 14:44:10 -0000 On Tue, 25 Mar 2014 13:30:35 +0100 Ralf Wenk wrote: > Hi, > > I tried the new experimental TARGET_ARCH armv6hf on my raspberry pi. > World and kernel are build with > make -j 8 -C $SRCROOT MALLOC_PRODUCTION=yes buildworld > make -j 8 -C $SRCROOT KERNCONF=$KERNCONF WITH_FDT=yes buildkernel > and installed over a normal armv6 kernel and world. The release used > was FreeBSD 11.0-CURRENT #0 r263667M. > > Within an hour since boot the system panics with an undefined > floating point instruction in supervisor mode. This should be fixed in r263914. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Mar 31 05:39:10 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 416F5BEE for ; Mon, 31 Mar 2014 05:39:10 +0000 (UTC) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 053D9AFA for ; Mon, 31 Mar 2014 05:39:09 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1WUUw1-00BvWO-19; Mon, 31 Mar 2014 07:39:01 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Ralf Wenk To: Andrew Turner Subject: Re: Experimental TARGET_ARCH armv6hf crashes on my RPi afer some time In-reply-to: <20140329144403.536295ab@bender.Home> References: <20140329144403.536295ab@bender.Home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Mar 2014 07:39:00 +0200 Message-Id: Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 05:39:10 -0000 On Sat, 29 Mar 2014 14:44:03 +0000 Andrew Turner wrote: > On Tue, 25 Mar 2014 13:30:35 +0100 > Ralf Wenk wrote: > > > Hi, > > > > I tried the new experimental TARGET_ARCH armv6hf on my raspberry pi. > > World and kernel are build with > > make -j 8 -C $SRCROOT MALLOC_PRODUCTION=yes buildworld > > make -j 8 -C $SRCROOT KERNCONF=$KERNCONF WITH_FDT=yes buildkernel > > and installed over a normal armv6 kernel and world. The release used > > was FreeBSD 11.0-CURRENT #0 r263667M. > > > > Within an hour since boot the system panics with an undefined > > floating point instruction in supervisor mode. > This should be fixed in r263914. yes it is fixed. The system is doing some work since 8 hours without a crash. uptime(1) shows 7:30AM up 8:02, 2 users, load averages: 0.60, 0.51, 0.41 The immediate panic when invoking systat -vm is also gone. In armv6hf and armv6 as well. Thank you Andrew. Ralf From owner-freebsd-arm@FreeBSD.ORG Mon Mar 31 07:57:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AE0853D for ; Mon, 31 Mar 2014 07:57:04 +0000 (UTC) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19DB683A for ; Mon, 31 Mar 2014 07:57:03 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id hu19so8171212vcb.29 for ; Mon, 31 Mar 2014 00:57:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2oae+dvcCNvQ1nXPBiq/syczK52ALBfVSVEyQ20UJvI=; b=GgUvnjMjjmbhkK9l7dh5M0XJEU3O4DZi0ZSgsBKytFNMfZe2uadPPPA2MyjHoZklnA COHTRLVnDApCN7fBWxRTc+/Tja6jiQDrXwHvrIUai0bnggpnpbU2SxkrcQecFbNkzohB fip/1zt6GTE2sk6W/c4Y11wGuoAco8jaTy8CAZ4i6oHlFvvC2OEfnipPkCHDs6X0vl/k 8DF6W4aOHxipM3coHMtiBmyZ+MicO4oEnMQFVeZOlvDJMdPuQMR+OXM5umUy+q0/te5C X2bt9oNyPClmX6blcYCUMCLw8jzkvUm4a1iC5gbev6Dc/ObxbVDqI+1JWYbavbtiIrZE a7tA== X-Gm-Message-State: ALoCoQlKBb8J7hNnqFKelPkxqehMdOy1i/T/ElVyAuFg9nH1Z3s0PyMFxV+qxmmtQN/ox4uW8jDF MIME-Version: 1.0 X-Received: by 10.58.23.6 with SMTP id i6mr21388262vef.12.1396250799541; Mon, 31 Mar 2014 00:26:39 -0700 (PDT) Received: by 10.220.209.135 with HTTP; Mon, 31 Mar 2014 00:26:39 -0700 (PDT) In-Reply-To: <1396048363.81853.177.camel@revolution.hippie.lan> References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> <1395494401.81853.34.camel@revolution.hippie.lan> <1395754555.81853.65.camel@revolution.hippie.lan> <1396048363.81853.177.camel@revolution.hippie.lan> Date: Mon, 31 Mar 2014 09:26:39 +0200 Message-ID: Subject: Re: arm SMP on Cortex-A15 From: Wojciech Macek To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 07:57:04 -0000 Sorry for late response. The word "workaround" might have been a little misleading, sorry. Yes, I agree that it is necessary step for armv7-mp, but I was afraid that by accident it can mask code errors. I just want to make sure if what I see in pmap is caused by any missing tlb-inv or not. The Olivier's change stopped the issue reproducing, so that's the reason I reverted it for a while. Well, each panic is an opportunity to make the code working better :) Also, that pmap-v6.c runs on platforms with separate D/I TBL flushing, and that's the reason why I'd like to spend some time debugging. Thanks a lot for comments. I remove the unnecessary lines and only leave changes in pmap_kenter_internal and pmap_kremove, where pages can be executable - it does not change anything for armv7, but might help on R-Pi. I try to close it up this week. Thanks, Wojtek 2014-03-29 0:12 GMT+01:00 Ian Lepore : > I finally got around to looking at your latest patch. Some comments... > > I think the changes to use ID flush in the following functions can't > possibly be needed, because the memory in question is page table entries > or other things that cannot be executable: pmap_l2ptp_ctor(), > pmap_grow_map(), pmap_growkernel(), pmap_copy_page_generic(), > pmap_copy_pages(). > > The change in vector_page_setprot() is probably unnecessary, but > harmless. There is no need for the L2_S_EXECUTABLE() check -- we just > forced it to be executable on the previous line. > > In pmap_postinit() I'm pretty sure an ID flush isn't needed, but > harmless since it's only called once at startup > > In general, since flushD and flushID are the same code none of these > changes is bad right now. There may come a day when we want to remove > the BTB flush in the the flushD case for performance, and having a bunch > of routines calling flushID when flushD is all that's really needed will > mean that someone will have to do all this analysis again to actually > get any performance benefit. > > -- Ian > > On Thu, 2014-03-27 at 14:27 +0100, Wojciech Macek wrote: > > Sorry, I meant > > > https://drive.google.com/file/d/0B-7yTLrPxaWtRjJvTzJZY3g5akU/edit?usp=sharing > > > > W. > > > > > > 2014-03-27 14:10 GMT+01:00 Wojciech Macek : > > > > > I started cleaning up and have some concerns. Sorry guys, the r263251 > > > still looks like a workaround to me :) > > > The fact that TLB cache issue is seen only on executable pages and that > > > Olivier's fix helps suggests, that we are missing flush-I somewhere > (crash > > > appears only when deallocating userspace vm, so my guess is > pmap_kremove, > > > where definitely should be flushID). For test purposes I reverted > r263251 > > > and added additional flushID/flushD logic to the pmap-v6 in > > > performance-critical sections, or modified flushD to flushID where the > > > speed is not the case. All changes integrated with previous patches > can be > > > found here: > > > > > > > https://drive.google.com/file/d/0B-7yTLrPxaWtRFRHTUtpZ3VKbG8/edit?usp=sharing > > > With above patch I'm able to run all tests without any problems. > > > > > > Maybe it would be better to fix these suspicious places in pmap > instead? > > > > > > Regards, > > > Wojtek > > > > > > > > > 2014-03-25 14:35 GMT+01:00 Ian Lepore : > > > > > > Good, that means we can stop searching for the missing tlb flush when a > > >> pte is invalidated. :) You guys can commit whenever you're ready (or > I > > >> can do it if you'd like). > > >> > > >> -- Ian > > >> > > >> On Tue, 2014-03-25 at 11:14 +0100, Wojciech Macek wrote: > > >> > Hi Ian, > > >> > > > >> > The r263251 fix helped, thanks! > > >> > So now, if you don';t have any objections, I will clean up a little > the > > >> > cpufunc.S & pmap-v6 changes and make them ready for submitting. > > >> > > > >> > Regards, > > >> > Wojtek > > >> > > > >> > > > >> > 2014-03-24 14:31 GMT+01:00 Wojciech Macek : > > >> > > > >> > > Without the unconditional invalidation, the panic shows up just > at the > > >> > > beginning, after rootfs is mounted and init scripts are running. > When > > >> a > > >> > > userspace process is exitting, its memory resources are freed - > this > > >> is the > > >> > > moment pmap_remove_pages fails due to tharanslation fault. It is > the > > >> > > "typical" crash I observed when TLB-cache holds an old entry. > Below > > >> there > > >> > > is a backtrace, but I doubt if it can be helpful. > > >> > > > > >> > > Regarding old pte/tlb, the TLB cache contains entry from old > process > > >> > > context, when in-memory-PTE value is already correct - at least > this > > >> was > > >> > > the scenario when I debugged it last year. So, invalidating after > > >> *pte=0 is > > >> > > definitely not our case. The issue shows up only on a15, where the > > >> > > tlb-prefetcher can cache pte entries anytime. > > >> > > > > >> > > I believe I don't have r263251 integrated. I'll give it a try - > > >> typically, > > >> > > the tlb-caused crash appears only on pages containing shared > > >> libraries code > > >> > > (with executable attr), so there is a chance Olivier's fix help. > > >> > > > > >> > > > > >> > > The fault: > > >> > > > > >> > > vm_fault(0xc5b894f0, 0, 2, 0) -> 1 > > >> > > Fatal kernel mode data abort: 'Translation Fault (P)' > > >> > > trapframe: 0xef2cca40 > > >> > > FSR=00000817, FAR=00000030, spsr=60000013 > > >> > > r0 =00000000, r1 =c320a048, r2 =00000000, r3 =c3208074 > > >> > > r4 =c5b7cd08, r5 =c5b7cd04, r6 =c5b05800, r7 =c5b895ac > > >> > > r8 =c320a044, r9 =fffffffe, r10=c5b895ac, r11=ef2ccae0 > > >> > > r12=00000000, ssp=ef2cca90, slr=c0604148, pc =c0628a60 > > >> > > > > >> > > [ thread pid 83 tid 100050 ] > > >> > > Stopped at pmap_remove_pages+0x270: streq r3, [r0, > > >> #0x030] > > >> > > db> bt > > >> > > Tracing pid 83 tid 100050 td 0xc5bc4320 > > >> > > db_trace_self() at db_trace_self > > >> > > pc = 0xc061f62c lr = 0xc024ddbc (db_hex2dec+0x498) > > >> > > sp = 0xef2cc738 fp = 0xef2cc750 > > >> > > r10 = 0xc0708270 > > >> > > db_hex2dec() at db_hex2dec+0x498 > > >> > > pc = 0xc024ddbc lr = 0xc024d76c (db_command_loop+0x2f0) > > >> > > sp = 0xef2cc758 fp = 0xef2cc7f8 > > >> > > r4 = 0x00000000 r5 = 0x00000000 > > >> > > r6 = 0xc0695cf1 > > >> > > db_command_loop() at db_command_loop+0x2f0 > > >> > > pc = 0xc024d76c lr = 0xc024d4dc (db_command_loop+0x60) > > >> > > sp = 0xef2cc800 fp = 0xef2cc810 > > >> > > r4 = 0xc0666f88 r5 = 0xc067b997 > > >> > > r6 = 0xc0752954 r7 = 0xc0748f80 > > >> > > r8 = 0xef2cca40 r9 = 0xc07084e0 > > >> > > r10 = 0xc0748f84 > > >> > > db_command_loop() at db_command_loop+0x60 > > >> > > pc = 0xc024d4dc lr = 0xc024ffb8 > (X_db_symbol_values+0x254) > > >> > > sp = 0xef2cc818 fp = 0xef2cc938 > > >> > > r4 = 0x00000000 r5 = 0xef2cc820 > > >> > > r6 = 0xc0748fb0 > > >> > > X_db_symbol_values() at X_db_symbol_values+0x254 > > >> > > pc = 0xc024ffb8 lr = 0xc0430554 (kdb_trap+0x164) > > >> > > sp = 0xef2cc940 fp = 0xef2cc968 > > >> > > r4 = 0x00000000 r5 = 0x00000817 > > >> > > r6 = 0xc0748fb0 r7 = 0xc0748f80 > > >> > > kdb_trap() at kdb_trap+0x164 > > >> > > pc = 0xc0430554 lr = 0xc0632ef0 > (data_abort_handler+0x7dc) > > >> > > sp = 0xef2cc970 fp = 0xef2cc988 > > >> > > r4 = 0xef2cca40 r5 = 0x600000d3 > > >> > > r6 = 0x00000030 r7 = 0x00000817 > > >> > > r8 = 0xc5b894f0 r9 = 0x00000001 > > >> > > r10 = 0xef2cca40 > > >> > > data_abort_handler() at data_abort_handler+0x7dc > > >> > > pc = 0xc0632ef0 lr = 0xc0632cc0 > (data_abort_handler+0x5ac) > > >> > > sp = 0xef2cc990 fp = 0xef2cca38 > > >> > > r4 = 0x00000817 r5 = 0xc5bc4320 > > >> > > r6 = 0xc5a47a0c r7 = 0x00000004 > > >> > > data_abort_handler() at data_abort_handler+0x5ac > > >> > > pc = 0xc0632cc0 lr = 0xc0621214 (exception_exit) > > >> > > sp = 0xef2cca40 fp = 0xef2ccae0 > > >> > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > > >> > > r6 = 0xc5b05800 r7 = 0xc5b895ac > > >> > > r8 = 0xc320a044 r9 = 0xfffffffe > > >> > > r10 = 0xc5b895ac > > >> > > exception_exit() at exception_exit > > >> > > pc = 0xc0621214 lr = 0xc0604148 (PHYS_TO_VM_PAGE+0x48) > > >> > > sp = 0xef2cca94 fp = 0xef2ccae0 > > >> > > r0 = 0x00000000 r1 = 0xc320a048 > > >> > > r2 = 0x00000000 r3 = 0xc3208074 > > >> > > r4 = 0xc5b7cd08 r5 = 0xc5b7cd04 > > >> > > r6 = 0xc5b05800 r7 = 0xc5b895ac > > >> > > r8 = 0xc320a044 r9 = 0xfffffffe > > >> > > r10 = 0xc5b895ac r12 = 0x00000000 > > >> > > pmap_remove_pages() at pmap_remove_pages+0x270 > > >> > > pc = 0xc0628a60 lr = 0xc05f2d08 (vmspace_exit+0xd8) > > >> > > sp = 0xef2ccae8 fp = 0xef2ccb10 > > >> > > r4 = 0xc5b895a8 r5 = 0xc5bc4320 > > >> > > r6 = 0x00000001 r7 = 0xc5a47960 > > >> > > r8 = 0xc5b895ac r9 = 0xc5b894f0 > > >> > > r10 = 0xc0753be0 > > >> > > vmspace_exit() at vmspace_exit+0xd8 > > >> > > pc = 0xc05f2d08 lr = 0xc03a7348 (exit1+0x930) > > >> > > sp = 0xef2ccb18 fp = 0xef2ccb70 > > >> > > r4 = 0xc5a479fc r5 = 0x00000004 > > >> > > r6 = 0xc583861c r7 = 0x00000001 > > >> > > r8 = 0xc5a47960 r9 = 0xc5bc4320 > > >> > > r10 = 0xc5a47a0c > > >> > > exit1() at exit1+0x930 > > >> > > pc = 0xc03a7348 lr = 0xc03f1604 (sigexit+0x8c4) > > >> > > sp = 0xef2ccb78 fp = 0xef2ccd68 > > >> > > r4 = 0x00000002 r5 = 0xc5bc4320 > > >> > > r6 = 0xc5a47960 r7 = 0xc5a47a0c > > >> > > r8 = 0xc5bc4320 r9 = 0xc5b7a000 > > >> > > r10 = 0x00000002 > > >> > > sigexit() at sigexit+0x8c4 > > >> > > pc = 0xc03f1604 lr = 0xc03f23a0 (postsig+0x39c) > > >> > > sp = 0xef2ccd70 fp = 0xef2cce18 > > >> > > r4 = 0x00000001 r5 = 0xc5bc4320 > > >> > > r6 = 0xc5a47960 r7 = 0xc5b7aab8 > > >> > > r8 = 0xc5a47a0c r9 = 0xc5b7a000 > > >> > > r10 = 0x00000002 > > >> > > postsig() at postsig+0x39c > > >> > > pc = 0xc03f23a0 lr = 0xc044388c (ast+0x4f4) > > >> > > sp = 0xef2cce20 fp = 0xef2cce58 > > >> > > r4 = 0x00000001 r5 = 0xc5bc4320 > > >> > > r6 = 0xc5a47960 r7 = 0xc5a47a0c > > >> > > r8 = 0xc5a47a0c r9 = 0x01020804 > > >> > > r10 = 0x00000ab8 > > >> > > ast() at ast+0x4f4 > > >> > > pc = 0xc044388c lr = 0xc0621080 (swi_entry+0x6c) > > >> > > sp = 0xef2cce60 fp = 0xbfffe438 > > >> > > r4 = 0x40000013 r5 = 0xc5bc4320 > > >> > > r6 = 0x00000001 r7 = 0x00000154 > > >> > > r8 = 0x20037008 r9 = 0xbfffee5c > > >> > > r10 = 0xbfffea10 > > >> > > swi_entry() at swi_entry+0x6c > > >> > > pc = 0xc0621080 lr = 0xc0621080 (swi_entry+0x6c) > > >> > > sp = 0xef2cce60 fp = 0xbfffe438 > > >> > > Unable to unwind further > > >> > > db> > > >> > > > > >> > > > > >> > > > > >> > > 2014-03-22 14:20 GMT+01:00 Ian Lepore : > > >> > > > > >> > > On Fri, 2014-03-21 at 07:20 +0100, Wojciech Macek wrote: > > >> > >> > No, changing flushD to flushID did not make any difference, > but I > > >> think > > >> > >> it > > >> > >> > should be there - D-only flushing might not be sufficient. > > >> > >> > > > >> > >> > > >> > >> Olivier reminded me right after I posted that: last week I made a > > >> change > > >> > >> to cpufunc.c that makes flushD and flushID the same. So of > course it > > >> > >> made no difference. :) It really should be flushID though, in > case > > >> > >> that ever changes. > > >> > >> > > >> > >> You didn't say whether you have that change, which was r263251. > > >> > >> > > >> > >> > Currently, I'm running pmap_kernel_internal attached below. It > is > > >> doing > > >> > >> > unconditional flushID at the end, just like the old comment was > > >> saying > > >> > >> :) > > >> > >> > SMP seems to be stable. > > >> > >> > > > >> > >> > > >> > >> That seems to say that somehow there is a valid TLB entry even > though > > >> > >> the old pte for that entry is zero. That means there's a problem > > >> > >> somewhere else in the code, but I don't see it. It looks to me > like > > >> we > > >> > >> do a TLB flush everywhere that we zero out a pte. > > >> > >> > > >> > >> You said without the unconditional flush it panics at startup. > > >> Where in > > >> > >> startup? Early, or after init is launched or what? Where does > the > > >> > >> panic backtrace to? > > >> > >> > > >> > >> If we've got some other pte/tlb maintenance problem, I'd hate to > > >> hide it > > >> > >> with this unconditional flush and have it appear as some other > > >> problem > > >> > >> later that will be even harder to track down. > > >> > >> > > >> > >> -- Ian > > >> > >> > > >> > >> > > >> > >> > > >> > > > > >> > > >> > > >> > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > From owner-freebsd-arm@FreeBSD.ORG Mon Mar 31 11:06:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C6088FC for ; Mon, 31 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 504D3B8E for ; Mon, 31 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2VB6fOj058626 for ; Mon, 31 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2VB6eYo058624 for freebsd-arm@FreeBSD.org; Mon, 31 Mar 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Mar 2014 11:06:40 GMT Message-Id: <201403311106.s2VB6eYo058624@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 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/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o ports/175605 arm devel/binutils: please fix build binutils-2.23.1 in ra 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 ports/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) 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 32 problems total. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 1 18:00:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3370C521 for ; Tue, 1 Apr 2014 18:00:41 +0000 (UTC) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7B1A7B5 for ; Tue, 1 Apr 2014 18:00:40 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id if17so9963868vcb.22 for ; Tue, 01 Apr 2014 11:00:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=iRVElz17ZBbtgXh6uWBB/irAbBHXKIFcmQFBLMyvj3M=; b=Xe+noiwkLf2i1sz8YI37b3A45HCuNOhLAFuE1Jwumu3I3c5mn4mLap6Q5kKCfR7YQM 8gaZPktjt59e/I2nMmeVt2z7kY4lONl+oG6tMvdlyOJpLxi1QkRz+X6PSGKZvYhuNjYl s/51abh/f7BCxspBq38itg3bp/vqqPEL/6WeGr1HctsKhYRnzaTmSBcYYgkWOWe4N8Pb aRCpAa2JZFtcrEFOO/+2819K9my6sjfWtzs215ObQYUx3ibsIHPyu7WU8/vC3gVFVC3J t1sha+S/bKSkWPgYjiWEwEE01ZAPA10Txf5jYtJLi1AN0dLrVSLP6Q/OEqXirK7kidb4 F6lQ== X-Gm-Message-State: ALoCoQm7UxEsItW5ZfW0ml7kTbhgwZABJ8JLOv6R+TRyi2IJCPYDgGcwvqbNz764fHx/4OT5WPQQ MIME-Version: 1.0 X-Received: by 10.52.6.162 with SMTP id c2mr24711843vda.6.1396373467366; Tue, 01 Apr 2014 10:31:07 -0700 (PDT) Received: by 10.220.39.133 with HTTP; Tue, 1 Apr 2014 10:31:07 -0700 (PDT) Date: Tue, 1 Apr 2014 14:31:07 -0300 Message-ID: Subject: Support Modem 3g From: Guilherme Ferreira Rosario To: freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 18:00:41 -0000 first sorry for bad english, Please 3g modem model which has comptabilidade with the FreeBSD version 10 or 11 arm architecture. thank you graciously From owner-freebsd-arm@FreeBSD.ORG Tue Apr 1 18:12:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8B958B4; Tue, 1 Apr 2014 18:12:11 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A71CB8FA; Tue, 1 Apr 2014 18:12:11 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 58D861FE027; Tue, 1 Apr 2014 20:12:08 +0200 (CEST) Message-ID: <533B01A7.6040800@selasky.org> Date: Tue, 01 Apr 2014 20:12:55 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Guilherme Ferreira Rosario , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org Subject: Re: Support Modem 3g References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 18:12:12 -0000 On 04/01/14 19:31, Guilherme Ferreira Rosario wrote: > first sorry for bad english, > > Please 3g modem model which has comptabilidade with the FreeBSD version 10 > or 11 arm architecture. > > thank you > > graciously Hi, The PFSense project has some 3G modem compatibility lists. https://doc.pfsense.org/index.php/Known_Working_3G-4G_Modems --HPS From owner-freebsd-arm@FreeBSD.ORG Wed Apr 2 09:29:27 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4038152A; Wed, 2 Apr 2014 09:29:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5519117; Wed, 2 Apr 2014 09:29:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s329TIrw061998; Wed, 2 Apr 2014 05:29:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s329TImA061991; Wed, 2 Apr 2014 09:29:18 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 2 Apr 2014 09:29:18 GMT Message-Id: <201404020929.s329TImA061991@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 09:29:27 -0000 TB --- 2014-04-02 06:00:42 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 06:00:42 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 06:00:42 - starting HEAD tinderbox run for arm/arm TB --- 2014-04-02 06:00:42 - cleaning the object tree TB --- 2014-04-02 06:00:42 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 06:00:47 - At svn revision 264031 TB --- 2014-04-02 06:00:48 - building world TB --- 2014-04-02 06:00:48 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 06:00:48 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 06:00:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 06:00:48 - SRCCONF=/dev/null TB --- 2014-04-02 06:00:48 - TARGET=arm TB --- 2014-04-02 06:00:48 - TARGET_ARCH=arm TB --- 2014-04-02 06:00:48 - TZ=UTC TB --- 2014-04-02 06:00:48 - __MAKE_CONF=/dev/null TB --- 2014-04-02 06:00:48 - cd /src TB --- 2014-04-02 06:00:48 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Apr 2 06:00:55 UTC 2014 >>> 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 Wed Apr 2 09:21:09 UTC 2014 TB --- 2014-04-02 09:21:09 - generating LINT kernel config TB --- 2014-04-02 09:21:09 - cd /src/sys/arm/conf TB --- 2014-04-02 09:21:09 - /usr/bin/make -B LINT TB --- 2014-04-02 09:21:09 - cd /src/sys/arm/conf TB --- 2014-04-02 09:21:09 - /obj/arm.arm/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 09:21:09 - building LINT kernel TB --- 2014-04-02 09:21:09 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 09:21:09 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 09:21:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 09:21:09 - SRCCONF=/dev/null TB --- 2014-04-02 09:21:09 - TARGET=arm TB --- 2014-04-02 09:21:09 - TARGET_ARCH=arm TB --- 2014-04-02 09:21:09 - TZ=UTC TB --- 2014-04-02 09:21:09 - __MAKE_CONF=/dev/null TB --- 2014-04-02 09:21:09 - cd /src TB --- 2014-04-02 09:21:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 2 09:21:10 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/iicsmb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/iicoc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/s35390a.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iir/iir.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iir/iir_ctrl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iir/iir_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iscsi/icl.c /src/sys/dev/iscsi/icl.c:1052:7: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat] minspace); ^~~~~~~~ /src/sys/dev/iscsi/icl.c:95:21: note: expanded from macro 'ICL_WARN' __func__, ## __VA_ARGS__); \ ^ /src/sys/dev/iscsi/icl.c:1057:7: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat] minspace); ^~~~~~~~ /src/sys/dev/iscsi/icl.c:95:21: note: expanded from macro 'ICL_WARN' __func__, ## __VA_ARGS__); \ ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-04-02 09:29:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-04-02 09:29:18 - ERROR: failed to build LINT kernel TB --- 2014-04-02 09:29:18 - 9988.60 user 1648.07 system 12515.81 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Apr 2 20:26:39 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6234DF0F; Wed, 2 Apr 2014 20:26:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E6A78F8; Wed, 2 Apr 2014 20:26:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s32KQbVU070002; Wed, 2 Apr 2014 16:26:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s32KQbZl069995; Wed, 2 Apr 2014 20:26:37 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 2 Apr 2014 20:26:37 GMT Message-Id: <201404022026.s32KQbZl069995@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 20:26:39 -0000 TB --- 2014-04-02 17:00:23 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 17:00:23 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 17:00:23 - starting HEAD tinderbox run for arm/arm TB --- 2014-04-02 17:00:23 - cleaning the object tree TB --- 2014-04-02 17:02:59 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 17:03:02 - At svn revision 264046 TB --- 2014-04-02 17:03:03 - building world TB --- 2014-04-02 17:03:03 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 17:03:03 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 17:03:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 17:03:03 - SRCCONF=/dev/null TB --- 2014-04-02 17:03:03 - TARGET=arm TB --- 2014-04-02 17:03:03 - TARGET_ARCH=arm TB --- 2014-04-02 17:03:03 - TZ=UTC TB --- 2014-04-02 17:03:03 - __MAKE_CONF=/dev/null TB --- 2014-04-02 17:03:03 - cd /src TB --- 2014-04-02 17:03:03 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Apr 2 17:03:10 UTC 2014 >>> 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 Wed Apr 2 20:18:40 UTC 2014 TB --- 2014-04-02 20:18:40 - generating LINT kernel config TB --- 2014-04-02 20:18:40 - cd /src/sys/arm/conf TB --- 2014-04-02 20:18:40 - /usr/bin/make -B LINT TB --- 2014-04-02 20:18:40 - cd /src/sys/arm/conf TB --- 2014-04-02 20:18:40 - /obj/arm.arm/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 20:18:40 - building LINT kernel TB --- 2014-04-02 20:18:40 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:18:40 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:18:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:18:40 - SRCCONF=/dev/null TB --- 2014-04-02 20:18:40 - TARGET=arm TB --- 2014-04-02 20:18:40 - TARGET_ARCH=arm TB --- 2014-04-02 20:18:40 - TZ=UTC TB --- 2014-04-02 20:18:40 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:18:40 - cd /src TB --- 2014-04-02 20:18:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 2 20:18:40 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/iicsmb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/iicoc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/s35390a.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iir/iir.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iir/iir_ctrl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iir/iir_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iscsi/icl.c /src/sys/dev/iscsi/icl.c:1052:7: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat] minspace); ^~~~~~~~ /src/sys/dev/iscsi/icl.c:95:21: note: expanded from macro 'ICL_WARN' __func__, ## __VA_ARGS__); \ ^ /src/sys/dev/iscsi/icl.c:1057:7: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat] minspace); ^~~~~~~~ /src/sys/dev/iscsi/icl.c:95:21: note: expanded from macro 'ICL_WARN' __func__, ## __VA_ARGS__); \ ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-04-02 20:26:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-04-02 20:26:37 - ERROR: failed to build LINT kernel TB --- 2014-04-02 20:26:37 - 9984.67 user 1592.16 system 12373.71 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Apr 2 23:30:22 2014 Return-Path: Delivered-To: FreeBSD-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07EC0F92 for ; Wed, 2 Apr 2014 23:30:22 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F9A3AC3 for ; Wed, 2 Apr 2014 23:30:17 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s32NF6h6027808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Apr 2014 01:15:07 +0200 (CEST) (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 s32NF1Cl086158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2014 01:15:01 +0200 (CEST) (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 s32NF1Y7044960; Thu, 3 Apr 2014 01:15:01 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s32NF0ZN044959; Thu, 3 Apr 2014 01:15:00 +0200 (CEST) (envelope-from ticso) Date: Thu, 3 Apr 2014 01:15:00 +0200 From: Bernd Walter To: FreeBSD-arm@freebsd.org Subject: iMX6 based Novena crowd funding project Message-ID: <20140402231500.GF30097@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Bernd Walter X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 23:30:22 -0000 http://www.crowdsupply.com/kosagi/novena-open-laptop I'm not quite happy with the bundling setup, but have been fascinated by that board since I've first noticed it mid 2013. Hope that one day we can run X on iMX6 as I'm not a Linux fan. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 00:08:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 918FE44C for ; Thu, 3 Apr 2014 00:08:53 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68CA8D18 for ; Thu, 3 Apr 2014 00:08:53 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id p10so924322pdj.3 for ; Wed, 02 Apr 2014 17:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=6+bjBwobIP3O4jIoZGUV9s84oFzENXg76gAi/9h0rz0=; b=FqJMqY1G5d+AqmnnJNi2dcmAcOvzppCoR5JhKXOrRgemz5FYTyVMfYiIUgFooJN7eI ldNRNozNVCEhbHsdd6/w6rQ6Qp6y4CkYeC0INN1F+BYiuYBiNJZ62cKexRchYQkirCsG SS/IAKdzusemZa16aU9z7Aq3o59cY4w2K8gkFz7APdMBIkuNFJX1OK5nd0ip66QRh21R 2gGEF/NV4cMjxnyl2xcK9rNT19DdjcaSD8WQ/ug6g7CJCYNZJ5hJQSotHEtZi07fSxbm zF2Ubr9kenLSINhbM7QoXg6wJfZSV7gqH3VnWOJZarqbZkz6chZmHUAiF2gNnAMDf5O/ dYEA== X-Received: by 10.66.102.4 with SMTP id fk4mr3310721pab.59.1396483733009; Wed, 02 Apr 2014 17:08:53 -0700 (PDT) Received: from [216.131.71.129] ([216.131.71.129]) by mx.google.com with ESMTPSA id gu11sm7006444pbd.74.2014.04.02.17.08.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 17:08:51 -0700 (PDT) Message-ID: <533CA68E.1020602@gmail.com> Date: Thu, 03 Apr 2014 08:08:46 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: BeagleBone Black: Increase CPU frequency from 800MHz to 1GHz 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 00:08:53 -0000 Hi community, I am working on a small project to increase AM335x Cortex-A8 MPU frequency from 800MHz to 1GHz. Would you please point to me which tree should I base my work on? Is it current? I did notice that there is "projects/armv6", svn log under sys/arm/ti shows the latest commit is "2012-08-15" -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 00:58:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DB0599A for ; Thu, 3 Apr 2014 00:58:06 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF172124 for ; Thu, 3 Apr 2014 00:58:05 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id q107so1053740qgd.39 for ; Wed, 02 Apr 2014 17:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=dfWlTjX9NVIdRRzCs2ZJtQtDlXRX3KP9yGm20RGByGg=; b=cGAA3hJ2EF/6CVgNHmwzP5Pv1DDoigbomwNimmw9ENzF8orsBSp9BMVPcWIeIYu0a0 L/z/+gxbe+Aysy4xvbw8wuZBiVrXXq0wCLMSX5wZBmhxp+d7pJBaPdTE2+lUvIoTOOmz vVljaNobChynjmdiOjKzxf55925c1anRL6fFyYDwt80a9+HX+6aTLAEurGXzIx8z8kLL 2q0SATlmK2B1lewwYU4rKbCFeObVmlWKoyYkRUGyIYp29zYiwNYFjR/Z9yXTII9bIg5G s6B6Dq3clNL96yaDaO76cx9JLJ7Px1soVPa/BrP4AEt1s8nKulAw91ME1UItyxdq4XG9 83bw== X-Received: by 10.224.75.5 with SMTP id w5mr4258518qaj.52.1396486685116; Wed, 02 Apr 2014 17:58:05 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id e69sm4814452qgf.17.2014.04.02.17.57.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Apr 2014 17:57:58 -0700 (PDT) Date: Wed, 2 Apr 2014 20:57:55 -0400 From: Shawn Webb To: FreeBSD ARM Subject: Building an image for Raspberry Pi Message-ID: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 00:58:06 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey all, So I'm trying to build an image for the rPi, and I came across Crochet =66rom the Raspberry Pi wiki page on FreeBSD's wiki. I'm basing my build off of a fresh HEAD. I'm not entirely sure if I should be contacting the Crochet developers about this, or if the freebsd-arm list would be better. Either way, please forgive me if this isn't the most effective place. It seems that when Crochet tries to build U-Boot from source, U-Boot requires the application armv6-freebsd-gcc. I can't find such an application in the ports tree (grep -rn arv6-freebsd-gcc /usr/ports). It seems people have successfully built FreeBSD for ARM. However, the instructions I'm seeing from a little bit of googling have turned up pretty outdated posts. You can probably tell I'm a newb at ARM on FreeBSD. What ought I do next? Thanks, Shawn --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTPLIRAAoJEGqEZY9SRW7u7fkP/0Umikx1uu4ntDpLowdyb0wR /m+7x5M2/jdLi2K9DKiLVzJz01iINOtorZtsCriBnek022BTpBoSrPYKNVB5G3yY ZEXMl5fP5y36CqBlcBrwT8/YEsESpQOLGYYcmU338LjN3aC8+GvtHhgGwOsIK9gY e4qgnCJTsgJrRFoolb6XkO/Kj45zu2wKB1YpwrxGaDseJimeUhCCAgdBw4mZCZmo DlAeRmXb7k2IBeHfhQgloGrcjcElcbMQChcwckpRh6Je4F3pTLNjJjjKcOsWfPrw nAcPnA3luB9m6Fyvcgr6ailCM0ebSVp9IvwZrEG4srE+kn3IIfSM0lrkqktUU2+b EYQ83GlYHnKrgMPvpf3KESnFoCw/ZBVik7iHoXYPRiwTI5UVGgz9NvThjVxnQfnZ cel7g9/mcoC+bb/2QMRkU5ykdObo3a0NZ6YPQKAeNCNbfMnYak2B/Xv9TWtR8nTn VoQV7U85e91DqFdg+HnjHTaGM5qd9S+QfYolqZJEAOrjjCt2qywK0dnNqZ1Hqkh9 hfYjCBq+jK7+X+IV6urvTMwzuXLrruz+RM4pvPk4T4GqEhk9oaVWtMs/xGL8IJsp dhM6HZv/AHxYquiKBr96y08El1RlAaPQ6SjVjU4EsTAmQ2eKBsMwgkru96pWzy6P W7AUHeq/Ho5OPFP7eOvD =B5dK -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 01:05:33 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD3DDC93 for ; Thu, 3 Apr 2014 01:05:33 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 821C61C8 for ; Thu, 3 Apr 2014 01:05:33 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WVW5t-0009Ax-PJ; Thu, 03 Apr 2014 01:05:26 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3315NM3086471; Wed, 2 Apr 2014 19:05:23 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/hRXVF2AAbyj5z8RzurD1J Subject: Re: BeagleBone Black: Increase CPU frequency from 800MHz to 1GHz From: Ian Lepore To: Xuebing Wang In-Reply-To: <533CA68E.1020602@gmail.com> References: <533CA68E.1020602@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 2014 19:05:23 -0600 Message-ID: <1396487123.81853.274.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 01:05:33 -0000 On Thu, 2014-04-03 at 08:08 +0800, Xuebing Wang wrote: > Hi community, > > I am working on a small project to increase AM335x Cortex-A8 MPU > frequency from 800MHz to 1GHz. > > Would you please point to me which tree should I base my work on? Is it > current? > > I did notice that there is "projects/armv6", svn log under sys/arm/ti > shows the latest commit is "2012-08-15" > Definitely use -current. That projects branch was where the initial armv6 work was done long ago, but that was all merged to 10 and has now evolved into 11-current. I think very many Beaglebone users will be interested in your work, including me! -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 01:15:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EC17EBA for ; Thu, 3 Apr 2014 01:15:32 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 07155294 for ; Thu, 3 Apr 2014 01:15:31 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s331FNaf034531 for ; Wed, 2 Apr 2014 21:15:29 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <533CB62B.3040502@m5p.com> Date: Wed, 02 Apr 2014 21:15:23 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Building an image for Raspberry Pi References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> In-Reply-To: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> 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]); Wed, 02 Apr 2014 21:15:29 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 01:15:32 -0000 On 04/02/14 20:57, Shawn Webb wrote: > Hey all, > > So I'm trying to build an image for the rPi, and I came across Crochet > from the Raspberry Pi wiki page on FreeBSD's wiki. I'm basing my build > off of a fresh HEAD. > > I'm not entirely sure if I should be contacting the Crochet developers > about this, or if the freebsd-arm list would be better. Either way, > please forgive me if this isn't the most effective place. > > It seems that when Crochet tries to build U-Boot from source, U-Boot > requires the application armv6-freebsd-gcc. I can't find such an > application in the ports tree (grep -rn arv6-freebsd-gcc /usr/ports). What I found on my most recent clean build (on a FreeBSD 10-STABLE system) was that I had to set HOSTCC to cc in the environment in order to build U-Boot. I don't even really understand why it worked, but it did. -- George > > It seems people have successfully built FreeBSD for ARM. However, the > instructions I'm seeing from a little bit of googling have turned up > pretty outdated posts. > > You can probably tell I'm a newb at ARM on FreeBSD. What ought I do > next? > > Thanks, > > Shawn > From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 01:29:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9356227 for ; Thu, 3 Apr 2014 01:29:15 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8426D367 for ; Thu, 3 Apr 2014 01:29:15 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id x13so1147834qcv.15 for ; Wed, 02 Apr 2014 18:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=idVx+DVi7LOb8/rHgotJMEqbH/KJ3eZXugXKhMSovkw=; b=yXHNgJbUpJRsuwqzYqjBQ6iXxLqxcA8RD2Y74gbdSjQcpfag2spGIl7OJ/I47O3cxh TONyph5l9JVZEJ/j3wF3EsaJvQUThux0lCOhVNsyx4ZIU8apowyTIvQaWBXT72uPt1bz 7ak720D4jj88IpOsaTGofEFbDhDn5RX94gjgLO1QHAfBsjzbe3QAHyL6E+zCDF5jlRk9 ntIAnlYNthScF1BfVcojXK9U6MQV1d55t62JllLRg4Y6/bikV5y2QcKPbJrAMNkOVd3q d4MsL60YqF8LNjlr78ObE/onthpDv4K/QCuUFFg5c6eidW7ELypN/MjP5vh6BZtIEXNu vHng== X-Received: by 10.140.49.233 with SMTP id q96mr4178937qga.76.1396488554740; Wed, 02 Apr 2014 18:29:14 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id w2sm7122174qar.21.2014.04.02.18.29.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Apr 2014 18:29:13 -0700 (PDT) Date: Wed, 2 Apr 2014 21:29:11 -0400 From: Shawn Webb To: George Mitchell Subject: Re: Building an image for Raspberry Pi Message-ID: <20140403012911.GB71905@pwnie.vrt.sourcefire.com> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <533CB62B.3040502@m5p.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KFztAG8eRSV9hGtP" Content-Disposition: inline In-Reply-To: <533CB62B.3040502@m5p.com> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 01:29:15 -0000 --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Apr 02, 2014 09:15 PM -0400, George Mitchell wrote: > On 04/02/14 20:57, Shawn Webb wrote: > > Hey all, > > > > So I'm trying to build an image for the rPi, and I came across Crochet > > from the Raspberry Pi wiki page on FreeBSD's wiki. I'm basing my build > > off of a fresh HEAD. > > > > I'm not entirely sure if I should be contacting the Crochet developers > > about this, or if the freebsd-arm list would be better. Either way, > > please forgive me if this isn't the most effective place. > > > > It seems that when Crochet tries to build U-Boot from source, U-Boot > > requires the application armv6-freebsd-gcc. I can't find such an > > application in the ports tree (grep -rn arv6-freebsd-gcc /usr/ports). >=20 > What I found on my most recent clean build (on a FreeBSD 10-STABLE > system) was that I had to set HOSTCC to cc in the environment in > order to build U-Boot. I don't even really understand why it worked, > but it did. -- George Setting HOSTCC didn't really do anything for me. However, setting CC to /usr/bin/armv6-freebsd-cc got me further in the process. I'm now getting tons of errors like this: /usr/bin/armv6-freebsd-ld: ERROR: Source object /usr/armv6-freebsd/usr/lib/= libstand.a(bcd.o) has EABI version 5, but target ubldr has EABI version 0 /usr/bin/armv6-freebsd-ld: failed to merge target specific data of file /us= r/armv6-freebsd/usr/lib/libstand.a(bcd.o) --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTPLlmAAoJEGqEZY9SRW7utOwQALMeEBG4sVt6zM5ruxCZqHzc ECMMGmI6adUhCwG4XelYCsKb/1ElSmO9mizcQmOhnP/Nx5Yes46SN5EkRfTLMe9H zbsJQClixz76lLz2gvKZymYks9ulIsHsX+jNQZnsgGvml/+D9i1mw+PsNvGwxRzz HiDRIuRgXtqxyMa0ROcoItid6qn1pp7tYg40e3aCZt7jUWuDuJU8L7qlqwfrzH70 i/c3ivr+kBlDO22OVvoCWi2GDNhX578noN6TsFqKaOTbMEVsYDgpUK/k/SSAvK7o tkCiYihobMY0DG4buwBDXpPPAgoe3iI8FnN2LOvWl20UbWkLtjSv7hDy8UljhW82 94eHmk2sRRRIkwkAY9TL0rl5GWjxvXWURFlZBOWaNx56pJpEnfEYA3HVGNPKkPuT TwFsSMZI7A3PM4BgJz4zq3ZZvG8VZzHFuMobd1TjBIZMC9PmFTq2g+wFRd+nF4z0 E3/1fB7PBTVBnHgOZqiej68gveYdb+5VLGrSbfiNMnOyY0hMny0kaipIlFackOD2 Qno2ytkr86t/EnEx7gkfXbxCFRw8q6M0dJtwazw5A+DC7u2zCwyRNv+iymJYjxet qSPkbCGK3N6dOVWZdKBfxjOrnKLCuJYSKtMnA3vW+IxX8PsgXL+13a3ZVN15WGiK oauzGNIRe+L6V7KBLTwQ =Y63a -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 05:35:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA8CCA64 for ; Thu, 3 Apr 2014 05:35:26 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57049A66 for ; Thu, 3 Apr 2014 05:35:26 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id t61so1254169wes.17 for ; Wed, 02 Apr 2014 22:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wb9SIg7qeWPu5ijK4r39amBp8JhoZvem/JuEVYwyOPE=; b=N3PnywwYv2lzNEPwCfqpTUXli2ODhzJdIoeZjVG+cicVZHTo1t1IOarH9a+Tymg0mC C1juVEVtdR7D1DpFwgo+O0MZfVyr7RtR2F5h/pjiGzhjhdwwRHxR+NOuBq6teU2TRFPC xzDPAA97fcLZFOqKrzoAAO0y7UVQ9zxMjw2sQjNuYuXzMx/LqUtYbvYEaRRGZhvlbNis d9Pe46z/3dMoIl19pafcn3MaVk4KVuJKhagnpkZDKYdXdvt5mwITgCFFeXR0zQeIURTf mav0v8Bge+3PZl9YnvH8FQZEKDbo/raEdzvdgLBzgWR3y32IY31rTXfy73+UzqCDXjKt hMng== MIME-Version: 1.0 X-Received: by 10.194.119.168 with SMTP id kv8mr6553298wjb.41.1396503324571; Wed, 02 Apr 2014 22:35:24 -0700 (PDT) Received: by 10.14.211.134 with HTTP; Wed, 2 Apr 2014 22:35:24 -0700 (PDT) In-Reply-To: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> Date: Wed, 2 Apr 2014 22:35:24 -0700 Message-ID: Subject: Re: Building an image for Raspberry Pi From: hiren panchasara To: Shawn Webb Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:35:26 -0000 On Wed, Apr 2, 2014 at 5:57 PM, Shawn Webb wrote: > Hey all, > > So I'm trying to build an image for the rPi, and I came across Crochet > from the Raspberry Pi wiki page on FreeBSD's wiki. I'm basing my build > off of a fresh HEAD. > > I'm not entirely sure if I should be contacting the Crochet developers > about this, or if the freebsd-arm list would be better. Either way, > please forgive me if this isn't the most effective place. This is the correct list. > > It seems that when Crochet tries to build U-Boot from source, U-Boot > requires the application armv6-freebsd-gcc. I can't find such an > application in the ports tree (grep -rn arv6-freebsd-gcc /usr/ports). > > It seems people have successfully built FreeBSD for ARM. However, the > instructions I'm seeing from a little bit of googling have turned up > pretty outdated posts. Been a while since I've build an arm image with crochet but I believe https://github.com/kientzle/crochet-freebsd is up-to-date. Are you using it? cheers, Hiren From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 05:41:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32323CEA; Thu, 3 Apr 2014 05:41:10 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.glenbarber.us", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04BADA9F; Thu, 3 Apr 2014 05:41:09 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 631B5BB55; Thu, 3 Apr 2014 05:41:08 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 631B5BB55 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 3 Apr 2014 01:41:06 -0400 From: Glen Barber To: Shawn Webb Subject: Re: Building an image for Raspberry Pi Message-ID: <20140403054106.GT14379@glenbarber.us> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q43QQdzFtqSKgsg+" Content-Disposition: inline In-Reply-To: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:41:10 -0000 --Q43QQdzFtqSKgsg+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 02, 2014 at 08:57:55PM -0400, Shawn Webb wrote: > Hey all, >=20 > So I'm trying to build an image for the rPi, and I came across Crochet > from the Raspberry Pi wiki page on FreeBSD's wiki. I'm basing my build > off of a fresh HEAD. >=20 > I'm not entirely sure if I should be contacting the Crochet developers > about this, or if the freebsd-arm list would be better. Either way, > please forgive me if this isn't the most effective place. >=20 > It seems that when Crochet tries to build U-Boot from source, U-Boot > requires the application armv6-freebsd-gcc. I can't find such an > application in the ports tree (grep -rn arv6-freebsd-gcc /usr/ports). >=20 You need to build the XDEV stuff for the build environment. Something like: make -C /usr/src XDEV=3Darm XDEV_ARCH=3Darmv6 should do the trick. > It seems people have successfully built FreeBSD for ARM. However, the > instructions I'm seeing from a little bit of googling have turned up > pretty outdated posts. >=20 > You can probably tell I'm a newb at ARM on FreeBSD. What ought I do > next? >=20 Are you aware that we have FreeBSD/arm images on FTP now? Not that I am trying to deter you from building your own images, but if you're just looking for an image to install to get your RPI running FreeBSD, we have you covered. :-) http://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/ Glen --Q43QQdzFtqSKgsg+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTPPRyAAoJELls3eqvi17QaBQP/2l56gtc7oalaY/Z0G42H0eE ydZzMEBXLcm6ezMV/KkaQ0bcUqzRX/kVIwssX6/dpZPshNg8oqLnYA5lBZk4nYa/ FW1YQYSaosrlCfgUhfgKk5t9VOumFU/Euwy9vMO/E9tfI8DINibWR88h/RSLdxkd 5kxVrHOH6aQ3WZshROtlv1VxYBaxLKmpE5FbCl7+lVBc0+2G9YRgFHCpy0ZC2X++ Us+dhJDm0D/meTKhrpuTbhaFLjxQ2k8u+4uLKKc5hPMPkUgp2NXG+oQ4RIacjfuR Br7wN699mcUD4YkXPhfMF5KTFcr52RmNzzLq5qJq6Q9bj80sDvAUcyRvxFpcsqYx FenK3jQdMRhkKvJXgyyJRlTnr8/25ADZ+5M2dUKkYi4+MCwgjF36L2wPdWWrJx+M yTzOn3xA8P4aCnrzvAuJZc01Son8PJiQde4FIRK1/0lbRxM8xAtNJ1Bn1t2TqTmT 9p6SXUrN8F3wV5kHRzz98Av41+ZE7GD9z2LF2/I37vuGtu+MEpVGkVxXRAiDKDt9 M+/5TTE4ypJdxXbVlEWj4rsqHF+mKqTmK2M703227XOfbcDpp02Ev5vntO7nDqpY iLaUqfRbCDBc/4JhzO9pzagruty5x4hNUtRnG21TCbHXrWI/7rSaiEz+lHF6xVG5 YCIiEg0Dapv31aEMxeUu =ESjF -----END PGP SIGNATURE----- --Q43QQdzFtqSKgsg+-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 06:14:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76DA0772; Thu, 3 Apr 2014 06:14:49 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 20FA8D7B; Thu, 3 Apr 2014 06:14:49 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id i17so1392862qcy.0 for ; Wed, 02 Apr 2014 23:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=YRXBRZp8yxV88jKuPZMYOHyNhD1p24GLvvJHQiAQ84I=; b=0W+TLtAsKzT3dU6ewpNTfWkmo0FQpR/eVS95J8gMI4W4B38Gz8A5WSPK+PNhX65oB2 PJ7UCgxNLDNcLil1IknRvbhWE0P84cdteqm0MrDGA/SFsrCTiqdgRt2Lctj6MoQyjjV0 bB2PCxLd8osyqbr/nGBBr6q6MsLGoGmFzxc5u40fRtPhUqwPutzWHFQqOEgFpiHfbJ8f 1hZ/ZifoFmq85zT65MBT0NcEynAhT7+IeYW3dDT7zCxu3jumyp9cW91OEAWXaGT3Ye8z IkHKRTgrEmrUeX10b7x2+zPFye2dLjwdB8WpSCCm0NtnXSQg4dttnV+5eTI9nbLFl1iQ A8sw== X-Received: by 10.140.50.231 with SMTP id s94mr5029221qga.33.1396505687262; Wed, 02 Apr 2014 23:14:47 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id e69sm5697404qgf.17.2014.04.02.23.14.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Apr 2014 23:14:45 -0700 (PDT) Date: Thu, 3 Apr 2014 02:14:43 -0400 From: Shawn Webb To: Glen Barber Subject: Re: Building an image for Raspberry Pi Message-ID: <20140403061443.GD71905@pwnie.vrt.sourcefire.com> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <20140403054106.GT14379@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hoZxPH4CaxYzWscb" Content-Disposition: inline In-Reply-To: <20140403054106.GT14379@glenbarber.us> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 06:14:49 -0000 --hoZxPH4CaxYzWscb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Apr 03, 2014 01:41 AM -0400, Glen Barber wrote: > You need to build the XDEV stuff for the build environment. >=20 > Something like: make -C /usr/src XDEV=3Darm XDEV_ARCH=3Darmv6 >=20 > should do the trick. Yeah, I have the xdev stuff installed. It kinda seems like just using this xdev stuff isn't sufficient. It seems u-boot might require some gcc-centric items (though I'm unsure what they are). >=20 > > It seems people have successfully built FreeBSD for ARM. However, the > > instructions I'm seeing from a little bit of googling have turned up > > pretty outdated posts. > >=20 > > You can probably tell I'm a newb at ARM on FreeBSD. What ought I do > > next? > >=20 >=20 > Are you aware that we have FreeBSD/arm images on FTP now? Not that I am > trying to deter you from building your own images, but if you're just > looking for an image to install to get your RPI running FreeBSD, we have > you covered. :-) I've been toying with that pretty much all evening. It seems that fbsd has a really hard time booting on the rpi. I'm getting this error pretty much 90% of the time when I try to boot: http://lists.freebsd.org/pipermail/freebsd-arm/2014-January/007228.html I'll play around with things a bit more. I have a semi-functional system now. I mainly want to be able to build my own images so I can publish nightly builds of my ASLR work now that Oliver and I just added support for [nearly all|all] architectures fbsd supports. --hoZxPH4CaxYzWscb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTPPxRAAoJEGqEZY9SRW7ue5kP/RDMjsitLynhZ4vDglrAil4B 5N8H5TWKCu9Xrjb5uSQLNKzdPSYA0+6eKpd4fuRH/gnAnLgECfdMQ2ERSJ3+9uk6 Zw7vcKc0OVo+QVeaFpNDK2GwOMTwwTGYB1CptmBWgQZGXvkIJj9/kSO+tB8VGbdh dz8MdDzDjrfX4BFW59rgkvK/HU+kEk+nIoOPnXZx/pxgjEcDYA8Io1ZTa1NvG6VX qTpe0scCSF9LETLm+R4PXAkTTZetVp4O0bCbRDWoJ91xYpDaf4syAe5QSx2d5OjY ys/WyKmBe4RSfpZBV3Fde/VuoceTiU2MHPITLLZwESFt4WDTs082ngumoEGFN2QB eRETDK6HTQnDQEm5+N6cc2bMiPTPAGsqr0dwQFTtvP+EcUT43yf4gQd1H0nHyK1V JMNm3PzNlxTW56dMAY33dA8dVxdayMaINUvdjZQcwJCRSPQFWoV5QpIRebjLiun0 +RnzmFXPyWx8SrYaAlNwnAgwhaxuw1eJClP1RwjOtStt2K08WQHm2Ihgt6/adtGr wc4g9/esevK8WUixgANJEqEXEZGwYrhHYNBgIB3V4uO28lCrwQHIplX1a/pwziRI +t2WLNLB6q64pDYtSzxHh6Zb99rvE2XFFvVyCKP9rOFyjnSoCKPeZb13bAZ+7ZeQ aENm5xx+fNEi81YF3xOI =Vwkx -----END PGP SIGNATURE----- --hoZxPH4CaxYzWscb-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 06:19:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02F447EC; Thu, 3 Apr 2014 06:19:27 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.glenbarber.us", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B07A8D9E; Thu, 3 Apr 2014 06:19:26 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 2B715BEF0; Thu, 3 Apr 2014 06:19:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 2B715BEF0 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 3 Apr 2014 02:19:23 -0400 From: Glen Barber To: Shawn Webb Subject: Re: Building an image for Raspberry Pi Message-ID: <20140403061923.GW14379@glenbarber.us> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <20140403054106.GT14379@glenbarber.us> <20140403061443.GD71905@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9I0HVnGRacHebCDW" Content-Disposition: inline In-Reply-To: <20140403061443.GD71905@pwnie.vrt.sourcefire.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 06:19:27 -0000 --9I0HVnGRacHebCDW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 03, 2014 at 02:14:43AM -0400, Shawn Webb wrote: > On Apr 03, 2014 01:41 AM -0400, Glen Barber wrote: > > You need to build the XDEV stuff for the build environment. > >=20 > > Something like: make -C /usr/src XDEV=3Darm XDEV_ARCH=3Darmv6 > >=20 > > should do the trick. >=20 > Yeah, I have the xdev stuff installed. It kinda seems like just using > this xdev stuff isn't sufficient. It seems u-boot might require some > gcc-centric items (though I'm unsure what they are). >=20 Can you send me a script(1)-ed build log? > >=20 > > > It seems people have successfully built FreeBSD for ARM. However, the > > > instructions I'm seeing from a little bit of googling have turned up > > > pretty outdated posts. > > >=20 > > > You can probably tell I'm a newb at ARM on FreeBSD. What ought I do > > > next? > > >=20 > >=20 > > Are you aware that we have FreeBSD/arm images on FTP now? Not that I am > > trying to deter you from building your own images, but if you're just > > looking for an image to install to get your RPI running FreeBSD, we have > > you covered. :-) >=20 > I've been toying with that pretty much all evening. It seems that fbsd > has a really hard time booting on the rpi. I'm getting this error pretty > much 90% of the time when I try to boot: >=20 > http://lists.freebsd.org/pipermail/freebsd-arm/2014-January/007228.html >=20 > I'll play around with things a bit more. I have a semi-functional system > now. I mainly want to be able to build my own images so I can publish > nightly builds of my ASLR work now that Oliver and I just added support > for [nearly all|all] architectures fbsd supports. Do you have a slower SD card you can try? I've seen that happen sporadically with Class 10 SD cards, but have not yet seen it on lesser speed SD cards. (I still boot-test faster SD cards, but haven't hit this issue in a while though.) Glen --9I0HVnGRacHebCDW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTPP1rAAoJELls3eqvi17Q4W8QANFcCraQIQa04tU2bGvffLFH kiLXUkBjI0GcDk3dLIu+ygTkEuugNt/HTsgjMygx+nOxSRfC+j5S6XAFLA2J3E6E R/fGczq9cMmJtjTeoSt/+lm0eFSPuOd1gdk33ltBFjhvDvw+/gZPtq79xc+YtZk0 kZ3bigejDXcEFUbFUb28oFMX6pp/71U49t6g1yxMRQLKX57krTutu0VfPv03qhrG UkG05B8LgTYoWX8O8l31ha7TJixl4fyk/C82jdPoJDXnXrmkc/SlTJY3LsPNQT9O 44qgpJP4+tTmfJ1Rd6qSiYo5Spr2SGY+TYFNIUYtaRl+AEeBb8UDiPrzKzeNRMHF KiOu92TGZVmAJDQ0eeItD6aXuYkZ0t2j48Z+wPkUhPNDlbs4P0jKfOMD0J3zLujS z3j1lO/y0OBMBnzKHzPrsvtQb3k4QBcnhG3WO8JDrxMRMNwQ3F0jku/laHQv7G/U jmWZtI1Gjjb0mqv8PwfgGSfHNDPh6cGNMdi0lraSdugzo07SnnOjRWnDhpzKjMTE s3hSmE1IkMLbXe3O3IPlnszi8vwPaUr0t3Kw6hA43E878Sqnylv6ngZrzguFEY3F mIRER3D9qE0F+R4NwcG1B05IVRkh80IF3jkfUbfnTVBRWCmEpRRv90o2zc6XhqOj +Sj1mwhIDQYyv8ERDKRO =SC7w -----END PGP SIGNATURE----- --9I0HVnGRacHebCDW-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 06:28:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C75C88AB; Thu, 3 Apr 2014 06:28:15 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7047DE41; Thu, 3 Apr 2014 06:28:15 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id c9so1385526qcz.33 for ; Wed, 02 Apr 2014 23:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4iQIfNtRJ1UC3Ldrzy4aWGcq0UJhZ4nkCiCGWz07zFk=; b=t+1UjaSY3OJM1j10Ir0y26Z+3iezhvCcdi7xoTdKeC1CB8+gRidN4IYEEXg00UleB2 iWZzUXlYw18QsTPDTOww2kBg2RZmQoVfbO0Ai3fWcYMTpm7Zb8meygs06BoGQiNb8KWL ImmQvSQqECcKWAgoG545RiWIA4sFPZ3ZZS0dfgOP5NpeJIOnrlUr1850CKP31fcrn9ru VBPFA3u3ysVSRZ/iEQXeVH2DPrMtvadCIfHLLgh+bQprMdn4uw8OQHUsYB0yomQtyZoe uMU7yUj7fIxi8UxsgevHROSmijrRhwe9UEXvG/4rjFCj3arRXraFSymBr39ym9zR5cKT RT1w== X-Received: by 10.140.80.112 with SMTP id b103mr85633qgd.98.1396506494618; Wed, 02 Apr 2014 23:28:14 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id d15sm8360030qae.23.2014.04.02.23.28.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Apr 2014 23:28:13 -0700 (PDT) Date: Thu, 3 Apr 2014 02:28:11 -0400 From: Shawn Webb To: Glen Barber Subject: Re: Building an image for Raspberry Pi Message-ID: <20140403062811.GE71905@pwnie.vrt.sourcefire.com> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <20140403054106.GT14379@glenbarber.us> <20140403061443.GD71905@pwnie.vrt.sourcefire.com> <20140403061923.GW14379@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wTWi5aaYRw9ix9vO" Content-Disposition: inline In-Reply-To: <20140403061923.GW14379@glenbarber.us> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 06:28:15 -0000 --wTWi5aaYRw9ix9vO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Apr 03, 2014 02:19 AM -0400, Glen Barber wrote: > On Thu, Apr 03, 2014 at 02:14:43AM -0400, Shawn Webb wrote: > > On Apr 03, 2014 01:41 AM -0400, Glen Barber wrote: > > > You need to build the XDEV stuff for the build environment. > > >=20 > > > Something like: make -C /usr/src XDEV=3Darm XDEV_ARCH=3Darmv6 > > >=20 > > > should do the trick. > >=20 > > Yeah, I have the xdev stuff installed. It kinda seems like just using > > this xdev stuff isn't sufficient. It seems u-boot might require some > > gcc-centric items (though I'm unsure what they are). > >=20 >=20 > Can you send me a script(1)-ed build log? I'd be happy to. Do you want the build log of the u-boot build through Crochet or of the xdev build? xdev builds fine, just not u-boot via Crochet. >=20 > > >=20 > > > > It seems people have successfully built FreeBSD for ARM. However, t= he > > > > instructions I'm seeing from a little bit of googling have turned up > > > > pretty outdated posts. > > > >=20 > > > > You can probably tell I'm a newb at ARM on FreeBSD. What ought I do > > > > next? > > > >=20 > > >=20 > > > Are you aware that we have FreeBSD/arm images on FTP now? Not that I= am > > > trying to deter you from building your own images, but if you're just > > > looking for an image to install to get your RPI running FreeBSD, we h= ave > > > you covered. :-) > >=20 > > I've been toying with that pretty much all evening. It seems that fbsd > > has a really hard time booting on the rpi. I'm getting this error pretty > > much 90% of the time when I try to boot: > >=20 > > http://lists.freebsd.org/pipermail/freebsd-arm/2014-January/007228.html > >=20 > > I'll play around with things a bit more. I have a semi-functional system > > now. I mainly want to be able to build my own images so I can publish > > nightly builds of my ASLR work now that Oliver and I just added support > > for [nearly all|all] architectures fbsd supports. >=20 > Do you have a slower SD card you can try? I've seen that happen > sporadically with Class 10 SD cards, but have not yet seen it on lesser > speed SD cards. (I still boot-test faster SD cards, but haven't hit > this issue in a while though.) The one I'm currently using is a class 10 card, so maybe that's it. I've got a class 2 microsd card with an adapter that I'll try. I'll report back soon-ish with results. --wTWi5aaYRw9ix9vO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTPP96AAoJEGqEZY9SRW7uHq8P/RTmDbW+1ZNioTpDstuFeO81 PdC7UsbF5xZW3eK691xviIwAMt5fvsywOraGRyUgCV4kjiC0JLk6J7G3XV1DwC/r NWYcqsvgLfmzW2QuUaO4ExvH/VxrhfkdEIYGpKY6JvdD1Ld974z1Fg+08+QPzBJ/ qVxna3qONw1lsXHgCcE+2trCjjvcGsAuoGfTphMVcOR5DOG9ap+R/stqTtcI/1om rXmXj/ddMWjGU2XDl8+MHT1cPx6+N4yKq24FA4dRGjFwcuR0yH3EzJ8NdAbjkLFZ moUG3ucY2lIvy1vA/cBkCSHL4SOLcVZzyuSKP5qbjeMOhvbjUq6yJxMV25FAE+ah kjw/ccXacAhExFeXjxEYSCa02JFhaqCO2s0NzN8oggvXTAejIeJ0o4TJl2ZNWn0W URhQ2kOeHCj1xoV7eiIcBYq3Ur+AVVxwEGuSDfl8Lfo7ZAcVzcSUVmLBUPGEvKtn CPIwRPmNVd3TbPQhGe6kH3/5pPRKK5QoWaIHbCq0GLrL2YoMIoTKFY5E+BBeoR2/ CZTuxIsj9Y8Ns6kzDT0m+XAzOUE4QX2f9bdLoIMnKyFsCH7TExYO/+945p5kbRf1 zKXh32mzvRELRErl1XFFohLS4FWkeS62XSnGmZbKSz7qeE0lditMQfdQjl4jJ/Vw NYXa5TniYbCTwszNH/JS =NZF1 -----END PGP SIGNATURE----- --wTWi5aaYRw9ix9vO-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 06:31:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76624900; Thu, 3 Apr 2014 06:31:03 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.glenbarber.us", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32606ED6; Thu, 3 Apr 2014 06:31:03 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id C89DCBFF4; Thu, 3 Apr 2014 06:31:01 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us C89DCBFF4 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 3 Apr 2014 02:30:59 -0400 From: Glen Barber To: Shawn Webb Subject: Re: Building an image for Raspberry Pi Message-ID: <20140403063059.GX14379@glenbarber.us> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <20140403054106.GT14379@glenbarber.us> <20140403061443.GD71905@pwnie.vrt.sourcefire.com> <20140403061923.GW14379@glenbarber.us> <20140403062811.GE71905@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3ioKt2kN+IccB5F4" Content-Disposition: inline In-Reply-To: <20140403062811.GE71905@pwnie.vrt.sourcefire.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 06:31:03 -0000 --3ioKt2kN+IccB5F4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 03, 2014 at 02:28:11AM -0400, Shawn Webb wrote: > On Apr 03, 2014 02:19 AM -0400, Glen Barber wrote: > > On Thu, Apr 03, 2014 at 02:14:43AM -0400, Shawn Webb wrote: > > > On Apr 03, 2014 01:41 AM -0400, Glen Barber wrote: > > > > You need to build the XDEV stuff for the build environment. > > > >=20 > > > > Something like: make -C /usr/src XDEV=3Darm XDEV_ARCH=3Darmv6 > > > >=20 > > > > should do the trick. > > >=20 > > > Yeah, I have the xdev stuff installed. It kinda seems like just using > > > this xdev stuff isn't sufficient. It seems u-boot might require some > > > gcc-centric items (though I'm unsure what they are). > > >=20 > >=20 > > Can you send me a script(1)-ed build log? >=20 > I'd be happy to. Do you want the build log of the u-boot build through > Crochet or of the xdev build? xdev builds fine, just not u-boot via > Crochet. >=20 If XDEV build is fine, no need to send that. Just the u-boot log then. > >=20 > > > >=20 > > > > > It seems people have successfully built FreeBSD for ARM. However,= the > > > > > instructions I'm seeing from a little bit of googling have turned= up > > > > > pretty outdated posts. > > > > >=20 > > > > > You can probably tell I'm a newb at ARM on FreeBSD. What ought I = do > > > > > next? > > > > >=20 > > > >=20 > > > > Are you aware that we have FreeBSD/arm images on FTP now? Not that= I am > > > > trying to deter you from building your own images, but if you're ju= st > > > > looking for an image to install to get your RPI running FreeBSD, we= have > > > > you covered. :-) > > >=20 > > > I've been toying with that pretty much all evening. It seems that fbsd > > > has a really hard time booting on the rpi. I'm getting this error pre= tty > > > much 90% of the time when I try to boot: > > >=20 > > > http://lists.freebsd.org/pipermail/freebsd-arm/2014-January/007228.ht= ml > > >=20 > > > I'll play around with things a bit more. I have a semi-functional sys= tem > > > now. I mainly want to be able to build my own images so I can publish > > > nightly builds of my ASLR work now that Oliver and I just added suppo= rt > > > for [nearly all|all] architectures fbsd supports. > >=20 > > Do you have a slower SD card you can try? I've seen that happen > > sporadically with Class 10 SD cards, but have not yet seen it on lesser > > speed SD cards. (I still boot-test faster SD cards, but haven't hit > > this issue in a while though.) >=20 > The one I'm currently using is a class 10 card, so maybe that's it. I've > got a class 2 microsd card with an adapter that I'll try. I'll report > back soon-ish with results. Ok, thanks for experimenting. I thought there was a fix committed for this, but maybe I'm wrong. Glen --3ioKt2kN+IccB5F4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTPQAjAAoJELls3eqvi17QIKMP/AiuWSYd77MeLqz0cCVbE4qP 2Ftzsyu+cOk7PjSJjze/fFv03StcZY6EBidVqojmWOrzFiXwOiaYIm0oscRrUibV sSKweCQJwUdDVVvQn8R/2L+ZmsFCAoxbtrEzT83QdLDDI5PD3KAufW9B4RUA9Fqo oDO6w82e7zhWempf6kFizrTQl5LZ21B4flTQv9RIFA96aoBVVGJnxsjY2BENBICb LQBDiR2+KcX6Ee5+VcMEe7hhiZlEf8A7EOJ5BtsVWq+ik3cj0oI8yhLlX/crmzMj jSYK5VKKZxYgD1H0gO4yN9V66Mhy+eBfYAuDypwrgMpfRUnCoufL2CEi7LIvLwnP 1uKsY6+gDCRYGDjuDUVZ2+7o4I1N1BHJy25gu8025Mtdx9myKjPYmthYWXE59zlQ QE30CnKlDs/C5b8/XLI7vUtKRAFZuGnbq0L6xOQYVLmcLlUdpepee8M7gYFqKcsQ swGXJDbA3BQWDFLRgL07nJ+f6BJowA+ksWB0Ug/LgLHgoqqqY566VnXyUNr02Usy /JJXwvfqc/vzOdq5ATOV+4c7Q4LN+qCjB6og/DL9UNM8Lp87OTWG3RCailw071bt JdB96yXQ6Jgxv4jqp3EnJqWsgeQL4eo58hMWzQuSemaVsZOwSvHtWQ9UihYZvsNN 4LuDSZRJ7iLjZxgafV5f =OQjQ -----END PGP SIGNATURE----- --3ioKt2kN+IccB5F4-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 07:09:17 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C005A252; Thu, 3 Apr 2014 07:09:17 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 682AB1E0; Thu, 3 Apr 2014 07:09:17 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id w7so1403158qcr.36 for ; Thu, 03 Apr 2014 00:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4fmlgh/ozLs1jGd/goxYxN1UWYs8p8FR5rdn5t/m5gI=; b=ylsZshpDt7ECE82ngZbEPsjd24EVghyih5IfzT2sg7C4e1VxFWQyo51zMyS9fgmc3G I1OxDE8ej3RhPDgMV3NxUrhiXYGKNYXtEThYqzY76OrtKT0J0E7Wh9cgW1VTn4cWCbXO YFlwgvL0wDgtvXIwySXarusNvqfClJ7o+bf2DG7mdqn7dlRLqQXp+WO5WD+Yyq7jwx2I HXPGpcbmzxLoRjtRCilWUDfpaeVqzdV5T5OI+mcB8q29tqi9/Ma+ILNc08vcHkVAmrxY EkxM2Rgu98GR6SKeQfWTGZmMwGVFq0CHlAi3z82KT1E+7ehERsu9PBJP8i4JWvcpaB42 /G1A== X-Received: by 10.140.37.194 with SMTP id r60mr5329998qgr.61.1396508956553; Thu, 03 Apr 2014 00:09:16 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id f2sm8517319qaa.28.2014.04.03.00.09.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Apr 2014 00:09:15 -0700 (PDT) Date: Thu, 3 Apr 2014 03:09:12 -0400 From: Shawn Webb To: Glen Barber Subject: Re: Building an image for Raspberry Pi Message-ID: <20140403070912.GF71905@pwnie.vrt.sourcefire.com> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <20140403054106.GT14379@glenbarber.us> <20140403061443.GD71905@pwnie.vrt.sourcefire.com> <20140403061923.GW14379@glenbarber.us> <20140403062811.GE71905@pwnie.vrt.sourcefire.com> <20140403063059.GX14379@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ULyIDA2m8JTe+TiX" Content-Disposition: inline In-Reply-To: <20140403063059.GX14379@glenbarber.us> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 07:09:17 -0000 --ULyIDA2m8JTe+TiX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Apr 03, 2014 02:30 AM -0400, Glen Barber wrote: > If XDEV build is fine, no need to send that. Just the u-boot log then. >=20 It appears there's a bug report filed for Crochet, except that the comments on the bug report are old and don't reflect clang 3.4 and other recent changes to HEAD: https://github.com/kientzle/crochet-freebsd/issues/22 Without modification, this is the error log I get when trying to build u-boot: http://ix.io/brC If I set HOSTCC, CC, CXX, and LD in Crochet's config.sh to /usr/bin/armv6-freebsd-cc, I get this error: http://ix.io/brE I was able at some point to get further in the compilation process, but it's 3am here and I've forgotten what I did. If I figure it out, I'll report back. --ULyIDA2m8JTe+TiX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTPQkXAAoJEGqEZY9SRW7uwOAP/3PSDbUfj8hMxaBMQo5mqCUX Nag8akEF9gH9PRO7DBTgXqtMvtmjKNocnH1bn65gShL9Eng2AcqPtbPL8dmKoWi4 SYmv71CjZqa9hv3I88h3lhUMsvr2Q7/JlVaiVGVM147wJ9vR5Ibw6BlH4geYN/GN QZHrEKmWHMUP4fXY+evoZacaIMacEsTGRcEZUcB9a1MbENbWc0j+7HE+XEyiDCdN H9HPL8IsCAVsHnXZoCS3lJb8TM7QCQo1DUSb5X4EDSVuT9IeMALZi8/6MRkH7cHn /48fsb780c0pVOdRxcNfzLFQqOu7KU2Jyqo/WHdH7a1ZE2m8bHjtzDb4PHLs+VXZ gD4Q+XQlMMEY8SYLmpMQNc39XFWRxDKeLnJ8fIaFKZDd/Xlp+zKkLiZZEaRbMP/O oGHx0uM5b/OqH4C/ne5yS5bszksM2gLKabz23Fp5Sv/0bR3+EOoraZIgv1WiJn4H S7Z+YxQuXzOZSvxR9GAbpauHEtY5uzQ1Oh+uShS+Xa4pB8Vr5DSL2F9Cmkie0wTV nbISNrTlsRsYiY2ZW/qFZbdyx4TjmWeHExsi2v3jSJwtGMYYESOrslOIjqS8D43f OnSJ1IFT3IPaIzrUqQVrrQhTN1El1ZA0pfRI6LGKY2G7AlmF7PWNkNhRP0In8OTH zRdOL78YJHbkwhPhbvyw =Jc/2 -----END PGP SIGNATURE----- --ULyIDA2m8JTe+TiX-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 3 15:53:31 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39EACC43; Thu, 3 Apr 2014 15:53:31 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B09AD72; Thu, 3 Apr 2014 15:53:30 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WVjxD-000JWf-Bj; Thu, 03 Apr 2014 15:53:23 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s33FrKQE087327; Thu, 3 Apr 2014 09:53:20 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+wXwB97Lg/W3eK2claKr2y Subject: Re: Building an image for Raspberry Pi From: Ian Lepore To: Glen Barber In-Reply-To: <20140403063059.GX14379@glenbarber.us> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <20140403054106.GT14379@glenbarber.us> <20140403061443.GD71905@pwnie.vrt.sourcefire.com> <20140403061923.GW14379@glenbarber.us> <20140403062811.GE71905@pwnie.vrt.sourcefire.com> <20140403063059.GX14379@glenbarber.us> Content-Type: text/plain; charset="us-ascii" Date: Thu, 03 Apr 2014 09:53:20 -0600 Message-ID: <1396540400.81853.284.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:53:31 -0000 On Thu, 2014-04-03 at 02:30 -0400, Glen Barber wrote: > On Thu, Apr 03, 2014 at 02:28:11AM -0400, Shawn Webb wrote: > > On Apr 03, 2014 02:19 AM -0400, Glen Barber wrote: [...] > > > > > > Do you have a slower SD card you can try? I've seen that happen > > > sporadically with Class 10 SD cards, but have not yet seen it on lesser > > > speed SD cards. (I still boot-test faster SD cards, but haven't hit > > > this issue in a while though.) > > > > The one I'm currently using is a class 10 card, so maybe that's it. I've > > got a class 2 microsd card with an adapter that I'll try. I'll report > > back soon-ish with results. > > Ok, thanks for experimenting. I thought there was a fix committed for > this, but maybe I'm wrong. > > Glen No, we've never figured out the RPi sdcard mystery. We've tried forcing the driver to run the card bus faster and slower and while it sometimes seems to change things, it's never really been a fix. I've gone as far as putting an oscilliscope on the clock and data lines and everything looks normal up to the point where the bus locks up, then it "just stops working". There must be some subtle timing thing with our driver that gets the hardware into a bad state, and the u-boot and linux drivers are just enough different that they don't encounter it. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Apr 4 01:02:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 826EE3BC for ; Fri, 4 Apr 2014 01:02:27 +0000 (UTC) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5901D395 for ; Fri, 4 Apr 2014 01:02:27 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id um1so2653199pbc.16 for ; Thu, 03 Apr 2014 18:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=/FGNV7gb3IhQGxMHA2KmNz41hVvIJUH7VVsQYRIRNvQ=; b=PaYB9ZMYf87aJ2K/FrcyWJrLP6e41QxXLH9EEfPtZCf6rgW//d8C69zmmtgN8zFJdq jUyiu7TjzufyM52dQOpHJABBQHBYs2hB9tDoW2MsWN2Q2PoMG0LkYJT1Hj6WA6HlQ+x7 pnsU6uttBflZ+dFuyFwjj8wFoLJbyKITekS/aucdNbIahnmTigynolyYGmVNTzdP6Rdd X9xVmOVGYD7AI8N/c0DU7vdbbawj0Ga9agxuOEVtDJa3XcDNdv5om2RB+uvys//N+e/1 DctPZcA8V01RAlOmt/hOFbwJXoLRHaqAucxFrfVt2DKLzuc3a8FH9cZg4/KhcGGibmA4 IqAQ== X-Received: by 10.68.90.132 with SMTP id bw4mr11268773pbb.136.1396573347008; Thu, 03 Apr 2014 18:02:27 -0700 (PDT) Received: from [172.16.1.21] ([202.89.38.236]) by mx.google.com with ESMTPSA id h6sm13866493pbl.75.2014.04.03.18.02.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 18:02:26 -0700 (PDT) From: Stephen Woolerton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: binutils on Raspberry Pi Message-Id: <9F9940F6-2DC6-45F1-A483-A4BC8EDEB384@gmail.com> Date: Fri, 4 Apr 2014 14:02:21 +1300 To: FreeBSD ARM Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 01:02:27 -0000 Hi everyone, Has anyone managed to get binutils compiling on a Raspberry Pi? (I would = like to compile GNUstep, and binutils is a dependancy.) Re the bug report at: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D175605,= I have the same issue, and hoping someone has got binutils working, and = can say how they did it. Thanks Stephen= From owner-freebsd-arm@FreeBSD.ORG Fri Apr 4 03:00:00 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD1A075D for ; Fri, 4 Apr 2014 03:00:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 905A6E29 for ; Fri, 4 Apr 2014 03:00:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s34300wO087603 for ; Fri, 4 Apr 2014 03:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s34300ve087602; Fri, 4 Apr 2014 03:00:00 GMT (envelope-from gnats) Resent-Date: Fri, 4 Apr 2014 03:00:00 GMT Resent-Message-Id: <201404040300.s34300ve087602@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, Edgar Martinez Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5811E6CB for ; Fri, 4 Apr 2014 02:53:17 +0000 (UTC) Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44BF6DF8 for ; Fri, 4 Apr 2014 02:53:17 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s342rHS0025555 for ; Fri, 4 Apr 2014 02:53:17 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s342rHJT025543; Fri, 4 Apr 2014 02:53:17 GMT (envelope-from nobody) Message-Id: <201404040253.s342rHJT025543@cgiserv.freebsd.org> Date: Fri, 4 Apr 2014 02:53:17 GMT From: Edgar Martinez To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/188249: xdev tools broken -HEAD rev-264095 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 03:00:00 -0000 >Number: 188249 >Category: arm >Synopsis: xdev tools broken -HEAD rev-264095 >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: Fri Apr 04 03:00:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Edgar Martinez >Release: HEAD rev-264095 >Organization: OCMS >Environment: FreeBSD pickles 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Fri Jan 17 01:46:25 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 >Description: Building xdev tools for arm image. cmd: armv6-freebsd-cc -print-file-name=include out: include should be... out: /usr/armv6-freebsd/usr/lib/include >How-To-Repeat: Fresh FBSD10 install. No other changes other than svn co of head followed by "make XDEV=arm XDEV_ARCH=armv6 xdev" >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Fri Apr 4 17:58:48 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5554173C; Fri, 4 Apr 2014 17:58:48 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B84FD0E; Fri, 4 Apr 2014 17:58:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s34HwmHm099087; Fri, 4 Apr 2014 17:58:48 GMT (envelope-from bapt@freefall.freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s34Hwlft099086; Fri, 4 Apr 2014 17:58:47 GMT (envelope-from bapt) Date: Fri, 4 Apr 2014 17:58:47 GMT Message-Id: <201404041758.s34Hwlft099086@freefall.freebsd.org> To: wink15987@gmail.com, bapt@FreeBSD.org, freebsd-arm@FreeBSD.org From: bapt@FreeBSD.org Subject: Re: arm/188249: xdev tools broken -HEAD rev-264095 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 17:58:48 -0000 Synopsis: xdev tools broken -HEAD rev-264095 State-Changed-From-To: open->closed State-Changed-By: bapt State-Changed-When: Fri Apr 4 17:58:47 UTC 2014 State-Changed-Why: Fixed. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=188249 From owner-freebsd-arm@FreeBSD.ORG Fri Apr 4 18:00:01 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BD2D7B5 for ; Fri, 4 Apr 2014 18:00:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 69D21D26 for ; Fri, 4 Apr 2014 18:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s34I01P1099289 for ; Fri, 4 Apr 2014 18:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s34I01Y8099288; Fri, 4 Apr 2014 18:00:01 GMT (envelope-from gnats) Date: Fri, 4 Apr 2014 18:00:01 GMT Message-Id: <201404041800.s34I01Y8099288@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: arm/188249: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dfilter service List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 18:00:01 -0000 The following reply was made to PR arm/188249; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/188249: commit references a PR Date: Fri, 4 Apr 2014 17:58:38 +0000 (UTC) Author: bapt Date: Fri Apr 4 17:58:33 2014 New Revision: 264131 URL: http://svnweb.freebsd.org/changeset/base/264131 Log: Prevent XDTP from being a relative path XDTP is used as the default SYSROOT for clang and thus should be an absolute path. PR: arm/188249 Submitted by: Edgar Martinez Reviewed by: imp Modified: head/Makefile.inc1 Modified: head/Makefile.inc1 ============================================================================== --- head/Makefile.inc1 Fri Apr 4 17:57:49 2014 (r264130) +++ head/Makefile.inc1 Fri Apr 4 17:58:33 2014 (r264131) @@ -1875,7 +1875,11 @@ NOFUN=-DNO_FSCHG MK_HTML=no MK_INFO=no - CPUTYPE=${XDEV_CPUTYPE} XDDIR=${XDEV_ARCH}-freebsd -XDTP?=usr/${XDDIR} +XDTP?=/usr/${XDDIR} +.if ${XDTP:N/*} +.error XDTP variable should be an absolute path +.endif + CDBENV=MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX}/${XDDIR} \ INSTALL="sh ${.CURDIR}/tools/install.sh" CDENV= ${CDBENV} \ _______________________________________________ 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 Fri Apr 4 20:58:19 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A432FAD for ; Fri, 4 Apr 2014 20:58:19 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50451A1 for ; Fri, 4 Apr 2014 20:58:19 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WWBBp-0007iQ-Rb for freebsd-arm@FreeBSD.org; Fri, 04 Apr 2014 20:58:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s34KwFa3088794 for ; Fri, 4 Apr 2014 14:58:15 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18lBWXNfzx6DLcmFCN8uYB4 Subject: WANDBOARD.common kernel config will be deleted From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Fri, 04 Apr 2014 14:58:15 -0600 Message-ID: <1396645095.81853.321.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:58:19 -0000 This is just a heads-up for anyone who has a custom kernel config that's doing "include WANDBOARD.common" ... that config is going to be deleted soon. Please change your include to "IMX6" instead (they're equivelent except that SMP is enabled in IMX6). I've adjusted the three WANDBOARD- configs to include IMX6. Those board-type configs are eventually going to be deleted too, but we're missing a couple bits of build infrastructure needed to specify which .dts file(s) you want compiled if they're not compiled into the kernel. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Apr 4 21:11:21 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90BD477B for ; Fri, 4 Apr 2014 21:11:21 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6723B229 for ; Fri, 4 Apr 2014 21:11:20 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WWBOM-0008OF-2H for freebsd-arm@FreeBSD.org; Fri, 04 Apr 2014 21:11:14 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s34LBBfk088814 for ; Fri, 4 Apr 2014 15:11:11 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+a9T+AZ2+ZEqauJinoVXMA Subject: ARM SMP is ready for prime time on FreeBSD From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Fri, 04 Apr 2014 15:11:11 -0600 Message-ID: <1396645871.81853.330.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 21:11:21 -0000 Thanks to the contributions of many dedicated freebsd-arm hackers over the past few months, it looks like SMP is now solid enough for everyday use. SMP has been "kinda working" for a while, but I think the pmap fixes we've been working on for the past few weeks have made things pretty robust. I've had continuous stress-testing on running on dual and quad-core boards with a multi-threaded app that maxes out all the cores with heavy floating point and network IO and haven't had any app crashes or kernel panics for a couple weeks. I've updated the kernel configs for the platforms I know have multiple cores, as of r264138. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Apr 4 22:43:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43CD96C7 for ; Fri, 4 Apr 2014 22:43:36 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0121FBFB for ; Fri, 4 Apr 2014 22:43:35 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id a108so4070402qge.13 for ; Fri, 04 Apr 2014 15:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=sHT/DHAbwiArE0fv/w0KDzS1ATlZzrjacr08/YRzWYI=; b=NWNs5IAQfzErpGrVrEbe+z0Mgy9iScHOQwPgIxWxLrtMXG0aF77BgG6cleRcnqgoUt Q/Msn/geD2HpohL/aUXPTFs3KPZPth/G6taKAiPebXnlr/dw3J2z4IsPpQmFhyiS9awd qWQSyJyFhyAIpe1gGIEtrDfQoqA3uoF7+xB7lLCS0nheyP3aUv9ERLLjsEsXvBJuDv0f tQAm9mDPfKvOYmCe+u3ChGAeslZXRrbUY3hVpKxvarO+0E+ZJrnonVQxWlJi9Dluigla KVxjZlCqFy8nsipjbj9r9ls4rTLZTao6r8ZJKvf7jsg5VmCqHjGJyDvp3QKwC/oyC0RB xMZA== X-Received: by 10.224.63.138 with SMTP id b10mr17528809qai.79.1396651415140; Fri, 04 Apr 2014 15:43:35 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id o16sm18809052qax.30.2014.04.04.15.43.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Apr 2014 15:43:34 -0700 (PDT) Date: Fri, 4 Apr 2014 18:43:31 -0400 From: Shawn Webb To: freebsd-arm@freebsd.org Subject: HEAD build broken Message-ID: <20140404224331.GF3830@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Zw+/jwnNHcBRYYu" Content-Disposition: inline X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 22:43:36 -0000 --/Zw+/jwnNHcBRYYu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey all, It looks like building 11-CURRENT is broken for the RPI-B. I've pasted the buildworld log here: http://ix.io/buI I'm building on an 11-CURRENT amd64 host. Should I file a PR? Thanks, Shawn --/Zw+/jwnNHcBRYYu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTPzWTAAoJEGqEZY9SRW7umWsP/jdLCdpEEqvsXHbGneO9XEQg wDOX5uepajNVchttsRTVPUq0mZGraOWiBq6380TksjRLtWZj23npL7VODiVYpUq0 ZXxepHdft7OuWOvGbDXzLO6dPG22UfuKLl/2luDZ+dCF9tX4DGmANjHAC+uiFivH MzHvKixlz6PhqhtceVVu4dsZILUwwX8n4Cl8R2CATil8oWyZUSZGom9H1wJzLI+M gymV9iDNYwpHfsbndtRSV03UbGYp6pCpuPObQ1zIcBOvb62i9Myu6IOul8U6Jrme xoPWWbAMTERxRQTpM6LMqCitk3zjBjjEtke7npo4AWIzG1Iu0Ya1dwOAHn6gkg9U zedgc71Bxx+thtd3583nkUL/KBu+J64yhtMQWVmTgn6xDYFYm/ddDqBiHwlcIHDA sUDJBTU+5lOQP7JpGN1obKQMSN/7ofMSM5Y5zlVTDRskWSKHfHv6cs/OE+M9OPHq QYA5Kcl3M9negVJydlnKb9gbKm9M3OTUNroO52ozLoKYmA5XysGKbBAlvB3GIr1V GhaW5sIza+AMYkR3m9S8euXnm//GE2OqtcAgYBzJAGOvGjJd0XEly9Dzg8mYlfgm gYa9bCEo9dwDM4J4uVadrjvkf2lGb1aQVEUOcMpGRJSzu6FXzNrKLGnq4f7dCWMv VGo6lzE04bheKe5ch5Uo =HBAA -----END PGP SIGNATURE----- --/Zw+/jwnNHcBRYYu-- From owner-freebsd-arm@FreeBSD.ORG Fri Apr 4 23:12:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDE6B47F for ; Fri, 4 Apr 2014 23:12:59 +0000 (UTC) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB171E69 for ; Fri, 4 Apr 2014 23:12:59 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id ur14so1568486igb.14 for ; Fri, 04 Apr 2014 16:12:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YefUimMowxIBOuRTZgaTfN3/aURKnXN0CsWpm4ZhPVI=; b=eqQKqdfiDYAjvhExGc9PH47FZWBg9qPUMFb8PzZRo0uDJo48cIHTGYvUW26cM+rNgT AcOHOwE6fdBYRKa51h7X5wWVHIu1I/5ydexC56jc4iUvjr6wIad1UDGF3USNdKecgCit SoZ/sd4/e4jMbzYOt2s4FlP152cPEtPpyrrdgiaJZoueQkLzyGhNTbIqIQZszdDelkr1 n3Z6IEN7OdFoWXd/Gad8ZvKitdnrp6sNpXFAWAEBV7TPMA1G7txtHIzIMnYl8YgSRqLe dlMG+WgXmI2FKetFBwoXuc7SlDlE1EMxCaZ9BF5Kl5et0jMgLeBIxHEUgu1UNWf21aFP QpTQ== X-Gm-Message-State: ALoCoQnjfGj6M2XoAtOWtSIT3Rhjkp5gqLYdR+ud0uAdbTOqYDl+PnnFA8r1Pz/3Oum5gaNafR8ts3zxpzgjiMpMSrDFO8lG16bt/i5ihIY7Jhc03rGLh38= X-Received: by 10.50.28.101 with SMTP id a5mr6217359igh.46.1396653172758; Fri, 04 Apr 2014 16:12:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.128.200 with HTTP; Fri, 4 Apr 2014 16:12:37 -0700 (PDT) In-Reply-To: <1396645871.81853.330.camel@revolution.hippie.lan> References: <1396645871.81853.330.camel@revolution.hippie.lan> From: "Lundberg, Johannes" Date: Sat, 5 Apr 2014 08:12:37 +0900 Message-ID: Subject: Re: ARM SMP is ready for prime time on FreeBSD To: Ian Lepore Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 23:13:00 -0000 This is great news. Thank you very much! -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Sat, Apr 5, 2014 at 6:11 AM, Ian Lepore wrote: > Thanks to the contributions of many dedicated freebsd-arm hackers over > the past few months, it looks like SMP is now solid enough for everyday > use. SMP has been "kinda working" for a while, but I think the pmap > fixes we've been working on for the past few weeks have made things > pretty robust. I've had continuous stress-testing on running on dual > and quad-core boards with a multi-threaded app that maxes out all the > cores with heavy floating point and network IO and haven't had any app > crashes or kernel panics for a couple weeks. > > I've updated the kernel configs for the platforms I know have multiple > cores, as of r264138. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 01:50:05 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75749CD3 for ; Sat, 5 Apr 2014 01:50:05 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4AD64C4B for ; Sat, 5 Apr 2014 01:50:05 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WWFkB-000FMM-Sn; Sat, 05 Apr 2014 01:50:04 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s351o1Uk088893; Fri, 4 Apr 2014 19:50:01 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/dLqbE/dltnMrRem1YtxsR Subject: Re: HEAD build broken From: Ian Lepore To: Shawn Webb In-Reply-To: <20140404224331.GF3830@pwnie.vrt.sourcefire.com> References: <20140404224331.GF3830@pwnie.vrt.sourcefire.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 04 Apr 2014 19:50:01 -0600 Message-ID: <1396662601.81853.332.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 01:50:05 -0000 On Fri, 2014-04-04 at 18:43 -0400, Shawn Webb wrote: > Hey all, > > It looks like building 11-CURRENT is broken for the RPI-B. I've pasted > the buildworld log here: http://ix.io/buI > > I'm building on an 11-CURRENT amd64 host. > > Should I file a PR? > > Thanks, > > Shawn I can't reproduce that failure at r263912. Do you have anything in make.conf or src.conf? I tried with both clang and gcc. gcc failed, but not the way yours did (it failed on some floating point assember instructions). -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 11:02:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FFEBF1B for ; Sat, 5 Apr 2014 11:02:19 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BABB2D7F for ; Sat, 5 Apr 2014 11:02:18 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id x13so4689342wgg.9 for ; Sat, 05 Apr 2014 04:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=fBGpSQB2mHTrUwJX1xgEkW18KEyuZQ/k12UTAXRrLeA=; b=PvPYskrEIep52MjywnpOtrX5zaEzLsj578g96IonI2tMYe+ToNdfjwlYeHc+onv/6z 47kDDIc4BThdbsDarXbpPbmff6S1ea8sjnAkREdu+z2rFnAv6gM3wy6uhjUT/1rc9pZb 8hcPTx7sLssP92/NHlmfVd8ZixNHGtyuqZ8tqqoXhM+1Izr3p7RkyfzStxCzdpzV+h52 SU5SZ/wxOeUjmvTHcc0+M17akT8d9umv0deXv8g25KeAGbqo1MgM2iFMkeQqM1NE5eu1 T7oAc792mvP7jqGlf7VTG7wwElTGhL4eYrBM29OfZEZ4YrXJi4CyWeaFe4m7TxJBaWJC 7ALg== X-Received: by 10.180.187.225 with SMTP id fv1mr11335863wic.14.1396695737080; Sat, 05 Apr 2014 04:02:17 -0700 (PDT) Received: from [192.168.0.10] (178-83-152-199.dynamic.hispeed.ch. [178.83.152.199]) by mx.google.com with ESMTPSA id y51sm26258600eeu.0.2014.04.05.04.02.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Apr 2014 04:02:16 -0700 (PDT) Message-ID: <533FE2B6.8040009@gmail.com> Date: Sat, 05 Apr 2014 13:02:14 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ARM Subject: Dreamplug: Panic when copying from USB stick to internal SD-Card (USB) 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.17 Precedence: list Reply-To: mattia.rossi.mate@gmail.com List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 11:02:19 -0000 Hi all, does anyone have a hint on what's happening here? I keep running into panics when copying world from the USB stick i boot from, to the internal SD-Card where I want to boot from next. backtrace: root@dreamplug:/ # panic: Lock vm object not exclusively locked @ /usr/devel/dre amplug/sys/arm/arm/pmap.c:4474 KDB: enter: panic [ thread pid 8 tid 100040 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 8 tid 100040 td 0xc3c6d320 db_trace_self() at db_trace_self pc = 0xc0db048c lr = 0xc0947f44 (db_hex2dec+0x4d4) sp = 0xde03da10 fp = 0xde03da28 r10 = 0xc0f562ec db_hex2dec() at db_hex2dec+0x4d4 pc = 0xc0947f44 lr = 0xc09478b8 (db_command_loop+0x300) sp = 0xde03da30 fp = 0xde03dad0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 db_command_loop() at db_command_loop+0x300 pc = 0xc09478b8 lr = 0xc0947608 (db_command_loop+0x50) sp = 0xde03dad8 fp = 0xde03dae8 r4 = 0xc0e0500c r5 = 0xc0e2214d r6 = 0xc0f562d8 r7 = 0xde03dcc0 r8 = 0xc0f4a340 r9 = 0xc0f4a344 r10 = 0xc0eee390 db_command_loop() at db_command_loop+0x50 pc = 0xc0947608 lr = 0xc0949fe8 (X_db_symbol_values+0x250) sp = 0xde03daf0 fp = 0xde03dc10 r4 = 0x00000000 r5 = 0xc0f562e4 r6 = 0xc0f4a368 X_db_symbol_values() at X_db_symbol_values+0x250 pc = 0xc0949fe8 lr = 0xc0af1318 (kdb_trap+0xd4) sp = 0xde03dc18 fp = 0xde03dc38 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc0f4a368 r7 = 0xde03dcc0 kdb_trap() at kdb_trap+0xd4 pc = 0xc0af1318 lr = 0xc0dc2c60 (undefinedinstruction+0x25c) sp = 0xde03dc40 fp = 0xde03dcb8 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0dc2954 r7 = 0xe7ffffff r8 = 0xc3c6d320 r9 = 0xc0af0bc0 r10 = 0xde03dcc0 undefinedinstruction() at undefinedinstruction+0x25c pc = 0xc0dc2c60 lr = 0xc0db2034 (exception_exit) sp = 0xde03dcc0 fp = 0xde03dd18 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0xc0e1e26a r7 = 0xc0f3c2e0 r8 = 0xc3c6d320 r9 = 0xc0f57dc0 r10 = 0xc0f3c140 exception_exit() at exception_exit pc = 0xc0db2034 lr = 0xc0af0bb4 (kdb_enter+0x40) sp = 0xde03dd10 fp = 0xde03dd18 r0 = 0xc0f4a354 r1 = 0x00000000 r2 = 0xc0e25b59 r3 = 0x000000ab r4 = 0xc0e221a7 r5 = 0xde03dd54 r6 = 0xc0e1e26a r7 = 0xc0f3c2e0 r8 = 0xc3c6d320 r9 = 0xc0f57dc0 r10 = 0xc0f3c140 r12 = 0x00000000 kdb_enter() at kdb_enter+0x50 pc = 0xc0af0bc4 lr = 0xc0abc964 (kassert_panic+0x1cc) sp = 0xde03dd20 fp = 0xde03dd40 r4 = 0x00000100 kassert_panic() at kassert_panic+0x1cc pc = 0xc0abc964 lr = 0xc0abc9cc (kproc_shutdown) sp = 0xde03dd48 fp = 0xde03dd4c r4 = 0xc3c6d320 r5 = 0xc0f5cd10 r6 = 0xc0f55080 r7 = 0xc10720bc r8 = 0xc0e57eea r9 = 0xc0f55030 r10 = 0x000002fe kproc_shutdown() at kproc_shutdown pc = 0xc0abc9cc lr = 0xc3c6d320 (0xc3c6d320) sp = 0xde03dd54 fp = 0xde03dd68 r4 = 0xc0abc9cc r5 = 0xde03dd54 Unknown entry: 0 _end() at 0xc3c6d320 pc = 0xc3c6d320 lr = 0xc3c6d320 (0xc3c6d320) sp = 0xde03dd54 fp = 0xde03dd68 Unable to unwind into user mode db> Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 12:09:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B750A8E9; Sat, 5 Apr 2014 12:09:25 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75EE835A; Sat, 5 Apr 2014 12:09:25 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id i4so4716233oah.38 for ; Sat, 05 Apr 2014 05:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PjefAb7gQIURnLv0fexW2cx7ffkKPT4s6TewMC1CwVk=; b=yGlgEG8fPXf97JkzCIeyvw7cgs2DUFoeqO+1Wm0IGunyndSpw3cszep9/oerH8p4C0 pwl94BeBFngWmS4l/yhA0SZTB/D1WrTqRVnudw9Py3c46QCB2wbbGnBT7Gr7Kwb905px PHsxYjVg0gqlTnh4tUfp8t1EG/CxitcGsJPsWswgF1DMPIhKjRrM2I7xOljVmVMbVOYB EdIU+VicMPU2UaCpXxFnKHavT4jhIN+DGuNG1Tt9HlGp+UqGqRzfAxssH5Z3OF0azENE 0W4oMr9nvzwQPlLFe1gjKb+9+WsXJptyb84Wq0bV/lDYSO7fMzJryDqnptq4ZArnREUE YtpQ== MIME-Version: 1.0 X-Received: by 10.182.129.225 with SMTP id nz1mr1815640obb.47.1396699764802; Sat, 05 Apr 2014 05:09:24 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.76.10.101 with HTTP; Sat, 5 Apr 2014 05:09:24 -0700 (PDT) In-Reply-To: <1396645871.81853.330.camel@revolution.hippie.lan> References: <1396645871.81853.330.camel@revolution.hippie.lan> Date: Sat, 5 Apr 2014 14:09:24 +0200 X-Google-Sender-Auth: Pw97h9LbC-NYTyGNJoRtApEgcTw Message-ID: Subject: Re: ARM SMP is ready for prime time on FreeBSD From: Zbigniew Bodek To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 12:09:25 -0000 2014-04-04 23:11 GMT+02:00 Ian Lepore : > Thanks to the contributions of many dedicated freebsd-arm hackers over > the past few months, it looks like SMP is now solid enough for everyday > use. SMP has been "kinda working" for a while, but I think the pmap > fixes we've been working on for the past few weeks have made things > pretty robust. I've had continuous stress-testing on running on dual > and quad-core boards with a multi-threaded app that maxes out all the > cores with heavy floating point and network IO and haven't had any app > crashes or kernel panics for a couple weeks. > > I've updated the kernel configs for the platforms I know have multiple > cores, as of r264138. > > -- Ian > Great work guys. Thank you. Best regards zbb From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 14:09:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BA47412; Sat, 5 Apr 2014 14:09:53 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA0AE1A9; Sat, 5 Apr 2014 14:09:52 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id i17so4752456qcy.28 for ; Sat, 05 Apr 2014 07:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=GSbnP1+/YqPC2wHclljAGRvOnzRxLE5QaXHTXyATGfY=; b=oEPU+qUopBzlk1OM+4bLtEOu8+bohdLfUwQQXJLSwK3kwmt1npf6KOWS0DErujm6hV /GdvMqJ24jGDC5ok7rZwdsSjMeeYQy2lw/OAn5YFS2LEfIf+MW0nVGefyr8E3zEiU8du QeHR06nScJONnIHmnGrr8kC5JvqPgAoZMvW1qRlhDBSl8md63vR7dV1xPRtEzuMJzXGD QvmaOjaHoSwaLSsG3yC9lME3kkpSEry84LqUH6qJ0/nVaBMnd35QRirRj9F8cTsj66qv MJTzQ1gTA3j0dyWQuCGRC5IAoVfvwP63bh4F+wkwEdNMSLCg3ungXMf4rzyTm9NYWgle rX+g== X-Received: by 10.224.69.193 with SMTP id a1mr1080854qaj.95.1396703005566; Sat, 05 Apr 2014 06:03:25 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id s111sm15018780qge.19.2014.04.05.06.03.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Apr 2014 06:03:24 -0700 (PDT) Date: Sat, 5 Apr 2014 09:03:22 -0400 From: Shawn Webb To: Ian Lepore Subject: Re: HEAD build broken Message-ID: <20140405130322.GI3830@pwnie.vrt.sourcefire.com> References: <20140404224331.GF3830@pwnie.vrt.sourcefire.com> <1396662601.81853.332.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GlnCQLZWzqLRJED8" Content-Disposition: inline In-Reply-To: <1396662601.81853.332.camel@revolution.hippie.lan> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 14:09:53 -0000 --GlnCQLZWzqLRJED8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Apr 04, 2014 07:50 PM -0600, Ian Lepore wrote: > On Fri, 2014-04-04 at 18:43 -0400, Shawn Webb wrote: > > Hey all, > >=20 > > It looks like building 11-CURRENT is broken for the RPI-B. I've pasted > > the buildworld log here: http://ix.io/buI > >=20 > > I'm building on an 11-CURRENT amd64 host. > >=20 > > Should I file a PR? > >=20 > > Thanks, > >=20 > > Shawn >=20 > I can't reproduce that failure at r263912. Do you have anything in > make.conf or src.conf? I tried with both clang and gcc. gcc failed, > but not the way yours did (it failed on some floating point assember > instructions). I forgot about src.conf. I had some stale items in there from back when VirtualBox had issues with clang. Removing them fixed my build. Thanks! --GlnCQLZWzqLRJED8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTP/8aAAoJEGqEZY9SRW7u8JIP+QECRC8DHNCpoBbVSjCo5K3h W6IaQNhv16kqk1W9D3NatygU+xffbdJkxfHeTL6lx7ZCNQZCCnKAN5ut5S/DajNP uaNjCyuwRMQYxLjY5MfcxzU5UG3TFHZOYuDA8R23iSkkpdl1Q8ATwhZNy3oxcGCy n3PmI3YaVWqPqviY6x+HrFjK3sMOIYiTsg/O66rs7jqT6JZInMglMFxeWvgiB5CE PU/gg+a22rgMVwhSY95j9LrbwHXFaMVBsKYZVBYoMRlICYDP8upbfFHbQhmr4sus gZrO5JLaY/8nCdBKOuzlrIn7Jbwl60ZiBZLzb+HcWZFbkJHdOXFpi+kMW4yAI1K6 iQLEUtlY3hsy/byh/oIAGXW3Niz1q1ZsZaP1b58VSlr4j9s/x4dnV8jRVnj/NGrR tXbjtRcQ6IzsFcQ9kNn/d+iofNp7Y7EeWDO+g0obwUs5mjcUVoTHSyyGwCRIksjQ Fzo5CokFmqahVpOY9utHgZvpfzWdB7rq7xuJojKLii0qTVouVi0lxv8k7Jaa5sW7 FPv6SBbkOpyWgN2K29lnfl6c2gBv7Anv8j0cUaINP3lMmwT6u4izoQXNXU/YtPrm 3+UVHA+5pM7/9+fw3B4ghl45p1YLr8r/2e8ZrGmJrciAVhb7WlOAhUwnD/z6yKsg j9YBzJylsvIVC5lFm/u3 =S/mn -----END PGP SIGNATURE----- --GlnCQLZWzqLRJED8-- From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 15:37:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35AEEC34 for ; Sat, 5 Apr 2014 15:37:42 +0000 (UTC) Received: from iwiw03d.mail.t-online.hu (iwiw03d.mail.t-online.hu [84.2.42.68]) by mx1.freebsd.org (Postfix) with ESMTP id E979EDD8 for ; Sat, 5 Apr 2014 15:37:41 +0000 (UTC) Received: from fmx25.freemail.hu (fmx25.freemail.hu [195.228.245.75]) by iwiw03d.mail.t-online.hu (Postfix) with SMTP id 07DEC4EAC04 for ; Sat, 5 Apr 2014 15:08:05 +0200 (CEST) Received: (qmail 17039 invoked by uid 151); 5 Apr 2014 15:08:05 +0200 Received: from 195.228.245.211 (HELO xmldata04.freemail.private) (80.98.117.10) by fmx25.freemail.hu with SMTP; 5 Apr 2014 15:08:05 +0200 Received: from webmail by smtp gw id s35D84Xx040575; Sat, 5 Apr 2014 15:08:04 +0200 (CEST) Date: Sat, 5 Apr 2014 15:08:04 +0200 (CEST) From: Kover Attila Subject: Re: screen(1) crashes plus weird output for screen -ls To: freebsd-arm@freebsd.org Message-ID: X-Originating-IP: [80.98.117.10] X-HTTP-User-Agent: Unknown X-Original-User: koverat MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 15:37:42 -0000 Hi, I have some old RPi images which I was build (I use a modified image build = script from kernelnomicon.org), the oldest is r252056 from June 2013. I was= a distant memory that screen was worked some months ago, so I was booted t= hat old image, compiled screen from ports (r350213, recently fetched with s= vn) and the test shows that it is work with the old kernel version. root@freepi:~ # screen -ls There are screens on: 561.pts-0.freepi (Attached) 568.pts-2.freepi (Detached) 2 Sockets in /tmp/screens/S-root. root@freepi:~ # uname -a FreeBSD freepi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r252056M: Fri Jun 21 17= :59:17 CEST 2013 root@dlc-10c:/root/ujra/svnhead/obj/arm.armv6/root/ujr= a/svnhead/head/sys/RPI-B-DRS arm root@freepi:~ # screen --version Screen version 4.00.03 (FAU) 23-Oct-06 root@freepi:~ #=20 Best Regards Attila > Hi, >=20 > while working with screen(1) it dumps core very often on arm. > Using gdb on the core shows > (gdb) bt > #0 0x2029bc18 in strlen () from /lib/libc.so.7 > #1 0x0001e9a4 in ?? () > (gdb) > as the last function called every time. >=20 > Interestingly the output of "screen -ls" is a little bit weird an looks >=20 > There is a screen on: > 814.ttyu0.rpi (Attached) > -1073746664 Socket > =C3=90 =C3=A1 in =C2=B0=C3=B5=C3=BF=C2=BF8=C3=A8. >=20 > instead of the expected=20 >=20 > There is a screen on: > 814.ttyu0.rpi (Attached) > 1 Socket in /tmp/screens/S-root From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 16:25:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8111AB11 for ; Sat, 5 Apr 2014 16:25:11 +0000 (UTC) Received: from mailgate-01.zdv.uni-mainz.de (mailgate-01.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f1]) by mx1.freebsd.org (Postfix) with ESMTP id 103DA254 for ; Sat, 5 Apr 2014 16:25:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1396715112; x=1428251112; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=KLKKFAWJmxqZTgawh8O1xmxSVF3DoOu46mfI11tCmPY=; b=kIO4fLB95SmdSWoqr3g16bdRSnKTqNIxYZKT7yRQfoNDRuRjJUro9L4l jnakTufI4//NWAw8A/P4OQzCOVuAlPlZ1r6xuYFsI2pXHzPh2nD8SF9tk pnwKebQVzGTD3WJ+x5jO+qauY0bSqtHbnZTGyY+m94dEgPv9lXM1gboxP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAAElQFMKXgZQ/2dsb2JhbABYgmWBM4wluRd0giyBCwGBACYBBBuHcQGdArFlF5MwBIkilgWLc4Mwgis X-IPAS-Result: AqQEAAElQFMKXgZQ/2dsb2JhbABYgmWBM4wluRd0giyBCwGBACYBBBuHcQGdArFlF5MwBIkilgWLc4Mwgis Received: from e14hub-01.zdv.uni-mainz.de ([10.94.6.80]) by mailgate-01.zdv.uni-mainz.de with ESMTP; 05 Apr 2014 18:25:10 +0200 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by E14HUB-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c5f) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 5 Apr 2014 18:25:08 +0200 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) with Microsoft SMTP Server (TLS) id 15.0.847.32; Sat, 5 Apr 2014 18:25:08 +0200 Received: from e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090]) by e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090%15]) with mapi id 15.00.0847.030; Sat, 5 Apr 2014 18:25:08 +0200 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: "'freebsd-arm@freebsd.org'" Subject: sleep command with armv6hf Thread-Topic: sleep command with armv6hf Thread-Index: Ac9Q6bdmGvnX8HesTcC/76T/cz8N0Q== Date: Sat, 5 Apr 2014 16:25:08 +0000 Message-ID: <79020061b2a74d8e8d56d47361ca3f4d@e15be-01.zdv.Uni-Mainz.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 16:25:11 -0000 under armv6hf the sleep command gives sleep: nanosleep: Invalid argument Further investigations seem to indicate the following problem: sleep calls the function __aeabi_d2lz vmov r0, r1, d8 bl __aeabi_d2lz mov r4, r0 mov r5, r1 with the argument in the r0/r1 registers. But the function in libgcc.a expects the argument in d0 (seems to be compiled with hardfloat as well). __aeabi_d2lz: 0: e92d4010 push {r4, lr} 4: ec52cb10 vmov ip, r2, d0 8: e3a000ff mov r0, #255 ; 0xff c: e59f10a8 ldr r1, [pc, #168] ; bc <__aeabi_d2lz+0xbc> 10: e3800c07 orr r0, r0, #1792 ; 0x700 14: e0004a22 and r4, r0, r2, lsr #20 Besides, when compiling sleep without optimization, the argument for __aeabi_d2lz by chance is in d0 as well as r0/r1. So this accidentally works. Regards Juergen From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 17:40:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D853DC7 for ; Sat, 5 Apr 2014 17:40:07 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id B94E8A81 for ; Sat, 5 Apr 2014 17:40:07 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 367575DEC1; Sat, 5 Apr 2014 17:40:06 +0000 (UTC) Date: Sat, 5 Apr 2014 18:39:58 +0100 From: Andrew Turner To: "=?ISO-8859-1?Q?Wei=DF,_J=FCrgen?=" Subject: Re: sleep command with armv6hf Message-ID: <20140405183958.65834b35@bender.Home> In-Reply-To: <79020061b2a74d8e8d56d47361ca3f4d@e15be-01.zdv.Uni-Mainz.DE> References: <79020061b2a74d8e8d56d47361ca3f4d@e15be-01.zdv.Uni-Mainz.DE> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/jvIpo=hq1.TgNaa6a1cvgfW" Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 17:40:07 -0000 --MP_/jvIpo=hq1.TgNaa6a1cvgfW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 5 Apr 2014 16:25:08 +0000 "Wei=C3=9F, J=C3=BCrgen" wrote: > under armv6hf the sleep command gives >=20 > sleep: nanosleep: Invalid argument >=20 > Further investigations seem to indicate the following problem: >=20 > sleep calls the function __aeabi_d2lz >=20 > vmov r0, r1, d8 > bl __aeabi_d2lz > mov r4, r0 > mov r5, r1 >=20 > with the argument in the r0/r1 registers. But the function > in libgcc.a expects the argument in d0 (seems to be > compiled with hardfloat as well). Can you try the attached patch. It should fix the function to use the slightly odd calling convention of the __aeabi_* functions. Andrew --MP_/jvIpo=hq1.TgNaa6a1cvgfW Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=aeabi_d2lz.diff Index: contrib/compiler-rt/lib/fixdfdi.c =================================================================== --- contrib/compiler-rt/lib/fixdfdi.c (revision 264019) +++ contrib/compiler-rt/lib/fixdfdi.c (working copy) @@ -25,7 +25,7 @@ ARM_EABI_FNALIAS(d2lz, fixdfdi) -di_int +COMPILER_RT_ABI di_int __fixdfdi(double a) { double_bits fb; --MP_/jvIpo=hq1.TgNaa6a1cvgfW-- From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 17:43:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E38D208; Sat, 5 Apr 2014 17:43:38 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4129FB05; Sat, 5 Apr 2014 17:43:37 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s35HECY2001419; Sat, 5 Apr 2014 17:14:12 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.100] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id 2tnf9e8fnwvsqnrfasj9ctzxii; Sat, 05 Apr 2014 17:14:12 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Building an image for Raspberry Pi From: Tim Kientzle In-Reply-To: <20140403061443.GD71905@pwnie.vrt.sourcefire.com> Date: Sat, 5 Apr 2014 10:14:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <525F718A-53F7-4172-9D23-190D1364AD0A@kientzle.com> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <20140403054106.GT14379@glenbarber.us> <20140403061443.GD71905@pwnie.vrt.sourcefire.com> To: Shawn Webb X-Mailer: Apple Mail (2.1874) Cc: Glen Barber , FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 17:43:38 -0000 On Apr 2, 2014, at 11:14 PM, Shawn Webb wrote: > On Apr 03, 2014 01:41 AM -0400, Glen Barber wrote: >> You need to build the XDEV stuff for the build environment. >>=20 >> Something like: make -C /usr/src XDEV=3Darm XDEV_ARCH=3Darmv6 >>=20 >> should do the trick. >=20 > Yeah, I have the xdev stuff installed. It kinda seems like just using > this xdev stuff isn't sufficient. It seems u-boot might require some > gcc-centric items (though I'm unsure what they are). Unfortunately, my time has been rather cramped, though Tom Everett and Patrick Kelsey have been doing a bunch of Crochet work recently. The confusing part about U-Boot is that it requires two different = compilers to build: * Building the U-Boot loader needs an ARM cross-compiler and relies on = GCC-specific options. * U-Boot also builds some tools that run on the build host; that uses a = different native compiler and does not seem to rely on GCC-specific = features. For the host tools, setting HOSTCC=3Dcc always worked well for me. I never had any problems with clang or gcc as the native host compiler for that part of U-Boot. For the loader itself, you can try the XDEV tools (which last I checked still built GCC) or you can try the ARM EABI GCC cross-compiler from ports (which may be broken; I volunteered to maintain it and then ran out of time to work on it). One specific GCC-ism used by U-Boot (an option to reserve a specific CPU register for global data) was added to clang recently but I don't know if that's reached FreeBSD yet. That might allow clang to build the U-Boot loader, but it will require some work: the XDEV target also builds ARM binutils and cross-libraries which are essential. Best luck, Tim From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 18:44:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC1F7A05 for ; Sat, 5 Apr 2014 18:44:56 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69A7EF98 for ; Sat, 5 Apr 2014 18:44:56 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id l18so5036046wgh.16 for ; Sat, 05 Apr 2014 11:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NSoLSgdNWSlxb4COQ3V5oTVcFU6cR2OleBBXaYwSI6Q=; b=ymAWFF3VkpsqqA93UKIRTedLDOt09rrgGsGcKYzZiPE6nATojPH6Q/mOFfYkEiD7Rk Qe6PwDZuulewNwsYVuArcJG3StfHJqaQ52pbzI/B8zAs/CjgBh/iplMNHGg2HKV9mgkx 5P0LWCrGloW4STJVn4tJQHagwaDtaEfNwxZzHTFswXNEHkwkl2hv+mhzmuNYb01c5fJz 4VQFBZ/0f9O7cRzCt3LNXP7jjWTn6GRnB0lilQkcqBg8zjfXL/o39f4bvvM3Nf5H68RL TdthdjyVyMJoGy66oJ8NJtb2HKFp/jBJXIWcU2V84sBHcluPybmFktjVLjGuhLcWTrUb se0Q== X-Received: by 10.180.188.66 with SMTP id fy2mr13615067wic.45.1396723493723; Sat, 05 Apr 2014 11:44:53 -0700 (PDT) Received: from [192.168.0.10] (178-83-152-199.dynamic.hispeed.ch. [178.83.152.199]) by mx.google.com with ESMTPSA id h47sm28842310eey.13.2014.04.05.11.44.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Apr 2014 11:44:52 -0700 (PDT) Message-ID: <53404F23.4080609@gmail.com> Date: Sat, 05 Apr 2014 20:44:51 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ARM Subject: Re: Dreamplug: Panic when copying from USB stick to internal SD-Card (USB) References: <533FE2B6.8040009@gmail.com> In-Reply-To: <533FE2B6.8040009@gmail.com> 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.17 Precedence: list Reply-To: mattia.rossi.mate@gmail.com List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 18:44:56 -0000 Here some additional db output that might be useful: Sleeping thread (tid 100040, pid 8) owns a non-sleepable lock KDB: stack backtrace of thread 100040: cpu_switch() at cpu_switch+0x3c pc = 0xc0dc11dc lr = 0xc0ae1d98 (sched_switch+0x164) sp = 0xde03dae8 fp = 0xde03daf8 r4 = 0xc3c6d320 r5 = 0xc3745c80 r6 = 0xc0f4aa84 r7 = 0xc0f57fc0 sched_switch() at sched_switch+0x164 pc = 0xc0ae1d98 lr = 0xc0ac57ec (mi_switch+0x1ac) sp = 0xde03db00 fp = 0xde03db20 r4 = 0xc0f2f950 r5 = 0x00000000 r6 = 0xc3c6d320 r7 = 0x00000000 mi_switch() at mi_switch+0x1ac pc = 0xc0ac57ec lr = 0xc0afe548 (sleepq_wait+0x1fc) sp = 0xde03db28 fp = 0xde03db48 r4 = 0xc3c6d320 r5 = 0xc0f4aa84 r6 = 0xc54e1828 r7 = 0x00000090 r8 = 0x0000005c r9 = 0xc0f4a600 r10 = 0xc0f4aa94 sleepq_wait() at sleepq_wait+0x1fc pc = 0xc0afe548 lr = 0xc0afe39c (sleepq_wait+0x50) sp = 0xde03db50 fp = 0xde03db60 r4 = 0x0000005c r5 = 0xc3c6d320 r6 = 0xc54e1828 r7 = 0xc0e27125 r8 = 0xc3cae3f4 r9 = 0x00000000 r10 = 0xc0f0f850 sleepq_wait() at sleepq_wait+0x50 pc = 0xc0afe39c lr = 0xc0ac514c (_sleep+0x368) sp = 0xde03db68 fp = 0xde03dbb8 r4 = 0x00000000 r5 = 0xc54e1828 r6 = 0xc0f0f850 r7 = 0xc0f57ca4 _sleep() at _sleep+0x368 pc = 0xc0ac514c lr = 0xc0902cd8 (cam_periph_runccb+0xd8) sp = 0xde03dbc0 fp = 0xde03dc88 r4 = 0xc54e1828 r5 = 0xc54e1800 r6 = 0x00000000 r7 = 0xc0928524 r8 = 0x00000000 r9 = 0x00000034 r10 = 0x00000000 cam_periph_runccb() at cam_periph_runccb+0xd8 pc = 0xc0902cd8 lr = 0xc0927484 (scsi_read_dvd_structure+0x9568) sp = 0xde03dc90 fp = 0xde03dcc0 r4 = 0xc3953880 r5 = 0x00000ec9 r6 = 0x00000000 r7 = 0xc3ccd000 r8 = 0xc0e02b21 r9 = 0xc54e1800 r10 = 0xc0e03246 scsi_read_dvd_structure() at scsi_read_dvd_structure+0x9568 pc = 0xc0927484 lr = 0xc0abc3c8 (kern_reboot+0x6c0) sp = 0xde03dcc8 fp = 0xde03dd18 r4 = 0x000001c1 r5 = 0xc35c5600 r6 = 0xc36d521c r7 = 0xc0e21bc4 r8 = 0xc36d5200 r9 = 0x00000104 r10 = 0xc0f2f954 kern_reboot() at kern_reboot+0x6c0 pc = 0xc0abc3c8 lr = 0xc0abc988 (kassert_panic+0x1f0) sp = 0xde03dd20 fp = 0xde03dd40 r4 = 0x00000104 r5 = 0xde03dd54 r6 = 0xc0e1e26a r7 = 0xc0f3c2e0 r8 = 0xc3c6d320 r9 = 0xc0f57dc0 r10 = 0xc0f3c140 kassert_panic() at kassert_panic+0x1f0 pc = 0xc0abc988 lr = 0xc0abc9cc (kproc_shutdown) sp = 0xde03dd48 fp = 0xde03dd4c r4 = 0xc3c6d320 r5 = 0xc0f5cd10 r6 = 0xc0f55080 r7 = 0xc10720bc r8 = 0xc0e57eea r9 = 0xc0f55030 r10 = 0x000002fe kproc_shutdown() at kproc_shutdown pc = 0xc0abc9cc lr = 0xc3c6d320 (0xc3c6d320) sp = 0xde03dd54 fp = 0xde03dd68 r4 = 0xc0abc9cc r5 = 0xde03dd54 Unknown entry: 0 _end() at 0xc3c6d320 pc = 0xc3c6d320 lr = 0xc3c6d320 (0xc3c6d320) sp = 0xde03dd54 fp = 0xde03dd68 Unable to unwind into user mode panic: sleeping thread KDB: enter: panic [ thread pid 11 tid 100020 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> c Uptime: 1h42m1s panic: msleep KDB: enter: panic [ thread pid 11 tid 100020 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> c Uptime: 1h42m1s panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /usr/d evel/dreamplug/sys/cam/scsi/scsi_da.c:3777 KDB: enter: panic [ thread pid 11 tid 100020 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 11 tid 100020 td 0xc3743c80 db_trace_self() at db_trace_self pc = 0xc0db048c lr = 0xc0947f44 (db_hex2dec+0x4d4) sp = 0xddf7de40 fp = 0xddf7de58 r10 = 0xc0f562ec db_hex2dec() at db_hex2dec+0x4d4 pc = 0xc0947f44 lr = 0xc09478b8 (db_command_loop+0x300) sp = 0xddf7de60 fp = 0xddf7df00 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 db_command_loop() at db_command_loop+0x300 pc = 0xc09478b8 lr = 0xc0947608 (db_command_loop+0x50) sp = 0xddf7df08 fp = 0xddf7df18 r4 = 0xc0e0500c r5 = 0xc0e2214d r6 = 0xc0f562d8 r7 = 0xddf7e0f0 r8 = 0xc0f4a340 r9 = 0xc0f4a344 r10 = 0xc0eee390 db_command_loop() at db_command_loop+0x50 pc = 0xc0947608 lr = 0xc0949fe8 (X_db_symbol_values+0x250) sp = 0xddf7df20 fp = 0xddf7e040 r4 = 0x00000000 r5 = 0xc0f562e4 r6 = 0xc0f4a368 X_db_symbol_values() at X_db_symbol_values+0x250 pc = 0xc0949fe8 lr = 0xc0af1318 (kdb_trap+0xd4) sp = 0xddf7e048 fp = 0xddf7e068 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc0f4a368 r7 = 0xddf7e0f0 kdb_trap() at kdb_trap+0xd4 pc = 0xc0af1318 lr = 0xc0dc2c60 (undefinedinstruction+0x25c) sp = 0xddf7e070 fp = 0xddf7e0e8 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0dc2954 r7 = 0xe7ffffff r8 = 0xc3743c80 r9 = 0xc0af0bc0 r10 = 0xddf7e0f0 undefinedinstruction() at undefinedinstruction+0x25c pc = 0xc0dc2c60 lr = 0xc0db2034 (exception_exit) sp = 0xddf7e0f0 fp = 0xddf7e148 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0xc0e1fdc9 r7 = 0xc0f3c140 r8 = 0xc3743c80 r9 = 0xc0f57dc0 r10 = 0xc0e03246 exception_exit() at exception_exit pc = 0xc0db2034 lr = 0xc0af0bb4 (kdb_enter+0x40) sp = 0xddf7e140 fp = 0xddf7e148 r0 = 0xc0f4a354 r1 = 0x00000000 r2 = 0xc0e25b59 r3 = 0x000000ab r4 = 0xc0e221a7 r5 = 0xddf7e19c r6 = 0xc0e1fdc9 r7 = 0xc0f3c140 r8 = 0xc3743c80 r9 = 0xc0f57dc0 r10 = 0xc0e03246 r12 = 0x00000000 kdb_enter() at kdb_enter+0x50 pc = 0xc0af0bc4 lr = 0xc0abc964 (kassert_panic+0x1cc) sp = 0xddf7e150 fp = 0xddf7e170 r4 = 0x00000004 kassert_panic() at kassert_panic+0x1cc pc = 0xc0abc964 lr = 0xc0abc898 (kassert_panic+0x100) sp = 0xddf7e178 fp = 0xddf7e190 r4 = 0xc0f3c1e0 r5 = 0xc0e1fdc9 r6 = 0xddf7e19c r7 = 0xc0f3c140 r8 = 0xc0f2f950 r9 = 0x00000004 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x100 pc = 0xc0abc898 lr = 0xc0aa8ecc (__mtx_lock_sleep+0x70) sp = 0xddf7e1a8 fp = 0xddf7e1d0 r4 = 0xc3cae404 r5 = 0xc3cae3f4 r6 = 0x00000ec1 r7 = 0x00000ec1 __mtx_lock_sleep() at __mtx_lock_sleep+0x70 pc = 0xc0aa8ecc lr = 0xc0aa8dd8 (__mtx_lock_flags+0xd8) sp = 0xddf7e1d8 fp = 0xddf7e1f8 r4 = 0xc0e03246 r5 = 0xc0f2f950 r6 = 0xc3cae404 r7 = 0x00000ec1 r8 = 0x00000000 r9 = 0x00000004 r10 = 0xc0e03246 __mtx_lock_flags() at __mtx_lock_flags+0xd8 pc = 0xc0aa8dd8 lr = 0xc0927408 (scsi_read_dvd_structure+0x94ec) sp = 0xddf7e200 fp = 0xddf7e230 r4 = 0xc3953880 r5 = 0x00000ec9 r6 = 0x00000000 r7 = 0xc3ccd000 r8 = 0xc0e02b21 scsi_read_dvd_structure() at scsi_read_dvd_structure+0x94ec pc = 0xc0927408 lr = 0xc0abc3c8 (kern_reboot+0x6c0) sp = 0xddf7e238 fp = 0xddf7e288 r4 = 0x000001c1 r5 = 0xc35c5600 r6 = 0xc36d521c r7 = 0xc0e21bc4 r8 = 0xc36d5200 r9 = 0x00000004 r10 = 0xc0f2f954 kern_reboot() at kern_reboot+0x6c0 pc = 0xc0abc3c8 lr = 0xc0abc988 (kassert_panic+0x1f0) sp = 0xddf7e290 fp = 0xddf7e2b0 r4 = 0x00000004 r5 = 0xddf7e2dc r6 = 0xc0e1fdc9 r7 = 0xc0f3c140 r8 = 0xc3743c80 r9 = 0xc0f57dc0 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x1f0 pc = 0xc0abc988 lr = 0xc0abc898 (kassert_panic+0x100) sp = 0xddf7e2b8 fp = 0xddf7e2d0 r4 = 0xc0f3c1e0 r5 = 0xc0e1fdc9 r6 = 0xddf7e2dc r7 = 0xc0f3c140 r8 = 0xc0f2f950 r9 = 0x00000004 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x100 pc = 0xc0abc898 lr = 0xc0aa8ecc (__mtx_lock_sleep+0x70) sp = 0xddf7e2e8 fp = 0xddf7e310 r4 = 0xc3cae404 r5 = 0xc3cae3f4 r6 = 0x00000ec1 r7 = 0x00000ec1 __mtx_lock_sleep() at __mtx_lock_sleep+0x70 pc = 0xc0aa8ecc lr = 0xc0aa8dd8 (__mtx_lock_flags+0xd8) sp = 0xddf7e318 fp = 0xddf7e338 r4 = 0xc0e03246 r5 = 0xc0f2f950 r6 = 0xc3cae404 r7 = 0x00000ec1 r8 = 0x00000000 r9 = 0x00000004 r10 = 0xc0e03246 __mtx_lock_flags() at __mtx_lock_flags+0xd8 pc = 0xc0aa8dd8 lr = 0xc0927408 (scsi_read_dvd_structure+0x94ec) sp = 0xddf7e340 fp = 0xddf7e370 r4 = 0xc3953880 r5 = 0x00000ec9 r6 = 0x00000000 r7 = 0xc3ccd000 r8 = 0xc0e02b21 scsi_read_dvd_structure() at scsi_read_dvd_structure+0x94ec pc = 0xc0927408 lr = 0xc0abc3c8 (kern_reboot+0x6c0) sp = 0xddf7e378 fp = 0xddf7e3c8 r4 = 0x000001c1 r5 = 0xc35c5600 r6 = 0xc36d521c r7 = 0xc0e21bc4 r8 = 0xc36d5200 r9 = 0x00000004 r10 = 0xc0f2f954 kern_reboot() at kern_reboot+0x6c0 pc = 0xc0abc3c8 lr = 0xc0abc988 (kassert_panic+0x1f0) sp = 0xddf7e3d0 fp = 0xddf7e3f0 r4 = 0x00000004 r5 = 0xddf7e41c r6 = 0xc0e1fdc9 r7 = 0xc0f3c140 r8 = 0xc3743c80 r9 = 0xc0f57dc0 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x1f0 pc = 0xc0abc988 lr = 0xc0abc898 (kassert_panic+0x100) sp = 0xddf7e3f8 fp = 0xddf7e410 r4 = 0xc0f3c1e0 r5 = 0xc0e1fdc9 r6 = 0xddf7e41c r7 = 0xc0f3c140 r8 = 0xc0f2f950 r9 = 0x00000004 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x100 pc = 0xc0abc898 lr = 0xc0aa8ecc (__mtx_lock_sleep+0x70) sp = 0xddf7e428 fp = 0xddf7e450 r4 = 0xc3cae404 r5 = 0xc3cae3f4 r6 = 0x00000ec1 r7 = 0x00000ec1 __mtx_lock_sleep() at __mtx_lock_sleep+0x70 pc = 0xc0aa8ecc lr = 0xc0aa8dd8 (__mtx_lock_flags+0xd8) sp = 0xddf7e458 fp = 0xddf7e478 r4 = 0xc0e03246 r5 = 0xc0f2f950 r6 = 0xc3cae404 r7 = 0x00000ec1 r8 = 0x00000000 r9 = 0x00000004 r10 = 0xc0e03246 __mtx_lock_flags() at __mtx_lock_flags+0xd8 pc = 0xc0aa8dd8 lr = 0xc0927408 (scsi_read_dvd_structure+0x94ec) sp = 0xddf7e480 fp = 0xddf7e4b0 r4 = 0xc3953880 r5 = 0x00000ec9 r6 = 0x00000000 r7 = 0xc3ccd000 r8 = 0xc0e02b21 scsi_read_dvd_structure() at scsi_read_dvd_structure+0x94ec pc = 0xc0927408 lr = 0xc0abc3c8 (kern_reboot+0x6c0) sp = 0xddf7e4b8 fp = 0xddf7e508 r4 = 0x000001c1 r5 = 0xc35c5600 r6 = 0xc36d521c r7 = 0xc0e21bc4 r8 = 0xc36d5200 r9 = 0x00000004 r10 = 0xc0f2f954 kern_reboot() at kern_reboot+0x6c0 pc = 0xc0abc3c8 lr = 0xc0abc988 (kassert_panic+0x1f0) sp = 0xddf7e510 fp = 0xddf7e530 r4 = 0x00000004 r5 = 0xddf7e55c r6 = 0xc0e1fdc9 r7 = 0xc0f3c140 r8 = 0xc3743c80 r9 = 0xc0f57dc0 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x1f0 pc = 0xc0abc988 lr = 0xc0abc898 (kassert_panic+0x100) sp = 0xddf7e538 fp = 0xddf7e550 r4 = 0xc0f3c1e0 r5 = 0xc0e1fdc9 r6 = 0xddf7e55c r7 = 0xc0f3c140 r8 = 0xc0f2f950 r9 = 0x00000004 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x100 pc = 0xc0abc898 lr = 0xc0aa8ecc (__mtx_lock_sleep+0x70) sp = 0xddf7e568 fp = 0xddf7e590 r4 = 0xc3cae404 r5 = 0xc3cae3f4 r6 = 0x00000ec1 r7 = 0x00000ec1 __mtx_lock_sleep() at __mtx_lock_sleep+0x70 pc = 0xc0aa8ecc lr = 0xc0aa8dd8 (__mtx_lock_flags+0xd8) sp = 0xddf7e598 fp = 0xddf7e5b8 r4 = 0xc0e03246 r5 = 0xc0f2f950 r6 = 0xc3cae404 r7 = 0x00000ec1 r8 = 0x00000000 r9 = 0x00000004 r10 = 0xc0e03246 __mtx_lock_flags() at __mtx_lock_flags+0xd8 pc = 0xc0aa8dd8 lr = 0xc0927408 (scsi_read_dvd_structure+0x94ec) sp = 0xddf7e5c0 fp = 0xddf7e5f0 r4 = 0xc3953880 r5 = 0x00000ec9 r6 = 0x00000000 r7 = 0xc3ccd000 r8 = 0xc0e02b21 scsi_read_dvd_structure() at scsi_read_dvd_structure+0x94ec pc = 0xc0927408 lr = 0xc0abc3c8 (kern_reboot+0x6c0) sp = 0xddf7e5f8 fp = 0xddf7e648 r4 = 0x000001c1 r5 = 0xc35c5600 r6 = 0xc36d521c r7 = 0xc0e21bc4 r8 = 0xc36d5200 r9 = 0x00000004 r10 = 0xc0f2f954 kern_reboot() at kern_reboot+0x6c0 pc = 0xc0abc3c8 lr = 0xc0abc988 (kassert_panic+0x1f0) sp = 0xddf7e650 fp = 0xddf7e670 r4 = 0x00000004 r5 = 0xddf7e69c r6 = 0xc0e1fdc9 r7 = 0xc0f3c140 r8 = 0xc3743c80 r9 = 0xc0f57dc0 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x1f0 pc = 0xc0abc988 lr = 0xc0abc898 (kassert_panic+0x100) sp = 0xddf7e678 fp = 0xddf7e690 r4 = 0xc0f3c1e0 r5 = 0xc0e1fdc9 r6 = 0xddf7e69c r7 = 0xc0f3c140 r8 = 0xc0f2f950 r9 = 0x00000004 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x100 pc = 0xc0abc898 lr = 0xc0aa8ecc (__mtx_lock_sleep+0x70) sp = 0xddf7e6a8 fp = 0xddf7e6d0 r4 = 0xc3cae404 r5 = 0xc3cae3f4 r6 = 0x00000ec1 r7 = 0x00000ec1 __mtx_lock_sleep() at __mtx_lock_sleep+0x70 pc = 0xc0aa8ecc lr = 0xc0aa8dd8 (__mtx_lock_flags+0xd8) sp = 0xddf7e6d8 fp = 0xddf7e6f8 r4 = 0xc0e03246 r5 = 0xc0f2f950 r6 = 0xc3cae404 r7 = 0x00000ec1 r8 = 0x00000000 r9 = 0x00000004 r10 = 0xc0e03246 __mtx_lock_flags() at __mtx_lock_flags+0xd8 pc = 0xc0aa8dd8 lr = 0xc0927408 (scsi_read_dvd_structure+0x94ec) sp = 0xddf7e700 fp = 0xddf7e730 r4 = 0xc3953880 r5 = 0x00000ec9 r6 = 0x00000000 r7 = 0xc3ccd000 r8 = 0xc0e02b21 scsi_read_dvd_structure() at scsi_read_dvd_structure+0x94ec pc = 0xc0927408 lr = 0xc0abc3c8 (kern_reboot+0x6c0) sp = 0xddf7e738 fp = 0xddf7e788 r4 = 0x000001c1 r5 = 0xc35c5600 r6 = 0xc36d521c r7 = 0xc0e21bc4 r8 = 0xc36d5200 r9 = 0x00000004 r10 = 0xc0f2f954 kern_reboot() at kern_reboot+0x6c0 pc = 0xc0abc3c8 lr = 0xc0abc988 (kassert_panic+0x1f0) sp = 0xddf7e790 fp = 0xddf7e7b0 r4 = 0x00000004 r5 = 0xddf7e7dc r6 = 0xc0e1fdc9 r7 = 0xc0f3c140 r8 = 0xc3743c80 r9 = 0xc0f57dc0 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x1f0 pc = 0xc0abc988 lr = 0xc0abc898 (kassert_panic+0x100) sp = 0xddf7e7b8 fp = 0xddf7e7d0 r4 = 0xc0f3c1e0 r5 = 0xc0e1fdc9 r6 = 0xddf7e7dc r7 = 0xc0f3c140 r8 = 0xc0f2f950 r9 = 0x00000004 r10 = 0xc0e03246 kassert_panic() at kassert_panic+0x100 pc = 0xc0abc898 lr = 0xc0aa8ecc (__mtx_lock_sleep+0x70) sp = 0xddf7e7e8 fp = 0xddf7e810 r4 = 0xc3cae404 r5 = 0xc3cae3f4 r6 = 0x00000ec1 r7 = 0x00000ec1 __mtx_lock_sleep() at __mtx_lock_sleep+0x70 pc = 0xc0aa8ecc lr = 0xc0aa8dd8 (__mtx_lock_flags+0xd8) sp = 0xddf7e818 fp = 0xddf7e838 r4 = 0xc0e03246 r5 = 0xc0f2f950 r6 = 0xc3cae404 r7 = 0x00000ec1 r8 = 0x00000000 r9 = 0x00000004 r10 = 0xc0e03246 __mtx_lock_flags() at __mtx_lock_flags+0xd8 pc = 0xc0aa8dd8 lr = 0xc0927408 (scsi_read_dvd_structure+0x94ec) sp = 0xddf7e840 fp = 0xddf7e870 r4 = 0xc3953880 r5 = 0x00000ec9 r6 = 0x00000000 r7 = 0xc3ccd000 r8 = 0xc0e02b21 scsi_read_dvd_structure() at scsi_read_dvd_structure+0x94ec pc = 0xc0927408 lr = 0xc0abc3c8 (kern_reboot+0x6c0) sp = 0xddf7e878 fp = 0xddf7e8c8 r4 = 0x000001c1 r5 = 0xc35c5600 r6 = 0xc36d521c r7 = 0xc0e21bc4 r8 = 0xc36d5200 r9 = 0x00000004 r10 = 0xc0f2f954 kern_reboot() at kern_reboot+0x6c0 pc = 0xc0abc3c8 lr = 0xc0abc988 (kassert_panic+0x1f0) sp = 0xddf7e8d0 fp = 0xddf7e8f0 r4 = 0x00000004 r5 = 0xddf7e91c r6 = 0xc0e22d66 r7 = 0xc0f3c140 r8 = 0xc3743c80 r9 = 0xc0f57dc0 r10 = 0xc0f2f950 kassert_panic() at kassert_panic+0x1f0 pc = 0xc0abc988 lr = 0xc0abc898 (kassert_panic+0x100) sp = 0xddf7e8f8 fp = 0xddf7e910 r4 = 0xc0f3c1e0 r5 = 0xc0e22d66 r6 = 0xddf7e91c r7 = 0xc0f3c140 r8 = 0xc3cae3f4 r9 = 0x0000005c r10 = 0xc0f2f950 kassert_panic() at kassert_panic+0x100 pc = 0xc0abc898 lr = 0xc0ac4e68 (_sleep+0x84) sp = 0xddf7e928 fp = 0xddf7e978 r4 = 0xc0df8d65 r5 = 0x00000000 r6 = 0xc36e6000 r7 = 0xc3743c80 _sleep() at _sleep+0x84 pc = 0xc0ac4e68 lr = 0xc090a328 (cam_periph_getccb+0x7c) sp = 0xddf7e980 fp = 0xddf7e9b0 r4 = 0x00000480 r5 = 0xc3953880 r6 = 0xc39538bc r7 = 0x00000000 r8 = 0xc0df8d65 r9 = 0x00000100 r10 = 0xc0e03246 cam_periph_getccb() at cam_periph_getccb+0x7c pc = 0xc090a328 lr = 0xc092742c (scsi_read_dvd_structure+0x9510) sp = 0xddf7e9b8 fp = 0xddf7e9e8 r4 = 0xc3953880 r5 = 0x00000ec9 r6 = 0x00000000 r7 = 0xc3ccd000 r8 = 0xc0e02b21 r9 = 0x00000004 scsi_read_dvd_structure() at scsi_read_dvd_structure+0x9510 pc = 0xc092742c lr = 0xc0abc3c8 (kern_reboot+0x6c0) sp = 0xddf7e9f0 fp = 0xddf7ea40 r4 = 0x000001c1 r5 = 0xc35c5600 r6 = 0xc36d521c r7 = 0xc0e21bc4 r8 = 0xc36d5200 r9 = 0x00000004 r10 = 0xc0f2f954 kern_reboot() at kern_reboot+0x6c0 pc = 0xc0abc3c8 lr = 0xc0abc988 (kassert_panic+0x1f0) sp = 0xddf7ea48 fp = 0xddf7ea68 r4 = 0x00000004 r5 = 0xddf7ea7c r6 = 0xc0e280bb r7 = 0xc3c6d320 r8 = 0xc3743c80 r9 = 0xc0f57dc0 r10 = 0xc0f57cb8 kassert_panic() at kassert_panic+0x1f0 pc = 0xc0abc988 lr = 0xc0abc9cc (kproc_shutdown) sp = 0xddf7ea70 fp = 0xddf7ea74 r4 = 0x00000008 r5 = 0xc35c3840 r6 = 0xc0e27bbe r7 = 0xc3c6d320 r8 = 0xc0e10122 r9 = 0xc0f2f950 r10 = 0xc0f57cb8 kproc_shutdown() at kproc_shutdown pc = 0xc0abc9cc lr = 0x00000008 (0x8) sp = 0xddf7ea7c fp = 0xddf7eaa8 r4 = 0xc0abc9cc r5 = 0xddf7ea7c Unable to unwind into user mode db> On 05/04/14 13:02, Mattia Rossi wrote: > Hi all, > > does anyone have a hint on what's happening here? > > I keep running into panics when copying world from the USB stick i > boot from, to the internal SD-Card where I want to boot from next. > > backtrace: > > root@dreamplug:/ # panic: Lock vm object not exclusively locked @ > /usr/devel/dre > amplug/sys/arm/arm/pmap.c:4474 > > KDB: enter: panic > [ thread pid 8 tid 100040 ] > Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 8 tid 100040 td 0xc3c6d320 > db_trace_self() at db_trace_self > pc = 0xc0db048c lr = 0xc0947f44 (db_hex2dec+0x4d4) > sp = 0xde03da10 fp = 0xde03da28 > r10 = 0xc0f562ec > db_hex2dec() at db_hex2dec+0x4d4 > pc = 0xc0947f44 lr = 0xc09478b8 (db_command_loop+0x300) > sp = 0xde03da30 fp = 0xde03dad0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000000 > db_command_loop() at db_command_loop+0x300 > pc = 0xc09478b8 lr = 0xc0947608 (db_command_loop+0x50) > sp = 0xde03dad8 fp = 0xde03dae8 > r4 = 0xc0e0500c r5 = 0xc0e2214d > r6 = 0xc0f562d8 r7 = 0xde03dcc0 > r8 = 0xc0f4a340 r9 = 0xc0f4a344 > r10 = 0xc0eee390 > db_command_loop() at db_command_loop+0x50 > pc = 0xc0947608 lr = 0xc0949fe8 (X_db_symbol_values+0x250) > sp = 0xde03daf0 fp = 0xde03dc10 > r4 = 0x00000000 r5 = 0xc0f562e4 > r6 = 0xc0f4a368 > X_db_symbol_values() at X_db_symbol_values+0x250 > pc = 0xc0949fe8 lr = 0xc0af1318 (kdb_trap+0xd4) > sp = 0xde03dc18 fp = 0xde03dc38 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc0f4a368 r7 = 0xde03dcc0 > kdb_trap() at kdb_trap+0xd4 > pc = 0xc0af1318 lr = 0xc0dc2c60 (undefinedinstruction+0x25c) > sp = 0xde03dc40 fp = 0xde03dcb8 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc0dc2954 r7 = 0xe7ffffff > r8 = 0xc3c6d320 r9 = 0xc0af0bc0 > r10 = 0xde03dcc0 > undefinedinstruction() at undefinedinstruction+0x25c > pc = 0xc0dc2c60 lr = 0xc0db2034 (exception_exit) > sp = 0xde03dcc0 fp = 0xde03dd18 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0xc0e1e26a r7 = 0xc0f3c2e0 > r8 = 0xc3c6d320 r9 = 0xc0f57dc0 > r10 = 0xc0f3c140 > exception_exit() at exception_exit > pc = 0xc0db2034 lr = 0xc0af0bb4 (kdb_enter+0x40) > sp = 0xde03dd10 fp = 0xde03dd18 > r0 = 0xc0f4a354 r1 = 0x00000000 > r2 = 0xc0e25b59 r3 = 0x000000ab > r4 = 0xc0e221a7 r5 = 0xde03dd54 > r6 = 0xc0e1e26a r7 = 0xc0f3c2e0 > r8 = 0xc3c6d320 r9 = 0xc0f57dc0 > r10 = 0xc0f3c140 r12 = 0x00000000 > kdb_enter() at kdb_enter+0x50 > pc = 0xc0af0bc4 lr = 0xc0abc964 (kassert_panic+0x1cc) > sp = 0xde03dd20 fp = 0xde03dd40 > r4 = 0x00000100 > kassert_panic() at kassert_panic+0x1cc > pc = 0xc0abc964 lr = 0xc0abc9cc (kproc_shutdown) > sp = 0xde03dd48 fp = 0xde03dd4c > r4 = 0xc3c6d320 r5 = 0xc0f5cd10 > r6 = 0xc0f55080 r7 = 0xc10720bc > r8 = 0xc0e57eea r9 = 0xc0f55030 > r10 = 0x000002fe > kproc_shutdown() at kproc_shutdown > pc = 0xc0abc9cc lr = 0xc3c6d320 (0xc3c6d320) > sp = 0xde03dd54 fp = 0xde03dd68 > r4 = 0xc0abc9cc r5 = 0xde03dd54 > Unknown entry: 0 > _end() at 0xc3c6d320 > pc = 0xc3c6d320 lr = 0xc3c6d320 (0xc3c6d320) > sp = 0xde03dd54 fp = 0xde03dd68 > Unable to unwind into user mode > db> > > > Cheers, > > Mat From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 20:10:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20BEA312 for ; Sat, 5 Apr 2014 20:10:31 +0000 (UTC) Received: from mailgate-01.zdv.uni-mainz.de (mailgate-01.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f1]) by mx1.freebsd.org (Postfix) with ESMTP id A129392D for ; Sat, 5 Apr 2014 20:10:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1396728631; x=1428264631; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VeMSDoQkebiznyd0BK6nI2tKa3MJD80Pp5hPiX+LTAU=; b=KmHwPLf8D0Gh2cCLO77GKBceDL615G8fSstECs202dCTg6L4qMuU4jKg V00lgamDeuXvXwJZ0nFjuPVLJqMKblCufQQ6wNV/XMECCHQGp1+JHHccT iDH5p6qnB/fMtq85hOs7TmiX1svtT36jVKxf47UaoURVXAi5dfpzSZPFb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAHJiQFMKXgZQ/2dsb2JhbABYgmWBM4MKwQgZgRJ0giUBAQEEIxFFDAQCAQgRBAEBAQICIwMCAgIwFAEICAEBBA4FCIdxAaweoiUXgSmNLRsHBoJpgUkEnyeLc4Mwgis X-IPAS-Result: AqoEAHJiQFMKXgZQ/2dsb2JhbABYgmWBM4MKwQgZgRJ0giUBAQEEIxFFDAQCAQgRBAEBAQICIwMCAgIwFAEICAEBBA4FCIdxAaweoiUXgSmNLRsHBoJpgUkEnyeLc4Mwgis Received: from e14hub-01.zdv.uni-mainz.de ([10.94.6.80]) by mailgate-01.zdv.uni-mainz.de with ESMTP; 05 Apr 2014 22:10:29 +0200 Received: from e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) by E14HUB-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c5f) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 5 Apr 2014 22:09:51 +0200 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) with Microsoft SMTP Server (TLS) id 15.0.847.32; Sat, 5 Apr 2014 22:09:51 +0200 Received: from e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090]) by e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090%15]) with mapi id 15.00.0847.030; Sat, 5 Apr 2014 22:09:50 +0200 From: =?utf-8?B?V2Vpw58sIErDvHJnZW4=?= To: 'Andrew Turner' Subject: RE: sleep command with armv6hf Thread-Topic: sleep command with armv6hf Thread-Index: Ac9Q6bdmGvnX8HesTcC/76T/cz8N0f//9yoA//+1ofA= Date: Sat, 5 Apr 2014 20:09:50 +0000 Message-ID: <22ab1b9199024cae9c8c9ff6f445c631@e15be-01.zdv.Uni-Mainz.DE> References: <79020061b2a74d8e8d56d47361ca3f4d@e15be-01.zdv.Uni-Mainz.DE> <20140405183958.65834b35@bender.Home> In-Reply-To: <20140405183958.65834b35@bender.Home> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 20:10:31 -0000 VGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhlIHBhdGNoLiBOb3cgdGhlIGZ1bmN0aW9uIGV4cGVjdHMN Cml0cyBhcmd1bWVudHMgaW4gdGhlIHIwL3IxICByZWdpc3RlcnMuDQoNClRoZSBzbGVlcCBjb21t YW5kIHdvcmtzIGFzIHdlbGwuDQoNClJlZ2FyZHMNCg0KSnVlcmdlbg0KDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW5kcmV3IFR1cm5lciBbbWFpbHRvOmFuZHJld0Bm dWJhci5nZWVrLm56XQ0KPiBTZW50OiBTYXR1cmRheSwgQXByaWwgMDUsIDIwMTQgNzo0MCBQTQ0K PiBUbzogV2Vpw58sIErDvHJnZW4NCj4gQ2M6ICdmcmVlYnNkLWFybUBmcmVlYnNkLm9yZycNCj4g U3ViamVjdDogUmU6IHNsZWVwIGNvbW1hbmQgd2l0aCBhcm12NmhmDQo+IA0KPiBPbiBTYXQsIDUg QXByIDIwMTQgMTY6MjU6MDggKzAwMDANCj4gIldlacOfLCBKw7xyZ2VuIiA8d2Vpc3NAdW5pLW1h aW56LmRlPiB3cm90ZToNCj4gDQo+ID4gdW5kZXIgYXJtdjZoZiB0aGUgc2xlZXAgY29tbWFuZCBn aXZlcw0KPiA+DQo+ID4gc2xlZXA6IG5hbm9zbGVlcDogSW52YWxpZCBhcmd1bWVudA0KPiA+DQo+ ID4gRnVydGhlciBpbnZlc3RpZ2F0aW9ucyBzZWVtIHRvIGluZGljYXRlIHRoZSBmb2xsb3dpbmcg cHJvYmxlbToNCj4gPg0KPiA+IHNsZWVwIGNhbGxzIHRoZSBmdW5jdGlvbiBfX2FlYWJpX2QybHoN Cj4gPg0KPiA+ICAgICAgICAgdm1vdiAgICByMCwgcjEsIGQ4DQo+ID4gICAgICAgICBibCAgICAg IF9fYWVhYmlfZDJseg0KPiA+ICAgICAgICAgbW92ICAgICByNCwgcjANCj4gPiAgICAgICAgIG1v diAgICAgcjUsIHIxDQo+ID4NCj4gPiB3aXRoIHRoZSBhcmd1bWVudCBpbiB0aGUgcjAvcjEgcmVn aXN0ZXJzLiBCdXQgdGhlIGZ1bmN0aW9uDQo+ID4gaW4gbGliZ2NjLmEgZXhwZWN0cyB0aGUgYXJn dW1lbnQgaW4gZDAgKHNlZW1zIHRvIGJlDQo+ID4gY29tcGlsZWQgd2l0aCBoYXJkZmxvYXQgYXMg d2VsbCkuDQo+IA0KPiBDYW4geW91IHRyeSB0aGUgYXR0YWNoZWQgcGF0Y2guIEl0IHNob3VsZCBm aXggdGhlIGZ1bmN0aW9uIHRvIHVzZSB0aGUNCj4gc2xpZ2h0bHkgb2RkIGNhbGxpbmcgY29udmVu dGlvbiBvZiB0aGUgX19hZWFiaV8qIGZ1bmN0aW9ucy4NCj4gDQo+IEFuZHJldw0K From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 20:55:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6246412F for ; Sat, 5 Apr 2014 20:55:00 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1E6ACCA for ; Sat, 5 Apr 2014 20:54:58 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s35Ksigi006034 for ; Sat, 5 Apr 2014 22:54:56 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53406D94.5020605@fgznet.ch> Date: Sat, 05 Apr 2014 22:54:44 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "'freebsd-arm@freebsd.org'" Subject: MARVELL BOARD: RD-88F6281A -CURRENT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 20:55:00 -0000 Hi all, I'm very new to arm hardware, but not to FreeBSD. I got my hands on a broken (software like) ix2-200 Iomega StorCenter. A few wires and a screen session allowed me to dive into it and I tried to boot -CURRENT on it. Below where I end. The config I used is the DB-88F6XXX with enabling the INVARIANTS etc. The board itself identifies as the subject says. It has this: Soc: 88F6281 A0CPU running @ 1000Mhz L2 running @ 333Mhz SysClock = 333Mhz , TClock = 200Mhz DRAM (DDR2) CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x00000000 size 256 Has anyone a hint or an idea where to start debugging this? TIA, Andreas --- Marvell>> go 900000 ## Starting application at 0x00900000 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #16 r264151:264172M: Sat Apr 5 22:45:05 CEST 2014 andreast@tcx58.andreas.nets:/usr/obj/arm.arm/export/devel/fbsd/src/sys/DB-88F6XXX arm FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 WARNING: WITNESS option enabled, expect reduced performance. panic: Bad list head 0xc101b0c0 first->prev != head KDB: enter: panic vm_fault(0, c1030000, 2, 0) -> 0 Fatal kernel mode data abort: 'Translation Fault (P)' trapframe: 0xc102ffb0 FSR=00000007, FAR=c1030000, spsr=a00000d3 r0 =c0c32044, r1 =c1034000, r2 =c103000c, r3 =a00000d3 r4 =c0c9ddf1, r5 =ffff1004, r6 =c0c7d1db, r7 =c0d6b4d0 r8 =c101f750, r9 =c1020230, r10=c0d6b330, r11=c1036d58 r12=00000000, ssp=c1030004, slr=c0a9bba0, pc =c0c32044 [ thread pid 0 tid 0 ] Stopped at 0xc0c32044: str r0, [r13, -#0x004]! db> bt Tracing pid 0 tid 0 td 0xc101f750 (null)() at 0xc0c30364 pc = 0xc0c30364 lr = 0xc0938f68 (0xc0938f68) sp = 0xc102fcb8 fp = 0xc102fcd0 r10 = 0xc101e7d0 (null)() at 0xc0938f68 pc = 0xc0938f68 lr = 0xc09388d4 (0xc09388d4) sp = 0xc102fcd8 fp = 0xc102fd78 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 (null)() at 0xc09388d4 pc = 0xc09388d4 lr = 0xc0938624 (0xc0938624) sp = 0xc102fd80 fp = 0xc102fd90 r4 = 0xc0c7ea69 r5 = 0xc0c9dd97 r6 = 0xc101e7bc r7 = 0xc102ffb0 r8 = 0xc0d78ec0 r9 = 0xc0d78ec4 r10 = 0xc0d37c00 (null)() at 0xc0938624 pc = 0xc0938624 lr = 0xc093b024 (0xc093b024) sp = 0xc102fd98 fp = 0xc102feb8 From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 21:10:39 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91336530 for ; Sat, 5 Apr 2014 21:10:39 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65D0DE19 for ; Sat, 5 Apr 2014 21:10:38 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WWXrJ-000N3y-8S; Sat, 05 Apr 2014 21:10:37 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s35LAYHd089752; Sat, 5 Apr 2014 15:10:34 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/ZqEIlIA9/qChjz+wbaIIu Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT From: Ian Lepore To: Andreas Tobler In-Reply-To: <53406D94.5020605@fgznet.ch> References: <53406D94.5020605@fgznet.ch> Content-Type: text/plain; charset="us-ascii" Date: Sat, 05 Apr 2014 15:10:34 -0600 Message-ID: <1396732234.81853.334.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 21:10:39 -0000 On Sat, 2014-04-05 at 22:54 +0200, Andreas Tobler wrote: > Hi all, > > I'm very new to arm hardware, but not to FreeBSD. > I got my hands on a broken (software like) ix2-200 Iomega StorCenter. A > few wires and a screen session allowed me to dive into it and I tried to > boot -CURRENT on it. Below where I end. > > The config I used is the DB-88F6XXX with enabling the INVARIANTS etc. > The board itself identifies as the subject says. It has this: > Soc: 88F6281 A0CPU running @ 1000Mhz L2 running @ 333Mhz > SysClock = 333Mhz , TClock = 200Mhz > DRAM (DDR2) CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 > DRAM CS[0] base 0x00000000 size 256 > > Has anyone a hint or an idea where to start debugging this? > > TIA, > Andreas > > [...] Easy things first, I guess... in sys/boot/fdt/dts/db88f6281.dts I see reg = <0x0 0x20000000>; // 512M at 0x0 Try cutting that in half and rebuilding the kernel. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 21:53:28 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEB699DF; Sat, 5 Apr 2014 21:53:28 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56EA214D; Sat, 5 Apr 2014 21:53:27 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s35LrO1q038964; Sat, 5 Apr 2014 23:53:24 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53407B53.4040807@fgznet.ch> Date: Sat, 05 Apr 2014 23:53:23 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT References: <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> In-Reply-To: <1396732234.81853.334.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 21:53:28 -0000 On 05.04.14 23:10, Ian Lepore wrote: > On Sat, 2014-04-05 at 22:54 +0200, Andreas Tobler wrote: >> Hi all, >> >> I'm very new to arm hardware, but not to FreeBSD. >> I got my hands on a broken (software like) ix2-200 Iomega StorCenter. A >> few wires and a screen session allowed me to dive into it and I tried to >> boot -CURRENT on it. Below where I end. >> >> The config I used is the DB-88F6XXX with enabling the INVARIANTS etc. >> The board itself identifies as the subject says. It has this: >> Soc: 88F6281 A0CPU running @ 1000Mhz L2 running @ 333Mhz >> SysClock = 333Mhz , TClock = 200Mhz >> DRAM (DDR2) CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 >> DRAM CS[0] base 0x00000000 size 256 >> >> Has anyone a hint or an idea where to start debugging this? >> >> TIA, >> Andreas >> >> [...] > > Easy things first, I guess... in sys/boot/fdt/dts/db88f6281.dts I see > > reg = <0x0 0x20000000>; // 512M at 0x0 > > Try cutting that in half and rebuilding the kernel. Yep, simple thing! As said, new to the hardware :) Thanks a lot. Sure, now I 'hang' in an other area. mge0: mem 0x72000-0x73fff irq 12,13,14,11,46 on simplebus0 mge0: Ethernet address: 00:d0:b8:1e:3b:df mge0: attaching PHYs failed --> hangs According to the u-boot env I have two eth's and only the second is wired and used. >From u-boot: Net: egiga0, egiga1 [PRIME] Now my questions, how do I enable verbose boot? On PowerPC I know I have to do it in boot/loader.conf, here too? I guess my hardware is different from an eval board, so I expect I'd need a customized dts, no? If so, how do I get the information out of the u-boot? Again, thx a lot! Andreas From owner-freebsd-arm@FreeBSD.ORG Sat Apr 5 22:31:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CB087C4 for ; Sat, 5 Apr 2014 22:31:42 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 505586BD for ; Sat, 5 Apr 2014 22:31:41 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WWZ7f-000AcR-AK; Sat, 05 Apr 2014 22:31:35 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s35MVWE5089792; Sat, 5 Apr 2014 16:31:32 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+fCK2zplwlclAKbPJ1WFeC Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT From: Ian Lepore To: Andreas Tobler In-Reply-To: <53407B53.4040807@fgznet.ch> References: <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> <53407B53.4040807@fgznet.ch> Content-Type: text/plain; charset="us-ascii" Date: Sat, 05 Apr 2014 16:31:31 -0600 Message-ID: <1396737091.81853.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 22:31:42 -0000 On Sat, 2014-04-05 at 23:53 +0200, Andreas Tobler wrote: > On 05.04.14 23:10, Ian Lepore wrote: > > On Sat, 2014-04-05 at 22:54 +0200, Andreas Tobler wrote: > >> Hi all, > >> > >> I'm very new to arm hardware, but not to FreeBSD. > >> I got my hands on a broken (software like) ix2-200 Iomega StorCenter. A > >> few wires and a screen session allowed me to dive into it and I tried to > >> boot -CURRENT on it. Below where I end. > >> > >> The config I used is the DB-88F6XXX with enabling the INVARIANTS etc. > >> The board itself identifies as the subject says. It has this: > >> Soc: 88F6281 A0CPU running @ 1000Mhz L2 running @ 333Mhz > >> SysClock = 333Mhz , TClock = 200Mhz > >> DRAM (DDR2) CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 > >> DRAM CS[0] base 0x00000000 size 256 > >> > >> Has anyone a hint or an idea where to start debugging this? > >> > >> TIA, > >> Andreas > >> > >> [...] > > > > Easy things first, I guess... in sys/boot/fdt/dts/db88f6281.dts I see > > > > reg = <0x0 0x20000000>; // 512M at 0x0 > > > > Try cutting that in half and rebuilding the kernel. > > Yep, simple thing! As said, new to the hardware :) > > Thanks a lot. > > Sure, now I 'hang' in an other area. > > mge0: mem 0x72000-0x73fff irq > 12,13,14,11,46 on simplebus0 > mge0: Ethernet address: 00:d0:b8:1e:3b:df > mge0: attaching PHYs failed > --> hangs > According to the u-boot env I have two eth's and only the second is > wired and used. > > From u-boot: > Net: egiga0, egiga1 [PRIME] > > Now my questions, how do I enable verbose boot? On PowerPC I know I have > to do it in boot/loader.conf, here too? > > I guess my hardware is different from an eval board, so I expect I'd > need a customized dts, no? If so, how do I get the information out of > the u-boot? > Again, thx a lot! > Andreas You're probably not even using loader(8) but rather launching the kernel directly (only newer arm systems and newer versions of u-boot use loader). That means things like tunables and bootverbose have to be hacked into the kernel, at least for now to make some progress. The initarm_early_init() routine in arm/mv/mv_machdep.c is a good place to throw in a bootverbose=1. For disabling egiga0 just add status="disabled" to its entry in the dts file. Have a look at the dreamplug dts files for an example of setting up egiga1, but I'm not sure everything will be exactly the same. You may need to transplant the phy0 entry from egiga0 into egiga1 for that box. The 'bdinfo' command in u-boot sometimes shows lots of good info, sometimes not so much. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 00:21:19 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A59D37C; Sun, 6 Apr 2014 00:21:19 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 790D9E19; Sun, 6 Apr 2014 00:21:18 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WWapp-000Dj5-OQ; Sun, 06 Apr 2014 00:21:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s360LF36089841; Sat, 5 Apr 2014 18:21:15 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18+yGMzpM/IYDHRZ7DMpZ6g Subject: Re: ARM SMP is ready for prime time on FreeBSD From: Ian Lepore To: Zbigniew Bodek In-Reply-To: References: <1396645871.81853.330.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 05 Apr 2014 18:21:15 -0600 Message-ID: <1396743675.81853.343.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 00:21:19 -0000 On Sat, 2014-04-05 at 14:09 +0200, Zbigniew Bodek wrote: > 2014-04-04 23:11 GMT+02:00 Ian Lepore : > > Thanks to the contributions of many dedicated freebsd-arm hackers over > > the past few months, it looks like SMP is now solid enough for everyday > > use. SMP has been "kinda working" for a while, but I think the pmap > > fixes we've been working on for the past few weeks have made things > > pretty robust. I've had continuous stress-testing on running on dual > > and quad-core boards with a multi-threaded app that maxes out all the > > cores with heavy floating point and network IO and haven't had any app > > crashes or kernel panics for a couple weeks. > > > > I've updated the kernel configs for the platforms I know have multiple > > cores, as of r264138. > > > > -- Ian > > > > Great work guys. Thank you. > > Best regards > zbb I discovered today that I somehow dropped a couple TLB flushes in putting together the commit for r264129, so anyone using SMP should update to today's r264183 or later. Sorry 'bout that. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 15:59:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A308985C for ; Sun, 6 Apr 2014 15:59:06 +0000 (UTC) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73DF2B58 for ; Sun, 6 Apr 2014 15:59:06 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id y10so5397995pdj.8 for ; Sun, 06 Apr 2014 08:58:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=w87h9/o7KcM6tVM/lombVw+RMnQYvqpvhE16h/2aGNg=; b=hBjy9FCRHK5CY8KV5iTfSJ0LQ6y6JQt9dvEGbicnh+pp0TQvXHiHlQzfr/iU5v+cn4 yZDv3k6YwjdF6IpFVs4jUDQ/Jx6Q03v9i1mEyipP4z/lK5q6qeoYDxCImwuCNjFaRkgd aOQFL4B/lifoRR1WZTkE7A578jMhHc75kpRK7UKkQdJJZlQRum9O0g+BX52i9dHWkoEy e3Dx3MOQycqJzRWi8W574SZ1QQuYcW9lvUG5qVUsTe4vcp9qDaA0fr+BwtzmWu8/FV+p l40kUn7KXPJnyOu4z3EfD6T5J/LgCHJ49VlvparhGQfYsevhzcZBxZYGFhWi7waF9WBs DdcQ== X-Gm-Message-State: ALoCoQnJWFffp0WLORvgSzBhJaGh6pQNaWW0CEM6BRBcPbwJExQ3rzmE7m5f8uZfMVuwqIrwxxpk X-Received: by 10.66.122.201 with SMTP id lu9mr26284678pab.40.1396799939077; Sun, 06 Apr 2014 08:58:59 -0700 (PDT) Received: from lgmac-josharris.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id et3sm30962804pbc.52.2014.04.06.08.58.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Apr 2014 08:58:58 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Building an image for Raspberry Pi From: Warner Losh In-Reply-To: <525F718A-53F7-4172-9D23-190D1364AD0A@kientzle.com> Date: Sun, 6 Apr 2014 09:58:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <20140403054106.GT14379@glenbarber.us> <20140403061443.GD71905@pwnie.vrt.sourcefire.com> <525F718A-53F7-4172-9D23-190D1364AD0A@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1874) Cc: Glen Barber , FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 15:59:06 -0000 On Apr 5, 2014, at 11:14 AM, Tim Kientzle wrote: >=20 > On Apr 2, 2014, at 11:14 PM, Shawn Webb wrote: >=20 >> On Apr 03, 2014 01:41 AM -0400, Glen Barber wrote: >>> You need to build the XDEV stuff for the build environment. >>>=20 >>> Something like: make -C /usr/src XDEV=3Darm XDEV_ARCH=3Darmv6 >>>=20 >>> should do the trick. >>=20 >> Yeah, I have the xdev stuff installed. It kinda seems like just using >> this xdev stuff isn't sufficient. It seems u-boot might require some >> gcc-centric items (though I'm unsure what they are). >=20 > Unfortunately, my time has been rather cramped, though > Tom Everett and Patrick Kelsey have been doing a bunch > of Crochet work recently. >=20 > The confusing part about U-Boot is that it requires two different = compilers to build: >=20 > * Building the U-Boot loader needs an ARM cross-compiler and relies on = GCC-specific options. >=20 > * U-Boot also builds some tools that run on the build host; that uses = a different native compiler and does not seem to rely on GCC-specific = features. >=20 > For the host tools, setting HOSTCC=3Dcc always worked well > for me. I never had any problems with clang or gcc as the > native host compiler for that part of U-Boot. >=20 > For the loader itself, you can try the XDEV tools (which last > I checked still built GCC) or you can try the ARM EABI > GCC cross-compiler from ports (which may be broken; I > volunteered to maintain it and then ran out of time to work on it). >=20 > One specific GCC-ism used by U-Boot (an option to reserve > a specific CPU register for global data) was added to clang > recently but I don't know if that's reached FreeBSD yet. That > might allow clang to build the U-Boot loader, but it will require > some work: the XDEV target also builds ARM binutils and > cross-libraries which are essential. With the switch to clang on arm recently, the XDEV tools have started = building a clang compiler. Should we force it to build a gcc compiler = instead? Warner From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 16:52:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0208DA08; Sun, 6 Apr 2014 16:52:57 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B47E869; Sun, 6 Apr 2014 16:52:56 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s36Gqr1u007057; Sun, 6 Apr 2014 16:52:53 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.100] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id eq38y4svinnxii5m3ya5a5dbwn; Sun, 06 Apr 2014 16:52:53 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Building an image for Raspberry Pi From: Tim Kientzle In-Reply-To: Date: Sun, 6 Apr 2014 09:52:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <20140403054106.GT14379@glenbarber.us> <20140403061443.GD71905@pwnie.vrt.sourcefire.com> <525F718A-53F7-4172-9D23-190D1364AD0A@kientzle.com> To: Warner Losh X-Mailer: Apple Mail (2.1874) Cc: Glen Barber , FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 16:52:57 -0000 On Apr 6, 2014, at 8:58 AM, Warner Losh wrote: >=20 > On Apr 5, 2014, at 11:14 AM, Tim Kientzle wrote: >=20 >>=20 >> On Apr 2, 2014, at 11:14 PM, Shawn Webb wrote: >>=20 >>> On Apr 03, 2014 01:41 AM -0400, Glen Barber wrote: >>>> You need to build the XDEV stuff for the build environment. >>>>=20 >>>> Something like: make -C /usr/src XDEV=3Darm XDEV_ARCH=3Darmv6 >>>>=20 >>>> should do the trick. >>>=20 >>> Yeah, I have the xdev stuff installed. It kinda seems like just = using >>> this xdev stuff isn't sufficient. It seems u-boot might require some >>> gcc-centric items (though I'm unsure what they are). >>=20 >> Unfortunately, my time has been rather cramped, though >> Tom Everett and Patrick Kelsey have been doing a bunch >> of Crochet work recently. >>=20 >> The confusing part about U-Boot is that it requires two different = compilers to build: >>=20 >> * Building the U-Boot loader needs an ARM cross-compiler and relies = on GCC-specific options. >>=20 >> * U-Boot also builds some tools that run on the build host; that uses = a different native compiler and does not seem to rely on GCC-specific = features. >>=20 >> For the host tools, setting HOSTCC=3Dcc always worked well >> for me. I never had any problems with clang or gcc as the >> native host compiler for that part of U-Boot. >>=20 >> For the loader itself, you can try the XDEV tools (which last >> I checked still built GCC) or you can try the ARM EABI >> GCC cross-compiler from ports (which may be broken; I >> volunteered to maintain it and then ran out of time to work on it). >>=20 >> One specific GCC-ism used by U-Boot (an option to reserve >> a specific CPU register for global data) was added to clang >> recently but I don't know if that's reached FreeBSD yet. That >> might allow clang to build the U-Boot loader, but it will require >> some work: the XDEV target also builds ARM binutils and >> cross-libraries which are essential. >=20 > With the switch to clang on arm recently, the XDEV tools have started = building a clang compiler. Should we force it to build a gcc compiler = instead? Certainly, it would be nice to have an option for a GCC XDEV. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 16:56:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A281A60; Sun, 6 Apr 2014 16:56:29 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.glenbarber.us", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 674FD9B; Sun, 6 Apr 2014 16:56:29 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id C407E7B40; Sun, 6 Apr 2014 16:56:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us C407E7B40 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 6 Apr 2014 12:56:19 -0400 From: Glen Barber To: Tim Kientzle Subject: Re: Building an image for Raspberry Pi Message-ID: <20140406165619.GA14379@glenbarber.us> References: <20140403005755.GA71905@pwnie.vrt.sourcefire.com> <20140403054106.GT14379@glenbarber.us> <20140403061443.GD71905@pwnie.vrt.sourcefire.com> <525F718A-53F7-4172-9D23-190D1364AD0A@kientzle.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XeYnZTu7hwE7l7sm" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 16:56:29 -0000 --XeYnZTu7hwE7l7sm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 06, 2014 at 09:52:53AM -0700, Tim Kientzle wrote: > > With the switch to clang on arm recently, the XDEV tools have > > started building a clang compiler. Should we force it to build a > > gcc compiler instead? >=20 > Certainly, it would be nice to have an option for a GCC XDEV. >=20 I wonder if this is why I have not run into this build failure. I'm forcing existence of gcc(1), and set WITH_GCC=3D1 for the xdev build: =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=3D=3D=3D head/release/arm/release.sh: 98 eval chroot ${CHROOTDIR} make -C /usr/src/gnu/usr.bin/cc \ 99 WITH_GCC=3D1 ${WORLD_FLAGS} -j1 obj depend all install 100 # Build the 'xdev' target for crochet. 101 eval chroot ${CHROOTDIR} make -C /usr/src \ 102 XDEV=3D${XDEV} XDEV_ARCH=3D${XDEV_ARCH} WITH_GCC=3D1 \ 103 ${WORLD_FLAGS} xdev =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=3D=3D=3D Unless this change is too recent (within the last week), and I just haven't built against these changes yet. Glen --XeYnZTu7hwE7l7sm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTQYczAAoJELls3eqvi17QugsP/0qRM5Jvt+GF9+8UrVliTVut BgEPupa7ybYZ4dhwJEJ6g6zq2pO/+VOkMEDBJexppFAcn+giYBlibmbYjsFmgjU1 PPfZ6tT4CU5LrTgK/SgU52H+o81W05bmmfi327vleS40OJycNxSdBkC6LEFT+hzT rrkfIaxevM3/T8ASFLnA16hRzBpH7RtlNFuOSFuT76pwqQGx+jO7RxH4uNeGbDx2 ln0W54zpAf7o9cRZ2shVftTCahCL34Xlp6qLOGULjBSFmyOOCPX95TbzL2Smopga DJ25dyAYmm4q0JUNqTjU4IY1q8FQCLllXkTZKjWJx4yKpF4NKLNJp0DkO6CV8c4M JV+7G4qhvWoa1tdXGE1CKFpHI1h+EeuWZCTlzEVo3IMTPCKjh9S4+xim/73w+Yzo OtsFnE6drb9N3FlAUKLNRLjjcmcSWC4uziSFyHpVGAYwgPgF2y9lAOAltqHvVynW obrhVJAk9yR+c7ZrU4piHO9p1DMuMr2PsQZHYgvPN+9GUCQCfg7FWOptFxHhsWMH eZUMEFzaKaiULYNaUQeawTeIzWNX7eMEbLUUB8ua9MHyFxTsdyH23ykoOwVMgfxw 01kKmau3TJGt6is76ZYXlnfgrysV2XZcU+p9jP0AF58uW7oVjz4BGTXOJMJOXwxj C069OR0vpc0A07+pg9ew =bIbD -----END PGP SIGNATURE----- --XeYnZTu7hwE7l7sm-- From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 17:26:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA0015E2 for ; Sun, 6 Apr 2014 17:26:40 +0000 (UTC) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id 76B172F9 for ; Sun, 6 Apr 2014 17:26:40 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.10.1.20] ([83.19.65.138]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N3M00E0UDJOGA00@mta.uoks.uj.edu.pl> for freebsd-arm@freebsd.org; Sun, 06 Apr 2014 19:21:25 +0200 (CEST) Received: from [10.10.1.20] by saiph.uoks.uj.edu.pl (Dr.Web (R) milter module ver.6.0.2.2) ; Sun, 06 Apr 2014 19:21:24 +0200 Received: from [10.10.1.20] ([83.19.65.138]) by mta.uoks.uj.edu.pl with ESMTPSA; Sun, 06 Apr 2014 19:21:24 +0200 (CEST) Date: Sun, 06 Apr 2014 19:21:23 +0200 From: Jakub Klama In-reply-to: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> Message-id: <53418D13.7030107@freebsd.org> References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> Subject: [RFC] Refactored interrupt handling on ARM To: freebsd-arm@freebsd.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 X-Forwarded-Message-Id: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.2 X-Antivirus-Code: 0x100000 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 17:26:40 -0000 Hello all, It has been a long time since my SoC 2012 ended. However, I've finally merged refactored interrupt handling framework to head and added SMP support (IPIs). Let's start: What is this and how does it work? It's a refactored interrupt handling code for ARM which supports multiple, stacked interrupt controllers. In particular, it creates a clean way to support IRQ multiplexers such as GPIO controllers with interrupt generation functionality. Approach used in this code is somewhat similar to one usedin powerpc port. Every interrupt controller should implement methods from pic_if.m interface - at least pic_config, pic_unmask, pic_mask and pic_eoi. It should also install IRQ handler on parent interrupt controller (specified by interrupt-parent in FDT, defaulting to nexus). The root interrupt controller is nexus - on ARM it has exactly one IRQ line (typically nexus0:0) representing core IRQ signal (on MIPS, there will be probably five of them). SoC interrupt controller, such as GIC then installs handler on nexus0:0 IRQ and exposes itself as interrupt controller by calling arm_register_pic(). When the interrupt arrives, pic driver calls arm_dispatch_irq() function. So, for example, a typical SoC interrupt tree can look like that: nexus0 (provides 1 irq) | \-- gic0 (provides 160 irqs, uses irq nexus0:0) | \-- gpio0 (provides 8 irqs, uses irq gic0:42) | | | \-- mmcsd0 (uses irqs gpio0:1, gpio0:2) | \-- spi0 (uses irq gpio0:3) | ... \-- gpio1 (provides 8 irqs, uses irq gic0:43) \-- ehci0 (uses irq gic0:109) ... Interrupt numbers used in rman are composed of two 8-bit fields: higher 8 bits are the pic index and lower 8 bits are IRQ line number inside particular pic (so there are 256 pics supported with maximum of 256 irq lines on each). These numbers are generated using FDT_MAP_IRQ() macro called from FDT code. As you can see from the provided dmesg logs, irq numbers are printed in form of "pic_name:line_number", i.e: "nexus0:0" or "gic0:109". Of course there's still support for shared interrupt handlers - on LPC3250 there are 3 pics attached to one in-core IRQ line. There's also support for IPIs. Calls to pic_ipi_get(), pic_ipi_clear(), pic_ipi_send() and ..._init_secondary() are redirected to one interrupt controller registered as capable to do IPIs. There can be only one interrupt controller with IPI support registered (and certainly not the root one). Code was tested on following platforms: * EA3250 (arm/lpc) * Pandaboard (arm/ti) (both with SMP enabled and disabled) Merging it would not require any changes in existing ARM ports (unless they will be adopted to new framework and will have ARM_INTRNG option enabled), except for adding arm/arm/intr.c to their file lists (as it's now not compiled-in by default). That was tested too. dmesg outputs can be found there: * http://people.freebsd.org/~jceel/intrng/pandaboard.dmesg.txt * http://people.freebsd.org/~jceel/intrng/ea3250.dmesg.txt diff against head as of r264192: * http://people.freebsd.org/~jceel/intrng/intrng.diff git branch containing the changes: * https://github.com/jceel/freebsd-arm-intrng/tree/intrng What do you think about that? That code probably needs some improvements, especially in IPI/SMP area, but I think it's a step further in interrupt handling on ARM. I really appreciate any comments and opinions. Regards, Jakub From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 19:42:50 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75563F25; Sun, 6 Apr 2014 19:42:50 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F289230C; Sun, 6 Apr 2014 19:42:49 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s36JgKJj047684; Sun, 6 Apr 2014 21:42:34 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <5341AE1C.4040207@fgznet.ch> Date: Sun, 06 Apr 2014 21:42:20 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT References: <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> <53407B53.4040807@fgznet.ch> <1396737091.81853.339.camel@revolution.hippie.lan> In-Reply-To: <1396737091.81853.339.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 19:42:50 -0000 On 06.04.14 00:31, Ian Lepore wrote: > On Sat, 2014-04-05 at 23:53 +0200, Andreas Tobler wrote: >> On 05.04.14 23:10, Ian Lepore wrote: >>> On Sat, 2014-04-05 at 22:54 +0200, Andreas Tobler wrote: >>>> Hi all, >>>> >>>> I'm very new to arm hardware, but not to FreeBSD. >>>> I got my hands on a broken (software like) ix2-200 Iomega StorCenter. A >>>> few wires and a screen session allowed me to dive into it and I tried to >>>> boot -CURRENT on it. Below where I end. >>>> >>>> The config I used is the DB-88F6XXX with enabling the INVARIANTS etc. >>>> The board itself identifies as the subject says. It has this: >>>> Soc: 88F6281 A0CPU running @ 1000Mhz L2 running @ 333Mhz >>>> SysClock = 333Mhz , TClock = 200Mhz >>>> DRAM (DDR2) CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 >>>> DRAM CS[0] base 0x00000000 size 256 >>>> >>>> Has anyone a hint or an idea where to start debugging this? >>>> >>>> TIA, >>>> Andreas >>>> >>>> [...] >>> >>> Easy things first, I guess... in sys/boot/fdt/dts/db88f6281.dts I see >>> >>> reg = <0x0 0x20000000>; // 512M at 0x0 >>> >>> Try cutting that in half and rebuilding the kernel. >> >> Yep, simple thing! As said, new to the hardware :) >> >> Thanks a lot. >> >> Sure, now I 'hang' in an other area. >> >> mge0: mem 0x72000-0x73fff irq >> 12,13,14,11,46 on simplebus0 >> mge0: Ethernet address: 00:d0:b8:1e:3b:df >> mge0: attaching PHYs failed >> --> hangs >> According to the u-boot env I have two eth's and only the second is >> wired and used. >> >> From u-boot: >> Net: egiga0, egiga1 [PRIME] >> >> Now my questions, how do I enable verbose boot? On PowerPC I know I have >> to do it in boot/loader.conf, here too? >> >> I guess my hardware is different from an eval board, so I expect I'd >> need a customized dts, no? If so, how do I get the information out of >> the u-boot? >> Again, thx a lot! >> Andreas > > You're probably not even using loader(8) but rather launching the kernel > directly (only newer arm systems and newer versions of u-boot use > loader). That means things like tunables and bootverbose have to be > hacked into the kernel, at least for now to make some progress. The > initarm_early_init() routine in arm/mv/mv_machdep.c is a good place to > throw in a bootverbose=1. Ok. I did it in sys/kern/init_main.c > For disabling egiga0 just add status="disabled" to its entry in the dts > file. Have a look at the dreamplug dts files for an example of setting > up egiga1, but I'm not sure everything will be exactly the same. You > may need to transplant the phy0 entry from egiga0 into egiga1 for that > box. Good start, thanks. > The 'bdinfo' command in u-boot sometimes shows lots of good info, > sometimes not so much. Hm, this command is not available in my env. Anyway, I figured to play with the regs in the enet dts section and I managed to get it up. Unfortunately I don't get any dhcp requests to the server, so no ack can be given. I'll play around. Sending DHCP Discover packet from interface mge0 (00:d0:b8:1e:3b:df) .... DHCP/BOOTP timeout for server 255.255.255.255 .... Thanks again! Andreas From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 20:11:00 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FA1390D for ; Sun, 6 Apr 2014 20:11:00 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F3E257B4 for ; Sun, 6 Apr 2014 20:10:59 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WWtP6-000EJq-VZ; Sun, 06 Apr 2014 20:10:57 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s36KArTq090684; Sun, 6 Apr 2014 14:10:53 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/3T8z0l1wwwJde32aIXvoT Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT From: Ian Lepore To: Andreas Tobler In-Reply-To: <5341AE1C.4040207@fgznet.ch> References: <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> <53407B53.4040807@fgznet.ch> <1396737091.81853.339.camel@revolution.hippie.lan> <5341AE1C.4040207@fgznet.ch> Content-Type: text/plain; charset="us-ascii" Date: Sun, 06 Apr 2014 14:10:52 -0600 Message-ID: <1396815052.81853.346.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 20:11:00 -0000 On Sun, 2014-04-06 at 21:42 +0200, Andreas Tobler wrote: > On 06.04.14 00:31, Ian Lepore wrote: > > On Sat, 2014-04-05 at 23:53 +0200, Andreas Tobler wrote: > >> On 05.04.14 23:10, Ian Lepore wrote: > >>> On Sat, 2014-04-05 at 22:54 +0200, Andreas Tobler wrote: > >>>> Hi all, > >>>> > >>>> I'm very new to arm hardware, but not to FreeBSD. > >>>> I got my hands on a broken (software like) ix2-200 Iomega StorCenter. A > >>>> few wires and a screen session allowed me to dive into it and I tried to > >>>> boot -CURRENT on it. Below where I end. > >>>> > >>>> The config I used is the DB-88F6XXX with enabling the INVARIANTS etc. > >>>> The board itself identifies as the subject says. It has this: > >>>> Soc: 88F6281 A0CPU running @ 1000Mhz L2 running @ 333Mhz > >>>> SysClock = 333Mhz , TClock = 200Mhz > >>>> DRAM (DDR2) CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 > >>>> DRAM CS[0] base 0x00000000 size 256 > >>>> > >>>> Has anyone a hint or an idea where to start debugging this? > >>>> > >>>> TIA, > >>>> Andreas > >>>> > >>>> [...] > >>> > >>> Easy things first, I guess... in sys/boot/fdt/dts/db88f6281.dts I see > >>> > >>> reg = <0x0 0x20000000>; // 512M at 0x0 > >>> > >>> Try cutting that in half and rebuilding the kernel. > >> > >> Yep, simple thing! As said, new to the hardware :) > >> > >> Thanks a lot. > >> > >> Sure, now I 'hang' in an other area. > >> > >> mge0: mem 0x72000-0x73fff irq > >> 12,13,14,11,46 on simplebus0 > >> mge0: Ethernet address: 00:d0:b8:1e:3b:df > >> mge0: attaching PHYs failed > >> --> hangs > >> According to the u-boot env I have two eth's and only the second is > >> wired and used. > >> > >> From u-boot: > >> Net: egiga0, egiga1 [PRIME] > >> > >> Now my questions, how do I enable verbose boot? On PowerPC I know I have > >> to do it in boot/loader.conf, here too? > >> > >> I guess my hardware is different from an eval board, so I expect I'd > >> need a customized dts, no? If so, how do I get the information out of > >> the u-boot? > >> Again, thx a lot! > >> Andreas > > > > You're probably not even using loader(8) but rather launching the kernel > > directly (only newer arm systems and newer versions of u-boot use > > loader). That means things like tunables and bootverbose have to be > > hacked into the kernel, at least for now to make some progress. The > > initarm_early_init() routine in arm/mv/mv_machdep.c is a good place to > > throw in a bootverbose=1. > > Ok. I did it in sys/kern/init_main.c > > > For disabling egiga0 just add status="disabled" to its entry in the dts > > file. Have a look at the dreamplug dts files for an example of setting > > up egiga1, but I'm not sure everything will be exactly the same. You > > may need to transplant the phy0 entry from egiga0 into egiga1 for that > > box. > > Good start, thanks. > > > The 'bdinfo' command in u-boot sometimes shows lots of good info, > > sometimes not so much. > > Hm, this command is not available in my env. > Anyway, I figured to play with the regs in the enet dts section and I > managed to get it up. Unfortunately I don't get any dhcp requests to the > server, so no ack can be given. I'll play around. > > Sending DHCP Discover packet from interface mge0 (00:d0:b8:1e:3b:df) > .... > DHCP/BOOTP timeout for server 255.255.255.255 > .... > > Thanks again! > Andreas I just realized that there's likely to be dts source for that box in linux, and sure enough: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts There should be a lot of good clues in there, although we're not quite so compatible that you can necessarily just paste linux dts code into our dts files. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 20:13:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60803955 for ; Sun, 6 Apr 2014 20:13:08 +0000 (UTC) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26FB17C0 for ; Sun, 6 Apr 2014 20:13:07 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id uy17so2879928igb.9 for ; Sun, 06 Apr 2014 13:13:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xrJqxZRxdHGuvLrYmy34lz0l+qT5VYG8ay0s7w6PPg0=; b=E0ZmY8czN+fg0GKR8lw82nThsmT207LJKmnvvzGt2EDxpw6mJsVTYRKIhddQ+u8F8q BZWbWvlfPPuBx2bJuSRVkB+dXt/zQNpqdpo1YQNjZlYTt9QnNQV61O174tHjMnKHC1p+ 3n7FDOEykemdi/5HdBJrniniwVYnjA750TK0gNmgcUXrVWvjtm/ybThXvC0fZBS8ZBzv Ldj1SKBW3lcbdMVyRUt2JeVHnMxIjYJN5h5zeV0kYZf1xWMtVIy5Z5643OGoRh6xwbSn eqcMzjrMWHXhPJEQ0lP2mWOBDyJ2gq5pMREvdDgOz0xlU9qcVa/LfG6S/xmFTfjzrhhv 8GMg== X-Gm-Message-State: ALoCoQmAYGuv4/cHWHnvNF12KPn6jpxjgSJCoJSEPOcFPU7tQqVdwmxzaomvMw4tCLiDlE6N0H9x X-Received: by 10.50.43.134 with SMTP id w6mr16211184igl.3.1396815180933; Sun, 06 Apr 2014 13:13:00 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id y9sm24096809igl.7.2014.04.06.13.13.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Apr 2014 13:13:00 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT From: Warner Losh In-Reply-To: <1396815052.81853.346.camel@revolution.hippie.lan> Date: Sun, 6 Apr 2014 14:12:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> <53407B53.4040807@fgznet.ch> <1396737091.81853.339.camel@revolution.hippie.lan> <5341AE1C.4040207@fgznet.ch> <1396815052.81853.346.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 20:13:08 -0000 On Apr 6, 2014, at 2:10 PM, Ian Lepore wrote: > On Sun, 2014-04-06 at 21:42 +0200, Andreas Tobler wrote: >> On 06.04.14 00:31, Ian Lepore wrote: >>> On Sat, 2014-04-05 at 23:53 +0200, Andreas Tobler wrote: >>>> On 05.04.14 23:10, Ian Lepore wrote: >>>>> On Sat, 2014-04-05 at 22:54 +0200, Andreas Tobler wrote: >>>>>> Hi all, >>>>>>=20 >>>>>> I'm very new to arm hardware, but not to FreeBSD. >>>>>> I got my hands on a broken (software like) ix2-200 Iomega = StorCenter. A >>>>>> few wires and a screen session allowed me to dive into it and I = tried to >>>>>> boot -CURRENT on it. Below where I end. >>>>>>=20 >>>>>> The config I used is the DB-88F6XXX with enabling the INVARIANTS = etc. >>>>>> The board itself identifies as the subject says. It has this: >>>>>> Soc: 88F6281 A0CPU running @ 1000Mhz L2 running @ 333Mhz >>>>>> SysClock =3D 333Mhz , TClock =3D 200Mhz >>>>>> DRAM (DDR2) CAS Latency =3D 5 tRP =3D 5 tRAS =3D 18 tRCD=3D6 >>>>>> DRAM CS[0] base 0x00000000 size 256 >>>>>>=20 >>>>>> Has anyone a hint or an idea where to start debugging this? >>>>>>=20 >>>>>> TIA, >>>>>> Andreas >>>>>>=20 >>>>>> [...] >>>>>=20 >>>>> Easy things first, I guess... in sys/boot/fdt/dts/db88f6281.dts I = see=20 >>>>>=20 >>>>> reg =3D <0x0 0x20000000>; // 512M at 0x0 >>>>>=20 >>>>> Try cutting that in half and rebuilding the kernel. >>>>=20 >>>> Yep, simple thing! As said, new to the hardware :) >>>>=20 >>>> Thanks a lot. >>>>=20 >>>> Sure, now I 'hang' in an other area. >>>>=20 >>>> mge0: mem 0x72000-0x73fff irq >>>> 12,13,14,11,46 on simplebus0 >>>> mge0: Ethernet address: 00:d0:b8:1e:3b:df >>>> mge0: attaching PHYs failed >>>> --> hangs >>>> According to the u-boot env I have two eth's and only the second is >>>> wired and used. >>>>=20 >>>> =46rom u-boot: >>>> Net: egiga0, egiga1 [PRIME] >>>>=20 >>>> Now my questions, how do I enable verbose boot? On PowerPC I know I = have >>>> to do it in boot/loader.conf, here too? >>>>=20 >>>> I guess my hardware is different from an eval board, so I expect = I'd >>>> need a customized dts, no? If so, how do I get the information out = of >>>> the u-boot? >>>> Again, thx a lot! >>>> Andreas >>>=20 >>> You're probably not even using loader(8) but rather launching the = kernel >>> directly (only newer arm systems and newer versions of u-boot use >>> loader). That means things like tunables and bootverbose have to be >>> hacked into the kernel, at least for now to make some progress. The >>> initarm_early_init() routine in arm/mv/mv_machdep.c is a good place = to >>> throw in a bootverbose=3D1. >>=20 >> Ok. I did it in sys/kern/init_main.c >>=20 >>> For disabling egiga0 just add status=3D"disabled" to its entry in = the dts >>> file. Have a look at the dreamplug dts files for an example of = setting >>> up egiga1, but I'm not sure everything will be exactly the same. = You >>> may need to transplant the phy0 entry from egiga0 into egiga1 for = that >>> box. >>=20 >> Good start, thanks. >>=20 >>> The 'bdinfo' command in u-boot sometimes shows lots of good info, >>> sometimes not so much. >>=20 >> Hm, this command is not available in my env. >> Anyway, I figured to play with the regs in the enet dts section and I >> managed to get it up. Unfortunately I don't get any dhcp requests to = the >> server, so no ack can be given. I'll play around. >>=20 >> Sending DHCP Discover packet from interface mge0 (00:d0:b8:1e:3b:df) >> .... >> DHCP/BOOTP timeout for server 255.255.255.255 >> .... >>=20 >> Thanks again! >> Andreas >=20 > I just realized that there's likely to be dts source for that box in > linux, and sure enough: >=20 > = https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-i= omega_ix2_200.dts >=20 > There should be a lot of good clues in there, although we're not quite > so compatible that you can necessarily just paste linux dts code into > our dts files. (a) We should fix the incompatibility. :) I do understand this may be = hardish=85 (b) All of Linux=92s files, as of the last major kernel release, are in = our vendor tree under base/vendor/device-tree. Warner= From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 20:44:18 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 050D948D; Sun, 6 Apr 2014 20:44:18 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E452AFF; Sun, 6 Apr 2014 20:44:16 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s36Ki3Aa044466; Sun, 6 Apr 2014 22:44:13 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <5341BC93.6080105@fgznet.ch> Date: Sun, 06 Apr 2014 22:44:03 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT References: <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> <53407B53.4040807@fgznet.ch> <1396737091.81853.339.camel@revolution.hippie.lan> <5341AE1C.4040207@fgznet.ch> <1396815052.81853.346.camel@revolution.hippie.lan> In-Reply-To: <1396815052.81853.346.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 20:44:18 -0000 On 06.04.14 22:10, Ian Lepore wrote: > On Sun, 2014-04-06 at 21:42 +0200, Andreas Tobler wrote: >> On 06.04.14 00:31, Ian Lepore wrote: >>> On Sat, 2014-04-05 at 23:53 +0200, Andreas Tobler wrote: >>>> On 05.04.14 23:10, Ian Lepore wrote: >>>>> On Sat, 2014-04-05 at 22:54 +0200, Andreas Tobler wrote: >>>>>> Hi all, >>>>>> >>>>>> I'm very new to arm hardware, but not to FreeBSD. >>>>>> I got my hands on a broken (software like) ix2-200 Iomega StorCenter. A >>>>>> few wires and a screen session allowed me to dive into it and I tried to >>>>>> boot -CURRENT on it. Below where I end. >>>>>> >>>>>> The config I used is the DB-88F6XXX with enabling the INVARIANTS etc. >>>>>> The board itself identifies as the subject says. It has this: >>>>>> Soc: 88F6281 A0CPU running @ 1000Mhz L2 running @ 333Mhz >>>>>> SysClock = 333Mhz , TClock = 200Mhz >>>>>> DRAM (DDR2) CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 >>>>>> DRAM CS[0] base 0x00000000 size 256 >>>>>> >>>>>> Has anyone a hint or an idea where to start debugging this? >>>>>> >>>>>> TIA, >>>>>> Andreas >>>>>> >>>>>> [...] >>>>> >>>>> Easy things first, I guess... in sys/boot/fdt/dts/db88f6281.dts I see >>>>> >>>>> reg = <0x0 0x20000000>; // 512M at 0x0 >>>>> >>>>> Try cutting that in half and rebuilding the kernel. >>>> >>>> Yep, simple thing! As said, new to the hardware :) >>>> >>>> Thanks a lot. >>>> >>>> Sure, now I 'hang' in an other area. >>>> >>>> mge0: mem 0x72000-0x73fff irq >>>> 12,13,14,11,46 on simplebus0 >>>> mge0: Ethernet address: 00:d0:b8:1e:3b:df >>>> mge0: attaching PHYs failed >>>> --> hangs >>>> According to the u-boot env I have two eth's and only the second is >>>> wired and used. >>>> >>>> From u-boot: >>>> Net: egiga0, egiga1 [PRIME] >>>> >>>> Now my questions, how do I enable verbose boot? On PowerPC I know I have >>>> to do it in boot/loader.conf, here too? >>>> >>>> I guess my hardware is different from an eval board, so I expect I'd >>>> need a customized dts, no? If so, how do I get the information out of >>>> the u-boot? >>>> Again, thx a lot! >>>> Andreas >>> >>> You're probably not even using loader(8) but rather launching the kernel >>> directly (only newer arm systems and newer versions of u-boot use >>> loader). That means things like tunables and bootverbose have to be >>> hacked into the kernel, at least for now to make some progress. The >>> initarm_early_init() routine in arm/mv/mv_machdep.c is a good place to >>> throw in a bootverbose=1. >> >> Ok. I did it in sys/kern/init_main.c >> >>> For disabling egiga0 just add status="disabled" to its entry in the dts >>> file. Have a look at the dreamplug dts files for an example of setting >>> up egiga1, but I'm not sure everything will be exactly the same. You >>> may need to transplant the phy0 entry from egiga0 into egiga1 for that >>> box. >> >> Good start, thanks. >> >>> The 'bdinfo' command in u-boot sometimes shows lots of good info, >>> sometimes not so much. >> >> Hm, this command is not available in my env. >> Anyway, I figured to play with the regs in the enet dts section and I >> managed to get it up. Unfortunately I don't get any dhcp requests to the >> server, so no ack can be given. I'll play around. >> >> Sending DHCP Discover packet from interface mge0 (00:d0:b8:1e:3b:df) >> .... >> DHCP/BOOTP timeout for server 255.255.255.255 >> .... >> >> Thanks again! >> Andreas > > I just realized that there's likely to be dts source for that box in > linux, and sure enough: > > https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts > > There should be a lot of good clues in there, although we're not quite > so compatible that you can necessarily just paste linux dts code into > our dts files. Yep, this is the place where I got the reg info, to change from xx to 0xb to get the interface attached. But nevertheless, I do not see any packets coming from this board. The tftpboot works, the dhcp-server works too, tested with ppc netboot. But this board does not really send out DHCPREQUESTS to the DHCP server. But maybe I hunt in the wrong place, I have to compare the other entries. Right now I concentrated on the eth0/1 part. Thanks. Andreas From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 21:12:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2BEBB05; Sun, 6 Apr 2014 21:12:55 +0000 (UTC) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3BCEBD50; Sun, 6 Apr 2014 21:12:54 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlab.sk with ESMTPA; Sun, 06 Apr 2014 23:07:24 +0200 id 00142003.5341C20C.00013921 Date: Sun, 6 Apr 2014 23:07:16 +0200 From: Milan Obuch To: Andreas Tobler Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT Message-ID: <20140406230716.13113e35@zeta.dino.sk> In-Reply-To: <5341BC93.6080105@fgznet.ch> References: <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> <53407B53.4040807@fgznet.ch> <1396737091.81853.339.camel@revolution.hippie.lan> <5341AE1C.4040207@fgznet.ch> <1396815052.81853.346.camel@revolution.hippie.lan> <5341BC93.6080105@fgznet.ch> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; i386-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 21:12:56 -0000 On Sun, 06 Apr 2014 22:44:03 +0200 Andreas Tobler wrote: > On 06.04.14 22:10, Ian Lepore wrote: > > On Sun, 2014-04-06 at 21:42 +0200, Andreas Tobler wrote: > >> On 06.04.14 00:31, Ian Lepore wrote: > >>> On Sat, 2014-04-05 at 23:53 +0200, Andreas Tobler wrote: [ snip ] > >>>> Sure, now I 'hang' in an other area. > >>>> > >>>> mge0: mem 0x72000-0x73fff > >>>> irq 12,13,14,11,46 on simplebus0 > >>>> mge0: Ethernet address: 00:d0:b8:1e:3b:df > >>>> mge0: attaching PHYs failed > >>>> --> hangs > >>>> According to the u-boot env I have two eth's and only the second > >>>> is wired and used. > >>>> > >>>> From u-boot: > >>>> Net: egiga0, egiga1 [PRIME] > >>>> > >>>> Now my questions, how do I enable verbose boot? On PowerPC I > >>>> know I have to do it in boot/loader.conf, here too? > >>>> > >>>> I guess my hardware is different from an eval board, so I expect > >>>> I'd need a customized dts, no? If so, how do I get the > >>>> information out of the u-boot? > >>>> Again, thx a lot! > >>>> Andreas > >>> > >>> You're probably not even using loader(8) but rather launching the > >>> kernel directly (only newer arm systems and newer versions of > >>> u-boot use loader). That means things like tunables and > >>> bootverbose have to be hacked into the kernel, at least for now > >>> to make some progress. The initarm_early_init() routine in > >>> arm/mv/mv_machdep.c is a good place to throw in a bootverbose=1. > >> > >> Ok. I did it in sys/kern/init_main.c > >> > >>> For disabling egiga0 just add status="disabled" to its entry in > >>> the dts file. Have a look at the dreamplug dts files for an > >>> example of setting up egiga1, but I'm not sure everything will be > >>> exactly the same. You may need to transplant the phy0 entry from > >>> egiga0 into egiga1 for that box. > >> > >> Good start, thanks. > >> > >>> The 'bdinfo' command in u-boot sometimes shows lots of good info, > >>> sometimes not so much. > >> > >> Hm, this command is not available in my env. > >> Anyway, I figured to play with the regs in the enet dts section > >> and I managed to get it up. Unfortunately I don't get any dhcp > >> requests to the server, so no ack can be given. I'll play around. > >> > >> Sending DHCP Discover packet from interface mge0 > >> (00:d0:b8:1e:3b:df) .... > >> DHCP/BOOTP timeout for server 255.255.255.255 > >> .... > >> > >> Thanks again! > >> Andreas > > > > I just realized that there's likely to be dts source for that box in > > linux, and sure enough: > > > > https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts > > > > There should be a lot of good clues in there, although we're not > > quite so compatible that you can necessarily just paste linux dts > > code into our dts files. > > Yep, this is the place where I got the reg info, to change from xx to > 0xb to get the interface attached. But nevertheless, I do not see any > packets coming from this board. The tftpboot works, the dhcp-server > works too, tested with ppc netboot. But this board does not really > send out DHCPREQUESTS to the DHCP server. > > But maybe I hunt in the wrong place, I have to compare the other > entries. Right now I concentrated on the eth0/1 part. > > Thanks. > Andreas > Maybe you need to check pin multiplexer setup. If eth1 is not connected to pins, there is no connectivity. Some time ago I did have just this problem - no packets on the wire, but it looked like mge1 interface works well... after I found multiplexed pin setup, all was clear to me. Milan From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 21:16:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 167A5B83; Sun, 6 Apr 2014 21:16:29 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B262FD70; Sun, 6 Apr 2014 21:16:27 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s36LGHMd086184; Sun, 6 Apr 2014 23:16:24 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <5341C421.90209@fgznet.ch> Date: Sun, 06 Apr 2014 23:16:17 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Milan Obuch Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT References: <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> <53407B53.4040807@fgznet.ch> <1396737091.81853.339.camel@revolution.hippie.lan> <5341AE1C.4040207@fgznet.ch> <1396815052.81853.346.camel@revolution.hippie.lan> <5341BC93.6080105@fgznet.ch> <20140406230716.13113e35@zeta.dino.sk> In-Reply-To: <20140406230716.13113e35@zeta.dino.sk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 21:16:29 -0000 On 06.04.14 23:07, Milan Obuch wrote: > On Sun, 06 Apr 2014 22:44:03 +0200 > Andreas Tobler wrote: > >> On 06.04.14 22:10, Ian Lepore wrote: >>> On Sun, 2014-04-06 at 21:42 +0200, Andreas Tobler wrote: >>>> On 06.04.14 00:31, Ian Lepore wrote: >>>>> On Sat, 2014-04-05 at 23:53 +0200, Andreas Tobler wrote: > > [ snip ] > >>>>>> Sure, now I 'hang' in an other area. >>>>>> >>>>>> mge0: mem 0x72000-0x73fff >>>>>> irq 12,13,14,11,46 on simplebus0 >>>>>> mge0: Ethernet address: 00:d0:b8:1e:3b:df >>>>>> mge0: attaching PHYs failed >>>>>> --> hangs >>>>>> According to the u-boot env I have two eth's and only the second >>>>>> is wired and used. >>>>>> >>>>>> From u-boot: >>>>>> Net: egiga0, egiga1 [PRIME] >>>>>> >>>>>> Now my questions, how do I enable verbose boot? On PowerPC I >>>>>> know I have to do it in boot/loader.conf, here too? >>>>>> >>>>>> I guess my hardware is different from an eval board, so I expect >>>>>> I'd need a customized dts, no? If so, how do I get the >>>>>> information out of the u-boot? >>>>>> Again, thx a lot! >>>>>> Andreas >>>>> >>>>> You're probably not even using loader(8) but rather launching the >>>>> kernel directly (only newer arm systems and newer versions of >>>>> u-boot use loader). That means things like tunables and >>>>> bootverbose have to be hacked into the kernel, at least for now >>>>> to make some progress. The initarm_early_init() routine in >>>>> arm/mv/mv_machdep.c is a good place to throw in a bootverbose=1. >>>> >>>> Ok. I did it in sys/kern/init_main.c >>>> >>>>> For disabling egiga0 just add status="disabled" to its entry in >>>>> the dts file. Have a look at the dreamplug dts files for an >>>>> example of setting up egiga1, but I'm not sure everything will be >>>>> exactly the same. You may need to transplant the phy0 entry from >>>>> egiga0 into egiga1 for that box. >>>> >>>> Good start, thanks. >>>> >>>>> The 'bdinfo' command in u-boot sometimes shows lots of good info, >>>>> sometimes not so much. >>>> >>>> Hm, this command is not available in my env. >>>> Anyway, I figured to play with the regs in the enet dts section >>>> and I managed to get it up. Unfortunately I don't get any dhcp >>>> requests to the server, so no ack can be given. I'll play around. >>>> >>>> Sending DHCP Discover packet from interface mge0 >>>> (00:d0:b8:1e:3b:df) .... >>>> DHCP/BOOTP timeout for server 255.255.255.255 >>>> .... >>>> >>>> Thanks again! >>>> Andreas >>> >>> I just realized that there's likely to be dts source for that box in >>> linux, and sure enough: >>> >>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts >>> >>> There should be a lot of good clues in there, although we're not >>> quite so compatible that you can necessarily just paste linux dts >>> code into our dts files. >> >> Yep, this is the place where I got the reg info, to change from xx to >> 0xb to get the interface attached. But nevertheless, I do not see any >> packets coming from this board. The tftpboot works, the dhcp-server >> works too, tested with ppc netboot. But this board does not really >> send out DHCPREQUESTS to the DHCP server. >> >> But maybe I hunt in the wrong place, I have to compare the other >> entries. Right now I concentrated on the eth0/1 part. >> >> Thanks. >> Andreas >> > > Maybe you need to check pin multiplexer setup. If eth1 is not connected > to pins, there is no connectivity. Some time ago I did have just this > problem - no packets on the wire, but it looked like mge1 interface > works well... after I found multiplexed pin setup, all was clear to me. Hm, would you mind giving me a hands on? Where and what do I have to check? As said, new to the arm and fdt/dts world. TIA, Andreas From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 21:51:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BBBB556; Sun, 6 Apr 2014 21:51:11 +0000 (UTC) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D38A8FA9; Sun, 6 Apr 2014 21:51:10 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlab.sk with ESMTPA; Sun, 06 Apr 2014 23:51:12 +0200 id 0014206C.5341CC50.00013CA3 Date: Sun, 6 Apr 2014 23:51:07 +0200 From: Milan Obuch To: Andreas Tobler Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT Message-ID: <20140406235107.4445ec19@zeta.dino.sk> In-Reply-To: <5341C421.90209@fgznet.ch> References: <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> <53407B53.4040807@fgznet.ch> <1396737091.81853.339.camel@revolution.hippie.lan> <5341AE1C.4040207@fgznet.ch> <1396815052.81853.346.camel@revolution.hippie.lan> <5341BC93.6080105@fgznet.ch> <20140406230716.13113e35@zeta.dino.sk> <5341C421.90209@fgznet.ch> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; i386-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 21:51:11 -0000 On Sun, 06 Apr 2014 23:16:17 +0200 Andreas Tobler wrote: > On 06.04.14 23:07, Milan Obuch wrote: > > On Sun, 06 Apr 2014 22:44:03 +0200 > > Andreas Tobler wrote: > > > >> On 06.04.14 22:10, Ian Lepore wrote: > >>> On Sun, 2014-04-06 at 21:42 +0200, Andreas Tobler wrote: > >>>> On 06.04.14 00:31, Ian Lepore wrote: > >>>>> On Sat, 2014-04-05 at 23:53 +0200, Andreas Tobler wrote: > > > > [ snip ] > > > >>>>>> Sure, now I 'hang' in an other area. > >>>>>> > >>>>>> mge0: mem 0x72000-0x73fff > >>>>>> irq 12,13,14,11,46 on simplebus0 > >>>>>> mge0: Ethernet address: 00:d0:b8:1e:3b:df > >>>>>> mge0: attaching PHYs failed > >>>>>> --> hangs > >>>>>> According to the u-boot env I have two eth's and only the > >>>>>> second is wired and used. > >>>>>> > >>>>>> From u-boot: > >>>>>> Net: egiga0, egiga1 [PRIME] > >>>>>> > >>>>>> Now my questions, how do I enable verbose boot? On PowerPC I > >>>>>> know I have to do it in boot/loader.conf, here too? > >>>>>> > >>>>>> I guess my hardware is different from an eval board, so I > >>>>>> expect I'd need a customized dts, no? If so, how do I get the > >>>>>> information out of the u-boot? > >>>>>> Again, thx a lot! > >>>>>> Andreas > >>>>> > >>>>> You're probably not even using loader(8) but rather launching > >>>>> the kernel directly (only newer arm systems and newer versions > >>>>> of u-boot use loader). That means things like tunables and > >>>>> bootverbose have to be hacked into the kernel, at least for now > >>>>> to make some progress. The initarm_early_init() routine in > >>>>> arm/mv/mv_machdep.c is a good place to throw in a bootverbose=1. > >>>> > >>>> Ok. I did it in sys/kern/init_main.c > >>>> > >>>>> For disabling egiga0 just add status="disabled" to its entry in > >>>>> the dts file. Have a look at the dreamplug dts files for an > >>>>> example of setting up egiga1, but I'm not sure everything will > >>>>> be exactly the same. You may need to transplant the phy0 entry > >>>>> from egiga0 into egiga1 for that box. > >>>> > >>>> Good start, thanks. > >>>> > >>>>> The 'bdinfo' command in u-boot sometimes shows lots of good > >>>>> info, sometimes not so much. > >>>> > >>>> Hm, this command is not available in my env. > >>>> Anyway, I figured to play with the regs in the enet dts section > >>>> and I managed to get it up. Unfortunately I don't get any dhcp > >>>> requests to the server, so no ack can be given. I'll play around. > >>>> > >>>> Sending DHCP Discover packet from interface mge0 > >>>> (00:d0:b8:1e:3b:df) .... > >>>> DHCP/BOOTP timeout for server 255.255.255.255 > >>>> .... > >>>> > >>>> Thanks again! > >>>> Andreas > >>> > >>> I just realized that there's likely to be dts source for that box > >>> in linux, and sure enough: > >>> > >>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts > >>> > >>> There should be a lot of good clues in there, although we're not > >>> quite so compatible that you can necessarily just paste linux dts > >>> code into our dts files. > >> > >> Yep, this is the place where I got the reg info, to change from xx > >> to 0xb to get the interface attached. But nevertheless, I do not > >> see any packets coming from this board. The tftpboot works, the > >> dhcp-server works too, tested with ppc netboot. But this board > >> does not really send out DHCPREQUESTS to the DHCP server. > >> > >> But maybe I hunt in the wrong place, I have to compare the other > >> entries. Right now I concentrated on the eth0/1 part. > >> > >> Thanks. > >> Andreas > >> > > > > Maybe you need to check pin multiplexer setup. If eth1 is not > > connected to pins, there is no connectivity. Some time ago I did > > have just this problem - no packets on the wire, but it looked like > > mge1 interface works well... after I found multiplexed pin setup, > > all was clear to me. > > Hm, would you mind giving me a hands on? Where and what do I have to > check? > > As said, new to the arm and fdt/dts world. > > TIA, > Andreas > Look into archives for this mailing list, my older message date Wed, 27 Oct 2010 22:59:34 with subject 'Re: Guruplug Server Plus working to some extent... [mge1 problem SOLVED]' has my dts where I solved just MPP (multipurpose pin) setup problem, similar to yours I think. Look for block MPP: mpp@10000 in there dts, maybe it could give you a hint about setup of MPP for you. Regards, Milan From owner-freebsd-arm@FreeBSD.ORG Sun Apr 6 22:38:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA3CFB9E; Sun, 6 Apr 2014 22:38:26 +0000 (UTC) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id 663983ED; Sun, 6 Apr 2014 22:38:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N3M00E0O57INT50@mta.uoks.uj.edu.pl>; Sun, 06 Apr 2014 16:21:18 +0200 (CEST) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.2 X-Antivirus-Code: 0x100000 Received: from mbox.uj.edu.pl by saiph.uoks.uj.edu.pl (Dr.Web (R) milter module ver.6.0.2.2) ; Sun, 06 Apr 2014 16:21:18 +0200 Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl with ESMTP; Sun, 06 Apr 2014 16:21:18 +0200 (CEST) Date: Sun, 06 Apr 2014 16:21:18 +0200 From: Jakub Klama Message-id: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> Subject: [RFC] Refactored interrupt handling on ARM To: freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org User-Agent: Roundcube Webmail/0.5 X-Sender: jakub.klama@uj.edu.pl Cc: wkoszek@freebsd.org, cognet@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 22:38:26 -0000 Hello all, It has been a long time since my SoC 2012 ended. However, I've finally merged refactored interrupt handling framework to head and added SMP support (IPIs). Let's start: What is this and how does it work? It's a refactored interrupt handling code for ARM which supports multiple, stacked interrupt controllers. In particular, it creates a clean way to support IRQ multiplexers such as GPIO controllers with interrupt generation functionality. Approach used in this code is somewhat similar to one used in powerpc port. Every interrupt controller should implement methods from pic_if.m interface - at least pic_config, pic_unmask, pic_mask and pic_eoi. It should also install IRQ handler on parent interrupt controller (specified by interrupt-parent in FDT, defaulting to nexus). The root interrupt controller is nexus - on ARM it has exactly one IRQ line (typically nexus0:0) representing core IRQ signal (on MIPS, there will be probably five of them). SoC interrupt controller, such as GIC then installs handler on nexus0:0 IRQ and exposes itself as interrupt controller by calling arm_register_pic(). When the interrupt arrives, pic driver calls arm_dispatch_irq() function. So, for example, a typical SoC interrupt tree can look like that: nexus0 (provides 1 irq) | \-- gic0 (provides 160 irqs, uses irq nexus0:0) | \-- gpio0 (provides 8 irqs, uses irq gic0:42) | | | \-- mmcsd0 (uses irqs gpio0:1, gpio0:2) | \-- spi0 (uses irq gpio0:3) | ... \-- gpio1 (provides 8 irqs, uses irq gic0:43) \-- ehci0 (uses irq gic0:109) ... Interrupt numbers used in rman are composed of two 8-bit fields: higher 8 bits are the pic index and lower 8 bits are IRQ line number inside particular pic (so there are 256 pics supported with maximum of 256 irq lines on each). These numbers are generated using FDT_MAP_IRQ() macro called from FDT code. As you can see from the provided dmesg logs, irq numbers are printed in form of "pic_name:line_number", i.e: "nexus0:0" or "gic0:109". Of course there's still support for shared interrupt handlers - on LPC3250 there are 3 pics attached to one in-core IRQ line. There's also support for IPIs. Calls to pic_ipi_get(), pic_ipi_clear(), pic_ipi_send() and ..._init_secondary() are redirected to one interrupt controller registered as capable to do IPIs. There can be only one interrupt controller with IPI support registered (and certainly not the root one). Code was tested on following platforms: * EA3250 (arm/lpc) * Pandaboard (arm/ti) (both with SMP enabled and disabled) Merging it would not require any changes in existing ARM ports (unless they will be adopted to new framework and will have ARM_INTRNG option enabled), except for adding arm/arm/intr.c to their file lists (as it's now not compiled-in by default). That was tested too. dmesg outputs can be found there: * http://people.freebsd.org/~jceel/intrng/pandaboard.dmesg.txt * http://people.freebsd.org/~jceel/intrng/ea3250.dmesg.txt diff against head as of r264192: * http://people.freebsd.org/~jceel/intrng/intrng.diff git branch containing the changes: * https://github.com/jceel/freebsd-arm-intrng/tree/intrng What do you think about that? That code probably needs some improvements, especially in IPI/SMP area, but I think it's a step further in interrupt handling on ARM. I really appreciate any comments and opinions. Regards, Jakub From owner-freebsd-arm@FreeBSD.ORG Mon Apr 7 01:45:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7D9A33B for ; Mon, 7 Apr 2014 01:45:38 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7696875C for ; Mon, 7 Apr 2014 01:45:38 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id n16so5977531oag.31 for ; Sun, 06 Apr 2014 18:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ub9Cy7X/ZI/IION+VGXJnM1279dwKZLTy4ZJNXvaN8Y=; b=eoI2j16cHIzfY1hqnq51k3wdFRxqKpod2gk+g4rbHumGi+PpORxCgEmmDqfqC3jMuG ptYy3BP3fPmoKGgLcXP8wXz55+kOmyyxlaAFs982ZskV7xZ73CGiAJyw4awOJz9RQ6Le YJR6HvicyTCfpts8zM5JXL3CkBm2083IyyFMA6e+eqW4+LA2dL37ZHeTbOZZtXlDbqqP cSDMmoBHpWXpwPFJFsGSDUgGKj0z+Mx2e4tTkc8ik7DHYaehi8O8nA7kh/kJnzXJxQK/ pGsp9ibh/8wiqDLsb+qfD25ykCBzc2+4zocH0msCGbOqlUjdT+AgrO0foUnY977O3m+/ ASrw== MIME-Version: 1.0 X-Received: by 10.182.40.201 with SMTP id z9mr4598045obk.45.1396835137765; Sun, 06 Apr 2014 18:45:37 -0700 (PDT) Received: by 10.182.123.17 with HTTP; Sun, 6 Apr 2014 18:45:37 -0700 (PDT) Date: Sun, 6 Apr 2014 18:45:37 -0700 Message-ID: Subject: Pogoplug with Freebsd 10 or 11? From: jungleboogie0 To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 01:45:38 -0000 Hi All, In the interest in supporting FreeBSD ARM on all things, has anyone tried Freebsd stable or 11 current with one of the Pogoplugs? I found this undated article where it explains how to get FreeBSD 8.2-RELEASE-p1 installed but nothing newer: https://cooltrainer.org/freebsd-kirkwood/ At this point, it may not be much of interest since the Pogoplug has 256MB of RAM and most new ARM things are start at 512MB with 1 gig quickly becoming the new popular RAM amount. This article is only a couple months past the year mark: http://netzhansa.blogspot.com/2013/02/pogo-vpn.html I wonder if he's still using the same setup. Best, Jungle ------- inum: 883510009902611 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-arm@FreeBSD.ORG Mon Apr 7 02:52:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9989635 for ; Mon, 7 Apr 2014 02:52:42 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADE07C57 for ; Mon, 7 Apr 2014 02:52:42 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WWzfn-000Lyt-1L; Mon, 07 Apr 2014 02:52:35 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s372qWLe090871; Sun, 6 Apr 2014 20:52:33 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/yZmkI56bHANOKN2NqXpOv Subject: Re: Pogoplug with Freebsd 10 or 11? From: Ian Lepore To: jungleboogie0 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sun, 06 Apr 2014 20:52:32 -0600 Message-ID: <1396839152.81853.351.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 02:52:42 -0000 On Sun, 2014-04-06 at 18:45 -0700, jungleboogie0 wrote: > Hi All, > > In the interest in supporting FreeBSD ARM on all things, > has anyone tried Freebsd stable or 11 current with one of the > Pogoplugs? > > I found this undated article where it explains how to get > FreeBSD 8.2-RELEASE-p1 installed but nothing newer: > https://cooltrainer.org/freebsd-kirkwood/ > > At this point, it may not be much of interest since the > Pogoplug has 256MB of RAM and most new ARM things > are start at 512MB with 1 gig quickly becoming the new > popular RAM amount. > > This article is only a couple months past the year mark: > http://netzhansa.blogspot.com/2013/02/pogo-vpn.html > > I wonder if he's still using the same setup. > > Best, > Jungle Chances are you could get it running without too much effort, it'll be similar to Dreamplug and the other Kirkwood-based systems we support. There are nagging reports of serious problems with Kirkwood systems, especially when using USB, and nobody seems have the combo of time and skills to track down the cause. (I would mostly likely be that somebody, but time is my problem; I have to concentrate on ixm6 stuff for $work). -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Apr 7 06:01:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62787FC5 for ; Mon, 7 Apr 2014 06:01:49 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DEAC6D29 for ; Mon, 7 Apr 2014 06:01:48 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id z11so4295162lbi.36 for ; Sun, 06 Apr 2014 23:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=OjPYGjnP5cr3cf6fHmvsu1WZFgrimMzxe8fY4n8xP4k=; b=pzk1B6Pwo+jWva/oiefC1vvVqPBxTzsddnbFAHeJbhecDXEibz6S1ISODyWYP83fL9 XDikYAj8H7urNDudFtVGOyFhvEoby88c7gQlvNb9z7kj/Qyv5hC6TEFp/NQZAIh/3L1b Z0S7jmtZBwakp/ZpLtMOmFrIG7cL1MXQKlgVplpPljmvv+8LnZEiYDWRpS/yTyetNnk2 XoBTJclt8vzTMafxpz6lZhhqayl8AXhH7V4wbq8vrRS2eFJwgvGS1rHCKZS9wmD6cMD6 Y09xijgVjj/AU+AE7UYaJusxHVIk7h2qcCiz8PmcWNb1H+xQ+A1kWLbbTWfvgUkXW0Dd ABDg== X-Received: by 10.152.87.71 with SMTP id v7mr19882681laz.10.1396850506735; Sun, 06 Apr 2014 23:01:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.162.42 with HTTP; Sun, 6 Apr 2014 23:01:06 -0700 (PDT) In-Reply-To: <1396839152.81853.351.camel@revolution.hippie.lan> References: <1396839152.81853.351.camel@revolution.hippie.lan> From: Odhiambo Washington Date: Mon, 7 Apr 2014 09:01:06 +0300 Message-ID: Subject: Re: Pogoplug with Freebsd 10 or 11? To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 06:01:49 -0000 In the same breath, could someone please tell me if FreeBSD supports pcDuino-v3 ?? I am so tempted to get one for myself, just to be counted among those running on 'ARM' :-) On 7 April 2014 05:52, Ian Lepore wrote: > On Sun, 2014-04-06 at 18:45 -0700, jungleboogie0 wrote: > > Hi All, > > > > In the interest in supporting FreeBSD ARM on all things, > > has anyone tried Freebsd stable or 11 current with one of the > > Pogoplugs? > > > > I found this undated article where it explains how to get > > FreeBSD 8.2-RELEASE-p1 installed but nothing newer: > > https://cooltrainer.org/freebsd-kirkwood/ > > > > At this point, it may not be much of interest since the > > Pogoplug has 256MB of RAM and most new ARM things > > are start at 512MB with 1 gig quickly becoming the new > > popular RAM amount. > > > > This article is only a couple months past the year mark: > > http://netzhansa.blogspot.com/2013/02/pogo-vpn.html > > > > I wonder if he's still using the same setup. > > > > Best, > > Jungle > > Chances are you could get it running without too much effort, it'll be > similar to Dreamplug and the other Kirkwood-based systems we support. > There are nagging reports of serious problems with Kirkwood systems, > especially when using USB, and nobody seems have the combo of time and > skills to track down the cause. (I would mostly likely be that > somebody, but time is my problem; I have to concentrate on ixm6 stuff > for $work). > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 "I can't hear you -- I'm using the scrambler." From owner-freebsd-arm@FreeBSD.ORG Mon Apr 7 07:16:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2171FBD1; Mon, 7 Apr 2014 07:16:58 +0000 (UTC) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4C7FBC; Mon, 7 Apr 2014 07:16:57 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id md12so6355287pbc.9 for ; Mon, 07 Apr 2014 00:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=VsTH4rsEi5yN+t6lePzeX7tbagtHU1fBP87xIpN8X9U=; b=i/GtlD+yuYCWv8NOw2ChOfkJLIHGSOZ267oJEJcQVnqqTuuCsaPDVMNiW0UHrrsmhV /XPFxhx+NGrHouZ08OQGJArgjOlOWuqt5lQBn7omI4FUfb3nElRzrZz4pX8U7vPN2KpE 5oG0tf9s6qB/C/Nn5Z3iWfOKbCloSfm5oNPOcuViXyanPopwdme17lpJt/sTdT+/uh8k I5XU0h4aQEvMBUqYT86JUIETL3ueDoqnO6XO4LaJDNNv+5hQC2tLZrF6+pdWf2ZqZTyA K8MfCSB3Itn6joZTiFUBVS80FHKK3JVZv26HAF0+zHlIWH6Whg0ePljbV+dQxO0QZCW1 DPHQ== X-Received: by 10.68.194.97 with SMTP id hv1mr44733pbc.162.1396855017548; Mon, 07 Apr 2014 00:16:57 -0700 (PDT) Received: from [192.168.1.7] ([124.78.94.205]) by mx.google.com with ESMTPSA id it4sm34641281pbc.39.2014.04.07.00.16.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 00:16:56 -0700 (PDT) Message-ID: <534250BE.9030202@gmail.com> Date: Mon, 07 Apr 2014 15:16:14 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: u-boot@lists.denx.de, albert.u.boot@aribaud.net, trini@ti.com, vanbaren@cideas.com, kientzle@FreeBSD.org, freebsd-arm@freebsd.org Subject: Latest u-boot release on BeagleBone Black for FreeBSD 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 07:16:58 -0000 Hi u-boot community, I am trying to port u-boot (release u-boot-2014.04-rc3.tar.bz2) to FreeBSD on BeagleBone Black. In FreeBSD, there is a u-boot loader (named ubldr), which can call u-boot API to get fdt (Flat Device Tree) data. Example is: -- fdt header I have to comment out below 3 lines, in order to get correct fdt data in FreeBSD ubldr from u-boot. Would you please advice what is the best way to fix this? In file common/env_common.c: const uchar *env_get_addr(int index) { // if (gd->env_valid) // return (uchar *)(gd->env_addr + index); // else return &default_environment[index]; } -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Mon Apr 7 09:25:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C07906E6; Mon, 7 Apr 2014 09:25:46 +0000 (UTC) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94BB410B; Mon, 7 Apr 2014 09:25:46 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id uo5so6484976pbc.10 for ; Mon, 07 Apr 2014 02:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=CiD41e1r5fMBUtZhmtUBLf16WJ9/cU0ksxoLSv5WiP0=; b=E4jntkceCTe+LaMxS/jGRKJ1v/H8ERj3Sd5I/AL2U8afdCjOr/7cOKcyVIGTD/uip7 G5fRvvRTa5EgW8o0+8ni6n5sfjtb1K8JeRehbosq4HHPLrWw5WggEgOMV02a8nXI9tBV HiMqKJERqqBSrk2Rbt8vF8kungRVAKYqfAkMo+tPSEnnht9A4RYmeaMsZhQdvcluj/GE Id8xKpsUngAlZ1e2Abx5m9IO45xF2sl0c02CnyqCOGqg2hpCvWV2sfPc3KRgRBK8fwIC nK3ziI0+i+ophruDkoyxrzYQlWMPj3vIquaACQZewDfgQw2Q7JUEoyfF4ern4GvNSSJ8 sMQw== X-Received: by 10.68.113.194 with SMTP id ja2mr30028751pbb.30.1396862746252; Mon, 07 Apr 2014 02:25:46 -0700 (PDT) Received: from localhost.localdomain ([216.131.71.149]) by mx.google.com with ESMTPSA id vx10sm83226003pac.17.2014.04.07.02.25.43 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 02:25:45 -0700 (PDT) From: Xuebing Wang To: freebsd-arm@freebsd.org, kientzle@FreeBSD.org Subject: [BeagleBone Black Test PATCH 0/2] port latest u-boot Date: Mon, 7 Apr 2014 17:25:30 +0800 Message-Id: <1396862732-4961-1-git-send-email-xbing6@gmail.com> X-Mailer: git-send-email 1.7.9.5 Cc: xbing6@gmail.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 09:25:46 -0000 Hi Tim and all, This is for discussion only. Would you please advice? This is motivated by trying to increase CPU frequency for BeagleBone Black. AM335x cpufreq is not supported yet. In order to achieve the goal to increase CPU freq, I am thinking of a 2-step approach: 1) port latest u-boot, which have cpufreq better organized 2) tweak u-boot opp/freq later With this 2 patches, I can boot into FreeBSD on my BeagleBone Black (BBB), but my BBB consistently reboots every 50 seconds after ubldr boots kernel. It looks like that a watchdog is not cleared, any idea on this? Xuebing Wang (2): BeagleBone Black: port latest u-boot (u-boot-2014.04-rc3.tar.bz2) BeagleBone Black: in u-boot, force to use default_environment[index] common/env_common.c | 6 +++--- include/configs/am335x_evm.h | 32 +++++++++++++++++++------------- include/configs/ti_armv7_common.h | 2 +- 3 files changed, 23 insertions(+), 17 deletions(-) -- 1.9.0 From owner-freebsd-arm@FreeBSD.ORG Mon Apr 7 09:25:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDA5C6E8; Mon, 7 Apr 2014 09:25:49 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9ED9A10C; Mon, 7 Apr 2014 09:25:49 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id p10so6289411pdj.12 for ; Mon, 07 Apr 2014 02:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=Pz3f4uAu1E+pfE6uyAd/sOWwwiTXfzTSYvX4Ihfav+c=; b=GNv8Xqjx0CvPf0BHy0bFu9XyBZtyFcvAFEwpACRBK2W3X9OsFs1571qrixH7adLjWo 3E2Os+Vjl5AGmJ0cNpcz6VC+DI0qkVT7lBheLU6jFoehskhkcWZ0K/1+xBDCbSo3pt3x LFUebU/SgeSUdMarTbwADTr7hdjvXW7cCjC0CJ8s4lNMFcN5qgiUrdm0o6g766GY1Y9w jXXEmvPzPIzKc6lJum1/Ozlb+IdTBg6NbPo3CuGhErcQUvAhx8/+2ZRW5CZmz+F4SJcK Xnm/ERSX8P3hdEjjj8YF1PQiEIvq87JmouaeedCLz9BOaqQfiS9amw8XeTgQH7yW7PbD LgOQ== X-Received: by 10.68.215.40 with SMTP id of8mr29649372pbc.15.1396862749271; Mon, 07 Apr 2014 02:25:49 -0700 (PDT) Received: from localhost.localdomain ([216.131.71.149]) by mx.google.com with ESMTPSA id vx10sm83226003pac.17.2014.04.07.02.25.46 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 02:25:48 -0700 (PDT) From: Xuebing Wang To: freebsd-arm@freebsd.org, kientzle@FreeBSD.org Subject: [BeagleBone Black Test PATCH 1/2] BeagleBone Black: port latest u-boot (u-boot-2014.04-rc3.tar.bz2) Date: Mon, 7 Apr 2014 17:25:31 +0800 Message-Id: <1396862732-4961-2-git-send-email-xbing6@gmail.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1396862732-4961-1-git-send-email-xbing6@gmail.com> References: <1396862732-4961-1-git-send-email-xbing6@gmail.com> Cc: xbing6@gmail.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 09:25:49 -0000 Procedure to build: 1) gmake CROSS_COMPILE=arm-eabi- am335x_boneblack_config 2) gmake CROSS_COMPILE=arm-eabi- (can add -j4 to make build faster) Known issues: 1) On 11-current, FreeBSD reboots every 50 seconds after ubldr boots kernel. This is reproducible. 2) In u-boot, type command "usb start" command shows: U-Boot# usb start (Re)start USB... USB0: lowlevel init failed USB error: all controllers failed lowlevel init --- include/configs/am335x_evm.h | 32 +++++++++++++++++++------------- include/configs/ti_armv7_common.h | 2 +- 2 files changed, 20 insertions(+), 14 deletions(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 884a42b..3755ac0 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -18,6 +18,12 @@ #include +#ifndef CONFIG_SPL_BUILD +#define CONFIG_CMD_ELF +#define CONFIG_API +#define CONFIG_SYS_MMC_MAX_DEVICE 2 +#endif + #define MACH_TYPE_TIAM335EVM 3589 /* Until the next sync */ #define CONFIG_MACH_TYPE MACH_TYPE_TIAM335EVM #define CONFIG_BOARD_LATE_INIT @@ -61,14 +67,14 @@ #ifndef CONFIG_SPL_BUILD #define CONFIG_EXTRA_ENV_SETTINGS \ - "loadaddr=0x80200000\0" \ - "fdtaddr=0x80F80000\0" \ + "loadaddr=0x88000000\0" \ + "fdtaddr=0x80000100\0" \ + "bootfile=bbubldr\0" \ "fdt_high=0xffffffff\0" \ "boot_fdt=try\0" \ "rdaddr=0x81000000\0" \ "bootpart=0:2\0" \ "bootdir=/boot\0" \ - "bootfile=zImage\0" \ "fdtfile=undefined\0" \ "console=ttyO0,115200n8\0" \ "partitions=" \ @@ -102,8 +108,8 @@ "root=/dev/nfs " \ "nfsroot=${serverip}:${rootpath},${nfsopts} rw " \ "ip=dhcp\0" \ - "bootenv=uEnv.txt\0" \ - "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ + "bootenv=bb-uEnv.txt\0" \ + "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ "importbootenv=echo Importing environment from mmc ...; " \ "env import -t $loadaddr $filesize\0" \ "ramargs=setenv bootargs console=${console} " \ @@ -111,21 +117,21 @@ "root=${ramroot} " \ "rootfstype=${ramrootfstype}\0" \ "loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \ - "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \ - "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \ - "mmcloados=run mmcargs; " \ + "loadimage=fatload mmc ${mmcdev} ${loadaddr} ${bootfile}\0" \ + "loadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile};fdt addr ${fdtaddr}\0" \ + "mmcloados=" \ "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ "if run loadfdt; then " \ - "bootz ${loadaddr} - ${fdtaddr}; " \ + "bootelf ${loadaddr};" \ "else " \ "if test ${boot_fdt} = try; then " \ - "bootz; " \ + "bootelf ${loadaddr};" \ "else " \ "echo WARN: Cannot load the DT; " \ "fi; " \ "fi; " \ "else " \ - "bootz; " \ + "bootelf ${loadaddr};" \ "fi;\0" \ "mmcboot=mmc dev ${mmcdev}; " \ "if mmc rescan; then " \ @@ -159,9 +165,9 @@ "bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \ "findfdt="\ "if test $board_name = A335BONE; then " \ - "setenv fdtfile am335x-bone.dtb; fi; " \ + "setenv fdtfile bbone.dtb; fi; " \ "if test $board_name = A335BNLT; then " \ - "setenv fdtfile am335x-boneblack.dtb; fi; " \ + "setenv fdtfile bboneblk.dtb; fi; " \ "if test $board_name = A33515BB; then " \ "setenv fdtfile am335x-evm.dtb; fi; " \ "if test $board_name = A335X_SK; then " \ diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 69d69a5..3f0be68 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -201,7 +201,7 @@ /* FAT sd card locations. */ #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1 -#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img" +#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "bb-uboot.img" #ifdef CONFIG_SPL_OS_BOOT #define CONFIG_SYS_SPL_ARGS_ADDR 0x80F80000 -- 1.9.0 From owner-freebsd-arm@FreeBSD.ORG Mon Apr 7 09:25:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C92A746; Mon, 7 Apr 2014 09:25:52 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F41910E; Mon, 7 Apr 2014 09:25:52 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id r10so6268807pdi.16 for ; Mon, 07 Apr 2014 02:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=048RJhdgkA5CoOnvGBXGoMy0wgd9dxwh6NxbR5uDows=; b=ztzK376wT/rXwXM9TAVNLQcFlOB5It5X9O2pVFmAuQ+yD7byh0kHptoJkO6sM99a0D RNRgA/dlHeyt8RLkQWzIGxzB5TSTWie7zeoqv7w+r+rQ9Kq0uybYBJmW5AsS2ymwQIUb xBfcIC3RBuBLtaJ1iWl1jIQWCJT5MbJq2YzE9lHRiydBYU4UEBrgvmEhF3s39RbQXkdU MnqU1vcmdd0BfwnBT+PXb87e0OFwVx7G4r/euGb6fxuS2ggcb4uTj/xv7DEeulsQKgRa LlS6rdrhz/QAUKjc4m8Q2y2mRAf8gxA9XCrUUwmMkSLkcyp14aatN0B98aJVUL8gRRDL ru9g== X-Received: by 10.68.133.163 with SMTP id pd3mr541163pbb.166.1396862752115; Mon, 07 Apr 2014 02:25:52 -0700 (PDT) Received: from localhost.localdomain ([216.131.71.149]) by mx.google.com with ESMTPSA id vx10sm83226003pac.17.2014.04.07.02.25.49 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 02:25:51 -0700 (PDT) From: Xuebing Wang To: freebsd-arm@freebsd.org, kientzle@FreeBSD.org Subject: [BeagleBone Black Test PATCH 2/2] BeagleBone Black: in u-boot, force to use default_environment[index] Date: Mon, 7 Apr 2014 17:25:32 +0800 Message-Id: <1396862732-4961-3-git-send-email-xbing6@gmail.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1396862732-4961-1-git-send-email-xbing6@gmail.com> References: <1396862732-4961-1-git-send-email-xbing6@gmail.com> Cc: xbing6@gmail.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 09:25:52 -0000 Without this patch, ubldr can NOT get fdt (Flat Device Tree) by calling u-boot API, thus can not boot FreeBSD kernel. TODO: This is a test patch, needs to find a better way. --- common/env_common.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/common/env_common.c b/common/env_common.c index c0bfc2f..2fd399f 100644 --- a/common/env_common.c +++ b/common/env_common.c @@ -59,9 +59,9 @@ uchar env_get_char(int index) const uchar *env_get_addr(int index) { - if (gd->env_valid) - return (uchar *)(gd->env_addr + index); - else +// if (gd->env_valid) +// return (uchar *)(gd->env_addr + index); +// else return &default_environment[index]; } -- 1.9.0 From owner-freebsd-arm@FreeBSD.ORG Mon Apr 7 11:06:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 169D59D7 for ; Mon, 7 Apr 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE9C6BE5 for ; Mon, 7 Apr 2014 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s37B6eES070985 for ; Mon, 7 Apr 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s37B6e04070983 for freebsd-arm@FreeBSD.org; Mon, 7 Apr 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Apr 2014 11:06:40 GMT Message-Id: <201404071106.s37B6e04070983@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 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/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o ports/175605 arm devel/binutils: please fix build binutils-2.23.1 in ra 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 ports/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) 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 32 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Apr 7 17:02:22 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F20D867; Mon, 7 Apr 2014 17:02:22 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D22219A8; Mon, 7 Apr 2014 17:02:21 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s37H2CVK046062; Mon, 7 Apr 2014 19:02:16 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <5342DA14.2040100@fgznet.ch> Date: Mon, 07 Apr 2014 19:02:12 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Milan Obuch Subject: Re: MARVELL BOARD: RD-88F6281A -CURRENT References: <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> <53407B53.4040807@fgznet.ch> <1396737091.81853.339.camel@revolution.hippie.lan> <5341AE1C.4040207@fgznet.ch> <1396815052.81853.346.camel@revolution.hippie.lan> <5341BC93.6080105@fgznet.ch> <20140406230716.13113e35@zeta.dino.sk> <5341C421.90209@fgznet.ch> <20140406235107.4445ec19@zeta.dino.sk> In-Reply-To: <20140406235107.4445ec19@zeta.dino.sk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:02:22 -0000 On 06.04.14 23:51, Milan Obuch wrote: > On Sun, 06 Apr 2014 23:16:17 +0200 > Andreas Tobler wrote: > >> On 06.04.14 23:07, Milan Obuch wrote: >>> On Sun, 06 Apr 2014 22:44:03 +0200 >>> Andreas Tobler wrote: >>> >>>> On 06.04.14 22:10, Ian Lepore wrote: >>>>> On Sun, 2014-04-06 at 21:42 +0200, Andreas Tobler wrote: >>>>>> On 06.04.14 00:31, Ian Lepore wrote: >>>>>>> On Sat, 2014-04-05 at 23:53 +0200, Andreas Tobler wrote: >>> >>> [ snip ] >>> >>>>>>>> Sure, now I 'hang' in an other area. >>>>>>>> >>>>>>>> mge0: mem 0x72000-0x73fff >>>>>>>> irq 12,13,14,11,46 on simplebus0 >>>>>>>> mge0: Ethernet address: 00:d0:b8:1e:3b:df >>>>>>>> mge0: attaching PHYs failed >>>>>>>> --> hangs >>>>>>>> According to the u-boot env I have two eth's and only the >>>>>>>> second is wired and used. >>>>>>>> >>>>>>>> From u-boot: >>>>>>>> Net: egiga0, egiga1 [PRIME] >>>>>>>> >>>>>>>> Now my questions, how do I enable verbose boot? On PowerPC I >>>>>>>> know I have to do it in boot/loader.conf, here too? >>>>>>>> >>>>>>>> I guess my hardware is different from an eval board, so I >>>>>>>> expect I'd need a customized dts, no? If so, how do I get the >>>>>>>> information out of the u-boot? >>>>>>>> Again, thx a lot! >>>>>>>> Andreas >>>>>>> >>>>>>> You're probably not even using loader(8) but rather launching >>>>>>> the kernel directly (only newer arm systems and newer versions >>>>>>> of u-boot use loader). That means things like tunables and >>>>>>> bootverbose have to be hacked into the kernel, at least for now >>>>>>> to make some progress. The initarm_early_init() routine in >>>>>>> arm/mv/mv_machdep.c is a good place to throw in a bootverbose=1. >>>>>> >>>>>> Ok. I did it in sys/kern/init_main.c >>>>>> >>>>>>> For disabling egiga0 just add status="disabled" to its entry in >>>>>>> the dts file. Have a look at the dreamplug dts files for an >>>>>>> example of setting up egiga1, but I'm not sure everything will >>>>>>> be exactly the same. You may need to transplant the phy0 entry >>>>>>> from egiga0 into egiga1 for that box. >>>>>> >>>>>> Good start, thanks. >>>>>> >>>>>>> The 'bdinfo' command in u-boot sometimes shows lots of good >>>>>>> info, sometimes not so much. >>>>>> >>>>>> Hm, this command is not available in my env. >>>>>> Anyway, I figured to play with the regs in the enet dts section >>>>>> and I managed to get it up. Unfortunately I don't get any dhcp >>>>>> requests to the server, so no ack can be given. I'll play around. >>>>>> >>>>>> Sending DHCP Discover packet from interface mge0 >>>>>> (00:d0:b8:1e:3b:df) .... >>>>>> DHCP/BOOTP timeout for server 255.255.255.255 >>>>>> .... >>>>>> >>>>>> Thanks again! >>>>>> Andreas >>>>> >>>>> I just realized that there's likely to be dts source for that box >>>>> in linux, and sure enough: >>>>> >>>>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts >>>>> >>>>> There should be a lot of good clues in there, although we're not >>>>> quite so compatible that you can necessarily just paste linux dts >>>>> code into our dts files. >>>> >>>> Yep, this is the place where I got the reg info, to change from xx >>>> to 0xb to get the interface attached. But nevertheless, I do not >>>> see any packets coming from this board. The tftpboot works, the >>>> dhcp-server works too, tested with ppc netboot. But this board >>>> does not really send out DHCPREQUESTS to the DHCP server. >>>> >>>> But maybe I hunt in the wrong place, I have to compare the other >>>> entries. Right now I concentrated on the eth0/1 part. >>>> >>>> Thanks. >>>> Andreas >>>> >>> >>> Maybe you need to check pin multiplexer setup. If eth1 is not >>> connected to pins, there is no connectivity. Some time ago I did >>> have just this problem - no packets on the wire, but it looked like >>> mge1 interface works well... after I found multiplexed pin setup, >>> all was clear to me. >> >> Hm, would you mind giving me a hands on? Where and what do I have to >> check? >> >> As said, new to the arm and fdt/dts world. >> >> TIA, >> Andreas >> > > Look into archives for this mailing list, my older message date Wed, 27 > Oct 2010 22:59:34 with subject 'Re: Guruplug Server Plus working to some > extent... [mge1 problem SOLVED]' has my dts where I solved just MPP > (multipurpose pin) setup problem, similar to yours I think. Look for > block MPP: mpp@10000 in there dts, maybe it could give you a hint about > setup of MPP for you. Thank you Milan!!!! The data sheet helped a lot. But in the end I was so lazy and I took the DREAMPLUG-1001 combo where I adjusted the PHY reg and the Memory size. Now I have booted into multiuser. Great! .... FreeBSD 11.0-CURRENT #7 r264151:264189M: Mon Apr 7 18:49:48 CEST 2014 andreast@tcx58.andreas.nets:/usr/obj/arm.arm/export/devel/fbsd/src/sys/DREAMPLUG-1001 arm FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 WARNING: DIAGNOSTIC option enabled, expect reduced performance. Preloaded elf kernel "kernel" at 0xc0ee782c. CPU: Feroceon 881 rev 1 (Marvell core) Little-endian DC enabled IC enabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 268431360 (255 MB) avail memory = 2542837742 MB) .... Thanks to all. Andreas From owner-freebsd-arm@FreeBSD.ORG Tue Apr 8 01:41:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 573C0692 for ; Tue, 8 Apr 2014 01:41:26 +0000 (UTC) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AF601034 for ; Tue, 8 Apr 2014 01:41:25 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id lj1so280865pab.34 for ; Mon, 07 Apr 2014 18:41:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=dquYMmjlksJjN3Um0UNjCjGkTyNhCnU6bGmSJGzx5Hs=; b=abM4mCCXOiCs99rGLrnxJKLzLvJFK7kGo+l42/9GunuVod5knafJymQaO/fpsug6vX YFX3OrL5SrMSsiZfPCSOSqWClxTx+uPCm9g03eMO8TSm1jt8dVF4maLZ87KuhHCUkCzy QtiYv0qHPMg1p7nK2cW9iMT/rUWA/AJFiazwf2zNI1RJIOesyYd8dPEpB6POcVH1PImE IQrWHJqEfR2qvvhn8Lre7tMWAy18GiUSYC5KCQln6taqfmq8fgc6rBufW95bmWLiJsHW mxUIE5wRkrfqJpVFmrSwQwl1puBscBwUYzwwO+x+Ui74hr5elbvMjtKPW0h0UHRUTcKB sMeA== X-Gm-Message-State: ALoCoQmIr1QR++11x2YsbH5/+tbPvQD/M6elXWOCcYkeoMU3fJskI3UXdWS78m/fEGKKAd0j6Act X-Received: by 10.66.141.12 with SMTP id rk12mr931777pab.152.1396921279249; Mon, 07 Apr 2014 18:41:19 -0700 (PDT) Received: from [192.168.1.3] (c-50-156-22-189.hsd1.ca.comcast.net. [50.156.22.189]) by mx.google.com with ESMTPSA id j3sm790366pbh.38.2014.04.07.18.41.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 18:41:18 -0700 (PDT) Sender: Tim Kientzle Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [BeagleBone Black Test PATCH 0/2] port latest u-boot From: Tim Kientzle In-Reply-To: <1396862732-4961-1-git-send-email-xbing6@gmail.com> Date: Mon, 7 Apr 2014 18:41:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1396862732-4961-1-git-send-email-xbing6@gmail.com> To: Xuebing Wang X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 01:41:26 -0000 On Apr 7, 2014, at 2:25 AM, Xuebing Wang wrote: > Hi Tim and all, >=20 > This is for discussion only. Would you please advice? >=20 > This is motivated by trying to increase CPU frequency for BeagleBone = Black. >=20 > AM335x cpufreq is not supported yet. In order to achieve the goal to = increase > CPU freq, I am thinking of a 2-step approach: > 1) port latest u-boot, which have cpufreq better organized > 2) tweak u-boot opp/freq later Setting the processor frequency after the OS is running is not difficult. The AM335x TRM shows exactly how to do it. I would not change U-Boot but rather implement a FreeBSD driver that exposed a read/write sysctl to reprogram the CPU frequency. Getting powerd to work with this should be straightforward. Tim From owner-freebsd-arm@FreeBSD.ORG Tue Apr 8 02:02:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B206AD1; Tue, 8 Apr 2014 02:02:23 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AB3211EA; Tue, 8 Apr 2014 02:02:23 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id v10so295460pde.15 for ; Mon, 07 Apr 2014 19:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yi1qTLMd/E3c4NKijdqoNQyzQfu2m84bhx7wi1gG6LA=; b=sj+xK36cwfS3UZGq1zfwqyjvp2duQxPs6wM0tkalV2BLN3F79TQ1RUj2V2wCO8Uq2P UcP9JU5Zgn3v6ee40WL1VWMVA8pBqGpARUKqiB09+qodVsgkmrinpEPRG/EaIC56grsQ Kv/N6uHOqAzR79iWvz4q7gX7w53r4YsBrZoAJ+h7G5AabYQ7Tpjcr8s1iNKTIrTQ8jch 5SyotCM03/9dpybF0mtdrrcDjCHOQK83w9m9SIumAUVcRawlsm55G/zwW99sNRcVuvIK ESj5GHpjDDKOhjISvt7G4f2AR7fHnoPtAtQFXWLKMWAX0N8Nrm5kh5lyW9KjKAwM7HB7 NJfg== X-Received: by 10.68.132.68 with SMTP id os4mr927279pbb.129.1396922541519; Mon, 07 Apr 2014 19:02:21 -0700 (PDT) Received: from [192.168.1.8] ([124.78.94.205]) by mx.google.com with ESMTPSA id hr5sm2506320pac.18.2014.04.07.19.02.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 19:02:20 -0700 (PDT) Message-ID: <534358A7.90906@gmail.com> Date: Tue, 08 Apr 2014 10:02:15 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: [BeagleBone Black Test PATCH 0/2] port latest u-boot References: <1396862732-4961-1-git-send-email-xbing6@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 02:02:23 -0000 Thanks Tim. Do you see a need to port the latest u-boot, with AM33xx code better organized? As you can see, the way to configure is even changed from am335x_evm_config to am335x_boneblack_config. Does the current BeagleBone Black FreeBSD u-boot support below? a) Boot ubldr, kernel and whole system from NFS b) Boot ubldr, kernel ... from Ethernet over USB Thanks. On 04/08/2014 09:41 AM, Tim Kientzle wrote: > On Apr 7, 2014, at 2:25 AM, Xuebing Wang wrote: > >> Hi Tim and all, >> >> This is for discussion only. Would you please advice? >> >> This is motivated by trying to increase CPU frequency for BeagleBone Black. >> >> AM335x cpufreq is not supported yet. In order to achieve the goal to increase >> CPU freq, I am thinking of a 2-step approach: >> 1) port latest u-boot, which have cpufreq better organized >> 2) tweak u-boot opp/freq later > Setting the processor frequency after the OS is running > is not difficult. The AM335x TRM shows exactly how to do it. > > I would not change U-Boot but rather implement > a FreeBSD driver that exposed a read/write sysctl > to reprogram the CPU frequency. > > Getting powerd to work with this should be straightforward. > > Tim > > -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Tue Apr 8 03:42:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FB95397; Tue, 8 Apr 2014 03:42:23 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 352781B4F; Tue, 8 Apr 2014 03:42:23 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id D9B1939865; Mon, 7 Apr 2014 20:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1396928542; bh=ddcfmcN7mbIvvtpAdm3rVkEUmME431lLOWhIIO8g1UE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=aIKKiOgQossrTBeptjhwWWba98ausNUpoxvKWGAPQIgm/EZmufO6vnSbiz0KitMW3 4kRwwjVBFJzdhqzK6KNkvTVL3lHVlAX6dJIxfOtJUKPUOhmZEB2sX5gwZlsDVt8yQh tYlaqvQI5C8OV33A0ZMduNiMWEsEl+WaBgeoQZdM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [BeagleBone Black Test PATCH 0/2] port latest u-boot From: Rui Paulo In-Reply-To: <534358A7.90906@gmail.com> Date: Mon, 7 Apr 2014 20:42:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1396862732-4961-1-git-send-email-xbing6@gmail.com> <534358A7.90906@gmail.com> To: Xuebing Wang X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 03:42:23 -0000 On Apr 7, 2014, at 19:02, Xuebing Wang wrote: > Thanks Tim. >=20 > Do you see a need to port the latest u-boot, with AM33xx code better = organized? >=20 > As you can see, the way to configure is even changed from = am335x_evm_config to am335x_boneblack_config. >=20 > Does the current BeagleBone Black FreeBSD u-boot support below? > a) Boot ubldr, kernel and whole system from NFS It supports booting ubldr from TFTP and the rest from NFS, at least. =20 > b) Boot ubldr, kernel ... from Ethernet over USB No, but that doesn't seem very important since it already has an = ethernet port. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Tue Apr 8 06:50:07 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5677219B for ; Tue, 8 Apr 2014 06:50:07 +0000 (UTC) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C8C41A55 for ; Tue, 8 Apr 2014 06:50:06 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1WXPrA-001FqM-H3; Tue, 08 Apr 2014 08:50:04 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Ralf Wenk To: Andrew Turner Subject: Experimental TARGET_ARCH armv6hf - missing fpsetmask? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Apr 2014 08:50:02 +0200 Message-Id: Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 06:50:07 -0000 Hello Andrew, I just wanted to let you know that compiling perl 5.16 on a r264192 armv6hf kernel and world fails early because of missing the/a fpsetmask function. Same release with armv6 kernel and world compiles successfully. These are the lines where fpsetmask is mentioned during the compilation: `sh cflags "optimize='-O -pipe'" perlmini.o` -DPIC -fPIC -DPERL_IS_MINIPERL -DPERL_EXTERNAL_GLOB perlmini.c CCCMD = cc -DPERL_CORE -c -DAPPLLIB_EXP="/usr/local/lib/perl5/5.16/B SDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -O -pipe -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings perl.c:134:5: warning: implicit declaration of function 'fpsetmask' is invalid in C99 [-Wimplicit-function-declaration] PERL_SYS_INIT_BODY(argc, argv); ^ ./unixish.h:131:29: note: expanded from macro 'PERL_SYS_INIT_BODY' MALLOC_CHECK_TAINT2(*c,*v) PERL_FPU_INIT; PERLIO_INIT; MALLOC_INIT ^ ./perl.h:2706:33: note: expanded from macro 'PERL_FPU_INIT' # define PERL_FPU_INIT (void)fpsetmask(0) ^ 1 warning generated. And these are the lines where the linker failed: LD_LIBRARY_PATH=/usr/ports/lang/perl5.16/work/perl-5.16.3 cc -pthread -Wl,-E -fstack-protector -L/usr/local/lib -o miniperl perlmini.o opmini.o miniperlmain.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o -lm -lcrypt -lutil perlmini.o: In function `Perl_sys_init': perlmini.c:(.text+0xc): undefined reference to `fpsetmask' perlmini.o: In function `Perl_sys_init3': perlmini.c:(.text+0x20): undefined reference to `fpsetmask' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [miniperl] Error code 1 (ignored) LD_LIBRARY_PATH=/usr/ports/lang/perl5.16/work/perl-5.16.3 ./miniperl -Ilib make_patchnum.pl ./miniperl: not found Kind regards, Ralf From owner-freebsd-arm@FreeBSD.ORG Tue Apr 8 09:19:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C0CF185 for ; Tue, 8 Apr 2014 09:19:24 +0000 (UTC) Received: from iwiw03d.mail.t-online.hu (iwiw03d.mail.t-online.hu [84.2.42.68]) by mx1.freebsd.org (Postfix) with ESMTP id F234F18BA for ; Tue, 8 Apr 2014 09:19:23 +0000 (UTC) Received: from fmx25.freemail.hu (fmx25.freemail.hu [195.228.245.75]) by iwiw03d.mail.t-online.hu (Postfix) with SMTP id AAFEB4E8177 for ; Tue, 8 Apr 2014 11:19:15 +0200 (CEST) Received: (qmail 74096 invoked by uid 151); 8 Apr 2014 11:19:15 +0200 Received: from 195.228.245.211 (HELO xmldata09.freemail.private) (80.98.117.10) by fmx25.freemail.hu with SMTP; 8 Apr 2014 11:19:15 +0200 Received: from webmail by smtp gw id s389JFhv040752; Tue, 8 Apr 2014 11:19:15 +0200 (CEST) Date: Tue, 8 Apr 2014 11:19:15 +0200 (CEST) From: Kover Attila Subject: Re: Experimental TARGET_ARCH armv6hf - missing fpsetmask? To: freebsd-arm@freebsd.org Message-ID: X-Originating-IP: [80.98.117.10] X-HTTP-User-Agent: Unknown X-Original-User: koverat MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 09:19:24 -0000 Hi, > I just wanted to let you know that compiling perl 5.16 on a r264192 > armv6hf kernel and world fails early because of missing the/a fpsetmask > function. Same release with armv6 kernel and world compiles successfully. I was get the same problem not only with perl 5.16 but with 5.18 too, but I was found a temporary workaround: I was edited perl.h and commented out the lines which responsible for the fpsetmask definition (see below the diff), so basically it is like '#ifdef HAS_FPSETMASK' false and the '#else' block will "run" in compile time. Best Regards Attila [root@freepi ~]# uname -ap FreeBSD freepi 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r264192M: Sun Apr 6 19:40:52 CEST 2014 root@dlc:/root/ujra/svnhead/obj/arm.armv6hf/root/ujra/svnhead/head/sys/RPI-B-DRS arm armv6hf [root@freepi ~]# perl --version This is perl 5, version 18, subversion 2 (v5.18.2) built for arm-freebsd-thread-multi-64int Copyright 1987-2013, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. [root@freepi ~]# [root@freepi /usr/ports/lang/perl5.18/work/perl-5.18.2 ]# diff perl.h perl-armv6hf.h 2730,2733c2730,2733 < # ifdef HAS_FPSETMASK < # if HAS_FLOATINGPOINT_H < # include < # endif --- > // # ifdef HAS_FPSETMASK > // # if HAS_FLOATINGPOINT_H > // # include > // # endif 2738,2739c2738,2739 < # define PERL_FPU_INIT (void)fpsetmask(0) < # else --- > // # define PERL_FPU_INIT (void)fpsetmask(0) > // # else 2749c2749 < # endif --- > // # endif From owner-freebsd-arm@FreeBSD.ORG Tue Apr 8 13:00:48 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B1C96D8; Tue, 8 Apr 2014 13:00:48 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3EFEA1DFD; Tue, 8 Apr 2014 13:00:47 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WXVdp-000Nff-74; Tue, 08 Apr 2014 13:00:41 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s38D0b1M092683; Tue, 8 Apr 2014 07:00:37 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/M1swt0q5HUZywrs83oqPh Subject: Re: Latest u-boot release on BeagleBone Black for FreeBSD From: Ian Lepore To: Xuebing Wang In-Reply-To: <534250BE.9030202@gmail.com> References: <534250BE.9030202@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 Apr 2014 07:00:37 -0600 Message-ID: <1396962037.81853.405.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: albert.u.boot@aribaud.net, freebsd-arm@FreeBSD.org, u-boot@lists.denx.de, vanbaren@cideas.com, trini@ti.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 13:00:48 -0000 On Mon, 2014-04-07 at 15:16 +0800, Xuebing Wang wrote: > Hi u-boot community, > > I am trying to port u-boot (release u-boot-2014.04-rc3.tar.bz2) to > FreeBSD on BeagleBone Black. > > In FreeBSD, there is a u-boot loader (named ubldr), which can call > u-boot API to get fdt (Flat Device Tree) data. Example is: > -- fdt header > > I have to comment out below 3 lines, in order to get correct fdt data in > FreeBSD ubldr from u-boot. Would you please advice what is the best way > to fix this? > > In file common/env_common.c: > const uchar *env_get_addr(int index) > { > // if (gd->env_valid) > // return (uchar *)(gd->env_addr + index); > // else > return &default_environment[index]; > } > Are you using a fairly recent ubldr on the freebsd side? I made some changes around March 1st on how ubldr finds / loads fdt data... It first looks for env vars named fdtaddr then fdt_addr in the u-boot environment. If the variable exists it tries to validate the data at that address as a valid dtb header and if it is, that's the data that is passed to the kernel. Otherwise it next it looks for env vars named fdtfile then fdt_file. If one of those exists it tries to load that filename from the freebsd filesystem in the usual places where kernel and modules are located (/boot/kernel, /boot/modules). It seems strange to me that things work only if you comment out the dynamic environment in u-boot. You said "in order to get the correct fdt data" and I wonder what you mean by that. Do you mean that the u-boot script stuff is loading fdt data, but it's not the freebsd data but rather the linux data? Unfortunately, freebsd isn't able to use linux or vendor-supplied dtb files yet. We're working towards using only documented bindings but right now we still need freebsd-specific extra properties in the dtb. I added the support for fdtfile/fdt_file specifically to handle this situation until we're able to handle the vendor dtb files. If you manipulate your u-boot environment so that fdtaddr and fdt_addr are unset and fdtfile is the name of the appropriate freebsd dtb file (which you must install on your freebsd image along with the kernel), then everything should work out properly. Of course an alternative is to install the freebsd dtb files onto the msdos partition along with u-boot and let u-boot load them and set fdtaddr. If this is what you're doing and it still isn't working, I suspect the problem is in ubldr, not u-boot itself. We'll have to turn on some debugging in sys/boot/fdt/fdt_loader_cmd.c to track that down. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Apr 8 13:06:06 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17943875; Tue, 8 Apr 2014 13:06:06 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF5B51E72; Tue, 8 Apr 2014 13:06:05 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WXVj2-00025u-M7; Tue, 08 Apr 2014 13:06:04 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s38D62xL092689; Tue, 8 Apr 2014 07:06:02 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Bv17/p7phZqBNSi0Lq+Jv Subject: Re: [BeagleBone Black Test PATCH 0/2] port latest u-boot From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <1396862732-4961-1-git-send-email-xbing6@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 Apr 2014 07:06:01 -0600 Message-ID: <1396962361.81853.409.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, Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 13:06:06 -0000 On Mon, 2014-04-07 at 18:41 -0700, Tim Kientzle wrote: > On Apr 7, 2014, at 2:25 AM, Xuebing Wang wrote: > > > Hi Tim and all, > > > > This is for discussion only. Would you please advice? > > > > This is motivated by trying to increase CPU frequency for BeagleBone Black. > > > > AM335x cpufreq is not supported yet. In order to achieve the goal to increase > > CPU freq, I am thinking of a 2-step approach: > > 1) port latest u-boot, which have cpufreq better organized > > 2) tweak u-boot opp/freq later > > Setting the processor frequency after the OS is running > is not difficult. The AM335x TRM shows exactly how to do it. > > I would not change U-Boot but rather implement > a FreeBSD driver that exposed a read/write sysctl > to reprogram the CPU frequency. > > Getting powerd to work with this should be straightforward. > > Tim > I agree with this, we should handle the frequency change in the kernel rather than in u-boot. On the other hand, I'm all for updating to a newer u-boot for other reasons. I did that for imx6, updating to 2014.01 in place of the 2013.04 that wandboard was using, and it went well. In fact, pretty much all I had to do was remove all the patches I had been using for 2013.04 except for turning on the API option and a couple other options. There apparently have been recent fixes to some of the API stuff, such as how storage devices are enumerated, which will help with the new features added to ubldr that let you choose which device to load the kernel from with u-boot env vars. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Apr 9 03:19:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24EE1DC0; Wed, 9 Apr 2014 03:19:03 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF8431D9E; Wed, 9 Apr 2014 03:19:02 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id bj1so1924174pad.3 for ; Tue, 08 Apr 2014 20:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hpD0cV/fE56gL7XW4S9jBh0cMwcQ5yGTNN5Gb8RoQ8c=; b=0Qn7FOZaJCfPnk10CwDn3iEyRfj/RyExuV1+5Wj0ZqZU33dPujE3L6pR5z7mOwc+05 Qx4vFZn3KtZqeHn3tb1dhcDlImHHqY51m3B2UDL4oL7hjK5SX7NES3onwPVG1YKIOyJp +GrNn5oQdKfW3kOpOLxBFXMeSRr24hDBEiC+mNejNF3W0UA0Ri0LLJ2ML6t2amvSowmd ai43qEsPHvEJI8lI0+1D65AxGrRvirnYo+MG/EVmYI5aaFtiuD16GklpLVOBzcs3aaYQ RiC0cRnujj8YOpxejlZIiX2GyZcyQQ07u0lsG85tm5WRU0rQ4K9gNsEhH5GAn9ToAzfS ApxA== X-Received: by 10.67.23.135 with SMTP id ia7mr8906124pad.5.1397013542557; Tue, 08 Apr 2014 20:19:02 -0700 (PDT) Received: from [216.131.71.104] ([216.131.71.104]) by mx.google.com with ESMTPSA id yo9sm18753103pab.16.2014.04.08.20.18.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Apr 2014 20:19:01 -0700 (PDT) Message-ID: <5344BC21.9030109@gmail.com> Date: Wed, 09 Apr 2014 11:18:57 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ian Lepore , Tim Kientzle Subject: Re: [BeagleBone Black Test PATCH 0/2] port latest u-boot References: <1396862732-4961-1-git-send-email-xbing6@gmail.com> <1396962361.81853.409.camel@revolution.hippie.lan> In-Reply-To: <1396962361.81853.409.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 03:19:03 -0000 1) I fixed the "kernel reboots every 50 seconds issue" by disable Watchdog. AM335x Watchdog is enabled by below commit in mainline u-boot. It is written on Oct 1 2013. commit 6843918e0035bf06cb65ad2b4c98b38e86e43bd5 Author: Tom Rini Date: Tue Oct 1 12:32:04 2013 -0400 am335x: Enable CONFIG_OMAP_WATCHDOG support There is a board-specific portion for calling watchdog enable itself, in main U-Boot. Signed-off-by: Tom Rini 2) Do we consider to port the latest u-boot? On 04/08/2014 09:06 PM, Ian Lepore wrote: > On Mon, 2014-04-07 at 18:41 -0700, Tim Kientzle wrote: >> On Apr 7, 2014, at 2:25 AM, Xuebing Wang wrote: >> >>> Hi Tim and all, >>> >>> This is for discussion only. Would you please advice? >>> >>> This is motivated by trying to increase CPU frequency for BeagleBone Black. >>> >>> AM335x cpufreq is not supported yet. In order to achieve the goal to increase >>> CPU freq, I am thinking of a 2-step approach: >>> 1) port latest u-boot, which have cpufreq better organized >>> 2) tweak u-boot opp/freq later >> Setting the processor frequency after the OS is running >> is not difficult. The AM335x TRM shows exactly how to do it. >> >> I would not change U-Boot but rather implement >> a FreeBSD driver that exposed a read/write sysctl >> to reprogram the CPU frequency. >> >> Getting powerd to work with this should be straightforward. >> >> Tim >> > I agree with this, we should handle the frequency change in the kernel > rather than in u-boot. > > On the other hand, I'm all for updating to a newer u-boot for other > reasons. I did that for imx6, updating to 2014.01 in place of the > 2013.04 that wandboard was using, and it went well. In fact, pretty > much all I had to do was remove all the patches I had been using for > 2013.04 except for turning on the API option and a couple other options. > There apparently have been recent fixes to some of the API stuff, such > as how storage devices are enumerated, which will help with the new > features added to ubldr that let you choose which device to load the > kernel from with u-boot env vars. > > -- Ian > > > -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Wed Apr 9 03:21:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7EB6E1D; Wed, 9 Apr 2014 03:21:37 +0000 (UTC) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7CF41DB5; Wed, 9 Apr 2014 03:21:37 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id um1so1920773pbc.2 for ; Tue, 08 Apr 2014 20:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hvtuUuVbLMIfsaVtpuGgllihF65YZHzs/PfkOcRi9Vg=; b=MFZReOJLiZ2YAootvYEeBGEvYS2A05sa1OgQycKNV/H14hy9DxWjPe17t3KD2R2QMf 3TPPzy0xd8YcAFbjrO0c/3ryzn3vblJrg1TFwME4cl+45rTwtDb8USPZ5fUyQUAvuQ6t yT53hr5xmcD8cMQoIo8DwxCy45KP061iXxURBBee5UR3LYyCDPdVupoymPflTBL2Pi1H tkLL/rlG9w7mqJ68VzYwbvPXZfMXLxfMr8MVoTiPV8mxVqA81teGLICiXwPmNoQYargE 6mrsrJz0mWf5OH7Rh1Q7/vbY9tYjba/blxpZBB0M7yZM4bKqts13obgZ5LQ4V1sFRFxW FxuA== X-Received: by 10.68.170.131 with SMTP id am3mr8794135pbc.97.1397013697168; Tue, 08 Apr 2014 20:21:37 -0700 (PDT) Received: from [216.131.71.104] ([216.131.71.104]) by mx.google.com with ESMTPSA id jd5sm7915171pbb.18.2014.04.08.20.21.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Apr 2014 20:21:35 -0700 (PDT) Message-ID: <5344BCBA.8050908@gmail.com> Date: Wed, 09 Apr 2014 11:21:30 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: BeagleBone Black: Increase CPU frequency from 800MHz to 1GHz References: <533CA68E.1020602@gmail.com> <1396487123.81853.274.camel@revolution.hippie.lan> In-Reply-To: <1396487123.81853.274.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 03:21:37 -0000 Thanks Ian. Any suggestions what CPU Freq benchmark tool to use? On 04/03/2014 09:05 AM, Ian Lepore wrote: > On Thu, 2014-04-03 at 08:08 +0800, Xuebing Wang wrote: >> Hi community, >> >> I am working on a small project to increase AM335x Cortex-A8 MPU >> frequency from 800MHz to 1GHz. >> >> Would you please point to me which tree should I base my work on? Is it >> current? >> >> I did notice that there is "projects/armv6", svn log under sys/arm/ti >> shows the latest commit is "2012-08-15" >> > Definitely use -current. That projects branch was where the initial > armv6 work was done long ago, but that was all merged to 10 and has now > evolved into 11-current. > > I think very many Beaglebone users will be interested in your work, > including me! > > -- Ian > > > -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Wed Apr 9 05:42:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9E76AFB for ; Wed, 9 Apr 2014 05:42:32 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1ECB1B13 for ; Wed, 9 Apr 2014 05:42:32 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id hz1so2055961pad.35 for ; Tue, 08 Apr 2014 22:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=fpKs4R03V+Yx9ruw3/Z1hoZ7MQKBPcBm+GigVNqOr3Q=; b=I+BON8nUN2xEhMJ+Zjq2EqukuWxJY/qNnlIZVxygzlqyNS+Pr898UeQJWqs51OND1j 03WOQsXQ+MxReBOYDr9kCPZ0512V0C86BVVcjWpHHJil1OjTn5qjI+RHAjIx9N3gffOj Ckq+IF13Mk+/Kq8YW01pV5QF5VILFEWywq6XknD0Igvh6dwNnTvouQjobgnK0cYOzjw3 EURY0EwWpfFpb9mjsyBQkDJNfTCxuCagqvAY6A/CiUNDRj++SWudNNpWq0JSqrKbOzbP 5j9WcqF3XuMtzzVOCOjoORQpq/KCrg78fmBZFXE+id+v1hSCM4CpshRFLzqS7Kcrocrb V2dA== X-Received: by 10.68.249.100 with SMTP id yt4mr9353729pbc.165.1397022151717; Tue, 08 Apr 2014 22:42:31 -0700 (PDT) Received: from [216.131.71.159] ([216.131.71.159]) by mx.google.com with ESMTPSA id gj9sm8663780pbc.7.2014.04.08.22.42.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Apr 2014 22:42:30 -0700 (PDT) Message-ID: <5344DDC3.4080302@gmail.com> Date: Wed, 09 Apr 2014 13:42:27 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: [BeagleBone Black] Issue of "Unable to unwind further" 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 05:42:32 -0000 I am using snapshot build (the latest BeagleBone snapshot build: FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140323-r263665.img Everytime I do reboot or poweroff, I get the captioned error. I googled it, I think I am not alone. Also, I have the same problem with portsnap fetch. Any idea how to fix it? Thanks. Below is the log from BeagleBone Black UART: root@beaglebone:~ # reboot Mar 24 09:22:54 beaglebone reboot: rebooted by root Mar 24 09:22:54 beaglebone syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...5 5 3 3 0 0 done All buffers synced. lock order reversal: 1st 0xc2b97934 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xc2b97814 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0541754 lr = 0xc02324b8 (db_trace_self_wrapper+0x30) sp = 0xde6cc9c0 fp = 0xde6ccad8 r10 = 0xc2b97814 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc02324b8 lr = 0xc039b1a4 (kdb_backtrace+0x38) sp = 0xde6ccae0 fp = 0xde6ccae8 r4 = 0xc0685484 r5 = 0xc0591b55 r6 = 0xc05c3999 r7 = 0xc05b0bdc kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc039b1a4 lr = 0xc03b5ad4 (witness_checkorder+0xe50) sp = 0xde6ccaf0 fp = 0xde6ccb40 r4 = 0xc059d070 witness_checkorder() at witness_checkorder+0xe50 pc = 0xc03b5ad4 lr = 0xc03480e8 (__lockmgr_args+0x8b4) sp = 0xde6ccb48 fp = 0xde6ccbb0 r4 = 0x00000000 r5 = 0x00080400 r6 = 0x00000584 r7 = 0xc2b97834 r8 = 0xc2b97814 r9 = 0x00080000 r10 = 0xc05c3996 __lockmgr_args() at __lockmgr_args+0x8b4 pc = 0xc03480e8 lr = 0xc03fa264 (vop_stdlock+0x3c) sp = 0xde6ccbb8 fp = 0xde6ccbc8 r4 = 0xde6ccbe8 r5 = 0xc065d020 r6 = 0x00000000 r7 = 0x00080400 r8 = 0xde6ccbe8 r9 = 0x00000000 r10 = 0x00000584 vop_stdlock() at vop_stdlock+0x3c pc = 0xc03fa264 lr = 0xc056a790 (VOP_LOCK1_APV+0xd8) sp = 0xde6ccbd0 fp = 0xde6ccbe0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd8 pc = 0xc056a790 lr = 0xc04186c0 (_vn_lock+0x44) sp = 0xde6ccbe8 fp = 0xde6ccc18 r4 = 0xc2b977e0 r5 = 0x0000000a r6 = 0xc05c3996 _vn_lock() at _vn_lock+0x44 pc = 0xc04186c0 lr = 0xc04f2c40 (ffs_flushfiles+0x98) sp = 0xde6ccc20 fp = 0xde6ccc48 r4 = 0xc2aaf900 r5 = 0x0000000a r6 = 0xc2aa3560 r7 = 0x00000000 r8 = 0xc2e05640 r9 = 0x00000000 r10 = 0x00000000 ffs_flushfiles() at ffs_flushfiles+0x98 pc = 0xc04f2c40 lr = 0xc04d5e10 (softdep_flushfiles+0x1d0) sp = 0xde6ccc50 fp = 0xde6ccc98 r4 = 0xc2aa3560 r5 = 0x0000000a r6 = 0xc2e05640 r7 = 0x00000000 r8 = 0x00000100 r9 = 0xc05c382e softdep_flushfiles() at softdep_flushfiles+0x1d0 pc = 0xc04d5e10 lr = 0xc04f5960 (ffs_unmount+0x104) sp = 0xde6ccca0 fp = 0xde6cccd0 r4 = 0xc2e05640 r5 = 0xc2c0a000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc2e05640 r9 = 0x00000000 r10 = 0xc2aaf900 ffs_unmount() at ffs_unmount+0x104 pc = 0xc04f5960 lr = 0xc04026f8 (dounmount+0x4c4) sp = 0xde6cccd8 fp = 0xde6ccd20 r4 = 0xc2b97900 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc2e05640 r9 = 0x00080000 r10 = 0x00080000 dounmount() at dounmount+0x4c4 pc = 0xc04026f8 lr = 0xc040aea4 (vfs_unmountall+0x48) sp = 0xde6ccd28 fp = 0xde6ccd48 r4 = 0xc2e05640 r5 = 0xc059d070 r6 = 0x00000000 r7 = 0xc2aa3560 r8 = 0xc065d2b0 r9 = 0xc05be5d0 r10 = 0xc05b1c05 vfs_unmountall() at vfs_unmountall+0x48 pc = 0xc040aea4 lr = 0xc0363fe4 (kern_reboot+0x47c) sp = 0xde6ccd50 fp = 0xde6ccdb0 r4 = 0xc06691e4 r5 = 0xc092aad8 r6 = 0x00000000 r7 = 0xcd2156a8 r8 = 0xc05a165f r9 = 0x00000000 r10 = 0xc05a161e kern_reboot() at kern_reboot+0x47c pc = 0xc0363fe4 lr = 0xc0363b60 ($d) sp = 0xde6ccdb8 fp = 0xde6ccdc0 r4 = 0xde6cce20 r5 = 0xc2a9dc80 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xde6cce18 r10 = 0x00000004 $d() at $d pc = 0xc0363b60 lr = 0xc05569f8 (swi_handler+0x284) sp = 0xde6ccdc8 fp = 0xde6cce60 r4 = 0xc2e05640 swi_handler() at swi_handler+0x284 pc = 0xc05569f8 lr = 0xc0543270 (swi_exit) sp = 0xde6cce68 fp = 0xbffffd08 r4 = 0x00000004 r5 = 0x00000002 r6 = 0xbffffce4 r7 = 0x00000037 r8 = 0x00000000 r9 = 0x00000000 swi_exit() at swi_exit pc = 0xc0543270 lr = 0xc0543270 (swi_exit) sp = 0xde6cce68 fp = 0xbffffd08 Unable to unwind further Uptime: 56s Rebooting... -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Wed Apr 9 09:33:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E30E58FD for ; Wed, 9 Apr 2014 09:33:29 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 688761C38 for ; Wed, 9 Apr 2014 09:33:29 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id u14so921627lbd.19 for ; Wed, 09 Apr 2014 02:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=QGouE4eA3+g5QAr8VGeXgC7KVFTS1vcY8rUSzQ2nSSY=; b=bw+KDAZMqn6jpk01lcj6xZGo3+AGcaiLzTjmuDIuv/sLE0T85EAsknDqiBwOaBbnFu ggeTHgS6rKpsOQ6VlCYGLFdEX2atTsZ/tweNP0h7/Om0OHZmFS/WfdPPxNOo/nSbK0Fu 7lMMulPTqnQPP1BdfTVql4F5yO9cGJiCdRB/6/nq6tgUJTls0tEsyBBV3sOq1aN8LKHE F2+R5LSTkRnPczBOsUv78q8EIuMtKJW/JBgkUGYbKg55JeKKUvClf7D1EGlpEf6tcbdD ljUX+C6Ibup/vN2aBys4nhR9pF7xCSu/wKlROHR0coarOuM6dEeVvBoQrSOUp87JCvVT UFWw== X-Received: by 10.112.128.131 with SMTP id no3mr247332lbb.57.1397036007209; Wed, 09 Apr 2014 02:33:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.207.10 with HTTP; Wed, 9 Apr 2014 02:32:57 -0700 (PDT) From: Matthias Gamsjager Date: Wed, 9 Apr 2014 11:32:57 +0200 Message-ID: Subject: CubieTruck Cubieboard3 support To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 09:33:29 -0000 Hello, I found a wiki entry for the Cubieboard 1 and 2. There is a Cubieboard 3 with rather nice specs. Does anyone have any success booting Freebsd on that board? Regards, Matthias From owner-freebsd-arm@FreeBSD.ORG Wed Apr 9 09:53:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9A23D59 for ; Wed, 9 Apr 2014 09:53:07 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A875A1DED for ; Wed, 9 Apr 2014 09:53:07 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id hn18so6214958igb.11 for ; Wed, 09 Apr 2014 02:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a5DSOGaulWfclUw3brAFGPiSU6Ec7muqH6NdLtK/lqA=; b=A1GwYm2nR4pMoRxzYDt32DLTgmHTRZKm0MuW1nd8XKXwL9AzwE7bgkuIqG03kRNLyb DWYCDOkAnRh2NiURandvqJspc9degJwX3pBp6nhItSfroGnfuNHOD7sgpFE3n5X6J7sD /av6g2e8Ax6Mzi8qSTTaaPfhLBMRzLf4PmEWPcTq2fOc0uMRl+IDUcbO2JBKYzUYwok3 3DAixCt6yk/ie5vijvV8jBppou18omtZh+ZuEAQW5XycywJpCgAlihCwEOvQKYLCKwl6 wNbK9KxS9V9jgiX/BFYSU78ndUeGtU3N4yjNLT66nVsHixX63j16VHDXWt+vq9GMjnaF xLcQ== MIME-Version: 1.0 X-Received: by 10.50.12.100 with SMTP id x4mr3548636igb.15.1397037187073; Wed, 09 Apr 2014 02:53:07 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Wed, 9 Apr 2014 02:53:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Apr 2014 17:53:07 +0800 Message-ID: Subject: Re: CubieTruck Cubieboard3 support From: Ganbold Tsagaankhuu To: Matthias Gamsjager Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 09:53:08 -0000 On Wed, Apr 9, 2014 at 5:32 PM, Matthias Gamsjager wrote: > Hello, > > I found a wiki entry for the Cubieboard 1 and 2. There is a Cubieboard > 3 with rather nice specs. > > Does anyone have any success booting Freebsd on that board? > If I understand correctly it is similar to Cubieboard 2 so boot most probably will work. Ganbold > > > Regards, > Matthias > _______________________________________________ > 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 Apr 9 10:02:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5218DF for ; Wed, 9 Apr 2014 10:02:58 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 502AB1042 for ; Wed, 9 Apr 2014 10:02:58 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id z11so933033lbi.8 for ; Wed, 09 Apr 2014 03:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=uO6mMSjlt5BhYwaYtSKpoLcaenOwtKUn5a9H38FPBsA=; b=EtvFyJ1sN5TMoC7W4nPD6hUthhn3DCqBNxUeAnPqzPCm2l+4vixH3/m7Vbugclv2AP m50gxieJuC1NhWcRakHBImlzgNNAGwvxDF3NqWByjCw7/bXN060Wn3W3ODhbKCD7CcLG ZZTTotdiU6tKCxe6cBRwKRLj3GFMtvNUCrsOtYcknVrgMrAyB4PVUl37uTjeiUhz/Pqf 8oqTsH9nqUzl/uvIOybkmyEDt+2jEpIRQBg7KN5kGcZRSXouEbVC0yEINBGLPJPqjTsb sTlQvnyzsLLZVLGOfaPm8CIaFLAKANSUXKRa/T8hgLQt84DxeOT1Y8Uxwen1gFwgtdhd jY8A== X-Received: by 10.112.137.193 with SMTP id qk1mr462947lbb.53.1397037776098; Wed, 09 Apr 2014 03:02:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.207.10 with HTTP; Wed, 9 Apr 2014 03:02:25 -0700 (PDT) In-Reply-To: References: From: Matthias Gamsjager Date: Wed, 9 Apr 2014 12:02:25 +0200 Message-ID: Subject: Re: CubieTruck Cubieboard3 support Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 10:02:58 -0000 > > If I understand correctly it is similar to Cubieboard 2 so boot most > probably will work. > > Ganbold > Isn't the uboot image specifically build for the Cubieboard 2? From owner-freebsd-arm@FreeBSD.ORG Wed Apr 9 10:27:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F1135D0 for ; Wed, 9 Apr 2014 10:27:20 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B3E21260 for ; Wed, 9 Apr 2014 10:27:20 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id as1so2233506iec.17 for ; Wed, 09 Apr 2014 03:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yb+lYJQGjdqh7Q1c4RbWba8q2OvYeqs+NtMoKJrZorw=; b=RqW9vFQj7jhn99OJim7Z/j8DJEOAlsiU8Asn0VO6r3Fs5Dnnxyxxih+WkdUov0sn9D 1CEUbSNPpBGj+JiZ8dLdZ8OymMnHx38EYsWQGcIhmjrASkU5GwptxtloDNWwZ5EosV1t CbRwB2/VSsB4ZQJC8msqo4QA5kEwSbZEXXaV61rGemRqLdQOVun8jirTt+LOAGcvoUam iSWCa8Fjw0zi+Pv+xjI7J2mH0bS7ImAgfrgU2rm/kKcuU/YoIy1iKcAqiNXFI7DL3UWY Ix10jxcCAv3eArQNVbnr/4AJQXr6oNpTRwNldq1a+rudWznjE4HwodxlBelrOip3ewsa b5EA== MIME-Version: 1.0 X-Received: by 10.42.88.204 with SMTP id d12mr7566278icm.24.1397039239466; Wed, 09 Apr 2014 03:27:19 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Wed, 9 Apr 2014 03:27:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Apr 2014 18:27:19 +0800 Message-ID: Subject: Re: CubieTruck Cubieboard3 support From: Ganbold Tsagaankhuu To: Matthias Gamsjager Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Stalin Joseph , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 10:27:20 -0000 On Wed, Apr 9, 2014 at 6:02 PM, Matthias Gamsjager wrote: > > > > If I understand correctly it is similar to Cubieboard 2 so boot most > > probably will work. > > > > Ganbold > > > > Isn't the uboot image specifically build for the Cubieboard 2? > I think you can contact Coba since he has Cubietruck and he might be able to tell. Ganbold > _______________________________________________ > 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 Apr 9 11:26:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A08038C6 for ; Wed, 9 Apr 2014 11:26:04 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29308191B for ; Wed, 9 Apr 2014 11:26:03 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id pv20so1002968lab.24 for ; Wed, 09 Apr 2014 04:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=uQFRG+ltb+LAAsAwgfvaodhh5SnWGQkyNKmhiFWuCIk=; b=N5lZ2tcj6fdu0wi+n3R5xgUplwsFOmhg2aeKe1rWr6ToFrVkFpmjLSsOJAazYEerrq 7voMUMLa15uRhcm0QPfALAVHpoFt6c7KY+SatAQwKUoyUarQHaorGVZIPF7mC4678XGw HE2ST19NtHs9WpXUJiB/rHGlAGjJliaLb940hYWEjD2abmdKFzhpYx07KjOmxF3V+ARp i6DFBcANe7SgpwTPcDECcpkpR/DLAsGCs4xMvjd25PBSq3JOccXmgNoVczCelE6aTSe2 tJTahw7TGMd7FaDX6nC+hedSMnoczfXCeNelztNEC/DVugXwzAEa2z2nCFN8T6UfFajM VgYA== X-Received: by 10.112.209.5 with SMTP id mi5mr6778000lbc.30.1397042762049; Wed, 09 Apr 2014 04:26:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.207.10 with HTTP; Wed, 9 Apr 2014 04:25:31 -0700 (PDT) In-Reply-To: References: From: Matthias Gamsjager Date: Wed, 9 Apr 2014 13:25:31 +0200 Message-ID: Subject: Re: CubieTruck Cubieboard3 support To: coba@whisper.su Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:26:04 -0000 I will follow the wiki page and provide an image :) On Wed, Apr 9, 2014 at 1:23 PM, wrote: > Good day guys, > > If you=E2=80=99ll provide kernel I can try to boot it and return info. If= you want I > can even provide ssh access to cubietruck. :) > > On 09 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 14:27, Ganbold Tsagaankhuu wrote: > > > > > On Wed, Apr 9, 2014 at 6:02 PM, Matthias Gamsjager > wrote: >> >> > >> > If I understand correctly it is similar to Cubieboard 2 so boot most >> > probably will work. >> > >> > Ganbold >> > >> >> Isn't the uboot image specifically build for the Cubieboard 2? > > > > I think you can contact Coba since he has Cubietruck and he might be able= to > tell. > > Ganbold > > >> >> _______________________________________________ >> 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 Apr 9 12:19:44 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B412DD2E; Wed, 9 Apr 2014 12:19:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 896191FD0; Wed, 9 Apr 2014 12:19:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s39CJhH6011311; Wed, 9 Apr 2014 08:19:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s39CJhrH011298; Wed, 9 Apr 2014 12:19:43 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 9 Apr 2014 12:19:43 GMT Message-Id: <201404091219.s39CJhrH011298@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 12:19:44 -0000 TB --- 2014-04-09 09:00:37 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-09 09:00:37 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-09 09:00:37 - starting HEAD tinderbox run for arm/arm TB --- 2014-04-09 09:00:37 - cleaning the object tree TB --- 2014-04-09 09:00:37 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-09 09:00:41 - At svn revision 264295 TB --- 2014-04-09 09:00:42 - building world TB --- 2014-04-09 09:00:42 - CROSS_BUILD_TESTING=YES TB --- 2014-04-09 09:00:42 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-09 09:00:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-09 09:00:42 - SRCCONF=/dev/null TB --- 2014-04-09 09:00:42 - TARGET=arm TB --- 2014-04-09 09:00:42 - TARGET_ARCH=arm TB --- 2014-04-09 09:00:42 - TZ=UTC TB --- 2014-04-09 09:00:42 - __MAKE_CONF=/dev/null TB --- 2014-04-09 09:00:42 - cd /src TB --- 2014-04-09 09:00:42 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Apr 9 09:00:49 UTC 2014 >>> 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 Wed Apr 9 12:19:42 UTC 2014 TB --- 2014-04-09 12:19:42 - generating LINT kernel config TB --- 2014-04-09 12:19:42 - cd /src/sys/arm/conf TB --- 2014-04-09 12:19:42 - /usr/bin/make -B LINT TB --- 2014-04-09 12:19:42 - cd /src/sys/arm/conf TB --- 2014-04-09 12:19:42 - /obj/arm.arm/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-09 12:19:42 - building LINT kernel TB --- 2014-04-09 12:19:42 - CROSS_BUILD_TESTING=YES TB --- 2014-04-09 12:19:42 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-09 12:19:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-09 12:19:42 - SRCCONF=/dev/null TB --- 2014-04-09 12:19:42 - TARGET=arm TB --- 2014-04-09 12:19:42 - TARGET_ARCH=arm TB --- 2014-04-09 12:19:42 - TZ=UTC TB --- 2014-04-09 12:19:42 - __MAKE_CONF=/dev/null TB --- 2014-04-09 12:19:42 - cd /src TB --- 2014-04-09 12:19:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 9 12:19:42 UTC 2014 >>> 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/legacy/bin:/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 -I /src/sys/arm/conf /src/sys/arm/conf/LINT WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `CAM_DEBUG_DELAY' encountered. /src/sys/arm/conf/LINT: unknown option "IMAGACT_BINMISC" *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-04-09 12:19:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-04-09 12:19:43 - ERROR: failed to build LINT kernel TB --- 2014-04-09 12:19:43 - 9700.24 user 1533.06 system 11945.94 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Apr 9 12:58:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD681ECF for ; Wed, 9 Apr 2014 12:58:58 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 448B31484 for ; Wed, 9 Apr 2014 12:58:58 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id w7so1098164lbi.6 for ; Wed, 09 Apr 2014 05:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=2lrNhT2kzfdqRuVSxJ2O92lLw3iyJ8w6o69iRBFPOOo=; b=UpretaDDQVfVzFpadAHQU/1jmREgkcPYWvQqcSgevHDJaSHDyry3yIqLorhuENbDvd pQLg3y1QiewwvuUPmrg0O9nId8h+nl1MG0wy6Qdf4MRrzASQ4lbPqTrU8WwHVNJlDqRa bPM/SPTEuCNybV3KC1K30kc4Nm3+Ir4SmODs+lBwASMuW7Apq7aCbGHENZYlRVC06glC MwmZ8aAszGrdDxp6X8AY3F0uP04vUOEwUiQy1t9tPpso2C0aOhvyF8SVn2vGr/tCGPuj HSIuqCUCjoxsWWI5OLrCZk5gY923ClMhuRKSDis+sL53n3wjq7bhrqqzQm60RoowCU9J Dl4g== X-Received: by 10.112.184.104 with SMTP id et8mr1666712lbc.40.1397048336196; Wed, 09 Apr 2014 05:58:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.207.10 with HTTP; Wed, 9 Apr 2014 05:58:26 -0700 (PDT) In-Reply-To: References: From: Matthias Gamsjager Date: Wed, 9 Apr 2014 14:58:26 +0200 Message-ID: Subject: Re: CubieTruck Cubieboard3 support To: coba@whisper.su Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 12:58:58 -0000 I sent you an image file via wetransfer On Wed, Apr 9, 2014 at 1:27 PM, wrote: > Would be nice if you give me whole image to boot up because right now i d= on=E2=80=99t have free storage on bsd to cross compile whole system. :( > > On 09 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 15:25, Matthias Gamsjager wrote: > >> I will follow the wiki page and provide an image :) >> >> On Wed, Apr 9, 2014 at 1:23 PM, wrote: >>> Good day guys, >>> >>> If you=E2=80=99ll provide kernel I can try to boot it and return info. = If you want I >>> can even provide ssh access to cubietruck. :) >>> >>> On 09 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 14:27, Ganbold Tsagaankhuu <= ganbold@gmail.com> wrote: >>> >>> >>> >>> >>> On Wed, Apr 9, 2014 at 6:02 PM, Matthias Gamsjager >>> wrote: >>>> >>>>> >>>>> If I understand correctly it is similar to Cubieboard 2 so boot most >>>>> probably will work. >>>>> >>>>> Ganbold >>>>> >>>> >>>> Isn't the uboot image specifically build for the Cubieboard 2? >>> >>> >>> >>> I think you can contact Coba since he has Cubietruck and he might be ab= le to >>> tell. >>> >>> Ganbold >>> >>> >>>> >>>> _______________________________________________ >>>> 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 Apr 9 16:14:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D221938 for ; Wed, 9 Apr 2014 16:14:18 +0000 (UTC) Received: from mogw0108.ocn.ad.jp (mogw0108.ocn.ad.jp [118.23.109.82]) by mx1.freebsd.org (Postfix) with ESMTP id 5C39F1C99 for ; Wed, 9 Apr 2014 16:14:17 +0000 (UTC) Received: from mv-osn-hcb007.ocn.ad.jp (mv-osn-hcb007.ocn.ad.jp [118.23.180.69]) by mogw0108.ocn.ad.jp (Postfix) with ESMTP id 7F01E258238 for ; Thu, 10 Apr 2014 01:14:16 +0900 (JST) Received: from smtp.ocn.ne.jp (mv-osn-hcb007 [118.23.180.69]) by mv-osn-hcb007.ocn.ad.jp (Postfix) with ESMTP id 662A63642AA for ; Thu, 10 Apr 2014 01:14:16 +0900 (JST) Received: from [192.168.2.32] (p12241-ipngn702souka.saitama.ocn.ne.jp [180.28.107.241]) by smtp.ocn.ne.jp (Postfix) with ESMTP for ; Thu, 10 Apr 2014 01:14:16 +0900 (JST) Message-ID: <534571D0.4090506@dream.com> Date: Thu, 10 Apr 2014 01:14:08 +0900 From: biwa User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: How build my application? Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:14:18 -0000 Hi, all. 'FreeBSD CURRENT' is work fine on WANDBOARD-DUAL. But, not work my application (ex. Hello World Application.) my step: 1. build for cross-compiler make xdev XDEV=arm XDEV_ARCH=armv6 2. make HelloWorld application (hello.c) #include #include int main(void) { printf("Hello world\n"); return 0; } 3. compile my application armv6-freebsd-cc -mcpu=cortex-a9 -Wa,-meabi=5 hello.c (built a.out) 4. execute my application FreeBSD on WANDBOARD, type a.out , follow 'ERROR' result. ----- Spurious interrupt detected [0x000003ff] pid 24 (a.out), uid 0: exited on signal 6 ld-elf.so.1: assert failed: /src/libexec/rtld-elf/rtld_lock.c:233 Abort trap ----- What mistake? From owner-freebsd-arm@FreeBSD.ORG Wed Apr 9 18:54:07 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2051B5C4; Wed, 9 Apr 2014 18:54:07 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD070113E; Wed, 9 Apr 2014 18:54:06 +0000 (UTC) Received: from [192.168.1.104] (c-24-6-177-88.hsd1.ca.comcast.net [24.6.177.88]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 3AACC1929A9; Wed, 9 Apr 2014 18:54:05 +0000 (UTC) Subject: Re: [head tinderbox] failure on powerpc/powerpc From: Sean Bruno To: FreeBSD Tinderbox In-Reply-To: <201404091812.s39ICHBs012578@freebsd-current.sentex.ca> References: <201404091812.s39ICHBs012578@freebsd-current.sentex.ca> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MzRgGSrbG0PiMSCLRigp" Date: Wed, 09 Apr 2014 11:54:04 -0700 Message-ID: <1397069644.1121.13.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: powerpc@freebsd.org, mips64@freebsd.org, current@freebsd.org, ia64 , sparc64@freebsd.org, arm@freebsd.org, i386 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 18:54:07 -0000 --=-MzRgGSrbG0PiMSCLRigp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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. > /src/sys/powerpc/conf/LINT: unknown option "IMAGACT_BINMISC" > *** Error code 1 >=20 > Stop. > bmake: stopped in /src > *** [buildkernel] Error code 1 >=20 > Stop in /src. > TB --- 2014-04-09 18:12:17 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2014-04-09 18:12:17 - ERROR: failed to build LINT kernel > TB --- 2014-04-09 18:12:17 - 8505.48 user 1007.32 system 9668.85 real >=20 >=20 I believe I have un-derp'd the build at svn r264304 sean --=-MzRgGSrbG0PiMSCLRigp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTRZdMAAoJEBkJRdwI6BaHe8cH/iNmIH0VCJnQIRd0HaFAKLAT lrFfY/+JoGOidXcVAF4IBEzoCeA8W2dInb29S6OGEE8aQb2gt0iobDpc6KPsbaEB zzc+LJGi4s8v2EoIimv32Sif3f8jwHCTZRNuqrKXCEvXtIl69zx+Tu/44v9i0SDy mzFmhuhnTIdGGdBmJv8ydovUMOy/tB6NT4LAGNDfC4QwekD+4NXmiJsKt2SHN2cJ YHWgKtxVDd/iGu2b4J8aWN/mFcPzAt26HiFi1s/r3y70ysYIj6N/ahueriHbaTWu s/1LZ11ovsJeU0LO9tbRaRCZtKgr6GPvpabiMobFTsWhdFagV9HazCWHsMO6GAk= =T1EW -----END PGP SIGNATURE----- --=-MzRgGSrbG0PiMSCLRigp-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 10 02:16:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCF4B6EC; Thu, 10 Apr 2014 02:16:18 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A78CC112E; Thu, 10 Apr 2014 02:16:18 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id fb1so3330396pad.1 for ; Wed, 09 Apr 2014 19:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=f1Bb1wAF99u5yBVCocx9Y69HKbFiVyUacM3DMldpTmU=; b=HMDAgut+ZTWXO/SuTko1JU2aWeqelG9DVhvxFn9u4yQRjmxEGij8yOz0HK0ptXHnH0 CYJcx/4B+1w2mi+2gCfteb+bTQ0ozD5AyXzYcNeoavO6H/4ld9sSLtYRs5Cv0CE4p/V8 U0UkYlZoBhWb4mAlRc5lGfiny+smsUDZpFZ8hAKQdsbX8xogVf5havlHwNevtW2oC++9 Jrv7OEa5mVJHt3oDBpRHUO5TqIHwLZeLigphqfL7fBJRemiX3RkUizD6yFYwRgr9BNAt AXqLC7pd6tMfAnBVGd3zVaLa9wxkOAKtYv/Nz+Mz04USWF2LdruUI3/zbEPr2Jh4/7eq pXmg== X-Received: by 10.68.138.165 with SMTP id qr5mr16210684pbb.123.1397096177599; Wed, 09 Apr 2014 19:16:17 -0700 (PDT) Received: from [216.131.71.97] ([216.131.71.97]) by mx.google.com with ESMTPSA id av2sm5518608pbc.16.2014.04.09.19.16.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 19:16:16 -0700 (PDT) Message-ID: <5345FEED.1040604@gmail.com> Date: Thu, 10 Apr 2014 10:16:13 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org, Tim Kientzle Subject: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 Content-Type: multipart/mixed; boundary="------------080405020601010403050600" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 02:16:18 -0000 This is a multi-part message in MIME format. --------------080405020601010403050600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The latest u-boot is 2014-01. With the latest u-boot, BeagleBone Black CPU runs at 1GHz. I run some benchmark with "ubench -c -s", the number is increased from 5186 to 9588. Attached are the 3 patches for ports: sysutils/u-boot-beaglebone-eabi Thanks. ================================================== Current u-boot: U-Boot 2013.04 (Mar 24 2014 - 07:32:45) root@beaglebone:~ # ubench -c -s Unix Benchmark Utility v.0.3 FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263665: Mon Mar 24 07:27:38 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm Ubench Single CPU: 5186 (0.40s) ================================================== u-boot-2014-01: root@beaglebone:~ # ubench -c -s FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263665: Mon Mar 24 07:27:38 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm Ubench Single CPU: 9588 (0.41s) -- Thanks, Xuebing Wang --------------080405020601010403050600 Content-Type: text/plain; charset=UTF-8; name="patch.add-u-boot-patches" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch.add-u-boot-patches" ------------------------------------------------------------------------ r4 | root | 2014-04-10 09:55:56 +0800 (Thu, 10 Apr 2014) | 5 lines Add the patches for u-boot into folder files/ Submitted by: Xuebing Wang Sponsored by: Tutamen, LLC Index: files/patch-include_configs_ti_am335x_common.h =================================================================== --- files/patch-include_configs_ti_am335x_common.h (revision 0) +++ files/patch-include_configs_ti_am335x_common.h (revision 4) @@ -0,0 +1,23 @@ +--- include/configs/ti_am335x_common.h.orig 2014-04-10 09:22:45.000000000 +0800 ++++ include/configs/ti_am335x_common.h 2014-04-10 09:23:01.000000000 +0800 +@@ -48,10 +48,6 @@ + */ + #define CONFIG_SYS_BOOTCOUNT_ADDR 0x44E3E000 + +-/* Enable the HW watchdog, since we can use this with bootcount */ +-#define CONFIG_HW_WATCHDOG +-#define CONFIG_OMAP_WATCHDOG +- + /* + * SPL related defines. The Public RAM memory map the ROM defines the + * area between 0x402F0400 and 0x4030B800 as a download area and +@@ -62,9 +58,6 @@ + #define CONFIG_SPL_TEXT_BASE 0x402F0400 + #define CONFIG_SPL_MAX_SIZE (0x4030B800 - CONFIG_SPL_TEXT_BASE) + +-/* Enable the watchdog inside of SPL */ +-#define CONFIG_SPL_WATCHDOG_SUPPORT +- + /* + * Since SPL did pll and ddr initialization for us, + * we don't need to do it twice. Index: files/patch-include_configs_am335x_evm.h =================================================================== --- files/patch-include_configs_am335x_evm.h (revision 0) +++ files/patch-include_configs_am335x_evm.h (revision 4) @@ -0,0 +1,84 @@ +--- include/configs/am335x_evm.h.orig 2014-04-10 09:14:56.000000000 +0800 ++++ include/configs/am335x_evm.h 2014-04-10 09:15:36.000000000 +0800 +@@ -18,6 +18,12 @@ + + #include + ++#ifndef CONFIG_SPL_BUILD ++#define CONFIG_CMD_ELF ++#define CONFIG_API ++#define CONFIG_SYS_MMC_MAX_DEVICE 2 ++#endif ++ + #define MACH_TYPE_TIAM335EVM 3589 /* Until the next sync */ + #define CONFIG_MACH_TYPE MACH_TYPE_TIAM335EVM + +@@ -54,14 +60,14 @@ + + #ifndef CONFIG_SPL_BUILD + #define CONFIG_EXTRA_ENV_SETTINGS \ +- "loadaddr=0x80200000\0" \ +- "fdtaddr=0x80F80000\0" \ ++ "loadaddr=0x88000000\0" \ ++ "fdtaddr=0x80000100\0" \ ++ "bootfile=bbubldr\0" \ + "fdt_high=0xffffffff\0" \ + "boot_fdt=try\0" \ + "rdaddr=0x81000000\0" \ + "bootpart=0:2\0" \ + "bootdir=/boot\0" \ +- "bootfile=zImage\0" \ + "fdtfile=undefined\0" \ + "console=ttyO0,115200n8\0" \ + "optargs=\0" \ +@@ -92,8 +98,8 @@ + "root=/dev/nfs " \ + "nfsroot=${serverip}:${rootpath},${nfsopts} rw " \ + "ip=dhcp\0" \ +- "bootenv=uEnv.txt\0" \ +- "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ ++ "bootenv=bb-uEnv.txt\0" \ ++ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ + "importbootenv=echo Importing environment from mmc ...; " \ + "env import -t $loadaddr $filesize\0" \ + "ramargs=setenv bootargs console=${console} " \ +@@ -101,21 +107,21 @@ + "root=${ramroot} " \ + "rootfstype=${ramrootfstype}\0" \ + "loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \ +- "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \ +- "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \ +- "mmcloados=run mmcargs; " \ ++ "loadimage=fatload mmc ${mmcdev} ${loadaddr} ${bootfile}\0" \ ++ "loadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile};fdt addr ${fdtaddr}\0" \ ++ "mmcloados=" \ + "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ + "if run loadfdt; then " \ +- "bootz ${loadaddr} - ${fdtaddr}; " \ ++ "bootelf ${loadaddr};" \ + "else " \ + "if test ${boot_fdt} = try; then " \ +- "bootz; " \ ++ "bootelf ${loadaddr};" \ + "else " \ + "echo WARN: Cannot load the DT; " \ + "fi; " \ + "fi; " \ + "else " \ +- "bootz; " \ ++ "bootelf ${loadaddr};" \ + "fi;\0" \ + "mmcboot=mmc dev ${mmcdev}; " \ + "if mmc rescan; then " \ +@@ -149,9 +155,9 @@ + "bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \ + "findfdt="\ + "if test $board_name = A335BONE; then " \ +- "setenv fdtfile am335x-bone.dtb; fi; " \ ++ "setenv fdtfile bbone.dtb; fi; " \ + "if test $board_name = A335BNLT; then " \ +- "setenv fdtfile am335x-boneblack.dtb; fi; " \ ++ "setenv fdtfile bboneblk.dtb; fi; " \ + "if test $board_name = A33515BB; then " \ + "setenv fdtfile am335x-evm.dtb; fi; " \ + "if test $board_name = A335X_SK; then " \ Index: files/patch-common_env_common.c =================================================================== --- files/patch-common_env_common.c (revision 0) +++ files/patch-common_env_common.c (revision 4) @@ -0,0 +1,15 @@ +--- common/env_common.c.orig 2014-04-10 09:21:17.000000000 +0800 ++++ common/env_common.c 2014-04-10 09:21:41.000000000 +0800 +@@ -59,9 +59,9 @@ + + const uchar *env_get_addr(int index) + { +- if (gd->env_valid) +- return (uchar *)(gd->env_addr + index); +- else ++// if (gd->env_valid) ++// return (uchar *)(gd->env_addr + index); ++// else + return &default_environment[index]; + } + Index: files/patch-include_configs_ti_armv7_common.h =================================================================== --- files/patch-include_configs_ti_armv7_common.h (revision 0) +++ files/patch-include_configs_ti_armv7_common.h (revision 4) @@ -0,0 +1,11 @@ +--- include/configs/ti_armv7_common.h.orig 2014-04-10 09:19:02.000000000 +0800 ++++ include/configs/ti_armv7_common.h 2014-04-10 09:19:18.000000000 +0800 +@@ -197,7 +197,7 @@ + + /* FAT sd card locations. */ + #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1 +-#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img" ++#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "bb-uboot.img" + + #ifdef CONFIG_SPL_OS_BOOT + #define CONFIG_SYS_SPL_ARGS_ADDR 0x80F80000 ------------------------------------------------------------------------ --------------080405020601010403050600 Content-Type: text/plain; charset=UTF-8; name="patch.Makefile-distinfo" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch.Makefile-distinfo" Index: Makefile =================================================================== --- Makefile (revision 349971) +++ Makefile (working copy) @@ -1,7 +1,7 @@ # $FreeBSD$ PORTNAME= beaglebone -PORTVERSION= 2013.04 +PORTVERSION= 2014.01 CATEGORIES= sysutils MASTER_SITES= ftp://ftp.denx.de/pub/u-boot/ \ ${MASTER_SITE_LOCAL} @@ -8,7 +8,7 @@ MASTER_SITE_SUBDIR= kientzle PKGNAMEPREFIX= u-boot- PKGNAMESUFFIX= -eabi -DISTNAME= u-boot-2013.04 +DISTNAME= u-boot-2014.01 MAINTAINER= kientzle@FreeBSD.org COMMENT= U-Boot loader for BeagleBone and BeagleBone Black Index: distinfo =================================================================== --- distinfo (revision 349971) +++ distinfo (working copy) @@ -1,2 +1,2 @@ -SHA256 (u-boot-2013.04.tar.bz2) = 4150e5a4480707c55a8d5b4570262e43af68d8ed3bdc0a433d8e7df47989a69e -SIZE (u-boot-2013.04.tar.bz2) = 9837387 +SHA256 (u-boot-2014.01.tar.bz2) = cdaf8c81583abfa2e73da46cfcf87b0cbd9741d9aa766f3b905376e3652d543d +SIZE (u-boot-2014.01.tar.bz2) = 10180625 --------------080405020601010403050600 Content-Type: text/plain; charset=UTF-8; name="patch.remove-files" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch.remove-files" Index: files/patch-api_Makefile =================================================================== --- files/patch-api_Makefile (revision 350678) +++ files/patch-api_Makefile (working copy) @@ -1,11 +0,0 @@ ---- api/Makefile.orig 2013-04-19 09:25:43.000000000 -0500 -+++ api/Makefile 2013-05-16 17:14:54.000000000 -0500 -@@ -24,7 +24,7 @@ - - LIB = $(obj)libapi.o - --COBJS-$(CONFIG_API) += api.o api_display.o api_net.o api_storage.o \ -+COBJS-$(CONFIG_API) += api.o api_display.o api_storage.o \ - api_platform-$(ARCH).o - - COBJS := $(COBJS-y) Index: files/patch-api_api.c =================================================================== --- files/patch-api_api.c (revision 350678) +++ files/patch-api_api.c (working copy) @@ -1,62 +0,0 @@ ---- api/api.c.orig 2013-04-19 09:25:43.000000000 -0500 -+++ api/api.c 2013-05-16 17:04:11.000000000 -0500 -@@ -226,8 +226,8 @@ - debugf("RESTART ENUM\n"); - - /* net device enumeration first */ -- if (dev_enum_net(di)) -- return 0; -+ //if (dev_enum_net(di)) -+ //return 0; - } - - /* -@@ -264,8 +264,8 @@ - if (di->type & DEV_TYP_STOR) - err = dev_open_stor(di->cookie); - -- else if (di->type & DEV_TYP_NET) -- err = dev_open_net(di->cookie); -+ // else if (di->type & DEV_TYP_NET) -+ // err = dev_open_net(di->cookie); - else - err = API_ENODEV; - -@@ -295,8 +295,8 @@ - if (di->type & DEV_TYP_STOR) - err = dev_close_stor(di->cookie); - -- else if (di->type & DEV_TYP_NET) -- err = dev_close_net(di->cookie); -+ // else if (di->type & DEV_TYP_NET) -+ // err = dev_close_net(di->cookie); - else - /* - * In case of unknown device we cannot change its state, so -@@ -364,8 +364,8 @@ - */ - return API_ENODEV; - -- else if (di->type & DEV_TYP_NET) -- err = dev_write_net(di->cookie, buf, *len); -+ // else if (di->type & DEV_TYP_NET) -+ // err = dev_write_net(di->cookie, buf, *len); - else - err = API_ENODEV; - -@@ -436,6 +436,7 @@ - - *act_len_stor = dev_read_stor(di->cookie, buf, *len_stor, *start); - -+#if 0 - } else if (di->type & DEV_TYP_NET) { - - /* 3. arg points to the var with length of packet to read */ -@@ -452,6 +453,7 @@ - - *act_len_net = dev_read_net(di->cookie, buf, *len_net); - -+#endif - } else - return API_ENODEV; - Index: files/patch-examples_api_Makefile =================================================================== --- files/patch-examples_api_Makefile (revision 350678) +++ files/patch-examples_api_Makefile (working copy) @@ -1,11 +0,0 @@ ---- examples/api/Makefile.orig 2013-04-19 09:25:43.000000000 -0500 -+++ examples/api/Makefile 2013-05-16 17:05:38.000000000 -0500 -@@ -69,7 +69,7 @@ - ######################################################################### - - $(OUTPUT): $(OBJS) -- $(LD) -Ttext $(LOAD_ADDR) -o $@ $^ $(PLATFORM_LIBS) -+ $(LD) -static -Ttext $(LOAD_ADDR) -o $@ $^ $(PLATFORM_LIBS) - $(OBJCOPY) -O binary $@ $(OUTPUT).bin 2>/dev/null - - # Rule to build generic library C files Index: files/patch-include_configs_am335x_evm.h =================================================================== --- files/patch-include_configs_am335x_evm.h (revision 350678) +++ files/patch-include_configs_am335x_evm.h (working copy) @@ -1,236 +0,0 @@ ---- include/configs/am335x_evm.h.orig 2013-04-19 09:25:43.000000000 -0500 -+++ include/configs/am335x_evm.h 2013-05-16 17:08:37.000000000 -0500 -@@ -20,6 +20,12 @@ - - #include - -+#ifndef CONFIG_SPL_BUILD -+#define CONFIG_CMD_ELF -+#define CONFIG_API -+#define CONFIG_SYS_MMC_MAX_DEVICE 2 -+#endif -+ - #define CONFIG_DMA_COHERENT - #define CONFIG_DMA_COHERENT_SIZE (1 << 20) - -@@ -53,94 +59,24 @@ - #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG - #ifndef CONFIG_SPL_BUILD - #define CONFIG_EXTRA_ENV_SETTINGS \ -- "loadaddr=0x80200000\0" \ -- "fdtaddr=0x80F80000\0" \ -- "fdt_high=0xffffffff\0" \ -- "rdaddr=0x81000000\0" \ -- "bootdir=/boot\0" \ -- "bootfile=uImage\0" \ -+ "loadaddr=0x88000000\0" \ -+ "fdtaddr=0x80000100\0" \ -+ "bootfile=bbubldr\0" \ - "fdtfile=\0" \ -- "console=ttyO0,115200n8\0" \ -- "optargs=\0" \ -- "mtdids=" MTDIDS_DEFAULT "\0" \ -- "mtdparts=" MTDPARTS_DEFAULT "\0" \ -- "dfu_alt_info_mmc=" DFU_ALT_INFO_MMC "\0" \ -- "dfu_alt_info_emmc=rawemmc mmc 0 3751936\0" \ -- "dfu_alt_info_nand=" DFU_ALT_INFO_NAND "\0" \ - "mmcdev=0\0" \ -- "mmcroot=/dev/mmcblk0p2 ro\0" \ -- "mmcrootfstype=ext4 rootwait\0" \ -- "bootpart=0:2\0" \ -- "nandroot=ubi0:rootfs rw ubi.mtd=7,2048\0" \ -- "nandrootfstype=ubifs rootwait=1\0" \ -- "nandsrcaddr=0x280000\0" \ -- "nandimgsize=0x500000\0" \ -- "rootpath=/export/rootfs\0" \ -- "nfsopts=nolock\0" \ -- "static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \ -- "::off\0" \ -- "ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \ -- "ramrootfstype=ext2\0" \ -- "mmcargs=setenv bootargs console=${console} " \ -- "${optargs} " \ -- "root=${mmcroot} " \ -- "rootfstype=${mmcrootfstype}\0" \ -- "nandargs=setenv bootargs console=${console} " \ -- "${optargs} " \ -- "root=${nandroot} " \ -- "rootfstype=${nandrootfstype}\0" \ -- "spiroot=/dev/mtdblock4 rw\0" \ -- "spirootfstype=jffs2\0" \ -- "spisrcaddr=0xe0000\0" \ -- "spiimgsize=0x362000\0" \ -- "spibusno=0\0" \ -- "spiargs=setenv bootargs console=${console} " \ -- "${optargs} " \ -- "root=${spiroot} " \ -- "rootfstype=${spirootfstype}\0" \ -- "netargs=setenv bootargs console=${console} " \ -- "${optargs} " \ -- "root=/dev/nfs " \ -- "nfsroot=${serverip}:${rootpath},${nfsopts} rw " \ -- "ip=dhcp\0" \ -- "bootenv=uEnv.txt\0" \ -- "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ -+ "bootenv=bb-uEnv.txt\0" \ -+ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ - "importbootenv=echo Importing environment from mmc ...; " \ - "env import -t $loadaddr $filesize\0" \ -- "ramargs=setenv bootargs console=${console} " \ -- "${optargs} " \ -- "root=${ramroot} " \ -- "rootfstype=${ramrootfstype}\0" \ -- "loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \ -- "loaduimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \ -- "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \ - "mmcboot=echo Booting from mmc ...; " \ -- "run mmcargs; " \ -- "bootm ${loadaddr} - ${fdtaddr}\0" \ -- "nandboot=echo Booting from nand ...; " \ -- "run nandargs; " \ -- "nand read ${loadaddr} ${nandsrcaddr} ${nandimgsize}; " \ -- "bootm ${loadaddr}\0" \ -- "spiboot=echo Booting from spi ...; " \ -- "run spiargs; " \ -- "sf probe ${spibusno}:0; " \ -- "sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; " \ -- "bootm ${loadaddr}\0" \ -- "netboot=echo Booting from network ...; " \ -- "setenv autoload no; " \ -- "dhcp; " \ -- "tftp ${loadaddr} ${bootfile}; " \ -- "tftp ${fdtaddr} ${fdtfile}; " \ -- "run netargs; " \ -- "bootm ${loadaddr} - ${fdtaddr}\0" \ -- "ramboot=echo Booting from ramdisk ...; " \ -- "run ramargs; " \ -- "bootm ${loadaddr} ${rdaddr} ${fdtaddr}\0" \ -+ "bootelf ${kloadaddr}\0" \ -+ "loadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile};fdt addr ${fdtaddr}\0" \ -+ "loadimage=fatload mmc ${mmcdev} ${loadaddr} ${bootfile}\0" \ - "findfdt="\ - "if test $board_name = A335BONE; then " \ -- "setenv fdtfile am335x-bone.dtb; fi; " \ -+ "setenv fdtfile bbone.dtb; fi; " \ - "if test $board_name = A335BNLT; then " \ -- "setenv fdtfile am335x-boneblack.dtb; fi; " \ -+ "setenv fdtfile bboneblk.dtb; fi; " \ - "if test $board_name = A33515BB; then " \ - "setenv fdtfile am335x-evm.dtb; fi; " \ - "if test $board_name = A335X_SK; then " \ -@@ -160,12 +96,10 @@ - "echo Running uenvcmd ...;" \ - "run uenvcmd;" \ - "fi;" \ -- "if run loaduimage; then " \ -+ "if run loadimage; then " \ - "run loadfdt;" \ - "run mmcboot;" \ - "fi;" \ -- "else " \ -- "run nandboot;" \ - "fi;" \ - - /* Clock Defines */ -@@ -205,8 +139,6 @@ - #define CONFIG_DOS_PARTITION - #define CONFIG_CMD_FAT - #define CONFIG_FAT_WRITE --#define CONFIG_CMD_EXT2 --#define CONFIG_CMD_EXT4 - #define CONFIG_CMD_FS_GENERIC - - #define CONFIG_SPI -@@ -230,7 +162,6 @@ - /* USB Device Firmware Update support */ - #define CONFIG_DFU_FUNCTION - #define CONFIG_DFU_MMC --#define CONFIG_DFU_NAND - #define CONFIG_CMD_DFU - #define DFU_ALT_INFO_MMC \ - "boot part 0 1;" \ -@@ -240,14 +171,6 @@ - "u-boot.img.raw mmc 300 3C0;" \ - "u-boot.img fat 0 1;" \ - "uEnv.txt fat 0 1" --#define DFU_ALT_INFO_NAND \ -- "SPL part 0 1;" \ -- "SPL.backup1 part 0 2;" \ -- "SPL.backup2 part 0 3;" \ -- "SPL.backup3 part 0 4;" \ -- "u-boot part 0 5;" \ -- "kernel part 0 7;" \ -- "rootfs part 0 8" - - /* Physical Memory Map */ - #define CONFIG_NR_DRAM_BANKS 1 /* 1 bank of DRAM */ -@@ -313,7 +236,7 @@ - #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x300 /* address 0x60000 */ - #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x200 /* 256 KB */ - #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1 --#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img" -+#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "bb-uboot.img" - #define CONFIG_SPL_MMC_SUPPORT - #define CONFIG_SPL_FAT_SUPPORT - #define CONFIG_SPL_I2C_SUPPORT -@@ -323,51 +246,15 @@ - #define CONFIG_SPL_LIBGENERIC_SUPPORT - #define CONFIG_SPL_SERIAL_SUPPORT - #define CONFIG_SPL_GPIO_SUPPORT --#define CONFIG_SPL_YMODEM_SUPPORT --#define CONFIG_SPL_NET_SUPPORT --#define CONFIG_SPL_NET_VCI_STRING "AM335x U-Boot SPL" --#define CONFIG_SPL_ETH_SUPPORT - #define CONFIG_SPL_SPI_SUPPORT - #define CONFIG_SPL_SPI_FLASH_SUPPORT - #define CONFIG_SPL_SPI_LOAD - #define CONFIG_SPL_SPI_BUS 0 - #define CONFIG_SPL_SPI_CS 0 - #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x80000 --#define CONFIG_SPL_MUSB_NEW_SUPPORT - #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/am33xx/u-boot-spl.lds" - - #define CONFIG_SPL_BOARD_INIT --#define CONFIG_SPL_NAND_AM33XX_BCH --#define CONFIG_SPL_NAND_SUPPORT --#define CONFIG_SPL_NAND_BASE --#define CONFIG_SPL_NAND_DRIVERS --#define CONFIG_SPL_NAND_ECC --#define CONFIG_SYS_NAND_5_ADDR_CYCLE --#define CONFIG_SYS_NAND_PAGE_COUNT (CONFIG_SYS_NAND_BLOCK_SIZE / \ -- CONFIG_SYS_NAND_PAGE_SIZE) --#define CONFIG_SYS_NAND_PAGE_SIZE 2048 --#define CONFIG_SYS_NAND_OOBSIZE 64 --#define CONFIG_SYS_NAND_BLOCK_SIZE (128*1024) --#define CONFIG_SYS_NAND_BAD_BLOCK_POS NAND_LARGE_BADBLOCK_POS --#define CONFIG_SYS_NAND_ECCPOS { 2, 3, 4, 5, 6, 7, 8, 9, \ -- 10, 11, 12, 13, 14, 15, 16, 17, \ -- 18, 19, 20, 21, 22, 23, 24, 25, \ -- 26, 27, 28, 29, 30, 31, 32, 33, \ -- 34, 35, 36, 37, 38, 39, 40, 41, \ -- 42, 43, 44, 45, 46, 47, 48, 49, \ -- 50, 51, 52, 53, 54, 55, 56, 57, } -- --#define CONFIG_SYS_NAND_ECCSIZE 512 --#define CONFIG_SYS_NAND_ECCBYTES 14 -- --#define CONFIG_SYS_NAND_ECCSTEPS 4 --#define CONFIG_SYS_NAND_ECCTOTAL (CONFIG_SYS_NAND_ECCBYTES * \ -- CONFIG_SYS_NAND_ECCSTEPS) -- --#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_TEXT_BASE -- --#define CONFIG_SYS_NAND_U_BOOT_OFFS 0x80000 -- - /* - * 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM - * 64 bytes before this address should be set aside for u-boot.img's -@@ -462,7 +349,7 @@ - #define CONFIG_PHY_ADDR 0 - #define CONFIG_PHY_SMSC - --#define CONFIG_NAND -+#undef CONFIG_NAND - /* NAND support */ - #ifdef CONFIG_NAND - #define CONFIG_CMD_NAND --------------080405020601010403050600-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 10 03:06:17 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B23983B; Thu, 10 Apr 2014 03:06:17 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 690771624; Thu, 10 Apr 2014 03:06:16 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id b57so2443257eek.26 for ; Wed, 09 Apr 2014 20:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FLsUfaDiACULGueYWTYYN9fNUn/HRh6U9FuCPUxYa1w=; b=hqUI0KFFapD1FFEDJeijqOJ8PZD4bTfLyNx9gJmVoMcHznl6+zhRdil3DA71oB5Avg 1/UqUxEkErEDljoQ7TjdrFJToyrxgUxXiSD2+QLtYd1fBzHjpx0ipfh9fU5sXtK/NlbF SJYyodNyBe5A72YO4JIvu1hUg1BSXm8sRY+gV0Cvr8SHRxlU2lKjlwtIo9uhNYbsjlfA QG/HaG9hqA6kV78F/RzfJQJF+fWmaZ3fyWAISEHRSWxDbvjibxWBRMutyjtxY7yncrUC rDzsptnq3tqJbgM0LQ315RihiCGUMD7I2SylwQvYiEq5VN1kytBM3tN0Gw8MRkebyMg2 YxJw== X-Received: by 10.15.43.77 with SMTP id w53mr17008335eev.10.1397099174644; Wed, 09 Apr 2014 20:06:14 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id q41sm6535956eez.7.2014.04.09.20.05.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 20:06:13 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53460A6A.5080502@hot.ee> Date: Thu, 10 Apr 2014 06:05:14 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: BeagleBone Black: Increase CPU frequency from 800MHz to 1GHz References: <533CA68E.1020602@gmail.com> <1396487123.81853.274.camel@revolution.hippie.lan> In-Reply-To: <1396487123.81853.274.camel@revolution.hippie.lan> X-TagToolbar-Keys: D20140410060514305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 03:06:17 -0000 On 2014-04-03 04:05, Ian Lepore wrote: > On Thu, 2014-04-03 at 08:08 +0800, Xuebing Wang wrote: >> Hi community, >> >> I am working on a small project to increase AM335x Cortex-A8 MPU >> frequency from 800MHz to 1GHz. >> >> Would you please point to me which tree should I base my work on? Is it >> current? >> >> I did notice that there is "projects/armv6", svn log under sys/arm/ti >> shows the latest commit is "2012-08-15" >> > > Definitely use -current. That projects branch was where the initial > armv6 work was done long ago, but that was all merged to 10 and has now > evolved into 11-current. > > I think very many Beaglebone users will be interested in your work, > including me! > > -- Ian I worry that I might need heatsink on SoC when running 1GHz... I hope this thing has proper thermal downscaling or other means of protection. At 500MHz and under load, it's already too warm... the thing was sitting on table with SoC side up. The original idea of running it inside enclosed box doesn't seem so good anymore... From owner-freebsd-arm@FreeBSD.ORG Thu Apr 10 10:50:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA736287; Thu, 10 Apr 2014 10:50:02 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C6D012AB; Thu, 10 Apr 2014 10:50:01 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3AAnZdV060586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Apr 2014 12:49:35 +0200 (CEST) (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 s3AAnLeZ019024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Apr 2014 12:49:21 +0200 (CEST) (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 s3AAnLbM095802; Thu, 10 Apr 2014 12:49:21 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3AAnLLi095801; Thu, 10 Apr 2014 12:49:21 +0200 (CEST) (envelope-from ticso) Date: Thu, 10 Apr 2014 12:49:21 +0200 From: Bernd Walter To: Xuebing Wang Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 Message-ID: <20140410104921.GA95756@cicely7.cicely.de> References: <5345FEED.1040604@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5345FEED.1040604@gmail.com> 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.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 10:50:03 -0000 On Thu, Apr 10, 2014 at 10:16:13AM +0800, Xuebing Wang wrote: > The latest u-boot is 2014-01. > > With the latest u-boot, BeagleBone Black CPU runs at 1GHz. I run some > benchmark with "ubench -c -s", the number is increased from 5186 to 9588. > > Attached are the 3 patches for ports: sysutils/u-boot-beaglebone-eabi > > Thanks. > > > ================================================== > Current u-boot: > > U-Boot 2013.04 (Mar 24 2014 - 07:32:45) > > root@beaglebone:~ # ubench -c -s > Unix Benchmark Utility v.0.3 > FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263665: Mon Mar 24 > 07:27:38 UTC 2014 > root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE > arm > Ubench Single CPU: 5186 (0.40s) > > > ================================================== > u-boot-2014-01: > > root@beaglebone:~ # ubench -c -s > FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263665: Mon Mar 24 > 07:27:38 UTC 2014 > root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE > arm > Ubench Single CPU: 9588 (0.41s) That's a lot more than is expected when going from 800 to 1000MHz. Is there anything else different - e.g. cache settings? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Apr 10 12:28:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8758CE19; Thu, 10 Apr 2014 12:28:47 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56FB11BEE; Thu, 10 Apr 2014 12:28:47 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id kq14so3938485pab.10 for ; Thu, 10 Apr 2014 05:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TjDscVVAErMselikOH/D58bD7ioOenKlgfYsOt5xUeo=; b=ZJ2nVb8eWHmywjlXi/TNrFY2cllTi/vt6+5jAYW2emEZBXS17K2o22IIHHeSrsRvuj tgYS5GsjxCl2KwkdOEokNgSLVnh0YIiAO2LPaFLNZkbaxuHSaSOtHzsxa3RA/hvvNEPS rkypB9VmKfbHxThlmQtudfCxKQbEvkD2cLezcy3Gk5cR4KA4xckWn2NcCmoZtXkPCXhT zS8Pji+Pred/V6hl67BskY6tGXEUgimF/iMMRiJJcZw4LDCW1Jaldxibu+sIgqzc4C7W g3FS8sweyiF+oN27jhkyG2m0Fp3YwdnNXyY9WDTZlq27FGDHogzXaYH3pS2cjAXw2OET r4Yw== X-Received: by 10.68.239.70 with SMTP id vq6mr19134093pbc.152.1397132926967; Thu, 10 Apr 2014 05:28:46 -0700 (PDT) Received: from [216.131.71.98] ([216.131.71.98]) by mx.google.com with ESMTPSA id ff4sm20047613pad.24.2014.04.10.05.28.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 05:28:46 -0700 (PDT) Message-ID: <53468E7A.70309@gmail.com> Date: Thu, 10 Apr 2014 20:28:42 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ticso@cicely.de Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> In-Reply-To: <20140410104921.GA95756@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 12:28:47 -0000 On 04/10/2014 06:49 PM, Bernd Walter wrote: > That's a lot more than is expected when going from 800 to 1000MHz. > Is there anything else different - e.g. cache settings? I am not sure. In the current u-boot UART log, we see "WARNING: Caches not enabled". With the latest u-boot, there is no such warning. However, Kernel does print out below about cache: Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Thu Apr 10 14:02:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E30EF7A8 for ; Thu, 10 Apr 2014 14:02:22 +0000 (UTC) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6E901678 for ; Thu, 10 Apr 2014 14:02:22 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1WYFYa-00CDeU-Gv; Thu, 10 Apr 2014 16:02:20 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Ralf Wenk To: freebsd-arm@freebsd.org Subject: Re: screen(1) crashes plus weird output for screen -ls In-reply-to: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Apr 2014 16:02:20 +0200 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 14:02:22 -0000 Hi, the optimizations made by the current Clang seems to be the cause. Without optimization (-O0) =22screen -ls=22 shows the expected There is a screen on: 43597.pts-0.raspberry-pi (Detached) 1 Socket in /tmp/screens/S-root. With the first optimization level (-O1) I get There is a screen on: 43597.pts-0.raspberry-pi (Detached) 120984 Socket=F5=FF=BFl=E5 in . and with -O2 There is a screen on: 43597.pts-0.raspberry-pi (Detached) -1073746696 Socket =D0=A0=E1 in =F5=FF=BF8=E8. Ralf From owner-freebsd-arm@FreeBSD.ORG Thu Apr 10 14:41:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8354F58 for ; Thu, 10 Apr 2014 14:41:03 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8F2F19FA for ; Thu, 10 Apr 2014 14:41:03 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1WYGA2-0005yP-A2 for freebsd-arm@freebsd.org; Thu, 10 Apr 2014 07:41:02 -0700 Date: Thu, 10 Apr 2014 07:41:02 -0700 (PDT) From: RoBo To: freebsd-arm@freebsd.org Message-ID: <1397140862302-5902344.post@n5.nabble.com> In-Reply-To: <5282BCAE.1000707@m5p.com> References: <106622132.66623.1384225190003.JavaMail.mail@webmail07> <20131112073941.GA19103@mail.bsdpad.com> <52820D9C.8060707@m5p.com> <1384274735.31172.299.camel@revolution.hippie.lan> <5282BCAE.1000707@m5p.com> Subject: Re: FreeBSD on HardKernel's ODROID platform 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 14:41:04 -0000 Hello, Did anyone build a working FreeBSD image for Odroid? -- View this message in context: http://freebsd.1045724.n5.nabble.com/FreeBSD-on-HardKernel-s-ODROID-platform-tp5860429p5902344.html Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@FreeBSD.ORG Thu Apr 10 14:45:49 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD6921CD for ; Thu, 10 Apr 2014 14:45:49 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80E4E1A63 for ; Thu, 10 Apr 2014 14:45:49 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WYGEY-000Ln9-01; Thu, 10 Apr 2014 14:45:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3AEjd8w095278; Thu, 10 Apr 2014 08:45:39 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/vfvXQwd4hUfTI/Xk3ZJYD Subject: Re: BeagleBone Black: Increase CPU frequency from 800MHz to 1GHz From: Ian Lepore To: "Sulev-Madis Silber (ketas)" In-Reply-To: <53460A6A.5080502@hot.ee> References: <533CA68E.1020602@gmail.com> <1396487123.81853.274.camel@revolution.hippie.lan> <53460A6A.5080502@hot.ee> Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Apr 2014 08:45:39 -0600 Message-ID: <1397141139.1124.46.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, Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 14:45:49 -0000 On Thu, 2014-04-10 at 06:05 +0300, Sulev-Madis Silber (ketas) wrote: > On 2014-04-03 04:05, Ian Lepore wrote: > > On Thu, 2014-04-03 at 08:08 +0800, Xuebing Wang wrote: > >> Hi community, > >> > >> I am working on a small project to increase AM335x Cortex-A8 MPU > >> frequency from 800MHz to 1GHz. > >> > >> Would you please point to me which tree should I base my work on? Is it > >> current? > >> > >> I did notice that there is "projects/armv6", svn log under sys/arm/ti > >> shows the latest commit is "2012-08-15" > >> > > > > Definitely use -current. That projects branch was where the initial > > armv6 work was done long ago, but that was all merged to 10 and has now > > evolved into 11-current. > > > > I think very many Beaglebone users will be interested in your work, > > including me! > > > > -- Ian > > I worry that I might need heatsink on SoC when running 1GHz... I hope > this thing has proper thermal downscaling or other means of protection. > At 500MHz and under load, it's already too warm... the thing was sitting > on table with SoC side up. The original idea of running it inside > enclosed box doesn't seem so good anymore... On what basis are you declaring it "too warm"? Did you use an IR thermometer or something? The datasheet gives lifetime ratings with a junction temperature of 90c, I'll bet you're nowhere near that. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Apr 10 14:47:18 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9A39322 for ; Thu, 10 Apr 2014 14:47:18 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D22C1A86 for ; Thu, 10 Apr 2014 14:47:18 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WYGG5-0007Je-E3; Thu, 10 Apr 2014 14:47:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3AElEUO095284; Thu, 10 Apr 2014 08:47:14 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18HHefaqduqLr/9YETELQK+ Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 From: Ian Lepore To: Xuebing Wang In-Reply-To: <53468E7A.70309@gmail.com> References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> <53468E7A.70309@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Apr 2014 08:47:14 -0600 Message-ID: <1397141234.1124.47.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 14:47:18 -0000 On Thu, 2014-04-10 at 20:28 +0800, Xuebing Wang wrote: > On 04/10/2014 06:49 PM, Bernd Walter wrote: > > That's a lot more than is expected when going from 800 to 1000MHz. > > Is there anything else different - e.g. cache settings? > I am not sure. > > In the current u-boot UART log, we see "WARNING: Caches not enabled". > With the latest u-boot, there is no such warning. > > However, Kernel does print out below about cache: > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > The same thing happened in imx6 u-boot, the 2013.04 didnt' turn on caches, but 2014.01 does. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Apr 10 15:19:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DA54C9B for ; Thu, 10 Apr 2014 15:19:56 +0000 (UTC) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F7F61E60 for ; Thu, 10 Apr 2014 15:19:55 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id v10so4021951pde.29 for ; Thu, 10 Apr 2014 08:19:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ekZQ+Fh0goY5ZvnNjmSfv3OhAAqHrXzsPq8ZpIO8fkc=; b=VcaGp1TK9HPyodipWbwbhzSfvpIwxOyxF3pSidtl4YnGdz0KLetWFum/5YsSmD0IGz F4cfUEN65MUgYzLpWAcVOhWBK4IE7TOD5NeqcF7fzTSdqAiKojLex/SOqWq/TdTCAYlM aU0uK/oA4l/6/Z1UTjQ/vkVBLEbHwmEqZ35y5VdbsA7VkZGI8kvz0LxMCsOruGQd9fSU SNcgi3VUV+HsI1V8L83QbH565qRL9+ZwYaYurASmXkcXzP2KYgNs4r1KccQaaDq1fADh fpwZDadqAFrDIhT7I02USuAxHvYimY5cWL2bZ+sQciTNBYB+64rUgckhViiJqjNw+8Lg aayg== X-Gm-Message-State: ALoCoQlPKLB/H4IsMoCuL8xYlskiyH6CqCU8HW53/BCgmlympzyg6q1GsEokDAjXB1MsQo282/6U X-Received: by 10.66.184.239 with SMTP id ex15mr5452667pac.122.1397143189264; Thu, 10 Apr 2014 08:19:49 -0700 (PDT) Received: from [10.64.24.116] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id vg1sm9736536pbc.44.2014.04.10.08.19.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 08:19:48 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: screen(1) crashes plus weird output for screen -ls From: Warner Losh In-Reply-To: Date: Thu, 10 Apr 2014 09:19:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <18ADCE9C-C604-4067-B4D1-32EC07499231@bsdimp.com> References: To: Ralf Wenk X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 15:19:56 -0000 Is this with clang or gcc? Does the other compiler give different = results? Warner On Apr 10, 2014, at 8:02 AM, Ralf Wenk wrote: > Hi, >=20 > the optimizations made by the current Clang seems to be the cause. >=20 > Without optimization (-O0) "screen -ls" shows the expected >=20 > There is a screen on: > 43597.pts-0.raspberry-pi (Detached) > 1 Socket in /tmp/screens/S-root. >=20 > With the first optimization level (-O1) I get >=20 > There is a screen on: > 43597.pts-0.raspberry-pi (Detached) > 120984 Socket=F5=FF=BFl=E5 in . >=20 > and with -O2 >=20 > There is a screen on: > 43597.pts-0.raspberry-pi (Detached) > -1073746696 Socket > =D0 =E1 in =F5=FF=BF8=E8. >=20 >=20 > Ralf >=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 Thu Apr 10 21:00:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00B9148B for ; Thu, 10 Apr 2014 21:00:29 +0000 (UTC) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B74B1148A for ; Thu, 10 Apr 2014 21:00:29 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1WYM5D-008xD0-Oy; Thu, 10 Apr 2014 23:00:27 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Ralf Wenk To: Warner Losh Subject: Re: screen(1) crashes plus weird output for screen -ls In-reply-to: <18ADCE9C-C604-4067-B4D1-32EC07499231@bsdimp.com> References: <18ADCE9C-C604-4067-B4D1-32EC07499231@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Apr 2014 23:00:27 +0200 Message-Id: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 21:00:30 -0000 This is with clang. The release tag for kernel and world is r264192. =24 cc -v FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 Target: armv6--freebsd11.0-gnueabi Thread model: posix Selected GCC installation:=20 =24 I was not successful in compiling a gcc from the ports on armv6. ONLY_FOR_ARCHS prohibits it. After adding armv6 to the allowed architectures I ran into the binutils building problem mentioned here on the list. As I know too less about binutils my humble patches were not successful. Ralf > Is this with clang or gcc? Does the other compiler give different resul= ts? >=20 > Warner >=20 > On Apr 10, 2014, at 8:02 AM, Ralf Wenk wro= te: >=20 > > Hi, > >=20 > > the optimizations made by the current Clang seems to be the cause. > >=20 > > Without optimization (-O0) =22screen -ls=22 shows the expected > >=20 > > There is a screen on: > > 43597.pts-0.raspberry-pi (Detached) > > 1 Socket in /tmp/screens/S-root. > >=20 > > With the first optimization level (-O1) I get > >=20 > > There is a screen on: > > 43597.pts-0.raspberry-pi (Detached) > > 120984 Socket=F5=FF=BFl=E5 in . > >=20 > > and with -O2 > >=20 > > There is a screen on: > > 43597.pts-0.raspberry-pi (Detached) > > -1073746696 Socket > > =D0 =E1 in =F5=FF=BF8=E8. > >=20 > >=20 > > Ralf From owner-freebsd-arm@FreeBSD.ORG Thu Apr 10 22:43:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEACE916 for ; Thu, 10 Apr 2014 22:43:18 +0000 (UTC) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77A541D21 for ; Thu, 10 Apr 2014 22:43:18 +0000 (UTC) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.14.8/8.14.8) with ESMTP id s3AMhCCA080498; Fri, 11 Apr 2014 00:43:12 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: Ralf Wenk Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Fri, 11 Apr 2014 00:43:11 +0200 (CEST) Message-ID: <443afb9423c.5a6681a6@mail.schwarzes.net> In-Reply-To: References: <18ADCE9C-C604-4067-B4D1-32EC07499231@bsdimp.com> User-Agent: YAM/2.9 (MorphOS; PPC; rv:20131224r7420) Subject: Re: screen(1) crashes plus weird output for screen -ls MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Fri, 11 Apr 2014 00:43:13 +0200 (CEST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 22:43:18 -0000 On 10.04.14, Ralf Wenk wrote: > I was not successful in compiling a gcc from the ports on armv6. > ONLY_FOR_ARCHS prohibits it. After adding armv6 to the allowed > architectures I ran into the binutils building problem mentioned > here on the list. As I know too less about binutils my humble patches > were not successful. The legacy standard freebsd gcc is still included in the source tree, you can use the WITH_GCC/WITH_GNUCXX options in scr.conf when building and installing world. Andreas From owner-freebsd-arm@FreeBSD.ORG Fri Apr 11 10:15:13 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44210D0F for ; Fri, 11 Apr 2014 10:15:13 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D29AB1332 for ; Fri, 11 Apr 2014 10:15:12 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id t61so5209310wes.3 for ; Fri, 11 Apr 2014 03:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=RBEaKazbNhs2w1U2iKmCquwRcXxHjHPuLe6EEATMexI=; b=B49f/jvrFuDWbGIOFEcPA2HZK7qOYAq7dbh5ciu86HjEBoW1dRrqH/L+EZCbcSlarv YFHjlZ1ORdP/MjWwBoezhU8neGjwttZaMJQNIrjlR2Nmi6qpZLyXjoSVSgjcTFNWdlX6 hCGRzeW/AjkVM93Imge4ceqx0fAiivp3mmps1pF/8Ub/GzcLLOkIjHuLv9SSAWALGN4B UCg2+ScN/aexMvNISbP9j2AoA4KIRmf8g5xTVFkFxsH4deU9qGCkYifWj/wBisDJwARH 8FjsxRbacrH5uBh2mhIUVNSQAeCR/66k0wMDHcDujW/W2tB/tCBPCK9WBrqHpQsJC0T2 95qA== X-Received: by 10.194.110.100 with SMTP id hz4mr8038266wjb.50.1397211311037; Fri, 11 Apr 2014 03:15:11 -0700 (PDT) Received: from [0.0.0.0] (log77-7-88-185-146-198.fbx.proxad.net. [88.185.146.198]) by mx.google.com with ESMTPSA id ga10sm10638245wjb.23.2014.04.11.03.15.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 03:15:09 -0700 (PDT) Message-ID: <5347C0AB.1080808@gmail.com> Date: Fri, 11 Apr 2014 12:15:07 +0200 From: Nico User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: arm@freebsd.org Subject: libgcrypt 1.5.3 patch problem 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.17 Precedence: list Reply-To: nmatringe@gmail.com List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 10:15:13 -0000 Hello This may be trivial but I'm at a loss (newbie/not a software guy inside) I have applied this patch http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-September/261533.html but it was designed for version 1.5.2 and it doesn't seem to work with 1.5.3 : it patches ok but then the patched patch-mpi-longlong.h doesn't work anymore (patch errors) root@beaglebone:/usr/ports/security/libgcrypt # make install ===> License GPLv2 LGPL21 accepted by the user ===> libgcrypt-1.5.3_1 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by libgcrypt-1.5.3_1 for building ===> Extracting for libgcrypt-1.5.3_1 => SHA256 Checksum OK for libgcrypt-1.5.3.tar.bz2. ===> Patching for libgcrypt-1.5.3_1 ===> Applying FreeBSD patches for libgcrypt-1.5.3_1 3 out of 5 hunks failed--saving rejects to ./mpi/longlong.h.rej => Patch patch-mpi-longlong.h failed to apply cleanly. => Patch(es) patch-cipher-rijndael.c patch-mpi-config.links applied cleanly. *** Error code 1 Stop. make: stopped in /usr/ports/security/libgcrypt System is FreeBSD beaglebone 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Fri Jan 31 18:38:40 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm Has anyone experienced the same problem, or managed to successfuly build ? Thanks Nicolas From owner-freebsd-arm@FreeBSD.ORG Sat Apr 12 13:10:01 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC06A645 for ; Sat, 12 Apr 2014 13:10:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4A4515AF for ; Sat, 12 Apr 2014 13:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3CDA17E056002 for ; Sat, 12 Apr 2014 13:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3CDA1sw056001; Sat, 12 Apr 2014 13:10:01 GMT (envelope-from gnats) Resent-Date: Sat, 12 Apr 2014 13:10:01 GMT Resent-Message-Id: <201404121310.s3CDA1sw056001@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, Guy Yur Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5586244C for ; Sat, 12 Apr 2014 13:04:06 +0000 (UTC) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4A1A1562 for ; Sat, 12 Apr 2014 13:04:05 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id t10so5010322eei.14 for ; Sat, 12 Apr 2014 06:04:03 -0700 (PDT) Received: from vm2.localdomain ([31.210.185.47]) by mx.google.com with ESMTPSA id o4sm25266726eef.20.2014.04.12.06.04.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Apr 2014 06:04:02 -0700 (PDT) Received: by vm2.localdomain (sSMTP sendmail emulation); Sat, 12 Apr 2014 16:03:38 +0300 Message-Id: <534939c2.045f0e0a.59a8.ffff808b@mx.google.com> Date: Sat, 12 Apr 2014 16:03:38 +0300 From: Guy Yur To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.114 Subject: arm/188510: [patch] "rtadvctl show" crashes on BeagleBone Black due to unaligned access X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Guy Yur List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 13:10:01 -0000 >Number: 188510 >Category: arm >Synopsis: [patch] "rtadvctl show" crashes on BeagleBone Black due to unaligned access >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Apr 12 13:10:01 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Guy Yur >Release: FreeBSD 11.0-CURRENT arm.armv6 >Organization: >Environment: System: FreeBSD bbb-router.localdomain 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r264364M: Sat Apr 12 14:23:46 IDT 2014 root@vm4.localdomain:/usr/obj/arm.armv6/usr/src/sys/BBB-ROUTER arm >Description: "rtadvctl show" core dumps on Bus error when run on BeagleBone Black. (gdb) bt #0 cm_pl2bin (str=, cp=) at /usr/src/usr.sbin/rtadvctl/../rtadvd/control.c:458 #1 0x0000a59c in action_plgeneric (action=, plstr=, buf=0xbfffcd6c "\001") at /usr/src/usr.sbin/rtadvctl/rtadvctl.c:264 #2 0x0000a3c8 in action_propget (argv=0xbffff2d1 "", cp=0xbfffedf0) at /usr/src/usr.sbin/rtadvctl/rtadvctl.c:285 #3 0x00009354 in action_show (argc=, argv=) at /usr/src/usr.sbin/rtadvctl/rtadvctl.c:432 #4 0x00009184 in main (argc=, argv=0xbffff2d1) at /usr/src/usr.sbin/rtadvctl/rtadvctl.c:187 #5 0x00008fdc in __start (argc=2, argv=0xbffffb98, env=0xbffffba4, ps_strings=, obj=0x2003c000, cleanup=) at /usr/src/lib/csu/arm/crt1.c:115 #6 0x2001fd3c in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 #7 0x2001fd3c in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 Current language: auto; currently minimal disassembly: 0x0000b0c4 : str r0, [r8] info registers: ... r8 0xbfffcd87 -1073754745 ... pc 0xb0c4 45252 The protocol between rtadvd and rtadvctl writes a size_t len followed by a string for each of ifname, key and value. When ifname or key is supplied and their length is not a multiple of 4 the write of the next field size_t len will be to an unaligned address and a trap will be generated on the BeagleBone Black. >How-To-Repeat: Run "rtadvctl show" on an arm machine with trapping for unaligned access enabled. >Fix: Attached two patches with different ways to resolve the problem. 1. rtadvd_control_align.patch Round up the strings to align on sizeof(size_t). Is there a round up macro that can be used instead of explicit calculation? Requires using matching rtadvd and rtadvctl since the protocol changed. 2. rtadvd_control_packed.patch Use __packed structure access for the size_t len so byte instructions will be used to read/write the len on arm. Protocol doesn't change so compatibility between old and fixed rtadvd and rtadvctl is kept. --- rtadvd_control_align.patch begins here --- Index: usr.sbin/rtadvd/control.c =================================================================== --- usr.sbin/rtadvd/control.c (revision 264366) +++ usr.sbin/rtadvd/control.c (working copy) @@ -362,7 +362,7 @@ cm_bin2pl(char *str, struct ctrl_msg_pl *cp) } memcpy(cp->cp_ifname, p, len); cp->cp_ifname[len] = '\0'; - p += len; + p += (len + sizeof(size_t)) & ~(sizeof(size_t) - 1); } lenp = (size_t *)p; @@ -377,7 +377,7 @@ cm_bin2pl(char *str, struct ctrl_msg_pl *cp) } memcpy(cp->cp_key, p, len); cp->cp_key[len] = '\0'; - p += len; + p += (len + sizeof(size_t)) & ~(sizeof(size_t) - 1); } lenp = (size_t *)p; @@ -402,20 +402,26 @@ cm_bin2pl(char *str, struct ctrl_msg_pl *cp) size_t cm_pl2bin(char *str, struct ctrl_msg_pl *cp) { - size_t len; + size_t len, ifname_len, key_len, val_len; size_t *lenp; char *p; struct ctrl_msg_hdr *cm; len = sizeof(size_t); - if (cp->cp_ifname != NULL) - len += strlen(cp->cp_ifname); + if (cp->cp_ifname != NULL) { + ifname_len = strlen(cp->cp_ifname); + len += (ifname_len + sizeof(size_t)) & ~(sizeof(size_t) - 1); + } len += sizeof(size_t); - if (cp->cp_key != NULL) - len += strlen(cp->cp_key); + if (cp->cp_key != NULL) { + key_len = strlen(cp->cp_key); + len += (key_len + sizeof(size_t)) & ~(sizeof(size_t) - 1); + } len += sizeof(size_t); - if (cp->cp_val != NULL && cp->cp_val_len > 0) - len += cp->cp_val_len; + if (cp->cp_val != NULL && cp->cp_val_len > 0) { + val_len = cp->cp_val_len; + len += (val_len + sizeof(size_t)) & ~(sizeof(size_t) - 1); + } if (len > CM_MSG_MAXLEN - sizeof(*cm)) { syslog(LOG_DEBUG, "<%s> msg too long (len=%zu)", @@ -426,36 +432,36 @@ cm_pl2bin(char *str, struct ctrl_msg_pl *cp) memset(str, 0, len); p = str; lenp = (size_t *)p; - + if (cp->cp_ifname != NULL) { - *lenp++ = strlen(cp->cp_ifname); + *lenp++ = ifname_len; p = (char *)lenp; - memcpy(p, cp->cp_ifname, strlen(cp->cp_ifname)); - p += strlen(cp->cp_ifname); + memcpy(p, cp->cp_ifname, ifname_len); + p += (ifname_len + sizeof(size_t)) & ~(sizeof(size_t) - 1); } else { - *lenp++ = '\0'; + *lenp++ = 0; p = (char *)lenp; } lenp = (size_t *)p; if (cp->cp_key != NULL) { - *lenp++ = strlen(cp->cp_key); + *lenp++ = key_len; p = (char *)lenp; - memcpy(p, cp->cp_key, strlen(cp->cp_key)); - p += strlen(cp->cp_key); + memcpy(p, cp->cp_key, key_len); + p += (key_len + sizeof(size_t)) & ~(sizeof(size_t) - 1); } else { - *lenp++ = '\0'; + *lenp++ = 0; p = (char *)lenp; } lenp = (size_t *)p; if (cp->cp_val != NULL && cp->cp_val_len > 0) { - *lenp++ = cp->cp_val_len; + *lenp++ = val_len; p = (char *)lenp; - memcpy(p, cp->cp_val, cp->cp_val_len); - p += cp->cp_val_len; + memcpy(p, cp->cp_val, val_len); + p += (val_len + sizeof(size_t)) & ~(sizeof(size_t) - 1); } else { - *lenp++ = '\0'; + *lenp++ = 0; p = (char *)lenp; } --- rtadvd_control_align.patch ends here --- --- rtadvd_control_packed.patch begins here --- Index: usr.sbin/rtadvd/control.c =================================================================== --- usr.sbin/rtadvd/control.c (revision 264366) +++ usr.sbin/rtadvd/control.c (working copy) @@ -343,7 +343,10 @@ struct ctrl_msg_pl * cm_bin2pl(char *str, struct ctrl_msg_pl *cp) { size_t len; - size_t *lenp; + struct unaligned_len { + size_t len; + } __packed; + struct unaligned_len *lenp; char *p; memset(cp, 0, sizeof(*cp)); @@ -350,9 +353,9 @@ cm_bin2pl(char *str, struct ctrl_msg_pl *cp) p = str; - lenp = (size_t *)p; - len = *lenp++; - p = (char *)lenp; + lenp = (struct unaligned_len *)p; + len = lenp->len; + p = (char *)(lenp + 1); syslog(LOG_DEBUG, "<%s> len(ifname) = %zu", __func__, len); if (len > 0) { cp->cp_ifname = malloc(len + 1); @@ -365,9 +368,9 @@ cm_bin2pl(char *str, struct ctrl_msg_pl *cp) p += len; } - lenp = (size_t *)p; - len = *lenp++; - p = (char *)lenp; + lenp = (struct unaligned_len *)p; + len = lenp->len; + p = (char *)(lenp + 1); syslog(LOG_DEBUG, "<%s> len(key) = %zu", __func__, len); if (len > 0) { cp->cp_key = malloc(len + 1); @@ -380,9 +383,9 @@ cm_bin2pl(char *str, struct ctrl_msg_pl *cp) p += len; } - lenp = (size_t *)p; - len = *lenp++; - p = (char *)lenp; + lenp = (struct unaligned_len *)p; + len = lenp->len; + p = (char *)(lenp + 1); syslog(LOG_DEBUG, "<%s> len(val) = %zu", __func__, len); if (len > 0) { cp->cp_val = malloc(len + 1); @@ -403,7 +406,10 @@ size_t cm_pl2bin(char *str, struct ctrl_msg_pl *cp) { size_t len; - size_t *lenp; + struct unaligned_len { + size_t len; + } __packed; + struct unaligned_len *lenp; char *p; struct ctrl_msg_hdr *cm; @@ -425,38 +431,38 @@ cm_pl2bin(char *str, struct ctrl_msg_pl *cp) syslog(LOG_DEBUG, "<%s> msglen=%zu", __func__, len); memset(str, 0, len); p = str; - lenp = (size_t *)p; - + lenp = (struct unaligned_len *)p; + if (cp->cp_ifname != NULL) { - *lenp++ = strlen(cp->cp_ifname); - p = (char *)lenp; + lenp->len = strlen(cp->cp_ifname); + p = (char *)(lenp + 1); memcpy(p, cp->cp_ifname, strlen(cp->cp_ifname)); p += strlen(cp->cp_ifname); } else { - *lenp++ = '\0'; - p = (char *)lenp; + lenp->len = 0; + p = (char *)(lenp + 1); } - lenp = (size_t *)p; + lenp = (struct unaligned_len *)p; if (cp->cp_key != NULL) { - *lenp++ = strlen(cp->cp_key); - p = (char *)lenp; + lenp->len = strlen(cp->cp_key); + p = (char *)(lenp + 1); memcpy(p, cp->cp_key, strlen(cp->cp_key)); p += strlen(cp->cp_key); } else { - *lenp++ = '\0'; - p = (char *)lenp; + lenp->len = 0; + p = (char *)(lenp + 1); } - lenp = (size_t *)p; + lenp = (struct unaligned_len *)p; if (cp->cp_val != NULL && cp->cp_val_len > 0) { - *lenp++ = cp->cp_val_len; - p = (char *)lenp; + lenp->len = cp->cp_val_len; + p = (char *)(lenp + 1); memcpy(p, cp->cp_val, cp->cp_val_len); p += cp->cp_val_len; } else { - *lenp++ = '\0'; - p = (char *)lenp; + lenp->len = 0; + p = (char *)(lenp + 1); } return (len); --- rtadvd_control_packed.patch ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Sat Apr 12 19:04:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 977AF5C1 for ; Sat, 12 Apr 2014 19:04:54 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76EC41588 for ; Sat, 12 Apr 2014 19:04:53 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s3CJ4l8u045451; Sat, 12 Apr 2014 19:04:47 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id yiqwgv347hukhjtxutgfcjq5jn; Sat, 12 Apr 2014 19:04:47 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [BeagleBone Black Test PATCH 0/2] port latest u-boot From: Tim Kientzle In-Reply-To: <1396962361.81853.409.camel@revolution.hippie.lan> Date: Sat, 12 Apr 2014 12:04:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <58844C09-01AD-4739-B865-C8E5FA24F9C1@freebsd.org> References: <1396862732-4961-1-git-send-email-xbing6@gmail.com> <1396962361.81853.409.camel@revolution.hippie.lan> To: Xuebing Wang X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 19:04:54 -0000 On Apr 8, 2014, at 6:06 AM, Ian Lepore wrote: > On Mon, 2014-04-07 at 18:41 -0700, Tim Kientzle wrote: >> On Apr 7, 2014, at 2:25 AM, Xuebing Wang wrote: >>=20 >>> Hi Tim and all, >>>=20 >>> This is for discussion only. Would you please advice? >>>=20 >>> This is motivated by trying to increase CPU frequency for BeagleBone = Black. >>>=20 >>> AM335x cpufreq is not supported yet. In order to achieve the goal to = increase >>> CPU freq, I am thinking of a 2-step approach: >>> 1) port latest u-boot, which have cpufreq better organized >>> 2) tweak u-boot opp/freq later >>=20 >> Setting the processor frequency after the OS is running >> is not difficult. The AM335x TRM shows exactly how to do it. >>=20 >> I would not change U-Boot but rather implement >> a FreeBSD driver that exposed a read/write sysctl >> to reprogram the CPU frequency. >>=20 >> Getting powerd to work with this should be straightforward. >>=20 >> Tim >>=20 >=20 > I agree with this, we should handle the frequency change in the kernel > rather than in u-boot. I don't have time to work on this right now, but I found some old code I wrote -- from back before FreeBSD was running on BeagleBone and I was experimenting with standalone code -- to set the MPU PLL. The following implements the sequence described in 8.1.6.9.1 of the AM335x TRM (www.ti.com/lit/ug/spruh73j/spruh73j.pdf=E2=80=8E) to set the CPU frequency: #define CM_WKUP(offset) \ ((volatile int32_t *)(((volatile char *)0x44e00400) + (offset))) void mpu_pll(void) { int desired =3D 500; /* 500 MHz requested */ int input_clk =3D 24; /* BeagleBone uses 24MHz master crystal */ int output_divider =3D 2; /* Range: 1 - 31 */ int input_divider =3D 24; /* Range: 1 - 128 */ int multiplier =3D desired * output_divider * input_divider / = input_clk; /* Range: 2 - 2047 */ *CM_WKUP(0x88) =3D 4; /* MPU PLL to bypass mode */ while ((*CM_WKUP(0x20) & 0x100) =3D=3D 0) /* Wait for bypass = mode. */ ; *CM_WKUP(0x2C) =3D (multiplier << 8) | (input_divider - 1); *CM_WKUP(0xA8) =3D output_divider; /* Set "M2 divider" */ *CM_WKUP(0x88) =3D 7; /* MPU PLL to lock mode */ while ((*CM_WKUP(0x20) & 1) =3D=3D 1) /* Wait for MPU PLL to = lock. */ ; /* Final result =3D input_clk * multiplier / input_divider / = output_divider */ } Of course, in the kernel, this would have to first set up the proper memory mapping to access the registers. I believe this is the foundation for an AM335x cpufreq driver that would allow powerd to dynamically adjust the CPU frequency, providing both low power when the system is idle and good performance when needed. Cheers, Tim P.S. Apparently, the M2 output divider can be changed on-the-fly without forcing the PLL into bypass mode and back. That may be more appropriate for handling the dev.cpu.0.freq sysctl. (That is, set the multiplier to 2000 and the input_divider to 24. Then output dividers of 2, 3, 4, 10, 31 give 1000MHz, 667MHz, 500MHz, 200MHz, 65MHz.) P.P.S. I have some comments in my original code that BeagleBone (White) needs to keep the clock below 500MHz when running from USB power instead of AC. Don't know if that's relevant for BBB or not. From owner-freebsd-arm@FreeBSD.ORG Mon Apr 14 11:06:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 270ACE6D for ; Mon, 14 Apr 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC824164F for ; Mon, 14 Apr 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3EB6fcP025803 for ; Mon, 14 Apr 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3EB6frI025801 for freebsd-arm@FreeBSD.org; Mon, 14 Apr 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Apr 2014 11:06:41 GMT Message-Id: <201404141106.s3EB6frI025801@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 11:06:42 -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/188510 arm [patch] "rtadvctl show" crashes on BeagleBone Black du o arm/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o ports/175605 arm devel/binutils: please fix build binutils-2.23.1 in ra 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 ports/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) 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 33 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Apr 14 16:15:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B1AC7DE; Mon, 14 Apr 2014 16:15:29 +0000 (UTC) Received: from mail.machdep.com (mail.machdep.com [195.91.211.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E4D5D1A59; Mon, 14 Apr 2014 16:15:28 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=machdep.com) by mail.machdep.com with smtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WZjWf-0003ab-VK; Mon, 14 Apr 2014 20:14:30 +0400 Received: by machdep.com (nbSMTP-1.00) for uid 1001 br@machdep.com; Mon, 14 Apr 2014 20:14:29 +0400 (MSK) Date: Mon, 14 Apr 2014 20:14:29 +0400 From: Ruslan Bukin To: Jakub Klama Subject: Re: [RFC] Refactored interrupt handling on ARM Message-ID: <20140414161429.GA13727@machdep.com> References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <53418D13.7030107@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:15:29 -0000 On Sun, Apr 06, 2014 at 07:21:23PM +0200, Jakub Klama wrote: > What do you think about that? That code probably needs some > improvements, especially in IPI/SMP area, but I think it's a step > further in interrupt handling on ARM. This is exactly I looked for a month ago, when I was porting keyboard for chromebook. Keyboard depends on Chrome Embedded Controller (EC), which provides external gpio interrupt, and the overall interrupt controllers on exynos tree looks like: nexus0 (1 irq) | \--gic0 (160 irq) | \--combiner0 (32 groups, 8 irq per group at max) | \--gpio0 (205 irq) | \-- Chrome EC Keyboard So seems supporting standard exynos DTS from samsung becomes easier now. thanks. -Ruslan From owner-freebsd-arm@FreeBSD.ORG Mon Apr 14 16:39:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9D8EC96 for ; Mon, 14 Apr 2014 16:39:47 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9349D1CBA for ; Mon, 14 Apr 2014 16:39:47 +0000 (UTC) Received: from zeppelin.tachypleus.net ([128.135.100.106]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s3EGdcYZ021636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 14 Apr 2014 09:39:39 -0700 Message-ID: <534C0F48.2090302@freebsd.org> Date: Mon, 14 Apr 2014 09:39:36 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: [RFC] Refactored interrupt handling on ARM References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> In-Reply-To: <53418D13.7030107@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;wofOXvPD4xGrq5xB+Bh/TQ== M;TOpoX/PD4xGrq5xB+Bh/TQ== X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:39:47 -0000 This is really nice! One quick question: why have you made FDT_MAP_IRQ() a public interface? Shouldn't calling the function it maps to just be a private implementation detail in nexus? -Nathan On 04/06/14 10:21, Jakub Klama wrote: > Hello all, > > It has been a long time since my SoC 2012 ended. However, I've finally > merged refactored interrupt handling framework to head and added SMP > support (IPIs). Let's start: > > What is this and how does it work? > > It's a refactored interrupt handling code for ARM which supports > multiple, stacked interrupt controllers. In particular, it creates a > clean way to support IRQ multiplexers such as GPIO controllers with > interrupt generation functionality. Approach used in this code is > somewhat similar to one usedin powerpc port. > > Every interrupt controller should implement methods from pic_if.m > interface - at least pic_config, pic_unmask, pic_mask and pic_eoi. It > should also install IRQ handler on parent interrupt controller > (specified by interrupt-parent in FDT, defaulting to nexus). > > The root interrupt controller is nexus - on ARM it has exactly one IRQ > line (typically nexus0:0) representing core IRQ signal (on MIPS, there > will be probably five of them). SoC interrupt controller, such as GIC > then installs handler on nexus0:0 IRQ and exposes itself as interrupt > controller by calling arm_register_pic(). When the interrupt arrives, > pic driver calls arm_dispatch_irq() function. > > So, for example, a typical SoC interrupt tree can look like that: > > nexus0 (provides 1 irq) > | > \-- gic0 (provides 160 irqs, uses irq nexus0:0) > | > \-- gpio0 (provides 8 irqs, uses irq gic0:42) > | | > | \-- mmcsd0 (uses irqs gpio0:1, gpio0:2) > | \-- spi0 (uses irq gpio0:3) > | ... > \-- gpio1 (provides 8 irqs, uses irq gic0:43) > \-- ehci0 (uses irq gic0:109) > ... > > Interrupt numbers used in rman are composed of two 8-bit fields: higher > 8 bits are the pic index and lower 8 bits are IRQ line number inside > particular pic (so there are 256 pics supported with maximum of 256 > irq lines on each). These numbers are generated using FDT_MAP_IRQ() > macro called from FDT code. > > As you can see from the provided dmesg logs, irq numbers are printed in > form of "pic_name:line_number", i.e: "nexus0:0" or "gic0:109". > > Of course there's still support for shared interrupt handlers - on > LPC3250 there are 3 pics attached to one in-core IRQ line. > > There's also support for IPIs. Calls to pic_ipi_get(), pic_ipi_clear(), > pic_ipi_send() and ..._init_secondary() are redirected to one interrupt > controller registered as capable to do IPIs. There can be only one > interrupt controller with IPI support registered (and certainly not the > root one). > > Code was tested on following platforms: > * EA3250 (arm/lpc) > * Pandaboard (arm/ti) (both with SMP enabled and disabled) > > Merging it would not require any changes in existing ARM ports (unless > they will be adopted to new framework and will have ARM_INTRNG option > enabled), except for adding arm/arm/intr.c to their file lists (as it's > now not compiled-in by default). That was tested too. > > dmesg outputs can be found there: > * http://people.freebsd.org/~jceel/intrng/pandaboard.dmesg.txt > * http://people.freebsd.org/~jceel/intrng/ea3250.dmesg.txt > > diff against head as of r264192: > * http://people.freebsd.org/~jceel/intrng/intrng.diff > > git branch containing the changes: > * https://github.com/jceel/freebsd-arm-intrng/tree/intrng > > What do you think about that? That code probably needs some > improvements, especially in IPI/SMP area, but I think it's a step > further in interrupt handling on ARM. > > I really appreciate any comments and opinions. > > Regards, > Jakub > _______________________________________________ > 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 Apr 14 19:16:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F25C213C for ; Mon, 14 Apr 2014 19:16:50 +0000 (UTC) Received: from mail2.etsms.com (Mail2.etsms.com [107.1.132.102]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "Cisco Appliance Demo Certificate", Issuer "Cisco Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 898B010B0 for ; Mon, 14 Apr 2014 19:16:50 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.97,858,1389762000"; d="scan'208,217";a="1251692" Received: from unknown (HELO XCGSTRVA001.etsms.com) ([192.168.2.15]) by mail2.etsms.com with ESMTP/TLS/AES128-SHA; 14 Apr 2014 15:15:40 -0400 Received: from XCGSTRVA002.etsms.com ([fe80::95c6:6492:6e57:8b9d]) by XCGSTRVA001.etsms.com ([fe80::f53e:fd57:a674:b792%16]) with mapi id 14.01.0438.000; Mon, 14 Apr 2014 15:15:40 -0400 From: Network Operations To: "freebsd-arm@freebsd.org" Subject: freebsd-arm@freebsd.org Thread-Topic: freebsd-arm@freebsd.org Thread-Index: Ac9YFemkNG3T8OMcSt2cYp+jVxPaag== Date: Mon, 14 Apr 2014 19:16:26 +0000 Message-ID: <7E55C7FCF9907D41AD6373EADC4FE76D5D2BABC3@XCGSTRVA002.etsms.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.16] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:16:51 -0000 freebsd-arm@freebsd.org From owner-freebsd-arm@FreeBSD.ORG Mon Apr 14 20:34:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35147770 for ; Mon, 14 Apr 2014 20:34:13 +0000 (UTC) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA35817EE for ; Mon, 14 Apr 2014 20:34:12 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1WZnZx-004VDY-U1; Mon, 14 Apr 2014 22:34:09 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Ralf Wenk To: Andreas Schwarz Subject: Re: screen(1) crashes plus weird output for screen -ls In-reply-to: <443afb9423c.5a6681a6@mail.schwarzes.net> References: <18ADCE9C-C604-4067-B4D1-32EC07499231@bsdimp.com> <443afb9423c.5a6681a6@mail.schwarzes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Apr 2014 22:34:09 +0200 Message-Id: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:34:13 -0000 Andreas Schwarz wrote: > On 10.04.14, Ralf Wenk wrote: >=20 > > I was not successful in compiling a gcc from the ports on armv6. > > ONLY_FOR_ARCHS prohibits it. =5B...=5D >=20 > The legacy standard freebsd gcc is still included in the source tree, y= ou can use the=20 > WITH_GCC/WITH_GNUCXX options in scr.conf when building and installing w= orld. I had some minor trouble to get it going. Adding both options terminates the build here with -- gnu/lib/libsupc++__L --- /root/rpi/head/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_= arm.cc :44:1: error: functions that differ only in their return type cannot be=20 overloaded __cxa_type_match(_Unwind_Exception* ue_header, =5E Just setting WITH_GCC got me finally a successful build. Now back to the problem with screen on arm. Compiling screen with gcc instead of clang using the standard optimizatio= n (-O) results in a correct working screen as =22screen -ls=22 prints There is a screen on: 3164.pts-2.raspberry-pi (Detached) 1 Socket in /tmp/screens/S-pi. while a fresh with clang -O compiled screen prints There is a screen on: 3164.pts-2.raspberry-pi (Detached) -1073746600 Socket =D0=A0=E1 in =F0=F5=FF=BF8=E8. Compiling screen with clang -O0 results in the same output as gcc. I think this supports my idea of suspecting the clang optimizations. The gcc used is =24 gcc -v Using built-in specs. Target: armv6-undermydesk-freebsd Configured with: FreeBSD/armv6 system compiler Thread model: posix gcc version 4.2.1 20070831 patched =5BFreeBSD=5D =24 Ralf From owner-freebsd-arm@FreeBSD.ORG Mon Apr 14 20:58:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F00E265 for ; Mon, 14 Apr 2014 20:58:45 +0000 (UTC) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id 4D2331A75 for ; Mon, 14 Apr 2014 20:58:45 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N41002K0GXPA020@mta.uoks.uj.edu.pl> for freebsd-arm@freebsd.org; Mon, 14 Apr 2014 22:58:37 +0200 (CEST) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.2 X-Antivirus-Code: 0x100000 Received: from mbox.uj.edu.pl by saiph.uoks.uj.edu.pl (Dr.Web (R) milter module ver.6.0.2.2) ; Mon, 14 Apr 2014 22:58:37 +0200 Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl with ESMTP; Mon, 14 Apr 2014 22:58:37 +0200 (CEST) Date: Mon, 14 Apr 2014 22:58:37 +0200 From: Jakub Klama In-reply-to: <534C0F48.2090302@freebsd.org> Message-id: References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> Subject: Re: [RFC] Refactored interrupt handling on ARM To: freebsd-arm@freebsd.org User-Agent: Roundcube Webmail/0.5 X-Sender: jakub.klama@uj.edu.pl X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:58:45 -0000 On Mon, 14 Apr 2014 09:39:36 -0700, Nathan Whitehorn wrote: > This is really nice! One quick question: why have you made > FDT_MAP_IRQ() a public interface? Shouldn't calling the function it > maps to just be a private implementation detail in nexus? > -Nathan Well, FDT_MAP_IRQ() existed before my changes and was public. It just returned pin and discarded the node parameter: #define FDT_MAP_IRQ(node, pin) (pin) so I left it as is and changed the implementation to route IRQ to parent IC. Jakub From owner-freebsd-arm@FreeBSD.ORG Mon Apr 14 22:00:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F893B66 for ; Mon, 14 Apr 2014 22:00:15 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 089C31221 for ; Mon, 14 Apr 2014 22:00:14 +0000 (UTC) Received: from zeppelin.tachypleus.net ([128.135.100.107]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s3EM0B8E015938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 15:00:12 -0700 Message-ID: <534C5A6A.1090707@freebsd.org> Date: Mon, 14 Apr 2014 15:00:10 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jakub Klama , freebsd-arm@freebsd.org Subject: Re: [RFC] Refactored interrupt handling on ARM References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;DJq5JiDE4xG3KpxB+Bh/TQ== M;PPETJyDE4xG3KpxB+Bh/TQ== X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:00:15 -0000 On 04/14/14 13:58, Jakub Klama wrote: > On Mon, 14 Apr 2014 09:39:36 -0700, Nathan Whitehorn wrote: >> This is really nice! One quick question: why have you made >> FDT_MAP_IRQ() a public interface? Shouldn't calling the function it >> maps to just be a private implementation detail in nexus? >> -Nathan > > Well, FDT_MAP_IRQ() existed before my changes and was public. It just > returned pin and discarded the node parameter: > > #define FDT_MAP_IRQ(node, pin) (pin) > > so I left it as is and changed the implementation to route IRQ to > parent IC. > > I had deliberately made it private with the last round of interrupt changes. The idea was to rely completely on newbus for interrupt mapping. Having a public interface allows code to bypass the bus hierarchy, which usually isn't a good thing. This ended up happening all over the place on PowerPC, for example. This made a lot of drivers less MI than they should have been and took a lot of time to get rid of. -Nathan From owner-freebsd-arm@FreeBSD.ORG Mon Apr 14 22:44:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5ECC0573; Mon, 14 Apr 2014 22:44:14 +0000 (UTC) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id 1B60516C2; Mon, 14 Apr 2014 22:44:13 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N41002BGLTNA030@mta.uoks.uj.edu.pl>; Tue, 15 Apr 2014 00:44:11 +0200 (CEST) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.2 X-Antivirus-Code: 0x100000 Received: from mbox.uj.edu.pl by saiph.uoks.uj.edu.pl (Dr.Web (R) milter module ver.6.0.2.2) ; Tue, 15 Apr 2014 00:44:11 +0200 Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl with ESMTP; Tue, 15 Apr 2014 00:44:11 +0200 (CEST) Date: Tue, 15 Apr 2014 00:44:11 +0200 From: Jakub Klama In-reply-to: <534C5A6A.1090707@freebsd.org> Message-id: <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> Subject: Re: [RFC] Refactored interrupt handling on ARM To: Nathan Whitehorn User-Agent: Roundcube Webmail/0.5 X-Sender: jakub.klama@uj.edu.pl Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:44:14 -0000 On Mon, 14 Apr 2014 15:00:10 -0700, Nathan Whitehorn wrote: > I had deliberately made it private with the last round of interrupt > changes. The idea was to rely completely on newbus for interrupt > mapping. Having a public interface allows code to bypass the bus > hierarchy, which usually isn't a good thing. This ended up happening > all over the place on PowerPC, for example. This made a lot of > drivers > less MI than they should have been and took a lot of time to get rid > of. Agree. In fact, we can completely remove FDT_MAP_IRQ macro, as well as FDT_INTR_MAX. Jakub From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 05:44:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7ED0431 for ; Tue, 15 Apr 2014 05:44:22 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF9261CBE for ; Tue, 15 Apr 2014 05:44:22 +0000 (UTC) Received: from zeppelin.tachypleus.net ([12.39.6.101]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s3F5iJOC008267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 22:44:20 -0700 Message-ID: <534CC733.7010009@freebsd.org> Date: Mon, 14 Apr 2014 22:44:19 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jakub Klama Subject: Re: [RFC] Refactored interrupt handling on ARM References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> In-Reply-To: <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;xvUO/WDE4xGmd5xB+Bh/TQ== M;+CZW/WDE4xGmd5xB+Bh/TQ== Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 05:44:22 -0000 On 04/14/14 15:44, Jakub Klama wrote: > On Mon, 14 Apr 2014 15:00:10 -0700, Nathan Whitehorn wrote: >> I had deliberately made it private with the last round of interrupt >> changes. The idea was to rely completely on newbus for interrupt >> mapping. Having a public interface allows code to bypass the bus >> hierarchy, which usually isn't a good thing. This ended up happening >> all over the place on PowerPC, for example. This made a lot of drivers >> less MI than they should have been and took a lot of time to get rid >> of. > > Agree. In fact, we can completely remove FDT_MAP_IRQ macro, as well as > FDT_INTR_MAX. > > Jakub > Great! Very nice work with all of this, by the way. It's a thorny problem and I'm glad to see it being solved. -Nathan From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 13:55:36 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2319837C; Tue, 15 Apr 2014 13:55:36 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D59E01CE3; Tue, 15 Apr 2014 13:55:35 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.8/8.14.8) with ESMTP id s3FDtYmf091166; Tue, 15 Apr 2014 13:55:34 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.8/8.14.8/Submit) id s3FDtY4D091165; Tue, 15 Apr 2014 13:55:34 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 Apr 2014 13:55:34 GMT Message-Id: <201404151355.s3FDtY4D091165@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:55:36 -0000 TB --- 2014-04-15 13:55:16 - tinderbox 2.21 running on freebsd-stable.sentex.ca TB --- 2014-04-15 13:55:16 - FreeBSD freebsd-stable.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263737: Wed Mar 26 08:50:55 UTC 2014 des@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-15 13:55:16 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-04-15 13:55:16 - cleaning the object tree TB --- 2014-04-15 13:55:16 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-15 13:55:20 - At svn revision 264498 TB --- 2014-04-15 13:55:21 - building world TB --- 2014-04-15 13:55:21 - CROSS_BUILD_TESTING=YES TB --- 2014-04-15 13:55:21 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-15 13:55:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-15 13:55:21 - SRCCONF=/dev/null TB --- 2014-04-15 13:55:21 - TARGET=arm TB --- 2014-04-15 13:55:21 - TARGET_ARCH=arm TB --- 2014-04-15 13:55:21 - TZ=UTC TB --- 2014-04-15 13:55:21 - __MAKE_CONF=/dev/null TB --- 2014-04-15 13:55:21 - cd /src TB --- 2014-04-15 13:55:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Apr 15 13:55:26 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -DCTF_OLD_VERSIONS -I/src/cddl/lib/libctf/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libctf/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libctf/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libctf/../../../cddl/contrib/opensolaris/common/ctf -I/src/cddl/lib/libctf/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libctf/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/cddl/lib/libctf/../../../cddl/contrib/opensolaris/common/ctf/ctf_util.c -o ctf_util.o building static ctf library ranlib libctf.a sh /src/tools/install.sh -C -o root -g wheel -m 444 libctf.a /obj/arm.arm/src/tmp/legacy/usr/lib ===> lib/libelf (obj,depend,all,install) /obj/arm.arm/src/tmp/src/lib/libelf created for /src/lib/libelf m4 -D SRCDIR=/src/lib/libelf /src/lib/libelf/libelf_fsize.m4 > libelf_fsize.c m4 -D SRCDIR=/src/lib/libelf /src/lib/libelf/libelf_msize.m4 > libelf_msize.c m4 -D SRCDIR=/src/lib/libelf /src/lib/libelf/libelf_convert.m4 > libelf_convert.c rm -f .depend mkdep -f .depend -a -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -I/obj/arm.arm/src/tmp/legacy/usr/include -std=gnu99 /src/lib/libelf/elf_begin.c /src/lib/libelf/elf_cntl.c /src/lib/libelf/elf_end.c /src/lib/libelf/elf_errmsg.c /src/lib/libelf/elf_errno.c /src/lib/libelf/elf_data.c /src/lib/libelf/elf_fill.c /src/lib/libelf/elf_flag.c /src/lib/libelf/elf_getarhdr.c /src/lib/libelf/elf_getarsym.c /src/lib/libelf/elf_getbase.c /src/lib/libelf/elf_getident.c /src/lib/libelf/elf_hash.c /src/lib/libelf/elf_kind.c /src/lib/libelf/elf_memory.c /src/lib/libelf/elf_next.c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rawfile.c /src/lib/libelf/elf_phnum.c /src/lib/libelf/elf_shnum.c /src/lib/libelf/elf_shstrndx.c /src/lib/libelf/elf_scn.c /src/lib/libelf/elf_strptr.c /src/lib/libelf/elf_update.c /src/lib/libelf/elf_version.c /src/lib/libelf/gelf_cap.c /src/lib/libelf/gelf_checksum.c /src/lib/libelf/gelf_dyn.c /src/lib/libelf/gelf_ehdr.c /src/lib/libelf/gelf_! getclass.c /src/lib/libelf/gelf_fsize.c /src/lib/libelf/gelf_move.c /src/lib/libelf/gelf_phdr.c /src/lib/libelf/gelf_rel.c /src/lib/libelf/gelf_rela.c /src/lib/libelf/gelf_shdr.c /src/lib/libelf/gelf_sym.c /src/lib/libelf/gelf_syminfo.c /src/lib/libelf/gelf_symshndx.c /src/lib/libelf/gelf_xlate.c /src/lib/libelf/libelf.c /src/lib/libelf/libelf_align.c /src/lib/libelf/libelf_allocate.c /src/lib/libelf/libelf_ar.c /src/lib/libelf/libelf_ar_util.c /src/lib/libelf/libelf_checksum.c /src/lib/libelf/libelf_data.c /src/lib/libelf/libelf_ehdr.c /src/lib/libelf/libelf_extended.c /src/lib/libelf/libelf_phdr.c /src/lib/libelf/libelf_shdr.c /src/lib/libelf/libelf_xlate.c libelf_fsize.c libelf_msize.c libelf_convert.c cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_begin.c -o elf_begin.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** [elf_end.o] Error code 1 Stop in /src/lib/libelf. *** [bootstrap-tools] Error code 1 Stop in /src. *** [_bootstrap-tools] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2014-04-15 13:55:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-04-15 13:55:34 - ERROR: failed to build world TB --- 2014-04-15 13:55:34 - 8.36 user 2.99 system 17.80 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 14:12:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8AB5F8F for ; Tue, 15 Apr 2014 14:12:06 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78F3910CF for ; Tue, 15 Apr 2014 14:12:06 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id rp16so9478002pbb.26 for ; Tue, 15 Apr 2014 07:12:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hBhhf9NqnpZBOAIuzS9yev72KtV1X8YqQBCqq5YhMaM=; b=f8OuabD4aTHjIALnvpMBUB6FNbvEfSjWB7L0eTyGg8V5s4kadZmZ5ov+FzPIQ80bYt Ua2jCavSiPDefIAd7HT77R48FtihwWUeLytqcHS8pOANR64XXtbd5EPuzygKHDH/dbu8 dmQR2BQkAdc6WmPBs1NZ6mvStd3JujRf9fTH5f/L5Kom0GAofB6ZWLWVE4zXsyx5bP5C A3Z7TlbnrIYop9f2F/u0/jutoSnBZd8qs9xSuM4uUxuCRhk2PRq7x+6JLjeDV75cd/II 3gVmaqNgTqhDtOavX3soyQ2gmXgfpAtGRLZZavXNjJunoMWf/q78j/HMjoOoHM/YOYJt dawA== X-Gm-Message-State: ALoCoQmxrq4nbPcX8h2BQi/Ph4gK7f4e0ZC90bgH9IO73d6nDDaJcdrdX1Mmp+2CrZAITvfTusk9 X-Received: by 10.68.238.164 with SMTP id vl4mr2304931pbc.10.1397571120762; Tue, 15 Apr 2014 07:12:00 -0700 (PDT) Received: from macintosh-c42c033c0b73.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ss2sm96403377pab.8.2014.04.15.07.11.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 07:11:59 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [RFC] Refactored interrupt handling on ARM From: Warner Losh In-Reply-To: <534CC733.7010009@freebsd.org> Date: Tue, 15 Apr 2014 08:11:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> <534CC733.7010009@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 14:12:06 -0000 On Apr 14, 2014, at 11:44 PM, Nathan Whitehorn = wrote: >=20 > On 04/14/14 15:44, Jakub Klama wrote: >> On Mon, 14 Apr 2014 15:00:10 -0700, Nathan Whitehorn wrote: >>> I had deliberately made it private with the last round of interrupt >>> changes. The idea was to rely completely on newbus for interrupt >>> mapping. Having a public interface allows code to bypass the bus >>> hierarchy, which usually isn't a good thing. This ended up happening >>> all over the place on PowerPC, for example. This made a lot of = drivers >>> less MI than they should have been and took a lot of time to get rid >>> of. >>=20 >> Agree. In fact, we can completely remove FDT_MAP_IRQ macro, as well = as >> FDT_INTR_MAX. >>=20 >> Jakub >>=20 >=20 > Great! Very nice work with all of this, by the way. It's a thorny = problem and I'm glad to see it being solved. This is looking nice on the surface. I=92ve done a small portion of this = sort of work for the Atmel port, so I=92ll see how well this can be = extended to work there. Unlike the gic device, there=92s 3 or 4 pio = controllers that act as interrupt handlers, plus the need to wire up = pins relatively early... I=92d clean up the name =91intrng.c=92 though, since ng things tend to = become dated=85 ARM_INTRNG also suffers from this naming flaw. Is there = any reason not to have it on all the time? Also, the ARM_INTRNG ifdef is = inconsistently applied. Looking at the FDT, it appears that the interrupt numbers are hard coded = for things that appear to be connected to GPIOs. This hard coding (and = changes to reflect differences in mapping) is really bad. Linux = specifies the GPIO more directly (though each SoC is different in the = details). I haven=92t looked at LPC (where I noticed the change) on = Linux to see if these changes bring us closer to being able to use the = stock FDT for that platform. Do these changes help with that? While I = appreciate the aesthetic appeal of having purely an interrupt number and = PIC (interrupt parent), I=92m not sure that will work everywhere. dosoftints() does nothing, is that on purpose? 255 is too few interrupts to have. We need easily twice that for Atmel. = And chance we can remove NIRQ as well? Finally, I=92m not sure what the change to kern_intr.c is supposed to = accomplish. It seems weird to me. Can you explain it? I=92d think that = would have a bad effect on other platforms. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 15:02:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29B1C437 for ; Tue, 15 Apr 2014 15:02:34 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A3031638 for ; Tue, 15 Apr 2014 15:02:33 +0000 (UTC) Received: from zeppelin.tachypleus.net ([128.135.100.108]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s3FF2Rrw003237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 08:02:28 -0700 Message-ID: <534D4A01.2020804@freebsd.org> Date: Tue, 15 Apr 2014 08:02:25 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: [RFC] Refactored interrupt handling on ARM References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> <534CC733.7010009@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-ID: C;snl29a7E4xGvVrilf7iULg== M;fs/l9a7E4xGvVrilf7iULg== Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 15:02:34 -0000 On 04/15/14 07:11, Warner Losh wrote: > On Apr 14, 2014, at 11:44 PM, Nathan Whitehorn wrote: > >> On 04/14/14 15:44, Jakub Klama wrote: >>> On Mon, 14 Apr 2014 15:00:10 -0700, Nathan Whitehorn wrote: >>>> I had deliberately made it private with the last round of interrupt >>>> changes. The idea was to rely completely on newbus for interrupt >>>> mapping. Having a public interface allows code to bypass the bus >>>> hierarchy, which usually isn't a good thing. This ended up happening >>>> all over the place on PowerPC, for example. This made a lot of drivers >>>> less MI than they should have been and took a lot of time to get rid >>>> of. >>> Agree. In fact, we can completely remove FDT_MAP_IRQ macro, as well as >>> FDT_INTR_MAX. >>> >>> Jakub >>> >> Great! Very nice work with all of this, by the way. It's a thorny problem and I'm glad to see it being solved. > This is looking nice on the surface. Ive done a small portion of this sort of work for the Atmel port, so Ill see how well this can be extended to work there. Unlike the gic device, theres 3 or 4 pio controllers that act as interrupt handlers, plus the need to wire up pins relatively early... > > Id clean up the name intrng.c though, since ng things tend to become dated ARM_INTRNG also suffers from this naming flaw. Is there any reason not to have it on all the time? Also, the ARM_INTRNG ifdef is inconsistently applied. > > Looking at the FDT, it appears that the interrupt numbers are hard coded for things that appear to be connected to GPIOs. This hard coding (and changes to reflect differences in mapping) is really bad. Linux specifies the GPIO more directly (though each SoC is different in the details). I havent looked at LPC (where I noticed the change) on Linux to see if these changes bring us closer to being able to use the stock FDT for that platform. Do these changes help with that? While I appreciate the aesthetic appeal of having purely an interrupt number and PIC (interrupt parent), Im not sure that will work everywhere. > > dosoftints() does nothing, is that on purpose? > > 255 is too few interrupts to have. We need easily twice that for Atmel. And chance we can remove NIRQ as well? > > Finally, Im not sure what the change to kern_intr.c is supposed to accomplish. It seems weird to me. Can you explain it? Id think that would have a bad effect on other platforms. > > Warner > > > On a related note, I'm confused by the simplebus.c changes. machine/fdt.h isn't an MI header (it doesn't exist on PowerPC, for example). Neither is FDT_DESCRIBE_IRQ() an MI interface. If you want an interface like this, it seems like it should be a standard part of the MI interrupt layer rather than yet more hacks in simplebus. -Nathan From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 15:29:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6527FAA; Tue, 15 Apr 2014 15:29:35 +0000 (UTC) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id 90735188D; Tue, 15 Apr 2014 15:29:35 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N420026VWD8A0I0@mta.uoks.uj.edu.pl>; Tue, 15 Apr 2014 17:29:33 +0200 (CEST) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.2 X-Antivirus-Code: 0x100000 Received: from mbox.uj.edu.pl by saiph.uoks.uj.edu.pl (Dr.Web (R) milter module ver.6.0.2.2) ; Tue, 15 Apr 2014 17:29:33 +0200 Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl with ESMTP; Tue, 15 Apr 2014 17:29:33 +0200 (CEST) Date: Tue, 15 Apr 2014 17:29:32 +0200 From: Jakub Klama In-reply-to: Message-id: <619da7d72d2345b1fcac5426b45c6ead@uj.edu.pl> References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> <534CC733.7010009@freebsd.org> Subject: Re: [RFC] Refactored interrupt handling on ARM To: Warner Losh User-Agent: Roundcube Webmail/0.5 X-Sender: jakub.klama@uj.edu.pl Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 15:29:36 -0000 On Tue, 15 Apr 2014 08:11:57 -0600, Warner Losh wrote: > This is looking nice on the surface. I’ve done a small portion of > this sort of work for the Atmel port, so I’ll see how well this can > be > extended to work there. Unlike the gic device, there’s 3 or 4 pio > controllers that act as interrupt handlers, plus the need to wire up > pins relatively early... > > I’d clean up the name ‘intrng.c’ though, since ng things tend to > become dated… ARM_INTRNG also suffers from this naming flaw. Is there > any reason not to have it on all the time? Also, the ARM_INTRNG ifdef > is inconsistently applied. Well, the naming thing is the least significant one I guess... and one which can be fixed in a moment. ARM_INTRNG should be enabled only on platforms which have pic drivers using pic_if.m interface instead of the old one. The purpose for that option is to not break existing code. > Looking at the FDT, it appears that the interrupt numbers are hard > coded for things that appear to be connected to GPIOs. This hard > coding (and changes to reflect differences in mapping) is really bad. Can you give an example? > Linux specifies the GPIO more directly (though each SoC is different > in the details). I haven’t looked at LPC (where I noticed the change) > on Linux to see if these changes bring us closer to being able to use > the stock FDT for that platform. Do these changes help with that? LPC changes purpose was rather to give an example, surely other platforms can benefit more from these. > While I appreciate the aesthetic appeal of having purely an interrupt > number and PIC (interrupt parent), I’m not sure that will work > everywhere. > > dosoftints() does nothing, is that on purpose? It's present to not break compatibility and I'm not even sure what should it do. However: % ack dosoftints arm/arm/intrng.c 417:void dosoftints(void); 419:dosoftints(void) arm/arm/intr.c 138:void dosoftints(void); 140:dosoftints(void) is it needed anyways? > 255 is too few interrupts to have. We need easily twice that for > Atmel. And chance we can remove NIRQ as well? Currently we can have 255 pics and 256 irqs on each, but because irq number is stored in int, we easily (down to changing two lines of code) divide it by 16:16 or 8:24, thus having 2^16 pics and 2^16 irqs on each or 256 pics with 2^24 irqs on each maximum. Regarding NIRQ, there's surely possible to get rid of it, but it will need also removing intrcnt/sintrcnt/intrnames and creating more flexible interface instead (for other archs too). Anyways, it's some step in removing it. > Finally, I’m not sure what the change to kern_intr.c is supposed to > accomplish. It seems weird to me. Can you explain it? I’d think that > would have a bad effect on other platforms. trapframe is passed to the first intr_event_handle() call and saved in td->td_intr_frame (just like it was before). If the consecutive calls to intr_event_handle() supply 0/NULL as trapframe, filter function which wants trapframe instead of argument will get the saved one. So the only situation where the behavior is different is case where you call intr_event_handle(ie, NULL). BTW This change was discussed some time ago with cognet@. Jakub From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 15:41:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD9523B6; Tue, 15 Apr 2014 15:41:50 +0000 (UTC) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id 88E981A0E; Tue, 15 Apr 2014 15:41:50 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N42002DVWXPA0I0@mta.uoks.uj.edu.pl>; Tue, 15 Apr 2014 17:41:49 +0200 (CEST) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.2 X-Antivirus-Code: 0x100000 Received: from mbox.uj.edu.pl by saiph.uoks.uj.edu.pl (Dr.Web (R) milter module ver.6.0.2.2) ; Tue, 15 Apr 2014 17:41:49 +0200 Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl with ESMTP; Tue, 15 Apr 2014 17:41:49 +0200 (CEST) Date: Tue, 15 Apr 2014 17:41:49 +0200 From: Jakub Klama In-reply-to: <534D4A01.2020804@freebsd.org> Message-id: <167c8a4b580fff7e4f1a85edfa962dd6@uj.edu.pl> References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> <534CC733.7010009@freebsd.org> <534D4A01.2020804@freebsd.org> Subject: Re: [RFC] Refactored interrupt handling on ARM To: Nathan Whitehorn User-Agent: Roundcube Webmail/0.5 X-Sender: jakub.klama@uj.edu.pl Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 15:41:50 -0000 On Tue, 15 Apr 2014 08:02:25 -0700, Nathan Whitehorn wrote: > On a related note, I'm confused by the simplebus.c changes. > machine/fdt.h isn't an MI header (it doesn't exist on PowerPC, for > example). Neither is FDT_DESCRIBE_IRQ() an MI interface. If you want > an interface like this, it seems like it should be a standard part of > the MI interrupt layer rather than yet more hacks in simplebus. Right. I was not aware of machine/fdt.h obsolescence. Jakub From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 16:59:33 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09500C8E for ; Tue, 15 Apr 2014 16:59:33 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB24B1299 for ; Tue, 15 Apr 2014 16:59:32 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wa6Qb-0000uW-EH; Tue, 15 Apr 2014 16:41:45 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3FGfgTZ000869; Tue, 15 Apr 2014 10:41:42 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/4Ek/dbon+dMezhjjpsSRF Subject: Re: [RFC] Refactored interrupt handling on ARM From: Ian Lepore To: Jakub Klama In-Reply-To: <619da7d72d2345b1fcac5426b45c6ead@uj.edu.pl> References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> <534CC733.7010009@freebsd.org> <619da7d72d2345b1fcac5426b45c6ead@uj.edu.pl> Content-Type: text/plain; charset="windows-1251" Date: Tue, 15 Apr 2014 10:41:42 -0600 Message-ID: <1397580102.1124.121.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s3FGfgTZ000869 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 16:59:33 -0000 On Tue, 2014-04-15 at 17:29 +0200, Jakub Klama wrote: > On Tue, 15 Apr 2014 08:11:57 -0600, Warner Losh wrote: > > This is looking nice on the surface. I=92ve done a small portion of > > this sort of work for the Atmel port, so I=92ll see how well this can= =20 > > be > > extended to work there. Unlike the gic device, there=92s 3 or 4 pio > > controllers that act as interrupt handlers, plus the need to wire up > > pins relatively early... > > > > I=92d clean up the name =91intrng.c=92 though, since ng things tend t= o > > become dated=85 ARM_INTRNG also suffers from this naming flaw. Is the= re > > any reason not to have it on all the time? Also, the ARM_INTRNG ifdef > > is inconsistently applied. >=20 > Well, the naming thing is the least significant one I guess... and > one which can be fixed in a moment. >=20 > ARM_INTRNG should be enabled only on platforms which have pic drivers > using pic_if.m interface instead of the old one. The purpose for that > option is to not break existing code. >=20 IMO we do too much of this. Unless there's a really good reason not to update the older platforms to use this new scheme, I think we should just convert everything to the new way. > > Looking at the FDT, it appears that the interrupt numbers are hard > > coded for things that appear to be connected to GPIOs. This hard > > coding (and changes to reflect differences in mapping) is really bad. >=20 > Can you give an example? >=20 > > Linux specifies the GPIO more directly (though each SoC is different > > in the details). I haven=92t looked at LPC (where I noticed the chang= e) > > on Linux to see if these changes bring us closer to being able to use > > the stock FDT for that platform. Do these changes help with that? >=20 > LPC changes purpose was rather to give an example, surely other > platforms can benefit more from these. >=20 > > While I appreciate the aesthetic appeal of having purely an interrupt > > number and PIC (interrupt parent), I=92m not sure that will work > > everywhere. > > > > dosoftints() does nothing, is that on purpose? >=20 > It's present to not break compatibility and I'm not even sure what > should it do. However: >=20 > % ack dosoftints > arm/arm/intrng.c > 417:void dosoftints(void); > 419:dosoftints(void) >=20 > arm/arm/intr.c > 138:void dosoftints(void); > 140:dosoftints(void) >=20 > is it needed anyways? >=20 > > 255 is too few interrupts to have. We need easily twice that for > > Atmel. And chance we can remove NIRQ as well? >=20 > Currently we can have 255 pics and 256 irqs on each, but because irq > number is stored in int, we easily (down to changing two lines of code= ) > divide it by 16:16 or 8:24, thus having 2^16 pics and 2^16 irqs on eac= h > or 256 pics with 2^24 irqs on each maximum. >=20 > Regarding NIRQ, there's surely possible to get rid of it, but it will > need also removing intrcnt/sintrcnt/intrnames and creating more > flexible interface instead (for other archs too). Anyways, it's some > step in removing it. >=20 > > Finally, I=92m not sure what the change to kern_intr.c is supposed to > > accomplish. It seems weird to me. Can you explain it? I=92d think tha= t > > would have a bad effect on other platforms. >=20 > trapframe is passed to the first intr_event_handle() call and saved > in td->td_intr_frame (just like it was before). If the consecutive > calls to intr_event_handle() supply 0/NULL as trapframe, filter > function which wants trapframe instead of argument will get the > saved one. So the only situation where the behavior is different > is case where you call intr_event_handle(ie, NULL). BTW This change > was discussed some time ago with cognet@. Since this is only needed by the new arm code, and the new arm code only calls intr_event_handle() from arm_dispatch_irq(), can't this logic just move into there? Also, I have a feeling EOI isn't being done in all the right places, but it could be a matter of misreading the diff. I need to actually apply the diff and read the code, and I'll get to that soon, really I will (I seem to be writing a new definition for "soon" every time I say that). -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 17:36:26 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6454A44; Tue, 15 Apr 2014 17:36:26 +0000 (UTC) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id 9F24616B4; Tue, 15 Apr 2014 17:36:26 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N43004CA28O1J00@mta.uoks.uj.edu.pl>; Tue, 15 Apr 2014 19:36:25 +0200 (CEST) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.2 X-Antivirus-Code: 0x100000 Received: from mbox.uj.edu.pl by saiph.uoks.uj.edu.pl (Dr.Web (R) milter module ver.6.0.2.2) ; Tue, 15 Apr 2014 19:36:24 +0200 Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl with ESMTP; Tue, 15 Apr 2014 19:36:25 +0200 (CEST) Date: Tue, 15 Apr 2014 19:36:24 +0200 From: Jakub Klama In-reply-to: <1397580102.1124.121.camel@revolution.hippie.lan> Message-id: References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> <534CC733.7010009@freebsd.org> <619da7d72d2345b1fcac5426b45c6ead@uj.edu.pl> <1397580102.1124.121.camel@revolution.hippie.lan> Subject: Re: [RFC] Refactored interrupt handling on ARM To: Ian Lepore User-Agent: Roundcube Webmail/0.5 X-Sender: jakub.klama@uj.edu.pl Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 17:36:27 -0000 On Tue, 15 Apr 2014 10:41:42 -0600, Ian Lepore wrote: > IMO we do too much of this. Unless there's a really good reason not > to > update the older platforms to use this new scheme, I think we should > just convert everything to the new way. I'd also vote for that. > Since this is only needed by the new arm code, and the new arm code > only > calls intr_event_handle() from arm_dispatch_irq(), can't this logic > just > move into there? Good point. I think that following change should be sufficent: --- a/sys/arm/arm/intrng.c +++ b/sys/arm/arm/intrng.c @@ -113,6 +113,14 @@ arm_dispatch_irq(device_t dev, struct trapframe *tf, int irq) debugf("pic %s, tf %p, irq %d\n", device_get_nameunit(dev), tf, irq); + /* + * If we got null trapframe argument, that probably means + * a call from non-root interrupt controller. In that case, + * we'll just use the saved one. + */ + if (tf == NULL) + tf = PCPU_GET(curthread)->td_intr_frame; + for (i = 0; arm_intrs[i].ih_dev != NULL; i++) { if (arm_intrs[i].ih_pic->ic_dev == dev && arm_intrs[i].ih_irq == irq) { Jakub From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 19:23:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B71AD7D4 for ; Tue, 15 Apr 2014 19:23:20 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 580E212F7 for ; Tue, 15 Apr 2014 19:23:20 +0000 (UTC) Received: from [2001:470:9174:1:2ca6:4031:637f:7644] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Wa8wn-0004Aj-4r; Tue, 15 Apr 2014 20:23:17 +0100 From: Mark R V Murray Content-Type: multipart/signed; boundary="Apple-Mail=_56E46362-BF0A-4321-AC4F-8F0A1E842A6C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Date: Tue, 15 Apr 2014 20:23:16 +0100 Subject: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. To: Tim Kientzle X-Mailer: Apple Mail (2.1874) X-SA-Score: -1.0 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 19:23:20 -0000 --Apple-Mail=_56E46362-BF0A-4321-AC4F-8F0A1E842A6C Content-Type: multipart/mixed; boundary="Apple-Mail=_D4C8EA88-9ADC-4040-AE4C-A4AE569890C4" --Apple-Mail=_D4C8EA88-9ADC-4040-AE4C-A4AE569890C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Tim I=92ve been doing some local hacks to cross-build ARM/RPI releases on = CURRENT/AMD64. What I=92m doing aren=92t clean releases in that I want to use the state = of /usr/src and /usr/ports =93as-is=94 and not a clean check out. This = allows me to experimentally break stuff without having to check it in = first. It also give me a way to build bootable images for when (not = =93if=94!) I mess things up properly on the RPI. It has the advantage = also of being quicker than the usual release build. (The hacks, as they stand now, are attached. I null-mount /usr/src and = /usr/ports instead of checking them out, and I have local checkouts of = crochet and u-boot to copy as checking them out during a release build = fails too often.) The problem is that sometime in the last month or so, things stopped = working, and its taken me until now to have the time to have a look at = it. The problem is that during the u-boot build, a CLANG-based xdev build is = used, and this has no *-gcc, only a *-cc. If I fix that with a symlink, = clang then objects to the -ffixed-r8 option. Clang has an equivalent = -ffixed-r9, but the u-boot that is mandated for FreeBSD/Arm/RPI use = doesn=92t have the R9 fix. Questions: 1) Are you aware of any of this? 2) Do you have a quick fix idea (preferably not involving GCC)? I=92m rather short of time right now, but may be able to get to this = over Easter. M --=20 Mark R V Murray --Apple-Mail=_D4C8EA88-9ADC-4040-AE4C-A4AE569890C4 Content-Disposition: attachment; filename=release_rpi_hacks.diff Content-Type: application/octet-stream; name="release_rpi_hacks.diff" Content-Transfer-Encoding: 7bit Index: arm/RPI-B.conf =================================================================== --- arm/RPI-B.conf (revision 264500) +++ arm/RPI-B.conf (working copy) @@ -17,7 +17,7 @@ set -a WORLD_FLAGS="-j $(sysctl -n hw.ncpu)" KERNEL_FLAGS="-j $(( $(( $(sysctl -n hw.ncpu) + 1 )) / 2 ))" -CHROOTDIR="/scratch" +CHROOTDIR="/usr/release/RPI" EMBEDDEDBUILD=1 EMBEDDEDPORTS="lang/python textproc/gsed" XDEV="arm" Index: arm/release.sh =================================================================== --- arm/release.sh (revision 264500) +++ arm/release.sh (working copy) @@ -75,8 +75,8 @@ } install_crochet() { - chroot ${CHROOTDIR} svn co -q ${CROCHETSRC}/${CROCHETBRANCH} \ - /tmp/crochet + rm -rf ${CHROOTDIR}/tmp/crochet + cp -rp /usr/src/release/crochet ${CHROOTDIR}/tmp/. } install_uboot() { @@ -87,8 +87,7 @@ else return 0 fi - chroot ${CHROOTDIR} svn co -q ${UBOOTSRC}/${UBOOTBRANCH} \ - /${UBOOTDIR} + cp -rp /usr/src/release/u-boot ${CHROOTDIR}${UBOOTDIR} } main() { @@ -99,21 +98,21 @@ WITH_GCC=1 ${WORLD_FLAGS} -j1 obj depend all install # Build the 'xdev' target for crochet. eval chroot ${CHROOTDIR} make -C /usr/src \ - XDEV=${XDEV} XDEV_ARCH=${XDEV_ARCH} WITH_GCC=1 \ - ${WORLD_FLAGS} xdev + XDEV=${XDEV} XDEV_ARCH=${XDEV_ARCH} ${WORLD_FLAGS} xdev + ( cd ${CHROOTDIR} && ln -sf ../..//usr/armv6-freebsd/usr/bin/cc armv6-freebsd-gcc ) # Run the ldconfig(8) startup script so /var/run/ld-elf*.so.hints # is created. - eval chroot ${CHROOTDIR} /etc/rc.d/ldconfig forcerestart + eval chroot ${CHROOTDIR} /etc/rc.d/ldconfig restart # Install security/ca_root_nss since we need to check the https # certificate of github. eval chroot ${CHROOTDIR} make -C /usr/ports/security/ca_root_nss \ OPTIONS_SET="ETCSYMLINK" BATCH=1 FORCE_PKG_REGISTER=1 \ - install clean distclean - EMBEDDEDPORTS="${EMBEDDEDPORTS} devel/subversion" + install clean for _PORT in ${EMBEDDEDPORTS}; do + eval chroot ${CHROOTDIR} make -C /usr/ports/${_PORT} clean eval chroot ${CHROOTDIR} make -C /usr/ports/${_PORT} \ - BATCH=1 FORCE_PKG_REGISTER=1 install clean distclean + BATCH=1 FORCE_PKG_REGISTER=1 install clean done mkdir -p ${CHROOTDIR}/tmp/crochet/work Index: release.sh =================================================================== --- release.sh (revision 264500) +++ release.sh (working copy) @@ -189,28 +189,30 @@ set -e # Everything must succeed mkdir -p ${CHROOTDIR}/usr +mkdir -p ${CHROOTDIR}/usr/src +mkdir -p ${CHROOTDIR}/usr/doc +mkdir -p ${CHROOTDIR}/usr/ports -if [ -z "${SRC_UPDATE_SKIP}" ]; then - ${VCSCMD} ${FORCE_SRC_KEY} ${SRCBRANCH} ${CHROOTDIR}/usr/src -fi +mount -t nullfs /usr/src ${CHROOTDIR}/usr/src +unmount=${CHROOTDIR}/usr/src if [ -z "${NODOC}" ] && [ -z "${DOC_UPDATE_SKIP}" ]; then - ${VCSCMD} ${DOCBRANCH} ${CHROOTDIR}/usr/doc + mount -t nullfs /usr/doc ${CHROOTDIR}/usr/doc + unmount="${unmount} ${CHROOTDIR}/usr/doc" fi if [ -z "${NOPORTS}" ] && [ -z "${PORTS_UPDATE_SKIP}" ]; then - ${VCSCMD} ${PORTBRANCH} ${CHROOTDIR}/usr/ports + mount -t nullfs /usr/ports ${CHROOTDIR}/usr/ports + unmount="${unmount} ${CHROOTDIR}/usr/ports" fi if [ -z "${CHROOTBUILD_SKIP}" ]; then cd ${CHROOTDIR}/usr/src env ${CHROOT_MAKEENV} make ${CHROOT_WMAKEFLAGS} buildworld - env ${CHROOT_MAKEENV} make ${CHROOT_IMAKEFLAGS} installworld \ - DESTDIR=${CHROOTDIR} - env ${CHROOT_MAKEENV} make ${CHROOT_DMAKEFLAGS} distribution \ - DESTDIR=${CHROOTDIR} + env ${CHROOT_MAKEENV} make ${CHROOT_IMAKEFLAGS} installworld DESTDIR=${CHROOTDIR} + env ${CHROOT_MAKEENV} make ${CHROOT_DMAKEFLAGS} distribution DESTDIR=${CHROOTDIR} fi mount -t devfs devfs ${CHROOTDIR}/dev cp /etc/resolv.conf ${CHROOTDIR}/etc/resolv.conf -trap "umount ${CHROOTDIR}/dev" EXIT # Clean up devfs mount on exit +trap "cd ${CHROOTDIR} && for mount in ${unmount} ${CHROOTDIR}/dev ; do umount \${mount} ; done" EXIT # Clean up mounts on exit # If MAKE_CONF and/or SRC_CONF are set and not character devices (/dev/null), # copy them to the chroot. @@ -257,7 +259,7 @@ PBUILD_FLAGS="OSVERSION=${_OSVERSION} BATCH=yes" PBUILD_FLAGS="${PBUILD_FLAGS}" chroot ${CHROOTDIR} make -C /usr/ports/textproc/docproj \ - ${PBUILD_FLAGS} OPTIONS_UNSET="FOP IGOR" install clean distclean + ${PBUILD_FLAGS} OPTIONS_UNSET="FOP IGOR" install clean fi fi --Apple-Mail=_D4C8EA88-9ADC-4040-AE4C-A4AE569890C4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_D4C8EA88-9ADC-4040-AE4C-A4AE569890C4-- --Apple-Mail=_56E46362-BF0A-4321-AC4F-8F0A1E842A6C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU02HKt58vKOKE6LNAQqm8QP6A0DpnDOSG/BrJObeLXUs6A+76a+EtV/g RkAUBJDhF0PtbfXfO9I2xmNNhwyShuizOV2e78AIl/6+7sQJ4AiIMBKsLkdNbSBM YgeMZwOf2X/WvQFbiqQoRXZ6rmLqU42N1BKT8SXaO+SA516TWa4KZqJQYompqFRS Le8ezWghEDM= =q1ZC -----END PGP SIGNATURE----- --Apple-Mail=_56E46362-BF0A-4321-AC4F-8F0A1E842A6C-- From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 20:02:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F7E3EDD for ; Tue, 15 Apr 2014 20:02:09 +0000 (UTC) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D51816B7 for ; Tue, 15 Apr 2014 20:02:09 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id um1so9933856pbc.16 for ; Tue, 15 Apr 2014 13:02:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=7LwI7j9MHJ3om0oahg22fgorUuUoVuvL/5qkjfKRgRQ=; b=D4EbViUISpy69L8gq89PRTuIg1rMB3v5F0NT8LHjC/O+wlwg21aikCRiPF2JuDwl1S FblwZy7yI9eitBQOVx3MSL4okrHxHXR4Nl+JlMpO9B/tfJqAuxQa4b5hfXckjhU2rc6Y 6r2O38i1T80RQP08piLFgu6HewT+DwddyWiJgCBsZc9zg+g8Iex+fwInWcVjMzaZP19W U+j2vX4glnoVQ5/rRR4lII4wGOOsUzozhl9vMcdWOT1DMencgLgROx0Z9+En459tZz0b ercvP0NFdiz5g/Y7s7+rhjc9jrRBbRXc9sEvWiUzk4R+EI/gRh5Bi9GK5+BZ02PnOMmC N3Lw== X-Gm-Message-State: ALoCoQmWQ5o8Cjk7koyGR8Ou8mEzW9EnPItWs6xwA28I+VYDQKCIA2aq8Sr5YnNlOR0ekONlyZF8 X-Received: by 10.68.129.34 with SMTP id nt2mr4190649pbb.18.1397592128491; Tue, 15 Apr 2014 13:02:08 -0700 (PDT) Received: from macintosh-c42c033c0b73.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ky8sm42119281pbc.64.2014.04.15.13.02.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 13:02:07 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [RFC] Refactored interrupt handling on ARM From: Warner Losh In-Reply-To: <1397580102.1124.121.camel@revolution.hippie.lan> Date: Tue, 15 Apr 2014 14:02:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <763F152E-B261-4BB4-A289-4E841C50BD81@bsdimp.com> References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> <534CC733.7010009@freebsd.org> <619da7d72d2345b1fcac5426b45c6ead@uj.edu.pl> <1397580102.1124.121.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 20:02:09 -0000 On Apr 15, 2014, at 10:41 AM, Ian Lepore wrote: > On Tue, 2014-04-15 at 17:29 +0200, Jakub Klama wrote: >> On Tue, 15 Apr 2014 08:11:57 -0600, Warner Losh wrote: >>> This is looking nice on the surface. I=92ve done a small portion of >>> this sort of work for the Atmel port, so I=92ll see how well this = can=20 >>> be >>> extended to work there. Unlike the gic device, there=92s 3 or 4 pio >>> controllers that act as interrupt handlers, plus the need to wire up >>> pins relatively early... >>>=20 >>> I=92d clean up the name =91intrng.c=92 though, since ng things tend = to >>> become dated=85 ARM_INTRNG also suffers from this naming flaw. Is = there >>> any reason not to have it on all the time? Also, the ARM_INTRNG = ifdef >>> is inconsistently applied. >>=20 >> Well, the naming thing is the least significant one I guess... and >> one which can be fixed in a moment. >>=20 >> ARM_INTRNG should be enabled only on platforms which have pic drivers >> using pic_if.m interface instead of the old one. The purpose for that >> option is to not break existing code. >>=20 >=20 > IMO we do too much of this. Unless there's a really good reason not = to > update the older platforms to use this new scheme, I think we should > just convert everything to the new way. I=92m 100% in agreement here. Those platforms that aren=92t upgraded = need to go away. >>> Looking at the FDT, it appears that the interrupt numbers are hard >>> coded for things that appear to be connected to GPIOs. This hard >>> coding (and changes to reflect differences in mapping) is really = bad. >>=20 >> Can you give an example? >>=20 >>> Linux specifies the GPIO more directly (though each SoC is different >>> in the details). I haven=92t looked at LPC (where I noticed the = change) >>> on Linux to see if these changes bring us closer to being able to = use >>> the stock FDT for that platform. Do these changes help with that? >>=20 >> LPC changes purpose was rather to give an example, surely other >> platforms can benefit more from these. >>=20 >>> While I appreciate the aesthetic appeal of having purely an = interrupt >>> number and PIC (interrupt parent), I=92m not sure that will work >>> everywhere. >>>=20 >>> dosoftints() does nothing, is that on purpose? >>=20 >> It's present to not break compatibility and I'm not even sure what >> should it do. However: >>=20 >> % ack dosoftints >> arm/arm/intrng.c >> 417:void dosoftints(void); >> 419:dosoftints(void) >>=20 >> arm/arm/intr.c >> 138:void dosoftints(void); >> 140:dosoftints(void) >>=20 >> is it needed anyways? >>=20 >>> 255 is too few interrupts to have. We need easily twice that for >>> Atmel. And chance we can remove NIRQ as well? >>=20 >> Currently we can have 255 pics and 256 irqs on each, but because irq >> number is stored in int, we easily (down to changing two lines of = code) >> divide it by 16:16 or 8:24, thus having 2^16 pics and 2^16 irqs on = each >> or 256 pics with 2^24 irqs on each maximum. >>=20 >> Regarding NIRQ, there's surely possible to get rid of it, but it will >> need also removing intrcnt/sintrcnt/intrnames and creating more >> flexible interface instead (for other archs too). Anyways, it's some >> step in removing it. >>=20 >>> Finally, I=92m not sure what the change to kern_intr.c is supposed = to >>> accomplish. It seems weird to me. Can you explain it? I=92d think = that >>> would have a bad effect on other platforms. >>=20 >> trapframe is passed to the first intr_event_handle() call and saved >> in td->td_intr_frame (just like it was before). If the consecutive >> calls to intr_event_handle() supply 0/NULL as trapframe, filter >> function which wants trapframe instead of argument will get the >> saved one. So the only situation where the behavior is different >> is case where you call intr_event_handle(ie, NULL). BTW This change >> was discussed some time ago with cognet@. >=20 > Since this is only needed by the new arm code, and the new arm code = only > calls intr_event_handle() from arm_dispatch_irq(), can't this logic = just > move into there? I agree with this as well=85 I don=92t think it is a safe assumption = that we can just change the MI behavior here... > Also, I have a feeling EOI isn't being done in all the right places, = but > it could be a matter of misreading the diff. I need to actually apply > the diff and read the code, and I'll get to that soon, really I will = (I > seem to be writing a new definition for "soon" every time I say that). Yea, I had that on my todo list to check carefully when I had time to look at this stuff in greater detail. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 20:03:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D26C8F for ; Tue, 15 Apr 2014 20:03:19 +0000 (UTC) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7EE416CD for ; Tue, 15 Apr 2014 20:03:18 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id rd3so10079342pab.11 for ; Tue, 15 Apr 2014 13:03:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cIooNGUQv0lNfdZS5VfBw+QHWp8MvtJIjTJx55LU+lI=; b=HGM3xxowh5mVz7TW1Rfu+ZleJempPh3BMz/Ee5aK/9wNYR75xQ/UbOiHHo2EHZIopP F2ApUsje0knCC56UNInlC6SZ/F4Mrf0TnK2p5G52yysi7Rc9NWMd2ZGoot0cMrT0iE1t mXlrDDZyhu0I0SvcHBiVFLXX7C6UHK7OwuIc26KAWupPp4ZrabFOizaFp2kHgJDZOCOd nHaior5aFnjDyNODmDA0mdy2bBdC2witxIEWBrG3jDArldaOryTj8Jfbg2/2mVRUn/pb sv9+4BTXq5vSbjZTdCUD1L8/LkfjiQIBRveMBer1WTj7HOlfPZrByfQEQTpFHtZBIj3W PH1g== X-Gm-Message-State: ALoCoQkuzBhpZa8bYcaX822kxi8u44jtShnCJio6Ztr2ddzKWf5jxHNSmgIg5AbpLQVVtqJKkPrZ X-Received: by 10.66.66.66 with SMTP id d2mr4154603pat.36.1397592196189; Tue, 15 Apr 2014 13:03:16 -0700 (PDT) Received: from macintosh-c42c033c0b73.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ak1sm42130413pbc.58.2014.04.15.13.03.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 13:03:15 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [RFC] Refactored interrupt handling on ARM From: Warner Losh In-Reply-To: Date: Tue, 15 Apr 2014 14:03:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1C9D6FD8-A237-4123-A22F-9D8FAF984C1B@bsdimp.com> References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> <534CC733.7010009@freebsd.org> <619da7d72d2345b1fcac5426b45c6ead@uj.edu.pl> <1397580102.1124.121.camel@revolution.hippie.lan> To: Jakub Klama X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 20:03:19 -0000 On Apr 15, 2014, at 11:36 AM, Jakub Klama wrote: > On Tue, 15 Apr 2014 10:41:42 -0600, Ian Lepore wrote: >> IMO we do too much of this. Unless there's a really good reason not = to >> update the older platforms to use this new scheme, I think we should >> just convert everything to the new way. >=20 > I'd also vote for that. >=20 >> Since this is only needed by the new arm code, and the new arm code = only >> calls intr_event_handle() from arm_dispatch_irq(), can't this logic = just >> move into there? >=20 > Good point. I think that following change should be sufficent: >=20 > --- a/sys/arm/arm/intrng.c > +++ b/sys/arm/arm/intrng.c > @@ -113,6 +113,14 @@ arm_dispatch_irq(device_t dev, struct trapframe = *tf, int irq) > debugf("pic %s, tf %p, irq %d\n", device_get_nameunit(dev), tf, = irq); > + /* > + * If we got null trapframe argument, that probably means > + * a call from non-root interrupt controller. In that case, > + * we'll just use the saved one. > + */ > + if (tf =3D=3D NULL) > + tf =3D PCPU_GET(curthread)->td_intr_frame; > + > for (i =3D 0; arm_intrs[i].ih_dev !=3D NULL; i++) { > if (arm_intrs[i].ih_pic->ic_dev =3D=3D dev && > arm_intrs[i].ih_irq =3D=3D irq) { I=92d have thought that the cascading controllers would have passed this = trap frame along. What am I missing? Warner= From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 20:30:01 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F8235F2; Tue, 15 Apr 2014 20:30:01 +0000 (UTC) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id 27C8818FD; Tue, 15 Apr 2014 20:30:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N430043IA9Z1J20@mta.uoks.uj.edu.pl>; Tue, 15 Apr 2014 22:29:59 +0200 (CEST) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.2 X-Antivirus-Code: 0x100000 Received: from mbox.uj.edu.pl by saiph.uoks.uj.edu.pl (Dr.Web (R) milter module ver.6.0.2.2) ; Tue, 15 Apr 2014 22:29:59 +0200 Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl with ESMTP; Tue, 15 Apr 2014 22:29:59 +0200 (CEST) Date: Tue, 15 Apr 2014 22:29:59 +0200 From: Jakub Klama In-reply-to: <1C9D6FD8-A237-4123-A22F-9D8FAF984C1B@bsdimp.com> Message-id: References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> <534C0F48.2090302@freebsd.org> <534C5A6A.1090707@freebsd.org> <246c2ef842c2b47eb2400c1f700ad441@uj.edu.pl> <534CC733.7010009@freebsd.org> <619da7d72d2345b1fcac5426b45c6ead@uj.edu.pl> <1397580102.1124.121.camel@revolution.hippie.lan> <1C9D6FD8-A237-4123-A22F-9D8FAF984C1B@bsdimp.com> Subject: Re: [RFC] Refactored interrupt handling on ARM To: Warner Losh User-Agent: Roundcube Webmail/0.5 X-Sender: jakub.klama@uj.edu.pl Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 20:30:01 -0000 On Tue, 15 Apr 2014 14:03:13 -0600, Warner Losh wrote: >> Good point. I think that following change should be sufficent: >> >> --- a/sys/arm/arm/intrng.c >> +++ b/sys/arm/arm/intrng.c >> @@ -113,6 +113,14 @@ arm_dispatch_irq(device_t dev, struct trapframe >> *tf, int irq) >> debugf("pic %s, tf %p, irq %d\n", device_get_nameunit(dev), >> tf, irq); >> + /* >> + * If we got null trapframe argument, that probably means >> + * a call from non-root interrupt controller. In that case, >> + * we'll just use the saved one. >> + */ >> + if (tf == NULL) >> + tf = PCPU_GET(curthread)->td_intr_frame; >> + >> for (i = 0; arm_intrs[i].ih_dev != NULL; i++) { >> if (arm_intrs[i].ih_pic->ic_dev == dev && >> arm_intrs[i].ih_irq == irq) { > > I’d have thought that the cascading controllers would have passed > this trap frame > along. What am I missing? What do you mean by "passed along"? In intr handler, you can have one argument passed: either the trap frame or user-provided arg, but not both. In fact, you will rarely (if ever) need both. Second thing is that the trap frame is saved in curthread->td_intr_frame and is easy to reach. So, in this solution, you will need to supply trap frame only in first (root) call to arm_dispatch_irq() on nexus and consecutive next level calls to intr_event_handle() will get same trap frame (so you can still use NULL arg on intr handler and get tf instead). Jakub From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 20:32:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04CCE6C5 for ; Tue, 15 Apr 2014 20:32:46 +0000 (UTC) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAB191989 for ; Tue, 15 Apr 2014 20:32:45 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id lj1so9901472pab.8 for ; Tue, 15 Apr 2014 13:32:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=I1f25/HhexVeksuOpcd12pmrYQVOq2MKC6hKA7syw60=; b=FO9X4dWpc/AmBeFqRZjqAAvL3wb6t9CcUbbK3sqk79mcBlJxW9sGDtXQacsl5OxgUl fRsFuMjLmW+/JPj/Vh59SCV03WjOgDs91LhVfm30blSBucK1Bjui1AYyPjTnaV/RAAK0 bxCbcntv0GLMH3s5jaWTO83lz7q2MUtthFz3sab46OLkRJr4NiR92b9IDE34BNmo6DSZ zGdpxvIYyqVde70Ewo5yVg7vhLebMd0PHdnSY3G9/amMqjmKNntHedwusdAuctGyV/1K BZhw5ioySrFa8KsujTl91av4pIKd4jQwe6R8SEq3p4srtKBG71LYpEyZ0AmSYe8Px7Do Wb+w== X-Gm-Message-State: ALoCoQmISUQxRp6sbc8RWaDeb/L0x2wV0fXkJGymLnKj/Hw+H4LWMB/chMG9BWpCq84JpRASrvmp X-Received: by 10.66.142.201 with SMTP id ry9mr4286794pab.14.1397593964979; Tue, 15 Apr 2014 13:32:44 -0700 (PDT) Received: from macintosh-c42c033c0b73.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id om6sm42239653pbc.43.2014.04.15.13.32.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 13:32:44 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Warner Losh In-Reply-To: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> Date: Tue, 15 Apr 2014 14:32:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1EC12C2A-9407-493E-9240-13B394BCEFB1@bsdimp.com> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1874) Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 20:32:46 -0000 On Apr 15, 2014, at 1:23 PM, Mark R V Murray wrote: > Hi Tim >=20 > I=92ve been doing some local hacks to cross-build ARM/RPI releases on = CURRENT/AMD64. >=20 > What I=92m doing aren=92t clean releases in that I want to use the = state of /usr/src and /usr/ports =93as-is=94 and not a clean check out. = This allows me to experimentally break stuff without having to check it = in first. It also give me a way to build bootable images for when (not = =93if=94!) I mess things up properly on the RPI. It has the advantage = also of being quicker than the usual release build. >=20 > (The hacks, as they stand now, are attached. I null-mount /usr/src and = /usr/ports instead of checking them out, and I have local checkouts of = crochet and u-boot to copy as checking them out during a release build = fails too often.) >=20 > The problem is that sometime in the last month or so, things stopped = working, and its taken me until now to have the time to have a look at = it. >=20 > The problem is that during the u-boot build, a CLANG-based xdev build = is used, and this has no *-gcc, only a *-cc. If I fix that with a = symlink, clang then objects to the -ffixed-r8 option. Clang has an = equivalent -ffixed-r9, but the u-boot that is mandated for = FreeBSD/Arm/RPI use doesn=92t have the R9 fix. >=20 > Questions: >=20 > 1) Are you aware of any of this? >=20 > 2) Do you have a quick fix idea (preferably not involving GCC)? >=20 > I=92m rather short of time right now, but may be able to get to this = over Easter. I=92d be tempted to do "make xdev -DWITHOUT_CLANG -DWITH_GCC=94=20 Warner= From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 20:37:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E04C76F; Tue, 15 Apr 2014 20:37:50 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51DEF19B6; Tue, 15 Apr 2014 20:37:50 +0000 (UTC) Received: from [2001:470:9174:1:2ca6:4031:637f:7644] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WaA6w-0004Kf-Vk; Tue, 15 Apr 2014 21:37:47 +0100 Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1077451D-BB8F-4186-ABE4-B29B49AA6F3A"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <1EC12C2A-9407-493E-9240-13B394BCEFB1@bsdimp.com> Date: Tue, 15 Apr 2014 21:37:51 +0100 Message-Id: <0A518B2C-B3F4-45D6-9584-9F91FB2108D4@FreeBSD.org> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <1EC12C2A-9407-493E-9240-13B394BCEFB1@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1874) X-SA-Score: -1.0 Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 20:37:50 -0000 --Apple-Mail=_1077451D-BB8F-4186-ABE4-B29B49AA6F3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 15 Apr 2014, at 21:32, Warner Losh wrote: >> Questions: >>=20 >> 1) Are you aware of any of this? >>=20 >> 2) Do you have a quick fix idea (preferably not involving GCC)? >>=20 >> I=92m rather short of time right now, but may be able to get to this = over Easter. >=20 > I=92d be tempted to do "make xdev -DWITHOUT_CLANG -DWITH_GCC=94=20 I may be headed in that direction, reluctantly. "make xdev -DWITH_GCC=94 still made xdev with clang; mebbe the = -DWITHOUT_CLANG will help, but it would be a bonus to not have GCC at = all. M --=20 Mark R V Murray --Apple-Mail=_1077451D-BB8F-4186-ABE4-B29B49AA6F3A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU02YpN58vKOKE6LNAQq99wP+Le2WZy8kN7kaapfRZ1CrE48SrG5/+1wT q2NyIaiIVfCeqBrG85hggFpxmubJZE73IklEaCZAIsu0CBL4sm7kpudCracLndd3 12FgFs7vpztPAf5uxbeHYu62P6Pk/7kYfjNTO9FDhqf4uf2M0WAURY2pT8S1GwXn DC0foXEZ8iI= =8tTL -----END PGP SIGNATURE----- --Apple-Mail=_1077451D-BB8F-4186-ABE4-B29B49AA6F3A-- From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 20:42:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3728A41 for ; Tue, 15 Apr 2014 20:42:52 +0000 (UTC) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB1881A6B for ; Tue, 15 Apr 2014 20:42:52 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id md12so10009560pbc.37 for ; Tue, 15 Apr 2014 13:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=0JfAD4nOnYY6D7j6bx7RSiSP16M5mLUsiD2aBn10jjI=; b=AQorYSEv4dusxDhrWccXKhLiXy1tISNVETt3Z8ob+Yg9CEzgZSIpqIh8PWn7Gro2o9 uv12D+5uQodpHFc8qOkNApdpkG8HcnRaUQsb6gR5c6GJNCcqAYcXLMOCPWs0bnfI4mct 6fL2B3fIW8NdvkmVtq1XbMU5VcNJGAGZ57ZA2Ydo/IanOetUIhUXMYuyzxlJ8gThwlfT RHJxnuxLRNP8JUkGYa41+Jk+5UixztUpPCxir3o/ZF7IFGAnXWW9NutWWAIIDGyKS+XR XQpIHY8UwiaITX+E/d7brdgoEjDySk5H+eewfHycgm8ruQQxFOjRUjqub577eMKNlLCX fY9Q== X-Received: by 10.68.143.196 with SMTP id sg4mr4117922pbb.155.1397594572359; Tue, 15 Apr 2014 13:42:52 -0700 (PDT) Received: from [192.168.40.122] ([209.12.167.3]) by mx.google.com with ESMTPSA id my6sm42276813pbc.36.2014.04.15.13.42.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 13:42:51 -0700 (PDT) Message-ID: <534D99CB.40607@gmail.com> Date: Tue, 15 Apr 2014 13:42:51 -0700 From: Jungle Boogie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: What happened to 11-Current ARM X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 20:42:52 -0000 Hello All, Weekly I check on what's been updated for ARM on 11-CURRENT and this week, there's only one image and its for the zedboard. ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 Is this expected from now on? -- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 20:45:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E6C8B76; Tue, 15 Apr 2014 20:45:21 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F31281A85; Tue, 15 Apr 2014 20:45:20 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 32B9F10B39; Tue, 15 Apr 2014 20:45:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 32B9F10B39 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 15 Apr 2014 16:45:16 -0400 From: Glen Barber To: Jungle Boogie Subject: Re: What happened to 11-Current ARM Message-ID: <20140415204516.GF33565@glenbarber.us> References: <534D99CB.40607@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GV0iVqYguTV4Q9ER" Content-Disposition: inline In-Reply-To: <534D99CB.40607@gmail.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 20:45:21 -0000 --GV0iVqYguTV4Q9ER Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: > Hello All, >=20 > Weekly I check on what's been updated for ARM on 11-CURRENT and this week, > there's only one image and its for the zedboard. >=20 > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 >=20 > Is this expected from now on? The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. Glen --GV0iVqYguTV4Q9ER Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTTZpcAAoJELls3eqvi17Q7GAQAKgceoBHT/IpS9s2E67y2QGY xV+UG1ngYa5Tj2P67tm6fUSwLxcS07y2newVTsjC7nV365GPgaJzlPUKUzRnZpnt biTJCeb+oAxc8fS0OAkRniRK/xT5wMtzWxqf3lzKNrEWnhSyM1EvjiZkcnnlf+rH UIGGfvjH2jTDYCew9YHWLQnbH/4Re8EVbnA5SfeClTcP4IH0zPKjfNZJj156Rin4 MZZTvwwn811RdvuZYO8H41cEidSBD3kEMPJWDDgv0uH+avsusSuf8AAl0rYqhMqg 7w3DkQjSyvo+BQ0lp+5Ab7iwq2xHe/Gq+DpWehjCR4xEli7YPZJCIEvJRGVBL3lm /zSzZS05gUKrg8Q48BSaawx0g8jLrGKUJlm7y4oGS+xs7JRtNTcDsgSE5qTeFNlJ JQC4rHtL0XIzpXMz8SLhGDu+4oPdfG/fNzI4WKx4bHvHv/2AFvyADuEj3uetycCC WndPe2JWZNCdpvsNIpXna5BvlNsrq4JkxlNU9Cv47YhNwA32qP+4WPwhaAdeadCZ PujT/N4kjulPibN99T8qehodsaKskwZyxn3XaGL1fOBY3q2lnaTuBu5mAyY68zYz sbmSPaIyCugYc+kLXFhG2QkZgJf8EkavVE6nkS/UWOEyXZmK7IwuARd6XhLjw1ly a9GnpEjANKMJjvADTY4S =rLeK -----END PGP SIGNATURE----- --GV0iVqYguTV4Q9ER-- From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 20:51:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36A61CCD for ; Tue, 15 Apr 2014 20:51:46 +0000 (UTC) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F31751B2C for ; Tue, 15 Apr 2014 20:51:45 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id uy5so4439992obc.2 for ; Tue, 15 Apr 2014 13:51:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ByKEN6PlmToY18gdtLwIk7Q/owKy8kCaXR1v1sx1PmI=; b=i5iLzHt0PkLhzSq2F2WabCDatdWq9jvLOQxO4rT9V66V1a6I9EXYo2Xposoy6c2h4M ICTGnP6tQEq9wKGFDsHmRN5trWB9lK2gBPiUvEg1leOQZsXMweeeeLh4mXGeob7GZMl7 /a9a9FcbIha+/tyienND8fIoG99v8c1xLmEm785/fEaarUudzQAs9uNJML15naJ76CGP Dz35OJ9uB83Rsvl0zJJTmd0yfRlYMw3hhsfFYj0szHkoG2htxJbVnx+YDQ3mSPkdLftt /oDT8S62HGt1dMijPe7BgG4EZgV7YvrD0nn4iHboBJcqO++noSaKkghBkDw1wRaMgHfI KfuA== X-Gm-Message-State: ALoCoQmQG2jRcVgcVb9Ait3Ar9fGwM5wOboIuU82FP5BKXWCWFSvk7yXgGb7FVRSaC2MRjou+RwJ MIME-Version: 1.0 X-Received: by 10.60.43.232 with SMTP id z8mr2795268oel.69.1397595099602; Tue, 15 Apr 2014 13:51:39 -0700 (PDT) Received: by 10.182.246.135 with HTTP; Tue, 15 Apr 2014 13:51:39 -0700 (PDT) In-Reply-To: <20140415204516.GF33565@glenbarber.us> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> Date: Tue, 15 Apr 2014 14:51:39 -0600 Message-ID: Subject: Re: What happened to 11-Current ARM From: Tom Everett To: Glen Barber Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 20:51:46 -0000 I built WANDBOARD-QUAD last week and it worked. http://files.khubla.com/freebsd-wandboard/FreeBSD-armv6-11.0-IMX6-r264433.log http://files.khubla.com/freebsd-wandboard/FreeBSD-armv6-11.0-IMX6-r264433.img.gz On Tue, Apr 15, 2014 at 2:45 PM, Glen Barber wrote: > On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: > > Hello All, > > > > Weekly I check on what's been updated for ARM on 11-CURRENT and this > week, > > there's only one image and its for the zedboard. > > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 > > > > Is this expected from now on? > > The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. > > Glen > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 21:05:46 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 576441EA; Tue, 15 Apr 2014 21:05:46 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2ADAC1C55; Tue, 15 Apr 2014 21:05:45 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WaAY4-000M2l-SY; Tue, 15 Apr 2014 21:05:45 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3FL5gXF001101; Tue, 15 Apr 2014 15:05:42 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18rEmcg//EDzcBGy5axG6++ Subject: Re: What happened to 11-Current ARM From: Ian Lepore To: Glen Barber In-Reply-To: <20140415204516.GF33565@glenbarber.us> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 2014 15:05:42 -0600 Message-ID: <1397595942.1124.125.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 21:05:46 -0000 On Tue, 2014-04-15 at 16:45 -0400, Glen Barber wrote: > On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: > > Hello All, > > > > Weekly I check on what's been updated for ARM on 11-CURRENT and this week, > > there's only one image and its for the zedboard. > > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 > > > > Is this expected from now on? > > The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. > > Glen > Failed how? Is there a build log to look at? Do emails go out on failure, like with tinderbox, and I'm not on the right list? -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 21:13:45 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92BBC3B4; Tue, 15 Apr 2014 21:13:45 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62C731D4F; Tue, 15 Apr 2014 21:13:45 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id C937810DEB; Tue, 15 Apr 2014 21:13:43 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us C937810DEB Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 15 Apr 2014 17:13:41 -0400 From: Glen Barber To: Ian Lepore Subject: Re: What happened to 11-Current ARM Message-ID: <20140415211341.GG33565@glenbarber.us> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m972NQjnE83KvVa/" Content-Disposition: inline In-Reply-To: <1397595942.1124.125.camel@revolution.hippie.lan> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 21:13:45 -0000 --m972NQjnE83KvVa/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 15, 2014 at 03:05:42PM -0600, Ian Lepore wrote: > On Tue, 2014-04-15 at 16:45 -0400, Glen Barber wrote: > > On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: > > > Hello All, > > >=20 > > > Weekly I check on what's been updated for ARM on 11-CURRENT and this = week, > > > there's only one image and its for the zedboard. > > >=20 > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 > > >=20 > > > Is this expected from now on? > >=20 > > The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. > >=20 > > Glen > >=20 >=20 > Failed how? Is there a build log to look at? Do emails go out on > failure, like with tinderbox, and I'm not on the right list? >=20 No, these build logs are not mailed. armv6-freebsd-gcc: not found I don't know what changed, or when, but have not had time to look into this. Glen --m972NQjnE83KvVa/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTTaEFAAoJELls3eqvi17QcjwQAIpU45oON8f0hlA5m+Gb1pze f3Gke3+ZPjdzjxW0+orVRW6qfqbEhAfRGPNxUwkeigXr4SdmKxJ7yPT+w/VHiHQh EneLe2bbY/M/STf1E5rb23aorq6Ejbc2gYjo4B6X0xex7Nqqlk+vWhkC9yL78TPx x9Dt3kQh359iF76ZbW9CqYvYfZWS/v0Y8FEj4Cq32JcwWARufmQ6RyZdprqER8Wn iTjjPSjru0Y0HACxDiAe/d6torpoMmOnV7sSj1WuFLxMmta3SnYWuqummoVMHIHk boKzdb04SuvNMLN9CpFUIbYeolBr1wBfrZqWutsWIPp3jUuxwgL4GIrX8rImGmnx EZDKaISLyhVPNThcTSkymaHpqx59qg0BZdmWvGD/pU0puxpSR8w86DmBi+Vk13SI DUOC9RGy9QfG9sJhLQuZMVs9XyEvlFAS4PrHPP0l1Dt3lNz5tHdHhDhlb89liM/l SZc2Uj7rE4zVmDFFW2XPqjWXWhs3utpuKSfpUKCgwwxOQCNGMHxYN/Eqm1+Fr/ZZ Ma66ERgsJ9wu9yefoX2Rlo4pF+CJKNbKaA8UIakGoSlkbBK/gwtouxdEwtAsa8Iq Me120cvbWcifzuVVbcyhW/Ks+39xaJFpGCwWpvoLAd68KKH6ujXQKxN8S+48oguA +F0LJx7jCkVsFmtZQqgK =V1wA -----END PGP SIGNATURE----- --m972NQjnE83KvVa/-- From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 21:39:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0A6868B for ; Tue, 15 Apr 2014 21:39:44 +0000 (UTC) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2D28109F for ; Tue, 15 Apr 2014 21:39:44 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id z10so9961417pdj.32 for ; Tue, 15 Apr 2014 14:39:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=b+PMDEUP8gLLv2KPeKdwCxMFkkhjbdKsmwQBPC1qIek=; b=mLjz39YiVkubNn0yCFfbyTtYeJ+lJwAXpPtEFHBiUbEZXJo7rxyX3MOXNNd5f7JPn2 t+YNLkk/LImnWdzVf0Jy5GCKFWosi35oZwndsCZPioI4HrQGO2dcj/15d5HjVwtc/Y+x vhCID/ogFCvqYxUU13KBNOs3j47zu5wfc34pDgps/F+ukcj7TZIEo5T+8rGVU0ySnQDj sPS4OR5nDn0AJv4MByN2q126hQbT7ZanZFqT8+sSeuuFqsgt0Soe9IsQl+EMCk6UbExZ PBNjp11IttADy2tnzAsMwbyAxLv9u1TxyGA0qEZ53RRkwCIpbGqp6SuMYSVzvI4iqLya dbSw== X-Gm-Message-State: ALoCoQms/OXOMACVnuRW5yemO5SwbaawbCDl6BF755El42+PM6U4Ag0lWbA6peZcD8TKI5wUidux X-Received: by 10.68.220.137 with SMTP id pw9mr4593395pbc.24.1397597978662; Tue, 15 Apr 2014 14:39:38 -0700 (PDT) Received: from macintosh-c42c033c0b73.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id pv4sm42423536pbb.55.2014.04.15.14.39.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 14:39:38 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: What happened to 11-Current ARM From: Warner Losh In-Reply-To: <20140415211341.GG33565@glenbarber.us> Date: Tue, 15 Apr 2014 15:39:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> To: Glen Barber X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 21:39:44 -0000 On Apr 15, 2014, at 3:13 PM, Glen Barber wrote: > On Tue, Apr 15, 2014 at 03:05:42PM -0600, Ian Lepore wrote: >> On Tue, 2014-04-15 at 16:45 -0400, Glen Barber wrote: >>> On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: >>>> Hello All, >>>>=20 >>>> Weekly I check on what's been updated for ARM on 11-CURRENT and = this week, >>>> there's only one image and its for the zedboard. >>>>=20 >>>> = ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 >>>>=20 >>>> Is this expected from now on? >>>=20 >>> The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. >>>=20 >>> Glen >>>=20 >>=20 >> Failed how? Is there a build log to look at? Do emails go out on >> failure, like with tinderbox, and I'm not on the right list? >>=20 >=20 > No, these build logs are not mailed. >=20 > armv6-freebsd-gcc: not found >=20 > I don't know what changed, or when, but have not had time to look into > this. You likely need to add WITHOUT_CLANG=3Dt WITH_GCC=3Dt to the crochet = build of xdev. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 22:19:38 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8CBB1E9; Tue, 15 Apr 2014 22:19:38 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87CEB146E; Tue, 15 Apr 2014 22:19:38 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 7DD491041F; Tue, 15 Apr 2014 22:19:36 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 7DD491041F Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 15 Apr 2014 18:19:34 -0400 From: Glen Barber To: Warner Losh Subject: Re: What happened to 11-Current ARM Message-ID: <20140415221934.GH33565@glenbarber.us> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IbVRjBtIbJdbeK1C" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 22:19:38 -0000 --IbVRjBtIbJdbeK1C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 15, 2014 at 03:39:35PM -0600, Warner Losh wrote: >=20 > On Apr 15, 2014, at 3:13 PM, Glen Barber wrote: >=20 > > On Tue, Apr 15, 2014 at 03:05:42PM -0600, Ian Lepore wrote: > >> On Tue, 2014-04-15 at 16:45 -0400, Glen Barber wrote: > >>> On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: > >>>> Hello All, > >>>>=20 > >>>> Weekly I check on what's been updated for ARM on 11-CURRENT and this= week, > >>>> there's only one image and its for the zedboard. > >>>>=20 > >>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 > >>>>=20 > >>>> Is this expected from now on? > >>>=20 > >>> The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. > >>>=20 > >>> Glen > >>>=20 > >>=20 > >> Failed how? Is there a build log to look at? Do emails go out on > >> failure, like with tinderbox, and I'm not on the right list? > >>=20 > >=20 > > No, these build logs are not mailed. > >=20 > > armv6-freebsd-gcc: not found > >=20 > > I don't know what changed, or when, but have not had time to look into > > this. >=20 > You likely need to add WITHOUT_CLANG=3Dt WITH_GCC=3Dt to the crochet buil= d of xdev. >=20 This is actually the default in this case. The build environment has armv6-freebsd-cc and armv6-freebsd11.0-cc, but no armv6-freebsd-gcc. Glen --IbVRjBtIbJdbeK1C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTTbB2AAoJELls3eqvi17Q87oP/1fYrREizuiT5l6U5ut3XgFX hKGdVZ7AAXBLinkMXsjwC1c3PvqMXynd3BC/0+O3ZENC2nLuj4cAMXJOoFS9qlk1 Z4QRwb9sLnUOXgPpzTKDivfaY9VALsrUuFSoalrcPW6ZPZLm3TTC5IrW2oSTIO/X D21bhAgRKXzX6WPIRUgp603kqAtIOSAUl3dbTLTZPAYQ3+ILvIsVuEohdSgZCpyZ ZLA2axMc+51qi7Ega72r7+JKJh3h8mxYOID0JxqDSJLG4GpcME95CVLbgP2oMi7W mgjNGmSKhLRMOIBZCSBFO1pU3Pmgl4WECzKZghMwKXPZ9R2V3YwAHoz3bFh+yQv6 6SRsd2bS2ko7w7LWbLRnJP5FCUwLqvAQl3eaTvkIMnTAt722yJtBn4j0U09nR6xv +1s907rBkYqV8Z1+jPVzzI/45uvlgDqhRXvZVbb15jkCxloO2pC9vsbaGAIsITvY e8pZPeyIuWhha664dTj20YSFzFDDUehXwinjISxsINVpWnujqGZsfx/ltZFgK+PY AOTlJdsasLUxeBL/NShHfkqUTYDf0x2/gjXThoZUP1Dgunh2yMVpusOY+6T+/QFH E9OMfswrP6uZvLfen5ifCKKOb201Z+8kmrO2hGDrb+0YSSYxb7WU1A+++BBRQPUo gvxqN/5yzmLXjoRVjLeD =qGT4 -----END PGP SIGNATURE----- --IbVRjBtIbJdbeK1C-- From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 23:02:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E763BCA; Tue, 15 Apr 2014 23:02:31 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D1C51872; Tue, 15 Apr 2014 23:02:31 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id x10so9964934pdj.23 for ; Tue, 15 Apr 2014 16:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jdqETJTQWo2Tcy4lf/j2NVsYf2ELBDFG1pWfNMFe0gc=; b=qnBsUZJ0sp9UXJF5bCM7vKAq+VaezyA4PYonnyKdjM5Dex9bbz52papRrH8B8KmgLa WmPUuIz6GR+fHpa0vTlUAF0BoAFP6WtqQBvzZqaNqNVXpSwkoK0jhHFsuJFQ4a64VW4x MT2TQ8KtAE5NBN9EV66SYrqsMetoJIHOpJQ1M4OfMSwYlSpm2LwLUXQDn9IEsueWUUGq RIjO9TwyXlXeHZ2JzLIDbLH81+erNWjJwHY/dxWlvesVkoj2VGa75LDNNTwZsRpFBu0r af5Isj/lbIKZHM8MBTBV1u1FG7h9edlr5/PkAOIVPEqRBqlEItYtbANBX3gB1cbaJPF5 cYSQ== X-Received: by 10.66.253.33 with SMTP id zx1mr4928357pac.28.1397602950691; Tue, 15 Apr 2014 16:02:30 -0700 (PDT) Received: from [216.131.71.105] ([216.131.71.105]) by mx.google.com with ESMTPSA id bz4sm42728376pbb.12.2014.04.15.16.02.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 16:02:29 -0700 (PDT) Message-ID: <534DBA81.4020505@gmail.com> Date: Wed, 16 Apr 2014 07:02:25 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> <53468E7A.70309@gmail.com> <1397141234.1124.47.camel@revolution.hippie.lan> In-Reply-To: <1397141234.1124.47.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 23:02:31 -0000 Hi, Anyone is interested in having these 3 patches about porting uboot 2014-01 merged? Thanks. On 04/10/2014 10:47 PM, Ian Lepore wrote: > On Thu, 2014-04-10 at 20:28 +0800, Xuebing Wang wrote: >> On 04/10/2014 06:49 PM, Bernd Walter wrote: >>> That's a lot more than is expected when going from 800 to 1000MHz. >>> Is there anything else different - e.g. cache settings? >> I am not sure. >> >> In the current u-boot UART log, we see "WARNING: Caches not enabled". >> With the latest u-boot, there is no such warning. >> >> However, Kernel does print out below about cache: >> Cache level 1: >> 32KB/64B 4-way data cache WT WB Read-Alloc >> 32KB/64B 4-way instruction cache Read-Alloc >> Cache level 2: >> 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc >> > The same thing happened in imx6 u-boot, the 2013.04 didnt' turn on > caches, but 2014.01 does. > > -- Ian > > > -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 23:05:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ABC4C2A; Tue, 15 Apr 2014 23:05:20 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E2A51884; Tue, 15 Apr 2014 23:05:19 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id q5so549216wiv.7 for ; Tue, 15 Apr 2014 16:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pqpg27N7r9hyB3ib6RX72ssZJt8HNClp1C5SP81vFgM=; b=nBb4cJ2/3ShHMMRAsX7OC1T6I85M9gWXs2q6zUMOUkI0/bWjW9xT9erH6EUCboGxnr 9bmg1esj1vF+b2to3UWbaX/UuiRa5sLWMLa3+3IC0Q625MbMBCJYE83fI+Ougwf6PDbo T5BYhTivDWQCGIXMlwUL3UFoxS5p9R+oU0IJBZNGUhFX/99n4sEZ7gBU515ss34bj001 ieEyoIA7eg9bRH3hXCpwSdCQCJ+CXQNBWrRXz55yJIzT0+XsP7b8Xiefds7nP3kPj/MA zlkly0ZuaEbdYIweqU+EdvMQUOKF0Uy3U90IDhS0M2GGHlRTEKTmm9+cz6YDiIQxhKvG XI6Q== X-Received: by 10.180.211.70 with SMTP id na6mr4537444wic.1.1397603117872; Tue, 15 Apr 2014 16:05:17 -0700 (PDT) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id kp5sm31627088wjb.30.2014.04.15.16.05.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 16:05:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 From: fabiodive In-Reply-To: <534DBA81.4020505@gmail.com> Date: Wed, 16 Apr 2014 00:05:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <97116232-B26D-451B-8195-F1C4AD5CB3E2@gmail.com> References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> <53468E7A.70309@gmail.com> <1397141234.1124.47.camel@revolution.hippie.lan> <534DBA81.4020505@gmail.com> To: Xuebing Wang X-Mailer: Apple Mail (2.1510) Cc: freebsd-arm@FreeBSD.org, ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 23:05:20 -0000 Hello sure! also..what about the work on the cpu frequency? Did you achieved 1Ghz? thank you f. On Apr 16, 2014, at 0:02 , Xuebing Wang wrote: > Hi, >=20 > Anyone is interested in having these 3 patches about porting uboot = 2014-01 merged? Thanks. >=20 >=20 > On 04/10/2014 10:47 PM, Ian Lepore wrote: >> On Thu, 2014-04-10 at 20:28 +0800, Xuebing Wang wrote: >>> On 04/10/2014 06:49 PM, Bernd Walter wrote: >>>> That's a lot more than is expected when going from 800 to 1000MHz. >>>> Is there anything else different - e.g. cache settings? >>> I am not sure. >>>=20 >>> In the current u-boot UART log, we see "WARNING: Caches not = enabled". >>> With the latest u-boot, there is no such warning. >>>=20 >>> However, Kernel does print out below about cache: >>> Cache level 1: >>> 32KB/64B 4-way data cache WT WB Read-Alloc >>> 32KB/64B 4-way instruction cache Read-Alloc >>> Cache level 2: >>> 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc >>>=20 >> The same thing happened in imx6 u-boot, the 2013.04 didnt' turn on >> caches, but 2014.01 does. >>=20 >> -- Ian >>=20 >>=20 >>=20 >=20 > --=20 > Thanks, > Xuebing Wang >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 23:16:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EF23DFF; Tue, 15 Apr 2014 23:16:26 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BDF71961; Tue, 15 Apr 2014 23:16:26 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id y10so9958268pdj.41 for ; Tue, 15 Apr 2014 16:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/e5hcyHGVT7xvUonm6QrYHcz4J5sC0FCvihvB/mJWWo=; b=Tf48fby05ou7b17WOda94va/BA/cT0/Czw5H5kFvsyeOfsdXzkgQYgdUDmYBHmcfXv R9w2FCHxDK3e7cIEIczBjWRLiKomfUwqtY0TDmbgf+O0cu5rz2vSw8j2dk9jfyCe3omg JWm2syGZiN9bX2S7kAXLrh0V/y9kWH8z//8Eyg6L5x9tARHgm0N+klVVyIW6oK12+j6M /LgrJjZ+zNAijNrSyxLXpvoiKDOu0Vl42OtVmXmukvPhPzV+ty7uFwj2zlHS0KUZIOqV yqRUp5/cwKvr0zRPmI6XTpFvRdKJgY0X22IVBGa+oVSJl2OqFMf+2UsASw5R1eFqgaDa +ffA== X-Received: by 10.68.110.4 with SMTP id hw4mr4780422pbb.147.1397603785799; Tue, 15 Apr 2014 16:16:25 -0700 (PDT) Received: from [216.131.71.105] ([216.131.71.105]) by mx.google.com with ESMTPSA id ac5sm42735385pbc.37.2014.04.15.16.16.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 16:16:25 -0700 (PDT) Message-ID: <534DBDC5.2020307@gmail.com> Date: Wed, 16 Apr 2014 07:16:21 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: fabiodive Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> <53468E7A.70309@gmail.com> <1397141234.1124.47.camel@revolution.hippie.lan> <534DBA81.4020505@gmail.com> <97116232-B26D-451B-8195-F1C4AD5CB3E2@gmail.com> In-Reply-To: <97116232-B26D-451B-8195-F1C4AD5CB3E2@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 23:16:26 -0000 On 04/16/2014 07:05 AM, fabiodive wrote: > Hello sure! > also..what about the work on the cpu frequency? > Did you achieved 1Ghz? Yes. http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007944.html > thank you > f. > From owner-freebsd-arm@FreeBSD.ORG Tue Apr 15 23:22:22 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 070E8E8D; Tue, 15 Apr 2014 23:22:22 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3D9D19FF; Tue, 15 Apr 2014 23:22:21 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id C9FF910A1C; Tue, 15 Apr 2014 23:22:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us C9FF910A1C Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 15 Apr 2014 19:22:11 -0400 From: Glen Barber To: Warner Losh Subject: Re: What happened to 11-Current ARM Message-ID: <20140415232211.GI33565@glenbarber.us> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> <20140415221934.GH33565@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="STPqjqpCrtky8aYs" Content-Disposition: inline In-Reply-To: <20140415221934.GH33565@glenbarber.us> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 23:22:22 -0000 --STPqjqpCrtky8aYs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 15, 2014 at 06:19:34PM -0400, Glen Barber wrote: > On Tue, Apr 15, 2014 at 03:39:35PM -0600, Warner Losh wrote: > >=20 > > On Apr 15, 2014, at 3:13 PM, Glen Barber wrote: > >=20 > > > On Tue, Apr 15, 2014 at 03:05:42PM -0600, Ian Lepore wrote: > > >> On Tue, 2014-04-15 at 16:45 -0400, Glen Barber wrote: > > >>> On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: > > >>>> Hello All, > > >>>>=20 > > >>>> Weekly I check on what's been updated for ARM on 11-CURRENT and th= is week, > > >>>> there's only one image and its for the zedboard. > > >>>>=20 > > >>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/1= 1.0 > > >>>>=20 > > >>>> Is this expected from now on? > > >>>=20 > > >>> The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. > > >>>=20 > > >>> Glen > > >>>=20 > > >>=20 > > >> Failed how? Is there a build log to look at? Do emails go out on > > >> failure, like with tinderbox, and I'm not on the right list? > > >>=20 > > >=20 > > > No, these build logs are not mailed. > > >=20 > > > armv6-freebsd-gcc: not found > > >=20 > > > I don't know what changed, or when, but have not had time to look into > > > this. > >=20 > > You likely need to add WITHOUT_CLANG=3Dt WITH_GCC=3Dt to the crochet bu= ild of xdev. > >=20 >=20 > This is actually the default in this case. >=20 > The build environment has armv6-freebsd-cc and armv6-freebsd11.0-cc, > but no armv6-freebsd-gcc. >=20 It seems WITHOUT_CLANG_IS_CC=3D1 is also needed. Sigh... Glen --STPqjqpCrtky8aYs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTTb8jAAoJELls3eqvi17QBo4P/Rg8vLzbI19R9CEMPEcgvkIV Pq1FqYMjP3mAHbIn/oUNlC8x6zBik8yrZmUSBYLGVvdHDWXxlHmhTTQNMXYL05zC O4sHLGhadw+HivmvO2uqaq2vtYXkopl0zBtpBOF1j9TbQbE9K1OfLFHDZIC4oJKc oGJgeuwjnU19cxPHoAaa1I/mg4GET+t1RkFPIK9KO2gSP23n74fUvrNNEijvDehk JUxLwn1MwQaIxRFrs1NPya4LZnnQ9AIeXOsuq+pW6B6/hOrx/oeXV0VkAJ/EtBhz +9lmcmEnmGGzfwWQMe19eUpBQNOiTJ6gCdwya4EFrycXP6gx11HM7Q/p3aZkUXJi DoYTDMxNUIDMoI2HA8dkxUzcmQFtbeYFOF49zkLDc4kIMNjRCUWksSJuq71RsSsG aJUfBG9+eFWQlimZoHuN9wlVG0x9ps9P+7l1T7fYgfktrHZzzZtK2qjsscG5jT5f NBeXatnNkptH0IYxlVOxiscRkR67N2svFHcBuk3yuzZrOKWCQWmH8o7VZ2tBEMGK wXgqGz3ZQKHl1q7jbg98YLLb/MNkaK2tWoy8kEFaD4zADkj/8vfnwEd0MYZArY6r luJHBKzV3KNYhCjPH5+m3prZjIuvxLbIrxSr1yt9e6hgKtQAQAO5xfVJb8mu9J2g Lom7aPC1Kjxd9rkW2dYW =aJ4S -----END PGP SIGNATURE----- --STPqjqpCrtky8aYs-- From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 01:45:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43EDB76F; Wed, 16 Apr 2014 01:45:01 +0000 (UTC) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A42761849; Wed, 16 Apr 2014 01:45:00 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id e49so8061458eek.25 for ; Tue, 15 Apr 2014 18:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pkdPpWfKYsWmWjlLGRq5MYLEeHsE5rVY8hgouxB0fJ8=; b=zsJ5w52s58pRE9VDUwG4iPnwGi4B4nkAXEld5XAfO42vNn9yR7PFG7wOO/3vPH6I4i oO0my7XMLSsgFGCkHAFTGZuORPoAGETmRG352e4g8FT7SsmB9UUeolYKhXWaPjMLJTiT 56gcmlzHrlWqo/nyTNW6cmC9bGDz8p5tpyoqIfrSjPZEjJxvaHkQUtcN4PVs6s8XVALg g+mNsDxLCaRvWCrZLZR5sypTmzvn9OAER5sCFi/Key+1ReTqNP0vUOsHrmP9f4ubpNmF KAWfr9+4XpWODF6/ova20y5h44ODicsIWoMb3wpMPa77NkrIPUNcSicQO1hL7D4I/lQo W6MQ== X-Received: by 10.15.36.136 with SMTP id i8mr1125192eev.113.1397612698965; Tue, 15 Apr 2014 18:44:58 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id 45sm53392423eeh.9.2014.04.15.18.44.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 18:44:57 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <534DE094.1000302@hot.ee> Date: Wed, 16 Apr 2014 04:44:52 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Xuebing Wang Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> <53468E7A.70309@gmail.com> <1397141234.1124.47.camel@revolution.hippie.lan> <534DBA81.4020505@gmail.com> <97116232-B26D-451B-8195-F1C4AD5CB3E2@gmail.com> <534DBDC5.2020307@gmail.com> In-Reply-To: <534DBDC5.2020307@gmail.com> X-TagToolbar-Keys: D20140416044450933 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 01:45:01 -0000 I can't seem to boot from eMMC... it fails at the point where ubldr says no devices found. Also, I didn't try to compare code, what are differences between this uboot + patches and one in crochet tree with those patches? I know it has some multi-device features... FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@rack0, Wed Apr 9 04:29:27 EEST 2014) DRAM: 512MB Card did not respond to voltage select! Card did not respond to voltage select! Number of U-Boot devices: 1 U-Boot env: loaderdev='mmc1:2.0' Found U-Boot device: net No boot device found! From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 01:51:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD15E9FB; Wed, 16 Apr 2014 01:51:12 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9215190A; Wed, 16 Apr 2014 01:51:12 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id z10so10126600pdj.18 for ; Tue, 15 Apr 2014 18:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RRhOxQoeKd9bu8pmTMST8gTdY7wb3mM5o+pU9g5EHaw=; b=VvR3hdJOTLyMclGBHr7EdkyIX55EEp+TKwmaIJYaL7eIegrgW/IESAa+BRQ2W3wm7N qTJGKQwGXGPP7mfiapRo8btmHW1jk0aYDwk37/WVvLT4CvF5JMLJrwfbU7Vvat7OPMCn WdXKtgXIhBjTQGCxReVMzB5wN3lDPsWkPoxrdVAMDEKPNZaeU2/z6aLYbhXNRcobffdU S+XTP9p13UeHeqfRvz7Pi2VBVsMoxzCNwAN8IrxM53qY6BthYiBe4UoDwCwNKz9Z+HC0 AODOfiFNnBrAOBdD0Dj5Q2Tzi7Yw1YEh/Tcr5i9MMwQFQ6pxmiPuzPdkdcUszszYrQW3 5LoQ== X-Received: by 10.67.1.39 with SMTP id bd7mr5527440pad.15.1397613072329; Tue, 15 Apr 2014 18:51:12 -0700 (PDT) Received: from [192.168.1.104] ([218.11.179.50]) by mx.google.com with ESMTPSA id ky8sm43199565pbc.64.2014.04.15.18.51.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 18:51:11 -0700 (PDT) Message-ID: <534DE206.8000107@gmail.com> Date: Wed, 16 Apr 2014 09:51:02 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Sulev-Madis Silber (ketas)" Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> <53468E7A.70309@gmail.com> <1397141234.1124.47.camel@revolution.hippie.lan> <534DBA81.4020505@gmail.com> <97116232-B26D-451B-8195-F1C4AD5CB3E2@gmail.com> <534DBDC5.2020307@gmail.com> <534DE094.1000302@hot.ee> In-Reply-To: <534DE094.1000302@hot.ee> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 01:51:12 -0000 I though flashing eMMC (booting from eMMC) is NOT supported yet. Am I correct? On 04/16/2014 09:44 AM, Sulev-Madis Silber (ketas) wrote: > I can't seem to boot from eMMC... it fails at the point where ubldr says > no devices found. Also, I didn't try to compare code, what are > differences between this uboot + patches and one in crochet tree with > those patches? I know it has some multi-device features... > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@rack0, Wed Apr 9 04:29:27 EEST 2014) > > DRAM: 512MB > Card did not respond to voltage select! > Card did not respond to voltage select! > Number of U-Boot devices: 1 > U-Boot env: loaderdev='mmc1:2.0' > Found U-Boot device: net > No boot device found! > -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 01:59:30 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA24AB48; Wed, 16 Apr 2014 01:59:29 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 949BF194F; Wed, 16 Apr 2014 01:59:29 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id C993110898; Wed, 16 Apr 2014 01:59:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us C993110898 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 15 Apr 2014 21:59:25 -0400 From: Glen Barber To: Warner Losh Subject: Re: What happened to 11-Current ARM Message-ID: <20140416015925.GM33565@glenbarber.us> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> <20140415221934.GH33565@glenbarber.us> <20140415232211.GI33565@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4ybNbZnZ8tziJ7D6" Content-Disposition: inline In-Reply-To: <20140415232211.GI33565@glenbarber.us> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 01:59:30 -0000 --4ybNbZnZ8tziJ7D6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 15, 2014 at 07:22:11PM -0400, Glen Barber wrote: > On Tue, Apr 15, 2014 at 06:19:34PM -0400, Glen Barber wrote: > > On Tue, Apr 15, 2014 at 03:39:35PM -0600, Warner Losh wrote: > > >=20 > > > On Apr 15, 2014, at 3:13 PM, Glen Barber wrote: > > >=20 > > > > On Tue, Apr 15, 2014 at 03:05:42PM -0600, Ian Lepore wrote: > > > >> On Tue, 2014-04-15 at 16:45 -0400, Glen Barber wrote: > > > >>> On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: > > > >>>> Hello All, > > > >>>>=20 > > > >>>> Weekly I check on what's been updated for ARM on 11-CURRENT and = this week, > > > >>>> there's only one image and its for the zedboard. > > > >>>>=20 > > > >>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES= /11.0 > > > >>>>=20 > > > >>>> Is this expected from now on? > > > >>>=20 > > > >>> The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. > > > >>>=20 > > > >>> Glen > > > >>>=20 > > > >>=20 > > > >> Failed how? Is there a build log to look at? Do emails go out on > > > >> failure, like with tinderbox, and I'm not on the right list? > > > >>=20 > > > >=20 > > > > No, these build logs are not mailed. > > > >=20 > > > > armv6-freebsd-gcc: not found > > > >=20 > > > > I don't know what changed, or when, but have not had time to look i= nto > > > > this. > > >=20 > > > You likely need to add WITHOUT_CLANG=3Dt WITH_GCC=3Dt to the crochet = build of xdev. > > >=20 > >=20 > > This is actually the default in this case. > >=20 > > The build environment has armv6-freebsd-cc and armv6-freebsd11.0-cc, > > but no armv6-freebsd-gcc. > >=20 >=20 > It seems WITHOUT_CLANG_IS_CC=3D1 is also needed. >=20 > Sigh... >=20 Also, this is "cute"... armv6-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32= -arm.c:9138 gmake: *** [u-boot] Segmentation fault (core dumped) gmake: *** Deleting file `u-boot' If there is going to be any expectation for armv6 being a tier-1 architecture, well, it just isn't going to work with the current state of things. Glen --4ybNbZnZ8tziJ7D6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTTeP9AAoJELls3eqvi17QCAcP/1nrNZcnhlkaPOhvjQPFfD4j W02uGCMdeCwH7RU388kDItgaf1AzMVPkm02YnFjN7vC5CC8lYmMccThjFCACCPkZ 7lrlvNvvwQ+oBRg3FDX/Lh2AV3LbVo0S1b+sV6kM74utTm/AcFt0pDk01RZZYJ44 FaNbW8rnWPHRpOgS045x1eFDXdMHkfftRaxXdY6QkpR9JemVZCaFFDawfzcKFbJU gJ73jH3rjqU9bXLux95Uzb16EE6e5wI/adKIYhRZdYr1WoU0TDnWxYCGWgIO811j 1R8AgESQwG1SnqQIYdzBNBcO7h72brs0OA8ZpVPXLvFzqbf1uX312Gewfl4ougTO VGDwQzLAEHsAV8AIJ3L8uaifcOj8W253uXxONoyE/jjrp/bFlrofa03bIluu5s5D hybilS6A2pvcz7lQGy1QzfotyXLnlML0GhWSGVB9BODVX3vMKh+ZpWq1P8dPaT60 v3UgRYDiTbrdEIzi7YDiIzLx0ZifwRvmZF24Kw3zMFd6QQAV+D9cklkqb1rj914y Bq+2pnxjUCn0LgUCabZyWgX+bMywP1A21iVdNMJb1q8XcVaw7EdOV7i3sGGprHM9 bqBESaq71av+HqBEqq7l/xAG1Kt5h41DdIhinrhuPIDyFnT4Hm8fmWEl5lDYfeVy oa4a5VuWe5uEHiIH4cvS =5PZ0 -----END PGP SIGNATURE----- --4ybNbZnZ8tziJ7D6-- From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 02:10:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34386E7D for ; Wed, 16 Apr 2014 02:10:31 +0000 (UTC) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF94D1A95 for ; Wed, 16 Apr 2014 02:10:30 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id t10so8231264eei.19 for ; Tue, 15 Apr 2014 19:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=5Oy5Qo2MSePdFAsKZX5k0vKxwZ86Mj051ZblC4CgUrE=; b=HpJ6MqFZYLAi+P4Di2+xjh0UxhUMGSQkoXs1fpFtdjAQ0uVSWPdfZx4UL9oLDOnbdY jDB9ABT0tiNecJk0QHApXHmoikKlxQqUXiSiJgFqOUJDJurT17LSt6FdVuuf2Y/Bhmhe 3BOvN+kNjeODle8Wcj0RWgFrTJIKjT/IRptXY0ql2taOmrfluXHgZjuksRLCwFjrBETY Dg/gMS+NKN5XnyyYc/F6kkWK6Dfat9/tdgI2ngcCin/oMcCVK+IQSLj7awE810PrP5l6 wkmAqQOhHItg2DP+B33riRECAQ0FCFounOb5qX2jv0polMp0O8BPC6dMkXqWpOmTRpGw CiaA== X-Received: by 10.15.43.77 with SMTP id w53mr1295196eev.10.1397614228048; Tue, 15 Apr 2014 19:10:28 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id p8sm53509749eef.26.2014.04.15.19.10.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 19:10:25 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <534DE68D.3020906@hot.ee> Date: Wed, 16 Apr 2014 05:10:21 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-arm Subject: BBB boot is flaky lately Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 02:10:31 -0000 Hello. I have many issues booting my BBB lately. Currently using r264282 Not only I get weird eMMC detection issues (1/4/8bit bus) and even failed boots (when device is not found at all): random boot #1: ------------------------------------------------------------- mmcsd0: 2GB at mmc0 48.0MHz/8bit/65535-block ------------------------------------------------------------- random boot #2: ------------------------------------------------------------- mmcsd0: 2GB at mmc0 48.0MHz/1bit/65535-block ------------------------------------------------------------- random boot #3: ------------------------------------------------------------- mmcsd0: 2GB at mmc0 48.0MHz/4bit/65535-block ------------------------------------------------------------- Now, I managed to get this (once): ------------------------------------------------------------- cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq 40,41,42,43 on simplebus0 cpsw0: CPSW SS Version 1.12 (0) cpsw0: Initial queue size TX=128 RX=384 cpsw0: Ethernet address: c8:a0:30:ad:93:a8 cpsw0: Failed to read from PHY. cpsw0: attaching PHYs failed vm_fault(0xc08b0c50, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc0996af0 FSR=00000005, FAR=00000018, spsr=80000193 r0 =c288d280, r1 =00000000, r2 =00000019, r3 =60000193 r4 =00000000, r5 =c288d280, r6 =00000006, r7 =c04d7964 r8 =c288d280, r9 =c28e828c, r10=c28e60c8, r11=c0996b50 r12=00000000, ssp=c0996b40, slr=c04f8af4, pc =c0344164 panic: Fatal abort Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... ------------------------------------------------------------- After reboot, problem persists, needs HW reset to successfully boot up. Any ideas? Thanks. From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 02:29:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8CB0438; Wed, 16 Apr 2014 02:29:26 +0000 (UTC) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3396A1BE6; Wed, 16 Apr 2014 02:29:26 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id c13so8220708eek.24 for ; Tue, 15 Apr 2014 19:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pqf9YMu7bZEzZjbdI1mmr3Cv1bb2QYQDGghlUjRRmpc=; b=CrrNb0OsBRVTS1d7t1v+kRbnAlTO6TMvaq4jfR3L1o+LdO3qWAV2Gs0D79nSNABa2+ R73RL4ZedpE1Q+VNQaS2zNA6CANO4916urZK8eNZPaB9yqdJyGHzJdqeC4i9NTAFWBhh xaqRn2/NLyJ/zaANZHoK7pXWbJD0OoYAQdw/dpGGG5/MmPodQ0p3Y7CZQdlU7mK/KW7J clNMyIdYJmX2puQwaGNkRk4O+y4pNtLNM93DKNCsICiIZyFp35EVYrjP8M8XbF8UlCKi K2aktusvhLJMcZZE14pNtQiOyXojA0QWtjyVJpTPsnEBhOAOrxJZpNnpbZzQCKStDWAM X11w== X-Received: by 10.14.2.68 with SMTP id 44mr1349281eee.63.1397615364436; Tue, 15 Apr 2014 19:29:24 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id u1sm53605717eex.31.2014.04.15.19.29.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 19:29:23 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <534DEB01.4070002@hot.ee> Date: Wed, 16 Apr 2014 05:29:21 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Xuebing Wang Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> <53468E7A.70309@gmail.com> <1397141234.1124.47.camel@revolution.hippie.lan> <534DBA81.4020505@gmail.com> <97116232-B26D-451B-8195-F1C4AD5CB3E2@gmail.com> <534DBDC5.2020307@gmail.com> <534DE094.1000302@hot.ee> <534DE206.8000107@gmail.com> In-Reply-To: <534DE206.8000107@gmail.com> X-TagToolbar-Keys: D20140416052920801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 02:29:26 -0000 It works with patched uboot 2013.04 There was discussion here about that. Recently I have some issues but it STILL works! :) On 2014-04-16 04:51, Xuebing Wang wrote: > I though flashing eMMC (booting from eMMC) is NOT supported yet. > > Am I correct? > > > On 04/16/2014 09:44 AM, Sulev-Madis Silber (ketas) wrote: >> I can't seem to boot from eMMC... it fails at the point where ubldr says >> no devices found. Also, I didn't try to compare code, what are >> differences between this uboot + patches and one in crochet tree with >> those patches? I know it has some multi-device features... >> >> >> FreeBSD/armv6 U-Boot loader, Revision 1.2 >> (root@rack0, Wed Apr 9 04:29:27 EEST 2014) >> >> DRAM: 512MB >> Card did not respond to voltage select! >> Card did not respond to voltage select! >> Number of U-Boot devices: 1 >> U-Boot env: loaderdev='mmc1:2.0' >> Found U-Boot device: net >> No boot device found! >> > From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 02:43:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B9BA63B for ; Wed, 16 Apr 2014 02:43:29 +0000 (UTC) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B25C41D27 for ; Wed, 16 Apr 2014 02:43:28 +0000 (UTC) Received: from [199.165.180.42] (dhcp12.beta.com [199.165.180.42]) by spoon.beta.com (8.14.5/8.14.5) with ESMTP id s3G2MF6l014474 for ; Tue, 15 Apr 2014 22:22:15 -0400 (EDT) (envelope-from mcgovern@beta.com) Subject: USB hubs on beaglebone black? From: "Brian J. McGovern" To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="us-ascii" Organization: B.E.T.A. Date: Tue, 15 Apr 2014 22:22:10 -0400 Message-ID: <1397614930.1484.4.camel@fbsd-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.7 required=5.0 tests=HELO_MISC_IP, RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on spoon.beta.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mcgovern@beta.com List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 02:43:29 -0000 All, I'm having an issue with my BBBs and I'm curious if this is a known issue. Googling on the keywords I can think of hasn't turned up much useful. When using webcamd, I can get a camera working fine. However, when I put a powered USB 2.0 hub between the BBB and the camera, I not only get no picture, but things like the vendor and device ID change... I'm assuming there is some corruption going on here, but I only have a small handful of identical USB hubs to play with, so I'm trying to determine whether going shopping is "worth it", or whether there is a problem with the USB stack. -B From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 02:54:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F80F749 for ; Wed, 16 Apr 2014 02:54:39 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC5B41DF4 for ; Wed, 16 Apr 2014 02:54:38 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id c11so7594729lbj.17 for ; Tue, 15 Apr 2014 19:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BMw2/1E2JROZbJXHkkQHrCtseRjqnLn0nL9fLdALPq8=; b=iA+rfKAl19L9JBGWhZOzdLwUiF74quUVLXK9VOKrU+soko3G8JvjeujMaQDZq5jN84 ndSDnrwsWU3uzdOfh04KfEsF9b2ogh/L2VKPCwvOJUVKt8R8DlGQW2oCiTPMtJoHDX29 g3HZUqdgsm3qCZ2GDA2U+SaITQLQ3r4xgFR7i928wFn8BPI4YCHl8pwZuc2JsKu8zBaC Tp6p+D6cZ0E3bbt2fquaBpwtvpSVzzdAWyx6Ge7GsQoMZZh6pkPLaQFH2JAsWkxCjwSy 1bthsJPOgfIb9C1DQdKogSYaqmrObSzD97KNsqzGcrezDVhF9T1bfzuJv2SAYgGa78mt 8MDg== MIME-Version: 1.0 X-Received: by 10.152.1.199 with SMTP id 7mr3476246lao.24.1397616876621; Tue, 15 Apr 2014 19:54:36 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.141.196 with HTTP; Tue, 15 Apr 2014 19:54:36 -0700 (PDT) In-Reply-To: <1397614930.1484.4.camel@fbsd-laptop> References: <1397614930.1484.4.camel@fbsd-laptop> Date: Tue, 15 Apr 2014 22:54:36 -0400 X-Google-Sender-Auth: dXsMJc9ipvDZD3B_PnppvnX-A0g Message-ID: Subject: Re: USB hubs on beaglebone black? From: Patrick Kelsey To: mcgovern@beta.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 02:54:39 -0000 On Tue, Apr 15, 2014 at 10:22 PM, Brian J. McGovern wrote: > All, > I'm having an issue with my BBBs and I'm curious if this is a known > issue. Googling on the keywords I can think of hasn't turned up much > useful. When using webcamd, I can get a camera working fine. However, > when I put a powered USB 2.0 hub between the BBB and the camera, I not > only get no picture, but things like the vendor and device ID change... > I'm assuming there is some corruption going on here, but I only have a > small handful of identical USB hubs to play with, so I'm trying to > determine whether going shopping is "worth it", or whether there is a > problem with the USB stack. > > For what it's worth, I've been having in some ways the opposite experience. I was having issues with a wlan adapter plugged directly into the BBB USB port becoming unresponsive over time. This particular adapter requires power near the 500mA limit, so suspecting it might be a power delivery/consumption issue, I interposed a powered USB 2.0 hub and the problem has gone away. In this case, the hub that appears to have resolved my issue is built into a several-years-old NEC monitor. I haven't tested with other hubs. -Patrick From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 03:11:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51160C1A for ; Wed, 16 Apr 2014 03:11:18 +0000 (UTC) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D44701140 for ; Wed, 16 Apr 2014 03:11:17 +0000 (UTC) Received: from [199.165.180.42] (dhcp12.beta.com [199.165.180.42]) by spoon.beta.com (8.14.5/8.14.5) with ESMTP id s3G3B6fW014664; Tue, 15 Apr 2014 23:11:06 -0400 (EDT) (envelope-from mcgovern@beta.com) Subject: Re: USB hubs on beaglebone black? From: "Brian J. McGovern" To: Patrick Kelsey In-Reply-To: References: <1397614930.1484.4.camel@fbsd-laptop> Content-Type: text/plain; charset="us-ascii" Organization: B.E.T.A. Date: Tue, 15 Apr 2014 23:11:02 -0400 Message-ID: <1397617862.1484.21.camel@fbsd-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.7 required=5.0 tests=HELO_MISC_IP, RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on spoon.beta.com Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mcgovern@beta.com List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 03:11:18 -0000 On Tue, 2014-04-15 at 22:54 -0400, Patrick Kelsey wrote: > > > > On Tue, Apr 15, 2014 at 10:22 PM, Brian J. McGovern > wrote: > All, > I'm having an issue with my BBBs and I'm curious if this is > a known > issue. Googling on the keywords I can think of hasn't turned > up much > useful. When using webcamd, I can get a camera working fine. > However, > when I put a powered USB 2.0 hub between the BBB and the > camera, I not > only get no picture, but things like the vendor and device ID > change... > I'm assuming there is some corruption going on here, but I > only have a > small handful of identical USB hubs to play with, so I'm > trying to > determine whether going shopping is "worth it", or whether > there is a > problem with the USB stack. > > > > For what it's worth, I've been having in some ways the opposite > experience. I was having issues with a wlan adapter plugged directly > into the BBB USB port becoming unresponsive over time. This > particular adapter requires power near the 500mA limit, so suspecting > it might be a power delivery/consumption issue, I interposed a powered > USB 2.0 hub and the problem has gone away. In this case, the hub that > appears to have resolved my issue is built into a several-years-old > NEC monitor. I haven't tested with other hubs. > > > -Patrick > Its an interesting data point. I'm pretty sure I don't have a power problem, as the hub is powered, and the camera works great without the hub (I _am_ using a 5V PoE injector to power the BBB, so I'm not running off the 500ma available via the USB connection), but not with. I'll try to collect some data around what I'm seeing with and without the hubs tomorrow. I'll also have to check to see what the cameras do on more traditional AMD64 hosts and VMs, in case its the cameras instead of the hub causing the problems (they're logitech units, both SVGA and 1080p, but I don't have the models at my fingertips. My goal with this exchange was to see if I got a "don't bother, it doesn't work right" type message, but it looks like it may be going the other way :) From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 03:16:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21001D8C for ; Wed, 16 Apr 2014 03:16:09 +0000 (UTC) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3B9411DF for ; Wed, 16 Apr 2014 03:16:08 +0000 (UTC) Received: from [199.165.180.42] (dhcp12.beta.com [199.165.180.42]) by spoon.beta.com (8.14.5/8.14.5) with ESMTP id s3G3G6DP014679 for ; Tue, 15 Apr 2014 23:16:06 -0400 (EDT) (envelope-from mcgovern@beta.com) Subject: Plans for standardizing digital/analog I/O? From: "Brian J. McGovern" To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="us-ascii" Organization: B.E.T.A. Date: Tue, 15 Apr 2014 23:16:02 -0400 Message-ID: <1397618162.1484.26.camel@fbsd-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.7 required=5.0 tests=HELO_MISC_IP, RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on spoon.beta.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mcgovern@beta.com List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 03:16:09 -0000 This is probably best suited for a more generic list, but given digital and analog I/O are at the core of many of the ARM based development boards out there, I figured I'd ask here first... Is anyone talking about standardizing the various I/O framworks that exist/are being built? Or, perhaps more correctly,standardizing the _interfaces_ to the various I/O frameworks? To use the BBB as an example platform, the digital I/O work seems to use the gpio[ctl] framework, while the ADC uses sysctl under the new/current driver. I haven't looked at PWM outputs yet. Finally, given that I have passthrough driver for the various Velleman I/O boards (the 110, 140, and 167) which allow the application to speak the various protocols to the boards (not to mention allowing me to plug in 5V and 12V things in to the 1.8V BBB world without much modification), I'm discovering there are at least 6 ways to do I/O in my world, and I'm guessing there are a lot more if I were to keep digging. So, I'm curious if anyone is working on or proposing a more generic, or at least standard, kernel interface to plug in to? Perhaps sysctls are a way to go, or a set of /dev/hwio/* entries. I'd also be interested in hearing anyone's thoughts on the matter, should I decide to go off and build something, either in kernel or user space, to unify these spaces for the ease of application programming. -B From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 03:22:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDFA4E8D for ; Wed, 16 Apr 2014 03:22:06 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97A1E1294 for ; Wed, 16 Apr 2014 03:22:06 +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=VYZ6x8+oASSUR0/CNttAyZY7QmcRW0Q84+/PO3Pybcs=; b=mf4F2WlHGfaMLVsLKkVHG545a8DB+Pfn1jnUr0AKnRLeIQ3I8pyKn8NGgECXtADByPBzhQjrxLwJ0hHjFx6LYpspFEk8LcmnldTqM0d3qR0Lm6RdTYPEKhMB/90e/fRejaD65aSZhJTM4M6GBtPgvKKQsfIlVyykIEzOZV1cBLo=; Received: from bb219-74-38-150.singnet.com.sg ([219.74.38.150]:55989 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WaGQA-000Xnc-DA; Tue, 15 Apr 2014 21:21:58 -0600 Date: Wed, 16 Apr 2014 11:21:54 +0800 From: Erich Dollansky To: mcgovern@beta.com Subject: Re: USB hubs on beaglebone black? Message-ID: <20140416112154.1c81830c@X220.alogt.com> In-Reply-To: <1397617862.1484.21.camel@fbsd-laptop> References: <1397614930.1484.4.camel@fbsd-laptop> <1397617862.1484.21.camel@fbsd-laptop> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; 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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 03:22:06 -0000 Hi, On Tue, 15 Apr 2014 23:11:02 -0400 "Brian J. McGovern" wrote: > On Tue, 2014-04-15 at 22:54 -0400, Patrick Kelsey wrote: > > > > For what it's worth, I've been having in some ways the opposite > > experience. I was having issues with a wlan adapter plugged > > Its an interesting data point. I'm pretty sure I don't have a power > problem, as the hub is powered, and the camera works great without the did you try the hub on any other device? Erich From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 04:57:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 544017FA; Wed, 16 Apr 2014 04:57:04 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F4611A9B; Wed, 16 Apr 2014 04:57:04 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kx10so10368725pab.5 for ; Tue, 15 Apr 2014 21:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9JiM3vjdKzsIOtXlWww9rCoB++hWimH7Ru/NSIHW5/k=; b=SdTg/FHDLViOXlnbDYn7JjdsTljyrrQSzL33jjKkw/Rzaf8mvQeHYLlPwZQwZhXOPu 0O4xqRfWMzU4ZTbNT+WZxdeteEUrf4xih1kxgiPbAm4HR0kiLgJDN/kgSycWfdoprpu5 bOdFmV3Gzc/NfOjgB16u3/V+g/6hu10tKkG467KiJI9CM+iTL7088JU5S1WGZDB/xi1u w2TtzpNJq8r3D982RboXWs42qZ1rkDRT+ximrJQ4dxF/q2ykrvdgEuoXWuVExQkMejMb 9taY9Pf7Fcz8r4inRXgLmsdMSA1ln7u7P3sFKGj+zX2Zc12V+CHhKoDy/mlua4uuSSKb QXKg== X-Received: by 10.66.181.70 with SMTP id du6mr6192550pac.23.1397624223738; Tue, 15 Apr 2014 21:57:03 -0700 (PDT) Received: from [216.131.71.131] ([216.131.71.131]) by mx.google.com with ESMTPSA id au16sm105092345pac.27.2014.04.15.21.56.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 21:57:02 -0700 (PDT) Message-ID: <534E0D99.1040907@gmail.com> Date: Wed, 16 Apr 2014 12:56:57 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Sulev-Madis Silber (ketas)" Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> <53468E7A.70309@gmail.com> <1397141234.1124.47.camel@revolution.hippie.lan> <534DBA81.4020505@gmail.com> <97116232-B26D-451B-8195-F1C4AD5CB3E2@gmail.com> <534DBDC5.2020307@gmail.com> <534DE094.1000302@hot.ee> <534DE206.8000107@gmail.com> <534DEB01.4070002@hot.ee> In-Reply-To: <534DEB01.4070002@hot.ee> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 04:57:04 -0000 Are you willing to try uSDHC boot? On 04/16/2014 10:29 AM, Sulev-Madis Silber (ketas) wrote: > It works with patched uboot 2013.04 > > There was discussion here about that. > > > Recently I have some issues but it STILL works! :) > > > On 2014-04-16 04:51, Xuebing Wang wrote: >> I though flashing eMMC (booting from eMMC) is NOT supported yet. >> >> Am I correct? >> >> >> On 04/16/2014 09:44 AM, Sulev-Madis Silber (ketas) wrote: >>> I can't seem to boot from eMMC... it fails at the point where ubldr says >>> no devices found. Also, I didn't try to compare code, what are >>> differences between this uboot + patches and one in crochet tree with >>> those patches? I know it has some multi-device features... >>> >>> >>> FreeBSD/armv6 U-Boot loader, Revision 1.2 >>> (root@rack0, Wed Apr 9 04:29:27 EEST 2014) >>> >>> DRAM: 512MB >>> Card did not respond to voltage select! >>> Card did not respond to voltage select! >>> Number of U-Boot devices: 1 >>> U-Boot env: loaderdev='mmc1:2.0' >>> Found U-Boot device: net >>> No boot device found! >>> -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 08:01:22 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3D869F; Wed, 16 Apr 2014 08:01:22 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8545C1AD4; Wed, 16 Apr 2014 08:01:22 +0000 (UTC) Received: from [2001:470:9174:1:d011:3906:1218:6b9a] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WaKmN-0005Ow-5c; Wed, 16 Apr 2014 09:01:19 +0100 Subject: Re: What happened to 11-Current ARM Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_871099AC-5875-4055-98B1-D0124BEB23DA"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <20140416015925.GM33565@glenbarber.us> Date: Wed, 16 Apr 2014 09:01:21 +0100 Message-Id: References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> <20140415221934.GH33565@glenbarber.us> <20140415232211.GI33565@glenbarber.us> <20140416015925.GM33565@glenbarber.us> To: Glen Barber X-Mailer: Apple Mail (2.1874) X-SA-Score: -1.0 Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 08:01:22 -0000 --Apple-Mail=_871099AC-5875-4055-98B1-D0124BEB23DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 16 Apr 2014, at 02:59, Glen Barber wrote: > On Tue, Apr 15, 2014 at 07:22:11PM -0400, Glen Barber wrote: >> On Tue, Apr 15, 2014 at 06:19:34PM -0400, Glen Barber wrote: >>> On Tue, Apr 15, 2014 at 03:39:35PM -0600, Warner Losh wrote: >>>>=20 >>>> On Apr 15, 2014, at 3:13 PM, Glen Barber wrote: >>>>=20 >>>>> On Tue, Apr 15, 2014 at 03:05:42PM -0600, Ian Lepore wrote: >>>>>> On Tue, 2014-04-15 at 16:45 -0400, Glen Barber wrote: >>>>>>> On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: >>>>>>>> Hello All, >>>>>>>>=20 >>>>>>>> Weekly I check on what's been updated for ARM on 11-CURRENT and = this week, >>>>>>>> there's only one image and its for the zedboard. >>>>>>>>=20 >>>>>>>> = ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 >>>>>>>>=20 >>>>>>>> Is this expected from now on? >>>>>>>=20 >>>>>>> The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. >>>>>>>=20 >>>>>>> Glen >>>>>>>=20 >>>>>>=20 >>>>>> Failed how? Is there a build log to look at? Do emails go out = on >>>>>> failure, like with tinderbox, and I'm not on the right list? >>>>>>=20 >>>>>=20 >>>>> No, these build logs are not mailed. >>>>>=20 >>>>> armv6-freebsd-gcc: not found >>>>>=20 >>>>> I don't know what changed, or when, but have not had time to look = into >>>>> this. >>>>=20 >>>> You likely need to add WITHOUT_CLANG=3Dt WITH_GCC=3Dt to the = crochet build of xdev. >>>>=20 >>>=20 >>> This is actually the default in this case. >>>=20 >>> The build environment has armv6-freebsd-cc and armv6-freebsd11.0-cc, >>> but no armv6-freebsd-gcc. >>>=20 >>=20 >> It seems WITHOUT_CLANG_IS_CC=3D1 is also needed. >>=20 >> Sigh... >>=20 >=20 > Also, this is "cute"... >=20 > armv6-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > = /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf3= 2-arm.c:9138 > gmake: *** [u-boot] Segmentation fault (core dumped) > gmake: *** Deleting file `u-boot' >=20 > If there is going to be any expectation for armv6 being a tier-1 > architecture, well, it just isn't going to work with the current state > of things. And I=92m getting rm -f .depend mkdep -f .depend -a = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include =85 cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory : : Full log available on request, but I have some other nasty hacks in = place (that have relevance mainly during the full build; I null-mount = src/ and ports/ instead of checking them out). M --=20 Mark R V Murray --Apple-Mail=_871099AC-5875-4055-98B1-D0124BEB23DA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU0441t58vKOKE6LNAQpgogQAhzANf9K4akcKk67pRRUvbOPTb4IbNCjs 7DEoKBDUpPfl/dHM2Zg4nNREZqieqYdgK1aR+AL+YpqXg8h0p6wiOP/GfjlgseYF T4s5sZGIOp6gDX7BJn/qLy+X4Wb7cbD0onzWkpSFMvYG/LU/yVr90KS1t3oTOCkm bhhjfWJtTp4= =6mn9 -----END PGP SIGNATURE----- --Apple-Mail=_871099AC-5875-4055-98B1-D0124BEB23DA-- From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 10:06:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A039B3E; Wed, 16 Apr 2014 10:06:50 +0000 (UTC) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9B21174A; Wed, 16 Apr 2014 10:06:49 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id d17so8708022eek.29 for ; Wed, 16 Apr 2014 03:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ImLJH/rHftXxtYITHzdSEYshmXJ0gitdFd//PRivSH8=; b=jyoadIAh8sxLNxgvC4br/1RtXiElOO0bTr0smvWInNOLVIUPkfQJ5ZPd7qS/87VQH0 xCWL3I/CxDyrOr1iYT3hKnzDwEiH8CnJ8+HkMudey16L2/X8vWzV9SNrZkRzApneYJaQ nQQQt0tg8T5bxJSktCQSp742CwxdSeAbNJND9w3CjBTCu4YT1nNVWqzKJ758cnebK+ru 3kKlQrMqzRM6NxEFAkzcNcPXqFAep9zquqcJnA/Jg2Jq/kOnTOtNcmnH7OB9p8T5crcj n1iDTIzcoaJRh+GsI+rybcsSRAPySnmRyGlY4aP2XA1gfLChHku/h5qz2b59xP4M8cLU fjMw== X-Received: by 10.14.194.133 with SMTP id m5mr3963334een.38.1397642808260; Wed, 16 Apr 2014 03:06:48 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id a4sm56589677eep.12.2014.04.16.03.06.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 03:06:47 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <534E5634.6050303@hot.ee> Date: Wed, 16 Apr 2014 13:06:44 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Xuebing Wang Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> <53468E7A.70309@gmail.com> <1397141234.1124.47.camel@revolution.hippie.lan> <534DBA81.4020505@gmail.com> <97116232-B26D-451B-8195-F1C4AD5CB3E2@gmail.com> <534DBDC5.2020307@gmail.com> <534DE094.1000302@hot.ee> <534DE206.8000107@gmail.com> <534DEB01.4070002@hot.ee> <534E0D99.1040907@gmail.com> In-Reply-To: <534E0D99.1040907@gmail.com> X-TagToolbar-Keys: D20140416130643940 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 10:06:50 -0000 That seemed to work well at first glance. CPU was indeed 1GHz and I didn't see any issues. On 2014-04-16 07:56, Xuebing Wang wrote: > Are you willing to try uSDHC boot? > > > On 04/16/2014 10:29 AM, Sulev-Madis Silber (ketas) wrote: >> It works with patched uboot 2013.04 >> >> There was discussion here about that. >> >> >> Recently I have some issues but it STILL works! :) >> >> >> On 2014-04-16 04:51, Xuebing Wang wrote: >>> I though flashing eMMC (booting from eMMC) is NOT supported yet. >>> >>> Am I correct? >>> >>> >>> On 04/16/2014 09:44 AM, Sulev-Madis Silber (ketas) wrote: >>>> I can't seem to boot from eMMC... it fails at the point where ubldr >>>> says >>>> no devices found. Also, I didn't try to compare code, what are >>>> differences between this uboot + patches and one in crochet tree with >>>> those patches? I know it has some multi-device features... >>>> >>>> >>>> FreeBSD/armv6 U-Boot loader, Revision 1.2 >>>> (root@rack0, Wed Apr 9 04:29:27 EEST 2014) >>>> >>>> DRAM: 512MB >>>> Card did not respond to voltage select! >>>> Card did not respond to voltage select! >>>> Number of U-Boot devices: 1 >>>> U-Boot env: loaderdev='mmc1:2.0' >>>> Found U-Boot device: net >>>> No boot device found! >>>> > From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 13:21:04 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C85CBEC; Wed, 16 Apr 2014 13:21:04 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 142591E4C; Wed, 16 Apr 2014 13:21:03 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WaPlu-000Ey0-7L; Wed, 16 Apr 2014 13:21:02 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3GDKx6u002067; Wed, 16 Apr 2014 07:20:59 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19g8854m04cX9rM8WznQlnO Subject: Re: What happened to 11-Current ARM From: Ian Lepore To: Mark R V Murray In-Reply-To: References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> <20140415221934.GH33565@glenbarber.us> <20140415232211.GI33565@glenbarber.us> <20140416015925.GM33565@glenbarber.us> Content-Type: text/plain; charset="windows-1251" Date: Wed, 16 Apr 2014 07:20:59 -0600 Message-ID: <1397654459.1124.136.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s3GDKx6u002067 Cc: Glen Barber , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 13:21:04 -0000 On Wed, 2014-04-16 at 09:01 +0100, Mark R V Murray wrote: > On 16 Apr 2014, at 02:59, Glen Barber wrote: >=20 > > On Tue, Apr 15, 2014 at 07:22:11PM -0400, Glen Barber wrote: > >> On Tue, Apr 15, 2014 at 06:19:34PM -0400, Glen Barber wrote: > >>> On Tue, Apr 15, 2014 at 03:39:35PM -0600, Warner Losh wrote: > >>>>=20 > >>>> On Apr 15, 2014, at 3:13 PM, Glen Barber wrote: > >>>>=20 > >>>>> On Tue, Apr 15, 2014 at 03:05:42PM -0600, Ian Lepore wrote: > >>>>>> On Tue, 2014-04-15 at 16:45 -0400, Glen Barber wrote: > >>>>>>> On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: > >>>>>>>> Hello All, > >>>>>>>>=20 > >>>>>>>> Weekly I check on what's been updated for ARM on 11-CURRENT an= d this week, > >>>>>>>> there's only one image and its for the zedboard. > >>>>>>>>=20 > >>>>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAG= ES/11.0 > >>>>>>>>=20 > >>>>>>>> Is this expected from now on? > >>>>>>>=20 > >>>>>>> The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. > >>>>>>>=20 > >>>>>>> Glen > >>>>>>>=20 > >>>>>>=20 > >>>>>> Failed how? Is there a build log to look at? Do emails go out = on > >>>>>> failure, like with tinderbox, and I'm not on the right list? > >>>>>>=20 > >>>>>=20 > >>>>> No, these build logs are not mailed. > >>>>>=20 > >>>>> armv6-freebsd-gcc: not found > >>>>>=20 > >>>>> I don't know what changed, or when, but have not had time to look= into > >>>>> this. > >>>>=20 > >>>> You likely need to add WITHOUT_CLANG=3Dt WITH_GCC=3Dt to the croch= et build of xdev. > >>>>=20 > >>>=20 > >>> This is actually the default in this case. > >>>=20 > >>> The build environment has armv6-freebsd-cc and armv6-freebsd11.0-cc= , > >>> but no armv6-freebsd-gcc. > >>>=20 > >>=20 > >> It seems WITHOUT_CLANG_IS_CC=3D1 is also needed. > >>=20 > >> Sigh... > >>=20 > >=20 > > Also, this is "cute"... > >=20 > > armv6-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > > /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd= /elf32-arm.c:9138 > > gmake: *** [u-boot] Segmentation fault (core dumped) > > gmake: *** Deleting file `u-boot' > >=20 > > If there is going to be any expectation for armv6 being a tier-1 > > architecture, well, it just isn't going to work with the current stat= e > > of things. >=20 > And I=92m getting >=20 > rm -f .depend > mkdep -f .depend -a -I/usr/src/lib/clang/libllvmsupport/../../../con= trib/llvm/include =85 > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > : > : >=20 >=20 > Full log available on request, but I have some other nasty hacks in pla= ce (that have relevance mainly during the full build; I null-mount src/ a= nd ports/ instead of checking them out). >=20 > M I find that to switch compilers I now need all of this in make.conf: WITHOUT_CLANG=3Dyes WITHOUT_CLANG_IS_CC=3Dyes WITH_GCC=3Dyes WITH_GNUCXX=3Dyes It used to be sufficient to say WITHOUT_CLANG_IS_CC, but now you need to throw multiple switches at once to get the old behavior. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 16:24:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAE6DE0A for ; Wed, 16 Apr 2014 16:24:18 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF58C12E0 for ; Wed, 16 Apr 2014 16:24:18 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id rl12so10749736iec.4 for ; Wed, 16 Apr 2014 09:24:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=e1WKNu4atEasIesGjcQHep1rt+S2nnWGe9Hi+vq2q2g=; b=jJWlbyY++g3ySuyeX0kibYcAcMXqZoqVrCmI2EoqtuLwJx0e56Fjx+DPXupCgRPpHI VIBlZSuOohVe0V0xBqB4xY2z/61TVQcmJaxYxNs6t3Coe0Vp7RF4Oha42BEmdIzekls1 ECCVfEAATMYBm0TorYHqK+AxGB/81jVuOGBPjfzgaUrzi4w1d16XuuABRuwoMAU9yAbh Sdb1U5rydNB2irw36v7Yn/Edpgc07eVZGbol9Em0dAGWGSuR1rPrOdh963r7HIY2d4BC O8JDPVNXh1e9DnnJ7cT6HKsDuSR3VCHRqZVNp1LFw0sefIGr5/PRqxvCxae6sYNhfl+7 KQWA== X-Gm-Message-State: ALoCoQlHC2aUC9FV/aChuBa/RiW1AcYIm0dWUGB2G71VJVBSnGlkVnCL+Q9l27200rkKodyAHbrV X-Received: by 10.50.4.74 with SMTP id i10mr11289654igi.43.1397665457702; Wed, 16 Apr 2014 09:24:17 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id p18sm47072822igt.15.2014.04.16.09.24.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 09:24:16 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: What happened to 11-Current ARM From: Warner Losh In-Reply-To: <1397654459.1124.136.camel@revolution.hippie.lan> Date: Wed, 16 Apr 2014 10:24:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <40D86548-EA3E-49D5-B95B-97BAC7AFB716@bsdimp.com> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> <20140415221934.GH33565@glenbarber.us> <20140415232211.GI33565@glenbarber.us> <20140416015925.GM33565@glenbarber.us> <1397654459.1124.136.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: Glen Barber , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:24:19 -0000 On Apr 16, 2014, at 7:20 AM, Ian Lepore wrote: > On Wed, 2014-04-16 at 09:01 +0100, Mark R V Murray wrote: >> On 16 Apr 2014, at 02:59, Glen Barber wrote: >>=20 >>> On Tue, Apr 15, 2014 at 07:22:11PM -0400, Glen Barber wrote: >>>> On Tue, Apr 15, 2014 at 06:19:34PM -0400, Glen Barber wrote: >>>>> On Tue, Apr 15, 2014 at 03:39:35PM -0600, Warner Losh wrote: >>>>>>=20 >>>>>> On Apr 15, 2014, at 3:13 PM, Glen Barber wrote: >>>>>>=20 >>>>>>> On Tue, Apr 15, 2014 at 03:05:42PM -0600, Ian Lepore wrote: >>>>>>>> On Tue, 2014-04-15 at 16:45 -0400, Glen Barber wrote: >>>>>>>>> On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: >>>>>>>>>> Hello All, >>>>>>>>>>=20 >>>>>>>>>> Weekly I check on what's been updated for ARM on 11-CURRENT = and this week, >>>>>>>>>> there's only one image and its for the zedboard. >>>>>>>>>>=20 >>>>>>>>>> = ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 >>>>>>>>>>=20 >>>>>>>>>> Is this expected from now on? >>>>>>>>>=20 >>>>>>>>> The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. >>>>>>>>>=20 >>>>>>>>> Glen >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Failed how? Is there a build log to look at? Do emails go out = on >>>>>>>> failure, like with tinderbox, and I'm not on the right list? >>>>>>>>=20 >>>>>>>=20 >>>>>>> No, these build logs are not mailed. >>>>>>>=20 >>>>>>> armv6-freebsd-gcc: not found >>>>>>>=20 >>>>>>> I don't know what changed, or when, but have not had time to = look into >>>>>>> this. >>>>>>=20 >>>>>> You likely need to add WITHOUT_CLANG=3Dt WITH_GCC=3Dt to the = crochet build of xdev. >>>>>>=20 >>>>>=20 >>>>> This is actually the default in this case. >>>>>=20 >>>>> The build environment has armv6-freebsd-cc and = armv6-freebsd11.0-cc, >>>>> but no armv6-freebsd-gcc. >>>>>=20 >>>>=20 >>>> It seems WITHOUT_CLANG_IS_CC=3D1 is also needed. >>>>=20 >>>> Sigh... >>>>=20 >>>=20 >>> Also, this is "cute"... >>>=20 >>> armv6-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail >>> = /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf3= 2-arm.c:9138 >>> gmake: *** [u-boot] Segmentation fault (core dumped) >>> gmake: *** Deleting file `u-boot' >>>=20 >>> If there is going to be any expectation for armv6 being a tier-1 >>> architecture, well, it just isn't going to work with the current = state >>> of things. >>=20 >> And I=92m getting >>=20 >> rm -f .depend >> mkdep -f .depend -a = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include =85 >> cc: error trying to exec 'cc1plus': execvp: No such file or directory >> cc: error trying to exec 'cc1plus': execvp: No such file or directory >> cc: error trying to exec 'cc1plus': execvp: No such file or directory >> cc: error trying to exec 'cc1plus': execvp: No such file or directory >> cc: error trying to exec 'cc1plus': execvp: No such file or directory >> : >> : >>=20 >>=20 >> Full log available on request, but I have some other nasty hacks in = place (that have relevance mainly during the full build; I null-mount = src/ and ports/ instead of checking them out). >>=20 >> M >=20 > I find that to switch compilers I now need all of this in make.conf: >=20 > WITHOUT_CLANG=3Dyes > WITHOUT_CLANG_IS_CC=3Dyes > WITH_GCC=3Dyes > WITH_GNUCXX=3Dyes >=20 > It used to be sufficient to say WITHOUT_CLANG_IS_CC, but now you need = to > throw multiple switches at once to get the old behavior. I for one think CLANG_IS_CC is a crock of crap. I was told several = BSDcans ago that it was a temporary thing, but its staying power is distressing. I=92d = rather see the following: DEFAULT_COMPILER {clang,gcc} when set, causes a = symlink from = cc to this value. In an ideal world = this could also be something like = /usr/local/bin/gcc48 too. BOOTSTRAP_COMPILER {clang,gcc,external} which compiler is build to = bootstrap = the system. If unset, it defaults to the = DEFAULT_COMPILER You=92d set MK_{CLANG,GCC,GNUCXX} based on these values before = processing WITH/WITHOUT_FOO (which would also allow someone to override what=92s = built if the logic was wrong. Warner From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 16:48:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E56AF906; Wed, 16 Apr 2014 16:48:24 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEABD159C; Wed, 16 Apr 2014 16:48:24 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 1DC7874763; Wed, 16 Apr 2014 09:48:24 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 28664-01-8; Wed, 16 Apr 2014 09:48:23 -0700 (PDT) Received: from [10.8.0.26] (unknown [10.8.0.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 8789F743D4; Wed, 16 Apr 2014 09:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1397666540; bh=PBP6EbGEECga6LTdoph++jx1OH05c1TsEuazTRMIInU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=NCbxie6OYa7Um63lO49tv85DL9tTKsJNTPTW2+PHkibm1tvd5hOl38C+fvYvP/IIt 5uu+t2OzTfWcAHAjeTD6TWc17AyR3/xThW0s/vIuek1Rbh+Rz4rpW0aUtNmjb0ZSwG Hq5S3sY1etijRVYpKYoCdc18VDGENgd6ctjKMq08= Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: What happened to 11-Current ARM From: Jordan Hubbard In-Reply-To: <40D86548-EA3E-49D5-B95B-97BAC7AFB716@bsdimp.com> Date: Wed, 16 Apr 2014 21:42:13 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2095B803-D86F-4B1C-AE0D-575D8C878BC0@ixsystems.com> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> <20140415221934.GH33565@glenbarber.us> <20140415232211.GI33565@glenbarber.us> <20140416015925.GM33565@glenbarber.us> <1397654459.1124.136.camel@revolution.hippie.lan> <40D86548-EA3E-49D5-B95B-97BAC7AFB716@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1874) Cc: Glen Barber , freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:48:25 -0000 On Apr 16, 2014, at 9:24 PM, Warner Losh wrote: > DEFAULT_COMPILER {clang,gcc} when set, causes a = symlink from > = cc to this value. In an ideal world > = this could also be something like > = /usr/local/bin/gcc48 too. I=92d personally find it more than a little odd to have a setting in = /etc/make.conf in conjunction with a build create side-effects in my = filesystem such that this behavior results: # cc -v Using built-in specs. Target: amd64-undermydesk-freebsd =85 # cd /usr/src; make buildworld # cc -v FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 .. In other words, a build that was formerly not mutagenic to the build = system now becomes mutagenic, unless you had some other value of =93cc=94 = in mind than /usr/bin/cc? Why not simply follow existing precedent and introduce a cc-select = command that sets up all of the appropriate symlinks? Then at least = rather than setting a DEFAULT_COMPILER in /etc/make.conf you just run = the command explicitly to change the default compiler and there are no = surprises, since you did it explicitly. - Jordan From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 17:00:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1A8AB95 for ; Wed, 16 Apr 2014 17:00:15 +0000 (UTC) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75CA616A1 for ; Wed, 16 Apr 2014 17:00:15 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id rl12so10721361iec.22 for ; Wed, 16 Apr 2014 10:00:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=5isRAoKi7/447vHKdvikskjlUpv0uxoK5IffajGkp7w=; b=mX7lPGvqJwgAznDiCb6AmIjYcDH3A62YjrQVR3s6kY6qqVT96SXqNUtosTdizPQ9ME fvozMLrPNbkJbTnmsDz1BmQtSnxX9ZB3JaReLINH7MeZY0Ep1L/JQ+0LCqsaGIKsT7KS en/iIf+Ym91XVLQMKjp+AsEUzItS7SMzQnM58TzZ54lDJlkxt7kxwRHtfBN7Ky1fpCOc iMf1AX4xHwXqdS64yigsZITvqLkRfWViiJ2ibIV2xRQqQrez+Tq35wSCQT+wBJ1yiXUj QQJI7HGeksGlBh5Ah8JKWUGJuV2er03w5ItsDwva1Zyqxvkf5EUN5yHdevCDTdo9N9Va kCzw== X-Gm-Message-State: ALoCoQnlOnxuDGHoPzRn/xOg+F0OCN0zrpdZBq3aO3J5K6xz1JnJfSg6T7hGDlHkw6aHAjuDERDe X-Received: by 10.42.98.145 with SMTP id s17mr2833586icn.73.1397667609502; Wed, 16 Apr 2014 10:00:09 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ie20sm47308107igb.10.2014.04.16.10.00.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 10:00:08 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: What happened to 11-Current ARM From: Warner Losh In-Reply-To: <2095B803-D86F-4B1C-AE0D-575D8C878BC0@ixsystems.com> Date: Wed, 16 Apr 2014 11:00:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0AFC65DC-59EF-43C2-B96D-720741D31F15@bsdimp.com> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> <20140415221934.GH33565@glenbarber.us> <20140415232211.GI33565@glenbarber.us> <20140416015925.GM33565@glenbarber.us> <1397654459.1124.136.camel@revolution.hippie.lan> <40D86548-EA3E-49D5-B95B-97BAC7AFB716@bsdimp.com> <2095B803-D86F-4B1C-AE0D-575D8C878BC0@ixsystems.com> To: Jordan Hubbard X-Mailer: Apple Mail (2.1874) Cc: Glen Barber , freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:00:15 -0000 On Apr 16, 2014, at 10:42 AM, Jordan Hubbard wrote: >=20 > On Apr 16, 2014, at 9:24 PM, Warner Losh wrote: >=20 >> DEFAULT_COMPILER {clang,gcc} when set, causes a = symlink from >> = cc to this value. In an ideal world >> = this could also be something like >> = /usr/local/bin/gcc48 too. >=20 > I=92d personally find it more than a little odd to have a setting in = /etc/make.conf in conjunction with a build create side-effects in my = filesystem such that this behavior results: >=20 > # cc -v > Using built-in specs. > Target: amd64-undermydesk-freebsd > =85 > # cd /usr/src; make buildworld > # cc -v > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > .. >=20 > In other words, a build that was formerly not mutagenic to the build = system now becomes mutagenic, unless you had some other value of =93cc=94 = in mind than /usr/bin/cc? I=92m talking installworld here, not buildworld, so I don=92t think this = point is at all relevant. the behavior you describe wouldn=92t happen. = What you suggest would never happen, and the build wouldn=92t suddenly = become mutagenic. > Why not simply follow existing precedent and introduce a cc-select = command that sets up all of the appropriate symlinks? Then at least = rather than setting a DEFAULT_COMPILER in /etc/make.conf you just run = the command explicitly to change the default compiler and there are no = surprises, since you did it explicitly. Since your premise is wrong, the solution is wrong as well. All the = above would do is replace the really quite horrible CLANG_IS_CC with = something slightly more flexible and allow us to delete that from the = tree forever. The base behavior wouldn=92t change as far as what happens = to the the host system. Warner From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 17:05:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00273C60; Wed, 16 Apr 2014 17:05:26 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD2661755; Wed, 16 Apr 2014 17:05:26 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 1852D74F7B; Wed, 16 Apr 2014 10:05:26 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 32320-02; Wed, 16 Apr 2014 10:05:25 -0700 (PDT) Received: from [10.8.0.26] (unknown [10.8.0.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id EF3E574EDA; Wed, 16 Apr 2014 10:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1397667856; bh=ctoCwvl8AJ2te2DdpmoeTScG9HdxoeczWpctWqG8lqI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=mhJMaFisPtM89UA1PKq3TzWVyvNA3JU4B0qeXKY7nZppDLKtQMp1Hk8br3bMNhlKn TijTqI+3p6PXvHx2QdjeUWA9JWdtrldgeAX9V9rq9qerk06nMmGMinq3RVTeDn/elt jHJpADknFZUOa2dHe6NgfRF954Wqw8b1f35zncWU= Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: What happened to 11-Current ARM From: Jordan Hubbard In-Reply-To: <0AFC65DC-59EF-43C2-B96D-720741D31F15@bsdimp.com> Date: Wed, 16 Apr 2014 22:04:08 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: <89A4167B-D8BC-4EEC-A604-25F1A78EBC73@ixsystems.com> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> <20140415221934.GH33565@glenbarber.us> <20140415232211.GI33565@glenbarber.us> <20140416015925.GM33565@glenbarber.us> <1397654459.1124.136.camel@revolution.hippie.lan> <40D86548-EA3E-49D5-B95B-97BAC7AFB716@bsdimp.com> <2095B803-D86F-4B1C-AE0D-575D8C878BC0@ixsystems.com> <0AFC65DC-59EF-43C2-B96D-720741D31F15@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1874) Cc: Glen Barber , freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:05:27 -0000 On Apr 16, 2014, at 10:00 PM, Warner Losh wrote: > I=92m talking installworld here, not buildworld, so I don=92t think = this point is at all relevant. the behavior you describe wouldn=92t = happen. What you suggest would never happen, and the build wouldn=92t = suddenly become mutagenic. Got it. I withdraw my concern then! From owner-freebsd-arm@FreeBSD.ORG Wed Apr 16 19:44:55 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07B157DD; Wed, 16 Apr 2014 19:44:55 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3D0918E6; Wed, 16 Apr 2014 19:44:49 +0000 (UTC) Received: from [2001:470:9174:1:d011:3906:1218:6b9a] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WaVl8-0006jP-2c; Wed, 16 Apr 2014 20:44:46 +0100 Subject: Re: What happened to 11-Current ARM Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4C2E7D32-547A-44CB-9D5F-F0C6A55A9E8C"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <1397654459.1124.136.camel@revolution.hippie.lan> Date: Wed, 16 Apr 2014 20:44:51 +0100 Message-Id: <9E9C0B7B-E66E-428B-81DD-FDB3EF51BCEB@FreeBSD.org> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> <20140415221934.GH33565@glenbarber.us> <20140415232211.GI33565@glenbarber.us> <20140416015925.GM33565@glenbarber.us> <1397654459.1124.136.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) X-SA-Score: -1.0 Cc: Glen Barber , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 19:44:55 -0000 --Apple-Mail=_4C2E7D32-547A-44CB-9D5F-F0C6A55A9E8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1251 On 16 Apr 2014, at 14:20, Ian Lepore wrote: > I find that to switch compilers I now need all of this in make.conf: >=20 > WITHOUT_CLANG=3Dyes > WITHOUT_CLANG_IS_CC=3Dyes > WITH_GCC=3Dyes > WITH_GNUCXX=3Dyes >=20 > It used to be sufficient to say WITHOUT_CLANG_IS_CC, but now you need = to > throw multiple switches at once to get the old behaviour. My issue is that I want CLANG, but I have to have this bloody GCC just = to build u-boot. Right now, I=92d happily take GCC outside and shoot it! ;-) M --=20 Mark R V Murray --Apple-Mail=_4C2E7D32-547A-44CB-9D5F-F0C6A55A9E8C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU07duN58vKOKE6LNAQqOPAQArVP8kvfWw58y9DhxJiM9lECTQozRDrbI aiNDH5XOkt77/SDlT4Udtl9p/hAfRXiJY6eoTGTp571woQtdTRUq8Ot1y+0PoIB2 PvM/7bvSKRv1tUZEpCmH3O2Vsp8Es5pug6RGJaIi9GkEJC8/kxiPOdv+m865iwzs GquUz4EkG44= =192D -----END PGP SIGNATURE----- --Apple-Mail=_4C2E7D32-547A-44CB-9D5F-F0C6A55A9E8C-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 01:25:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8286C23 for ; Thu, 17 Apr 2014 01:25:48 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BAD9B1FE6 for ; Thu, 17 Apr 2014 01:25:48 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id x10so11360493pdj.34 for ; Wed, 16 Apr 2014 18:25:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=STavD8qn05rbIN4YCaGZY9eHG4EW8EO7aZXojtzxKDQ=; b=bAukHTrkIhTzFvhcjr00NDIxPYMFnB5A6S1+GPy2fSYAg5sAS9hrG0WPztvHTHtGMx A/GkjsDMt8/rEPx0Xn3dYM+6Cx2cM5iDiBGOrQ4lWGrIOpQvscb09qnFQR1DBoZOYO06 0maZX61E/gXtQmsfaPo1vIic0CoCt7vUMmq52vJoIpfE/mmmRTSeor8PoV1UTbAL2Nw2 /FXKslDLBPfpHI3y8++WhOWiLhsKryUXPYPokcyNnCjO/FV4uNg8NJgMnafSNS05wSFD TXC+L26Qi4erCqs/O7fGOdiQWoOT5TSqDdLgPdWTrCg87O4ZzFuldZKhD0BNIiojaBqC wiKg== X-Gm-Message-State: ALoCoQlW03aMRHvmRblIHJjA8pkh3/crpnRYiqPf3g764dLtkXplaEfm46XPcypZxOcVQHxlUNmJ X-Received: by 10.66.221.4 with SMTP id qa4mr12252727pac.138.1397697942106; Wed, 16 Apr 2014 18:25:42 -0700 (PDT) Received: from [192.168.1.2] (c-50-156-22-189.hsd1.ca.comcast.net. [50.156.22.189]) by mx.google.com with ESMTPSA id pe3sm49784443pbc.23.2014.04.16.18.25.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 18:25:41 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Tim Kientzle In-Reply-To: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> Date: Wed, 16 Apr 2014 18:25:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 01:25:49 -0000 On Apr 15, 2014, at 12:23 PM, Mark R V Murray wrote: > Hi Tim >=20 > I=92ve been doing some local hacks to cross-build ARM/RPI releases on = CURRENT/AMD64. >=20 > What I=92m doing aren=92t clean releases in that I want to use the = state of /usr/src and /usr/ports =93as-is=94 and not a clean check out. = This allows me to experimentally break stuff without having to check it = in first. It also give me a way to build bootable images for when (not = =93if=94!) I mess things up properly on the RPI. It has the advantage = also of being quicker than the usual release build. >=20 > (The hacks, as they stand now, are attached. I null-mount /usr/src and = /usr/ports instead of checking them out, and I have local checkouts of = crochet and u-boot to copy as checking them out during a release build = fails too often.) >=20 > The problem is that sometime in the last month or so, things stopped = working, and its taken me until now to have the time to have a look at = it. >=20 > The problem is that during the u-boot build, a CLANG-based xdev build = is used, and this has no *-gcc, only a *-cc. If I fix that with a = symlink, clang then objects to the -ffixed-r8 option. Clang has an = equivalent -ffixed-r9, but the u-boot that is mandated for = FreeBSD/Arm/RPI use doesn=92t have the R9 fix. >=20 > Questions: >=20 > 1) Are you aware of any of this? Yes. >=20 > 2) Do you have a quick fix idea (preferably not involving GCC)? No. Right now, the =93get it working=94 answer is to install GCC XDEV tools. Though I tried that on a clean system last weekend and it still failed to build. Haven=92t tracked down why. >=20 > I=92m rather short of time right now, but may be able to get to this = over Easter. Long-term, we=92d all like to see U-Boot build with clang. No idea yet whether that=92s hard or not. No idea if I=92ll have time to work on it in the near future. Tim From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 04:17:59 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 848A3126; Thu, 17 Apr 2014 04:17:59 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A2141F7F; Thu, 17 Apr 2014 04:17:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3H4Hx7s057409; Thu, 17 Apr 2014 04:17:59 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3H4Hwm6057408; Thu, 17 Apr 2014 04:17:58 GMT (envelope-from linimon) Date: Thu, 17 Apr 2014 04:17:58 GMT Message-Id: <201404170417.s3H4Hwm6057408@freefall.freebsd.org> To: ike@blackskyresearch.net, linimon@FreeBSD.org, freebsd-arm@FreeBSD.org, linimon@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: arm/175803: building xdev for arm failing X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 04:17:59 -0000 Synopsis: building xdev for arm failing State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Thu Apr 17 04:15:59 UTC 2014 State-Changed-Why: to submitter: xdev has recently been reworked. Is this PR now obsolete? Responsible-Changed-From-To: freebsd-arm->linimon Responsible-Changed-By: linimon Responsible-Changed-When: Thu Apr 17 04:15:59 UTC 2014 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=175803 From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 07:23:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6C47674 for ; Thu, 17 Apr 2014 07:23:13 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9BE7712B7 for ; Thu, 17 Apr 2014 07:23:13 +0000 (UTC) Received: from [2001:470:9174:1:f8c1:b412:e2cf:d4d8] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Wagf4-0007jK-GB; Thu, 17 Apr 2014 08:23:10 +0100 Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_75E63320-1399-4E3C-A0F3-2331E2FAADB4"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: Date: Thu, 17 Apr 2014 08:23:28 +0100 Message-Id: <4B9FEF94-9912-4861-9FE2-E8EC7BE3509C@grondar.org> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1874) X-SA-Score: -1.0 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 07:23:14 -0000 --Apple-Mail=_75E63320-1399-4E3C-A0F3-2331E2FAADB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 17 Apr 2014, at 02:25, Tim Kientzle wrote: >> The problem is that during the u-boot build, a CLANG-based xdev build = is used, and this has no *-gcc, only a *-cc. If I fix that with a = symlink, clang then objects to the -ffixed-r8 option. Clang has an = equivalent -ffixed-r9, but the u-boot that is mandated for = FreeBSD/Arm/RPI use doesn=92t have the R9 fix. >>=20 >> Questions: >>=20 >> 1) Are you aware of any of this? >=20 > Yes. >=20 >>=20 >> 2) Do you have a quick fix idea (preferably not involving GCC)? >=20 > No. >=20 > Right now, the =93get it working=94 answer is to install GCC XDEV = tools. Even that was broken, but I have it fixed now, locally. I=92ll tidy up = the patches and send them all out later. > Though I tried that on a clean system last weekend and it > still failed to build. Haven=92t tracked down why. src/release/arm/release.sh needs this: @@ -96,27 +96,27 @@ # This is not '-j'-safe, so force '-j1' to allow using # additional, non-'-j' options specified in WORLD_FLAGS. eval chroot ${CHROOTDIR} make -C /usr/src/gnu/usr.bin/cc \ - WITH_GCC=3D1 ${WORLD_FLAGS} -j1 obj depend all install + WITH_GCC=3D1 WITH_GNUXX=3D1 ${WORLD_FLAGS} -j1 obj = depend all install # Build the 'xdev' target for crochet. - eval chroot ${CHROOTDIR} make -C /usr/src WITHOUT_CLANG_IS_CC=3D1 = \ - XDEV=3D${XDEV} XDEV_ARCH=3D${XDEV_ARCH} WITH_GCC=3D1 \ + eval chroot ${CHROOTDIR} make -C /usr/src WITHOUT_CLANG_IS_CC=3D1 = WITHOUT_CLANG=3D1 \ + XDEV=3D${XDEV} XDEV_ARCH=3D${XDEV_ARCH} WITH_GCC=3D1 = WITH_GNUXX=3D1 \ ${WORLD_FLAGS} xdev =20 # Run the ldconfig(8) startup script so = /var/run/ld-elf*.so.hints # is created. >> I=92m rather short of time right now, but may be able to get to this = over Easter. >=20 > Long-term, we=92d all like to see U-Boot build with clang. >=20 > No idea yet whether that=92s hard or not. No idea if > I=92ll have time to work on it in the near future. How much hacking does u-boot need for 1) FreeBSD and 2) RPI? Should its head-of-trunk =93just work=94? They have apparently sorted = out the R8/R9 business which should make it CLANG-ready, IIUC. M --=20 Mark R V Murray --Apple-Mail=_75E63320-1399-4E3C-A0F3-2331E2FAADB4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU0+BcN58vKOKE6LNAQotqgP+M/dMc1VRs6ViyKmpE6PRr+O1GCp36fbD RcF+dhGN1mGik6GP/apsveev9prBfNlddzp61596XQKytBF8vjGvMcXLrTDQkqyX I54bBzGrAhu6VAUHDwXwcCYX170SraQDrZvLGaU6YWZbqyjIn9FafaQYxh6M1kqO AtVWiY0xS78= =U0fj -----END PGP SIGNATURE----- --Apple-Mail=_75E63320-1399-4E3C-A0F3-2331E2FAADB4-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 10:31:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06C3B3C6 for ; Thu, 17 Apr 2014 10:31:53 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D2FF1898 for ; Thu, 17 Apr 2014 10:31:51 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3HAVOCn027745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Apr 2014 12:31:24 +0200 (CEST) (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 s3HAVIAR037181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2014 12:31:18 +0200 (CEST) (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 s3HAVIQC044314; Thu, 17 Apr 2014 12:31:18 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3HAVHCa044313; Thu, 17 Apr 2014 12:31:17 +0200 (CEST) (envelope-from ticso) Date: Thu, 17 Apr 2014 12:31:17 +0200 From: Bernd Walter To: Tim Kientzle Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. Message-ID: <20140417103117.GE44138@cicely7.cicely.de> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> 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 , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 10:31:53 -0000 On Wed, Apr 16, 2014 at 06:25:39PM -0700, Tim Kientzle wrote: > > On Apr 15, 2014, at 12:23 PM, Mark R V Murray wrote: > > > Hi Tim > > > > I?ve been doing some local hacks to cross-build ARM/RPI releases on CURRENT/AMD64. > > > > What I?m doing aren?t clean releases in that I want to use the state of /usr/src and /usr/ports ?as-is? and not a clean check out. This allows me to experimentally break stuff without having to check it in first. It also give me a way to build bootable images for when (not ?if?!) I mess things up properly on the RPI. It has the advantage also of being quicker than the usual release build. > > > > (The hacks, as they stand now, are attached. I null-mount /usr/src and /usr/ports instead of checking them out, and I have local checkouts of crochet and u-boot to copy as checking them out during a release build fails too often.) > > > > The problem is that sometime in the last month or so, things stopped working, and its taken me until now to have the time to have a look at it. > > > > The problem is that during the u-boot build, a CLANG-based xdev build is used, and this has no *-gcc, only a *-cc. If I fix that with a symlink, clang then objects to the -ffixed-r8 option. Clang has an equivalent -ffixed-r9, but the u-boot that is mandated for FreeBSD/Arm/RPI use doesn?t have the R9 fix. > > > > Questions: > > > > 1) Are you aware of any of this? > > Yes. > > > > > 2) Do you have a quick fix idea (preferably not involving GCC)? > > No. > > Right now, the ?get it working? answer is to install GCC XDEV tools. > > Though I tried that on a clean system last weekend and it > still failed to build. Haven?t tracked down why. > > > > > I?m rather short of time right now, but may be able to get to this over Easter. > > Long-term, we?d all like to see U-Boot build with clang. > > No idea yet whether that?s hard or not. No idea if > I?ll have time to work on it in the near future. What are the symptoms with clang U-Boot? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 12:44:39 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F68D844 for ; Thu, 17 Apr 2014 12:44:39 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 200521761 for ; Thu, 17 Apr 2014 12:44:39 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WalgD-000DcH-Rl; Thu, 17 Apr 2014 12:44:38 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3HCiXWA003235; Thu, 17 Apr 2014 06:44:34 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1//4D3hJ/R4Wo7wSo7XV7Cd Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Ian Lepore To: Mark R V Murray In-Reply-To: <4B9FEF94-9912-4861-9FE2-E8EC7BE3509C@grondar.org> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <4B9FEF94-9912-4861-9FE2-E8EC7BE3509C@grondar.org> Content-Type: text/plain; charset="iso-8859-13" Date: Thu, 17 Apr 2014 06:44:33 -0600 Message-ID: <1397738673.1124.153.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s3HCiXWA003235 Cc: Tim Kientzle , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 12:44:39 -0000 On Thu, 2014-04-17 at 08:23 +0100, Mark R V Murray wrote: > On 17 Apr 2014, at 02:25, Tim Kientzle wrote: >=20 > >> The problem is that during the u-boot build, a CLANG-based xdev buil= d is used, and this has no *-gcc, only a *-cc. If I fix that with a symli= nk, clang then objects to the -ffixed-r8 option. Clang has an equivalent = -ffixed-r9, but the u-boot that is mandated for FreeBSD/Arm/RPI use does= n=FFt have the R9 fix. > >>=20 > >> Questions: > >>=20 > >> 1) Are you aware of any of this? > >=20 > > Yes. > >=20 > >>=20 > >> 2) Do you have a quick fix idea (preferably not involving GCC)? > >=20 > > No. > >=20 > > Right now, the =B4get it working=A1 answer is to install GCC XDEV too= ls. >=20 > Even that was broken, but I have it fixed now, locally. I=FFll tidy up = the patches and send them all out later. >=20 > > Though I tried that on a clean system last weekend and it > > still failed to build. Haven=FFt tracked down why. >=20 > src/release/arm/release.sh needs this: >=20 > @@ -96,27 +96,27 @@ > # This is not '-j'-safe, so force '-j1' to allow using > # additional, non-'-j' options specified in WORLD_FLAGS. > eval chroot ${CHROOTDIR} make -C /usr/src/gnu/usr.bin/cc \ > - WITH_GCC=3D1 ${WORLD_FLAGS} -j1 obj depend all install > + WITH_GCC=3D1 WITH_GNUXX=3D1 ${WORLD_FLAGS} -j1 obj depe= nd all install > # Build the 'xdev' target for crochet. > - eval chroot ${CHROOTDIR} make -C /usr/src WITHOUT_CLANG_IS_CC=3D= 1 \ > - XDEV=3D${XDEV} XDEV_ARCH=3D${XDEV_ARCH} WITH_GCC=3D1 \ > + eval chroot ${CHROOTDIR} make -C /usr/src WITHOUT_CLANG_IS_CC=3D= 1 WITHOUT_CLANG=3D1 \ > + XDEV=3D${XDEV} XDEV_ARCH=3D${XDEV_ARCH} WITH_GCC=3D1 WI= TH_GNUXX=3D1 \ > ${WORLD_FLAGS} xdev > =20 WITH_GNUXX doesn't seem right, shouldn't that be WITH_GNUCXX? If you generated that with diff rather than typing from memory, then maybe that port of the change isn't what fixes things and only WITH_GCC is needed. > # Run the ldconfig(8) startup script so /var/run/ld-elf*.so.hin= ts > # is created. >=20 > >> I=FFm rather short of time right now, but may be able to get to this= over Easter. > >=20 > > Long-term, we=FFd all like to see U-Boot build with clang. > >=20 > > No idea yet whether that=FFs hard or not. No idea if > > I=FFll have time to work on it in the near future. >=20 > How much hacking does u-boot need for 1) FreeBSD and 2) RPI? >=20 > Should its head-of-trunk =B4just work=A1? They have apparently sorted o= ut the R8/R9 business which should make it CLANG-ready, IIUC. >=20 > M From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 12:49:26 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 132D690F for ; Thu, 17 Apr 2014 12:49:26 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D914217A4 for ; Thu, 17 Apr 2014 12:49:25 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Walkq-000Gg9-UG; Thu, 17 Apr 2014 12:49:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3HCnLqf003242; Thu, 17 Apr 2014 06:49:21 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+cmEjErxZHRWWDSPF1Jj2t Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20140417103117.GE44138@cicely7.cicely.de> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 2014 06:49:21 -0600 Message-ID: <1397738961.1124.157.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 12:49:26 -0000 On Thu, 2014-04-17 at 12:31 +0200, Bernd Walter wrote: > On Wed, Apr 16, 2014 at 06:25:39PM -0700, Tim Kientzle wrote: > > > > On Apr 15, 2014, at 12:23 PM, Mark R V Murray wrote: > > > > > Hi Tim > > > > > > I?ve been doing some local hacks to cross-build ARM/RPI releases on CURRENT/AMD64. > > > > > > What I?m doing aren?t clean releases in that I want to use the state of /usr/src and /usr/ports ?as-is? and not a clean check out. This allows me to experimentally break stuff without having to check it in first. It also give me a way to build bootable images for when (not ?if?!) I mess things up properly on the RPI. It has the advantage also of being quicker than the usual release build. > > > > > > (The hacks, as they stand now, are attached. I null-mount /usr/src and /usr/ports instead of checking them out, and I have local checkouts of crochet and u-boot to copy as checking them out during a release build fails too often.) > > > > > > The problem is that sometime in the last month or so, things stopped working, and its taken me until now to have the time to have a look at it. > > > > > > The problem is that during the u-boot build, a CLANG-based xdev build is used, and this has no *-gcc, only a *-cc. If I fix that with a symlink, clang then objects to the -ffixed-r8 option. Clang has an equivalent -ffixed-r9, but the u-boot that is mandated for FreeBSD/Arm/RPI use doesn?t have the R9 fix. > > > > > > Questions: > > > > > > 1) Are you aware of any of this? > > > > Yes. > > > > > > > > 2) Do you have a quick fix idea (preferably not involving GCC)? > > > > No. > > > > Right now, the ?get it working? answer is to install GCC XDEV tools. > > > > Though I tried that on a clean system last weekend and it > > still failed to build. Haven?t tracked down why. > > > > > > > > I?m rather short of time right now, but may be able to get to this over Easter. > > > > Long-term, we?d all like to see U-Boot build with clang. > > > > No idea yet whether that?s hard or not. No idea if > > I?ll have time to work on it in the near future. > > What are the symptoms with clang U-Boot? > U-boot requires that a global register be set aside by the compiler and it's used to access all global vars. As I vaguely understand it, u-boot used to want r8 for this, and clang didn't used to support the concept at all. Now clang supports it, but only for r9, and apparently more recent u-boot expects r9 rather than r8. So the fix is probably to use more recent u-boot sources (I've been using 2014.01 for imx6 stuff), and probably to add the new -ffixed-r9 flag for a clang build. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 18:01:24 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D1AD437; Thu, 17 Apr 2014 18:01:24 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 601271DDF; Thu, 17 Apr 2014 18:01:24 +0000 (UTC) Received: from [2001:470:9174:1:f8c1:b412:e2cf:d4d8] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WaqcZ-0008jX-Nb; Thu, 17 Apr 2014 19:01:20 +0100 Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9F8B3F32-4CE3-436D-9819-4A8E7A8EB14B"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <1397738961.1124.157.camel@revolution.hippie.lan> Date: Thu, 17 Apr 2014 19:01:31 +0100 Message-Id: References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) X-SA-Score: -1.0 Cc: Tim Kientzle , freebsd-arm , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 18:01:24 -0000 --Apple-Mail=_9F8B3F32-4CE3-436D-9819-4A8E7A8EB14B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 17 Apr 2014, at 13:49, Ian Lepore wrote: > U-boot requires that a global register be set aside by the compiler = and > it's used to access all global vars. As I vaguely understand it, = u-boot > used to want r8 for this, and clang didn't used to support the concept > at all. Now clang supports it, but only for r9, and apparently more > recent u-boot expects r9 rather than r8. So the fix is probably to = use > more recent u-boot sources (I've been using 2014.01 for imx6 stuff), = and > probably to add the new -ffixed-r9 flag for a clang build. Correct. The pig in trying to build u-boot 2004.04 with Clang/XDEV is the use of #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t = *gd asm ("r9=94) which means =93gd is an alias for the r9 register and is a pointer to = type =85=94 =85 I think. :-) Clang doesn=92t like this one bit. First objection is to =93global = register variables=94, so if I experimentally knock out the =93register=94= , I simply get the second objection - to "multiple instances of the r9 = global variable=94. Googling a bit suggests that Clang just plain can=92t do this. :-( M --=20 Mark R V Murray --Apple-Mail=_9F8B3F32-4CE3-436D-9819-4A8E7A8EB14B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU1AW/958vKOKE6LNAQrR9wP8DMQ8uE2b/wnYmacp3WBinrKQKcle5EjQ YhGVIZvXiqfksXv0k8lVkrlbeTDwg90BqMxhnFGIUdf9/XrohBlK2blw1S4eTL+q 7TjerwJP9MDVgjyLCxsrqXHz1VVLrJl2FHbukrkj2MHK7DnOq8YQDe/x4yaeyNyg LRuOkgbzC0s= =aAjc -----END PGP SIGNATURE----- --Apple-Mail=_9F8B3F32-4CE3-436D-9819-4A8E7A8EB14B-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 19:07:19 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D2A1D9 for ; Thu, 17 Apr 2014 19:07:19 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CD31170D for ; Thu, 17 Apr 2014 19:07:18 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WareS-000FbS-FO; Thu, 17 Apr 2014 19:07:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3HJ78Kh003582; Thu, 17 Apr 2014 13:07:09 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+gWhi072JmlZc0VyywHvnF Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Ian Lepore To: Mark R V Murray In-Reply-To: References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> Content-Type: text/plain; charset="windows-1251" Date: Thu, 17 Apr 2014 13:07:08 -0600 Message-ID: <1397761628.1124.245.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s3HJ78Kh003582 Cc: Tim Kientzle , freebsd-arm , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:07:19 -0000 On Thu, 2014-04-17 at 19:01 +0100, Mark R V Murray wrote: > On 17 Apr 2014, at 13:49, Ian Lepore wrote: >=20 > > U-boot requires that a global register be set aside by the compiler a= nd > > it's used to access all global vars. As I vaguely understand it, u-b= oot > > used to want r8 for this, and clang didn't used to support the concep= t > > at all. Now clang supports it, but only for r9, and apparently more > > recent u-boot expects r9 rather than r8. So the fix is probably to u= se > > more recent u-boot sources (I've been using 2014.01 for imx6 stuff), = and > > probably to add the new -ffixed-r9 flag for a clang build. >=20 > Correct. >=20 > The pig in trying to build u-boot 2004.04 with Clang/XDEV is the use of >=20 > #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *= gd asm ("r9=94) >=20 > which means =93gd is an alias for the r9 register and is a pointer to t= ype =85=94 >=20 > =85 I think. :-) >=20 > Clang doesn=92t like this one bit. First objection is to =93global regi= ster variables=94, so if I experimentally knock out the =93register=94, I= simply get the second objection - to "multiple instances of the r9 globa= l variable=94. >=20 > Googling a bit suggests that Clang just plain can=92t do this. :-( >=20 > M Hmmm. After a bit of poking around in the llvm code, it looks like the full extent of the support for -ffixed-r9 is that it doesn't consider that register available for use by the code generator; that's only part of what u-boot needs. =20 Some online notes I found for clang 3.5 claim that global register variables aren't supported, and aren't likely to be any time soon. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 19:14:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D092C251 for ; Thu, 17 Apr 2014 19:14:33 +0000 (UTC) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EA9517B4 for ; Thu, 17 Apr 2014 19:14:33 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id z10so672421pdj.32 for ; Thu, 17 Apr 2014 12:14:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hmjn4xwjony83XL39+pMLmAFflAmEsPYsIjLE2LVpKk=; b=TGQwoOQPp1jb9T1Yw72fzroOY7vDFcOjzrGtSWos7829e7vd6HOjpMAhaVOx/3vV4y 0HaIJDlugxcqZelSJNnXmDFmp+DTtjhV7DmDy2yJhb+yt8xzMeUsPSDbwkYndU5cNAS7 tN45c2lPufgLNREUY8DoLGdb36E3DHISoSVYZ1/lbb0VTEuUJMSeyZxgRqF2n41iQKrT 0NJvS+JJivaW02/6PPoooo7ssuf6TnrqJxJK50WX4j+w73HhCh1b1zovRITFPWH7Wqu9 XPKvFq0PWpnbV7GiHMMAr5cKtntXyZvHUwbHmOgPsycku/yGcIAF94i8LPU1fQWjcINw U3xg== X-Gm-Message-State: ALoCoQmE7Mymo1ONZeT9fL1cXvAltHFrgr4NfB0vxg5bSB4A7Vmdvj8cpN7CpUEbQoTMSObe/4we X-Received: by 10.68.240.34 with SMTP id vx2mr17408189pbc.1.1397762067575; Thu, 17 Apr 2014 12:14:27 -0700 (PDT) Received: from lgmac-ckapadia.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id cz3sm55210763pbc.9.2014.04.17.12.14.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 12:14:26 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Warner Losh In-Reply-To: <1397761628.1124.245.camel@revolution.hippie.lan> Date: Thu, 17 Apr 2014 13:14:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7196A020-54E1-42FA-B8A0-25B145B0E412@bsdimp.com> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> <1397761628.1124.245.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: Tim Kientzle , freebsd-arm , ticso@cicely.de, Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:14:34 -0000 On Apr 17, 2014, at 1:07 PM, Ian Lepore wrote: > On Thu, 2014-04-17 at 19:01 +0100, Mark R V Murray wrote: >> On 17 Apr 2014, at 13:49, Ian Lepore wrote: >>=20 >>> U-boot requires that a global register be set aside by the compiler = and >>> it's used to access all global vars. As I vaguely understand it, = u-boot >>> used to want r8 for this, and clang didn't used to support the = concept >>> at all. Now clang supports it, but only for r9, and apparently more >>> recent u-boot expects r9 rather than r8. So the fix is probably to = use >>> more recent u-boot sources (I've been using 2014.01 for imx6 stuff), = and >>> probably to add the new -ffixed-r9 flag for a clang build. >>=20 >> Correct. >>=20 >> The pig in trying to build u-boot 2004.04 with Clang/XDEV is the use = of >>=20 >> #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t = *gd asm ("r9=94) >>=20 >> which means =93gd is an alias for the r9 register and is a pointer to = type =85=94 >>=20 >> =85 I think. :-) >>=20 >> Clang doesn=92t like this one bit. First objection is to =93global = register variables=94, so if I experimentally knock out the =93register=94= , I simply get the second objection - to "multiple instances of the r9 = global variable=94. >>=20 >> Googling a bit suggests that Clang just plain can=92t do this. :-( >>=20 >> M >=20 > Hmmm. After a bit of poking around in the llvm code, it looks like = the > full extent of the support for -ffixed-r9 is that it doesn't consider > that register available for use by the code generator; that's only = part > of what u-boot needs. =20 what=92s the other part? Global register variables like this? > Some online notes I found for clang 3.5 claim that global register > variables aren't supported, and aren't likely to be any time soon. Is that a poke in the eye of uboot, or is it more of a contention that uboot is moving away from that need? Warner From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 19:54:27 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94F3FCF8; Thu, 17 Apr 2014 19:54:27 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55E901BBC; Thu, 17 Apr 2014 19:54:27 +0000 (UTC) Received: from [2001:470:9174:1:f8c1:b412:e2cf:d4d8] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WasO0-0008r2-UM; Thu, 17 Apr 2014 20:54:23 +0100 Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8B80CFE4-1A6C-4FB9-B561-EF747DA4F38F"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <7196A020-54E1-42FA-B8A0-25B145B0E412@bsdimp.com> Date: Thu, 17 Apr 2014 20:54:35 +0100 Message-Id: <54D788B2-BD68-4F75-86FF-0C4E71D9B75A@grondar.org> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> <1397761628.1124.245.camel@revolution.hippie.lan> <7196A020-54E1-42FA-B8A0-25B145B0E412@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1874) X-SA-Score: -1.0 Cc: Tim Kientzle , freebsd-arm , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:54:27 -0000 --Apple-Mail=_8B80CFE4-1A6C-4FB9-B561-EF747DA4F38F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1251 On 17 Apr 2014, at 20:14, Warner Losh wrote: >=20 > On Apr 17, 2014, at 1:07 PM, Ian Lepore wrote: >>=20 >> Hmmm. After a bit of poking around in the llvm code, it looks like = the >> full extent of the support for -ffixed-r9 is that it doesn't consider >> that register available for use by the code generator; that's only = part >> of what u-boot needs. =20 >=20 > what=92s the other part? Global register variables like this? Yah. U-boot/Arm is heavily dependant on using R9 (previously R8) as a global register variable. >> Some online notes I found for clang 3.5 claim that global register >> variables aren't supported, and aren't likely to be any time soon. >=20 > Is that a poke in the eye of uboot, or is it more of a contention that > uboot is moving away from that need? It means that for now I guess we are stuck with using GCC to compile = u-boot. I=92d mind a lot less if this was done as a port. Hmm. A port to do what crochet does, without all the FreeBSD/ARM = (build|install)(world|kernel) stuff? Something that makes an empty .img (with only the weird boot = bits in it) as its =93product=94 for later use by the release process = might be nice. I=92m guessing (more like hoping) that once the boot bits work, they=92ll = be pretty stable for a given platform for a while, and the .img file = could be kept under src/release/=85 somewhere. This way, it doesn=92t = matter if some humongous GCC port is used for cross-building; this would = be only needed when the boot-bits change. M --=20 Mark R V Murray --Apple-Mail=_8B80CFE4-1A6C-4FB9-B561-EF747DA4F38F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU1Axgd58vKOKE6LNAQrw7gP8DM328rj4Qox5gvCJePfuXY2VrmkTk2gQ rRQbOfa92YIGwfufUxh/KwSeDv71/fJ3p9QzGvjnzJTN70YQuuK0OpPyfwcUu4AD GdxvGYV4BoNewZJisnwKt1cRMiET7RLe2nxjmnx2aP4e5B5d0UezcQtEjxiTmJCS seI6HQXm7Sw= =fiIl -----END PGP SIGNATURE----- --Apple-Mail=_8B80CFE4-1A6C-4FB9-B561-EF747DA4F38F-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 20:06:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6BBBE32 for ; Thu, 17 Apr 2014 20:06:11 +0000 (UTC) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B38951C86 for ; Thu, 17 Apr 2014 20:06:11 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id w10so705316pde.24 for ; Thu, 17 Apr 2014 13:06:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=55u0wOAbsZQ1v/rdck3m0K0wVtvxKJET733GZQ3Z4I4=; b=K+QpyyJesMyag6upYl0MmYn1KWv46gG7mhG8BdZ93jNoVUt+6niEW+Cq3rgnLKZITF pT/ngdCZ9RRsVgg+d1KU3u82pDiOmrq4I1K9J290ipOJd/OsAcyA44yIdd+pHmt4zsd/ MzUwIFIfecmq1IgUTB6o/PBuThPVeHfI4UdcPyWMkrIoNbD8AaNLaAITHXkhvsBcOQO7 OrsPUvj3iGo0HtIEoOyFSIP84AvWvVfbO0Gf7++21t2dpR5VNoJic3diYAN3r84BclXF pp73a5uHC+2Ol2+u8YBGQgfHTcr2z4Op2efpKaPjhsFJfYKy/4UAA4mFYJijIwZcFQqh SJhQ== X-Gm-Message-State: ALoCoQlWOJ2VfOSmVHOOUvmrw27OpQ3zGHRxzPv6d0oSWJpzjFa8AmfsIccYK4RW+vEU8CtG/Cgy X-Received: by 10.68.215.68 with SMTP id og4mr17647434pbc.112.1397765164976; Thu, 17 Apr 2014 13:06:04 -0700 (PDT) Received: from lgmac-ckapadia.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id kl1sm55295061pbd.73.2014.04.17.13.06.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 13:06:04 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Warner Losh In-Reply-To: <54D788B2-BD68-4F75-86FF-0C4E71D9B75A@grondar.org> Date: Thu, 17 Apr 2014 14:06:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> <1397761628.1124.245.camel@revolution.hippie.lan> <7196A020-54E1-42FA-B8A0-25B145B0E412@bsdimp.com> <54D788B2-BD68-4F75-86FF-0C4E71D9B75A@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1874) Cc: Tim Kientzle , freebsd-arm , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:06:12 -0000 On Apr 17, 2014, at 1:54 PM, Mark R V Murray wrote: >=20 > On 17 Apr 2014, at 20:14, Warner Losh wrote: >=20 >>=20 >> On Apr 17, 2014, at 1:07 PM, Ian Lepore wrote: >>>=20 >>> Hmmm. After a bit of poking around in the llvm code, it looks like = the >>> full extent of the support for -ffixed-r9 is that it doesn't = consider >>> that register available for use by the code generator; that's only = part >>> of what u-boot needs. =20 >>=20 >> what=92s the other part? Global register variables like this? >=20 > Yah. U-boot/Arm is heavily dependant on using R9 (previously R8) as a > global register variable. >=20 >>> Some online notes I found for clang 3.5 claim that global register >>> variables aren't supported, and aren't likely to be any time soon. >>=20 >> Is that a poke in the eye of uboot, or is it more of a contention = that >> uboot is moving away from that need? >=20 > It means that for now I guess we are stuck with using GCC to compile = u-boot. >=20 > I=92d mind a lot less if this was done as a port. >=20 > > Hmm. A port to do what crochet does, without all the FreeBSD/ARM = (build|install)(world|kernel) stuff? >=20 > Something that makes an empty .img (with only the weird boot = bits in it) as its =93product=94 for later use by the release process = might be nice. >=20 > I=92m guessing (more like hoping) that once the boot bits work, = they=92ll be pretty stable for a given platform for a while, and the = .img file could be kept under src/release/=85 somewhere. This way, it = doesn=92t matter if some humongous GCC port is used for cross-building; = this would be only needed when the boot-bits change. > Ideally we=92d have it as a package which crochet could grab and use = rather than build from scratch. And the package should build with = whatever arm gcc we provide it with. Then crochet wouldn=92t need to = build xdev. It is really kinda abusing it as it is because xdev is = intended to be a fully functional cross compiler for FreeBSD/arm, not = just an arm cross compiler=85 Warner= From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 20:50:18 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38FF6F9B for ; Thu, 17 Apr 2014 20:50:18 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06DD211BE for ; Thu, 17 Apr 2014 20:50:17 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WatGC-000K1i-6Y; Thu, 17 Apr 2014 20:50:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3HKoCvZ003667; Thu, 17 Apr 2014 14:50:12 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/9lvwpRtjOUag9xenwNrnC Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Ian Lepore To: Mark R V Murray In-Reply-To: <54D788B2-BD68-4F75-86FF-0C4E71D9B75A@grondar.org> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> <1397761628.1124.245.camel@revolution.hippie.lan> <7196A020-54E1-42FA-B8A0-25B145B0E412@bsdimp.com> <54D788B2-BD68-4F75-86FF-0C4E71D9B75A@grondar.org> Content-Type: text/plain; charset="windows-1251" Date: Thu, 17 Apr 2014 14:50:11 -0600 Message-ID: <1397767811.1124.289.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s3HKoCvZ003667 Cc: Tim Kientzle , freebsd-arm , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:50:18 -0000 On Thu, 2014-04-17 at 20:54 +0100, Mark R V Murray wrote: > On 17 Apr 2014, at 20:14, Warner Losh wrote: >=20 > >=20 > > On Apr 17, 2014, at 1:07 PM, Ian Lepore wrote: > >>=20 > >> Hmmm. After a bit of poking around in the llvm code, it looks like = the > >> full extent of the support for -ffixed-r9 is that it doesn't conside= r > >> that register available for use by the code generator; that's only p= art > >> of what u-boot needs. =20 > >=20 > > what=92s the other part? Global register variables like this? >=20 > Yah. U-boot/Arm is heavily dependant on using R9 (previously R8) as a > global register variable. >=20 > >> Some online notes I found for clang 3.5 claim that global register > >> variables aren't supported, and aren't likely to be any time soon. > >=20 > > Is that a poke in the eye of uboot, or is it more of a contention tha= t > > uboot is moving away from that need? >=20 > It means that for now I guess we are stuck with using GCC to compile u-= boot. >=20 > I=92d mind a lot less if this was done as a port. >=20 > > Hmm. A port to do what crochet does, without all the FreeBSD/ARM (build= |install)(world|kernel) stuff? >=20 > Something that makes an empty .img (with only the weird boot bi= ts in it) as its =93product=94 for later use by the release process might= be nice. >=20 > I=92m guessing (more like hoping) that once the boot bits work, they=92= ll be pretty stable for a given platform for a while, and the .img file c= ould be kept under src/release/=85 somewhere. This way, it doesn=92t matt= er if some humongous GCC port is used for cross-building; this would be o= nly needed when the boot-bits change. > I'm not very familiar with crochet, but I'm confused now... Tim K. is the creator of crochet, and he's the maintainer of the u-boot-beaglebone-eabi port, which uses the gcc cross-compiler from ports. So did Tim not use his own excellent port in crochet? -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 20:56:34 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AA4A226; Thu, 17 Apr 2014 20:56:34 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5AB9E1291; Thu, 17 Apr 2014 20:56:34 +0000 (UTC) Received: from [2001:470:9174:1:f8c1:b412:e2cf:d4d8] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WatM7-0008ut-Me; Thu, 17 Apr 2014 21:56:32 +0100 Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6B6D6D6F-5A1A-4E4F-B12E-50D1D6C63D46"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <1397767811.1124.289.camel@revolution.hippie.lan> Date: Thu, 17 Apr 2014 21:56:16 +0100 Message-Id: <94BF7018-052C-430D-85D8-CAE14EA63270@grondar.org> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> <1397761628.1124.245.camel@revolution.hippie.lan> <7196A020-54E1-42FA-B8A0-25B145B0E412@bsdimp.com> <54D788B2-BD68-4F75-86FF-0C4E71D9B75A@grondar.org> <1397767811.1124.289.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) X-SA-Score: -1.0 Cc: Tim Kientzle , freebsd-arm , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:56:34 -0000 --Apple-Mail=_6B6D6D6F-5A1A-4E4F-B12E-50D1D6C63D46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1251 On 17 Apr 2014, at 21:50, Ian Lepore wrote: > On Thu, 2014-04-17 at 20:54 +0100, Mark R V Murray wrote: >> I=92m guessing (more like hoping) that once the boot bits work, = they=92ll be pretty stable for a given platform for a while, and the = .img file could be kept under src/release/=85 somewhere. This way, it = doesn=92t matter if some humongous GCC port is used for cross-building; = this would be only needed when the boot-bits change. >> >=20 > I'm not very familiar with crochet, but I'm confused now... Tim K. is > the creator of crochet, and he's the maintainer of the > u-boot-beaglebone-eabi port, which uses the gcc cross-compiler from > ports. So did Tim not use his own excellent port in crochet? No, and it may have something to do with ports/lang/arm-*-(binutils|gcc) = being a bit unstable (By that I mean they kinda came-and-went, and which = to use was quite a guessing game. This is now moot as there is now the = useful-looking gcc-arm-ports/devel/embedded which seems to enjoy a lot = of TLC!). M --=20 Mark R V Murray --Apple-Mail=_6B6D6D6F-5A1A-4E4F-B12E-50D1D6C63D46 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU1A/9d58vKOKE6LNAQqzQwP/XMyZn0bouHQN82MK7piiws0m3eHh2Ebd K6USJLYJ0xwxs0wzQA3Bt1WrLZm3RC3J/H+bMR+gekKyV0PiUxrdhorB447BvOGn gvknm/5R9r6vmNJqGcTC2A+ECpB6XDlr1C8YNQaFV/Z1Mwyu/EMeOUIR67JNLbxd 6wJ7JfvHRYU= =x4qU -----END PGP SIGNATURE----- --Apple-Mail=_6B6D6D6F-5A1A-4E4F-B12E-50D1D6C63D46-- From owner-freebsd-arm@FreeBSD.ORG Fri Apr 18 00:06:31 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E8A15D3; Fri, 18 Apr 2014 00:06:31 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB59613B8; Fri, 18 Apr 2014 00:06:30 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id EEDE6117B9; Fri, 18 Apr 2014 00:06:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us EEDE6117B9 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 17 Apr 2014 20:06:24 -0400 From: Glen Barber To: Mark R V Murray Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. Message-ID: <20140418000624.GB49791@glenbarber.us> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> <1397761628.1124.245.camel@revolution.hippie.lan> <7196A020-54E1-42FA-B8A0-25B145B0E412@bsdimp.com> <54D788B2-BD68-4F75-86FF-0C4E71D9B75A@grondar.org> <1397767811.1124.289.camel@revolution.hippie.lan> <94BF7018-052C-430D-85D8-CAE14EA63270@grondar.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline In-Reply-To: <94BF7018-052C-430D-85D8-CAE14EA63270@grondar.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Tim Kientzle , freebsd-arm , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 00:06:31 -0000 --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 17, 2014 at 09:56:16PM +0100, Mark R V Murray wrote: >=20 > On 17 Apr 2014, at 21:50, Ian Lepore wrote: >=20 > > On Thu, 2014-04-17 at 20:54 +0100, Mark R V Murray wrote: > >> I=E2=80=99m guessing (more like hoping) that once the boot bits work, = they=E2=80=99ll be pretty stable for a given platform for a while, and the = =2Eimg file could be kept under src/release/=E2=80=A6 somewhere. This way, = it doesn=E2=80=99t matter if some humongous GCC port is used for cross-buil= ding; this would be only needed when the boot-bits change. > >> > >=20 > > I'm not very familiar with crochet, but I'm confused now... Tim K. is > > the creator of crochet, and he's the maintainer of the > > u-boot-beaglebone-eabi port, which uses the gcc cross-compiler from > > ports. So did Tim not use his own excellent port in crochet? >=20 > No, and it may have something to do with ports/lang/arm-*-(binutils|gcc) = being a bit unstable (By that I mean they kinda came-and-went, and which to= use was quite a guessing game. This is now moot as there is now the useful= -looking gcc-arm-ports/devel/embedded which seems to enjoy a lot of TLC!). >=20 You *can* use the lang/arm-* stuff, but I have been unable to get it to work, so for the release/arm/release.sh, I don't use it. Glen --lEGEL1/lMxI0MVQ2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTUGyAAAoJELls3eqvi17QGusP/ROrt9M7V8UHCfU9oTDyoQ3k +I+AqTnq/PMy6ptU0Q4z6wO3/UyIPrgT2+LwdPweD7sigKXpVCUsyTC8ibqeDHLi uJcZSC1ib5RuKAScC+I1F5hv0X+gzhWg8aP0eMSiclwrR6SMBSsB2YXwGkgIqDVB xrh6pbIQD+23Y7S9v8FR3g3OpGEclHLawiuI9chwQJzTB3prdVw97y76ljWkK7c8 iQV3mUJIoybRHYjuHK/awg8jJKGVV+nCKtuLoUcEiPlyMn8QTMs+QOxBpuaENIeI L7PoWVdeChj4/5PeMEnFTMExuUfSOxqP/dP9qYfnrcjcsJzl+EqmyezXdj7+DahD rcw2L964QYXmDmZba73QHv5jPTSMUnReRd4AWJGQRNp2SFWEjE4YnUMq2SxIYXC6 IcLt+ogTz/E3hVJ1lkAPstejPqabDGTZHlrH7YwIIryFbKT8bSg8lgIsgHLzyQ2H wh1GJPEyfb7otvai50VXx/bvIiV3jS4dVIIHPYflYKp6CktmlbY3Uh/A7YLQGPjN qJNEVxFYwLkN5pl5/h8/YogLYn1nrWJhPBxbscVnpBoNOGZZG+8ZgMn8zRdp4a6+ BVyzl/t0OjRoX3PRRCksSVDjkRT0Lg6RZUkFA2CEjPPnamNgcm6AGgWql3cagqb+ RH8ZQvaDYzAWwm3XN8sY =YRmd -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2-- From owner-freebsd-arm@FreeBSD.ORG Fri Apr 18 04:10:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD995830 for ; Fri, 18 Apr 2014 04:10:39 +0000 (UTC) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B69C190D for ; Fri, 18 Apr 2014 04:10:39 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id ma3so1069433pbc.41 for ; Thu, 17 Apr 2014 21:10:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=I+4FVT62K2fV42/xhYDfUcejr5ZykHRpSBltxJmXN8Q=; b=HG+e4lAkjY0YYxRcikZuSRApe2aWvVEcUoDmO1UhC7cBeNRJtOSkV8DzUqvWFaQuNz LP5fvzNDrecHdNIM2LvOGjD1PkppNh4J5dCM1j7wW1GR6irSNzvlxeNqsiebW+VOF954 F/5DbgtRqdn08lqUgbAXUZlWZPQxWz2Il+sY79ZKuBRjIkQ8QumlOrkSG+7ZpOwuaOmq Wz7RMNClPSoZAJ2jE5u8hDkAm9WbjLfTvp0hIy4c+5s0QUDybtFuMYWv1Z/Y29AKk3fq gnB5/q05qqVIwBbna7eEAxqG6ArEmBsC4XY5+ctdSMioUTXkcAbpMXLgO0sjRvxQN3ei VLRA== X-Gm-Message-State: ALoCoQkA/j6QGOCWM2iprQ5Frtyoylz7Hm/zUcFqoH5D2evOkNNUSKS9XNPudRSSYqdyOZUxbgaY X-Received: by 10.68.178.1 with SMTP id cu1mr19614410pbc.34.1397794233669; Thu, 17 Apr 2014 21:10:33 -0700 (PDT) Received: from [192.168.1.2] (c-50-156-22-189.hsd1.ca.comcast.net. [50.156.22.189]) by mx.google.com with ESMTPSA id ff4sm135351894pad.24.2014.04.17.21.10.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 21:10:32 -0700 (PDT) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Tim Kientzle In-Reply-To: <54D788B2-BD68-4F75-86FF-0C4E71D9B75A@grondar.org> Date: Thu, 17 Apr 2014 21:10:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1963F059-91A1-4D4C-84AE-7BC6C25044E1@kientzle.com> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> <1397761628.1124.245.camel@revolution.hippie.lan> <7196A020-54E1-42FA-B8A0-25B145B0E412@bsdimp.com> <54D788B2-BD68-4F75-86FF-0C4E71D9B75A@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm , Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 04:10:40 -0000 On Apr 17, 2014, at 12:54 PM, Mark R V Murray wrote: >=20 > On 17 Apr 2014, at 20:14, Warner Losh wrote: >=20 >>=20 >> On Apr 17, 2014, at 1:07 PM, Ian Lepore wrote: >>>=20 >>> Hmmm. After a bit of poking around in the llvm code, it looks like = the >>> full extent of the support for -ffixed-r9 is that it doesn't = consider >>> that register available for use by the code generator; that's only = part >>> of what u-boot needs. =20 >>=20 >> what=92s the other part? Global register variables like this? >=20 > Yah. U-boot/Arm is heavily dependant on using R9 (previously R8) as a > global register variable. >=20 >>> Some online notes I found for clang 3.5 claim that global register >>> variables aren't supported, and aren't likely to be any time soon. >>=20 >> Is that a poke in the eye of uboot, or is it more of a contention = that >> uboot is moving away from that need? >=20 > It means that for now I guess we are stuck with using GCC to compile = u-boot. Unless you can find some other way to make the =91gd=92 symbol return = the value of r9. Hmmm=85. How good is clang=92s inline assembly? #define gd __asm(=85. return r9 =85 ) Or maybe: #define gd getr9() gd_t *getr9(void); > I=92d mind a lot less if this was done as a port. >=20 > > Hmm. A port to do what crochet does, without all the FreeBSD/ARM = (build|install)(world|kernel) stuff? >=20 > Something that makes an empty .img (with only the weird boot = bits in it) as its =93product=94 for later use by the release process = might be nice. /usr/ports/sysutils/u-boot-beaglebone-eabi is looking for an owner. ;-) This was my attempt to do essentially what you suggest, but I never got = it quite working. There are experimental bits in Crochet to exploit = this port if it=92s been =93installed=94 on the system. (=93Install=94 in this case installs the built U-Boot bits in = /usr/local/share and puts a shell script in /usr/local/bin that can copy = those bits to a specified target dir.) Tim From owner-freebsd-arm@FreeBSD.ORG Fri Apr 18 04:17:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 616EC8AE for ; Fri, 18 Apr 2014 04:17:55 +0000 (UTC) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32FC619A1 for ; Fri, 18 Apr 2014 04:17:54 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id rq2so1081996pbb.19 for ; Thu, 17 Apr 2014 21:17:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=t9c5zY80iTIHxGNZujKDhZoyEhtjSnoxwLPVxBldQzE=; b=MqjGVYjq9tO3MGCfBJRNkgXYhG57sdU3A+JazNIhkB/T90aLVYF6wl+4HQAu6bvyTP Ep4rJOpvyF9yYLWL1tFiebNljmkm8nKjPuqamwZjuJxRI6QbTxXpgn0rJ8TRdFSoVeKd KbKx7CVFMRSRVB9dVk2WSczCYEBLqyNxek1MvJo3/mtZN0QHoyM3SrMzCM2dxoIeh/tX q/2mKdkXv2lll3akFoxr3apmehkPsBuD7HmHhLw3skq6rFosCdOIUdL8eCtKpSjGLUJR qyRf/8C45HFGAheufgQb7iVBC9ZaERiq9b00ikd7bDpwmH9dKAIRGKGJKph63foZ21sl QUog== X-Gm-Message-State: ALoCoQmDehzriWqFuEc8beE6F4fSSFVxVPDiMsTG+q06pJp9UHkcNzNs8jyScRCgW9wWi8Rfp3F5 X-Received: by 10.66.66.202 with SMTP id h10mr19764354pat.70.1397794668441; Thu, 17 Apr 2014 21:17:48 -0700 (PDT) Received: from [192.168.1.2] (c-50-156-22-189.hsd1.ca.comcast.net. [50.156.22.189]) by mx.google.com with ESMTPSA id iq10sm56981350pbc.14.2014.04.17.21.17.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 21:17:47 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Tim Kientzle In-Reply-To: <4B9FEF94-9912-4861-9FE2-E8EC7BE3509C@grondar.org> Date: Thu, 17 Apr 2014 21:17:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44685985-BD5A-4D5F-B6DB-99A7252F8C8C@kientzle.com> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <4B9FEF94-9912-4861-9FE2-E8EC7BE3509C@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 04:17:55 -0000 On Apr 17, 2014, at 12:23 AM, Mark R V Murray wrote: >=20 > How much hacking does u-boot need for 1) FreeBSD and 2) RPI? 1) standard patches to enable API and ELF support for ubldr. Crochet = has in-tree patches for several different target boards; look for the = part that=92s the same across all of them. ;-) 2) Oleksandr=92s hacked RPi version of U-Boot is on github >=20 > Should its head-of-trunk =93just work=94? They have apparently sorted = out the R8/R9 business which should make it CLANG-ready, IIUC. As noted elsewhere, clang and U-Boot need more reconciliation. Plus standard patches for FreeBSD to enable API and ELF support for = ubldr. Plus various board-specific patches: * the hard-coded U-boot start scripts vary enormously across different = boards and are almost always very Linux-specific; * some U-Boot start scripts read additional startup scripts from disk = which allows you to tweak without overriding the hard-coded portion, but = not all, and those that do don=92t always do it the same way. Tim From owner-freebsd-arm@FreeBSD.ORG Fri Apr 18 13:33:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B12C4BC; Fri, 18 Apr 2014 13:33:41 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34BB71134; Fri, 18 Apr 2014 13:33:41 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id y10so1458202pdj.13 for ; Fri, 18 Apr 2014 06:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=g3STaKuIvPC5M4893cbuWSboXzbYnivskOV33msOknE=; b=Hun3YzlY665+NIiB42xWaHDQDxflUp9afn7k4svdnPzH6V7VCKq42MSzKJuxLOhjEc Svos2TqaoOEN9EWhV8IQEb9RvITT2FoSUCktI2vj2CdrlD3auMHZMvuH6QcJr9uwhM9l gD5eHwdR8JwXEywAgzIz348Ho++6YDc8GX2Hhg334VQDeETljFW6lCILMMeqeGz2iNdj 8EZM3cxf0ORaHtTRRT4jQ/ngjNydnfQrA5Ovbpm2hwqaTMDcI853/+VmaR4UB+FAt6YP Sqpi2oSk4ZAkepRhfWYGGjx3OKp3wr4CFEwE5+O2NJ5yPJWXgV/JNDET6RVrjBqeDNKW A4tw== X-Received: by 10.68.201.165 with SMTP id kb5mr22006104pbc.80.1397828020818; Fri, 18 Apr 2014 06:33:40 -0700 (PDT) Received: from [216.131.71.99] ([216.131.71.99]) by mx.google.com with ESMTPSA id op3sm59972397pbc.40.2014.04.18.06.33.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 06:33:39 -0700 (PDT) Message-ID: <535129A2.3010809@gmail.com> Date: Fri, 18 Apr 2014 21:33:22 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Sulev-Madis Silber (ketas)" Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 References: <5345FEED.1040604@gmail.com> <20140410104921.GA95756@cicely7.cicely.de> <53468E7A.70309@gmail.com> <1397141234.1124.47.camel@revolution.hippie.lan> <534DBA81.4020505@gmail.com> <97116232-B26D-451B-8195-F1C4AD5CB3E2@gmail.com> <534DBDC5.2020307@gmail.com> <534DE094.1000302@hot.ee> <534DE206.8000107@gmail.com> <534DEB01.4070002@hot.ee> <534E0D99.1040907@gmail.com> <534E5634.6050303@hot.ee> In-Reply-To: <534E5634.6050303@hot.ee> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 13:33:41 -0000 Thanks for your checking. On 04/16/2014 06:06 PM, Sulev-Madis Silber (ketas) wrote: > That seemed to work well at first glance. CPU was indeed 1GHz and I > didn't see any issues. > > > On 2014-04-16 07:56, Xuebing Wang wrote: >> Are you willing to try uSDHC boot? >> >> >> On 04/16/2014 10:29 AM, Sulev-Madis Silber (ketas) wrote: >>> It works with patched uboot 2013.04 >>> >>> There was discussion here about that. >>> >>> >>> Recently I have some issues but it STILL works! :) >>> >>> >>> On 2014-04-16 04:51, Xuebing Wang wrote: >>>> I though flashing eMMC (booting from eMMC) is NOT supported yet. >>>> >>>> Am I correct? >>>> >>>> >>>> On 04/16/2014 09:44 AM, Sulev-Madis Silber (ketas) wrote: >>>>> I can't seem to boot from eMMC... it fails at the point where ubldr >>>>> says >>>>> no devices found. Also, I didn't try to compare code, what are >>>>> differences between this uboot + patches and one in crochet tree with >>>>> those patches? I know it has some multi-device features... >>>>> >>>>> >>>>> FreeBSD/armv6 U-Boot loader, Revision 1.2 >>>>> (root@rack0, Wed Apr 9 04:29:27 EEST 2014) >>>>> >>>>> DRAM: 512MB >>>>> Card did not respond to voltage select! >>>>> Card did not respond to voltage select! >>>>> Number of U-Boot devices: 1 >>>>> U-Boot env: loaderdev='mmc1:2.0' >>>>> Found U-Boot device: net >>>>> No boot device found! >>>>> -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Fri Apr 18 19:36:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A476FB47 for ; Fri, 18 Apr 2014 19:36:35 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 444F2168D for ; Fri, 18 Apr 2014 19:36:35 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id q5so1033816wiv.10 for ; Fri, 18 Apr 2014 12:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PUsxdsz1QU1SelBg6DZQKvIkTxbnqiWllxu5BH8hWrg=; b=q8rpO75wkpupdOCyklPnpXGkYvr0GyZbNf99dbBnbnRPKH9JLXscjZkrdLGq7HetSP wZquSr/My8NAq/Ve5NCltQ01T9j19cIgZKuUnmEHpAuhGww2pVlR3UYh4cSgt+VhvlLz 6OS1lc6q9bQT1xcmNL0UqXH8BLpJV6aFkUnMn1yaI11d/MG4SHMNpO47soUizo1LeS8f gIxqqRMSSDAb3LatnAW/rZSywECyz1jCxk+KFaXWOEiFYgKoP7+X5tlUqVx1gbkKyQM/ GRnbdVh0yFVj8CHlH0OG/AXUZxInL9lFkK5X7Y8I9TBuLJTIj3l+PQ7219KMFoJm4xPN COfw== MIME-Version: 1.0 X-Received: by 10.194.57.38 with SMTP id f6mr522366wjq.59.1397849792588; Fri, 18 Apr 2014 12:36:32 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 18 Apr 2014 12:36:32 -0700 (PDT) Date: Fri, 18 Apr 2014 15:36:32 -0400 Message-ID: Subject: crotchet-freebsd fails to build u-boot (master) From: Winston Smith To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 19:36:35 -0000 Firstly, I'm new here! Im trying to get FreeBSD up and running on the BBB booting from the eMMC. I'm using Patrick Kelsey's BBB-multi-install-config.sh script (https://github.com/pkelsey/crochet-configs/blob/master/BBB-multi-install-config.sh) with crotchet-freebsd building FreeBSD-11-CURRENT and u-boot master. CHK include/config/uboot.release CHK include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h HOSTCC tools/dumpimage.o HOSTCC tools/image-fit.o In file included from tools/image-fit.c:1: /usr/home/winston/Work/crochet-freebsd/u-boot-master/tools/../common/image-fit.c:887:3: warning: implicit declaration of function 'sha256_csum_wd' is invalid in C99 [-Wimplicit-function-declaration] sha256_csum_wd((unsigned char *)data, data_len, ^ /usr/home/winston/Work/crochet-freebsd/u-boot-master/tools/../common/image-fit.c:888:35: error: use of undeclared identifier 'CHUNKSZ_SHA256' (unsigned char *)value, CHUNKSZ_SHA256); ^ /usr/home/winston/Work/crochet-freebsd/u-boot-master/tools/../common/image-fit.c:889:16: error: use of undeclared identifier 'SHA256_SUM_LEN' *value_len = SHA256_SUM_LEN; ^ 1 warning and 2 errors generated. gmake[1]: *** [tools/image-fit.o] Error 1 gmake: *** [tools] Error 2 It looks like it's picking up the sha256.h header from /usr/include rather than in u-boot-master/include. I believe I'm using Clang for the u-boot compilation, as I built the xdev tools as follows: make XDEV=arm XDEV_ARCH=armv6 xdev I ran a build with u-boot-master and 10-stable xthe other day and I didn't run into this. I can only assume that the sha256.h is new in 11-current? Any ideas? Thanks! -W From owner-freebsd-arm@FreeBSD.ORG Sat Apr 19 00:09:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 762A752B for ; Sat, 19 Apr 2014 00:09:49 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12BB410A7 for ; Sat, 19 Apr 2014 00:09:48 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x12so977756wgg.30 for ; Fri, 18 Apr 2014 17:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NH7tlSgrRIWt/ooJc+mTxRGu8qguWSNehJdDKVzPMF4=; b=dyu+bq9extwOMY/H+nmO4wM3+Fwi7W0IuLwDhjj5M23NORppJlYf1iByvjHz7QbqxE zmLg1WKM2mCMzTXIZxc1RkDfhSSkrWcYUqbYIx/PE/E/RBtgNrwGcLkq8cQZN2DRe2e3 nbwf4dGyivRhxCxQV84CHuhGOQTxOLHYB25OYSgmWx/Ccn3AIO4oEBViP9yLwd2KaJkx Rv9TWEmhCf5xR0tXFUHk153lEeLbi6FVNpvJcvAMmbrp2TCn7/HVhZliRxtqb0LUfIA5 yERoPkGazcfe3YnV21Ax65gL0oBApBlFIBitPPf6E5xu/DE+s78iX3jU97OqJsd3T0wq fhXw== MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr4244352wic.5.1397866187280; Fri, 18 Apr 2014 17:09:47 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 18 Apr 2014 17:09:47 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Apr 2014 20:09:47 -0400 Message-ID: Subject: Re: crotchet-freebsd fails to build u-boot (master) From: Winston Smith To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 00:09:49 -0000 On Fri, Apr 18, 2014 at 3:36 PM, Winston Smith wrote: > > CHK include/config/uboot.release > CHK include/generated/version_autogenerated.h > CHK include/generated/timestamp_autogenerated.h > UPD include/generated/timestamp_autogenerated.h > HOSTCC tools/dumpimage.o > HOSTCC tools/image-fit.o > In file included from tools/image-fit.c:1: > /usr/home/winston/Work/crochet-freebsd/u-boot-master/tools/../common/image-fit.c:887:3: > warning: implicit declaration of function 'sha256_csum_wd' is invalid > in C99 [-Wimplicit-function-declaration] > sha256_csum_wd((unsigned char *)data, data_len, > ^ > /usr/home/winston/Work/crochet-freebsd/u-boot-master/tools/../common/image-fit.c:888:35: > error: use of undeclared identifier 'CHUNKSZ_SHA256' > (unsigned char *)value, CHUNKSZ_SHA256); > ^ > /usr/home/winston/Work/crochet-freebsd/u-boot-master/tools/../common/image-fit.c:889:16: > error: use of undeclared identifier 'SHA256_SUM_LEN' > *value_len = SHA256_SUM_LEN; > ^ > 1 warning and 2 errors generated. > gmake[1]: *** [tools/image-fit.o] Error 1 > gmake: *** [tools] Error 2 I retried with u-boot-2014.04 and it builds ok, so something has changed in the last 4 days that breaks this. While 2014.04 does build, it fails to boot on the BBB: U-Boot SPL 2014.04 (Apr 18 2014 - 19:41:02) reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img spl_load_image_fat: error reading image u-boot.img, err - -1 ### ERROR ### Please RESET the board ### Looks like the patches haven't properly been applied as mlo looking for u-boot.img rather than bb-uboot.img. Hmmm ... -W From owner-freebsd-arm@FreeBSD.ORG Sat Apr 19 00:34:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAEF383C for ; Sat, 19 Apr 2014 00:34:56 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59E2512BA for ; Sat, 19 Apr 2014 00:34:56 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id u57so1974841wes.8 for ; Fri, 18 Apr 2014 17:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=38tT+tTdJRA9uy2C39qvDJeU8oixOD2Mb4f05E+o95c=; b=Ck9ZwEQcLeDkxy/uvNz0lLroBOKj3YAZ73TRR367DPJckLh8DsOKeDjxyoXTCRFPUw Nd3tr85Kp5zJrK4ILCgtaDnaqAOBrAXR7giU+TxgVU1UIep8WgpZ8E6riJtoJ62lTiqO zV2S+vum2OeRCsiILSLqOiBuLgfYJNY3ue45KeNc0qBMpLf2893f5zDsk2Z5JvVMxn0V Tpw/azuO6fV8g+lqbxd3MSO20ikbhDbd7nsraYZAeaSjq2Q0cd0Y04niWEy612APAtOx 8RGlq6icb+xr4v9Wh+XtevLygRoUvzTJQ65Nwyz5QYXKhlI30rFazfay5AEoeSZ++Gch FPYg== MIME-Version: 1.0 X-Received: by 10.194.60.4 with SMTP id d4mr2609401wjr.28.1397867694078; Fri, 18 Apr 2014 17:34:54 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 18 Apr 2014 17:34:54 -0700 (PDT) Date: Fri, 18 Apr 2014 20:34:54 -0400 Message-ID: Subject: 11.0-BEAGLEBONE-r264670: "lock order reversal" warning on shutdown From: Winston Smith To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 00:34:56 -0000 Using u-boot-2013.04 and FreeBSD-armv6-11.0-BEAGLEBONE-r264670, I was able to boot from the SD card on a BBB. Upon shutdown, I see the following on the console: root@beaglebone:/boot/msdos # /sbin/halt Apr 19 00:02:33 beaglebone halt: halted by root Apr 19 00:02:33 beaglebone syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 0 1 0 1 0 0 0 done All buffers synced. lock order reversal: 1st 0xc2e58a54 ufs (ufs) @ /usr/src/FreeBSD-CURRENT/sys/kern/vfs_mount.c:1237 2nd 0xc2e64394 devfs (devfs) @ /usr/src/FreeBSD-CURRENT/sys/fs/msdosfs/msdosfs_vfsops.c:989 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0542258 lr = 0xc02324bc (db_trace_self_wrapper+0x30) sp = 0xde6d4a18 fp = 0xde6d4b30 r10 = 0xc2e64394 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc02324bc lr = 0xc039b358 (kdb_backtrace+0x38) sp = 0xde6d4b38 fp = 0xde6d4b40 r4 = 0xc0689484 r5 = 0xc059401b r6 = 0xc0594a31 r7 = 0xc05b3bdd kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc039b358 lr = 0xc03b5c78 (witness_checkorder+0xe50) sp = 0xde6d4b48 fp = 0xde6d4b98 r4 = 0xc059fa6d witness_checkorder() at witness_checkorder+0xe50 pc = 0xc03b5c78 lr = 0xc034829c (__lockmgr_args+0x8b4) sp = 0xde6d4ba0 fp = 0xde6d4c08 r4 = 0x00000000 r5 = 0x00080400 r6 = 0x000003dd r7 = 0xc2e643b4 r8 = 0xc2e64394 r9 = 0x00080000 r10 = 0xc0594a2e __lockmgr_args() at __lockmgr_args+0x8b4 pc = 0xc034829c lr = 0xc03fa524 (vop_stdlock+0x3c) sp = 0xde6d4c10 fp = 0xde6d4c20 r4 = 0xde6d4c40 r5 = 0xc0660df0 r6 = 0x00000000 r7 = 0x00080400 r8 = 0xde6d4c40 r9 = 0x00080300 r10 = 0x000003dd vop_stdlock() at vop_stdlock+0x3c pc = 0xc03fa524 lr = 0xc056c8a4 (VOP_LOCK1_APV+0xd8) sp = 0xde6d4c28 fp = 0xde6d4c38 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd8 pc = 0xc056c8a4 lr = 0xc0418980 (_vn_lock+0x44) sp = 0xde6d4c40 fp = 0xde6d4c70 r4 = 0xc2e64360 r5 = 0x00000001 r6 = 0xc0594a2e _vn_lock() at _vn_lock+0x44 pc = 0xc0418980 lr = 0xc02aa314 (msdosfs_sync+0x1a0) sp = 0xde6d4c78 fp = 0xde6d4cd0 r4 = 0xde6d4c9c r5 = 0x00000001 r6 = 0xc2d09960 r7 = 0xc2a962b0 r8 = 0x00000000 r9 = 0x00080300 r10 = 0xc2dfe700 msdosfs_sync() at msdosfs_sync+0x1a0 pc = 0xc02aa314 lr = 0xc0402958 (dounmount+0x464) sp = 0xde6d4cd8 fp = 0xde6d4d20 r4 = 0xc2e58a20 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc2d09960 r9 = 0x00080000 r10 = 0x00080000 dounmount() at dounmount+0x464 pc = 0xc0402958 lr = 0xc040b164 (vfs_unmountall+0x48) sp = 0xde6d4d28 fp = 0xde6d4d48 r4 = 0xc2d09960 r5 = 0xc059fa6d r6 = 0xc05a41ab r7 = 0xc2a962b0 r8 = 0xc0661080 r9 = 0xc05c1a76 r10 = 0xc05b4c36 vfs_unmountall() at vfs_unmountall+0x48 pc = 0xc040b164 lr = 0xc03640e4 (kern_reboot+0x468) sp = 0xde6d4d50 fp = 0xde6d4da8 r4 = 0xc066d024 r5 = 0x00000000 r6 = 0xc05a41ab r7 = 0xcd2156a8 r8 = 0x00000008 r9 = 0x00000000 r10 = 0xc092ea58 kern_reboot() at kern_reboot+0x468 pc = 0xc03640e4 lr = 0xc0363c74 ($d) sp = 0xde6d4db0 fp = 0xde6d4db8 r4 = 0xde6d4e18 r5 = 0xc2aa1640 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xde6d4e10 r10 = 0x00000004 $d() at $d pc = 0xc0363c74 lr = 0xc0557878 (swi_handler+0x284) sp = 0xde6d4dc0 fp = 0xde6d4e58 r4 = 0xc2d09960 swi_handler() at swi_handler+0x284 pc = 0xc0557878 lr = 0xc0543d74 (swi_exit) sp = 0xde6d4e60 fp = 0xbffffd00 r4 = 0x00000004 r5 = 0x00000002 r6 = 0xbffffcdc r7 = 0x00000037 r8 = 0x00000000 r9 = 0x00000000 swi_exit() at swi_exit pc = 0xc0543d74 lr = 0xc0543d74 (swi_exit) sp = 0xde6d4e60 fp = 0xbffffd00 Unable to unwind further Uptime: 20m13s The operating system has halted. Please press any key to reboot. From owner-freebsd-arm@FreeBSD.ORG Sat Apr 19 09:42:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4808F0 for ; Sat, 19 Apr 2014 09:42:11 +0000 (UTC) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67DEF1176 for ; Sat, 19 Apr 2014 09:42:11 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id c13so2233333eek.37 for ; Sat, 19 Apr 2014 02:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zPDHo+957a+OiuK7Lmc/nSkYcjl1+rpWUocG4LpsH3U=; b=H4Mzm1oZ8C+B+MT1DYLDIsI7mhmFrIHkcleP+Sv3q3LEfaV0qKERD0du1sga4VnvTV 0aQOADzZuKZVMJqc3CE2VxZktHURYcW/oqWVk2zd14eBIiSphb9jAUnXSCgJnxAdnHxm 8n1Pz151xVcnKrDG2CxYSJ1GPvuBFbGdMvYK9IYHOII+UX8gXN59cSY+BbL/3pC4v2N/ o2mvQcysyr+eguiwamg9974TLYWtcVqzYn9PG6ucbsvPfi+LhvTHvo0c95D61AGjlP/i fzoiWZnjWgEIYHfg/AtGjc4Kb6Cr1+5fJygJajxxhyP395ZZCwFgyNMOxIJj/px2Rb8u 3uEA== X-Received: by 10.15.83.68 with SMTP id b44mr29396342eez.11.1397900529759; Sat, 19 Apr 2014 02:42:09 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id o7sm84204708eew.25.2014.04.19.02.42.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 02:42:08 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <535244EE.5070303@hot.ee> Date: Sat, 19 Apr 2014 12:42:06 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Winston Smith Subject: Re: crotchet-freebsd fails to build u-boot (master) References: In-Reply-To: X-TagToolbar-Keys: D20140419124206975 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 09:42:11 -0000 On 2014-04-18 22:36, Winston Smith wrote: > Firstly, I'm new here! Im trying to get FreeBSD up and running on the > BBB booting from the eMMC. Oh hey! Finally more BBB+eMMC users. I've been running BBB from eMMC for weeks now and it's very stable, but on boot, something goes wrong with eMMC detection and sometimes network phy fails. Details are in this list somewhere. You could test those things, so I'm not alone with this. I currently also have two U-Boot's, 2013.04 from crochet (using those patches there) that gives me eMMC and 2014.01 with some patches from this list that gives me 1GHz CPU but no eMMC (fails in ubldr with no device found). Also more details in this list. The device currently almost fits with my needs. I'm trying to use it in my home automation system where several of same or similar boards make all sorts of IO available over IP so I could have monitoring and control. In this application, 1GHz (and non-scaling?!) CPU isn't really needed. I found that this board is cheap enough, compared with how much IO it has... And it runs FreeBSD! I sometimes encounter people that buy much more expensive and less capable hardware for purpose to hack it apart and interface with own system. I would rather take something like BBB and hack together system I actually need. Not sure how this will help you, though. I don't even use the any of methods you described to build system for it. Instead of that, I use my own scripts to make release and upgrade the board over network... Other than, maybe... that indeed "sha256.h" appeared in CURRENT at revision 263218... But none of my build machines actually run CURRENT. From owner-freebsd-arm@FreeBSD.ORG Sat Apr 19 18:45:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E8B4FB8 for ; Sat, 19 Apr 2014 18:45:56 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCAF412AA for ; Sat, 19 Apr 2014 18:45:55 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id y10so1470932wgg.13 for ; Sat, 19 Apr 2014 11:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UqrnwbH75vTs6hAUoxQBKrEP5vBD/VtX+X+nC9Cpfbs=; b=GGE06+PU/AE/JDOd0kj6+tomp3BRshR6I+oEzX32AegwtPmkUoeFpB4jLSli2QNmE6 bPT/WcIcDG1UW6lWgURyvOvEBWb9/zuIbQK6dDTz5fibGCTpgSQIw4lQ0NWSSpupeoos Q6UVN5yP7oNH2khmEPngKELCqCqGUYQ2WsIlhBUGJYmGL83DeQg/AdyqmchQxWFuYN08 aRSln4we4SVNXEkbIYu0YkBpOpatJt2k8f8MC0VOtGU6kCZclGrXqR1CxSr2emYtj/8l WBA4mpul0LZiCrNuOH/92sd4x7nrp4fqdnlALlUXjCuKTPB6FvACkHcT4XcEGf2k/I+z tcOA== MIME-Version: 1.0 X-Received: by 10.180.8.136 with SMTP id r8mr7445668wia.60.1397933154134; Sat, 19 Apr 2014 11:45:54 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Sat, 19 Apr 2014 11:45:54 -0700 (PDT) In-Reply-To: <535244EE.5070303@hot.ee> References: <535244EE.5070303@hot.ee> Date: Sat, 19 Apr 2014 14:45:54 -0400 Message-ID: Subject: Re: crotchet-freebsd fails to build u-boot (master) From: Winston Smith To: "Sulev-Madis Silber (ketas)" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 18:45:56 -0000 On Sat, Apr 19, 2014 at 5:42 AM, Sulev-Madis Silber (ketas) wrote: > Finally more BBB+eMMC users. I've been running BBB from eMMC for weeks > now and it's very stable, but on boot, something goes wrong with eMMC > detection and sometimes network phy fails. Details are in this list > somewhere. You could test those things, so I'm not alone with this. I started out with Angstrom on the BBB, got frustrated with that, switched to Debian which is actually pretty good, but FreeBSD is what I really want to run on these things! I haven't had much of a chance to play around with FreeBSD on this, but good so far! > I currently also have two U-Boot's, 2013.04 from crochet (using those > patches there) that gives me eMMC and 2014.01 with some patches from > this list that gives me 1GHz CPU but no eMMC (fails in ubldr with no > device found). Also more details in this list. Yeah, I've seen those emails. Which 2014.1 repo are you using? ... the patches in crotchet-freebsd are targeted to 2013.4, so they would need adapting to either u-boot master, or 2014.4. Seems like it might be useful to fork u-boot (at 2014.04) and apply the patches to the repo so at each [u-boot] release we can just pull/merge the upstream changes rather than having to mess with patches. >From the list, it looks like it's significantly faster with newer u-boot and the 1Ghz patches -- I think the caches are enabled too, I know with 2013.4 I see the following during boot: WARNING: Caches not enabled > The device currently almost fits with my needs. I'm trying to use it in > my home automation system where several of same or similar boards make > all sorts of IO available over IP so I could have monitoring and > control. In this application, 1GHz (and non-scaling?!) CPU isn't really > needed. > I found that this board is cheap enough, compared with how much IO it > has... And it runs FreeBSD! I sometimes encounter people that buy much > more expensive and less capable hardware for purpose to hack it apart > and interface with own system. I would rather take something like BBB > and hack together system I actually need. That's pretty much what I'm doing ... on this topic, any luck with i2c on BBB+FreeBSD? I'm pretty familiar with the Device Tree and device tree overlays on Linux, it seems like FreeBSD has a monolithic DTB file that it boots with. I don't need to load overlays dynamically (as the Linux cape mgr does), but it would be nice to be able to specify "additional" DTB files during boot so I don't have to alter the core DTB that crotchet-freebsd provides. > Not sure how this will help you, though. I don't even use the any of > methods you described to build system for it. Instead of that, I use my > own scripts to make release and upgrade the board over network... > Other than, maybe... that indeed "sha256.h" appeared in CURRENT at > revision 263218... But none of my build machines actually run CURRENT. I'm not entirely sure why u-boot-2013.4 succeeds against 11-CURRENT as the sha256.h file exists in both. There must be some difference in the way it's included (perhaps #include <> vs #include ""). I haven't really dug into it yet! From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 00:18:14 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD646E8A; Sun, 20 Apr 2014 00:18:14 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B39621136; Sun, 20 Apr 2014 00:18:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3K0IE4T056924; Sun, 20 Apr 2014 00:18:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3K0IEj5056923; Sun, 20 Apr 2014 00:18:14 GMT (envelope-from linimon) Date: Sun, 20 Apr 2014 00:18:14 GMT Message-Id: <201404200018.s3K0IEj5056923@freefall.freebsd.org> To: rozhuk.im@gmail.com, linimon@FreeBSD.org, freebsd-arm@FreeBSD.org, linimon@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: arm/166256: build fail in pmap.c X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 00:18:14 -0000 Synopsis: build fail in pmap.c State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun Apr 20 00:16:44 UTC 2014 State-Changed-Why: To submitter: this PR is probably obsolete by now. Please let us know if not. Responsible-Changed-From-To: freebsd-arm->linimon Responsible-Changed-By: linimon Responsible-Changed-When: Sun Apr 20 00:16:44 UTC 2014 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=166256 From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 02:11:31 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6161256; Sun, 20 Apr 2014 02:11:31 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CE25194E; Sun, 20 Apr 2014 02:11:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3K2BVYf096726; Sun, 20 Apr 2014 02:11:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3K2BVTC096725; Sun, 20 Apr 2014 02:11:31 GMT (envelope-from linimon) Date: Sun, 20 Apr 2014 02:11:31 GMT Message-Id: <201404200211.s3K2BVTC096725@freefall.freebsd.org> To: howard0su@gmail.com, linimon@FreeBSD.org, freebsd-arm@FreeBSD.org, ian@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: arm/183668: [panic] Panic when read unalign in ddb X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 02:11:31 -0000 Old Synopsis: Panic when read unalign in ddb New Synopsis: [panic] Panic when read unalign in ddb State-Changed-From-To: open->patched State-Changed-By: linimon State-Changed-When: Sun Apr 20 02:10:57 UTC 2014 State-Changed-Why: over to committer as possible MFC candidate. Responsible-Changed-From-To: freebsd-arm->ian Responsible-Changed-By: linimon Responsible-Changed-When: Sun Apr 20 02:10:57 UTC 2014 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=183668 From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 17:43:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09A2F3ED for ; Sun, 20 Apr 2014 17:43:42 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7C1013D7 for ; Sun, 20 Apr 2014 17:43:40 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s3KHRa4c090541; Sun, 20 Apr 2014 17:27:36 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id yx6eiihuz2c5yd9wbutzu6829s; Sun, 20 Apr 2014 17:27:36 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Today's Crochet fixes From: Tim Kientzle In-Reply-To: Date: Sun, 20 Apr 2014 10:27:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24AD766C-FA11-45AD-94B3-7C99EBF53FD0@freebsd.org> References: To: Winston Smith , FreeBSD ARM X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 17:43:42 -0000 I just pushed a couple of changes to Crochet that I thought folks would = be especially interested in: * All boards: Corrected instructions for building xdev tools. The instructions printed out by Crochet now include the right flags for building a correct GCC cross-compiler. With this, I've been able to build a working BeagleBone image on a fresh stock install = of FreeBSD/amd64 11-CURRENT r260789. * BeagleBone: Added a "copy-to-emmc.sh" script to root's home directory After logging in as root, try: /bin/sh copy-to-emmc.sh It will print scary warnings about erasing things. If you go ahead, it will reformat the eMMC and copy the system from SD to eMMC. Suggestions for improvements appreciated. Things I'm interested in help with: * Updating U-Boot for BeagleBone to a newer snapshot (Including migrating Patrick Kelsey's patches to support eMMC = booting) * Building U-Boot with clang (Winston Smith claims it "just works" if you have new enough U-Boot sources; I've not yet tried to = reproduce this. If it works as well as I hope, it will take a while to update U-Boot = sources for each Crochet-supported board.) * We're using geom_label for BeagleBone fstab now; would appreciate if someone could add this to the stock kernel configs. * Diane Bruce fixed the sysutils/u-boot-beaglebone-eabi port so it builds again. I've not yet tested to see if Crochet can generate a bootable image using it. It definitely lacks the newer patches that are in the Crochet-built version of U-Boot for BeagleBone. If this can be cleaned up, it should provide a template for migrating U-Boot for other boards into ports. * Testing other boards: RPi, PandaBoard, WandBoard, etc. If you play with any of the above, please let me know what you find. As always, patches are very welcome, pull requests even more so. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 17:54:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15780501; Sun, 20 Apr 2014 17:54:57 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79BF914E2; Sun, 20 Apr 2014 17:54:56 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so1139624wiv.3 for ; Sun, 20 Apr 2014 10:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dwu+XFl/fKsPffg4+g67ENAgqY2mfxBH9WCawxTKR2Q=; b=RvkC4ROmrdPInmbVsQpjRHDFzC6dFfIbZ13n7U9ptv974AjTQFMagdy/wN5uYCrIP9 g6Yz2fg+YKU9U+xl1xDPTvUUhrLngZ2Bk3CRDqCW8QhB3G1CVelNVl8McduKs8CTJRyU i5sdp/2vv2a8YAhS3sRZSXnojNzsR+thw++23GtkLpm8sre/ieFNWW8D/Zc4NhFAVg12 fSM+UvQ3TZdpzkEKRwHhdotToyxpgda27CuNJNsqJA5nb7OXdhgNT/ggaVI9u+mvuvcG gRTyyk+HrRi1iM1UDTUqJVFHhPd/WGCOTks+teuEkf/UaZk+CQ26U5wwKuSFXhbctjGI sK0g== X-Received: by 10.180.81.40 with SMTP id w8mr10656486wix.45.1398016494594; Sun, 20 Apr 2014 10:54:54 -0700 (PDT) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id ll1sm53494586wjc.6.2014.04.20.10.54.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Apr 2014 10:54:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Today's Crochet fixes From: fabiodive In-Reply-To: <24AD766C-FA11-45AD-94B3-7C99EBF53FD0@freebsd.org> Date: Sun, 20 Apr 2014 18:54:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0FD02F98-DA8E-48E7-9C23-1F02BDFD5811@gmail.com> References: <24AD766C-FA11-45AD-94B3-7C99EBF53FD0@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1510) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 17:54:57 -0000 Hello Tim, today I am building an image with crochet from FreeBSD 11 source, previously I was working successfully with FreeBSD 10 source set, I would like to explore the work of Xuebing Wang trying to include his patches to increase the CPU frequency. I will try to patch u-boot 2014.01. I had some trouble before trying to = use sysutils/u-boot-beaglebone-eabi.=20 Thank you for valuable work, until now. cheers, Fabio On Apr 20, 2014, at 18:27 , Tim Kientzle wrote: > I just pushed a couple of changes to Crochet that I thought folks = would be especially interested in: >=20 > * All boards: Corrected instructions for building xdev tools. >=20 > The instructions printed out by Crochet now include the right > flags for building a correct GCC cross-compiler. With this, I've > been able to build a working BeagleBone image on a fresh stock install = of > FreeBSD/amd64 11-CURRENT r260789. >=20 > * BeagleBone: Added a "copy-to-emmc.sh" script to root's home = directory >=20 > After logging in as root, try: /bin/sh copy-to-emmc.sh >=20 > It will print scary warnings about erasing things. If you go ahead, > it will reformat the eMMC and copy the system from SD to eMMC. > Suggestions for improvements appreciated. >=20 >=20 > Things I'm interested in help with: >=20 > * Updating U-Boot for BeagleBone to a newer snapshot > (Including migrating Patrick Kelsey's patches to support eMMC = booting) >=20 > * Building U-Boot with clang (Winston Smith claims it "just works" > if you have new enough U-Boot sources; I've not yet tried to = reproduce this. > If it works as well as I hope, it will take a while to update = U-Boot sources > for each Crochet-supported board.) >=20 > * We're using geom_label for BeagleBone fstab now; would appreciate > if someone could add this to the stock kernel configs. >=20 > * Diane Bruce fixed the sysutils/u-boot-beaglebone-eabi port so it > builds again. I've not yet tested to see if Crochet can generate a > bootable image using it. It definitely lacks the newer patches that > are in the Crochet-built version of U-Boot for BeagleBone. If this > can be cleaned up, it should provide a template for migrating > U-Boot for other boards into ports. >=20 > * Testing other boards: RPi, PandaBoard, WandBoard, etc. >=20 > If you play with any of the above, please let me know what you find. > As always, patches are very welcome, pull requests even more so. >=20 > Cheers, >=20 > Tim >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 18:41:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B5FE284 for ; Sun, 20 Apr 2014 18:41:03 +0000 (UTC) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3190118AA for ; Sun, 20 Apr 2014 18:41:02 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id vb8so1082700obc.24 for ; Sun, 20 Apr 2014 11:40:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VHr7IahajlGrl2MJxNHdHheVsmtXSIEU4XFHl3/2V8A=; b=NuwattN23dGcRQtMvd3XhQc473dcvJaS3xlYfII9D+LjqusyBhuSmjpDMchucyK67/ OYUsqzpCoN6J/gwXaoo2bIun91KEbXQUz4qhjPnlN8QuJZz3CmA24WEAcZtn7uD8G53y DAjacXGunj90lufWvBU0bEVxJNP/2s9kZaR3nro8mvSKs5fLSNxTEPugWzMoem7NJliL TgoFOry0ovIKATwex6UUtEL50HqytUYaTPTnW6abcoCsJDCWj+86eKr/GuxPGxYL182a DI0PE4CVQxHu1Lvfnu8oRzI78iXHbrzRSakF+szkUpwgY4BEpz/crPK4ZxHzX6c0jnKN uesQ== X-Gm-Message-State: ALoCoQlqUUFzFeq+Rfi014vgZiS9FZrWch6i+D70+a52Awon+LwpVNsW9jC+rXm5e0pIWQhygwAy MIME-Version: 1.0 X-Received: by 10.60.150.143 with SMTP id ui15mr2814846oeb.50.1398019255736; Sun, 20 Apr 2014 11:40:55 -0700 (PDT) Received: by 10.182.246.135 with HTTP; Sun, 20 Apr 2014 11:40:55 -0700 (PDT) In-Reply-To: <24AD766C-FA11-45AD-94B3-7C99EBF53FD0@freebsd.org> References: <24AD766C-FA11-45AD-94B3-7C99EBF53FD0@freebsd.org> Date: Sun, 20 Apr 2014 12:40:55 -0600 Message-ID: Subject: Re: Today's Crochet fixes From: Tom Everett To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 18:41:03 -0000 I'm building a wandboard image with your latest sources right now. I'll let you know if it fails. Are the updated xdev instructions valid for FreeBSD-10 also, or just for FreeBSD-11? On Sun, Apr 20, 2014 at 11:27 AM, Tim Kientzle wrote: > I just pushed a couple of changes to Crochet that I thought folks would be > especially interested in: > > * All boards: Corrected instructions for building xdev tools. > > The instructions printed out by Crochet now include the right > flags for building a correct GCC cross-compiler. With this, I've > been able to build a working BeagleBone image on a fresh stock install of > FreeBSD/amd64 11-CURRENT r260789. > > * BeagleBone: Added a "copy-to-emmc.sh" script to root's home directory > > After logging in as root, try: /bin/sh copy-to-emmc.sh > > It will print scary warnings about erasing things. If you go ahead, > it will reformat the eMMC and copy the system from SD to eMMC. > Suggestions for improvements appreciated. > > > Things I'm interested in help with: > > * Updating U-Boot for BeagleBone to a newer snapshot > (Including migrating Patrick Kelsey's patches to support eMMC booting) > > * Building U-Boot with clang (Winston Smith claims it "just works" > if you have new enough U-Boot sources; I've not yet tried to reproduce > this. > If it works as well as I hope, it will take a while to update U-Boot > sources > for each Crochet-supported board.) > > * We're using geom_label for BeagleBone fstab now; would appreciate > if someone could add this to the stock kernel configs. > > * Diane Bruce fixed the sysutils/u-boot-beaglebone-eabi port so it > builds again. I've not yet tested to see if Crochet can generate a > bootable image using it. It definitely lacks the newer patches that > are in the Crochet-built version of U-Boot for BeagleBone. If this > can be cleaned up, it should provide a template for migrating > U-Boot for other boards into ports. > > * Testing other boards: RPi, PandaBoard, WandBoard, etc. > > If you play with any of the above, please let me know what you find. > As always, patches are very welcome, pull requests even more so. > > Cheers, > > 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" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 18:48:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70217385 for ; Sun, 20 Apr 2014 18:48:08 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E0E418E7 for ; Sun, 20 Apr 2014 18:48:07 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s3KIm6oL090809; Sun, 20 Apr 2014 18:48:06 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id 6suextbheptxmwgpctnfm94bqa; Sun, 20 Apr 2014 18:48:06 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Today's Crochet fixes From: Tim Kientzle In-Reply-To: Date: Sun, 20 Apr 2014 11:48:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <55CF56A1-B69E-467D-B835-1DBD9053127E@freebsd.org> References: <24AD766C-FA11-45AD-94B3-7C99EBF53FD0@freebsd.org> To: Tom Everett X-Mailer: Apple Mail (2.1874) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 18:48:08 -0000 On Apr 20, 2014, at 11:40 AM, Tom Everett wrote: > Are the updated xdev instructions valid for FreeBSD-10 also, or just = for FreeBSD-11? I believe they will work with both, though I've only tried with = 11-CURRENT. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 20:06:31 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D378DEAC; Sun, 20 Apr 2014 20:06:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 940B61083; Sun, 20 Apr 2014 20:06:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s3KK6NYe001383; Sun, 20 Apr 2014 16:06:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s3KK6N2B001367; Sun, 20 Apr 2014 20:06:23 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 20 Apr 2014 20:06:23 GMT Message-Id: <201404202006.s3KK6N2B001367@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 20:06:31 -0000 TB --- 2014-04-20 18:50:39 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-20 18:50:39 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-20 18:50:39 - starting HEAD tinderbox run for arm/arm TB --- 2014-04-20 18:50:39 - cleaning the object tree TB --- 2014-04-20 18:50:39 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-20 18:50:44 - At svn revision 264702 TB --- 2014-04-20 18:50:45 - building world TB --- 2014-04-20 18:50:45 - CROSS_BUILD_TESTING=YES TB --- 2014-04-20 18:50:45 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-20 18:50:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-20 18:50:45 - SRCCONF=/dev/null TB --- 2014-04-20 18:50:45 - TARGET=arm TB --- 2014-04-20 18:50:45 - TARGET_ARCH=arm TB --- 2014-04-20 18:50:45 - TZ=UTC TB --- 2014-04-20 18:50:45 - __MAKE_CONF=/dev/null TB --- 2014-04-20 18:50:45 - cd /src TB --- 2014-04-20 18:50:45 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Apr 20 18:50:52 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_create_nil.c -o! uuid_create_nil.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_equal.c -o uuid! _equal.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_from_string.c -! o uuid_from_string.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_hash.c -o uuid_! hash.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_is_nil.c -o uui! d_is_nil.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_stream.c -o uui! d_stream.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_to_string.c -o ! uuid_to_string.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr.c -o xdr.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_array.c -o xdr_ar! ray.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_float.c -o xdr_fl! oat.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_mem.c -o xdr_mem.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_rec.c -o xdr_rec.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_reference.c -o xd! r_reference.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_sizeof.c -o xdr_s! izeof.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_stdio.c -o xdr_st! dio.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/softfloat/bits32/softfloa! t.c -o softfloat.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/arm/gen/fpgetround.c -o f! pgetround.o /tmp/fpgetround-9ed3a3.s: Assembler messages: /tmp/fpgetround-9ed3a3.s:21: Error: selected processor does not support `vmrs r0,fpscr' cc: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[3]: stopped in /src/lib/libc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-04-20 20:06:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-04-20 20:06:23 - ERROR: failed to build world TB --- 2014-04-20 20:06:23 - 4004.88 user 416.82 system 4543.84 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 20:37:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6D59822 for ; Sun, 20 Apr 2014 20:37:41 +0000 (UTC) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78CBA1298 for ; Sun, 20 Apr 2014 20:37:41 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id d49so3242552eek.27 for ; Sun, 20 Apr 2014 13:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5gMs+F9dU4g6a9IeQCsWvH3YijJqsSLeGnkLEgN6DYg=; b=aZQxX8NElGLvJ+qvmuTc3lKmCz/IMJtBc6y6bY2/Jq2qVoHCx7CkuFJqxozNQ9sghN 9mqo4AEW2POjYcCp/HSC2M61UMz1hNYVogR1hYQ4vb0vPIVSxmwGgaIfjoE6OJbdaY1R RjyQlqZg7zrhPpDKnpqTXaQmOwcvFm4BVuZ6zV6dp77YcGOusIHukvEbG3tLODO7FOvo yBUpOOtoH6JZDu9YCLUj6cR7WxMi2O6eJ8eyqLXQYT/M7qmFGjvo/eKvSNEvZ4Pl+4Am M8+MMXbvET9dReDbLCCU7oQ901/VLGf2Sl30Em8aOFXSbNTm+p2ST+7lO83EcozJe418 SwlQ== X-Received: by 10.14.220.130 with SMTP id o2mr41163898eep.42.1398026259735; Sun, 20 Apr 2014 13:37:39 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id 48sm97455687eei.24.2014.04.20.13.37.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Apr 2014 13:37:38 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53542FFC.90603@hot.ee> Date: Sun, 20 Apr 2014 23:37:16 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Winston Smith Subject: Re: crotchet-freebsd fails to build u-boot (master) References: <535244EE.5070303@hot.ee> In-Reply-To: X-TagToolbar-Keys: D20140420233716239 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 20:37:42 -0000 On 2014-04-19 21:45, Winston Smith wrote: > On Sat, Apr 19, 2014 at 5:42 AM, Sulev-Madis Silber (ketas) > wrote: >> Finally more BBB+eMMC users. I've been running BBB from eMMC for weeks >> now and it's very stable, but on boot, something goes wrong with eMMC >> detection and sometimes network phy fails. Details are in this list >> somewhere. You could test those things, so I'm not alone with this. > > I started out with Angstrom on the BBB, got frustrated with that, > switched to Debian which is actually pretty good, but FreeBSD is what > I really want to run on these things! I haven't had much of a chance > to play around with FreeBSD on this, but good so far! > >> I currently also have two U-Boot's, 2013.04 from crochet (using those >> patches there) that gives me eMMC and 2014.01 with some patches from >> this list that gives me 1GHz CPU but no eMMC (fails in ubldr with no >> device found). Also more details in this list. > > Yeah, I've seen those emails. Which 2014.1 repo are you using? ... > the patches in crotchet-freebsd are targeted to 2013.4, so they would > need adapting to either u-boot master, or 2014.4. Seems like it might > be useful to fork u-boot (at 2014.04) and apply the patches to the > repo so at each [u-boot] release we can just pull/merge the upstream > changes rather than having to mess with patches. 2014.01 was from ftp.denx.de, like all other uboots. Then some patches on top (different, not from crochet). > > From the list, it looks like it's significantly faster with newer > u-boot and the 1Ghz patches -- I think the caches are enabled too, I > know with 2013.4 I see the following during boot: > > WARNING: Caches not enabled > >> The device currently almost fits with my needs. I'm trying to use it in >> my home automation system where several of same or similar boards make >> all sorts of IO available over IP so I could have monitoring and >> control. In this application, 1GHz (and non-scaling?!) CPU isn't really >> needed. >> I found that this board is cheap enough, compared with how much IO it >> has... And it runs FreeBSD! I sometimes encounter people that buy much >> more expensive and less capable hardware for purpose to hack it apart >> and interface with own system. I would rather take something like BBB >> and hack together system I actually need. > > That's pretty much what I'm doing ... on this topic, any luck with i2c > on BBB+FreeBSD? I2C should work, I think (?) someone used LM75 temperature sensor and on boot where you see powered by "USB", "AC" or "USB and AC"... it's from PMIC via I2C. If you add own FDT, you get all serial ports enabled (I assume they pass data, never tried). Shared pins, though. PWM works. ADC works now. I think LCD barely works too (not via HDMI chip, though). Additionally, I could give you my code that makes IO available over IP. All Perl & POE, which is good or bad (depends what you like). Includes server to connect up your IO boards and simple JS web interface. > > I'm pretty familiar with the Device Tree and device tree overlays on > Linux, it seems like FreeBSD has a monolithic DTB file that it boots > with. I don't need to load overlays dynamically (as the Linux cape > mgr does), but it would be nice to be able to specify "additional" DTB > files during boot so I don't have to alter the core DTB that > crotchet-freebsd provides. Not sure how to specify more FDT files. But you can create multiple ones, compile and use them. With or without some uboot scripting. The whole IO system needs some rework. For example, I would like some "more unified" way to access everything, configure ADC and interrupts, receive changes on GPIO inputs, set GPIO outputs. I don't actually like the Linux idea where you have FS for that. I would want to open one device for read / write, or something like this. > >> Not sure how this will help you, though. I don't even use the any of >> methods you described to build system for it. Instead of that, I use my >> own scripts to make release and upgrade the board over network... >> Other than, maybe... that indeed "sha256.h" appeared in CURRENT at >> revision 263218... But none of my build machines actually run CURRENT. > > I'm not entirely sure why u-boot-2013.4 succeeds against 11-CURRENT as > the sha256.h file exists in both. There must be some difference in > the way it's included (perhaps #include <> vs #include ""). I haven't > really dug into it yet! > From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 21:48:19 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92410787; Sun, 20 Apr 2014 21:48:19 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64DCC17BD; Sun, 20 Apr 2014 21:48:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3KLmJFu097164; Sun, 20 Apr 2014 21:48:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3KLmHuR097162; Sun, 20 Apr 2014 21:48:17 GMT (envelope-from linimon) Date: Sun, 20 Apr 2014 21:48:17 GMT Message-Id: <201404202148.s3KLmHuR097162@freefall.freebsd.org> To: Meyser@xenet.de, linimon@FreeBSD.org, freebsd-arm@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: arm/184078: [xdev] cross installworld missing include files X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 21:48:19 -0000 Old Synopsis: cross installworld missing include files New Synopsis: [xdev] cross installworld missing include files State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Sun Apr 20 21:47:57 UTC 2014 State-Changed-Why: to submitter: xdev has recently been reworked. Is this PR now obsolete? http://www.freebsd.org/cgi/query-pr.cgi?pr=184078 From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 23:24:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2589A87D for ; Sun, 20 Apr 2014 23:24:06 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 030551FE5 for ; Sun, 20 Apr 2014 23:24:05 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s3KNO4ba091879; Sun, 20 Apr 2014 23:24:05 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id 4py7smdfa3iw9curpcip23zcts; Sun, 20 Apr 2014 23:24:04 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: BeagleBone/eMMC boot oddity Date: Sun, 20 Apr 2014 16:24:04 -0700 Message-Id: <2CD725FF-B5D9-4207-BB88-642BE7B055FC@freebsd.org> To: Patrick Kelsey Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 23:24:06 -0000 Trying to take advantage of eMMC booting and running into a snag. I want to have a large SD card inserted for "extra storage" on a BeagleBone that boots and runs the system per se from eMMC. (Idea is to use the BeagleBone as a web server where the actual content is stored on the separate SD card for easy updating.) But when I try booting, I run into this problem: FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@t, Sat Apr 12 14:38:27 PDT 2014) DRAM: 512MB MMC Device 2 not found MMC Device 3 not found MMC Device 2 not found Number of U-Boot devices: 3 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... good. | can't load 'kernel' Basically, because unit=0 exists and has a FreeBSD partition, it seems that ubldr is never looking at unit 1 where the actual system is installed. Any ideas? Tim From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 23:37:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 362D3A4B for ; Sun, 20 Apr 2014 23:37:38 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13F8310DD for ; Sun, 20 Apr 2014 23:37:37 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s3KNbath091928 for freebsd-arm@freebsd.org; Sun, 20 Apr 2014 23:37:36 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id e5atbusnwtumj2kinvjyzxa34a; for freebsd-arm@freebsd.org; Sun, 20 Apr 2014 23:37:36 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Curious BeagleBone console hang... Message-Id: <723E6F77-A274-4115-8D37-C12353494EA1@freebsd.org> Date: Sun, 20 Apr 2014 16:37:36 -0700 To: FreeBSD ARM Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 23:37:38 -0000 Here's an odd one: $ stty 72 consistently hangs the serial console on a BeagleBone running FreeBSD-CURRENT r264208. (I found this out by accidentally omitting 'rows' when I typed the command.) Doesn't seem to affect an SSH session, only the serial console. After doing this, nothing seems to be running; the console is just completely non responsive: even echo is dead. I can recover by logging in through SSH and killing the console login. Trying to puzzle it out: $ truss stty 72 ... ioctl(0,TIOCGETA,0xbffffcb0) = 0 (0x0) ioctl(0,TIOCGETD,0xbffffc9c) = 0 (0x0) ioctl(0,TIOCGWINSZ,0xbffffcdc) = 0 (0x0) ioctl(1,TIOCGETA,0xbffffb60) = 0 (0x0) ioctl(2,TIOCGETA,0xbffffb60) = 0 (0x0) fstat(1,{ mode=crw------- ,inode=32,size=0,blksize=4096 }) = 0 (0x0) fstat(2,{ mode=crw------- ,inode=32,size=0,blksize=4096 }) = 0 (0x0 Does this make sense to anyone? Tim From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 00:24:44 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E6B63BA; Mon, 21 Apr 2014 00:24:44 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51E9014A5; Mon, 21 Apr 2014 00:24:43 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wc22M-0007CV-Qj; Mon, 21 Apr 2014 00:24:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3L0OeSC006689; Sun, 20 Apr 2014 18:24:40 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/jDv4g1236+IPZ7tXWKd29 Subject: Re: BeagleBone/eMMC boot oddity From: Ian Lepore To: Tim Kientzle In-Reply-To: <2CD725FF-B5D9-4207-BB88-642BE7B055FC@freebsd.org> References: <2CD725FF-B5D9-4207-BB88-642BE7B055FC@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Apr 2014 18:24:40 -0600 Message-ID: <1398039880.1124.368.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 00:24:44 -0000 On Sun, 2014-04-20 at 16:24 -0700, Tim Kientzle wrote: > Trying to take advantage of eMMC booting and running into a snag. > > I want to have a large SD card inserted for "extra storage" > on a BeagleBone that boots and runs the system per se > from eMMC. (Idea is to use the BeagleBone as a web server > where the actual content is stored on the separate SD > card for easy updating.) > > But when I try booting, I run into this problem: > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@t, Sat Apr 12 14:38:27 PDT 2014) > > DRAM: 512MB > MMC Device 2 not found > MMC Device 3 not found > MMC Device 2 not found > Number of U-Boot devices: 3 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=0 slice= partition=... good. > | > can't load 'kernel' > > Basically, because unit=0 exists and has a FreeBSD partition, > it seems that ubldr is never looking at unit 1 where the actual > system is installed. > > Any ideas? > > Tim In your u-boot environment set loaderdev=disk1 --Ian From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 00:35:16 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60258443; Mon, 21 Apr 2014 00:35:16 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 348A61567; Mon, 21 Apr 2014 00:35:16 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wc2CZ-000EGe-6N; Mon, 21 Apr 2014 00:35:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3L0ZD90006695; Sun, 20 Apr 2014 18:35:13 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19FoxdYMhfck5FrFa+2rrfN Subject: Re: Curious BeagleBone console hang... From: Ian Lepore To: Tim Kientzle In-Reply-To: <723E6F77-A274-4115-8D37-C12353494EA1@freebsd.org> References: <723E6F77-A274-4115-8D37-C12353494EA1@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Apr 2014 18:35:13 -0600 Message-ID: <1398040513.1124.369.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 00:35:16 -0000 On Sun, 2014-04-20 at 16:37 -0700, Tim Kientzle wrote: > Here's an odd one: > > $ stty 72 > > consistently hangs the serial console on a BeagleBone > running FreeBSD-CURRENT r264208. (I found this out > by accidentally omitting 'rows' when I typed the command.) > > Doesn't seem to affect an SSH session, only the serial console. > > After doing this, nothing seems to be running; the console > is just completely non responsive: even echo is dead. > > I can recover by logging in through SSH and killing the > console login. > > Trying to puzzle it out: > > $ truss stty 72 > ... > ioctl(0,TIOCGETA,0xbffffcb0) = 0 (0x0) > ioctl(0,TIOCGETD,0xbffffc9c) = 0 (0x0) > ioctl(0,TIOCGWINSZ,0xbffffcdc) = 0 (0x0) > ioctl(1,TIOCGETA,0xbffffb60) = 0 (0x0) > ioctl(2,TIOCGETA,0xbffffb60) = 0 (0x0) > fstat(1,{ mode=crw------- ,inode=32,size=0,blksize=4096 }) = 0 (0x0) > fstat(2,{ mode=crw------- ,inode=32,size=0,blksize=4096 }) = 0 (0x0 > > > Does this make sense to anyone? > > Tim You're setting the line speed to 72 baud, and due to recent kernel changes the console baud rate is allowed to be changed now, so you lose console comms as soon as the change takes effect. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 01:06:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B172C998; Mon, 21 Apr 2014 01:06:21 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8ADBA17A2; Mon, 21 Apr 2014 01:06:20 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s3L16Jhm092206; Mon, 21 Apr 2014 01:06:19 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id 82pxb6idnwdnrffzq6aihxnebw; Mon, 21 Apr 2014 01:06:19 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Curious BeagleBone console hang... From: Tim Kientzle In-Reply-To: <1398040513.1124.369.camel@revolution.hippie.lan> Date: Sun, 20 Apr 2014 18:06:19 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <723E6F77-A274-4115-8D37-C12353494EA1@freebsd.org> <1398040513.1124.369.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 01:06:21 -0000 On Apr 20, 2014, at 5:35 PM, Ian Lepore wrote: > On Sun, 2014-04-20 at 16:37 -0700, Tim Kientzle wrote: >> Here's an odd one: >> >> $ stty 72 >> >> consistently hangs the serial console on a BeagleBone >> running FreeBSD-CURRENT r264208. (I found this out >> by accidentally omitting 'rows' when I typed the command.) >> >> Doesn't seem to affect an SSH session, only the serial console. >> >> After doing this, nothing seems to be running; the console >> is just completely non responsive: even echo is dead. >> >> I can recover by logging in through SSH and killing the >> console login. >> >> Trying to puzzle it out: >> >> $ truss stty 72 >> ... >> ioctl(0,TIOCGETA,0xbffffcb0) = 0 (0x0) >> ioctl(0,TIOCGETD,0xbffffc9c) = 0 (0x0) >> ioctl(0,TIOCGWINSZ,0xbffffcdc) = 0 (0x0) >> ioctl(1,TIOCGETA,0xbffffb60) = 0 (0x0) >> ioctl(2,TIOCGETA,0xbffffb60) = 0 (0x0) >> fstat(1,{ mode=crw------- ,inode=32,size=0,blksize=4096 }) = 0 (0x0) >> fstat(2,{ mode=crw------- ,inode=32,size=0,blksize=4096 }) = 0 (0x0 >> >> >> Does this make sense to anyone? >> >> Tim > > You're setting the line speed to 72 baud, and due to recent kernel > changes the console baud rate is allowed to be changed now, so you lose > console comms as soon as the change takes effect. Thank you! I went through the stty man page several times and consistently overlooked the description for a bare number. That makes perfect sense. I guess getty must reset the line when the login session exits, which would explain why killing the login session recovers it. Tim From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 05:11:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 673F55CF; Mon, 21 Apr 2014 05:11:41 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB0901C08; Mon, 21 Apr 2014 05:11:40 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x12so2269879wgg.18 for ; Sun, 20 Apr 2014 22:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sz8nyIYP/FM5MsZ5My2TgalCmJP62mQGzwYVhq+AtoY=; b=TtYOxNXyPtUU1JA8PaGidtq/rcW40cRt2R6oq8YKCjrEenUrpEJrk3nsXAMtISbM/r 39cWnZ6fuADxEoIM2MMh9fmsJzntnQkU2yuV4ZsyfjG1giQk3TwjpoO49wHzin6Ow7Gt S0VwWrFFuoWLenOLm/nvb8khDwgz5mWV1wZGlISyDkAJigZcPwsequf8BXSkky13TxkD cefNZYask2pviFF8VOBm3AP38ZAQepr35pMhdY0fG9wfmzx3/yoYriyJtvy8IUnY21XF 3Hj6Ftsd35vwYoJL0vBfUKeLATHD66aVNoNfdnNY2Y4ClPL5M9jjisSRXXtl1RLNwL8T xqRA== X-Received: by 10.180.37.178 with SMTP id z18mr12491430wij.46.1398057098985; Sun, 20 Apr 2014 22:11:38 -0700 (PDT) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id do2sm13981404wib.18.2014.04.20.22.11.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Apr 2014 22:11:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Today's Crochet fixes From: fabiodive In-Reply-To: <55CF56A1-B69E-467D-B835-1DBD9053127E@freebsd.org> Date: Mon, 21 Apr 2014 06:11:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24AD766C-FA11-45AD-94B3-7C99EBF53FD0@freebsd.org> <55CF56A1-B69E-467D-B835-1DBD9053127E@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1510) Cc: Xuebing Wang , FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 05:11:41 -0000 Hello all, I have here my BBB with a working FreeBSD 11 revision 264703, the image was generated by the last crochet source from git, I used the u-boot from ports /usr/ports/sysutils/u-boot-beaglebone-eabi patched with the last diff files from Xuebing Wang to increase the CPU frequency clock to 1GHz. I had to modify a bit crochet source to allow installation of the u-boot from ports, I couldn't figure out a better way installing without = modifications, maybe it was my fault, I spent a bit of time following all the calls to = the=20 related functions and variables, in then end I forced to pickup u-boot from the installed port commenting out an testing if block and using an absolute path to the port. The command "ubench -c -s" output is: Ubench Single CPU: 9401 (0.39s) I suppose BBB is running at 1GHz, if somebody has got better ideas to check the system clock and do some benchmarking I will appreciate that. I am monitoring CPU temperature but the system I really stable. I like this setup. Thank you to all the guys who worked to every single piece of this puzzle. thank you cheers f. On Apr 20, 2014, at 19:48 , Tim Kientzle wrote: >=20 > On Apr 20, 2014, at 11:40 AM, Tom Everett wrote: >=20 >> Are the updated xdev instructions valid for FreeBSD-10 also, or just = for FreeBSD-11? >=20 > I believe they will work with both, though I've only tried with = 11-CURRENT. >=20 > Tim >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 09:07:17 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B154992; Mon, 21 Apr 2014 09:07:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F1721FC1; Mon, 21 Apr 2014 09:07:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s3L97Fwm057962; Mon, 21 Apr 2014 05:07:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s3L97FWR057957; Mon, 21 Apr 2014 09:07:15 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 21 Apr 2014 09:07:15 GMT Message-Id: <201404210907.s3L97FWR057957@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 09:07:17 -0000 TB --- 2014-04-21 07:50:28 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-21 07:50:28 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-21 07:50:28 - starting HEAD tinderbox run for arm/arm TB --- 2014-04-21 07:50:28 - cleaning the object tree TB --- 2014-04-21 07:51:08 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-21 07:51:12 - At svn revision 264720 TB --- 2014-04-21 07:51:13 - building world TB --- 2014-04-21 07:51:13 - CROSS_BUILD_TESTING=YES TB --- 2014-04-21 07:51:13 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-21 07:51:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-21 07:51:13 - SRCCONF=/dev/null TB --- 2014-04-21 07:51:13 - TARGET=arm TB --- 2014-04-21 07:51:13 - TARGET_ARCH=arm TB --- 2014-04-21 07:51:13 - TZ=UTC TB --- 2014-04-21 07:51:13 - __MAKE_CONF=/dev/null TB --- 2014-04-21 07:51:13 - cd /src TB --- 2014-04-21 07:51:13 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Apr 21 07:51:20 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_create_nil.c -o! uuid_create_nil.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_equal.c -o uuid! _equal.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_from_string.c -! o uuid_from_string.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_hash.c -o uuid_! hash.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_is_nil.c -o uui! d_is_nil.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_stream.c -o uui! d_stream.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_to_string.c -o ! uuid_to_string.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr.c -o xdr.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_array.c -o xdr_ar! ray.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_float.c -o xdr_fl! oat.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_mem.c -o xdr_mem.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_rec.c -o xdr_rec.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_reference.c -o xd! r_reference.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_sizeof.c -o xdr_s! izeof.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/xdr/xdr_stdio.c -o xdr_st! dio.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/softfloat/bits32/softfloa! t.c -o softfloat.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/arm/gen/fpgetround.c -o f! pgetround.o /tmp/fpgetround-ebc27e.s: Assembler messages: /tmp/fpgetround-ebc27e.s:21: Error: selected processor does not support `vmrs r0,fpscr' cc: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[3]: stopped in /src/lib/libc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-04-21 09:07:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-04-21 09:07:15 - ERROR: failed to build world TB --- 2014-04-21 09:07:15 - 4009.43 user 417.95 system 4606.35 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 11:06:43 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAAB6F2E for ; Mon, 21 Apr 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BDD24194F for ; Mon, 21 Apr 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3LB6hKv085648 for ; Mon, 21 Apr 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3LB6hoh085646 for freebsd-arm@FreeBSD.org; Mon, 21 Apr 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Apr 2014 11:06:43 GMT Message-Id: <201404211106.s3LB6hoh085646@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 11:06:44 -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/188510 arm [patch] "rtadvctl show" crashes on BeagleBone Black du o arm/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp f arm/184078 arm [xdev] cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o ports/175605 arm devel/binutils: please fix build binutils-2.23.1 in ra 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/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 ports/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) 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 30 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 12:48:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15301FEE; Mon, 21 Apr 2014 12:48:35 +0000 (UTC) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 763391432; Mon, 21 Apr 2014 12:48:34 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id b57so3580206eek.7 for ; Mon, 21 Apr 2014 05:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CZvkvaBp3wj2/DKxtZHIC3rMR6XVy1eOvd20IUvsnBM=; b=Ubs/mKRsTbXdoWjrJQyJZcGHbIAgnRYcqPV4sv+OQJQD2mKls9a7xG1yEPVDWSTYGP rMgUDlpwE60GATp1679dKiNJV5Z4hGFUG7KgizH8lIkGBKYH7dV+UyVZQuHsOreMtSIF EusrqNarjrXYcyFhIJqyQIIFuiYND7KXhMzjCPXYtnmFTjCul8Mk496dwPYdNeGe5OAp vkEk4XIVB/Um9rexsdv0TmX3zbdszJZVIu3NUb24y5+tegmxAN8VjBIlnEtapjZR3bkn +YKdYg8MbqB1hdv3GsW5YXknw5GWElLlgwu7kkU5O8wS62TxNfeAp9T6OyxLgcfdlZom 0Xfw== X-Received: by 10.14.115.195 with SMTP id e43mr2176056eeh.76.1398084512766; Mon, 21 Apr 2014 05:48:32 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id u46sm103358405eel.1.2014.04.21.05.48.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 05:48:31 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5355139C.8050804@hot.ee> Date: Mon, 21 Apr 2014 15:48:28 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: BeagleBone/eMMC boot oddity References: <2CD725FF-B5D9-4207-BB88-642BE7B055FC@freebsd.org> In-Reply-To: <2CD725FF-B5D9-4207-BB88-642BE7B055FC@freebsd.org> X-TagToolbar-Keys: D20140421154828446 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 12:48:35 -0000 On 2014-04-21 02:24, Tim Kientzle wrote: > Trying to take advantage of eMMC booting and running into a snag. Can you give me uboot version you're using (2014.01?) and your current set of patches for it so I could test it too? I'm assuming you have something I've not yet seen, so that's why I'm asking. From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 18:50:01 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 614953F8 for ; Mon, 21 Apr 2014 18:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5D418D1 for ; Mon, 21 Apr 2014 18:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3LIo18A037255 for ; Mon, 21 Apr 2014 18:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3LIo1Yw037254; Mon, 21 Apr 2014 18:50:01 GMT (envelope-from gnats) Date: Mon, 21 Apr 2014 18:50:01 GMT Message-Id: <201404211850.s3LIo1Yw037254@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Harald Weppner Subject: Re: arm/181601: Sporadic failure of root mount on ARM/Raspberry X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Harald Weppner List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 18:50:01 -0000 The following reply was made to PR arm/181601; it has been noted by GNATS. From: Harald Weppner To: "bug-followup@FreeBSD.org" , "info@martinlaabs.de" Cc: Subject: Re: arm/181601: Sporadic failure of root mount on ARM/Raspberry Date: Mon, 21 Apr 2014 18:38:08 +0000 --Apple-Mail=_79838C36-3AC2-44A1-89DC-2BB5E7BC29A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I=92ve been able to work around it by disabling high speed in a device = hint (hw.bcm2835.sdhci.hs=3D0) but was wondering if any progress on this = issue was made? Thanks & cheerio, Harry. --Apple-Mail=_79838C36-3AC2-44A1-89DC-2BB5E7BC29A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTVWWXAAoJEAK2yI4LwMAXNYcIAKqr2Z2p2/OsPRx015kaA8a0 NGahOiMwv0UBXlbqmFL5Ux0uNKR89Uo2615ptlfj0i9KhzkR6s/4kTFDTOJGtUX4 oNGgVzHodXHk360JQBDZoTobUNga35/0jt78buWD8RdBE8SudlgRqr6hE2v29iuD LZ3Wsb6By5VQ5tlxotlI73fFwvCIap4xwn/5oKoHNPVP0n2AsfzVo+Bsub2phVG5 2CTWphia4NEYDbjgJ29N53tRTfjx6Y05vd0uu6A2f9GuiyCDfObmbDChEP2iaxrF WENgH2AQSdLD1SeDIK8L1pnujiStBvuSTDRphdB7wQGwYMo3V4Cl4I7NfP4+GuQ= =//j+ -----END PGP SIGNATURE----- --Apple-Mail=_79838C36-3AC2-44A1-89DC-2BB5E7BC29A7-- From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 20:54:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2A6995C for ; Mon, 21 Apr 2014 20:54:41 +0000 (UTC) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ED6E1606 for ; Mon, 21 Apr 2014 20:54:41 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id k48so1029389wev.11 for ; Mon, 21 Apr 2014 13:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mezV61omzpcHPHpqDdUonodHW7u9Clt8DaP50K6amVo=; b=N7F0Xx0m1VaReLWES6rHsRQ86Gctl9qcq6ti+NF9KryMS9YhgjdXqJpBpss5pmOoND WyrtSme3LebA6tfpIrUvz3mKb9dJpPDkUTXU6dQkerdlvGtOTOh1CzFHuLbQN0KU24Ev H3iI735dwObHYX+KsjuCSVUZEEXw6YRdcTq4SmoR3myKyQltHw+CZEvEIbt4kilYh/9o K+vp/rqH6ErAkr/gGCDi4n+e38x5IdEq4MAX+LNxr6bSzWXxq1V4AiTTw599rKiTpsZN NK5HgjxyNFgOU/6vPaFPcw/QuccO99gI4e/uJXfT9QvBVHrZTn78IpiEwCF7DCAcscn/ n9cA== MIME-Version: 1.0 X-Received: by 10.180.93.41 with SMTP id cr9mr15403363wib.7.1398113678711; Mon, 21 Apr 2014 13:54:38 -0700 (PDT) Received: by 10.180.92.2 with HTTP; Mon, 21 Apr 2014 13:54:38 -0700 (PDT) Date: Tue, 22 Apr 2014 00:54:38 +0400 Message-ID: Subject: GSoC 2014 - FreeBSD on Android Emulator and (possibly) a phone From: Alexander Tarasikov To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:54:41 -0000 Hello, FreeBSD hackers! It's great news that I was accepted to GSoC 2014 for the project of porting FreeBSD to Android Emulator. I would like to report some of my progress and get advice on further directions. So I started by looking into the FreeBSD port to ARM Versatile board by Oleksandr Tymoshenko and got the image booting in QEMU which indicates that the cross-compiler toolchain is working correctly. I have added rudimentary Goldfish board (which is the virtual SoC and board emulated by the Android Emulator) to FreeBSD kernel and pushed a branch named 'android_goldfish_arm_10.0.0' based on release-10.0.0 to my github fork at https://github.com/astarasikov/freebsd/tree/android_goldfish_arm_10.0.0 Currently I did not manage to get it booting on the emulator yet. I have attached the GDB and verified that it gets loaded to the correct address and single-stepped it, but looks like MMU is not getting set up correctly and as soon as the kernel loads the program counter with the virtual address, it booms. I have tried various ARM revisions in both FreeBSD kernel and Android Emulator, but it's still not there. However, it was an overnight hack I made today so I need to invest more time into debugging and understanding FreeBSD Virtual Memory management. Since Android Emulator is based on QEMU, I will probably try adding Goldfish board to the source code of the QEMU version on which I had Versatile kernel running, but I think it's rather my fault :) Currently I'm running QEMU with Versatile inside FreeBSD and Android Emulator in Linux. I will look into using linux emulation to run the latest version of Android SDK and Emulator on FreeBSD. I think it would be good to get the latest version of emulator into ports, but that will depend on whether I have time for it. So currently for the midterm I want to get the kernel running with MMU :). If that goes well, porting MMC and Ethernet (SMC chip) emulation should be relatively easy. If I don't get drowned in debugging VM issues, we may have everything working quite soon. So I would like to ask the community which features would you recommend to implement during the course of the project except kernel with the support of block devices and networking? I can think of prebuilt images that could be easily deployed to Android Emulator on any platform. In previous mails it was discusses that it would be cool to get FreeBSD also running on some popular phone. If the emulator port does not take the whole summer, I could look into that. Unfortunately my phone (Sony Xperia Z) broke (the modem is not working and the screen is damaged partially though it can boot) so I'm thinking of getting some used Android Phone for hacking. I'm choosing between a Nexus 5 and Galaxy Note 3. I don't like Qualcomm but Nexus 5 is very popular (and has UART schematics available) while the exynos-based Galaxy Note is more freedom-friendly and the SoC is supported by the FreeBSD. -- Regards, Alexander From owner-freebsd-arm@FreeBSD.ORG Tue Apr 22 01:07:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99139241; Tue, 22 Apr 2014 01:07:37 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F9A61CDF; Tue, 22 Apr 2014 01:07:36 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id q58so4253802wes.40 for ; Mon, 21 Apr 2014 18:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bL2QStAjDjwTzDK8h9QvkdPoUOSztX1ghBVoJjuoOSc=; b=lCWjyxMsWmrGIZL6iYasQFdfR64x2dIx0xPOBEFyIRkqWZKypLgqJI/EjV/hH7nqIU 0PPFc1OakI7eUkbcZLsBzft2Ix6OpRsZE4tVEHSWCX7RVAM8jqR8o3lu7kcooSG2cGPT SeytuuuCFqMWVwGmUZ9grefuRdVdkGc4LcxhJvKRztmey02KiATuqTkitkApeZEV4wg2 vox+DDpquRJLdP2X0b/RO5LSlhHOlgnUX+EX3i6HOCJkUuPrqimov6J4NQPkARJ3TAAR 2ixKmV3DxKmir1s87hbskwl0j8OoQvMG4UtEyuyx61GPLFgy6pPo+1PL1JTJXB2VjFT/ Aspg== MIME-Version: 1.0 X-Received: by 10.194.81.164 with SMTP id b4mr31091722wjy.2.1398128855370; Mon, 21 Apr 2014 18:07:35 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Mon, 21 Apr 2014 18:07:35 -0700 (PDT) In-Reply-To: <2CD725FF-B5D9-4207-BB88-642BE7B055FC@freebsd.org> References: <2CD725FF-B5D9-4207-BB88-642BE7B055FC@freebsd.org> Date: Mon, 21 Apr 2014 21:07:35 -0400 Message-ID: Subject: Re: BeagleBone/eMMC boot oddity From: Winston Smith To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 01:07:37 -0000 On Sun, Apr 20, 2014 at 7:24 PM, Tim Kientzle wrote: > Trying to take advantage of eMMC booting and running into a snag. > > I want to have a large SD card inserted for "extra storage" > on a BeagleBone that boots and runs the system per se > from eMMC. (Idea is to use the BeagleBone as a web server > where the actual content is stored on the separate SD > card for easy updating.) I have booting 11-CURRENT with u-boot 2013.4 working. I built crotchet using Patrick's script to create an SD image which I put on a 4GB SD card, resized the freebsd (s2) partition with gpart and grew it to 3.7GB using growfs, I re-ran Patrick's script with BEAGLEBONE_BOOT_EMMC=y and copied the new image to the freebsd partition. Once I had booted on the BBB, I used dd to write the emmc version to the eMMC device, reboot and it works. I see the following from the FreeBSD loader: FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@freebsd, Fri Apr 18 19:01:14 EDT 2014) DRAM: 512MB MMC Device 2 not found MMC Device 3 not found MMC Device 2 not found Number of U-Boot devices: 3 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=...MMC Device 2 not found MMC Device 3 not found disk0: device open failed with error=2, handle=1 Checking unit=1 slice= partition=... good. Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x470708+0x2c78f8 syms=[0x4+0x85fe0+0x4+0x50d82] /boot/kernel/geom_label.ko text=0x50cc data=0x864+0x30 syms=[0x4+0x1020+0x4+0xfe2] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x0x80000100. Kernel entry at 0x80200100... ... Hope this helps somehow. -W From owner-freebsd-arm@FreeBSD.ORG Tue Apr 22 02:27:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84A9CDC4 for ; Tue, 22 Apr 2014 02:27:36 +0000 (UTC) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56B6014B0 for ; Tue, 22 Apr 2014 02:27:35 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id um1so4393457pbc.30 for ; Mon, 21 Apr 2014 19:27:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=FLys7Rt97RQW+Y6FO8hAFV33K+oCGLcf1Z21YehsHS0=; b=g+IsdY7zVq8GfV279452+MWc9h8ZclrtqPjuH3i0Qr41LGltAgESsEJx7hVveqYh8E yfSC1HKDRGJeqN031anBNOiaXbasRxsRuFyCEwBts3JgDia2aeGgsFOEMFOyrpqLp00T vW1GIn6LTfJaML2Nl+A4glqnNe+AjwitEMfDGZ7jagX/tIF7POpvHxks7Z3acEewJ5X/ 6TutpXmy9/YB+v7XZhqRavq8PTgkeySwtPYU5psJgcy2YxqRyN4y+hWKcGz4HHDr2VfF 3/VjALVRywktIr52IlwRsyoxiXaQjvTnUjHbo2dC+n6Mc70rmmEOuwueemuF6vFil7Zw 5Wrw== X-Gm-Message-State: ALoCoQkEkeOe0qaY92bkDluwrRSzHL1ITLLYI1W4/TGY5hkXvL9q3iE/p4WCmwByQVUDTXdX3g5e X-Received: by 10.68.137.136 with SMTP id qi8mr41860176pbb.79.1398133655203; Mon, 21 Apr 2014 19:27:35 -0700 (PDT) Received: from c-50-156-22-189.hsd1.ca.comcast.net (c-50-156-22-189.hsd1.ca.comcast.net. [50.156.22.189]) by mx.google.com with ESMTPSA id g6sm194347865pat.2.2014.04.21.19.27.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 19:27:34 -0700 (PDT) Sender: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: BeagleBone/eMMC boot oddity From: Tim Kientzle In-Reply-To: <5355139C.8050804@hot.ee> Date: Mon, 21 Apr 2014 19:27:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CD725FF-B5D9-4207-BB88-642BE7B055FC@freebsd.org> <5355139C.8050804@hot.ee> To: "Sulev-Madis Silber (ketas)" X-Mailer: Apple Mail (2.1874) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 02:27:36 -0000 On Apr 21, 2014, at 5:48 AM, Sulev-Madis Silber (ketas) = wrote: > On 2014-04-21 02:24, Tim Kientzle wrote: >> Trying to take advantage of eMMC booting and running into a snag. >=20 >=20 > Can you give me uboot version you're using (2014.01?) and your current > set of patches for it so I could test it too? I=92m using Crochet with no other patches. Ian Lepore=92s suggestion of adding loaderdev=3Ddisk1 to bb-uenv.txt on the MSDOS partition fixed it for me so that it always = boots from eMMC even if there is an SD card inserted. Otherwise, it = tries to boot from SD if there is an SD card and only boots from eMMC if = there is no SD card inserted. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Tue Apr 22 02:56:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40CE03BB for ; Tue, 22 Apr 2014 02:56:54 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E44E16FA for ; Tue, 22 Apr 2014 02:56:54 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so4536950iec.5 for ; Mon, 21 Apr 2014 19:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bQDnYjhg6aPlHve+vq3KwQX/diw/qw5y/7uzuGm8p5A=; b=m7gpzAoNEug475oRHN81ZGXAQzJzeOpV/6HWh/1JHJGEPhyAAM9Pl5OTAGynZkjtCL A64O8zW6m7TGV11FnXWJPuKfwuExDY6yPAds2eZJuenO90zHhZiKTk536Ucpt1YX3EMt wt+NXMBvGCSqJunnmry6Xb046xGwHNnC0qrB17Aa+evkoQht1721Blx9NuoYJqS8ZrV+ mu5yAFsiQKL0sLVoTaPk+RkJCJupBHrIyMp1p7x7pcpLOwFyRsfotg2QZfteXm6+EXY0 xjEXiTuf6vlp5VaXPpa9xe75frYfbf3y5fZkTTgIHHGXq+VdP9e8ABdsQJqPk9IHJ+eP SBGA== MIME-Version: 1.0 X-Received: by 10.42.44.4 with SMTP id z4mr35019743ice.34.1398135413411; Mon, 21 Apr 2014 19:56:53 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Mon, 21 Apr 2014 19:56:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Apr 2014 10:56:53 +0800 Message-ID: Subject: Re: GSoC 2014 - FreeBSD on Android Emulator and (possibly) a phone From: Ganbold Tsagaankhuu To: Alexander Tarasikov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 02:56:54 -0000 Alexander, On Tue, Apr 22, 2014 at 4:54 AM, Alexander Tarasikov < alexander.tarasikov@gmail.com> wrote: > Hello, FreeBSD hackers! > > It's great news that I was accepted to GSoC 2014 for the project of > porting FreeBSD to Android Emulator. > That is great news and it is very cool. > I would like to report some of my progress and get advice on further > directions. > > So I started by looking into the FreeBSD port to ARM Versatile board > by Oleksandr Tymoshenko and got the image booting in QEMU which > indicates that the cross-compiler toolchain is working correctly. > > I have added rudimentary Goldfish board (which is the virtual SoC and > board emulated by the Android Emulator) to FreeBSD kernel and pushed a > branch named 'android_goldfish_arm_10.0.0' based on release-10.0.0 to > my github fork at > https://github.com/astarasikov/freebsd/tree/android_goldfish_arm_10.0.0 > > Currently I did not manage to get it booting on the emulator yet. I > have attached the GDB and verified that it gets loaded to the correct > address and single-stepped it, but looks like MMU is not getting set > up correctly and as soon as the kernel loads the program counter with > the virtual address, it booms. I have tried various ARM revisions in > both FreeBSD kernel and Android Emulator, but it's still not there. > However, it was an overnight hack I made today so I need to invest > more time into debugging and understanding FreeBSD Virtual Memory > management. > > Are you sure release 10.0 would do ok in your case? In my opinion it is much better to use head version of the src tree, there are number of reasons. If necessary it would be easier to commit code changes to head src tree instead of 10.0 release or stable src tree. > Since Android Emulator is based on QEMU, I will probably try adding > Goldfish board to the source code of the QEMU version on which I had > Versatile kernel running, but I think it's rather my fault :) > > Currently I'm running QEMU with Versatile inside FreeBSD and Android > Emulator in Linux. I will look into using linux emulation to run the > latest version of Android SDK and Emulator on FreeBSD. I think it > would be good to get the latest version of emulator into ports, but > that will depend on whether I have time for it. > > So currently for the midterm I want to get the kernel running with MMU > :). If that goes well, porting MMC and Ethernet (SMC chip) emulation > should be relatively easy. > > If I don't get drowned in debugging VM issues, we may have everything > working quite soon. So I would like to ask the community which > features would you recommend to implement during the course of the > project except kernel with the support of block devices and > networking? I can think of prebuilt images that could be easily > deployed to Android Emulator on any platform. > > In previous mails it was discusses that it would be cool to get > FreeBSD also running on some popular phone. If the emulator port does > not take the whole summer, I could look into that. Unfortunately my > phone (Sony Xperia Z) broke (the modem is not working and the screen > is damaged partially though it can boot) so I'm thinking of getting > some used Android Phone for hacking. I'm choosing between a Nexus 5 > and Galaxy Note 3. I don't like Qualcomm but Nexus 5 is very popular > (and has UART schematics available) while the exynos-based Galaxy Note > is more freedom-friendly and the SoC is supported by the FreeBSD. > I heard exynos doc is not good or even no doc at all in some cases. Correct me if I'm wrong here. best regards, Ganbold > > -- > Regards, Alexander > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Tue Apr 22 10:33:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 375E4E4D; Tue, 22 Apr 2014 10:33:29 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 998EC12F9; Tue, 22 Apr 2014 10:33:28 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id b57so4452174eek.12 for ; Tue, 22 Apr 2014 03:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=20OvepNaX84cS+D8GVfBaB+FW6KU7+7OTyqEoDP0tpk=; b=Vr36RodaIA1J5HtaCwXAtSpJztTuZess9HHhWBNdy5ra1yKnal/j9cSuTWGcIUl305 JSmgcWT0wwici9yS+MwDA/CrHO/P+FPVXtocU2zZ9uh8Wo01KKmyhtnvW+OOyz0lxU65 g4TSrKhiMG8UqLSPGrAxhWhc0r2VS6PVe0ealdZjYgpNShUFOgh4+R7SC3TgKG0sMPXq x+jFffHZDBXMUjJ2jd650kUs9yMP36p4vI0/qLxMy/SHgqz5EaBk2Kgj/LMXxnE2G/cE XUGyHsAtPQRf5Z/K5ilzxM6ZARtKu8lU7p/3Zl0DGlq+WJmPGnSb2ZB+dZe+aPfTQZqj n/GA== X-Received: by 10.14.198.197 with SMTP id v45mr55109185een.9.1398162805891; Tue, 22 Apr 2014 03:33:25 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id bc51sm111798737eeb.22.2014.04.22.03.33.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 03:33:24 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53564568.4030909@hot.ee> Date: Tue, 22 Apr 2014 13:33:12 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: BeagleBone/eMMC boot oddity References: <2CD725FF-B5D9-4207-BB88-642BE7B055FC@freebsd.org> <5355139C.8050804@hot.ee> In-Reply-To: X-TagToolbar-Keys: D20140422133312408 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 10:33:29 -0000 On 2014-04-22 05:27, Tim Kientzle wrote: > > On Apr 21, 2014, at 5:48 AM, Sulev-Madis Silber (ketas) wrote: > >> On 2014-04-21 02:24, Tim Kientzle wrote: >>> Trying to take advantage of eMMC booting and running into a snag. >> >> >> Can you give me uboot version you're using (2014.01?) and your current >> set of patches for it so I could test it too? > > I’m using Crochet with no other patches. I thought it's new uboot already... > > > Ian Lepore’s suggestion of adding > > loaderdev=disk1 > > to bb-uenv.txt on the MSDOS partition fixed it for me so that it always boots from eMMC even if there is an SD card inserted. Otherwise, it tries to boot from SD if there is an SD card and only boots from eMMC if there is no SD card inserted. > > Cheers, > > Tim > From owner-freebsd-arm@FreeBSD.ORG Tue Apr 22 23:34:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2CB3F7A for ; Tue, 22 Apr 2014 23:34:25 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CC591A71 for ; Tue, 22 Apr 2014 23:34:25 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id x48so138059wes.21 for ; Tue, 22 Apr 2014 16:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q/1C9jg7xkNebuXo1gVmlKpLQH3BHPSzpUVXNZykp0s=; b=yswmnTvCX/2CNpe+NDVqUH9z8AITsShi02lUcQwyOTX5gncF0Sr+hwdU0raizCBqUt 67efygK+NxfQlV6fJmExxBIN4W+sXzTI+ImVGM53AU8SOJvet08mYGWustJ26hfffyRj DKAHsnUabtfHGhDyaov7d6tNj+wtBP3/pZdENf6xvWWjOvzoCGfDF35XMcKr6ADzyuoP 4zg7Yo+q3yLSYDOn3drrfz/C4yQyWFb3bnALUeZUq1UHlRh9uia/pNgvPbZFGFbXNudQ fumaKj7VQlK+nsBqqpQ/vuXpDb5O7SxPdP1mZWJK802dhGgmjThGqSClTG6+MLdlX9VW 1Erw== MIME-Version: 1.0 X-Received: by 10.180.93.41 with SMTP id cr9mr482227wib.7.1398209662580; Tue, 22 Apr 2014 16:34:22 -0700 (PDT) Received: by 10.180.92.2 with HTTP; Tue, 22 Apr 2014 16:34:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 03:34:22 +0400 Message-ID: Subject: Re: GSoC 2014 - FreeBSD on Android Emulator and (possibly) a phone From: Alexander Tarasikov To: Ganbold Tsagaankhuu Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 23:34:25 -0000 On Tue, Apr 22, 2014 at 6:56 AM, Ganbold Tsagaankhuu wrote: Hey! > > Are you sure release 10.0 would do ok in your case? > In my opinion it is much better to use head version of the src tree, there > are number of reasons. > If necessary it would be easier to commit code changes to head src tree > instead of 10.0 release or stable src tree. > Definitely. Versatile works on 10.0, so at least basic stuff like MMU should not be broken :) Will switch to head once I get timer and IRQ controller working properly. So I have got the kernel booting and UART working. Basically, it was crashing because the Cortex-A8 revision0 was not supported by FreeBSD and I added the core ID to avoid patching Android Emulator. Then I fixed some typos in the DTB and it worked. And we have the log, something like the following :) timer0: mem 0xff003000-0xff003fff irq 3 on simplebus0 Timecounter "Goldfish Timecouter" frequency 1000000 Hz quality 200 Event timer "Goldfish Event Timer 0" frequency 62500 Hz quality 200 done. 0xc0379b04(0)... done. 0xc011eb60(0)... done. 0xc0208fb0(0)... done. subsystem 4000000 > > > I heard exynos doc is not good or even no doc at all in some cases. > Correct me if I'm wrong here. > At least for Exynos4 TRM was available and looks like there's one for Exynos5 (I've added the link if you're interested) The good thing about Exynos is that all of hardware is supported by the vanilla linux without binary blobs so there's a reference implementation, so to say. By everything I mean that even camera is supported by the free driver. Some other SoCs like OMAP4 use a closed-source firmware running on a secondary cpu (DSP in OMAP4, modem in Qualcomm) that can control some hw. On omap4 the blob controls the camera, for example. On the other hand, if we're not diving into fanatism and conspiracy-theoretical paranoia, that does not prevent us from implementing support for hardware, and binaries can be pulled from public android images with a script. http://www.samsung.com/global/business/semiconductor/file/product/Exynos_5_Dual_User_Manaul_Public_REV100-0.pdf > best regards, > > Ganbold > > >> >> >> -- >> Regards, Alexander >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > -- Regards, Alexander From owner-freebsd-arm@FreeBSD.ORG Wed Apr 23 12:16:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 982C4A2C for ; Wed, 23 Apr 2014 12:16:56 +0000 (UTC) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2830C1DC5 for ; Wed, 23 Apr 2014 12:16:56 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id d17so720302eek.4 for ; Wed, 23 Apr 2014 05:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9kgS7IiLdkVPXnr/FREaCF1FTkGWqKUZag2C8je3mNA=; b=qjGESxQ7Z9xnjC2L3j2UMQUtynBY7CMoM7uFRM9VDKeVU8jo8nhPOl7n0q2swk5z7w bbCvqadIQUzDzJlWC236IDrR4H+KMnggoJCsbd3UCmnEgUoxErlPpY/EUOVm4LuBhAt1 NDwUxCilvFMGjozANCCMuRw8mRUtU6nLQ18asB/sX68aYSloBklmABe8Nal8iC1s0uM+ 5Zk0bltCGQhetIPffZolCAs5OqKz0BSXmTIf+QpytdcjjU3WLmYoi8d+Ztg+S1hLrdvS d9VDTgkhlIUlQ/6tH7aBgIWxTDnNVw24Kf39D0FOlBHLK+51u1rTi+hK0OpEiVBVUu+D BTcg== X-Received: by 10.14.246.1 with SMTP id p1mr62365109eer.20.1398255414337; Wed, 23 Apr 2014 05:16:54 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id e42sm5783199eev.32.2014.04.23.05.16.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 05:16:53 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5357AF24.2050503@hot.ee> Date: Wed, 23 Apr 2014 15:16:36 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Alexander Tarasikov Subject: Re: GSoC 2014 - FreeBSD on Android Emulator and (possibly) a phone References: In-Reply-To: X-TagToolbar-Keys: D20140423151636162 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 12:16:56 -0000 My excitement of getting FreeBSD to Note 3 quickly vanished when I found out that LTE version uses different HW... Of course that doesn't mean we should stop porting to Exynos, but... Damn, why hardware makers need have rules that seem to protect them from everyone else except actual competitors? From owner-freebsd-arm@FreeBSD.ORG Wed Apr 23 16:13:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABC55840 for ; Wed, 23 Apr 2014 16:13:26 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A8AB1867 for ; Wed, 23 Apr 2014 16:13:26 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id ih12so1080356qab.11 for ; Wed, 23 Apr 2014 09:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Aq5fW5+96TyqCEA5OrzGVJjao8igydoDI8w/VxkQkpk=; b=0K582oBYVuQxaimOnySPN+6GxcDarDyLmj+9l7nD8kpPZ/xIG4CwFrfOOMwGnIch/e eplodnvXZ1rWbgmu8mkVRFmNs9TAW6scpwEuoH9ivi1oTqm9RvY+ETnYoLHVVemBN7dd KZEM7fFQCPApxKAuIjfCw/pm1S5fzgW9N/gtwsX8ow25xC/01mwersq35pG6Z6kl6dMw OidMANwQAHNmoufRKfX88iAQUpEqj2XuAjUKbJ0Fcya0TnPYPhVJOUgFSUqrRh46vTHs ELySDjUo3JvaMV4T/BmVSeNi23zRxc2v4H24dBxSlO7ln7x9q7k5re1YJAYNqN5t2WAG zcQQ== MIME-Version: 1.0 X-Received: by 10.224.76.74 with SMTP id b10mr60864618qak.49.1398269603259; Wed, 23 Apr 2014 09:13:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Wed, 23 Apr 2014 09:13:23 -0700 (PDT) In-Reply-To: <5357AF24.2050503@hot.ee> References: <5357AF24.2050503@hot.ee> Date: Wed, 23 Apr 2014 09:13:23 -0700 X-Google-Sender-Auth: nXBbaPgJ5GRnHpOwvIWCoAXjh4Q Message-ID: Subject: Re: GSoC 2014 - FreeBSD on Android Emulator and (possibly) a phone From: Adrian Chadd To: "Sulev-Madis Silber (ketas)" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , Alexander Tarasikov X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:13:26 -0000 On 23 April 2014 05:16, Sulev-Madis Silber (ketas) wrote: > My excitement of getting FreeBSD to Note 3 quickly vanished when I found > out that LTE version uses different HW... > Of course that doesn't mean we should stop porting to Exynos, but... > > Damn, why hardware makers need have rules that seem to protect them from > everyone else except actual competitors? Because the chip manufacturers have this habit of integrating things into one IC die. -a From owner-freebsd-arm@FreeBSD.ORG Wed Apr 23 17:39:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7AD7D47 for ; Wed, 23 Apr 2014 17:39:36 +0000 (UTC) Received: from mail.machdep.com (mail.machdep.com [195.91.211.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A9D7125F for ; Wed, 23 Apr 2014 17:39:36 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=machdep.com) by mail.machdep.com with smtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wd0X3-000DPu-6r; Wed, 23 Apr 2014 21:00:25 +0400 Received: by machdep.com (nbSMTP-1.00) for uid 1001 br@machdep.com; Wed, 23 Apr 2014 21:00:25 +0400 (MSK) Date: Wed, 23 Apr 2014 21:00:25 +0400 From: Ruslan Bukin To: Alexander Tarasikov Subject: Re: GSoC 2014 - FreeBSD on Android Emulator and (possibly) a phone Message-ID: <20140423170025.GA51552@machdep.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 17:39:37 -0000 On Wed, Apr 23, 2014 at 03:34:22AM +0400, Alexander Tarasikov wrote: > http://www.samsung.com/global/business/semiconductor/file/product/Exynos_5_Dual_User_Manaul_Public_REV100-0.pdf Note public manual is truncated and has first 16 chapters only. -Ruslan From owner-freebsd-arm@FreeBSD.ORG Wed Apr 23 20:26:06 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF587F42; Wed, 23 Apr 2014 20:26:06 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31B861383; Wed, 23 Apr 2014 20:26:05 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s3NKPqhv066620; Wed, 23 Apr 2014 22:25:52 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s3NKPqaM066047; Wed, 23 Apr 2014 20:25:52 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 23 Apr 2014 20:25:52 GMT Message-Id: <201404232025.s3NKPqaM066047@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 20:26:07 -0000 TB --- 2014-04-23 19:30:46 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-04-23 19:30:46 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-23 19:30:46 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-04-23 19:30:46 - cleaning the object tree TB --- 2014-04-23 19:30:46 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-23 19:31:37 - At svn revision 264831 TB --- 2014-04-23 19:31:38 - building world TB --- 2014-04-23 19:31:38 - CROSS_BUILD_TESTING=YES TB --- 2014-04-23 19:31:38 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-23 19:31:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-23 19:31:38 - SRCCONF=/dev/null TB --- 2014-04-23 19:31:38 - TARGET=arm TB --- 2014-04-23 19:31:38 - TARGET_ARCH=arm TB --- 2014-04-23 19:31:38 - TZ=UTC TB --- 2014-04-23 19:31:38 - __MAKE_CONF=/dev/null TB --- 2014-04-23 19:31:38 - cd /src TB --- 2014-04-23 19:31:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Apr 23 19:31:48 UTC 2014 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp -o DwarfCompileUnit.o c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp -o DwarfDebug.o c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfException.cpp -o DwarfException.o /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfException.cpp: In member function 'void llvm::DwarfException::ComputeCallSiteTable(llvm::SmallVectorImpl&, const llvm::DenseMap >&, const llvm::SmallVectorImpl&, const llvm::SmallVectorImpl&)': /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfException.cpp:229: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmasmprinter *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-04-23 20:25:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-04-23 20:25:51 - ERROR: failed to build world TB --- 2014-04-23 20:25:51 - 2706.50 user 612.65 system 3305.21 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 00:40:00 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8860CD0 for ; Thu, 24 Apr 2014 00:40:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94BFA1BB4 for ; Thu, 24 Apr 2014 00:40:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3O0e0On068695 for ; Thu, 24 Apr 2014 00:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3O0e0qP068693; Thu, 24 Apr 2014 00:40:00 GMT (envelope-from gnats) Resent-Date: Thu, 24 Apr 2014 00:40:00 GMT Resent-Message-Id: <201404240040.s3O0e0qP068693@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, Winston Smith Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4DC1C51 for ; Thu, 24 Apr 2014 00:32:13 +0000 (UTC) Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B11A91B4F for ; Thu, 24 Apr 2014 00:32:13 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s3O0WD0Q011703 for ; Thu, 24 Apr 2014 00:32:13 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s3O0WDaH011684; Thu, 24 Apr 2014 00:32:13 GMT (envelope-from nobody) Message-Id: <201404240032.s3O0WDaH011684@cgiserv.freebsd.org> Date: Thu, 24 Apr 2014 00:32:13 GMT From: Winston Smith To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/188933: lock order reversal: backtrace while writing to SD/eMMC X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 00:40:00 -0000 >Number: 188933 >Category: arm >Synopsis: lock order reversal: backtrace while writing to SD/eMMC >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: Thu Apr 24 00:40:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Winston Smith >Release: 10.0-STABLE >Organization: >Environment: FreeBSD beaglebone 10.0-STABLE FreeBSD 10.0-STABLE #0 r264836: Wed Apr 23 18:52:04 EDT 2014 root@freebsd:/root/Work/crochet-freebsd/work/obj/arm.armv6/usr/src/FreeBSD-stable-10/sys/BEAGLEBONE arm >Description: I used crotchet-freebsd to build an ARM version of FreeBSD 10.0-STABLE r264836 for the BeagleBone Black. I booted a BeagleBone from the SD card. NOT the eMMC (although I have also seen this in FreeBSD-CURRENT booted from the eMMC). Next, I copied over bash-4.3.src.tgz to build and while unpacking it with `tar xf`, I see the following on the console: lock order reversal: 1st 0xcd182f70 bufwait (bufwait) @ /usr/src/FreeBSD-stable-10/sys/kern/vfs_bio.c:3050 2nd 0xc29c6a00 dirhash (dirhash) @ /usr/src/FreeBSD-stable-10/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0540880 lr = 0xc0230328 (db_trace_self_wrapper+0x30) sp = 0xdeafa7e8 fp = 0xdeafa900 r10 = 0xc29c6a00 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc0230328 lr = 0xc0398c90 (kdb_backtrace+0x38) sp = 0xdeafa908 fp = 0xdeafa910 r4 = 0xc067e3a4 r5 = 0xc05a5545 r6 = 0xc05c1009 r7 = 0xc05aaab5 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0398c90 lr = 0xc03b367c (witness_checkorder+0xe48) sp = 0xdeafa918 fp = 0xdeafa968 r4 = 0xc05c13cd witness_checkorder() at witness_checkorder+0xe48 pc = 0xc03b367c lr = 0xc0368dec (_sx_xlock+0x84) sp = 0xdeafa970 fp = 0xdeafa998 r4 = 0x0000011c r5 = 0xc05c1006 r6 = 0xc29c6a10 r7 = 0xc29c6a00 r8 = 0x00000000 r9 = 0xc2ef27e0 r10 = 0x00000000 _sx_xlock() at _sx_xlock+0x84 pc = 0xc0368dec lr = 0xc04fc83c (ufsdirhash_add+0x34) sp = 0xdeafa9a0 fp = 0xdeafa9b8 r4 = 0xc29c6a00 r5 = 0x00000818 r6 = 0xc2eee180 r7 = 0xdeafaa50 r8 = 0xdeafaa50 ufsdirhash_add() at ufsdirhash_add+0x34 pc = 0xc04fc83c lr = 0xc04ff350 (ufs_direnter+0x63c) sp = 0xdeafa9c0 fp = 0xdeafaa28 r4 = 0xc2eee180 r5 = 0x00000018 r6 = 0xcd39b818 r7 = 0xdeafaa50 r8 = 0xc2c41c80 r9 = 0xc2ef27e0 ufs_direnter() at ufs_direnter+0x63c pc = 0xc04ff350 lr = 0xc05087f4 (ufs_makeinode+0x3ec) sp = 0xdeafaa30 fp = 0xdeafab90 r4 = 0x00000000 r5 = 0xdeafad30 r6 = 0xdeafaa50 r7 = 0x00000000 r8 = 0xdeafad48 r9 = 0xc2ef27e0 r10 = 0xc2f33b80 ufs_makeinode() at ufs_makeinode+0x3ec pc = 0xc05087f4 lr = 0xc0504bdc (ufs_create+0x24) sp = 0xdeafab98 fp = 0xdeafab98 r4 = 0xdeafac68 r5 = 0xc06629d0 r6 = 0x00000000 r7 = 0x00100a02 r8 = 0x00000000 r9 = 0xdeafad50 r10 = 0xdeafad30 ufs_create() at ufs_create+0x24 pc = 0xc0504bdc lr = 0xc0563fc4 (VOP_CREATE_APV+0xd0) sp = 0xdeafaba0 fp = 0xdeafabb0 VOP_CREATE_APV() at VOP_CREATE_APV+0xd0 pc = 0xc0563fc4 lr = 0xc04143ac (vn_open_cred+0x274) sp = 0xdeafabb8 fp = 0xdeafac98 r4 = 0xdeaface0 r5 = 0xdeafad30 r6 = 0xc2ef27e0 vn_open_cred() at vn_open_cred+0x274 pc = 0xc04143ac lr = 0xc0414130 (vn_open+0x24) sp = 0xdeafaca0 fp = 0xdeafaca8 r4 = 0xc2c41c80 r5 = 0x000500cf r6 = 0x00000012 r7 = 0xdeaface0 r8 = 0x00000000 r9 = 0x20c4a380 r10 = 0xdeafacd0 vn_open() at vn_open+0x24 pc = 0xc0414130 lr = 0xc040d668 (kern_openat+0x248) sp = 0xdeafacb0 fp = 0xdeafada8 kern_openat() at kern_openat+0x248 pc = 0xc040d668 lr = 0xc040d3b0 (sys_open+0x28) sp = 0xdeafadb0 fp = 0xdeafadb8 r4 = 0xc2c41c80 r5 = 0xc29da640 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000001 r9 = 0xdeafae10 r10 = 0x20c42080 sys_open() at sys_open+0x28 pc = 0xc040d3b0 lr = 0xc0552a7c (swi_handler+0x284) sp = 0xdeafadc0 fp = 0xdeafae58 swi_handler() at swi_handler+0x284 pc = 0xc0552a7c lr = 0xc05421ac (swi_entry+0x2c) sp = 0xdeafae60 fp = 0xbffffa28 r4 = 0x20c09200 r5 = 0x000001a4 r6 = 0x20c4a39b r7 = 0x00000005 r8 = 0x00000001 r9 = 0x20c09364 swi_entry() at swi_entry+0x2c pc = 0xc05421ac lr = 0xc05421ac (swi_entry+0x2c) sp = 0xdeafae60 fp = 0xbffffa28 Unable to unwind further Filesystem mounts are as follows: /dev/ufs/sdfreebsd1 on / (ufs, local, noatime, journaled soft-updates, nfsv4acls) devfs on /dev (devfs, local) /dev/msdosfs/SDBOOT on /boot/msdos (msdosfs, local, noatime) /dev/md0 on /tmp (ufs, local, noatime, soft-updates) /dev/md1 on /var/log (ufs, local, noatime, soft-updates) /dev/md2 on /var/tmp (ufs, local, noatime, soft-updates) And here's the dmesg output: KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-STABLE #0 r264836: Wed Apr 23 18:52:04 EDT 2014 root@freebsd:/usr/home/davem/Work/crochet-freebsd/work/obj/arm.armv6/usr/src/FreeBSD-stable-10/sys/BEAGLEBONE arm FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 WARNING: WITNESS option enabled, expect reduced performance. CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 515538944 (491 MB) Texas Instruments AM3358 Processor, Revision ES1.1 random: initialized simplebus0: on fdtbus0 aintc0: mem 0x48200000-0x48200fff on simplebus0 aintc0: Revision 5.0 ti_scm0: mem 0x44e10000-0x44e11fff on simplebus0 am335x_prcm0: mem 0x44e00000-0x44e012ff on simplebus0 am335x_prcm0: Clocks: System 24.0 MHz, CPU 550 MHz am335x_dmtimer0: mem 0x44e05000-0x44e05fff,0x44e31000-0x44e31fff,0x48040000-0x48040fff,0x48042000-0x48042fff,0x48044000-0x48044fff,0x48046000-0x48046fff,0x48048000-0x48048fff,0x4804a000-0x4804afff irq 66,67,68,69,92,93,94,95 on simplebus0 Timecounter "AM335x Timecounter" frequency 24000000 Hz quality 1000 Event timer "AM335x Eventtimer0" frequency 24000000 Hz quality 1000 gpio0: mem 0x44e07000-0x44e07fff,0x4804c000-0x4804cfff,0x481ac000-0x481acfff,0x481ae000-0x481aefff irq 96,97,98,99,32,33,62,63 on simplebus0 gpioc0: on gpio0 gpiobus0: on gpio0 uart0: mem 0x44e09000-0x44e09fff irq 72 on simplebus0 uart0: console (115384,n,8,1) ti_edma30: mem 0x49000000-0x490fffff,0x49800000-0x498fffff,0x49900000-0x499fffff,0x49a00000-0x49afffff irq 12,13,14 on simplebus0 ti_edma30: EDMA revision 40014c00 sdhci_ti0: mem 0x48060000-0x48060fff irq 64 on simplebus0 mmc0: on sdhci_ti0 sdhci_ti1: mem 0x481d8000-0x481d8fff irq 28 on simplebus0 mmc1: on sdhci_ti1 cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq 40,41,42,43 on simplebus0 cpsw0: CPSW SS Version 1.12 (0) cpsw0: Initial queue size TX=128 RX=384 cpsw0: Ethernet address: 90:59:af:7c:14:f7 miibus0: on cpsw0 smscphy0: PHY 0 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto iichb0: mem 0x44e0b000-0x44e0bfff irq 70 on simplebus0 iichb0: I2C revision 4.0 iicbus0: on iichb0 iic0: on iicbus0 am335x_pmic0: at addr 0x24 on iicbus0 am335x_pwm0: mem 0x48300000-0x483000ff,0x48300100-0x4830017f,0x48300180-0x483001ff,0x48300200-0x4830025f irq 86,58 on simplebus0 am335x_pwm1: mem 0x48302000-0x483020ff,0x48302100-0x4830217f,0x48302180-0x483021ff,0x48302200-0x4830225f irq 87,59 on simplebus0 am335x_pwm2: mem 0x48304000-0x483040ff,0x48304100-0x4830417f,0x48304180-0x483041ff,0x48304200-0x4830425f irq 88,60 on simplebus0 musbotg0: mem 0x47400000-0x47400fff,0x47401000-0x474012ff,0x47401300-0x474013ff,0x47401400-0x474017ff,0x47401800-0x47401aff,0x47401b00-0x47401bff,0x47401c00-0x47401fff irq 17,18,19 on simplebus0 musbotg0: TI AM335X USBSS v0.0.13 usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus0 on musbotg0 usbus1: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus1 on musbotg0 Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 mmcsd0: 4GB at mmc0 48.0MHz/4bit/65535-block uhub0: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered mmcsd1: 2GB at mmc1 48.0MHz/8bit/65535-block am335x_pmic0: TPS65217C ver 1.2 powered by AC random: unblocking device. WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufs/sdfreebsd1 [rw,noatime]... warning: no time-of-day clock registered, system time will not be set accurately >How-To-Repeat: Happens on a fairly regular bases when accessing the SD card or eMMC devices. I've also seen it when umounting filesystems as well as during /sbin/halt. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 01:00:01 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CA33210 for ; Thu, 24 Apr 2014 01:00:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DB461D34 for ; Thu, 24 Apr 2014 01:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3O100Wi076853 for ; Thu, 24 Apr 2014 01:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3O100SR076852; Thu, 24 Apr 2014 01:00:00 GMT (envelope-from gnats) Date: Thu, 24 Apr 2014 01:00:00 GMT Message-Id: <201404240100.s3O100SR076852@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Winston Smith Subject: Re: arm/188933: lock order reversal: backtrace while writing to SD/eMMC X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Winston Smith List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 01:00:01 -0000 The following reply was made to PR arm/188933; it has been noted by GNATS. From: Winston Smith To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/188933: lock order reversal: backtrace while writing to SD/eMMC Date: Wed, 23 Apr 2014 20:56:30 -0400 --047d7b3a8214da983504f7bf51d6 Content-Type: text/plain; charset=UTF-8 Happened again, with a different report: lock order reversal: 1st 0xc2ad7814 ufs (ufs) @ /usr/src/FreeBSD-stable-10/sys/kern/vfs_subr.c:2101 2nd 0xcd2533f0 bufwait (bufwait) @ /usr/src/FreeBSD-stable-10/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xc34e1814 ufs (ufs) @ /usr/src/FreeBSD-stable-10/sys/kern/vfs_subr.c:2101 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0540880 lr = 0xc0230328 (db_trace_self_wrapper+0x30) sp = 0xdd9483f8 fp = 0xdd948510 r10 = 0xc34e1814 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc0230328 lr = 0xc0398c90 (kdb_backtrace+0x38) sp = 0xdd948518 fp = 0xdd948520 r4 = 0xc067e3a4 r5 = 0xc05a5545 r6 = 0xc05ad9ad r7 = 0xc05c0ac2 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0398c90 lr = 0xc03b367c (witness_checkorder+0xe48) sp = 0xdd948528 fp = 0xdd948578 r4 = 0xc05940e2 witness_checkorder() at witness_checkorder+0xe48 pc = 0xc03b367c lr = 0xc0344d3c (__lockmgr_args+0x8f0) sp = 0xdd948580 fp = 0xdd9485e8 r4 = 0x00000100 r5 = 0x00080100 r6 = 0x00000835 r7 = 0xc34e1834 r8 = 0xc34e1814 r9 = 0x00080000 r10 = 0xc05ad9aa __lockmgr_args() at __lockmgr_args+0x8f0 pc = 0xc0344d3c lr = 0xc04f6e54 (ffs_lock+0x80) sp = 0xdd9485f0 fp = 0xdd948618 r4 = 0xdd948638 r5 = 0x00080100 r6 = 0xc34e17e0 r7 = 0xc34e1814 r8 = 0xc34e1834 r9 = 0x00000000 r10 = 0x00000835 ffs_lock() at ffs_lock+0x80 pc = 0xc04f6e54 lr = 0xc0565e74 (VOP_LOCK1_APV+0xd8) sp = 0xdd948620 fp = 0xdd948630 r4 = 0xdd948638 r5 = 0xc06624c0 r6 = 0x00000000 r7 = 0x00080100 r8 = 0xdd948638 r9 = 0xc05acbea VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd8 pc = 0xc0565e74 lr = 0xc0414b20 (_vn_lock+0x44) sp = 0xdd948638 fp = 0xdd948668 r4 = 0xc34e17e0 r5 = 0x00000004 r6 = 0xc05ad9aa _vn_lock() at _vn_lock+0x44 pc = 0xc0414b20 lr = 0xc04054d0 (vget+0x60) sp = 0xdd948670 fp = 0xdd948690 r4 = 0xc34e17e0 r5 = 0x00000004 r6 = 0x00080100 r7 = 0xc07dbdac r8 = 0xc2c42c80 r9 = 0xc05acbea r10 = 0x00000000 vget() at vget+0x60 pc = 0xc04054d0 lr = 0xc03f9b4c (vfs_hash_get+0xd8) sp = 0xdd948698 fp = 0xdd9486c8 r4 = 0xc07dbd90 r5 = 0x00000004 r6 = 0xc29e4ac0 r7 = 0xc07dbdac r8 = 0xc34e17e0 vfs_hash_get() at vfs_hash_get+0xd8 pc = 0xc03f9b4c lr = 0xc04f1ea4 (ffs_vgetf+0x3c) sp = 0xdd9486d0 fp = 0xdd948728 r4 = 0xc325b0c0 r5 = 0x00080000 r6 = 0xc29e4ac0 r7 = 0x00000004 r8 = 0xc325b0c0 r9 = 0x00000000 r10 = 0xdd948788 ffs_vgetf() at ffs_vgetf+0x3c pc = 0xc04f1ea4 lr = 0xc04e8d40 (softdep_sync_buf+0x9c8) sp = 0xdd948730 fp = 0xdd9487a8 r4 = 0xc325b0c0 r5 = 0xc05bcdd9 r6 = 0xc05bcdd9 r7 = 0xc29f1300 r8 = 0xc325b0c0 r9 = 0x00000000 r10 = 0x00000004 softdep_sync_buf() at softdep_sync_buf+0x9c8 pc = 0xc04e8d40 lr = 0xc04f7c6c (ffs_syncvnode+0x2ec) sp = 0xdd9487b0 fp = 0xdd948800 r4 = 0xc2ad77e0 r5 = 0x00000000 r6 = 0xc05c0abf r7 = 0x00000001 r8 = 0xcd2533f0 r9 = 0x00000010 r10 = 0xcd253398 ffs_syncvnode() at ffs_syncvnode+0x2ec pc = 0xc04f7c6c lr = 0xc04cb414 (ffs_truncate+0x6d8) sp = 0xdd948808 fp = 0xdd9489b8 r4 = 0xc2ad77e0 r5 = 0x00000000 r6 = 0x00000200 r7 = 0xc2a01c80 r8 = 0x00000880 r9 = 0x00000000 r10 = 0x00000200 ffs_truncate() at ffs_truncate+0x6d8 pc = 0xc04cb414 lr = 0xc04ff5bc (ufs_direnter+0x8a8) sp = 0xdd9489c0 fp = 0xdd948a28 r4 = 0xc2ad77e0 r5 = 0xc2a01c80 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc34e17e0 r9 = 0xc2ad77e0 r10 = 0x00000000 ufs_direnter() at ufs_direnter+0x8a8 pc = 0xc04ff5bc lr = 0xc05087f4 (ufs_makeinode+0x3ec) sp = 0xdd948a30 fp = 0xdd948b90 r4 = 0x00000000 r5 = 0xdd948d30 r6 = 0xdd948a50 r7 = 0x00000000 r8 = 0xdd948d48 r9 = 0xc2ad77e0 r10 = 0xc34df780 ufs_makeinode() at ufs_makeinode+0x3ec pc = 0xc05087f4 lr = 0xc0504bdc (ufs_create+0x24) sp = 0xdd948b98 fp = 0xdd948b98 r4 = 0xdd948c68 r5 = 0xc06629d0 r6 = 0x00000000 r7 = 0x00000a03 r8 = 0x00000000 r9 = 0xdd948d50 r10 = 0xdd948d30 ufs_create() at ufs_create+0x24 pc = 0xc0504bdc lr = 0xc0563fc4 (VOP_CREATE_APV+0xd0) sp = 0xdd948ba0 fp = 0xdd948bb0 VOP_CREATE_APV() at VOP_CREATE_APV+0xd0 pc = 0xc0563fc4 lr = 0xc04143ac (vn_open_cred+0x274) sp = 0xdd948bb8 fp = 0xdd948c98 r4 = 0xdd948ce0 r5 = 0xdd948d30 r6 = 0xc2ad77e0 vn_open_cred() at vn_open_cred+0x274 pc = 0xc04143ac lr = 0xc0414130 (vn_open+0x24) sp = 0xdd948ca0 fp = 0xdd948ca8 r4 = 0xc2c42c80 r5 = 0x000500cf r6 = 0x00000012 r7 = 0xdd948ce0 r8 = 0x00000000 r9 = 0xbfffe25c r10 = 0xdd948cd0 vn_open() at vn_open+0x24 pc = 0xc0414130 lr = 0xc040d668 (kern_openat+0x248) sp = 0xdd948cb0 fp = 0xdd948da8 kern_openat() at kern_openat+0x248 pc = 0xc040d668 lr = 0xc040d3b0 (sys_open+0x28) sp = 0xdd948db0 fp = 0xdd948db8 r4 = 0xc2c42c80 r5 = 0xc2c2c640 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xffffffe4 r9 = 0xdd948e10 r10 = 0x01650f48 sys_open() at sys_open+0x28 pc = 0xc040d3b0 lr = 0xc0552a7c (swi_handler+0x284) sp = 0xdd948dc0 fp = 0xdd948e58 swi_handler() at swi_handler+0x284 pc = 0xc0552a7c lr = 0xc05421ac (swi_entry+0x2c) sp = 0xdd948e60 fp = 0xbfffe188 r4 = 0xbfffdfa8 r5 = 0xffffffe4 r6 = 0xbfffe250 r7 = 0x00000005 r8 = 0xffffffe4 r9 = 0x00000001 swi_entry() at swi_entry+0x2c pc = 0xc05421ac lr = 0xc05421ac (swi_entry+0x2c) sp = 0xdd948e60 fp = 0xbfffe188 Unable to unwind further --047d7b3a8214da983504f7bf51d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Happened again, with a different report:

lock order reversal:
=C2=A01st 0xc2ad= 7814 ufs (ufs) @ /usr/src/FreeBSD-stable-10/sys/kern/vfs_subr.c:2101
<= div> =C2=A02nd 0xcd2533f0 bufwait (bufwait) @ /usr/src/FreeBSD-stable-10/sys/ufs= /ffs/ffs_vnops.c:262
=C2=A03rd 0xc34e1814 ufs (ufs) @ /usr/src/Fr= eeBSD-stable-10/sys/kern/vfs_subr.c:2101
KDB: stack backtrace:
db_trace_self() at db_trace_self
pc =3D 0xc0540880 =C2=A0lr =3D 0xc0230328 (db_trace_sel= f_wrapper+0x30)
sp =3D 0xdd9483f8 =C2=A0fp =3D 0xdd948510
r10 =3D 0xc34e1814<= /div>
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
<= span class=3D"" style=3D"white-space:pre"> pc =3D 0xc0230328 =C2=A0= lr =3D 0xc0398c90 (kdb_backtrace+0x38)
sp =3D 0xdd948518 = =C2=A0fp =3D 0xdd948520
r4 =3D 0xc067e3a4 =C2=A0r5 =3D 0xc05a5545
r6 =3D 0xc05ad9ad =C2=A0r7 =3D 0xc= 05c0ac2
kdb_backtrace() at kdb_backtrace+0x38
pc =3D 0xc0398c90 =C2=A0lr =3D 0xc03b367c (wi= tness_checkorder+0xe48)
sp =3D 0xdd948528 =C2=A0fp =3D 0xdd948578
r4 =3D 0xc05940e2<= /div>
witness_checkorder() at witness_checkorder+0xe48
pc =3D 0xc03b367c =C2=A0lr = =3D 0xc0344d3c (__lockmgr_args+0x8f0)
sp =3D 0xdd948580 = =C2=A0fp =3D 0xdd9485e8
r4 =3D 0x00000100 =C2=A0r5 =3D 0x00080100
r6 =3D 0x00000835 =C2=A0r7 =3D 0xc= 34e1834
r8 =3D 0xc34e1814 = =C2=A0r9 =3D 0x00080000
r10 =3D 0xc05ad9aa
__lockmgr_args() at __lockmgr_args+0= x8f0
pc =3D 0xc0344d3c =C2= =A0lr =3D 0xc04f6e54 (ffs_lock+0x80)
sp =3D 0xdd9485f0 =C2=A0fp =3D 0xdd948618
r4 =3D 0xdd948638 =C2= =A0r5 =3D 0x00080100
r6 =3D 0xc34e17e0 = =C2=A0r7 =3D 0xc34e1814
r8 =3D 0xc34e1834 =C2=A0r9 =3D 0x00000000
r10 =3D 0x00000835
ffs_lock() at ffs_lock+0x80
pc =3D 0xc04f6e54 =C2=A0lr =3D 0xc0565e74 (VOP_LOCK1_AP= V+0xd8)
sp = =3D 0xdd948620 =C2=A0fp =3D 0xdd948630
r4 =3D 0xdd948638 = =C2=A0r5 =3D 0xc06624c0
r6 =3D 0x00000000 =C2=A0r7 =3D 0x00080100
r8 =3D 0xdd948638 =C2=A0r9 =3D 0xc= 05acbea
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd8
pc =3D 0xc0565e74 =C2=A0lr =3D 0xc0414b20 (_v= n_lock+0x44)
= sp =3D 0xdd948638 =C2=A0fp =3D 0xdd948668
r4 =3D 0xc34e17e0 = =C2=A0r5 =3D 0x00000004
r6 =3D 0xc05ad9aa
_vn_lock() at _vn_lock+0x44
pc =3D 0xc0414b20 =C2= =A0lr =3D 0xc04054d0 (vget+0x60)
sp =3D 0xdd948670 = =C2=A0fp =3D 0xdd948690
r4 =3D 0xc34e17e0 =C2=A0r5 =3D 0x00000004
r6 =3D 0x00080100 =C2=A0r7 =3D 0xc= 07dbdac
r8 =3D 0xc2c42c80 = =C2=A0r9 =3D 0xc05acbea
r10 =3D 0x00000000
vget() at vget+0x60
pc =3D 0xc04054d0 =C2=A0lr = =3D 0xc03f9b4c (vfs_hash_get+0xd8)
sp =3D 0xdd948698 = =C2=A0fp =3D 0xdd9486c8
r4 =3D 0xc07dbd90 =C2=A0r5 =3D 0x00000004
r6 =3D 0xc29e4ac0 =C2=A0r7 =3D 0xc= 07dbdac
r8 =3D 0xc34e17e0<= /div>
vfs_hash_get() at vfs_hash_get+0xd8
pc =3D 0xc03f9b4c =C2=A0lr =3D 0xc04f1ea4 = (ffs_vgetf+0x3c)
sp =3D 0xdd9486d0 = =C2=A0fp =3D 0xdd948728
r4 =3D 0xc325b0c0 =C2=A0r5 =3D 0x00080000
r6 =3D 0xc29e4ac0 =C2=A0r7 =3D 0x0= 0000004
r8 =3D 0xc325b0c0 = =C2=A0r9 =3D 0x00000000
r10 =3D 0xdd948788
ffs_vgetf() at ffs_vgetf+0x3c
<= div> pc =3D 0xc04f1ea4 = =C2=A0lr =3D 0xc04e8d40 (softdep_sync_buf+0x9c8)
sp =3D 0xdd948730 = =C2=A0fp =3D 0xdd9487a8
r4 =3D 0xc325b0c0 =C2=A0r5 =3D 0xc05bcdd9
r6 =3D 0xc05bcdd9 =C2=A0r7 =3D 0xc= 29f1300
r8 =3D 0xc325b0c0 = =C2=A0r9 =3D 0x00000000
r10 =3D 0x00000004
softdep_sync_buf() at softdep_sync_b= uf+0x9c8
pc =3D 0xc04e8d40 =C2= =A0lr =3D 0xc04f7c6c (ffs_syncvnode+0x2ec)
sp =3D 0xdd9487b0 =C2=A0fp =3D 0xdd948800
r4 =3D 0xc2ad77e= 0 =C2=A0r5 =3D 0x00000000
r6 =3D 0xc05c0abf = =C2=A0r7 =3D 0x00000001
r8 =3D 0xcd2533f0 =C2=A0r9 =3D 0x00000010
r10 =3D 0xcd253398
ffs_syncvnode() at ffs_syncvnode+0x2ec
pc =3D 0xc04f7c6c =C2=A0lr =3D 0xc04cb414 (f= fs_truncate+0x6d8)
sp =3D 0xdd948808 =C2=A0fp =3D 0xdd9489b8
r4 =3D 0xc2ad77e0 = =C2=A0r5 =3D 0x00000000
r6 =3D 0x00000200 =C2=A0r7 =3D 0xc2a01c80
r8 =3D 0x00000880 =C2=A0r9 =3D 0x0= 0000000
r10 =3D 0x00000200<= /div>
ffs_truncate() at ffs_truncate+0x6d8
pc =3D 0xc04cb414 =C2=A0lr =3D 0xc04ff5bc= (ufs_direnter+0x8a8)
sp =3D 0xdd9489c0 = =C2=A0fp =3D 0xdd948a28
r4 =3D 0xc2ad77e0 =C2=A0r5 =3D 0xc2a01c80
r6 =3D 0x00000000 =C2=A0r7 =3D 0x0= 0000000
r8 =3D 0xc34e17e0 = =C2=A0r9 =3D 0xc2ad77e0
r10 =3D 0x00000000
ufs_direnter() at ufs_direnter+0x8a8=
pc =3D 0xc04= ff5bc =C2=A0lr =3D 0xc05087f4 (ufs_makeinode+0x3ec)
sp =3D 0xdd948a30 = =C2=A0fp =3D 0xdd948b90
r4 =3D 0x00000000 =C2=A0r5 =3D 0xdd948d30
r6 =3D 0xdd948a50 =C2=A0r7 =3D 0x0= 0000000
r8 =3D 0xdd948d48 = =C2=A0r9 =3D 0xc2ad77e0
r10 =3D 0xc34df780
ufs_makeinode() at ufs_makeinode+0x3= ec
pc =3D 0xc= 05087f4 =C2=A0lr =3D 0xc0504bdc (ufs_create+0x24)
sp =3D 0xdd948b98 = =C2=A0fp =3D 0xdd948b98
r4 =3D 0xdd948c68 =C2=A0r5 =3D 0xc06629d0
r6 =3D 0x00000000 =C2=A0r7 =3D 0x0= 0000a03
r8 =3D 0x00000000 = =C2=A0r9 =3D 0xdd948d50
r10 =3D 0xdd948d30
ufs_create() at ufs_create+0x24
pc =3D 0xc0504bdc= =C2=A0lr =3D 0xc0563fc4 (VOP_CREATE_APV+0xd0)
sp =3D 0xdd948ba0 = =C2=A0fp =3D 0xdd948bb0
VOP_CREATE_APV() at VOP_CREATE_APV+0xd0
pc =3D 0xc0563= fc4 =C2=A0lr =3D 0xc04143ac (vn_open_cred+0x274)
sp =3D 0xdd948bb8 = =C2=A0fp =3D 0xdd948c98
r4 =3D 0xdd948ce0 =C2=A0r5 =3D 0xdd948d30
r6 =3D 0xc2ad77e0
vn_open_cred() at vn_open_cred+0x274
pc =3D 0xc04143ac =C2=A0lr =3D 0xc0414130 (vn= _open+0x24)
s= p =3D 0xdd948ca0 =C2=A0fp =3D 0xdd948ca8
r4 =3D 0xc2c42c80 = =C2=A0r5 =3D 0x000500cf
r6 =3D 0x00000012 =C2=A0r7 =3D 0xdd948ce0
r8 =3D 0x00000000 =C2=A0r9 =3D 0xb= fffe25c
r10 =3D 0xdd948cd0<= /div>
vn_open() at vn_open+0x24
pc =3D 0xc0414130 =C2=A0lr =3D 0xc040d668 (kern_open= at+0x248)
sp =3D 0xdd948cb0 = =C2=A0fp =3D 0xdd948da8
kern_openat() at kern_openat+0x248
<= div> pc =3D 0xc040d668 = =C2=A0lr =3D 0xc040d3b0 (sys_open+0x28)
sp =3D 0xdd948db0 = =C2=A0fp =3D 0xdd948db8
r4 =3D 0xc2c42c80 =C2=A0r5 =3D 0xc2c2c640
r6 =3D 0x00000000 =C2=A0r7 =3D 0x0= 0000000
r8 =3D 0xffffffe4 = =C2=A0r9 =3D 0xdd948e10
r10 =3D 0x01650f48
sys_open() at sys_open+0x28
pc =3D 0xc040d3b0 =C2= =A0lr =3D 0xc0552a7c (swi_handler+0x284)
sp =3D 0xdd948dc0 = =C2=A0fp =3D 0xdd948e58
swi_handler() at swi_handler+0x284
<= div> pc =3D 0xc0552a7c = =C2=A0lr =3D 0xc05421ac (swi_entry+0x2c)
sp =3D 0xdd948e60 = =C2=A0fp =3D 0xbfffe188
r4 =3D 0xbfffdfa8 =C2=A0r5 =3D 0xffffffe4
r6 =3D 0xbfffe250 =C2=A0r7 =3D 0x0= 0000005
r8 =3D 0xffffffe4 = =C2=A0r9 =3D 0x00000001
swi_entry() at swi_entry+0x2c
<= span class=3D"" style=3D"white-space:pre"> pc =3D 0xc05421ac =C2=A0= lr =3D 0xc05421ac (swi_entry+0x2c)
sp =3D 0xdd948e60 = =C2=A0fp =3D 0xbfffe188
Unable to unwind further

--047d7b3a8214da983504f7bf51d6-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 06:30:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B2B23BD for ; Thu, 24 Apr 2014 06:30:29 +0000 (UTC) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A6521C0C for ; Thu, 24 Apr 2014 06:30:29 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward5l.mail.yandex.net (Yandex) with ESMTP id 16FE4C40CEA for ; Thu, 24 Apr 2014 10:30:25 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id C65E0E4014A for ; Thu, 24 Apr 2014 10:30:24 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id ytELHtMTX3-UOd4nPXP; Thu, 24 Apr 2014 10:30:24 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: ae53ebb9-effb-4b53-b78b-6e1fc3310d5c Message-ID: <5358AF80.4010403@passap.ru> Date: Thu, 24 Apr 2014 10:30:24 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: buildkernel: #error "On SMP systems we should have proper atomic operations." X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:30:29 -0000 Hi All, I try to compile a kernel at WANDBOARD-QUAD and get the error: ----- ===> fuse (depend) [...] CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/arm.arm/usr/src/sys/IMX6 -std=iso9899:1999 /usr/src/sys/mod ules/fuse/../../fs/fuse/fuse_node.c /usr/src/sys/modules/fuse/../../fs/fuse/fuse_io.c /usr/src/sys/modules/fuse/../../fs/fuse/fuse_device.c /usr/src/sys/modules/fuse/../../fs/fuse/fuse_ipc.c /usr/src/sys/modules/fuse/../../fs/fuse/fuse_file.c /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vfsops.c /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vnops.c /usr/src/sys/modules/fuse/../. ./fs/fuse/fuse_internal.c /usr/src/sys/modules/fuse/../../fs/fuse/fuse_main.c --- .depend --- /usr/src/sys/arm/arm/stdatomic.c:120:2: error: "On SMP systems we should have proper atomic operations." #error "On SMP systems we should have proper atomic operations." ^ 1 error generated. ----- The system: ----- % uname -a FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r264681: Sun Apr 20 02:39:12 SAMT 2014 root@bb052.bsnet:/home/bsam/crochet-freebsd-master/work/obj/arm.armv6/usr/src/sys/IMX6 arm % svnlite info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 264824 Node Kind: directory Schedule: normal Last Changed Author: ed Last Changed Rev: 264823 Last Changed Date: 2014-04-23 18:05:28 +0400 (ср, 23 апр 2014) ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 07:01:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53B36844 for ; Thu, 24 Apr 2014 07:01:03 +0000 (UTC) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15F13103F for ; Thu, 24 Apr 2014 07:01:03 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id il7so2483797vcb.32 for ; Thu, 24 Apr 2014 00:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=f80HBSzy//1lOQ8yCFRbBZ+th0L0cWURP+fA3KIhnA0=; b=EcAMLM/eTjRYzThnZRkTwKilkzGwTZ/BF/UjdXXpJ3NYttwrkaiKxQD3HNSHFeFmJa CgokV78BKtDHUN5Mh1Ct6Vua/gjlcEm0Nsv6fs/bocmGM5OC51bx2J4XYB/hgENJpLyT qFJNDsGtASvV6MUMy2RckY56VQi9q4vDnH9Bgf/nKMhcvS5a0JSjyOnd/t2EP3/fnmus vPTnpdeZoLtQQ3u4BE5y9qBcjkjdbpugJrSxMiwQ/acnVDjRpdC5JGxL/xqdl6mTcZ7N /L35T+bIpP7P1pXsGkjSYqldHBGqpZbluXuoSubl/y0foFlc93bNVodDqu1jQvCiEX6Y xfCw== X-Received: by 10.58.28.204 with SMTP id d12mr84096veh.81.1398322862177; Thu, 24 Apr 2014 00:01:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.236.100 with HTTP; Thu, 24 Apr 2014 00:00:32 -0700 (PDT) From: Matthias Gamsjager Date: Thu, 24 Apr 2014 09:00:32 +0200 Message-ID: Subject: Re: CubieTruck Cubieboard3 support To: coba , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 07:01:03 -0000 Ok thx for your help. But by the looks of it the board isn't really supported yet. Maybe someone at the list can shine some light on the matter. On Wed, Apr 23, 2014 at 10:25 PM, coba wrote: > Good evening, > > I booted it, check log: > U-Boot SPL 2014.01-rc1-09161-g108ec3f (Jan 20 2014 - 05:50:52) > Board: Cubietruck > DRAM: 2048 MiB > CPU: 960000000Hz, AXI/AHB/APB: 3/2/2 > spl: not an uImage at 1600 > > > U-Boot 2014.01-rc1-09161-g108ec3f (Jan 20 2014 - 05:50:52) Allwinner > Technology > > CPU: Allwinner A20 (SUN7I) > Board: Cubietruck > I2C: ready > DRAM: 2 GiB > WARNING: Caches not enabled > MMC: SUNXI SD/MMC: 0 > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > Net: mii0 > Warning: failed to set MAC address > > Hit any key to stop autoboot: 0 > ** Unrecognized filesystem type ** > 158 bytes read in 8 ms (18.6 KiB/s) > Loaded environment from uEnv.txt > ** Unrecognized filesystem type ** > ** File not found boot/boot.scr ** > ** File not found boot.scr ** > 50072 bytes read in 11 ms (4.3 MiB/s) > 5912048 bytes read in 365 ms (15.4 MiB/s) > ## Booting kernel from Legacy Image at 48000000 ... > Image Name: Linux-3.4.75-sun7i > Created: 2014-02-09 18:49:43 UTC > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 5911984 Bytes =3D 5.6 MiB > Load Address: 40008000 > Entry Point: 40008000 > Verifying Checksum ... =D0=A7 > U-Boot SPL 2013.07-07794-gc0f3b94 (Aug 15 2013 - 18:01:45) > Board: Cubieboard2 > DRAM: 1024 MiB > CPU: 960000000Hz, AXI/AHB/APB: 3/2/2 > SUNXI SD/MMC: 0 > > > U-Boot 2013.07-07794-gc0f3b94 (Aug 15 2013 - 18:01:45) Allwinner Technolo= gy > > CPU: Allwinner A20 (SUN7I) > Board: Cubieboard2 > I2C: ready > DRAM: 1 GiB > MMC: SUNXI SD/MMC: 0 > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > Net: emac > Hit any key to stop autoboot: 0 > sun7i#fatload mmc 0 0x40200000 kernel; go 0x40200100 > reading kernel > 4992443 bytes read in 305 ms (15.6 MiB/s) > ## Starting application at 0x40200100 ... > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2014 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 11.0-CURRENT #0 r264301M: Thu Apr 17 11:40:33 CEST 2014 > matty@freebsd:/usr/obj/arm.armv6/storage/usr/src/11/sys/CUBIEBOARD2 a= rm > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Cortex A7 rev 4 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:2 LoUIS:2 > Cache level 1: > 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc > 32KB/32B 2-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > real memory =3D 1073741824 (1024 MB) > avail memory =3D 1040412672 (992 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > random device not loaded; using insecure entropy > random: initialized > ofwbus0: > simplebus0: on ofwbus0 > gic0: mem > 0x1c81000-0x1c81fff,0x1c82000-0x1c820ff on simplebus0 > gic0: pn 0x10, arch 0x2, rev 0x1, implementer 0x43b sc->nirqs 160 > a10_sramc0: mem 0x1c00000-0x1c00fff on simplebus= 0 > a20_cpu_cfg0: mem 0x1c25c00-0x1c25fff on > simplebus0 > a10_ccm0: mem 0x1c20000-0x1c203ff on > simplebus0 > a10_timer0: mem 0x1c20c00-0x1c20c8f irq 54 on > simplebus0 > Event timer "a10_timer Eventtimer" frequency 24000000 Hz quality 1000 > Timecounter "a10_timer timer0" frequency 24000000 Hz quality 1000 > a10wd0: mem 0x1c20c90-0x1c20c9f on simplebus0 > gpio0: mem 0x1c20800-0x1c20bff irq 60 on > simplebus0 > gpioc0: on gpio0 > gpiobus0: on gpio0 > ehci0: mem 0x1c14000-0x1c14fff = irq > 71 on simplebus0 > usbus0: EHCI version 1.0 > usbus0 on ehci0 > ehci1: mem 0x1c1c000-0x1c1cfff = irq > 72 on simplebus0 > usbus1: EHCI version 1.0 > usbus1 on ehci1 > uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebus0 > uart0: console (115200,n,8,1) > emac0: mem 0x1c0b000-0x1c0bfff irq 87 = on > simplebus0 > miibus0: on emac0 > rgephy0: PHY 0 on miibus= 0 > > vm_fault(0xc08a96a0, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc08cd9f8 > FSR=3D00000005, FAR=3D00000000, spsr=3Da00001d3 > r0 =3D00000000, r1 =3Dc053c2f3, r2 =3D00000072, r3 =3D00000008 > r4 =3Dc3b35e80, r5 =3Dc3b36000, r6 =3Dc3b36038, r7 =3D00000000 > r8 =3Dc055ecfa, r9 =3Dc3ad1700, r10=3Dc05c7240, r11=3Dc08cda60 > r12=3D00000000, ssp=3Dc08cda48, slr=3Dc024c8a4, pc =3Dc03d3238 > > [ thread pid 0 tid 100000 ] > Stopped at strcmp+0x4: ldrb r3, [r0] > db> bt > Tracing pid 0 tid 100000 td 0xc08a9390 > db_trace_self() at db_trace_self > pc =3D 0xc04e0eb4 lr =3D 0xc0231298 (db_hex2dec+0x4d8) > sp =3D 0xc08cd700 fp =3D 0xc08cd718 > r10 =3D 0xc08a8cb0 > db_hex2dec() at db_hex2dec+0x4d8 > pc =3D 0xc0231298 lr =3D 0xc0230c08 (db_command_loop+0x2fc) > sp =3D 0xc08cd720 fp =3D 0xc08cd7c0 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0x00000000 > db_command_loop() at db_command_loop+0x2fc > pc =3D 0xc0230c08 lr =3D 0xc023096c (db_command_loop+0x60) > sp =3D 0xc08cd7c8 fp =3D 0xc08cd7d8 > r4 =3D 0xc051d125 r5 =3D 0xc0535407 > r6 =3D 0xc08a8c9c r7 =3D 0xc08cd9f8 > r8 =3D 0x00000001 r9 =3D 0xc05c5280 > r10 =3D 0xc0605624 > db_command_loop() at db_command_loop+0x60 > pc =3D 0xc023096c lr =3D 0xc0233334 (X_db_symbol_values+0x250) > sp =3D 0xc08cd7e0 fp =3D 0xc08cd900 > r4 =3D 0x00000000 r5 =3D 0xc08a8ca8 > r6 =3D 0xc0605650 > X_db_symbol_values() at X_db_symbol_values+0x250 > pc =3D 0xc0233334 lr =3D 0xc034f7c8 (kdb_trap+0x168) > sp =3D 0xc08cd908 fp =3D 0xc08cd928 > r4 =3D 0x00000000 r5 =3D 0x00000005 > r6 =3D 0xc0605650 r7 =3D 0xc08cd9f8 > kdb_trap() at kdb_trap+0x168 > pc =3D 0xc034f7c8 lr =3D 0xc04f670c (data_abort_handler+0x680) > sp =3D 0xc08cd930 fp =3D 0xc08cd948 > r4 =3D 0xc08cd9f8 r5 =3D 0x00000005 > r6 =3D 0x600001d3 r7 =3D 0x00000000 > r8 =3D 0x00000013 r9 =3D 0xc08cd9f8 > r10 =3D 0x00000001 > data_abort_handler() at data_abort_handler+0x680 > pc =3D 0xc04f670c lr =3D 0xc04f64b4 (data_abort_handler+0x428) > sp =3D 0xc08cd950 fp =3D 0xc08cd9f0 > r4 =3D 0xc08cdeb0 r5 =3D 0xc08a9390 > r6 =3D 0xc08a9068 r7 =3D 0x00000005 > data_abort_handler() at data_abort_handler+0x428 > pc =3D 0xc04f64b4 lr =3D 0xc04e2a40 (exception_exit) > sp =3D 0xc08cd9f8 fp =3D 0xc08cda60 > r4 =3D 0xc3b35e80 r5 =3D 0xc3b36000 > r6 =3D 0xc3b36038 r7 =3D 0x00000000 > r8 =3D 0xc055ecfa r9 =3D 0xc3ad1700 > r10 =3D 0xc05c7240 > exception_exit() at exception_exit > pc =3D 0xc04e2a40 lr =3D 0xc024c8a4 (mii_phy_flowstatus+0x2080) > sp =3D 0xc08cda48 fp =3D 0xc08cda60 > r0 =3D 0x00000000 r1 =3D 0xc053c2f3 > r2 =3D 0x00000072 r3 =3D 0x00000008 > r4 =3D 0xc3b35e80 r5 =3D 0xc3b36000 > r6 =3D 0xc3b36038 r7 =3D 0x00000000 > r8 =3D 0xc055ecfa r9 =3D 0xc3ad1700 > r10 =3D 0xc05c7240 r12 =3D 0x00000000 > strcmp() at strcmp+0x4 > pc =3D 0xc03d3238 lr =3D 0xc024c8a4 (mii_phy_flowstatus+0x2080) > sp =3D 0xc08cda48 fp =3D 0xc08cda60 > Unwind failure (no registers changed) > > From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 07:11:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B1B0A8E for ; Thu, 24 Apr 2014 07:11:32 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56717113A for ; Thu, 24 Apr 2014 07:11:32 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id lf12so211442vcb.13 for ; Thu, 24 Apr 2014 00:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cmywaiaR8MA5tYEGBjRIwWlyCBLz81CgV0THxvOUF90=; b=k47o9ZK7duiXfOfYRvy3hyIjhNJD3t+HmO10eu3sCxhJDJNa7839J4Hm7SyApMMIpJ 4kBOEHD4NcsQ/zcG7mFXX1bTm8wFdIR1vq7O26HQ//4xT1qmSsCHzM9s4xIvOHlEIcOz XGv2kVedKuGF1YpbpLdWrJ9paXgXlRS7QjYLlrhP0cl3IFn7Zjq+IFrW1Uh38ToNtAMp RydhiQwEeaO94UyClKYbdcBiHWqWBXCItofzwslMZU6LlhGyl6PLcwyg/y+pJHY20loK YDoinjrJM21+9ZL8jLhVPNZnjU8WSriV0YMhzwinhyMNE/5v+MbkBI613JxGTaZrqrZi +i2Q== MIME-Version: 1.0 X-Received: by 10.220.92.193 with SMTP id s1mr80951vcm.34.1398323491347; Thu, 24 Apr 2014 00:11:31 -0700 (PDT) Received: by 10.52.187.1 with HTTP; Thu, 24 Apr 2014 00:11:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 15:11:31 +0800 Message-ID: Subject: Re: CubieTruck Cubieboard3 support From: Ganbold Tsagaankhuu To: Matthias Gamsjager Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: coba , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 07:11:32 -0000 On Thu, Apr 24, 2014 at 3:00 PM, Matthias Gamsjager w= rote: > Ok thx for your help. But by the looks of it the board isn't really > supported yet. Maybe someone at the list can shine some light on the > matter. > If you are referring to boot log that coba provided then iirc Alexander Fedorov's mmc driver was compiled into it. Maybe you should try without mmc driver. Ganbold > > > > On Wed, Apr 23, 2014 at 10:25 PM, coba wrote: > > Good evening, > > > > I booted it, check log: > > U-Boot SPL 2014.01-rc1-09161-g108ec3f (Jan 20 2014 - 05:50:52) > > Board: Cubietruck > > DRAM: 2048 MiB > > CPU: 960000000Hz, AXI/AHB/APB: 3/2/2 > > spl: not an uImage at 1600 > > > > > > U-Boot 2014.01-rc1-09161-g108ec3f (Jan 20 2014 - 05:50:52) Allwinner > > Technology > > > > CPU: Allwinner A20 (SUN7I) > > Board: Cubietruck > > I2C: ready > > DRAM: 2 GiB > > WARNING: Caches not enabled > > MMC: SUNXI SD/MMC: 0 > > *** Warning - bad CRC, using default environment > > > > In: serial > > Out: serial > > Err: serial > > Net: mii0 > > Warning: failed to set MAC address > > > > Hit any key to stop autoboot: 0 > > ** Unrecognized filesystem type ** > > 158 bytes read in 8 ms (18.6 KiB/s) > > Loaded environment from uEnv.txt > > ** Unrecognized filesystem type ** > > ** File not found boot/boot.scr ** > > ** File not found boot.scr ** > > 50072 bytes read in 11 ms (4.3 MiB/s) > > 5912048 bytes read in 365 ms (15.4 MiB/s) > > ## Booting kernel from Legacy Image at 48000000 ... > > Image Name: Linux-3.4.75-sun7i > > Created: 2014-02-09 18:49:43 UTC > > Image Type: ARM Linux Kernel Image (uncompressed) > > Data Size: 5911984 Bytes =3D 5.6 MiB > > Load Address: 40008000 > > Entry Point: 40008000 > > Verifying Checksum ... =D0=A7 > > U-Boot SPL 2013.07-07794-gc0f3b94 (Aug 15 2013 - 18:01:45) > > Board: Cubieboard2 > > DRAM: 1024 MiB > > CPU: 960000000Hz, AXI/AHB/APB: 3/2/2 > > SUNXI SD/MMC: 0 > > > > > > U-Boot 2013.07-07794-gc0f3b94 (Aug 15 2013 - 18:01:45) Allwinner > Technology > > > > CPU: Allwinner A20 (SUN7I) > > Board: Cubieboard2 > > I2C: ready > > DRAM: 1 GiB > > MMC: SUNXI SD/MMC: 0 > > *** Warning - bad CRC, using default environment > > > > In: serial > > Out: serial > > Err: serial > > Net: emac > > Hit any key to stop autoboot: 0 > > sun7i#fatload mmc 0 0x40200000 kernel; go 0x40200100 > > reading kernel > > 4992443 bytes read in 305 ms (15.6 MiB/s) > > ## Starting application at 0x40200100 ... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2014 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 > > The Regents of the University of California. All rights reserve= d. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 11.0-CURRENT #0 r264301M: Thu Apr 17 11:40:33 CEST 2014 > > matty@freebsd:/usr/obj/arm.armv6/storage/usr/src/11/sys/CUBIEBOARD2 > arm > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > > WARNING: WITNESS option enabled, expect reduced performance. > > CPU: Cortex A7 rev 4 (Cortex-A core) > > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > > WB disabled EABT branch prediction enabled > > LoUU:2 LoC:2 LoUIS:2 > > Cache level 1: > > 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc > > 32KB/32B 2-way instruction cache Read-Alloc > > Cache level 2: > > 256KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > > real memory =3D 1073741824 (1024 MB) > > avail memory =3D 1040412672 (992 MB) > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > random device not loaded; using insecure entropy > > random: initialized > > ofwbus0: > > simplebus0: on ofwbus0 > > gic0: mem > > 0x1c81000-0x1c81fff,0x1c82000-0x1c820ff on simplebus0 > > gic0: pn 0x10, arch 0x2, rev 0x1, implementer 0x43b sc->nirqs 160 > > a10_sramc0: mem 0x1c00000-0x1c00fff on > simplebus0 > > a20_cpu_cfg0: mem 0x1c25c00-0x1c25fff on > > simplebus0 > > a10_ccm0: mem 0x1c20000-0x1c203ff on > > simplebus0 > > a10_timer0: mem 0x1c20c00-0x1c20c8f irq 54 on > > simplebus0 > > Event timer "a10_timer Eventtimer" frequency 24000000 Hz quality 1000 > > Timecounter "a10_timer timer0" frequency 24000000 Hz quality 1000 > > a10wd0: mem 0x1c20c90-0x1c20c9f on simplebus0 > > gpio0: mem 0x1c20800-0x1c20bff irq 60 on > > simplebus0 > > gpioc0: on gpio0 > > gpiobus0: on gpio0 > > ehci0: mem 0x1c14000-0x1c14ff= f > irq > > 71 on simplebus0 > > usbus0: EHCI version 1.0 > > usbus0 on ehci0 > > ehci1: mem 0x1c1c000-0x1c1cff= f > irq > > 72 on simplebus0 > > usbus1: EHCI version 1.0 > > usbus1 on ehci1 > > uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebu= s0 > > uart0: console (115200,n,8,1) > > emac0: mem 0x1c0b000-0x1c0bfff irq 8= 7 > on > > simplebus0 > > miibus0: on emac0 > > rgephy0: PHY 0 on > miibus0 > > > > vm_fault(0xc08a96a0, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc08cd9f8 > > FSR=3D00000005, FAR=3D00000000, spsr=3Da00001d3 > > r0 =3D00000000, r1 =3Dc053c2f3, r2 =3D00000072, r3 =3D00000008 > > r4 =3Dc3b35e80, r5 =3Dc3b36000, r6 =3Dc3b36038, r7 =3D00000000 > > r8 =3Dc055ecfa, r9 =3Dc3ad1700, r10=3Dc05c7240, r11=3Dc08cda60 > > r12=3D00000000, ssp=3Dc08cda48, slr=3Dc024c8a4, pc =3Dc03d3238 > > > > [ thread pid 0 tid 100000 ] > > Stopped at strcmp+0x4: ldrb r3, [r0] > > db> bt > > Tracing pid 0 tid 100000 td 0xc08a9390 > > db_trace_self() at db_trace_self > > pc =3D 0xc04e0eb4 lr =3D 0xc0231298 (db_hex2dec+0x4d8) > > sp =3D 0xc08cd700 fp =3D 0xc08cd718 > > r10 =3D 0xc08a8cb0 > > db_hex2dec() at db_hex2dec+0x4d8 > > pc =3D 0xc0231298 lr =3D 0xc0230c08 (db_command_loop+0x2fc) > > sp =3D 0xc08cd720 fp =3D 0xc08cd7c0 > > r4 =3D 0x00000000 r5 =3D 0x00000000 > > r6 =3D 0x00000000 > > db_command_loop() at db_command_loop+0x2fc > > pc =3D 0xc0230c08 lr =3D 0xc023096c (db_command_loop+0x60) > > sp =3D 0xc08cd7c8 fp =3D 0xc08cd7d8 > > r4 =3D 0xc051d125 r5 =3D 0xc0535407 > > r6 =3D 0xc08a8c9c r7 =3D 0xc08cd9f8 > > r8 =3D 0x00000001 r9 =3D 0xc05c5280 > > r10 =3D 0xc0605624 > > db_command_loop() at db_command_loop+0x60 > > pc =3D 0xc023096c lr =3D 0xc0233334 (X_db_symbol_values+0x250= ) > > sp =3D 0xc08cd7e0 fp =3D 0xc08cd900 > > r4 =3D 0x00000000 r5 =3D 0xc08a8ca8 > > r6 =3D 0xc0605650 > > X_db_symbol_values() at X_db_symbol_values+0x250 > > pc =3D 0xc0233334 lr =3D 0xc034f7c8 (kdb_trap+0x168) > > sp =3D 0xc08cd908 fp =3D 0xc08cd928 > > r4 =3D 0x00000000 r5 =3D 0x00000005 > > r6 =3D 0xc0605650 r7 =3D 0xc08cd9f8 > > kdb_trap() at kdb_trap+0x168 > > pc =3D 0xc034f7c8 lr =3D 0xc04f670c (data_abort_handler+0x680= ) > > sp =3D 0xc08cd930 fp =3D 0xc08cd948 > > r4 =3D 0xc08cd9f8 r5 =3D 0x00000005 > > r6 =3D 0x600001d3 r7 =3D 0x00000000 > > r8 =3D 0x00000013 r9 =3D 0xc08cd9f8 > > r10 =3D 0x00000001 > > data_abort_handler() at data_abort_handler+0x680 > > pc =3D 0xc04f670c lr =3D 0xc04f64b4 (data_abort_handler+0x428= ) > > sp =3D 0xc08cd950 fp =3D 0xc08cd9f0 > > r4 =3D 0xc08cdeb0 r5 =3D 0xc08a9390 > > r6 =3D 0xc08a9068 r7 =3D 0x00000005 > > data_abort_handler() at data_abort_handler+0x428 > > pc =3D 0xc04f64b4 lr =3D 0xc04e2a40 (exception_exit) > > sp =3D 0xc08cd9f8 fp =3D 0xc08cda60 > > r4 =3D 0xc3b35e80 r5 =3D 0xc3b36000 > > r6 =3D 0xc3b36038 r7 =3D 0x00000000 > > r8 =3D 0xc055ecfa r9 =3D 0xc3ad1700 > > r10 =3D 0xc05c7240 > > exception_exit() at exception_exit > > pc =3D 0xc04e2a40 lr =3D 0xc024c8a4 (mii_phy_flowstatus+0x208= 0) > > sp =3D 0xc08cda48 fp =3D 0xc08cda60 > > r0 =3D 0x00000000 r1 =3D 0xc053c2f3 > > r2 =3D 0x00000072 r3 =3D 0x00000008 > > r4 =3D 0xc3b35e80 r5 =3D 0xc3b36000 > > r6 =3D 0xc3b36038 r7 =3D 0x00000000 > > r8 =3D 0xc055ecfa r9 =3D 0xc3ad1700 > > r10 =3D 0xc05c7240 r12 =3D 0x00000000 > > strcmp() at strcmp+0x4 > > pc =3D 0xc03d3238 lr =3D 0xc024c8a4 (mii_phy_flowstatus+0x208= 0) > > sp =3D 0xc08cda48 fp =3D 0xc08cda60 > > Unwind failure (no registers changed) > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 07:22:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2945CB7 for ; Thu, 24 Apr 2014 07:22:55 +0000 (UTC) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A23151232 for ; Thu, 24 Apr 2014 07:22:55 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id db11so2399454veb.21 for ; Thu, 24 Apr 2014 00:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=w18LO1wnhxbaCTWSYbCbB7baJylAnUlqjUzzOj2lrhE=; b=wfJU7GXREmXIJnx8zyf2gSw618xjCSxWCcOzGfY05RD+4DKvdmgliZb1052SlwO5TR ahD1NQ7akke03Hi6UkcWn3fOFBfP929FKT01Dpl/deTBsLXAWdlNslp83jeZn2ngX9U5 Q/p6X1YN4BKlkwKkCRhAE3mDlXNiPXGzyUcR0s6YHqq2zI+nVzXTPl6SjuunX3uBzRhS sVrugJIVEpsattFxkdkGEBflzgCjfPpw0yHU1ppI7MigX75n7pJanlnJCjWyNQBBw0le NENujcaEHdZnYBtvwAIs7oNnaQXxl6Lopru6zq6sl/p+9hAKWBm5Or+yf+pBFruYh3qV +YsA== X-Received: by 10.58.243.4 with SMTP id wu4mr36531vec.67.1398324174762; Thu, 24 Apr 2014 00:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.236.100 with HTTP; Thu, 24 Apr 2014 00:22:24 -0700 (PDT) In-Reply-To: References: From: Matthias Gamsjager Date: Thu, 24 Apr 2014 09:22:24 +0200 Message-ID: Subject: Re: CubieTruck Cubieboard3 support Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 07:22:55 -0000 > If you are referring to boot log that coba provided then iirc Alexander > Fedorov's mmc driver was compiled into it. > > Maybe you should try without mmc driver. The MMC section in the kernel config is commented. From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 07:37:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3966EEE for ; Thu, 24 Apr 2014 07:37:35 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FC2C133D for ; Thu, 24 Apr 2014 07:37:35 +0000 (UTC) Received: by mail-ig0-f170.google.com with SMTP id uq10so739280igb.5 for ; Thu, 24 Apr 2014 00:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZJInMnfkBTdnDOZordvh4wqCVoazTMOAw1/Esh2CIdw=; b=mWmCdWVphTGjowLtxvscfJYozzRKj9MN3vJwsp+lnFJfsa1M7SuoUrbqUXV0HS60nE e0wR26JsAqGoHU7Ga+L9MWpwP/PXUKIUBK1BJ2cTL06eKjxpX/ruqTiO7CvY16x3ntSt I6eDcV8k6XB4Cp9/AEy/NkTVQM/gfEi8/aakJTWNZ5yIAoO/a3kKpbZPK0SY67Iyq9OM +CBeL1uyYMTaQLgJXowfbflHTktSLGovqcYYExPfz8uhMtEbYAQqAQaVAWH6gwm9VSLc o9IYKZFUI12tS8B9EYSJZEPJjxNFEtRg1Wcc1LUEDpjyW9tJCWjyVjCka/SwWZfLStHa aBqA== MIME-Version: 1.0 X-Received: by 10.42.232.206 with SMTP id jv14mr247409icb.52.1398325055048; Thu, 24 Apr 2014 00:37:35 -0700 (PDT) Received: by 10.64.64.5 with HTTP; Thu, 24 Apr 2014 00:37:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 15:37:34 +0800 Message-ID: Subject: Re: CubieTruck Cubieboard3 support From: Ganbold Tsagaankhuu To: Matthias Gamsjager Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 07:37:35 -0000 On Thu, Apr 24, 2014 at 3:22 PM, Matthias Gamsjager wrote: > > If you are referring to boot log that coba provided then iirc Alexander > > Fedorov's mmc driver was compiled into it. > > > > Maybe you should try without mmc driver. > > The MMC section in the kernel config is commented. > Ah, I seem overlooked it. Please try without emac driver. Ganbold > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 12:50:01 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1461616 for ; Thu, 24 Apr 2014 12:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EA4F14A3 for ; Thu, 24 Apr 2014 12:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3OCo1ng053257 for ; Thu, 24 Apr 2014 12:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3OCo1hB053256; Thu, 24 Apr 2014 12:50:01 GMT (envelope-from gnats) Date: Thu, 24 Apr 2014 12:50:01 GMT Message-Id: <201404241250.s3OCo1hB053256@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Winston Smith Subject: Re: arm/188933: lock order reversal: backtrace while writing to SD/eMMC X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Winston Smith List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 12:50:01 -0000 The following reply was made to PR arm/188933; it has been noted by GNATS. From: Winston Smith To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/188933: lock order reversal: backtrace while writing to SD/eMMC Date: Thu, 24 Apr 2014 08:47:59 -0400 I found the exact same issue testing on FreeBSD-CURRENT on the BBB; this was removing a directory tree with `rm -rf` on the eMMC: FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r264670: Fri Apr 18 18:55:02 EDT 2014 root@freebsd:/root/Work/crochet-freebsd/work/obj/arm.armv6/usr/src/FreeBSD-CURRENT/sys/BEAGLEBONE arm lock order reversal: 1st 0xcd25b0f8 bufwait (bufwait) @ /usr/src/FreeBSD-CURRENT/sys/kern/vfs_bio.c:3081 2nd 0xc3260600 dirhash (dirhash) @ /usr/src/FreeBSD-CURRENT/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0542258 lr = 0xc02324bc (db_trace_self_wrapper+0x30) sp = 0xde6c89e0 fp = 0xde6c8af8 r10 = 0xc3260600 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc02324bc lr = 0xc039b358 (kdb_backtrace+0x38) sp = 0xde6c8b00 fp = 0xde6c8b08 r4 = 0xc0689484 r5 = 0xc059401b r6 = 0xc05c7b91 r7 = 0xc05b16e0 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc039b358 lr = 0xc03b5c78 (witness_checkorder+0xe50) sp = 0xde6c8b10 fp = 0xde6c8b60 r4 = 0xc05c7f53 witness_checkorder() at witness_checkorder+0xe50 pc = 0xc03b5c78 lr = 0xc036c1bc (_sx_xlock+0x7c) sp = 0xde6c8b68 fp = 0xde6c8b90 r4 = 0x0000011c r5 = 0xc05c7b8e r6 = 0xc3260610 r7 = 0xc3260600 r8 = 0x00000000 r9 = 0xc31a3280 r10 = 0x00000000 _sx_xlock() at _sx_xlock+0x7c pc = 0xc036c1bc lr = 0xc04fe408 (ufsdirhash_remove+0x38) sp = 0xde6c8b98 fp = 0xde6c8bb0 r4 = 0xc3260600 r5 = 0xc31a024c r6 = 0xce430018 r7 = 0xc31a3280 r8 = 0x00000018 ufsdirhash_remove() at ufsdirhash_remove+0x38 pc = 0xc04fe408 lr = 0xc0501260 (ufs_dirremove+0x14c) sp = 0xde6c8bb8 fp = 0xde6c8be8 r4 = 0xc3048c00 r5 = 0xc31a024c r6 = 0xc31a0240 r7 = 0xce430018 r8 = 0x00000000 ufs_dirremove() at ufs_dirremove+0x14c pc = 0xc0501260 lr = 0xc05076e8 (ufs_remove+0x64) sp = 0xde6c8bf0 fp = 0xde6c8c18 r4 = 0xc3041d80 r5 = 0x00000001 r6 = 0xc31a0240 r7 = 0xc3048c00 r8 = 0xc2e05000 r9 = 0xc3041d80 r10 = 0x00000000 ufs_remove() at ufs_remove+0x64 pc = 0xc05076e8 lr = 0xc056bd5c (VOP_REMOVE_APV+0xd0) sp = 0xde6c8c20 fp = 0xde6c8c30 r4 = 0xde6c8d78 r5 = 0xc066acd0 r6 = 0x00000000 r7 = 0xffffff9c r8 = 0x00000000 VOP_REMOVE_APV() at VOP_REMOVE_APV+0xd0 pc = 0xc056bd5c lr = 0xc04126dc (kern_unlinkat+0x1b4) sp = 0xde6c8c38 fp = 0xde6c8da8 r4 = 0xde6c8cd8 r5 = 0xc2e05000 r6 = 0x2081b358 kern_unlinkat() at kern_unlinkat+0x1b4 pc = 0xc04126dc lr = 0xc04122fc (sys_unlink+0x24) sp = 0xde6c8db0 fp = 0xde6c8db8 r4 = 0xc2e05000 r5 = 0xc2dfb640 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000001 r9 = 0xde6c8e10 r10 = 0x00012790 sys_unlink() at sys_unlink+0x24 pc = 0xc04122fc lr = 0xc0557878 (swi_handler+0x284) sp = 0xde6c8dc0 fp = 0xde6c8e58 swi_handler() at swi_handler+0x284 pc = 0xc0557878 lr = 0xc0543d74 (swi_exit) sp = 0xde6c8e60 fp = 0xbffffce0 r4 = 0x20803080 r5 = 0x0000a4ce r6 = 0x00000000 r7 = 0x0000000a r8 = 0x00000001 r9 = 0x00000000 swi_exit() at swi_exit pc = 0xc0543d74 lr = 0xc0543d74 (swi_exit) sp = 0xde6c8e60 fp = 0xbffffce0 Unable to unwind further From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 20:35:08 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C7222B5 for ; Thu, 24 Apr 2014 20:35:08 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6FFB91AD5 for ; Thu, 24 Apr 2014 20:35:07 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WdQMG-000Cv0-MU; Thu, 24 Apr 2014 20:35:00 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3OKYwmi010906; Thu, 24 Apr 2014 14:34:58 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18S97Sk13NjDy00z16xz5AB Subject: Re: buildkernel: #error "On SMP systems we should have proper atomic operations." From: Ian Lepore To: Boris Samorodov In-Reply-To: <5358AF80.4010403@passap.ru> References: <5358AF80.4010403@passap.ru> Content-Type: text/plain; charset="koi8-r" Date: Thu, 24 Apr 2014 14:34:58 -0600 Message-ID: <1398371698.61646.96.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s3OKYwmi010906 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:35:08 -0000 On Thu, 2014-04-24 at 10:30 +0400, Boris Samorodov wrote: > Hi All, >=20 > I try to compile a kernel at WANDBOARD-QUAD and get the error: > ----- > =3D=3D=3D> fuse (depend) > [...] > CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE > -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq > -I/usr/obj/arm.arm/usr/src/sys/IMX6 -std=3Diso9899:1999 /usr/src/sys/= mod > ules/fuse/../../fs/fuse/fuse_node.c > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_io.c > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_device.c > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_ipc.c > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_file.c > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vfsops.c > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vnops.c > /usr/src/sys/modules/fuse/../. > ./fs/fuse/fuse_internal.c > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_main.c > --- .depend --- > /usr/src/sys/arm/arm/stdatomic.c:120:2: error: "On SMP systems we shoul= d > have proper atomic operations." > #error "On SMP systems we should have proper atomic operations." > ^ > 1 error generated. > ----- >=20 > The system: > ----- > % uname -a > FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r264681: Sun Apr > 20 02:39:12 SAMT 2014 > root@bb052.bsnet:/home/bsam/crochet-freebsd-master/work/obj/arm.armv6/u= sr/src/sys/IMX6 > arm >=20 > % svnlite info /usr/src > Path: /usr/src > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 264824 > Node Kind: directory > Schedule: normal > Last Changed Author: ed > Last Changed Rev: 264823 > Last Changed Date: 2014-04-23 18:05:28 +0400 (=D3=D2, 23 =C1=D0=D2 2014= ) > ----- >=20 > --=20 > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve Hmmm, for a wandboard you shouldn't get to line 120, it's for armv5. Oh wait, you must have typo'd the TARGET=3D as arm instead of armv6, because= : -I/usr/obj/arm.arm/usr/src/sys/IMX6 -std=3Diso9899:1999 /usr/src/sys/mo= d that should be obj/arm.armv6/ in that path. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 20:38:06 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC66A4DF; Thu, 24 Apr 2014 20:38:05 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7FDC1B07; Thu, 24 Apr 2014 20:38:05 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 7A193150; Thu, 24 Apr 2014 20:38:03 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 7A193150 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 24 Apr 2014 16:38:01 -0400 From: Glen Barber To: Ian Lepore Subject: Re: buildkernel: #error "On SMP systems we should have proper atomic operations." Message-ID: <20140424203801.GH49791@glenbarber.us> References: <5358AF80.4010403@passap.ru> <1398371698.61646.96.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nPae/vprxxBmi7c6" Content-Disposition: inline In-Reply-To: <1398371698.61646.96.camel@revolution.hippie.lan> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:38:06 -0000 --nPae/vprxxBmi7c6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 24, 2014 at 02:34:58PM -0600, Ian Lepore wrote: > On Thu, 2014-04-24 at 10:30 +0400, Boris Samorodov wrote: > > Hi All, > >=20 > > I try to compile a kernel at WANDBOARD-QUAD and get the error: > > ----- > > =3D=3D=3D> fuse (depend) > > [...] > > CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE > > -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq > > -I/usr/obj/arm.arm/usr/src/sys/IMX6 -std=3Diso9899:1999 /usr/src/sys/= mod > > ules/fuse/../../fs/fuse/fuse_node.c > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_io.c > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_device.c > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_ipc.c > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_file.c > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vfsops.c > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vnops.c > > /usr/src/sys/modules/fuse/../. > > ./fs/fuse/fuse_internal.c > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_main.c > > --- .depend --- > > /usr/src/sys/arm/arm/stdatomic.c:120:2: error: "On SMP systems we should > > have proper atomic operations." > > #error "On SMP systems we should have proper atomic operations." > > ^ > > 1 error generated. > > ----- > >=20 > > The system: > > ----- > > % uname -a > > FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r264681: Sun Apr > > 20 02:39:12 SAMT 2014 > > root@bb052.bsnet:/home/bsam/crochet-freebsd-master/work/obj/arm.armv6/u= sr/src/sys/IMX6 > > arm > >=20 > > % svnlite info /usr/src > > Path: /usr/src > > Working Copy Root Path: /usr/src > > URL: https://svn0.us-west.freebsd.org/base/head > > Relative URL: ^/head > > Repository Root: https://svn0.us-west.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 264824 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: ed > > Last Changed Rev: 264823 > > Last Changed Date: 2014-04-23 18:05:28 +0400 (=D1=81=D1=80, 23 =D0=B0= =D0=BF=D1=80 2014) > > ----- > >=20 > > --=20 > > WBR, Boris Samorodov (bsam) > > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve >=20 > Hmmm, for a wandboard you shouldn't get to line 120, it's for armv5. Oh > wait, you must have typo'd the TARGET=3D as arm instead of armv6, because: >=20 > -I/usr/obj/arm.arm/usr/src/sys/IMX6 -std=3Diso9899:1999 /usr/src/sys/mod >=20 > that should be obj/arm.armv6/ in that path. >=20 I think TARGET=3Darm TARGET_ARCH=3Darmv6 is the correct environment, not TARGET=3Darmv6. Or did something change (again!)? Glen --nPae/vprxxBmi7c6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTWXYpAAoJELls3eqvi17QidgQAKsS8+JftCNQBSVX1hPZZuhy zJoF/C0FQYl90Pakei/eL4ElOD1R6lz0sdeSRLi7CqKkhoQYh5FDltr9h4ora/hl iL8b7tvT877txQhaKGqx+MbtnMKUVhG/RfkHSmQH2ylHhE6ngIcc/yGsaKINIKRO zt0nZKRpnYeSmbg+XJxOhWaQLr+oIN6FjT//7a22bVVW2pV0nlphPVkCFg5qNTtU X3YZOdtq6d0nZ+11pGg8MAwP6hUdq/y35Qw4AHRVrkEzPCaTUpxUT+xA61JMsHr9 gr4fQl6xCiLKiFvev0qTLUD1TYYSxf849i1KJqAFV+w9VrnjkMAR6uhT7qFfKzbx DAfszHGbpy25h8CrPkkYLJBhkx1y7Et8tieepY9loJFLScpYRm1rk/Q4PkEWZQ4A yLP3aIhDV/v+QaxkggedMq8LEsRFBnISpHzkp2hQ5MAWSE6LrT5InLsPoFWxktBB ehjUAw/TtwYPIhsKskpm7MXzzzgboslk7GqOdKY96FmhseSP+sF9zGjmgAwyYdTi xykw365zC2799TMZRgI7/SyDYj7tF8gzPo6aw3U9wT5PoObJcWhH9nbyXWuuQltV O090QKVesdBWNm/YJ3imOO3uDfKArA3G2tQ5HY5YPnre5bzGNGuQYM08Bk1UmpX4 Gpn01InbX3SI13b/f8GJ =ZBEl -----END PGP SIGNATURE----- --nPae/vprxxBmi7c6-- From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 20:44:11 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E1C6870; Thu, 24 Apr 2014 20:44:11 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6FF511BE6; Thu, 24 Apr 2014 20:44:11 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WdQV8-000JIn-4A; Thu, 24 Apr 2014 20:44:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3OKi8pI010922; Thu, 24 Apr 2014 14:44:08 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/ZxyOV+z9VuKgvvoTxrJ+z Subject: Re: buildkernel: #error "On SMP systems we should have proper atomic operations." From: Ian Lepore To: Glen Barber In-Reply-To: <20140424203801.GH49791@glenbarber.us> References: <5358AF80.4010403@passap.ru> <1398371698.61646.96.camel@revolution.hippie.lan> <20140424203801.GH49791@glenbarber.us> Content-Type: text/plain; charset="koi8-r" Date: Thu, 24 Apr 2014 14:44:08 -0600 Message-ID: <1398372248.61646.98.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s3OKi8pI010922 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:44:11 -0000 On Thu, 2014-04-24 at 16:38 -0400, Glen Barber wrote: > On Thu, Apr 24, 2014 at 02:34:58PM -0600, Ian Lepore wrote: > > On Thu, 2014-04-24 at 10:30 +0400, Boris Samorodov wrote: > > > Hi All, > > >=20 > > > I try to compile a kernel at WANDBOARD-QUAD and get the error: > > > ----- > > > =3D=3D=3D> fuse (depend) > > > [...] > > > CC=3D'cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE > > > -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq > > > -I/usr/obj/arm.arm/usr/src/sys/IMX6 -std=3Diso9899:1999 /usr/src/= sys/mod > > > ules/fuse/../../fs/fuse/fuse_node.c > > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_io.c > > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_device.c > > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_ipc.c > > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_file.c > > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vfsops.c > > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vnops.c > > > /usr/src/sys/modules/fuse/../. > > > ./fs/fuse/fuse_internal.c > > > /usr/src/sys/modules/fuse/../../fs/fuse/fuse_main.c > > > --- .depend --- > > > /usr/src/sys/arm/arm/stdatomic.c:120:2: error: "On SMP systems we s= hould > > > have proper atomic operations." > > > #error "On SMP systems we should have proper atomic operations." > > > ^ > > > 1 error generated. > > > ----- > > >=20 > > > The system: > > > ----- > > > % uname -a > > > FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r264681: Sun= Apr > > > 20 02:39:12 SAMT 2014 > > > root@bb052.bsnet:/home/bsam/crochet-freebsd-master/work/obj/arm.arm= v6/usr/src/sys/IMX6 > > > arm > > >=20 > > > % svnlite info /usr/src > > > Path: /usr/src > > > Working Copy Root Path: /usr/src > > > URL: https://svn0.us-west.freebsd.org/base/head > > > Relative URL: ^/head > > > Repository Root: https://svn0.us-west.freebsd.org/base > > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > > Revision: 264824 > > > Node Kind: directory > > > Schedule: normal > > > Last Changed Author: ed > > > Last Changed Rev: 264823 > > > Last Changed Date: 2014-04-23 18:05:28 +0400 (=D3=D2, 23 =C1=D0=D2 = 2014) > > > ----- > > >=20 > > > --=20 > > > WBR, Boris Samorodov (bsam) > > > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > >=20 > > Hmmm, for a wandboard you shouldn't get to line 120, it's for armv5. = Oh > > wait, you must have typo'd the TARGET=3D as arm instead of armv6, bec= ause: > >=20 > > -I/usr/obj/arm.arm/usr/src/sys/IMX6 -std=3Diso9899:1999 /usr/src/sy= s/mod > >=20 > > that should be obj/arm.armv6/ in that path. > >=20 >=20 > I think TARGET=3Darm TARGET_ARCH=3Darmv6 is the correct environment, no= t > TARGET=3Darmv6. >=20 > Or did something change (again!)? >=20 > Glen >=20 Nope, my bad, it should be TARGET_ARCH=3Darmv6 (and no need to also specify TARGET=3D at all). I'm just demonstrating once again that "multitasking" is shorthand for "screwing up multiple things at once." -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Apr 24 20:46:34 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 793C0976; Thu, 24 Apr 2014 20:46:34 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49AF71C1D; Thu, 24 Apr 2014 20:46:34 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 0DCA1297; Thu, 24 Apr 2014 20:46:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 0DCA1297 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 24 Apr 2014 16:46:31 -0400 From: Glen Barber To: Ian Lepore Subject: Re: buildkernel: #error "On SMP systems we should have proper atomic operations." Message-ID: <20140424204631.GI49791@glenbarber.us> References: <5358AF80.4010403@passap.ru> <1398371698.61646.96.camel@revolution.hippie.lan> <20140424203801.GH49791@glenbarber.us> <1398372248.61646.98.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5RIsqXDwgzvYGRyn" Content-Disposition: inline In-Reply-To: <1398372248.61646.98.camel@revolution.hippie.lan> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:46:34 -0000 --5RIsqXDwgzvYGRyn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 24, 2014 at 02:44:08PM -0600, Ian Lepore wrote: > Nope, my bad, it should be TARGET_ARCH=3Darmv6 (and no need to also > specify TARGET=3D at all). >=20 > I'm just demonstrating once again that "multitasking" is shorthand for > "screwing up multiple things at once." >=20 I am all too familiar with the concept. :) Thanks. Glen --5RIsqXDwgzvYGRyn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTWXgnAAoJELls3eqvi17QHhYQAMH9SlGr5dKthkkl9PXzLW2Y aDhS9nfe/5fbF4QPum6sGR5bkUoawuV0y4QQ109JR8MB+GFCArvpDpac2MKWmALE UFv7ob09P0FY81eAuiLNmifZzmvMtL6IOCOrqtjvUu6bczsRzUCCQbxZbd8mqlPW ohT08GZHPEA9lzB5Zb9+RA0yHKcrK0oCF8mCWQyGmLtqtVnFIyjwdrcNzEpzVO8L eQH4Zh+OgGjn53FYYKJSoq0Pi3P5sNl9uqWfsi+Tk3gh/Vc/G3LMY/2ID1Tjkjdw vYOetX8nAyjhu4L/JUdFg8xC798cLUSy+j3QR3lobrYH0Qc2YMiTU9UGApLaNsZc 0/nNYbhL0S1UiXokDuwYWVJMnIruXgwWRqcFA9an45wOZESfsbJmNPIZKZfP2q91 BeFQGfGgjPvuIK/4nYYUoh/HiTuLNjd/88FOkRAlGc7V+HoVc+EIXZLB5cqm3qzG ATr8IUf4TAsX9UYYWsh0Vh4JSfCRzd5pC7e3D69YSge4VacmogeoWoqAK9zpfKFn xrR6M2sQg5+DSo+zMQbIXBXXfnKmsLKKA+GyhiZfMYGNZ82M0YmULF9gqqUB2Omh RJN0bAWVtIoADNZGI5GCF6dv4UrOOllfBQ0faDhs/2RRq5Y5YHoeHA/nKkeZkyh7 DliVjcoinxSkLTQv/WBL =E3um -----END PGP SIGNATURE----- --5RIsqXDwgzvYGRyn-- From owner-freebsd-arm@FreeBSD.ORG Fri Apr 25 07:43:05 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85E15786; Fri, 25 Apr 2014 07:43:05 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19A0A1A1B; Fri, 25 Apr 2014 07:43:05 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 7B1D71A40E61; Fri, 25 Apr 2014 11:43:00 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 13D1E2C3824; Fri, 25 Apr 2014 11:42:59 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id KI0JzBbGm5-gxp06Rgp; Fri, 25 Apr 2014 11:42:59 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 3dccd8b2-8b94-4087-a69d-c0c6ebc6e605 Message-ID: <535A1203.90105@passap.ru> Date: Fri, 25 Apr 2014 11:42:59 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: buildkernel: #error "On SMP systems we should have proper atomic operations." References: <5358AF80.4010403@passap.ru> <1398371698.61646.96.camel@revolution.hippie.lan> <20140424203801.GH49791@glenbarber.us> <1398372248.61646.98.camel@revolution.hippie.lan> In-Reply-To: <1398372248.61646.98.camel@revolution.hippie.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 07:43:05 -0000 25.04.2014 00:44, Ian Lepore пишет: > On Thu, 2014-04-24 at 16:38 -0400, Glen Barber wrote: >> On Thu, Apr 24, 2014 at 02:34:58PM -0600, Ian Lepore wrote: >>> On Thu, 2014-04-24 at 10:30 +0400, Boris Samorodov wrote: >>>> Hi All, >>>> >>>> I try to compile a kernel at WANDBOARD-QUAD and get the error: >>>> ----- >>>> ===> fuse (depend) >>>> [...] >>>> CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE >>>> -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq >>>> -I/usr/obj/arm.arm/usr/src/sys/IMX6 -std=iso9899:1999 /usr/src/sys/mod >>>> ules/fuse/../../fs/fuse/fuse_node.c >>>> /usr/src/sys/modules/fuse/../../fs/fuse/fuse_io.c >>>> /usr/src/sys/modules/fuse/../../fs/fuse/fuse_device.c >>>> /usr/src/sys/modules/fuse/../../fs/fuse/fuse_ipc.c >>>> /usr/src/sys/modules/fuse/../../fs/fuse/fuse_file.c >>>> /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vfsops.c >>>> /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vnops.c >>>> /usr/src/sys/modules/fuse/../. >>>> ./fs/fuse/fuse_internal.c >>>> /usr/src/sys/modules/fuse/../../fs/fuse/fuse_main.c >>>> --- .depend --- >>>> /usr/src/sys/arm/arm/stdatomic.c:120:2: error: "On SMP systems we should >>>> have proper atomic operations." >>>> #error "On SMP systems we should have proper atomic operations." >>>> ^ >>>> 1 error generated. >>>> ----- >>>> >>>> The system: >>>> ----- >>>> % uname -a >>>> FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r264681: Sun Apr >>>> 20 02:39:12 SAMT 2014 >>>> root@bb052.bsnet:/home/bsam/crochet-freebsd-master/work/obj/arm.armv6/usr/src/sys/IMX6 >>>> arm >>>> >>>> % svnlite info /usr/src >>>> Path: /usr/src >>>> Working Copy Root Path: /usr/src >>>> URL: https://svn0.us-west.freebsd.org/base/head >>>> Relative URL: ^/head >>>> Repository Root: https://svn0.us-west.freebsd.org/base >>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>> Revision: 264824 >>>> Node Kind: directory >>>> Schedule: normal >>>> Last Changed Author: ed >>>> Last Changed Rev: 264823 >>>> Last Changed Date: 2014-04-23 18:05:28 +0400 (ср, 23 апр 2014) >>>> ----- >>>> >>>> -- >>>> WBR, Boris Samorodov (bsam) >>>> FreeBSD Committer, http://www.FreeBSD.org The Power To Serve >>> >>> Hmmm, for a wandboard you shouldn't get to line 120, it's for armv5. Oh >>> wait, you must have typo'd the TARGET= as arm instead of armv6, because: >>> >>> -I/usr/obj/arm.arm/usr/src/sys/IMX6 -std=iso9899:1999 /usr/src/sys/mod >>> >>> that should be obj/arm.armv6/ in that path. Oh, I see. TARGET defining is a trace of a previous cross-compiling. I'll fix my script and retry. >> I think TARGET=arm TARGET_ARCH=armv6 is the correct environment, not >> TARGET=armv6. >> >> Or did something change (again!)? > > Nope, my bad, it should be TARGET_ARCH=armv6 (and no need to also > specify TARGET= at all). Thank you! > I'm just demonstrating once again that "multitasking" is shorthand for > "screwing up multiple things at once." -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Fri Apr 25 07:55:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA49C9EE for ; Fri, 25 Apr 2014 07:55:32 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A6CB1B7E for ; Fri, 25 Apr 2014 07:55:32 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 72DD01A411C3 for ; Fri, 25 Apr 2014 11:55:30 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 1F55F2C381F for ; Fri, 25 Apr 2014 11:55:30 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id P9NBYocjjH-tTpmWOjb; Fri, 25 Apr 2014 11:55:29 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 8260fee2-9f71-4c6b-8f3f-ff8f9a254abf Message-ID: <535A14F1.5010808@passap.ru> Date: Fri, 25 Apr 2014 11:55:29 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: define a custom kernel X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 07:55:32 -0000 Hi All, I used to define a custom kernel at /etc/make.conf. At i386/amd64 archs it works: ----- % grep KERNCONF /etc/make.conf KERNCONF= BB64X % make -C /usr/src -V KERNCONF BB64X ----- However at arm I get: ----- % grep KERNCONF /etc/make.conf KERNCONF= WBQ % make -C /usr/src -V KERNCONF IMX6 % uname -a FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r264681: Sun Apr 20 02:39:12 SAMT 2014 root@bb052.bsnet:/home/bsam/crochet-freebsd-master/work/obj/arm.armv6/usr/src/sys/IMX6 arm ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Fri Apr 25 14:21:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BB028A8 for ; Fri, 25 Apr 2014 14:21:29 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13EBD1A31 for ; Fri, 25 Apr 2014 14:21:28 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id rl12so3864788iec.4 for ; Fri, 25 Apr 2014 07:21:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=CEh7zRxSq8UQPVniNoRCSmp56mOTaUaG47GPhj3oePE=; b=K8zg897Z7OlLiJWK8AzOT2ogGg4tIzBdGZPvpp2G89jbARX2AFKUk3viEkw5tUyGhc yhGtS0/1yv7aZDtP2Y/OTfzLjFrZk3nGRbn2B58nFW80tNkaqZBe25P6BTAeTa+ztWH6 NcK9PYMjSZsvGwR124ANzdQC3RlbXXk1N0Wuv5SBvK9vGAhAeDJLHdNbR3T7SkoGdbfA p2/PQXizCL81wlebr25PsIZy4zjQXC01YIXOHEFhBJNPnUuH2HkQIhX4rk0PnKOILsEd HqpDDFHvIp1MsHLtIIvJSMY6EqtByX7Ea9bQpAUBXWWZ2V2DIZb2cz952aW2Y5P0saj7 C5xg== X-Gm-Message-State: ALoCoQl0hkTCNi7db4x9DWb+Y3+yWWi1iSXa6IPkm3T+shaa8rdHM00wDd9k3Rxd9WwDkMZQ82rJ X-Received: by 10.50.92.98 with SMTP id cl2mr5419114igb.14.1398435682605; Fri, 25 Apr 2014 07:21:22 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id b6sm8920285igm.2.2014.04.25.07.21.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Apr 2014 07:21:22 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: define a custom kernel From: Warner Losh In-Reply-To: <535A14F1.5010808@passap.ru> Date: Fri, 25 Apr 2014 08:21:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <535A14F1.5010808@passap.ru> To: Boris Samorodov X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:21:29 -0000 do you have KERNCONF defined in /etc/src.conf on arm? Warner On Apr 25, 2014, at 1:55 AM, Boris Samorodov wrote: > Hi All, >=20 > I used to define a custom kernel at /etc/make.conf. At i386/amd64 > archs it works: > ----- > % grep KERNCONF /etc/make.conf > KERNCONF=3D BB64X >=20 > % make -C /usr/src -V KERNCONF > BB64X > ----- >=20 > However at arm I get: > ----- > % grep KERNCONF /etc/make.conf > KERNCONF=3D WBQ >=20 > % make -C /usr/src -V KERNCONF > IMX6 >=20 > % uname -a > FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r264681: Sun = Apr > 20 02:39:12 SAMT 2014 > = root@bb052.bsnet:/home/bsam/crochet-freebsd-master/work/obj/arm.armv6/usr/= src/sys/IMX6 > arm > ----- >=20 > --=20 > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Apr 25 14:29:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAECDB76 for ; Fri, 25 Apr 2014 14:29:48 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67CD41AB4 for ; Fri, 25 Apr 2014 14:29:48 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward8l.mail.yandex.net (Yandex) with ESMTP id C73E71A412E2; Fri, 25 Apr 2014 18:29:37 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 5FBB21704139; Fri, 25 Apr 2014 18:29:37 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id l52Xtf9SY3-TbSqY81G; Fri, 25 Apr 2014 18:29:37 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 95e95380-29aa-4287-98fd-26b829b9ede6 Message-ID: <535A7150.20800@passap.ru> Date: Fri, 25 Apr 2014 18:29:36 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: define a custom kernel References: <535A14F1.5010808@passap.ru> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:29:48 -0000 25.04.2014 18:21, Warner Losh пишет: > do you have KERNCONF defined in /etc/src.conf on arm? My bad! Usually I do not use src.conf, but this time it was indeed installed (assume by crochet scripts). Thank you! The problem solved. > On Apr 25, 2014, at 1:55 AM, Boris Samorodov wrote: > >> Hi All, >> >> I used to define a custom kernel at /etc/make.conf. At i386/amd64 >> archs it works: >> ----- >> % grep KERNCONF /etc/make.conf >> KERNCONF= BB64X >> >> % make -C /usr/src -V KERNCONF >> BB64X >> ----- >> >> However at arm I get: >> ----- >> % grep KERNCONF /etc/make.conf >> KERNCONF= WBQ >> >> % make -C /usr/src -V KERNCONF >> IMX6 >> >> % uname -a >> FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r264681: Sun Apr >> 20 02:39:12 SAMT 2014 >> root@bb052.bsnet:/home/bsam/crochet-freebsd-master/work/obj/arm.armv6/usr/src/sys/IMX6 >> arm >> ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Fri Apr 25 15:45:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 504DC750 for ; Fri, 25 Apr 2014 15:45:14 +0000 (UTC) Received: from mail-01.thismonkey.com (220-245-31-196.static.tpgi.com.au [220.245.31.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-01.thismonkey.com", Issuer "Thismonkey IT Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 990881382 for ; Fri, 25 Apr 2014 15:45:12 +0000 (UTC) X-TM-Via-MX: mail-01.thismonkey.com Received: from utility-01.thismonkey.com (utility-01.thismonkey.com [10.1.1.32]) by mail-01.thismonkey.com (8.14.5/8.14.5) with ESMTP id s3PFiYUJ082911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 26 Apr 2014 01:44:34 +1000 (EST) (envelope-from freebsd-lists-3@thismonkey.com) Received: from utility-01.thismonkey.com (localhost [127.0.0.1]) by utility-01.thismonkey.com (8.14.5/8.14.5) with ESMTP id s3PFiXrj076266 for ; Sat, 26 Apr 2014 01:44:34 +1000 (EST) (envelope-from freebsd-lists-3@thismonkey.com) Received: (from root@localhost) by utility-01.thismonkey.com (8.14.5/8.14.5/Submit) id s3PFiUsh076265 for freebsd-arm@freebsd.org; Sat, 26 Apr 2014 01:44:30 +1000 (EST) (envelope-from freebsd-lists-3@thismonkey.com) Date: Sat, 26 Apr 2014 01:44:30 +1000 From: Scott Aitken To: freebsd-arm@freebsd.org Subject: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined Message-ID: <20140425154430.GA76168@utility-01.thismonkey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (mail-01.thismonkey.com [10.1.2.50]); Sat, 26 Apr 2014 01:44:34 +1000 (EST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:45:14 -0000 Hi all, I'm hoping to use my RPi/FreeBSD as an Airplay device to my amplifier which presents a USB DAC. uname: FreeBSD raspberry-pi 10.0-STABLE FreeBSD 10.0-STABLE #0 r263906: Sat Mar 29 20:13:51 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm DAC in dmesg: uhid0: on usbus0 When I try to load snd_uaudio: root@raspberry-pi:~ # kldload snd_uaudio kldload: can't load snd_uaudio: No such file or directory dmesg: link_elf: symbol isa_dmastatus undefined KLD snd_uaudio.ko: depends on sound - not available or version mismatch The kernel modules are there in /boot/kernel. If I try to load sound.ko: root@raspberry-pi:~ # kldload sound.ko kldload: can't load sound.ko: No such file or directory dmesg: link_elf: symbol isa_dmastatus undefined Is sound.ko supported under RPi or am I doing something wrong here? Thanks in advance, Scott From owner-freebsd-arm@FreeBSD.ORG Fri Apr 25 16:17:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 847722EF for ; Fri, 25 Apr 2014 16:17:58 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42653171B for ; Fri, 25 Apr 2014 16:17:58 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 15FAF1FE02B; Fri, 25 Apr 2014 18:17:54 +0200 (CEST) Message-ID: <535A8AEA.1000100@selasky.org> Date: Fri, 25 Apr 2014 18:18:50 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Scott Aitken , freebsd-arm@freebsd.org Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined References: <20140425154430.GA76168@utility-01.thismonkey.com> In-Reply-To: <20140425154430.GA76168@utility-01.thismonkey.com> 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 16:17:58 -0000 On 04/25/14 17:44, Scott Aitken wrote: > Hi all, > > I'm hoping to use my RPi/FreeBSD as an Airplay device to my amplifier which > presents a USB DAC. > Hi, Audio devices which use ISOCHRONOUS data transport are not supported i FreeBSD, because the RPi uses very small buffers and has to handle 8000 IRQ/s typically for ISOC transfers. --HPS From owner-freebsd-arm@FreeBSD.ORG Fri Apr 25 21:01:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8457126 for ; Fri, 25 Apr 2014 21:01:07 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 79F0C1679 for ; Fri, 25 Apr 2014 21:01:06 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3PKfenB005409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Apr 2014 22:41:41 +0200 (CEST) (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 s3PKfZFd072107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Apr 2014 22:41:35 +0200 (CEST) (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 s3PKfZg0002594; Fri, 25 Apr 2014 22:41:35 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3PKfYZC002593; Fri, 25 Apr 2014 22:41:34 +0200 (CEST) (envelope-from ticso) Date: Fri, 25 Apr 2014 22:41:34 +0200 From: Bernd Walter To: Hans Petter Selasky Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined Message-ID: <20140425204134.GA458@cicely7.cicely.de> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535A8AEA.1000100@selasky.org> 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, Scott Aitken X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:01:08 -0000 On Fri, Apr 25, 2014 at 06:18:50PM +0200, Hans Petter Selasky wrote: > On 04/25/14 17:44, Scott Aitken wrote: > >Hi all, > > > >I'm hoping to use my RPi/FreeBSD as an Airplay device to my amplifier which > >presents a USB DAC. > > > > Hi, > > Audio devices which use ISOCHRONOUS data transport are not supported i > FreeBSD, because the RPi uses very small buffers and has to handle 8000 > IRQ/s typically for ISOC transfers. This looks more like uaudio module fails to load because it depends on sound module, which itself then requires ISA bus support in kernel. The sound.ko shouldn't require ISA when build on ARM. It might work to compile the drivers into the kernel. If it uses ISOCHRONOUS, then that's an unrelated problem IMO. Do all uaudio devices use isochronous endpoints or is it an optional thing? If it is optional, then he might have a chance. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 03:51:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 843EDA75 for ; Sat, 26 Apr 2014 03:51:49 +0000 (UTC) Received: from nm46-vm10.bullet.mail.bf1.yahoo.com (nm46-vm10.bullet.mail.bf1.yahoo.com [216.109.114.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D7671C80 for ; Sat, 26 Apr 2014 03:51:48 +0000 (UTC) Received: from [98.139.215.140] by nm46.bullet.mail.bf1.yahoo.com with NNFMP; 26 Apr 2014 03:51:41 -0000 Received: from [98.139.213.13] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 26 Apr 2014 03:51:41 -0000 Received: from [127.0.0.1] by smtp113.mail.bf1.yahoo.com with NNFMP; 26 Apr 2014 03:51:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s1024; t=1398484301; bh=4fLsyQjb7ToP0ZyL4GxELRLvwjEQ4JIKU7JbIoA+U40=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=24ROYYOvrqteG7vZvXwto4YecR0TAueELM1mvOup3/WnqbgO+BFIqJhIUM4hv7e1wY3/1H0C6xgiSAIuE6VYqAwGtfup/Gl5sYicJvKr/hfPMT8i0FTmxDR4uoioHoaeSM3T9Sd2nL2DZ0GXs2cbkBogv96G6kNfYY69JzPx/no= X-Yahoo-Newman-Id: 85817.34486.bm@smtp113.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: decS1w0VM1m9XWVXTH2PmLYmtAIB6QsJNR9nrkjbd22HS4v kF.2FPjcN2hFgdX7j7S_8ul4Khx9po3vZ_2CKi2wjZJIlmbEHKVxHx2P0Dw9 UuB_0Np55_UqNWJAiLDquHzhbu_7bEN9vFrPOLQMi06nguka5JsiCfv1RYOr 5ntS7MPfHA4Duc1myV7Vy8IRFwFcfcXttU9lxrvzwL7zxCIJruz6J_k.X_Gx t6.IvkNo_csPR7ruxcjtrkDLpcq8Bw4lW2mtcDxZksGXQABZR0zOzWrpQw8O muoIF2KHIZjO4LJjvgNtKpCz_0Ata474I04HiFDC6og0t6VIJKXSWqhC_9pI HytFEvPfYo2KUHZ3t0bm4OS05WOewi8k0ZpuWv_OzToayRa.oM2PeA077lNH 7w5BIyKhQCeFsY5VLugjX0Mxw6WvWz2LOUQJBojVW.sqBr4iRpfG_FxLAlfg qSsQhb0d4qhgjzGfGAf2c_dGjZvc6CcS1B7n0EgO8obqa4xH.jzPiUA__g1z pTWa8aEy8de9m8udEg8YEh.OxnCeFDVNnAna8uPpRDmh3LBbXTDZBAm.2qEj eMwT9JnAkEPtZpgO_X1HkDxvzSF5_aBZEHmvsptti6FUhpoNPSbLIxx05SXl _Hy34jjV.awH8.rWoXQ6ibK8RNqTk3fOeK8w9xO_LTFPra8pY1MYcYDMQ4o7 P X-Yahoo-SMTP: 51p0rh2swBCh3zxf6sJkNseoFwQzw1o- X-Rocket-Received: from [192.168.0.101] (daniloegea@177.34.241.163 with plain [98.139.211.125]) by smtp113.mail.bf1.yahoo.com with SMTP; 25 Apr 2014 20:51:41 -0700 PDT Message-ID: <535B2DC6.5050409@yahoo.com.br> Date: Sat, 26 Apr 2014 00:53:42 -0300 From: Danilo Egea User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Raspberry smsc0 failed to read register 0x114 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 03:51:49 -0000 Hello, I'm using 2 networks NICs on a Raspberry PI, the embedded NIC and one wifi adaptor, each one in a different network. When both adapters are UP and I send data through the *wifi* adapter I get the error [1]. If I remove the smsc device (with an usbconfig power_off for example) it works perfectly. Anyone got this problem? Thanks! [1] - https://dl.dropboxusercontent.com/u/23276705/smsc.jpg From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 11:14:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55B7C9C2 for ; Sat, 26 Apr 2014 11:14:48 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D26510AF for ; Sat, 26 Apr 2014 11:14:48 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1We0Z4-000ML5-BH; Sat, 26 Apr 2014 12:14:46 +0100 From: Mark R V Murray Content-Type: multipart/signed; boundary="Apple-Mail=_4A4D0807-BBBD-4C6B-A763-341EBFB33A3B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sat, 26 Apr 2014 12:14:49 +0100 Subject: i2c on RPI-B not working To: freebsd-arm Message-Id: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-SA-Score: -2.2 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 11:14:48 -0000 --Apple-Mail=_4A4D0807-BBBD-4C6B-A763-341EBFB33A3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi * The i2b bus on my RPI-B isn=92t working: [grapeseed] /usr/src 11:11 am # i2c -sv dev: /dev/iic0, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1 Error scanning I2C controller (/dev/iic0): Device not configured Scanning I2C devices on /dev/iic0: [grapeseed] /usr/src 11:11 am # i2c = -sv -f /dev/iic1 dev: /dev/iic1, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1 Error scanning I2C controller (/dev/iic1): Device not configured Its a bog-standard build with the RPI-B kernel, and a CURRENT about a = week old. Any ideas? M --=20 Mark R V Murray --Apple-Mail=_4A4D0807-BBBD-4C6B-A763-341EBFB33A3B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU1uVLt58vKOKE6LNAQqmWgP8DEoDMrBr4TWCv/Q63SwjrmyVlAUJE1kc /y1AYcKel3VyBGipWPtqYR/Xb+xhQHNQkYo0NM2ujOsix3asxyO4R0+TY82c/H3d hdwmzXbNy4isbxnIgMEEI/ai7xEhOuydDXgOuGxCRb9EV6IWW5/7I9Zn/JBo1H7I fmsswaPPfIo= =oLdR -----END PGP SIGNATURE----- --Apple-Mail=_4A4D0807-BBBD-4C6B-A763-341EBFB33A3B-- From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 18:34:08 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 419F6553; Sat, 26 Apr 2014 18:34:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA98D178D; Sat, 26 Apr 2014 18:34:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s3QIY5kR006767; Sat, 26 Apr 2014 14:34:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s3QIY4oh006751; Sat, 26 Apr 2014 18:34:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Apr 2014 18:34:04 GMT Message-Id: <201404261834.s3QIY4oh006751@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 18:34:08 -0000 TB --- 2014-04-26 15:20:26 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-26 15:20:26 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-26 15:20:26 - starting HEAD tinderbox run for arm/arm TB --- 2014-04-26 15:20:27 - cleaning the object tree TB --- 2014-04-26 15:20:27 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-26 15:20:34 - At svn revision 264973 TB --- 2014-04-26 15:20:35 - building world TB --- 2014-04-26 15:20:35 - CROSS_BUILD_TESTING=YES TB --- 2014-04-26 15:20:35 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-26 15:20:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-26 15:20:35 - SRCCONF=/dev/null TB --- 2014-04-26 15:20:35 - TARGET=arm TB --- 2014-04-26 15:20:35 - TARGET_ARCH=arm TB --- 2014-04-26 15:20:35 - TZ=UTC TB --- 2014-04-26 15:20:35 - __MAKE_CONF=/dev/null TB --- 2014-04-26 15:20:35 - cd /src TB --- 2014-04-26 15:20:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 26 15:20:42 UTC 2014 >>> 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 [...] cc -O -pipe -I. -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /src/usr.sbin/gssd/../../sys/kgssapi/gssd_prot.c cc -O -pipe -I. -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -o gssd gssd.o gssd_svc.o gssd_xdr.o gssd_prot.o -lgssapi -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt -lcrypto gzip -cn /src/usr.sbin/gssd/gssd.8 > gssd.8.gz ===> usr.sbin/gstat (all) cc -O -pipe -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c /src/usr.sbin/gstat/gstat.c cc -O -pipe -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -o gstat gstat.o -ldevstat -lkvm -lgeom -lbsdxml -lsbuf -ledit -lcurses gzip -cn /src/usr.sbin/gstat/gstat.8 > gstat.8.gz ===> usr.sbin/i2c (all) cc -O -pipe -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/usr.sbin/i2c/i2c.c cc -O -pipe -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -o i2c i2c.o gzip -cn /src/usr.sbin/i2c/i2c.8 > i2c.8.gz ===> usr.sbin/ifmcstat (all) cc -O -pipe -DINET6 -DWITH_KVM -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/usr.sbin/ifmcstat/ifmcstat.c /src/usr.sbin/ifmcstat/ifmcstat.c:119:9: error: 'sa_equal' macro redefined [-Werror] #define sa_equal(a1, a2) \ ^ /obj/arm.arm/src/tmp/usr/include/net/route.h:278:9: note: previous definition is here #define sa_equal(a, b) ( \ ^ 1 error generated. *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/ifmcstat *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-04-26 18:34:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-04-26 18:34:04 - ERROR: failed to build world TB --- 2014-04-26 18:34:04 - 9512.62 user 1490.84 system 11617.81 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 21:16:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 672402CE for ; Sat, 26 Apr 2014 21:16:52 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E73771688 for ; Sat, 26 Apr 2014 21:16:51 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so4010687wib.5 for ; Sat, 26 Apr 2014 14:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=ChbdKrDy7gxmED2wZzd+JZwn6ixb1gmTUSgkmXTWAqQ=; b=tXQx4V+U/PIYE151Rhvujr3Vo8sRk7d9mQmQQubNDmwQRQWCBT4I5Ostg9Pt3Vmwz5 R6oZLyS5VvHwqY6wmDyHcOHk2wkaMAV4zVaAn/ikhqVSPHoZgDYhppoIpuVtBSC61WV7 FybEUHBiPYpLrYdMaEbunyJYHy1CtU4REvAHXDnNiNrHeMp4378oWZiz36Sa8NKFkI6s ixB5efSa6S4n9kndVsV7pB1wViAZET4djUGDNgbC7sS0TsE5Oz98cK+JcDuIqI4TxEo/ vMgcWhf/7LyGn/b3pV1C6TZgyeiLz+iLJ+p31N6od5lqzNY3KyE+FW5FRsT/FtNj2Hqv Bq/g== X-Received: by 10.194.77.50 with SMTP id p18mr71564wjw.68.1398547010127; Sat, 26 Apr 2014 14:16:50 -0700 (PDT) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id ct2sm17679777wjb.33.2014.04.26.14.16.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Apr 2014 14:16:49 -0700 (PDT) From: fabiodive Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: BBB 1GHz patches for u-boot 2014-01 Date: Sat, 26 Apr 2014 22:16:45 +0100 Message-Id: To: Xuebing Wang Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 21:16:52 -0000 Hello all, I was compiling some new ports on my BBB and suddenly I got on the serial console header: mmcsd0: Error indicated: 1 Timeout sdhci_ti0-slot0: Got data interrupt 0x00000010, but there is no active = command. sdhci_ti0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_ti0-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000040 sdhci_ti0-slot0: Argument: 0x002751be | Trn mode: 0x0000193a sdhci_ti0-slot0: Present: 0x01e70000 | Host ctl: 0x00000006 sdhci_ti0-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_ti0-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 sdhci_ti0-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti0-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti0-slot0: =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 mmcsd0: Error indicated: 1 Timeout sdhci_ti0-slot0: Got data interrupt 0x00000010, but there is no active = command. sdhci_ti0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_ti0-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000040 sdhci_ti0-slot0: Argument: 0x0027b23e | Trn mode: 0x0000193a sdhci_ti0-slot0: Present: 0x01e70000 | Host ctl: 0x00000006 sdhci_ti0-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_ti0-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 sdhci_ti0-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti0-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti0-slot0: =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 mmcsd0: Error indicated: 1 Timeout sdhci_ti0-slot0: Got data interrupt 0x00000010, but there is no active = command. sdhci_ti0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_ti0-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000040 sdhci_ti0-slot0: Argument: 0x004e543e | Trn mode: 0x0000193a sdhci_ti0-slot0: Present: 0x01f70000 | Host ctl: 0x00000006 sdhci_ti0-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_ti0-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 sdhci_ti0-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti0-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti0-slot0: =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 g_vfs_done():mmcsd0s2a[WRITE(offset=3D667156480, length=3D32768)]error =3D= 5 g_vfs_done():mmcsd0s2a[WRITE(offset=3D1317208064, length=3D32768)]error = =3D 5 g_vfs_done():mmcsd0s2a[WRITE(offset=3D1329856512, length=3D32768)]error = =3D 5 mmcsd0: Error indicated: 1 Timeout sdhci_ti0-slot0: Got data interrupt 0x00000010, but there is no active = command. sdhci_ti0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_ti0-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000040 sdhci_ti0-slot0: Argument: 0x004e7c7e | Trn mode: 0x0000193a sdhci_ti0-slot0: Present: 0x01f70000 | Host ctl: 0x00000006 sdhci_ti0-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_ti0-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 sdhci_ti0-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti0-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti0-slot0: =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 mmcsd0: Error indicated: 1 Timeout sdhci_ti0-slot0: Got data interrupt 0x00000010, but there is no active = command. sdhci_ti0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_ti0-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000040 sdhci_ti0-slot0: Argument: 0x004e7cbe | Trn mode: 0x0000193a sdhci_ti0-slot0: Present: 0x01f70000 | Host ctl: 0x00000006 sdhci_ti0-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_ti0-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 sdhci_ti0-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti0-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti0-slot0: =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 mmcsd0: Error indicated: 1 Timeout sdhci_ti0-slot0: Got data interrupt 0x00000010, but there is no active = command. sdhci_ti0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_ti0-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000040 sdhci_ti0-slot0: Argument: 0x004e7cfe | Trn mode: 0x0000193a sdhci_ti0-slot0: Present: 0x01f70000 | Host ctl: 0x00000006 sdhci_ti0-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_ti0-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 sdhci_ti0-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti0-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti0-slot0: =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 g_vfs_done():mmcsd0s2a[WRITE(offset=3D2626158592, length=3D32768)]error = =3D 5 vm_fault(0xc0731c70, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (P)' trapframe: 0xdcfcebc0 FSR=3D00000017, FAR=3D00000010, spsr=3D40000013 r0 =3D00000001, r1 =3Dc262c320, r2 =3Dc262c320, r3 =3D00000010 r4 =3D00000010, r5 =3D00000000, r6 =3Dcd08ae90, r7 =3Dc278acd4 r8 =3Dc072b260, r9 =3D00000000, r10=3D00000000, r11=3Ddcfcec40 r12=3D0000ffff, ssp=3Ddcfcec10, slr=3Dc04534e8, pc =3Dc046fd18 panic: Fatal abort Uptime: 28m43s Automatic reboot in 15 seconds - press a key on the console to abort could be a sdcard problem but I am not sure, the system is a: Beaglebone Black running FreeBSD 11 built with the last crochet source code from github. root@beaglebone:~ # uname -ar FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r264703: Mon Apr = 21 04:52:38 WEST 2014 Please, if somebody has some ideas=85very welcome. Thank you cheers, f.= From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 22:18:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EAD0ECD for ; Sat, 26 Apr 2014 22:18:01 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D4D71AEA for ; Sat, 26 Apr 2014 22:18:00 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id u57so141665wes.31 for ; Sat, 26 Apr 2014 15:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sir3+hBItxOaONegrbQtudGookXH+iNdVoszgEkp7mE=; b=z2OWOP6fsdK+I3czZV1yIoWgxUskbPCx9diSD6tjBpX0wf8XK0t07nEtCF46m2SqWj Yzbw7a0TvAXf3mWpQWRT17W5L8jGBed9QtrUkTunpiD6vyN0+9nM112lSX/LdzLcTOJT wKmtGQWZ0nYPzdAMDsYQSKm2JJf5nKXeZlNiER+5+XgAD/4Olu+NabDGd6Ydomgmb8Cp DzYWT1R2RUYuBEdTg/AhEysbU5TSBG2yRnuPl3mlJLaVjOynK3c6BoLv/X2be9TQB7Mn 4KRphDmb+7Oin+WV2k1P8Ce5LbpeRW+gFva9roCo3o979pNsA0V3SBJFQ0D2HeCJzoue GX/w== MIME-Version: 1.0 X-Received: by 10.180.228.42 with SMTP id sf10mr8952480wic.33.1398550678935; Sat, 26 Apr 2014 15:17:58 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Sat, 26 Apr 2014 15:17:58 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Apr 2014 18:17:58 -0400 Message-ID: Subject: Re: BBB 1GHz patches for u-boot 2014-01 From: Winston Smith To: fabiodive Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM , Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 22:18:01 -0000 I saw something similar, but it didn't panic: sdhci_ti1-slot0: Got data interrupt 0x00100000, but there is no active command. sdhci_ti1-slot0: ============== REGISTER DUMP ============== sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti1-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000000 sdhci_ti1-slot0: Argument: 0x06c8d600 | Trn mode: 0x0000183a sdhci_ti1-slot0: Present: 0x01e70000 | Host ctl: 0x00000004 sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00000007 sdhci_ti1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti1-slot0: =========================================== mmcsd1: Error indicated: 1 Timeout I think perhaps FreeBSD-CURRENT is a bit too bleeding edge ... I have been trying to get 10-STABLE to work, it's fine on the SD card, but it hangs during boot on the eMMC. However 11-CURRENT boots ok on the eMMC, but has issues like this. -W. From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 22:23:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94FD2F54 for ; Sat, 26 Apr 2014 22:23:10 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D2541B8F for ; Sat, 26 Apr 2014 22:23:10 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u56so4997683wes.9 for ; Sat, 26 Apr 2014 15:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PFVQrBh7bP+/BxHiALorDzUwWqecwUN8qcMd+wzVKog=; b=zOlfzhEuAeX9CfcgGmqJLEsnqGsgUzoEI7FeupNH23T8Uy3DHYDD/zlFER8bXSRKvh uvmQc6560YV737k0jzowXy5dF6ChHiwBEParXerD5Xlb+tRgMs1tma95Z/Fi7+aZ46ZJ gF+bxEJQjY05xNG0SanGXzYu1M6kqWbNO4Q8Zhp3NxYP6et8Guc46YwHw+UVVRUHdfJ5 Zqo0uGjFNsGlcW2ToYJedTTAdKADIyup7UydiJhXwI/masQ6iz4KRsrZIMVDYh/AWxMr lxeu+0xQG0Ic8czkT36yFIcOm/dJkt9scEqh4glSBiJB1pjbGYQxzZ8XIO+yOX1SoGzJ Ez2w== MIME-Version: 1.0 X-Received: by 10.180.8.136 with SMTP id r8mr9060378wia.60.1398550988490; Sat, 26 Apr 2014 15:23:08 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Sat, 26 Apr 2014 15:23:08 -0700 (PDT) Date: Sat, 26 Apr 2014 18:23:08 -0400 Message-ID: Subject: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Winston Smith To: FreeBSD ARM Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 22:23:10 -0000 After some success with 11-CURRENT on the BBB/eMMC, I switched back to 10-STABLE but after building a crotchet-freebsd image (using Patrick's script), I can't get it to boot from the eMMC. The image works ok on the SD card, but if I either use the new copy-to-emmc.sh script, or build an eMMC specific image (using BEAGLEBONE_BOOT_EMMC=y), it hangs during the boot (below). It seems to fail when trying to access /boot/defaults/loader.conf Any ideas welcome! --- U-Boot SPL 2013.04 (Apr 18 2014 - 20:25:05) OMAP SD/MMC: 0 reading bb-uboot.img reading bb-uboot.img U-Boot 2013.04 (Apr 18 2014 - 20:25:05) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 mmc1(part 0) is current device SD/MMC found on device 1 reading bb-uEnv.txt reading bbubldr 247304 bytes read in 35 ms (6.7 MiB/s) reading bboneblk.dtb 15278 bytes read in 6 ms (2.4 MiB/s) Booting from mmc ... ## Starting application at 0x88000054 ... Consoles: U-Boot console Compatible API signature found @9f242240 MMC Device 2 not found MMC Device 3 not found MMC Device 2 not found Number of U-Boot devices: 3 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@freebsd, Fri Apr 25 20:27:41 EDT 2014) DRAM: 512MB Device: disk MMC Device 2 not found MMC Device 3 not found disk0: device open failed with error=2, handle=1 Device: net cpsw Waiting for PHY auto negotiation to complete. done link up on port 0, speed 100, full duplex From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 22:26:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12189F98 for ; Sat, 26 Apr 2014 22:26:08 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 997B91B9C for ; Sat, 26 Apr 2014 22:26:07 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so4043284wib.1 for ; Sat, 26 Apr 2014 15:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PD68EvvknuVVAbJ49QveGCHvU6NyWBwoiwYuGlbjaNM=; b=IFecJW3YmEIgG8l5T0xo0G53dY46JpBVdN30GPz7WHKQEXRu/wxkipizrxuYBq+66N h0cyHF4pXANRvQSIrWsVapjBCC6GGfdoWWNFBEo0iyip/K75QcTPBeLJHnf/2CLBkbyY 0br3/Wq/+0uiPWFuQOjijGFcs/+E16NFDQ55hiWXGG8U96+GreOU0RR/L10nTvstiKJq lw6eItfLp39m8aLWIFeaVcWoEfSX2l+TzNxvGtpwPLHaDFPr9zrGJTTRpsn6d+l4RjWB wSyvXFOa8ir8FF3ePojHhpJPrHd5PLLQ0kwm1JWnxesSCGXdJa6827T217mUg13Ai3bK jU4A== X-Received: by 10.180.126.33 with SMTP id mv1mr465612wib.6.1398551165959; Sat, 26 Apr 2014 15:26:05 -0700 (PDT) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id ct2sm17903976wjb.33.2014.04.26.15.26.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Apr 2014 15:26:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: BBB 1GHz patches for u-boot 2014-01 From: fabiodive In-Reply-To: Date: Sat, 26 Apr 2014 23:26:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> References: To: Winston Smith X-Mailer: Apple Mail (2.1510) Cc: FreeBSD ARM , Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 22:26:08 -0000 OK, I would like to add a couple of details: -I patched the u-boot 2014-01 with the last patch set from Xuebing, it works very good, I suppose at 1GHz,=20 -I get the panic during intensive sdcard write operation such as download, untar or install a port. -this maybe related with the new crochet version is=20 the eMMC is not recognised, I don't have the /dev/mmcsd1 device so I can't copy the system on the flash. thanks for your reply, f. On Apr 26, 2014, at 23:17 , Winston Smith = wrote: > I saw something similar, but it didn't panic: >=20 > sdhci_ti1-slot0: Got data interrupt 0x00100000, but there is no active = command. > sdhci_ti1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 > sdhci_ti1-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000000 > sdhci_ti1-slot0: Argument: 0x06c8d600 | Trn mode: 0x0000183a > sdhci_ti1-slot0: Present: 0x01e70000 | Host ctl: 0x00000004 > sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 > sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00000007 > sdhci_ti1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 > sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 > sdhci_ti1-slot0: =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 > mmcsd1: Error indicated: 1 Timeout >=20 >=20 > I think perhaps FreeBSD-CURRENT is a bit too bleeding edge ... I have > been trying to get 10-STABLE to work, it's fine on the SD card, but it > hangs during boot on the eMMC. However 11-CURRENT boots ok on the > eMMC, but has issues like this. >=20 > -W. From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 22:29:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 138E3FD1 for ; Sat, 26 Apr 2014 22:29:38 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3AEC1BA3 for ; Sat, 26 Apr 2014 22:29:37 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id n12so1710921wgh.18 for ; Sat, 26 Apr 2014 15:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9On4Bs3q+uiMD2jABpzu/yOzkwINUtXsD9hZXb7zNeQ=; b=MVyF3G0HM1pUllwJI/BCKAPG6oOYMEG/iz6ym6X/FBN1ED+2/b0matjpKIOVgkxFOP mAc/pwDaNNUKuLbvCQHh6bsSnpH7OoltPSIDx/685Rk4dLwkdoRiHzb4/xbi12tnj+aB X8uHbsnor1x6SEHyb2le5O7+M8M2XAvgXaAQIt2iZcjJD95Qq0/+xYQgv0F/dxknV5zJ rnYVaNVBOuR0rZw+ZKQUpHxqu20VaoCKERB12O9qNm3n+4thh6YCiQZdjTf2L8GyYONE rQQEpiw2eEFzFVNFXN12VO7rYezoowXuZ7/b+ydve5uMltCEctwUYgekhU3mXdvAflVu sxsA== MIME-Version: 1.0 X-Received: by 10.180.76.146 with SMTP id k18mr9023615wiw.5.1398551375849; Sat, 26 Apr 2014 15:29:35 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Sat, 26 Apr 2014 15:29:35 -0700 (PDT) Date: Sat, 26 Apr 2014 18:29:35 -0400 Message-ID: Subject: Looking for FreeBSD u-boot/kernel debugging help (BeagleBone Black) From: Winston Smith To: FreeBSD ARM Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 22:29:38 -0000 I'm looking for any wisdom on debugging FreeBSD/u-boot on the BBB. I have had some luck with 11-CURRENT, but I think 10-STABLE is probably a more realistic target. I did find this while Googling: https://wiki.freebsd.org/EmbeddedHandbook But it's not very complete. I also discovered that if I disconnect my serial terminal and reconnect it, it seems to bring the FreeBSD kernel to a debug prompt of sorts -- is there any documentation on this? Thanks. From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 22:31:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAF06AE for ; Sat, 26 Apr 2014 22:31:10 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64B811BB0 for ; Sat, 26 Apr 2014 22:31:10 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id l18so4881565wgh.28 for ; Sat, 26 Apr 2014 15:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7nw7BGnyVTLJvX3TOvwjC4lytvpM9E5/IaRBDfmD+U4=; b=btfjcOMQxjsiPIwj1IUHozZLGUUb7FSYbjpJfQr/Tkwm4lWa/VKMwi23WtI2HJ+wh2 I00V61xaswjPatOZ1TV0W6ZX3ITD4lvL5zv4Egbkg+Wx+17sqyHFbym3bcqxLAF+x5Xe WZC0T0zaIZXVKsDaAbaaPoqwdIb7rLuA+nc8AcjFbVKZP34pNWEuyk0tUrd0on6IqBgv hyfZ1e16ovlahs+MOi9Gh+rzbfs2HFV43voJhQNjT3/C6j6GHmSLrivNdcFbSEiPxj8v TtolSGlc9fPBLwNbxn3Y0kBa/3mVVWcZKSWXvl4FTHyCXz8/OsMj8ACV3yUzZgtv+B2a XZsg== MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr9039655wic.5.1398551468694; Sat, 26 Apr 2014 15:31:08 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Sat, 26 Apr 2014 15:31:08 -0700 (PDT) In-Reply-To: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> References: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> Date: Sat, 26 Apr 2014 18:31:08 -0400 Message-ID: Subject: Re: BBB 1GHz patches for u-boot 2014-01 From: Winston Smith To: fabiodive Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM , Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 22:31:10 -0000 On Sat, Apr 26, 2014 at 6:26 PM, fabiodive wrote: > -I patched the u-boot 2014-01 with the last patch set from Xuebing, > it works very good, I suppose at 1GHz, Do you have a link to those patches? From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 22:36:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCFB824C for ; Sat, 26 Apr 2014 22:36:45 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50E821C3B for ; Sat, 26 Apr 2014 22:36:45 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id bs8so4114584wib.17 for ; Sat, 26 Apr 2014 15:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kpyNc8+p7goInqNBAwdJqD5bOVscJk0GaiSQhtLfWpU=; b=LFRRAQSU5nJ8mzqQ9+smA6YHMPyJdHfRiYpbfV+OB71eGBG2DVX9T8/+WtCOiKunx2 xeKf/KUUzpKXV3z9s51Gae/xcSlXfgzmXz7gZJQDu+YHrBJbF8AAP823U46jQ/a+3Rtc p2mr4XXwoX+bU4ZsmV+EcN5sk2Rxkfn2jWqqKi7ZXVejeGxhJtyCqX9YU9I17K/AaWS6 DpSIdTOtRtMXEW8l4jPyaerhSQfbL1VgnMhtjfDbvrk2/lmkwTf1LjQPUHZwU16yQ+n4 uBPFct5x7BG+hZsTFy8JGQJhLsnNq7rLPcKYcZxOofUzEXMRRYpsZTwWhi31Hb89wX0F xCZg== X-Received: by 10.180.75.45 with SMTP id z13mr9151547wiv.41.1398551803501; Sat, 26 Apr 2014 15:36:43 -0700 (PDT) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id hg18sm6647405wib.19.2014.04.26.15.36.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Apr 2014 15:36:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: BBB 1GHz patches for u-boot 2014-01 From: fabiodive In-Reply-To: Date: Sat, 26 Apr 2014 23:36:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <746D7AE2-54D1-4758-816F-4954F3F01A5E@gmail.com> References: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> To: Winston Smith X-Mailer: Apple Mail (2.1510) Cc: FreeBSD ARM , Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 22:36:45 -0000 http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007944.html are three files On Apr 26, 2014, at 23:31 , Winston Smith = wrote: > On Sat, Apr 26, 2014 at 6:26 PM, fabiodive = wrote: >> -I patched the u-boot 2014-01 with the last patch set from Xuebing, >> it works very good, I suppose at 1GHz, >=20 > Do you have a link to those patches? From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 23:34:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B846F06 for ; Sat, 26 Apr 2014 23:34:45 +0000 (UTC) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 10F7E11D2 for ; Sat, 26 Apr 2014 23:34:44 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 49123B827; Sat, 26 Apr 2014 16:34:38 -0700 (PDT) To: Winston Smith Subject: Re: Looking for FreeBSD u-boot/kernel debugging help (BeagleBone Black) In-reply-to: Your message of "Sat, 26 Apr 2014 18:29:35 EDT." References: Comments: In-reply-to Winston Smith message dated "Sat, 26 Apr 2014 18:29:35 -0400." Date: Sat, 26 Apr 2014 16:34:38 -0700 From: Bakul Shah Message-Id: <20140426233438.49123B827@mail.bitblocks.com> Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 23:34:45 -0000 On Sat, 26 Apr 2014 18:29:35 EDT Winston Smith wrote: > I also discovered that if I disconnect my > serial terminal and reconnect it, it seems to bring the FreeBSD kernel > to a debug prompt of sorts -- is there any documentation on this? I suspect disconnecting/reconnecting the serial cable looks like a break to the kernel and that drops it into the debugger "ddb". [Though I can't seem to send a real break to it using kermit!] Type c and hit return to continue. To disable this behavior I think you can do sysctl debug.kbd.break_to_debugger=0 or add debug.kbd.break_to_debugger=0 to /etc/sysctl.conf man 1 ddb -- for debugger commands man 4 ddb -- for kernel config options to control ddb behavior From owner-freebsd-arm@FreeBSD.ORG Sun Apr 27 01:09:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B413D88 for ; Sun, 27 Apr 2014 01:09:00 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 039981850 for ; Sun, 27 Apr 2014 01:08:59 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hm4so4101035wib.0 for ; Sat, 26 Apr 2014 18:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PWFRdtKG01kmMX2s0TzMtmzvsGtLXjk+CZDBCzmlG34=; b=EDuTtbdyOXIlEiWkpthj9FWIWZlaMA5xEqXOm5QOeiLKRdAVFTeHXuVia7DnA5gxLW fnCyEmr1TPoFQU20CBL3DFwFQlwGXk/xJ2YXr8JQWJzzKrJgiMtKxnbkQCu8+Ai5qnHA aSIx8gyIsqs/VL0xKOR1xLq98OaD0cM1N0v90IRzf8Gm1C6C1QPJ34T2bzEw7y9qMVeQ W2NOJJqPT6mnwoL4H6BmwFH0gric1l+XC9UN/+WYpFseHfXQQ+17e0va+nkjeGbhIAvi z5QtJWO3duY1rBZFoS7gr7gb1nYnPcndSRkWBo7EHzINe5WB+c48qKoRPZbmfftVrUo6 ylnQ== MIME-Version: 1.0 X-Received: by 10.180.100.129 with SMTP id ey1mr9353435wib.60.1398560938313; Sat, 26 Apr 2014 18:08:58 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Sat, 26 Apr 2014 18:08:58 -0700 (PDT) In-Reply-To: <746D7AE2-54D1-4758-816F-4954F3F01A5E@gmail.com> References: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> <746D7AE2-54D1-4758-816F-4954F3F01A5E@gmail.com> Date: Sat, 26 Apr 2014 21:08:58 -0400 Message-ID: Subject: Re: BBB 1GHz patches for u-boot 2014-01 From: Winston Smith To: fabiodive Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM , Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 01:09:00 -0000 On Sat, Apr 26, 2014 at 6:36 PM, fabiodive wrote: > http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007944.html Forgive my ignorance here, but these don't quite look like regular patch files ... presumably they get applied to crotchet-freebsd/board/BeagleBone to replace the ones already in there? From owner-freebsd-arm@FreeBSD.ORG Sun Apr 27 03:48:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59AF74E7 for ; Sun, 27 Apr 2014 03:48:52 +0000 (UTC) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D990875E for ; Sun, 27 Apr 2014 03:48:51 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id e49so3819268eek.11 for ; Sat, 26 Apr 2014 20:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5yFgnwhRPDBjI4raMNrEhh3xEwRf4YCMKP0UyEqgAS4=; b=cwFppofi5T/gm1bQknR9fKRP9DeMyaEllO5Lbq8QCHwIMBYaAuswdr4N9lEk6YvfaI po7ssF2hnJcXk7PzZTZ94UA2Xp88XuGHMOQXc/Mz7XSaE+s81YGpT5wUuPjlopdSwhNb jD1AX/5hwXvvICHwZHH3W5VRYyneBG1B2FTxSUcgOP7R+i8iDdevSQsDs+Ue7pSb6QZh /kuUSeSuMja54ox1rPM6D3qivyXz5JtWf/aizlHFfxtMS1UooSKV9Le0Q8XFp2NwyOqD SgofAAHArSb3onsbLI6KPaqkPbqwv1iRdY79pPWg2tzbGCnB+nvIgVvqSsInXGev5lE7 5OgQ== X-Received: by 10.15.42.138 with SMTP id u10mr21522449eev.7.1398570528683; Sat, 26 Apr 2014 20:48:48 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id m42sm38338864eex.21.2014.04.26.20.48.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Apr 2014 20:48:47 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <535C7E1B.1090605@hot.ee> Date: Sun, 27 Apr 2014 06:48:43 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Winston Smith Subject: Re: BBB 1GHz patches for u-boot 2014-01 References: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> <746D7AE2-54D1-4758-816F-4954F3F01A5E@gmail.com> In-Reply-To: X-TagToolbar-Keys: D20140427064843238 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM , Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 03:48:52 -0000 On 2014-04-27 04:08, Winston Smith wrote: > On Sat, Apr 26, 2014 at 6:36 PM, fabiodive wrote: >> http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007944.html > > Forgive my ignorance here, but these don't quite look like regular > patch files ... presumably they get applied to > crotchet-freebsd/board/BeagleBone to replace the ones already in > there? No, those patches update BB[WB] uboot port to new version and are perfectly good patches that patch(1) accepts. I bet you can hack those into crochet too, if you really wish. I also wonder about those weird SD errors... I have different issues myself (there's message for that already, so I don't repeat). But my issues always appear on boot. I currently don't run from external SD but I just tried it and IIRC there are no changes to this code after that. Internal SD (or eMMC, however you name it) works well, although I had to apply strange hack which apparently changes some timings so eMMC detection works correctly. I don't know how that code works, I never write HW drivers, so I have no idea on that issue. Well, ian@, who DOES write HW drivers, has no idea too :P Maybe I should get more than one BBB (for which you need to make special order, I heard) to properly test my stuff and also other things like possible external SD weirdness. It's painful to boot from different medium to test some things while disturbing other things (long-running stability tests). I could say that BBB is nice piece of HW and 11-CURRENT is very STABLE (what a pun) overall, with (obviously) some CURRENTish glitches... I also must say that I use eMMC mostly read-only, with rare writes to upgrade (whole) system (which is ~150MB in size). BTW, I usually use IRC (EFnet : #bsdmips + several others, and I never quit), because I somehow find writing long pieces of text difficult. Although I like mail as non-instant means of communication. From owner-freebsd-arm@FreeBSD.ORG Sun Apr 27 14:34:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAE14F61; Sun, 27 Apr 2014 14:34:47 +0000 (UTC) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84D3F1A19; Sun, 27 Apr 2014 14:34:47 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id fb1so4213014pad.38 for ; Sun, 27 Apr 2014 07:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TvBST0FPhXtj0YBvAuQizfFtyMJ5DMFt8TEhhMdJE9M=; b=thdDj+dN0mWkDlKIIkKR1pxjvSHwrP3XLE/38VM+Wz03qE+xCOU6HKe5Cm++72Va05 PiLWRf9sRK68QHkZdvDIXmKQEm3F74utTQmypDz0RQvaurPBFw0wTi/8v3EVdUwol99i O9svYDdVrO1KOSA73vyp7TgE7MqZsLXGks/UjdL9jIq3028JyUuJBYSrajO9cdLn1V0i 8qjuUtYS4sfmA/f4PAoXAGaYG/pko1OeCkGHu/5LgoDQ8lfMh/9/nrNldluM6wfQXF1X ec0kGk1dorxQXs5QKRdhnNA9ZpMQ4oRGYjPwUwwxGBKQ6UBWci2zdkl1rib5Z7a5nw+Y UWOg== X-Received: by 10.66.177.168 with SMTP id cr8mr3044669pac.128.1398609276394; Sun, 27 Apr 2014 07:34:36 -0700 (PDT) Received: from [216.131.71.113] ([216.131.71.113]) by mx.google.com with ESMTPSA id ky8sm28741243pbc.64.2014.04.27.07.34.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Apr 2014 07:34:35 -0700 (PDT) Message-ID: <535D1576.6040005@gmail.com> Date: Sun, 27 Apr 2014 22:34:30 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Sulev-Madis Silber (ketas)" , Winston Smith Subject: Re: BBB 1GHz patches for u-boot 2014-01 References: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> <746D7AE2-54D1-4758-816F-4954F3F01A5E@gmail.com> <535C7E1B.1090605@hot.ee> In-Reply-To: <535C7E1B.1090605@hot.ee> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 14:34:47 -0000 1) We have 2 packages that concerning u-boot: 1a) Crocket 1b) /usr/ports/sysutils/u-boot-beaglebone-eabi Please note: the patches for u-boot in the above 2 packages are different. In my humble opinion, I'd think the u-boot patches for the above 2 packages are better to be identical. 2) My patches to the latest u-boot are against above 1b) /usr/ports/sysutils/u-boot-beaglebone-eabi 3) To rule out the sd-card issue is caused by the latest u-boot, would you mind to go back to the previous u-boot, and re-run the test? Replacing u-boot and MLO can be done by something similar below: scp MLO root@192.168.1.10:/boot/msdos scp u-boot.img root@192.168.1.10:/boot/msdos/BB_UBOOT.IMG Thanks. On 04/27/2014 11:48 AM, Sulev-Madis Silber (ketas) wrote: > On 2014-04-27 04:08, Winston Smith wrote: >> On Sat, Apr 26, 2014 at 6:36 PM, fabiodive wrote: >>> http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007944.html >> Forgive my ignorance here, but these don't quite look like regular >> patch files ... presumably they get applied to >> crotchet-freebsd/board/BeagleBone to replace the ones already in >> there? > > No, those patches update BB[WB] uboot port to new version and are > perfectly good patches that patch(1) accepts. I bet you can hack those > into crochet too, if you really wish. > > > I also wonder about those weird SD errors... I have different issues > myself (there's message for that already, so I don't repeat). But my > issues always appear on boot. I currently don't run from external SD but > I just tried it and IIRC there are no changes to this code after that. > Internal SD (or eMMC, however you name it) works well, although I had to > apply strange hack which apparently changes some timings so eMMC > detection works correctly. I don't know how that code works, I never > write HW drivers, so I have no idea on that issue. Well, ian@, who DOES > write HW drivers, has no idea too :P Maybe I should get more than one > BBB (for which you need to make special order, I heard) to properly test > my stuff and also other things like possible external SD weirdness. It's > painful to boot from different medium to test some things while > disturbing other things (long-running stability tests). I could say that > BBB is nice piece of HW and 11-CURRENT is very STABLE (what a pun) > overall, with (obviously) some CURRENTish glitches... I also must say > that I use eMMC mostly read-only, with rare writes to upgrade (whole) > system (which is ~150MB in size). > > > BTW, I usually use IRC (EFnet : #bsdmips + several others, and I never > quit), because I somehow find writing long pieces of text difficult. > Although I like mail as non-instant means of communication. > -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Sun Apr 27 16:40:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 487BA3EB for ; Sun, 27 Apr 2014 16:40:10 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D32AB900 for ; Sun, 27 Apr 2014 16:40:09 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id cc10so4649603wib.8 for ; Sun, 27 Apr 2014 09:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q4lcaMMx171YrtzHr7uV9XvkXktt/lrCl0lHcbkWyMI=; b=fDEMmce/f1k0clnuyMFMImjj/5QXYYudXf+ArDlLdXwW3hfVX/LZcbw2Brx2xBpyw9 RYxV/uUBQIUJqzWh6Dj/ckQ2LgQfzn/NfnmJ0/DGg8vMAONfKVgT5XWdo82uFC9QGQsH YPkRTZwZV4TArRByt9EyQXSITBrm7nmoRsZdcLY7vpwFzTYi8wicn9VzmfCTSteTraOf FmfrHzKBigAQkF/7BLzW/x3xUJ4u2uEVGDygOgpAzqpoDV+4Dtpjqy1th27yMiCjuBXr r0o8W2DXhGgpWtpwMN2x5yPP56ZsapKvrc648RnMsTrHKgW33xvgUS/SpTyD+gIzMfrR AnDQ== MIME-Version: 1.0 X-Received: by 10.180.100.129 with SMTP id ey1mr11841276wib.60.1398616807931; Sun, 27 Apr 2014 09:40:07 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Sun, 27 Apr 2014 09:40:07 -0700 (PDT) In-Reply-To: <535C7E1B.1090605@hot.ee> References: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> <746D7AE2-54D1-4758-816F-4954F3F01A5E@gmail.com> <535C7E1B.1090605@hot.ee> Date: Sun, 27 Apr 2014 12:40:07 -0400 Message-ID: Subject: Re: BBB 1GHz patches for u-boot 2014-01 From: Winston Smith To: "Sulev-Madis Silber (ketas)" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM , Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 16:40:10 -0000 On Sat, Apr 26, 2014 at 11:48 PM, Sulev-Madis Silber (ketas) wrote: > On 2014-04-27 04:08, Winston Smith wrote: >> On Sat, Apr 26, 2014 at 6:36 PM, fabiodive wrote: >>> http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007944.html >> >> Forgive my ignorance here, but these don't quite look like regular >> patch files ... presumably they get applied to >> crotchet-freebsd/board/BeagleBone to replace the ones already in >> there? > > > No, those patches update BB[WB] uboot port to new version and are > perfectly good patches that patch(1) accepts. I bet you can hack those > into crochet too, if you really wish. Yeah, I was wondering about the extra Makefile etc. I have been using pkgng (and manual builds) rather than the ports tree. I will have a go at hacking these into crotchet as that's how I'm building u-boot (from a tarball). > I also wonder about those weird SD errors... I have different issues > myself (there's message for that already, so I don't repeat). But my > issues always appear on boot. I currently don't run from external SD but > I just tried it and IIRC there are no changes to this code after that. > Internal SD (or eMMC, however you name it) works well, although I had to > apply strange hack which apparently changes some timings so eMMC > detection works correctly. I don't know how that code works, I never > write HW drivers, so I have no idea on that issue. Well, ian@, who DOES > write HW drivers, has no idea too :P I'm not sure about the lock-reversal warnings, although this may simply be a false-positive (since it's a WITNESS kernel?). The timeout errors are more concerning ... esp. the panics (although I haven't seen that). I really need to start digging into how to debug this [kernel] kind of stuff on the BBB. > Maybe I should get more than one > BBB (for which you need to make special order, I heard) to properly test > my stuff and also other things like possible external SD weirdness. It's > painful to boot from different medium to test some things while > disturbing other things (long-running stability tests). I don't think you need a special order to get more BBB's although the availability ebbs and flows. Seems like there's no availability right now, but if you keep checking, you'll suddenly see everyone get stock. Also, there's now apparently a company in China selling a clone of the BBB: http://www.embest-tech.com/shop/star/bb-black-replica.html According to some comments I saw on the beaglebone group, it seems to be of good quality. > I could say that > BBB is nice piece of HW and 11-CURRENT is very STABLE (what a pun) > overall, with (obviously) some CURRENTish glitches... I also must say > that I use eMMC mostly read-only, with rare writes to upgrade (whole) > system (which is ~150MB in size). My reason for switching from 11-CURRENT to 10-STABLE is that the Go folks aren't supporting Go on 11-CURRENT since it's not slated for release for a long time! (although Go 1.3beta1 + patches mostly works). However, Go works well [and is supported] on FreeBSD-10. So I need to find some middle ground between Go + FreeBSD and FreeBSD + BBB, which I'm hoping will be 10-STABLE (and an eventual 10.1 release?). > BTW, I usually use IRC (EFnet : #bsdmips + several others, and I never > quit), because I somehow find writing long pieces of text difficult. > Although I like mail as non-instant means of communication. OK. I'll dig up my IRC client! From owner-freebsd-arm@FreeBSD.ORG Sun Apr 27 17:05:00 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 517A1B9C for ; Sun, 27 Apr 2014 17:05:00 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25960B6F for ; Sun, 27 Apr 2014 17:04:59 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WeSVe-0003Bb-SV; Sun, 27 Apr 2014 17:04:59 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3RH4uD6014015; Sun, 27 Apr 2014 11:04:56 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19eYuESgd425LVocut172ZH Subject: Re: Looking for FreeBSD u-boot/kernel debugging help (BeagleBone Black) From: Ian Lepore To: Bakul Shah In-Reply-To: <20140426233438.49123B827@mail.bitblocks.com> References: <20140426233438.49123B827@mail.bitblocks.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Apr 2014 11:04:56 -0600 Message-ID: <1398618296.61646.161.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 17:05:00 -0000 On Sat, 2014-04-26 at 16:34 -0700, Bakul Shah wrote: > On Sat, 26 Apr 2014 18:29:35 EDT Winston Smith wrote: > > I also discovered that if I disconnect my > > serial terminal and reconnect it, it seems to bring the FreeBSD kernel > > to a debug prompt of sorts -- is there any documentation on this? > > I suspect disconnecting/reconnecting the serial cable looks like > a break to the kernel and that drops it into the debugger "ddb". > [Though I can't seem to send a real break to it using kermit!] > > Type c and hit return to continue. > > To disable this behavior I think you can do > sysctl debug.kbd.break_to_debugger=0 > or add > debug.kbd.break_to_debugger=0 > to /etc/sysctl.conf > > man 1 ddb -- for debugger commands > man 4 ddb -- for kernel config options to control ddb behavior That's exactly correct -- connecting the cable sometimes leads to a spurious break being asserted on the line (a break is just a long sequence of zeroes with no start/stop/data bit transitions). It's possible to configure a kernel without BREAK_TO_DEBUGGER and with ALT_BREAK_TO_DEBUGGER. That eliminates most line-noise spurious breaks but still allows the ~ ^b break sequence (which could theoretically happen in a burst of line noise, but not likely). A few of our kernels have BREAK_TO_DEBUGGER in the config, and I think that's probably a mistake. Most folks these days don't know anything about breaks or how to generate one on purpose. Any objections to removing them and using only the safer ALT_BREAK option? -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Apr 27 17:16:28 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B36CACC7 for ; Sun, 27 Apr 2014 17:16:28 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7612FC4E for ; Sun, 27 Apr 2014 17:16:28 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WeSgl-0008aD-DJ; Sun, 27 Apr 2014 17:16:27 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3RHGPRk014023; Sun, 27 Apr 2014 11:16:25 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19m8/PGcIAtAwpc2CfizL6D Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Ian Lepore To: Winston Smith In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Apr 2014 11:16:24 -0600 Message-ID: <1398618984.61646.165.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 17:16:28 -0000 On Sat, 2014-04-26 at 18:23 -0400, Winston Smith wrote: > After some success with 11-CURRENT on the BBB/eMMC, I switched back to > 10-STABLE but after building a crotchet-freebsd image (using Patrick's > script), I can't get it to boot from the eMMC. > > The image works ok on the SD card, but if I either use the new > copy-to-emmc.sh script, or build an eMMC specific image (using > BEAGLEBONE_BOOT_EMMC=y), it hangs during the boot (below). It seems > to fail when trying to access /boot/defaults/loader.conf > > Any ideas welcome! > > > --- > > U-Boot SPL 2013.04 (Apr 18 2014 - 20:25:05) > OMAP SD/MMC: 0 > reading bb-uboot.img > reading bb-uboot.img > > > U-Boot 2013.04 (Apr 18 2014 - 20:25:05) > > I2C: ready > DRAM: 512 MiB > WARNING: Caches not enabled > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Using default environment > > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Peripheral mode controller at 47401000 using PIO, IRQ 0 > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Host mode controller at 47401800 using PIO, IRQ 0 > Net: not set. Validating first E-fuse MAC > cpsw, usb_ether > Hit any key to stop autoboot: 0 > mmc1(part 0) is current device > SD/MMC found on device 1 > reading bb-uEnv.txt > reading bbubldr > 247304 bytes read in 35 ms (6.7 MiB/s) > reading bboneblk.dtb > 15278 bytes read in 6 ms (2.4 MiB/s) > Booting from mmc ... > ## Starting application at 0x88000054 ... > Consoles: U-Boot console > Compatible API signature found @9f242240 > MMC Device 2 not found > MMC Device 3 not found > MMC Device 2 not found > Number of U-Boot devices: 3 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@freebsd, Fri Apr 25 20:27:41 EDT 2014) > DRAM: 512MB > > Device: disk > MMC Device 2 not found > MMC Device 3 not found > disk0: device open failed with error=2, handle=1 > > Device: net > cpsw Waiting for PHY auto negotiation to complete. done > link up on port 0, speed 100, full duplex I only have a BBW, no BBB to play with, so I can't help too much with this. I can say however that if you're having trouble with reading the eMMC in ubldr, the trouble is probably in u-boot. U-boot is still in memory when ubldr is running, and it serves as a kind of mini-bios, providing access to console, disk, and network IO. I heard a rumor a while back that Patrick Kelsey had some patches for u-boot to fix problems with probing for disk devices. It may be that they were only needed for older versions of u-boot, I'm not sure. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Apr 27 17:43:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F46938E; Sun, 27 Apr 2014 17:43:15 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7910F86; Sun, 27 Apr 2014 17:43:14 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id x48so5542836wes.10 for ; Sun, 27 Apr 2014 10:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+avI6rnlrIZmx0jliZtiIyVxdp5KN4jOEQsy0GNG+go=; b=TADpneqc65z3JjxsI9BzrFG9kU4ItTcBRxPVIniDOuBaKwgOAMx83mbgJIjm5d0UYd TO0FVpGf5IGhZrUchYnjc7MZqamg7OLRUqATZ9p0jnzn7zPGakjPl6d+lszmHOazq/lP MYUyHCh+344ccn2nETd2xaK7fMr12ewqQf38z4JP6Gq4wYy5jx39kbnVuDJVjAh9hBhN GWnApSf1Dpr+1/OwM94hiDDIGKFFwTnlqJHX/MsQRLuFu+jgfbf+M6kN/gxGMkfY6EoO Ba7JMxgJWCsPp27eyftzv7sVDpDq3Fu/quWPzIrbf1FN622gen0qf7zTKJZNtW681nq9 jYNQ== MIME-Version: 1.0 X-Received: by 10.180.100.129 with SMTP id ey1mr11998334wib.60.1398620593193; Sun, 27 Apr 2014 10:43:13 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Sun, 27 Apr 2014 10:43:13 -0700 (PDT) In-Reply-To: <1398618984.61646.165.camel@revolution.hippie.lan> References: <1398618984.61646.165.camel@revolution.hippie.lan> Date: Sun, 27 Apr 2014 13:43:13 -0400 Message-ID: Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 17:43:15 -0000 On Sun, Apr 27, 2014 at 1:16 PM, Ian Lepore wrote: > I only have a BBW, no BBB to play with, so I can't help too much with > this. I can say however that if you're having trouble with reading the > eMMC in ubldr, the trouble is probably in u-boot. U-boot is still in > memory when ubldr is running, and it serves as a kind of mini-bios, > providing access to console, disk, and network IO. > > I heard a rumor a while back that Patrick Kelsey had some patches for > u-boot to fix problems with probing for disk devices. It may be that > they were only needed for older versions of u-boot, I'm not sure. I do have Patrick's fixes for u-boot. Interestingly, the same u-boot (2013.4 + Patrick's patches) works with 11-CURRENT but not 10-STABLE -- that's booting from eMMC, there are no issues booting from SD; also once booted from SD, there is no issues mounting the eMMC and accessing it (well ... aside from lock reversal warnings and the occasional sdhc timeout). Is there a way to debug this? Thanks! From owner-freebsd-arm@FreeBSD.ORG Sun Apr 27 18:37:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E3E3EB8 for ; Sun, 27 Apr 2014 18:37:43 +0000 (UTC) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F42113D1 for ; Sun, 27 Apr 2014 18:37:43 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id up15so5002348pbc.34 for ; Sun, 27 Apr 2014 11:37:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hQXjj0mP/tlBYtJ2NddRzs6auMwW7oSyQ0cGm0BeobQ=; b=cFNx5QV0SN07Szd3hmjomqmdH9HYCJu2nlTlKYSCSOn768Q0TQ0KZ83P/GL7JXY1RR /NaCUuzuiFMZIx2sraZI6Nj3UaMf2VUwVJk8igrs1tWgTG3mp3QN8f4EA4hnXlvlUhsK gYlI0kKpPFlr5bkN3tDM0ZBK3/zQOblUoWKuH0NWkhMhxM1DQx5Pe3RgdUSkmXxJnUGr PYYxgP0b/kVSpQ2pDOGqLJqnunv5GXlI+KxwJirjKE6xhK3D5fASQf8gegZYJHbGk1wA 1OntizfA+2C32ITZp9CTrCME5JeA9mnwotb74aHRqa9w0xNi1zEEkfX7Sk2rHNIxJ82r bTnQ== X-Gm-Message-State: ALoCoQnPMGe2RXoYL4C6eWSwh3CKGq89ckDThwG1FMe4iR1QbhfXfUm2bS5ZXxio99RnkBEyIA8A X-Received: by 10.66.227.193 with SMTP id sc1mr20826738pac.102.1398623433648; Sun, 27 Apr 2014 11:30:33 -0700 (PDT) Received: from [10.64.25.6] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id pl10sm29740560pbb.56.2014.04.27.11.30.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Apr 2014 11:30:32 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Looking for FreeBSD u-boot/kernel debugging help (BeagleBone Black) From: Warner Losh In-Reply-To: <1398618296.61646.161.camel@revolution.hippie.lan> Date: Sun, 27 Apr 2014 12:30:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <35FCA9EC-1569-494D-B193-90926D802219@bsdimp.com> References: <20140426233438.49123B827@mail.bitblocks.com> <1398618296.61646.161.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: Bakul Shah , FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 18:37:43 -0000 On Apr 27, 2014, at 11:04 AM, Ian Lepore wrote: > On Sat, 2014-04-26 at 16:34 -0700, Bakul Shah wrote: >> On Sat, 26 Apr 2014 18:29:35 EDT Winston Smith = wrote: >>> I also discovered that if I disconnect = my >>> serial terminal and reconnect it, it seems to bring the FreeBSD = kernel >>> to a debug prompt of sorts -- is there any documentation on this? >>=20 >> I suspect disconnecting/reconnecting the serial cable looks like >> a break to the kernel and that drops it into the debugger "ddb". >> [Though I can't seem to send a real break to it using kermit!] >>=20 >> Type c and hit return to continue.=20 >>=20 >> To disable this behavior I think you can do >> sysctl debug.kbd.break_to_debugger=3D0 >> or add >> debug.kbd.break_to_debugger=3D0 >> to /etc/sysctl.conf >>=20 >> man 1 ddb -- for debugger commands >> man 4 ddb -- for kernel config options to control ddb behavior >=20 > That's exactly correct -- connecting the cable sometimes leads to a > spurious break being asserted on the line (a break is just a long > sequence of zeroes with no start/stop/data bit transitions). >=20 > It's possible to configure a kernel without BREAK_TO_DEBUGGER and with > ALT_BREAK_TO_DEBUGGER. That eliminates most line-noise spurious = breaks > but still allows the ~ ^b break sequence (which could = theoretically > happen in a burst of line noise, but not likely). A few of our = kernels > have BREAK_TO_DEBUGGER in the config, and I think that's probably a > mistake. Most folks these days don't know anything about breaks or = how > to generate one on purpose. =20 >=20 > Any objections to removing them and using only the safer ALT_BREAK > option? Please leave it in the ATMEL config, but I think you can remove it from = the rest (including the specific atmel SoC boards). Warner= From owner-freebsd-arm@FreeBSD.ORG Sun Apr 27 18:52:49 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C7021D9 for ; Sun, 27 Apr 2014 18:52:49 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FCCB158C for ; Sun, 27 Apr 2014 18:52:48 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WeUBu-000D1Q-Do; Sun, 27 Apr 2014 18:52:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3RIqeNK014127; Sun, 27 Apr 2014 12:52:40 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18llEaXpGm/hP7nSXuv0WeR Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Ian Lepore To: Winston Smith In-Reply-To: References: <1398618984.61646.165.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Apr 2014 12:52:39 -0600 Message-ID: <1398624759.61646.174.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 18:52:49 -0000 On Sun, 2014-04-27 at 13:43 -0400, Winston Smith wrote: > On Sun, Apr 27, 2014 at 1:16 PM, Ian Lepore wrote: > > I only have a BBW, no BBB to play with, so I can't help too much with > > this. I can say however that if you're having trouble with reading the > > eMMC in ubldr, the trouble is probably in u-boot. U-boot is still in > > memory when ubldr is running, and it serves as a kind of mini-bios, > > providing access to console, disk, and network IO. > > > > I heard a rumor a while back that Patrick Kelsey had some patches for > > u-boot to fix problems with probing for disk devices. It may be that > > they were only needed for older versions of u-boot, I'm not sure. > > I do have Patrick's fixes for u-boot. Interestingly, the same u-boot > (2013.4 + Patrick's patches) works with 11-CURRENT but not 10-STABLE > -- that's booting from eMMC, there are no issues booting from SD; also > once booted from SD, there is no issues mounting the eMMC and > accessing it (well ... aside from lock reversal warnings and the > occasional sdhc timeout). > > Is there a way to debug this? > Just ignore the LORs, or even better, turn off WITNESS. IMO, it has become useless, because nobody fixes them anymore, or even responds to reports of them other than to sometimes post a link to a site that tracks "known LORs", but that site hasn't been updated for like 6 years. Note that this is just my personal opinion, not the position of the freebsd project in general. When it comes to the eMMC timeouts that happen after you've booted, that's something in my arena, but hard for me to debug without eMMC hardware. We've recently had a few changes to both the core sdhci driver and to the ti_sdhci code that glues sdhci to the hardware. Do the timeouts happen often, or is this something you can do to trigger them? If so, it might be interesting to try to revert r264099 and see if the problems go away. Those changes were related to configuring the sd clock. I'm pretty sure the old code was wrong, but the replacement code could have errors too. :) -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Apr 28 01:10:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D3092DF; Mon, 28 Apr 2014 01:10:35 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0294614B0; Mon, 28 Apr 2014 01:10:34 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id q5so4925706wiv.10 for ; Sun, 27 Apr 2014 18:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3kIUJNe1tdkRnnqAPhiLw0U6Xn2Gg8ogg5nWRpBxZL4=; b=KpKOLVG2RnVorZL6GNcn7CWk01xlmtmXXDtyiWRYuJ89J7gFlHVoDwy+yeoMpBU/Ar vLYDQYTZbQtJVQMW2qsrq3Z8HvOrb2mCj8WTnS51FEaD53K4qkXvqsR6zETqxT2uZOJF 43S/DqDs3IpWvz5jrjdsYNJJtAa7ih3z7H+86b5N7y+XKQ90oUJKcMDsiYb6m+6QYXC2 Xul9BcWPtZeWKpp06MctPZFeZxeTUPjCARnr+k1NP6Ay25BMkJwwlYJYL1H4WSZGT9Xx mCw0h2MsWgy8qY2OpRCOvS8K+3RzEpMHavY9DjE0YIESh/c61ZWFcp4qE+o2VJrYrJv+ /uTg== MIME-Version: 1.0 X-Received: by 10.194.71.164 with SMTP id w4mr16687105wju.0.1398647433290; Sun, 27 Apr 2014 18:10:33 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Sun, 27 Apr 2014 18:10:33 -0700 (PDT) In-Reply-To: <1398624759.61646.174.camel@revolution.hippie.lan> References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> Date: Sun, 27 Apr 2014 21:10:33 -0400 Message-ID: Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 01:10:35 -0000 On Sun, Apr 27, 2014 at 2:52 PM, Ian Lepore wrote: > Just ignore the LORs, or even better, turn off WITNESS. IMO, it has > become useless, because nobody fixes them anymore, or even responds to > reports of them other than to sometimes post a link to a site that > tracks "known LORs", but that site hasn't been updated for like 6 years. That's kind of what I figured; I will turn off WITNESS. > When it comes to the eMMC timeouts that happen after you've booted, > that's something in my arena, but hard for me to debug without eMMC > hardware. We've recently had a few changes to both the core sdhci > driver and to the ti_sdhci code that glues sdhci to the hardware. > > Do the timeouts happen often, or is this something you can do to trigger > them? If so, it might be interesting to try to revert r264099 and see > if the problems go away. Those changes were related to configuring the > sd clock. I'm pretty sure the old code was wrong, but the replacement > code could have errors too. :) At this point: 1) Timeouts (11-CURRENT) - I have seen them twice under heavy eMMC write load, but they haven't seemed to cause a problem for me - Fabio did report the timeouts followed by a panic 2) I can't boot from eMMC with 10-STABLE (but I can with 11-CURRENT) (both using the *same* u-boot) So: A) Should I go back to 11-CURRENT? (although I need 10-something for Golang) B) How can I/we help debug this further? Thanks! -W From owner-freebsd-arm@FreeBSD.ORG Mon Apr 28 01:28:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E41EB445 for ; Mon, 28 Apr 2014 01:28:29 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6E771619 for ; Mon, 28 Apr 2014 01:28:29 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WeaMu-0006Os-Bu; Mon, 28 Apr 2014 01:28:28 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3S1SQPY014329; Sun, 27 Apr 2014 19:28:26 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19m6SdmC3JGH57fxBAlfPrk Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Ian Lepore To: Winston Smith In-Reply-To: References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Apr 2014 19:28:25 -0600 Message-ID: <1398648505.61646.189.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 01:28:30 -0000 On Sun, 2014-04-27 at 21:10 -0400, Winston Smith wrote: > On Sun, Apr 27, 2014 at 2:52 PM, Ian Lepore wrote: > > When it comes to the eMMC timeouts that happen after you've booted, > > that's something in my arena, but hard for me to debug without eMMC > > hardware. We've recently had a few changes to both the core sdhci > > driver and to the ti_sdhci code that glues sdhci to the hardware. > > > > Do the timeouts happen often, or is this something you can do to trigger > > them? If so, it might be interesting to try to revert r264099 and see > > if the problems go away. Those changes were related to configuring the > > sd clock. I'm pretty sure the old code was wrong, but the replacement > > code could have errors too. :) > > At this point: > > 1) Timeouts (11-CURRENT) > - I have seen them twice under heavy eMMC write load, but they > haven't seemed to cause a problem for me > - Fabio did report the timeouts followed by a panic > 2) I can't boot from eMMC with 10-STABLE (but I can with 11-CURRENT) > (both using the *same* u-boot) > > So: > > A) Should I go back to 11-CURRENT? (although I need 10-something for Golang) > B) How can I/we help debug this further? > > Thanks! > If you need 10 we should probably figure out what the problem is there. If the same u-boot works on 11 and fails on 10, then the difference must be in ubldr, and there certainly have been changes there in 11. The quickest way to test that theory would be to build the image for 10 and then hand-copy the ubldr from an 11 build onto that sdcard and see if it works. If so, we can see about merging some ubldr stuff to 10. It may need to go into the msdos partition (I net-boot all my boards). -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Apr 28 02:35:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72DB0E0E; Mon, 28 Apr 2014 02:35:33 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE0051B76; Mon, 28 Apr 2014 02:35:32 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id w7so470935lbi.25 for ; Sun, 27 Apr 2014 19:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k91JYzV8zbkQDnx1b4z4YJR+mey8W4dHBAdE8niUNps=; b=IN1my9n1J/ASeWG9KQn9pIgRv6aNJwFn1R/4Q/fyOKVthT3RyfLbvc6xGAfaMBUqi5 cmDkLRLg79Qdg+15ltvvpg1IMfpWOg4QDmVfM1I7aka9c6GIkIF9/rI2yg1VjMENBlO5 mKHyS9YFq+vnSreUHxb3EMzwapsg7xEKuFOKDU1zJUXzx6RnAvqFYqlYxyQst/6jTePg LxxxURrG3Hs8nR8pIi01SRj7AECOOsn/pk0uBdeKFC57ll4G+AePhijpPIwmQUmwgaoo bFUopw1IxLOvOlq5BCpBjqcQQklu1aobu/N6YNhd37yIQ/hETk+ui9QcQSrjMsKrgfzM wBdg== MIME-Version: 1.0 X-Received: by 10.112.139.166 with SMTP id qz6mr16139162lbb.13.1398652529697; Sun, 27 Apr 2014 19:35:29 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.141.196 with HTTP; Sun, 27 Apr 2014 19:35:29 -0700 (PDT) In-Reply-To: <1398648505.61646.189.camel@revolution.hippie.lan> References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> Date: Sun, 27 Apr 2014 22:35:29 -0400 X-Google-Sender-Auth: Gpy8SUYjLadekh0CGD9XkJntcBc Message-ID: Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Patrick Kelsey To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 02:35:33 -0000 On Sun, Apr 27, 2014 at 9:28 PM, Ian Lepore wrote: > On Sun, 2014-04-27 at 21:10 -0400, Winston Smith wrote: > > On Sun, Apr 27, 2014 at 2:52 PM, Ian Lepore wrote: > > > When it comes to the eMMC timeouts that happen after you've booted, > > > that's something in my arena, but hard for me to debug without eMMC > > > hardware. We've recently had a few changes to both the core sdhci > > > driver and to the ti_sdhci code that glues sdhci to the hardware. > > > > > > Do the timeouts happen often, or is this something you can do to > trigger > > > them? If so, it might be interesting to try to revert r264099 and see > > > if the problems go away. Those changes were related to configuring the > > > sd clock. I'm pretty sure the old code was wrong, but the replacement > > > code could have errors too. :) > > > > At this point: > > > > 1) Timeouts (11-CURRENT) > > - I have seen them twice under heavy eMMC write load, but they > > haven't seemed to cause a problem for me > > - Fabio did report the timeouts followed by a panic > > 2) I can't boot from eMMC with 10-STABLE (but I can with 11-CURRENT) > > (both using the *same* u-boot) > > > > So: > > > > A) Should I go back to 11-CURRENT? (although I need 10-something for > Golang) > > B) How can I/we help debug this further? > > > > Thanks! > > > > If you need 10 we should probably figure out what the problem is there. > If the same u-boot works on 11 and fails on 10, then the difference must > be in ubldr, and there certainly have been changes there in 11. > > The quickest way to test that theory would be to build the image for 10 > and then hand-copy the ubldr from an 11 build onto that sdcard and see > if it works. If so, we can see about merging some ubldr stuff to 10. > It may need to go into the msdos partition (I net-boot all my boards). > The issue with booting from eMMC on 10-STABLE is in ubldr. On 10-STABLE, ubldr is hardwired to boot from the first disk device, which will always be the SD card when using a u-boot that has my mmc device enumeration patches (or an equivalent). The changes that Ian and I made to ubldr would have to be MFC'd to 10-STABLE to get the behavior you want without resorting to copying ubldr built from an 11-CURRENT tree to your device. -Patrick From owner-freebsd-arm@FreeBSD.ORG Mon Apr 28 11:06:44 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 423803C9 for ; Mon, 28 Apr 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1509B1A98 for ; Mon, 28 Apr 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3SB6hst086062 for ; Mon, 28 Apr 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3SB6hwf086060 for freebsd-arm@FreeBSD.org; Mon, 28 Apr 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Apr 2014 11:06:43 GMT Message-Id: <201404281106.s3SB6hwf086060@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 11:06:44 -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/188933 arm lock order reversal: backtrace while writing to SD/eMM o arm/188510 arm [patch] "rtadvctl show" crashes on BeagleBone Black du o arm/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp f arm/184078 arm [xdev] cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o ports/175605 arm devel/binutils: please fix build binutils-2.23.1 in ra 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/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 ports/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) 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 31 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Apr 28 19:40:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AF1CB7B; Mon, 28 Apr 2014 19:40:36 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E23CE17F7; Mon, 28 Apr 2014 19:40:35 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id z2so6308984wiv.6 for ; Mon, 28 Apr 2014 12:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4ce7QWJcOCQMGpRp4aUC1wsKkzhYxZBa9OI8JifJBt4=; b=LGk0/pNQklpKIX3aH+e0gqN/uzF5qsWqRsBs6MDlVTYQMXaz4M/HFSG93c7Wcfu+sB vI7NN2RLh6ugN2m5cbmQy3ft6PSDOAIIPy7ndo7FgRZHeFH4NDT1SVxxMgtfKv8sMD+B GzzJz4DHYenX+B31nH8sHS3XWE+4zxPuC0TnmK1taAVF7Wst+ovdQnbbh1q/0QaQKyrA AHZXrfBX5b4rUJsOcAkH16Eb/6t2m3GBqy27wZRQVrgdcdpsRj6Q3+LRWZVG4CdpfMbQ +lw9EeEbi2fT5f+nDKidju2OGSd3LYSF2UxSlXzMIxyDd/k0pRQzWaBXXa9gl2jSsQac iptA== MIME-Version: 1.0 X-Received: by 10.180.8.136 with SMTP id r8mr16941354wia.60.1398714034191; Mon, 28 Apr 2014 12:40:34 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Mon, 28 Apr 2014 12:40:34 -0700 (PDT) In-Reply-To: References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> Date: Mon, 28 Apr 2014 15:40:34 -0400 Message-ID: Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Winston Smith To: Patrick Kelsey Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 19:40:36 -0000 On Sun, Apr 27, 2014 at 10:35 PM, Patrick Kelsey wrote: > On Sun, Apr 27, 2014 at 9:28 PM, Ian Lepore wrote: >> If you need 10 we should probably figure out what the problem is there. >> If the same u-boot works on 11 and fails on 10, then the difference must >> be in ubldr, and there certainly have been changes there in 11. >> >> The quickest way to test that theory would be to build the image for 10 >> and then hand-copy the ubldr from an 11 build onto that sdcard and see >> if it works. If so, we can see about merging some ubldr stuff to 10. >> It may need to go into the msdos partition (I net-boot all my boards). That works!!! > The issue with booting from eMMC on 10-STABLE is in ubldr. On 10-STABLE, > ubldr is hardwired to boot from the first disk device, which will always be > the SD card when using a u-boot that has my mmc device enumeration patches > (or an equivalent). The changes that Ian and I made to ubldr would have to > be MFC'd to 10-STABLE to get the behavior you want without resorting to > copying ubldr built from an 11-CURRENT tree to your device. I'm not sure what MFC'd means, but yes, could we get this in 10-STABLE? It's my understanding that 11-CURRENT won't be released for quite some time, so presumably fixes of this nature would automatically get backported (MFC'd?) to 10-STABLE? Thanks! From owner-freebsd-arm@FreeBSD.ORG Mon Apr 28 19:44:15 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FBD5CFB for ; Mon, 28 Apr 2014 19:44:15 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5AA21845 for ; Mon, 28 Apr 2014 19:44:14 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WerTD-000M0k-Tw; Mon, 28 Apr 2014 19:44:08 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3SJi4vZ015332; Mon, 28 Apr 2014 13:44:04 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19xR+kG4XYPQ5RGiv90MvqM Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Ian Lepore To: Winston Smith In-Reply-To: References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 2014 13:44:04 -0600 Message-ID: <1398714244.61646.229.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 19:44:15 -0000 On Mon, 2014-04-28 at 15:40 -0400, Winston Smith wrote: > On Sun, Apr 27, 2014 at 10:35 PM, Patrick Kelsey wrote: > > On Sun, Apr 27, 2014 at 9:28 PM, Ian Lepore wrote: > >> If you need 10 we should probably figure out what the problem is there. > >> If the same u-boot works on 11 and fails on 10, then the difference must > >> be in ubldr, and there certainly have been changes there in 11. > >> > >> The quickest way to test that theory would be to build the image for 10 > >> and then hand-copy the ubldr from an 11 build onto that sdcard and see > >> if it works. If so, we can see about merging some ubldr stuff to 10. > >> It may need to go into the msdos partition (I net-boot all my boards). > > That works!!! > > > The issue with booting from eMMC on 10-STABLE is in ubldr. On 10-STABLE, > > ubldr is hardwired to boot from the first disk device, which will always be > > the SD card when using a u-boot that has my mmc device enumeration patches > > (or an equivalent). The changes that Ian and I made to ubldr would have to > > be MFC'd to 10-STABLE to get the behavior you want without resorting to > > copying ubldr built from an 11-CURRENT tree to your device. > > I'm not sure what MFC'd means, but yes, could we get this in 10-STABLE? > > It's my understanding that 11-CURRENT won't be released for quite some > time, so presumably fixes of this nature would automatically get > backported (MFC'd?) to 10-STABLE? > > Thanks! MFC is Merge From Current. Now that you & Patrick have both confirmed that the recent ubldr changes are a good fix, I'll get them merged to 10. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 00:00:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE2C36F1 for ; Tue, 29 Apr 2014 00:00:47 +0000 (UTC) Received: from nm26-vm7.access.bullet.mail.bf1.yahoo.com (nm26-vm7.access.bullet.mail.bf1.yahoo.com [216.109.115.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 966201241 for ; Tue, 29 Apr 2014 00:00:47 +0000 (UTC) Received: from [66.196.81.155] by nm26.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Apr 2014 23:58:12 -0000 Received: from [98.139.221.158] by tm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Apr 2014 23:58:12 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.bf1.yahoo.com with NNFMP; 28 Apr 2014 23:58:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1398729492; bh=Nu1PYbITRcWVMgNXBWtIQPm6YXXUjLK3vGVl7tCdzJk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; b=gDZBrdaF8iK3yqc9RjeCu+c/3E6tWZjaoVLcHftmP36ssckwyymLEHUPjXBCP6XoXCKdE1EgHqyhsnugaL3Xrt38/Xzh3aWchkDyQMaPhvl/XEaTVg6YCp5LlnzUjJrkSS3GYKKOR9aS0zbsG7yw3Ej+DkR2QDDvPtp/RNiNMaQ= X-Yahoo-Newman-Id: 102680.95002.bm@smtp118.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4ajugcgVM1l3ttyMBqHbfpCKS3qztynCTeRDkVlM7jPZi_h rvRKzQrFmZYdiNhM734xysePxfkx5bW1MUBl4C0L5Gz9t_sXxiGNoOPgVIS9 NO1p5xXDZHPWV7SC_SvWGVImmSEEP5xJVr98PQW4_SC4IjlCpy58rK6kOzpW fvwKE6.7eDzJVDY2I7zRGBM3_USJkrr1nCVoHVYTbi6CCHDTuz_unGuvENqm POVPRn1Y_DI.5DKsTDmcvq2LLzuXUHZpZaQMPVMTZ_kGexHZ4K75emBHiC9P ts9wgMrxJB2N5ZAnUuASuDRf7O7miQ2xmf94.hP.xu251vZACpL2cIyuRzSK VlGwp9D9sh1.IbPA4Be2UVyebzsqThW3WL2HxQNLjWUU8BgRy_8CdZK4TG3H 8wT87IBiQHf26YG6zm8Y0U_xtg6_e56TN5MCflcgoyL8hIZjXECP6G0tKO3a Mxram9v3n8Ie.aRjrQgKbLUAGeTdahxxL0LpaTGzB5IAo4gezyXd3iW9lMz6 4cPyvw4zb3H_S_BcnYU2thBvPmWcpVuOuMKNIG.v.0eYxYESuQftzuqg- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.160.145 with plain [98.139.221.42]) by smtp118.sbc.mail.bf1.yahoo.com with SMTP; 28 Apr 2014 23:58:12 +0000 UTC Message-ID: <535EEB12.2050704@sbcglobal.net> Date: Mon, 28 Apr 2014 16:58:10 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm Subject: SMP support for ZEDBOARD Content-Type: multipart/mixed; boundary="------------030108080408000602000508" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 00:00:47 -0000 This is a multi-part message in MIME format. --------------030108080408000602000508 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, All. I continue to test FreeBSD on the Zedboard and SMP seems very solid. Can I get someone to commit SMP support to head (diffs attached)? I also have some bug-fixes too, mainly for the ethernet driver. Should I just file bugs and provide the patches? Thanks, -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net --------------030108080408000602000508 Content-Type: text/plain; charset=UTF-8; name="patch.smp.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch.smp.txt" SW5kZXg6IHN5cy9hcm0veGlsaW54L3p5N19tcC5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIC9kZXYv bnVsbAkyMDE0LTA0LTA5IDA4OjMzOjAwLjAwMDAwMDAwMCAtMDcwMAorKysgc3lzL2FybS94 aWxpbngvenk3X21wLmMJMjAxNC0wNC0wNSAxMToyODoyOS4wMDAwMDAwMDAgLTA3MDAKQEAg LTAsMCArMSw5OCBAQAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTMgVGhvbWFzIFNraWJv LiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNl IGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlm aWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29u ZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2Ug Y29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRo aXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisg KiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhl IGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9u cyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRh dGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1 dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1Ig YGBBUyBJUycnIEFORCBBTlkgRVhQUkVTUyBPUgorICogSU1QTElFRCBXQVJSQU5USUVTLCBJ TkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQgV0FSUkFOVElFUwor ICogT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS UE9TRSBBUkUgRElTQ0xBSU1FRC4KKyAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1Ig QkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwKKyAqIElOQ0lERU5UQUwsIFNQ RUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcs IEJVVAorICogTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09P RFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLAorICogREFUQSwgT1IgUFJPRklUUzsgT1Ig QlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZCisgKiBU SEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklM SVRZLCBPUiBUT1JUCisgKiAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBB UklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YKKyAqIFRISVMgU09GVFdBUkUs IEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCisg Ki8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNEJCIpOwor I2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorI2luY2x1 ZGUgPHN5cy9idXMuaD4KKyNpbmNsdWRlIDxzeXMvbG9jay5oPgorI2luY2x1ZGUgPHN5cy9t dXRleC5oPgorI2luY2x1ZGUgPHN5cy9zbXAuaD4KKworI2luY2x1ZGUgPG1hY2hpbmUvc21w Lmg+CisjaW5jbHVkZSA8bWFjaGluZS9mZHQuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL2ludHIu aD4KKworI2luY2x1ZGUgPGFybS94aWxpbngvenk3X3JlZy5oPgorCisjZGVmaW5lIFpZTlE3 X0NQVTFfRU5UUlkJMHhmZmZmZmZmMAorCit2b2lkCitwbGF0Zm9ybV9tcF9pbml0X3NlY29u ZGFyeSh2b2lkKQoreworCisJZ2ljX2luaXRfc2Vjb25kYXJ5KCk7Cit9CisKK3ZvaWQKK3Bs YXRmb3JtX21wX3NldG1heGlkKHZvaWQpCit7CisKKyAgICAgICAgbXBfbWF4aWQgPSAxOwor fQorCitpbnQKK3BsYXRmb3JtX21wX3Byb2JlKHZvaWQpCit7CisKKwltcF9uY3B1cyA9IDI7 CisJcmV0dXJuICgxKTsKK30KKwordm9pZCAgICAKK3BsYXRmb3JtX21wX3N0YXJ0X2FwKHZv aWQpCit7CisJYnVzX3NwYWNlX2hhbmRsZV90IG9jbV9oYW5kbGU7CisKKwkvKiBNYXAgaW4g bWFnaWMgbG9jYXRpb24gdG8gZ2l2ZSBlbnRyeSBhZGRyZXNzIHRvIENQVTEuICovCisJaWYg KGJ1c19zcGFjZV9tYXAoZmR0YnVzX2JzX3RhZywgWllOUTdfQ1BVMV9FTlRSWSwgNCwKKwkJ CSAgMCwgJm9jbV9oYW5kbGUpICE9IDApCisJCXBhbmljKCJwbGF0Zm9ybV9tcF9zdGFydF9h cDogQ291bGRuJ3QgbWFwIE9DTVxuIik7CisKKwkvKiBXcml0ZSBzdGFydCBhZGRyZXNzIGZv ciBDUFUxLiAqLworCWJ1c19zcGFjZV93cml0ZV80KGZkdGJ1c19ic190YWcsIG9jbV9oYW5k bGUsIDAsCisJCQkgIHBtYXBfa2V4dHJhY3QoKHZtX29mZnNldF90KW1wZW50cnkpKTsKKwor CS8qIFRoZSBTQ1UgaXMgZW5hYmxlZCBieSB0aGUgQk9PVFJPTSBidXQgSSB0aGluayB0aGUg c2Vjb25kIENQVQorCSAqIGRvZXNuJ3QgdHVybiBvbiBmaWx0ZXJpbmcgdW50aWwgYWZ0ZXIg dGhlIHdha2UtdXAgYmVsb3cuCisJICogSSB0aGluayB0aGF0J3Mgd2h5IHRoaW5ncyBkb24n dCB3b3JrIGlmIEkgZG9uJ3QgcHV0IHRoZXNlCisJICogY2FjaGUgb3BzIGhlcmUuICBBbHNv LCB0aGUgbWFnaWMgbG9jYXRpb24sIDB4ZmZmZmZmZjAsIGlzbid0CisJICogaW4gdGhlIFND VSdzIGZpbHRlcmluZyByYW5nZSBzbyBpdCBuZWVkcyBhIHdyaXRlLWJhY2sgdG9vLgorCSAq LworCWNwdV9pZGNhY2hlX3diaW52X2FsbCgpOworCWNwdV9sMmNhY2hlX3diaW52X2FsbCgp OworCisJLyogV2FrZSB1cCBDUFUxLiAqLworCWFybXY3X3NldigpOworCisJYnVzX3NwYWNl X3VubWFwKGZkdGJ1c19ic190YWcsIG9jbV9oYW5kbGUsIDQpOworfQorCit2b2lkCitwbGF0 Zm9ybV9pcGlfc2VuZChjcHVzZXRfdCBjcHVzLCB1X2ludCBpcGkpCit7CisKKwlwaWNfaXBp X3NlbmQoY3B1cywgaXBpKTsKK30KSW5kZXg6IHN5cy9hcm0vY29uZi9aRURCT0FSRAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBzeXMvYXJtL2NvbmYvWkVEQk9BUkQJKHJldmlzaW9uIDI2NDc2NikK KysrIHN5cy9hcm0vY29uZi9aRURCT0FSRAkod29ya2luZyBjb3B5KQpAQCAtNTYsNiArNTYs NyBAQAogb3B0aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HICMgUG9zaXggUDEw MDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMKIG9wdGlvbnMgCUZSRUVCU0RfQk9PVF9MT0FE RVIKIG9wdGlvbnMgCVZGUAkJCSMgdmZwL25lb24KK29wdGlvbnMJCVNNUAkJCSMgU3ltbWV0 cmljIE11bHRpUHJvY2Vzc29yIEtlcm5lbAogCiAjIERlYnVnZ2luZwogbWFrZW9wdGlvbnMJ REVCVUc9LWcKSW5kZXg6IHN5cy9hcm0veGlsaW54L2ZpbGVzLnp5bnE3Cj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHN5cy9hcm0veGlsaW54L2ZpbGVzLnp5bnE3CShyZXZpc2lvbiAyNjQ3NjYpCisr KyBzeXMvYXJtL3hpbGlueC9maWxlcy56eW5xNwkod29ya2luZyBjb3B5KQpAQCAtMjEsNiAr MjEsNyBAQAogYXJtL3hpbGlueC96eTdfYnVzX3NwYWNlLmMJCQlzdGFuZGFyZAogYXJtL3hp bGlueC96eTdfc2xjci5jCQkJCXN0YW5kYXJkCiBhcm0veGlsaW54L3p5N19kZXZjZmcuYwkJ CQlzdGFuZGFyZAorYXJtL3hpbGlueC96eTdfbXAuYwkJCQlvcHRpb25hbCBzbXAKIAogZGV2 L2NhZGVuY2UvaWZfY2dlbS5jCQkJCW9wdGlvbmFsIGlmX2NnZW0KIGRldi9zZGhjaS9zZGhj aV9mZHQuYwkJCQlvcHRpb25hbCBzZGhjaQpJbmRleDogc3lzL2FybS94aWxpbngvc3RkLnp5 bnE3Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9hcm0veGlsaW54L3N0ZC56eW5xNwkocmV2aXNp b24gMjY0NzY2KQorKysgc3lzL2FybS94aWxpbngvc3RkLnp5bnE3CSh3b3JraW5nIGNvcHkp CkBAIC0yMCwzICsyMCw1IEBACiAKIG9wdGlvbnMJCUFSTV9MMl9QSVBUCiAKK29wdGlvbnMJ CUlQSV9JUlFfU1RBUlQ9MAorb3B0aW9ucwkJSVBJX0lSUV9FTkQ9MTUKCg== --------------030108080408000602000508-- From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 00:48:35 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 181F8A60 for ; Tue, 29 Apr 2014 00:48:35 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD1D31746 for ; Tue, 29 Apr 2014 00:48:34 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WewDo-000P7W-8p; Tue, 29 Apr 2014 00:48:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3T0mT4g015574; Mon, 28 Apr 2014 18:48:29 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18uboUbltLe/C4MPsd64bg2 Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Ian Lepore To: Winston Smith In-Reply-To: References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 2014 18:48:28 -0600 Message-ID: <1398732508.61646.245.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 00:48:35 -0000 On Mon, 2014-04-28 at 15:40 -0400, Winston Smith wrote: > On Sun, Apr 27, 2014 at 10:35 PM, Patrick Kelsey wrote: > > On Sun, Apr 27, 2014 at 9:28 PM, Ian Lepore wrote: > >> If you need 10 we should probably figure out what the problem is there. > >> If the same u-boot works on 11 and fails on 10, then the difference must > >> be in ubldr, and there certainly have been changes there in 11. > >> > >> The quickest way to test that theory would be to build the image for 10 > >> and then hand-copy the ubldr from an 11 build onto that sdcard and see > >> if it works. If so, we can see about merging some ubldr stuff to 10. > >> It may need to go into the msdos partition (I net-boot all my boards). > > That works!!! > > > The issue with booting from eMMC on 10-STABLE is in ubldr. On 10-STABLE, > > ubldr is hardwired to boot from the first disk device, which will always be > > the SD card when using a u-boot that has my mmc device enumeration patches > > (or an equivalent). The changes that Ian and I made to ubldr would have to > > be MFC'd to 10-STABLE to get the behavior you want without resorting to > > copying ubldr built from an 11-CURRENT tree to your device. > > I'm not sure what MFC'd means, but yes, could we get this in 10-STABLE? > > It's my understanding that 11-CURRENT won't be released for quite some > time, so presumably fixes of this nature would automatically get > backported (MFC'd?) to 10-STABLE? > > Thanks! Okay, all done. As of r265071 all the recent ubldr changes have been merged to the 10-stable branch and should work to boot eMMC on BBB. Unless I missed something, the ubldr in 10-stable should now be the same as the one in -current. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 03:04:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 753A6676 for ; Tue, 29 Apr 2014 03:04:18 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F06A6658 for ; Tue, 29 Apr 2014 03:04:17 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3T33riS068825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Apr 2014 05:03:53 +0200 (CEST) (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 s3T33lDj026380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 05:03:47 +0200 (CEST) (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 s3T33lcY029962; Tue, 29 Apr 2014 05:03:47 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3T33kQ2029961; Tue, 29 Apr 2014 05:03:46 +0200 (CEST) (envelope-from ticso) Date: Tue, 29 Apr 2014 05:03:46 +0200 From: Bernd Walter To: Thomas Skibo Subject: Re: SMP support for ZEDBOARD Message-ID: <20140429030345.GB28551@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535EEB12.2050704@sbcglobal.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 03:04:18 -0000 On Mon, Apr 28, 2014 at 04:58:10PM -0700, Thomas Skibo wrote: > > Hi, All. > > I continue to test FreeBSD on the Zedboard and SMP seems very solid. Can > I get someone to commit SMP support to head (diffs attached)? > > I also have some bug-fixes too, mainly for the ethernet driver. Should > I just file bugs and provide the patches? Didn't notice that there wasn't SMP on Zedboard yet, but I'm not running it for some time. However I recently received a shipping notice for 2 Parallella Boards, which should reach me soon. And unrelated to Zynq - I got my hands on 2 Radxa Boards based on RK3188 Quad A9 at 1.6GHz. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 04:12:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB2FA5B3 for ; Tue, 29 Apr 2014 04:12:12 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AEA2C4B for ; Tue, 29 Apr 2014 04:12:12 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h18so5666423igc.2 for ; Mon, 28 Apr 2014 21:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RgrrSxcsxuB9nQIFX251hj8PacLcWnIXSRcyYuOA9X4=; b=AscBp82d1DjjPsY505Gugd6L2pLzpHnPUyCLYQoNaJ33PrPE5P2bghfoJx8z2Wp8MM 2u7WNiPs/VJHCMIl1AlhKZFULqu6fIUVI3eZrd6CFxE/mS2i8hPKxmGfT9tH1N/vdRTq vUszm/YoReOyc52ZH5uuwR3+RUjBM3v9Dp51p16nUoYQyk8m0zMP2qgZW+X7DT3yWAsB 0NsHw6stsOKYQSbioSOSJYrN/HshX5+yFKV3/cn9/6v0kSA0+YHRdV6eJAofs1Qa6V87 qkJ2QYVm8okPoiJK6IvwtD4TxDLidV6YdTqwXIG8DmgvXeHkNpoxaI6X99snWX59Ma5/ I8oA== MIME-Version: 1.0 X-Received: by 10.50.141.198 with SMTP id rq6mr27995110igb.38.1398744731906; Mon, 28 Apr 2014 21:12:11 -0700 (PDT) Received: by 10.64.64.5 with HTTP; Mon, 28 Apr 2014 21:12:11 -0700 (PDT) In-Reply-To: <20140429030345.GB28551@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> Date: Tue, 29 Apr 2014 12:12:11 +0800 Message-ID: Subject: Re: SMP support for ZEDBOARD From: Ganbold Tsagaankhuu To: ticso@cicely.de Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , Thomas Skibo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 04:12:12 -0000 On Tue, Apr 29, 2014 at 11:03 AM, Bernd Walter wrote: > On Mon, Apr 28, 2014 at 04:58:10PM -0700, Thomas Skibo wrote: > > > > Hi, All. > > > > I continue to test FreeBSD on the Zedboard and SMP seems very solid. Can > > I get someone to commit SMP support to head (diffs attached)? > > > > I also have some bug-fixes too, mainly for the ethernet driver. Should > > I just file bugs and provide the patches? > > Didn't notice that there wasn't SMP on Zedboard yet, but I'm not > running it for some time. > However I recently received a shipping notice for 2 Parallella Boards, > which should reach me soon. > > And unrelated to Zynq - I got my hands on 2 Radxa Boards based on > RK3188 Quad A9 at 1.6GHz. > That is cool, we need more drivers in case of Radxa board :) Ganbold > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 14:51:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49C11B7A; Tue, 29 Apr 2014 14:51:05 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A92EDE23; Tue, 29 Apr 2014 14:51:04 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id x48so328225wes.35 for ; Tue, 29 Apr 2014 07:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6/glI31A5gVXDLkClk5p1bvHWruPSCXIrZMwrNSoTJ4=; b=pB897RemsbnCZqrsQkh8MM7DdMS+nXEMFFyl1R97n0ihKhhgYjtqQ4ebqXAF7iRoyJ jfHLsIRNQ3L4ye1W2UkSI7Y4pcbxz2bTmh1eR5AQIgYErOrxlYPWuNPDuIvwm2KOTrH9 qjgd9iQkAqeXO2FFAwoIhswGJ35saEQa/rWVYz6ldLExprm5z1kfHPW61BF5HAFJPV3o ydOf7rqXrYTpI2DgJqeJiI/jxWZjFG/vFNiQdtxEqEZzk5ju3ZJChL3s4QX+clyx5V3R uU9aZDOOE7bc4OZQjSWIz5yXfFGuI6Thy/NxvjJt4iBxRs4BxNjeWqTGbrrsvmacNxr/ t7XQ== MIME-Version: 1.0 X-Received: by 10.194.57.38 with SMTP id f6mr2511497wjq.59.1398783063029; Tue, 29 Apr 2014 07:51:03 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Tue, 29 Apr 2014 07:51:02 -0700 (PDT) In-Reply-To: <1398732508.61646.245.camel@revolution.hippie.lan> References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> <1398732508.61646.245.camel@revolution.hippie.lan> Date: Tue, 29 Apr 2014 10:51:02 -0400 Message-ID: Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 14:51:05 -0000 On Mon, Apr 28, 2014 at 8:48 PM, Ian Lepore wrote: > Okay, all done. As of r265071 all the recent ubldr changes have been > merged to the 10-stable branch and should work to boot eMMC on BBB. > Unless I missed something, the ubldr in 10-stable should now be the same > as the one in -current. Hmmm ... 10-STABLE builds and boots from eMMC, but I'm now running into a vm_fault when it tries (and fails) to set up the ethernet PHY: u-boot: Net: not set. Validating first E-fuse MAC Phy not found PHY reset timed out kernel: ... cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq 40,41,42,43 on simplebus0 cpsw0: CPSW SS Version 1.12 (0) cpsw0: Initial queue size TX=128 RX=384 cpsw0: Ethernet address: 90:59:ef:4c:28:d7 cpsw0: Failed to read from PHY. cpsw0: attaching PHYs failed vm_fault(0xc07e2ad0, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc08e2af0 FSR=00000005, FAR=00000018, spsr=80000093 r0 =c27c8680, r1 =00000000, r2 =00000019, r3 =60000193 r4 =00000000, r5 =c27c8680, r6 =00000006, r7 =c053c8a8 r8 =c27c8680, r9 =c281b28c, r10=c28190c8, r11=c08e2b50 r12=00000000, ssp=c08e2b40, slr=c055a590, pc =c038e374 [ thread pid 0 tid 100000 ] Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] db> The full bootlog is below. I'm not entirely sure that this isn't something I've broken myself (I was messing with the beaglebone_black.dts file yesterday!), although I thought I had rebuilt everything properly -- and the same image boots from the SD card. Here's the full log: U-Boot SPL 2013.04 (Apr 29 2014 - 08:26:49) OMAP SD/MMC: 0 mmc_send_cmd : timeout: No status update reading bb-uboot.img reading bb-uboot.img U-Boot 2013.04 (Apr 29 2014 - 08:26:49) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: not set. Validating first E-fuse MAC Phy not found PHY reset timed out cpsw, usb_ether Hit any key to stop autoboot: 0 mmc1(part 0) is current device SD/MMC found on device 1 reading bb-uEnv.txt reading bbubldr 251703 bytes read in 37 ms (6.5 MiB/s) reading bboneblk.dtb 15278 bytes read in 8 ms (1.8 MiB/s) Booting from mmc ... ## Starting application at 0x88000054 ... Consoles: U-Boot console Compatible U-Boot API signature found @9f242240 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@freebsd, Mon Apr 28 22:09:48 EDT 2014) DRAM: 512MB MMC Device 2 not found MMC Device 3 not found MMC Device 2 not found Number of U-Boot devices: 3 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=...MMC Device 2 not found MMC Device 3 not found disk0: device open failed with error=2, handle=1 Checking unit=1 slice= partition=... good. Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x468f08+0x17d8dc syms=[0x4+0x84b30+0x4+0x501f3] /boot/kernel/geom_label.ko text=0x50dc data=0x864+0x30 syms=[0x4+0x1020+0x4+0xfe2] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x0x80000100. Kernel entry at 0x80200100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-STABLE #0 r265072: Mon Apr 28 22:05:57 EDT 2014 root@freebsd:/root/Work/crochet-freebsd/work/obj/arm.armv6/usr/src/FreeBSD-stable-10/sys/BEAGLEBONE arm FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 WARNING: WITNESS option enabled, expect reduced performance. CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 515538944 (491 MB) Texas Instruments AM3358 Processor, Revision ES1.1 random device not loaded; using insecure entropy random: initialized simplebus0: on fdtbus0 aintc0: mem 0x48200000-0x48200fff on simplebus0 aintc0: Revision 5.0 ti_scm0: mem 0x44e10000-0x44e11fff on simplebus0 am335x_prcm0: mem 0x44e00000-0x44e012ff on simplebus0 am335x_prcm0: Clocks: System 24.0 MHz, CPU 550 MHz am335x_dmtimer0: mem 0x44e05000-0x44e05fff,0x44e31000-0x44e31fff,0x48040000-0x48040fff,0x48042000-0x48042fff,0x48044000-0x48044fff,0x48046000-0x48046fff,0x48048000-0x48048fff,0x4804a000-0x4804afff irq 66,67,68,69,92,93,94,95 on simplebus0 Timecounter "AM335x Timecounter" frequency 24000000 Hz quality 1000 Event timer "AM335x Eventtimer0" frequency 24000000 Hz quality 1000 gpio0: mem 0x44e07000-0x44e07fff,0x4804c000-0x4804cfff,0x481ac000-0x481acfff,0x481ae000-0x481aefff irq 96,97,98,99,32,33,62,63 on simplebus0 gpioc0: on gpio0 gpiobus0: on gpio0 uart0: mem 0x44e09000-0x44e09fff irq 72 on simplebus0 uart0: console (115384,n,8,1) ti_edma30: mem 0x49000000-0x490fffff,0x49800000-0x498fffff,0x49900000-0x499fffff,0x49a00000-0x49afffff irq 12,13,14 on simplebus0 ti_edma30: EDMA revision 40014c00 sdhci_ti0: mem 0x48060000-0x48060fff irq 64 on simplebus0 sdhci_ti1: mem 0x481d8000-0x481d8fff irq 28 on simplebus0 mmc0: on sdhci_ti1 cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq 40,41,42,43 on simplebus0 cpsw0: CPSW SS Version 1.12 (0) cpsw0: Initial queue size TX=128 RX=384 cpsw0: Ethernet address: 90:59:ef:4c:28:d7 cpsw0: Failed to read from PHY. cpsw0: attaching PHYs failed vm_fault(0xc07e2ad0, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc08e2af0 FSR=00000005, FAR=00000018, spsr=80000093 r0 =c27c8680, r1 =00000000, r2 =00000019, r3 =60000193 r4 =00000000, r5 =c27c8680, r6 =00000006, r7 =c053c8a8 r8 =c27c8680, r9 =c281b28c, r10=c28190c8, r11=c08e2b50 r12=00000000, ssp=c08e2b40, slr=c055a590, pc =c038e374 [ thread pid 0 tid 100000 ] Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] db> From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 15:22:53 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB467801 for ; Tue, 29 Apr 2014 15:22:53 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B0C9131A for ; Tue, 29 Apr 2014 15:22:53 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wf9rw-0001sE-2O; Tue, 29 Apr 2014 15:22:52 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3TFMmT1016359; Tue, 29 Apr 2014 09:22:48 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+cZdoKGgeZxmnxS91PlniR Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Ian Lepore To: Winston Smith In-Reply-To: References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> <1398732508.61646.245.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 2014 09:22:48 -0600 Message-ID: <1398784968.22079.13.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 15:22:53 -0000 On Tue, 2014-04-29 at 10:51 -0400, Winston Smith wrote: > On Mon, Apr 28, 2014 at 8:48 PM, Ian Lepore wrote: > > Okay, all done. As of r265071 all the recent ubldr changes have been > > merged to the 10-stable branch and should work to boot eMMC on BBB. > > Unless I missed something, the ubldr in 10-stable should now be the same > > as the one in -current. > > Hmmm ... 10-STABLE builds and boots from eMMC, but I'm now running > into a vm_fault when it tries (and fails) to set up the ethernet PHY: > > u-boot: > Net: not set. Validating first E-fuse MAC > Phy not found > PHY reset timed out > > > kernel: > ... > cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff > irq 40,41,42,43 on simplebus0 > cpsw0: CPSW SS Version 1.12 (0) > cpsw0: Initial queue size TX=128 RX=384 > cpsw0: Ethernet address: 90:59:ef:4c:28:d7 > cpsw0: Failed to read from PHY. > cpsw0: attaching PHYs failed > > vm_fault(0xc07e2ad0, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc08e2af0 > FSR=00000005, FAR=00000018, spsr=80000093 > r0 =c27c8680, r1 =00000000, r2 =00000019, r3 =60000193 > r4 =00000000, r5 =c27c8680, r6 =00000006, r7 =c053c8a8 > r8 =c27c8680, r9 =c281b28c, r10=c28190c8, r11=c08e2b50 > r12=00000000, ssp=c08e2b40, slr=c055a590, pc =c038e374 > > [ thread pid 0 tid 100000 ] > Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] > db> > > > > The full bootlog is below. I'm not entirely sure that this isn't > something I've broken myself (I was messing with the > beaglebone_black.dts file yesterday!), although I thought I had > rebuilt everything properly -- and the same image boots from the SD > card. > > Here's the full log: > > > > U-Boot SPL 2013.04 (Apr 29 2014 - 08:26:49) > OMAP SD/MMC: 0 > mmc_send_cmd : timeout: No status update > reading bb-uboot.img > reading bb-uboot.img > > > U-Boot 2013.04 (Apr 29 2014 - 08:26:49) > > I2C: ready > DRAM: 512 MiB > WARNING: Caches not enabled > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Using default environment > > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Peripheral mode controller at 47401000 using PIO, IRQ 0 > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Host mode controller at 47401800 using PIO, IRQ 0 > Net: not set. Validating first E-fuse MAC > Phy not found > PHY reset timed out > cpsw, usb_ether > Hit any key to stop autoboot: 0 > mmc1(part 0) is current device > SD/MMC found on device 1 > reading bb-uEnv.txt > reading bbubldr > 251703 bytes read in 37 ms (6.5 MiB/s) > reading bboneblk.dtb > 15278 bytes read in 8 ms (1.8 MiB/s) > Booting from mmc ... > ## Starting application at 0x88000054 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @9f242240 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@freebsd, Mon Apr 28 22:09:48 EDT 2014) > > DRAM: 512MB > MMC Device 2 not found > MMC Device 3 not found > MMC Device 2 not found > Number of U-Boot devices: 3 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=0 slice= partition=...MMC Device 2 not found > MMC Device 3 not found > disk0: device open failed with error=2, handle=1 > > Checking unit=1 slice= partition=... good. > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x468f08+0x17d8dc syms=[0x4+0x84b30+0x4+0x501f3] > /boot/kernel/geom_label.ko text=0x50dc data=0x864+0x30 > syms=[0x4+0x1020+0x4+0xfe2] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by U-Boot at address 0x0x80000100. This may be the problem -- ubldr's behavior for finding and using dtb files is more complex than it used to be. It may be that it used to claim to find and use the u-boot dtb, but it was really using a static dtb compiled into the kernel. Now if u-boot provides a valid dtb it'll actually get used, even if kernel has a static dtb compiled in. If you remove the u-boot env var 'fdtaddr' then it will fall back to using a compiled-in dtb file instead of a loaded one. What I've been doing these days is installing my dtb files in /boot/modules or /boot/kernel and then setting the dtb file name in a u-boot env var named fdtfile. That makes ubldr find and load the named file in the place it finds the kernel. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 16:06:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDF61427 for ; Tue, 29 Apr 2014 16:06:49 +0000 (UTC) Received: from mail.netsense.nl (pretsense.xs4all.nl [82.161.36.79]) by mx1.freebsd.org (Postfix) with ESMTP id 440A41828 for ; Tue, 29 Apr 2014 16:06:48 +0000 (UTC) Received: (qmail 63166 invoked from network); 29 Apr 2014 18:00:01 +0200 Received: from dhcp62.nest.nl (johan@172.16.79.62) by mail.netsense.nl with AES128-SHA encrypted SMTP; 29 Apr 2014 18:00:01 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_0C708EBA-7D30-4C46-8C5D-4C8672F17683"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.0\)) Subject: Re: SMP support for ZEDBOARD From: Johan Henselmans In-Reply-To: <20140429030345.GB28551@cicely7.cicely.de> Date: Tue, 29 Apr 2014 18:00:04 +0200 Message-Id: <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.1878) Cc: freebsd-arm , Thomas Skibo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 16:06:49 -0000 --Apple-Mail=_0C708EBA-7D30-4C46-8C5D-4C8672F17683 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Apr 2014, at 05:03, Bernd Walter wrote: > On Mon, Apr 28, 2014 at 04:58:10PM -0700, Thomas Skibo wrote: >>=20 >> Hi, All. >>=20 >> I continue to test FreeBSD on the Zedboard and SMP seems very solid. = Can=20 >> I get someone to commit SMP support to head (diffs attached)? >>=20 >> I also have some bug-fixes too, mainly for the ethernet driver. = Should=20 >> I just file bugs and provide the patches? >=20 > Didn't notice that there wasn't SMP on Zedboard yet, but I'm not > running it for some time. > However I recently received a shipping notice for 2 Parallella Boards, > which should reach me soon. >=20 I have received 2 parallella boards too.=20 Would it already be possible to run FreeBSD on the parallella, apart = from the epiphany support? > And unrelated to Zynq - I got my hands on 2 Radxa Boards based on > RK3188 Quad A9 at 1.6GHz. >=20 > --=20 > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Kind Regards, Johan Henselmans http://www.netsense.nl Tel: +31-20-6267538 Fax: +31-20-6279159 --Apple-Mail=_0C708EBA-7D30-4C46-8C5D-4C8672F17683 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFTX8yEWu36PW+dYJQRAsPvAJ9oQ+PokoLDH0qfQjDjOJGqyJI2lgCfWdB8 UuEQY61cuLL6qXWVJKKJ8s0= =lr2D -----END PGP SIGNATURE----- --Apple-Mail=_0C708EBA-7D30-4C46-8C5D-4C8672F17683-- From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 16:43:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD41A9F6 for ; Tue, 29 Apr 2014 16:43:20 +0000 (UTC) Received: from nm20-vm2.access.bullet.mail.bf1.yahoo.com (nm20-vm2.access.bullet.mail.bf1.yahoo.com [216.109.115.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A1E01BCA for ; Tue, 29 Apr 2014 16:43:19 +0000 (UTC) Received: from [66.196.81.160] by nm20.access.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 16:40:57 -0000 Received: from [98.139.244.49] by tm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 16:40:57 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 16:40:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1398789657; bh=29qzuH+xgvPWLDMGpKKAftKDPHCDO/PHgdmH0VeMVSQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=6Xro1VZwvGMdW2H/ejJN3/wXgC85HORY8mwGNK5TChaIX8OQnFmk8ecnL3/Jplvt1JblYTE0VXpe9uWPcBVQPyiu1KCGX5+SuPQMpKwxFLCteUWLVPhGhO7h79UZOxNhzuDeAHHNkSNoZi7H2o9NQ04LjY7bq6R0lF3fT4q92rM= X-Yahoo-Newman-Id: 874356.11175.bm@smtp111.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cbZ7CdgVM1neJ1FgzJhH_Ia.D.OAiKdpssbsV4EdLcxDTFI vSHejr_KtyRlkuyvMGOEDnWM05JKjUJHxU7vFriyqlghT6vv00eo1JG9XSMm _c_bJBH3nVKisKr7yvctfQ5CVKrX056eOzQhxzXh24d4oMwzkr6wyEM_9c55 uZJ.uaRmo1whsRUXrtnHwQHCtGRe9UTXug1bFtlki8jTDH.UwWT27SpCjRFb Ctoe.kS6wzxOZRRmRjdcg7mWR7lnzEf2.lnqR7UhZrf.i0OCrNuiHofP70Mx L3TRdIGp1ZHoqnuHkiry23PfL1AftC2A0umIsKEGJ3_I1sKqWCnD1nvOdy3P fkL6S0anSXWmNO2oVH0FWEB2nhvreSay8t9uXedLrAZR5Q.ocZgkhACdJ6n7 ih8GulWgfQGSnc.IWTWLRSe8Doi3VW4K_tjkwq8ltc9oqcHik_zvkn5xRMxj TYmpA7.JQGri0jaf7EJU9hajS05RI38LfDgIx1XZlytEE2mtymZzHNtU8JMU hO8a16QfEGrhJ6D8tY589UKm8NV5SZsCqd.McWiAS7LjSChc6qQ-- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.160.145 with plain [98.139.221.42]) by smtp111.sbc.mail.bf1.yahoo.com with SMTP; 29 Apr 2014 09:40:57 -0700 PDT Message-ID: <535FD615.6020500@sbcglobal.net> Date: Tue, 29 Apr 2014 09:40:53 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Johan Henselmans , ticso@cicely.de Subject: Re: SMP support for ZEDBOARD References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> In-Reply-To: <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 16:43:20 -0000 My parallella hasn't shipped but I think I'll get it mid-May. It will probably require tweaking their version of u-boot. I'm looking into that. But the Zedboard image with a few modified boot files should work. On 4/29/14, 9:00 AM, Johan Henselmans wrote: > > > I have received 2 parallella boards too. > > Would it already be possible to run FreeBSD on the parallella, apart from the epiphany support? > > -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 16:52:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AA3DE0B for ; Tue, 29 Apr 2014 16:52:29 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E8B551CBB for ; Tue, 29 Apr 2014 16:52:28 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3TGq9el078223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Apr 2014 18:52:10 +0200 (CEST) (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 s3TGprAx033276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 18:51:55 +0200 (CEST) (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 s3TGprhL035109; Tue, 29 Apr 2014 18:51:53 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3TGpr1S035108; Tue, 29 Apr 2014 18:51:53 +0200 (CEST) (envelope-from ticso) Date: Tue, 29 Apr 2014 18:51:53 +0200 From: Bernd Walter To: Johan Henselmans Subject: Re: SMP support for ZEDBOARD Message-ID: <20140429165151.GN28551@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> 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 , ticso@cicely.de, Thomas Skibo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 16:52:29 -0000 On Tue, Apr 29, 2014 at 06:00:04PM +0200, Johan Henselmans wrote: > > On 29 Apr 2014, at 05:03, Bernd Walter wrote: > > > On Mon, Apr 28, 2014 at 04:58:10PM -0700, Thomas Skibo wrote: > >> > >> Hi, All. > >> > >> I continue to test FreeBSD on the Zedboard and SMP seems very solid. Can > >> I get someone to commit SMP support to head (diffs attached)? > >> > >> I also have some bug-fixes too, mainly for the ethernet driver. Should > >> I just file bugs and provide the patches? > > > > Didn't notice that there wasn't SMP on Zedboard yet, but I'm not > > running it for some time. > > However I recently received a shipping notice for 2 Parallella Boards, > > which should reach me soon. > > > > I have received 2 parallella boards too. You already got them - cool. The tracking says my left Frankfurt yesterday - no further entry. Thursday isn't a business day..., so if I don't receive them tomorrow it will take more time. Not sure about customs either - I do have an ATLAS number, which could speed up the process and usually DHL does customs on their own. On the other hand someone in Berlin said that he had to speak with customs for clearance. > Would it already be possible to run FreeBSD on the parallella, apart from the epiphany support? I don' think it is that difficult. The FPGA isn't required to run the A9. Not sure about console ports, crystal setup and RAM. There are surely some minor tunings required for at least u-boot. It could even just work when build for Zedboard, but with 512MB RAM of course - some SDRAM chips are downward compatible to the smaller sized versions. The epyphany and HDMI could be tricky. Both requires loading the FPGA, which is supported under FreeBSD as Thomas wrote before, I never tried myself. AFAIK it uses some kind of DMA buffer and allocates a few MB DRAM for the epiphany - this shouldn't be too difficult either, but needs to be done of course. Porting the userland tools however might be tricky - didn't look into the code, but I wouldn't be surprised if it is full of Linux'ism. But a native GCC build from port won't compile and the epiphany cross compiler is based on GCC. Once I got mine first thing will be to run them a few days under Linux to see if they are technically Ok. Then I will take a look into the board configuration file differences. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 17:07:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42E4D7D5 for ; Tue, 29 Apr 2014 17:07:20 +0000 (UTC) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2DFDE1E63 for ; Tue, 29 Apr 2014 17:07:19 +0000 (UTC) Received: from [IPv6:2601:9:8280:426:68b3:3183:ca30:9368] (unknown [IPv6:2601:9:8280:426:68b3:3183:ca30:9368]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 3449B3986B; Tue, 29 Apr 2014 10:07:19 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: i2c on RPI-B not working From: Rui Paulo In-Reply-To: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> Date: Tue, 29 Apr 2014 10:07:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> References: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:07:20 -0000 On Apr 26, 2014, at 4:14, Mark R V Murray wrote: > Hi * >=20 > The i2b bus on my RPI-B isn=92t working: >=20 > [grapeseed] /usr/src 11:11 am # i2c -sv > dev: /dev/iic0, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1 > Error scanning I2C controller (/dev/iic0): Device not configured > Scanning I2C devices on /dev/iic0: [grapeseed] /usr/src 11:11 am # i2c = -sv -f /dev/iic1 > dev: /dev/iic1, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1 > Error scanning I2C controller (/dev/iic1): Device not configured >=20 > Its a bog-standard build with the RPI-B kernel, and a CURRENT about a = week old. This is because the controller doesn't support scanning. You need to = write your own C program to issue iic ioctls for reading / writing to = the i2c bus. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 17:08:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 549188F7 for ; Tue, 29 Apr 2014 17:08:08 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D99C61E6E for ; Tue, 29 Apr 2014 17:08:07 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3TH84NA078376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Apr 2014 19:08:05 +0200 (CEST) (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 s3TH7xND033410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 19:07:59 +0200 (CEST) (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 s3TH7wad035217; Tue, 29 Apr 2014 19:07:58 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3TH7wdS035216; Tue, 29 Apr 2014 19:07:58 +0200 (CEST) (envelope-from ticso) Date: Tue, 29 Apr 2014 19:07:58 +0200 From: Bernd Walter To: Ganbold Tsagaankhuu Subject: Radxa (was: SMP support for ZEDBOARD) Message-ID: <20140429170757.GR28551@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> 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: "ticso@cicely.de freebsd-arm" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:08:08 -0000 On Tue, Apr 29, 2014 at 12:12:11PM +0800, Ganbold Tsagaankhuu wrote: > On Tue, Apr 29, 2014 at 11:03 AM, Bernd Walter wrote: > > > And unrelated to Zynq - I got my hands on 2 Radxa Boards based on > > RK3188 Quad A9 at 1.6GHz. > > > > > That is cool, we need more drivers in case of Radxa board :) What is missing? I really didn't do anything with those boards yet. Just saw that some claims are made FreeBSD should basicly work at least. My personal interesest are basicly ethernet, cores, SD and seriel console. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 17:28:24 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53C5ED7C for ; Tue, 29 Apr 2014 17:28:24 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28EF0171 for ; Tue, 29 Apr 2014 17:28:23 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WfBpO-000PPx-J9; Tue, 29 Apr 2014 17:28:22 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3THSK4c016465; Tue, 29 Apr 2014 11:28:20 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/JmB3kdcNZUHuiRb6NNmfN Subject: Re: SMP support for ZEDBOARD From: Ian Lepore To: Thomas Skibo In-Reply-To: <535EEB12.2050704@sbcglobal.net> References: <535EEB12.2050704@sbcglobal.net> Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 2014 11:28:19 -0600 Message-ID: <1398792499.22079.18.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:28:24 -0000 On Mon, 2014-04-28 at 16:58 -0700, Thomas Skibo wrote: > Hi, All. > > I continue to test FreeBSD on the Zedboard and SMP seems very solid. Can > I get someone to commit SMP support to head (diffs attached)? > > I also have some bug-fixes too, mainly for the ethernet driver. Should > I just file bugs and provide the patches? > > Thanks, These look good, I'm going to commit them this afternoon. For the ethernet driver, start by just posting the patches here. If I don't get to them within a day or two of posting them, then a PR will help ensure they don't get lost. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 18:34:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E62B31D2 for ; Tue, 29 Apr 2014 18:34:38 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5232BB1C for ; Tue, 29 Apr 2014 18:34:37 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3TIYBOK079605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Apr 2014 20:34:23 +0200 (CEST) (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 s3TIY6W0034245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 20:34:06 +0200 (CEST) (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 s3TIY6uh037779; Tue, 29 Apr 2014 20:34:06 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3TIY5xF037776; Tue, 29 Apr 2014 20:34:05 +0200 (CEST) (envelope-from ticso) Date: Tue, 29 Apr 2014 20:34:05 +0200 From: Bernd Walter To: Thomas Skibo Subject: Re: SMP support for ZEDBOARD Message-ID: <20140429183404.GU28551@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535FD615.6020500@sbcglobal.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 18:34:39 -0000 On Tue, Apr 29, 2014 at 09:40:53AM -0700, Thomas Skibo wrote: > > My parallella hasn't shipped but I think I'll get it mid-May. Backer or preorder? I have a rather high 3k backer number. > It will probably require tweaking their version of u-boot. I'm looking > into that. But the Zedboard image with a few modified boot files should > work. Good to know that you get a parallella as well. I still struggle a lot with all this Linux influence in u-boot. I will never get those Linux thinking... Things had been so much easier without u-boot on RM9200 and Warner did a so clean, nice and understandable bootcode for it. > On 4/29/14, 9:00 AM, Johan Henselmans wrote: > > > > > >I have received 2 parallella boards too. > > > >Would it already be possible to run FreeBSD on the parallella, apart from > >the epiphany support? > > > > > > > -- > -------- > Thomas Skibo > ThomasSkibo@sbcglobal.net > > _______________________________________________ > 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" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 18:47:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AECBD6E7 for ; Tue, 29 Apr 2014 18:47:09 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9F377BD for ; Tue, 29 Apr 2014 18:10:51 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s3TI7uQP024114; Tue, 29 Apr 2014 18:07:56 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s3TI7ut4024113; Tue, 29 Apr 2014 18:07:56 GMT (envelope-from wkoszek) Date: Tue, 29 Apr 2014 18:07:56 +0000 From: "Wojciech A. Koszek" To: Thomas Skibo Subject: Re: SMP support for ZEDBOARD Message-ID: <20140429180756.GP91461@FreeBSD.org> References: <535EEB12.2050704@sbcglobal.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <535EEB12.2050704@sbcglobal.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Tue, 29 Apr 2014 18:08:01 +0000 (UTC) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 18:47:09 -0000 On Mon, Apr 28, 2014 at 04:58:10PM -0700, Thomas Skibo wrote: > > Hi, All. > > I continue to test FreeBSD on the Zedboard and SMP seems very solid. Can > I get someone to commit SMP support to head (diffs attached)? > > I also have some bug-fixes too, mainly for the ethernet driver. Should > I just file bugs and provide the patches? > Thomas This certainly looks good. Small style nit below. > Index: sys/arm/xilinx/zy7_mp.c > =================================================================== > --- /dev/null 2014-04-09 08:33:00.000000000 -0700 > +++ sys/arm/xilinx/zy7_mp.c 2014-04-05 11:28:29.000000000 -0700 > @@ -0,0 +1,98 @@ > +/*- > + * Copyright (c) 2013 Thomas Skibo. All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice, this list of conditions and the following disclaimer in the > + * documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR > + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES > + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. > + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, > + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > +__FBSDID("$FreeBSD$"); You need \n here. > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#include > + > +#define ZYNQ7_CPU1_ENTRY 0xfffffff0 > + > +void > +platform_mp_init_secondary(void) > +{ > + > + gic_init_secondary(); > +} > + > +void > +platform_mp_setmaxid(void) > +{ > + > + mp_maxid = 1; You have spaces here instead of TAB for alignment. > +} > + > +int > +platform_mp_probe(void) > +{ > + > + mp_ncpus = 2; Why does ARM port of FreeBSD need that? Why isn't number of CPUs read from the SCU register? This method sounds redundant (at least across ARM Cortex family) > + return (1); > +} > + > +void > +platform_mp_start_ap(void) > +{ > + bus_space_handle_t ocm_handle; > + > + /* Map in magic location to give entry address to CPU1. */ > + if (bus_space_map(fdtbus_bs_tag, ZYNQ7_CPU1_ENTRY, 4, > + 0, &ocm_handle) != 0) > + panic("platform_mp_start_ap: Couldn't map OCM\n"); > + > + /* Write start address for CPU1. */ > + bus_space_write_4(fdtbus_bs_tag, ocm_handle, 0, > + pmap_kextract((vm_offset_t)mpentry)); > + > + /* The SCU is enabled by the BOOTROM but I think the second CPU You probably need to start comments with: /* * ... (missing \n) > + * doesn't turn on filtering until after the wake-up below. > + * I think that's why things don't work if I don't put these > + * cache ops here. Also, the magic location, 0xfffffff0, isn't > + * in the SCU's filtering range so it needs a write-back too. > + */ > + cpu_idcache_wbinv_all(); > + cpu_l2cache_wbinv_all(); > + > + /* Wake up CPU1. */ > + armv7_sev(); > + > + bus_space_unmap(fdtbus_bs_tag, ocm_handle, 4); > +} > + > +void > +platform_ipi_send(cpuset_t cpus, u_int ipi) > +{ > + > + pic_ipi_send(cpus, ipi); > +} > Index: sys/arm/conf/ZEDBOARD > =================================================================== > --- sys/arm/conf/ZEDBOARD (revision 264766) > +++ sys/arm/conf/ZEDBOARD (working copy) > @@ -56,6 +56,7 @@ > options _KPOSIX_PRIORITY_SCHEDULING # Posix P1003_1B real-time extensions > options FREEBSD_BOOT_LOADER > options VFP # vfp/neon > +options SMP # Symmetric MultiProcessor Kernel I think we have \t\t instead of just \t here. > > # Debugging > makeoptions DEBUG=-g > Index: sys/arm/xilinx/files.zynq7 > =================================================================== > --- sys/arm/xilinx/files.zynq7 (revision 264766) > +++ sys/arm/xilinx/files.zynq7 (working copy) > @@ -21,6 +21,7 @@ > arm/xilinx/zy7_bus_space.c standard > arm/xilinx/zy7_slcr.c standard > arm/xilinx/zy7_devcfg.c standard > +arm/xilinx/zy7_mp.c optional smp > > dev/cadence/if_cgem.c optional if_cgem > dev/sdhci/sdhci_fdt.c optional sdhci > Index: sys/arm/xilinx/std.zynq7 > =================================================================== > --- sys/arm/xilinx/std.zynq7 (revision 264766) > +++ sys/arm/xilinx/std.zynq7 (working copy) > @@ -20,3 +20,5 @@ > > options ARM_L2_PIPT > > +options IPI_IRQ_START=0 > +options IPI_IRQ_END=15 > Run with older U-Boot, does it just work? -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 19:02:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A63FBD7; Tue, 29 Apr 2014 19:02:46 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9036EDB0; Tue, 29 Apr 2014 19:02:45 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id u57so663116wes.31 for ; Tue, 29 Apr 2014 12:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L+RBD4aU9pidEeGAYpqM7xCtlFkBZo8dC7oYPEUI+ig=; b=zguqMcmJXRKhis2MUCArJ+A8bbcclVlptNFGUryJurn6Y+uigAi4rstgS9F1K9TDaw d1pH1PqAbh2zzuW1ZgnwGAE8qsX0RTPv/GvKeFqLtlsC+LYLu+MjVOKiTLVzuclpFRpc XqVT6Bc6TGA/HPrRVr5kcfpG0cRBaQtIWCcQhmPldyfuNJDVLxksugRB30PtfEKDVQWV fbk587cm15qqsF+23B7wp9/lh1hyFphuOQxfurer4SoLpLu2DJ7NkAImD5BqlyWDPDVI sDUD6kOVgUy8yBv42T42mEerGO5mplyfVTFmzrHFv3hEvEdAUROsH/RgNO8BsjoDQzty VzTA== MIME-Version: 1.0 X-Received: by 10.180.228.42 with SMTP id sf10mr21864177wic.33.1398798163966; Tue, 29 Apr 2014 12:02:43 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Tue, 29 Apr 2014 12:02:43 -0700 (PDT) In-Reply-To: <1398784968.22079.13.camel@revolution.hippie.lan> References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> <1398732508.61646.245.camel@revolution.hippie.lan> <1398784968.22079.13.camel@revolution.hippie.lan> Date: Tue, 29 Apr 2014 15:02:43 -0400 Message-ID: Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 19:02:46 -0000 On Tue, Apr 29, 2014 at 11:22 AM, Ian Lepore wrote: > This may be the problem -- ubldr's behavior for finding and using dtb > files is more complex than it used to be. It may be that it used to > claim to find and use the u-boot dtb, but it was really using a static > dtb compiled into the kernel. Now if u-boot provides a valid dtb it'll > actually get used, even if kernel has a static dtb compiled in. After more testing, it appears the eMMC was somehow corrupted. I initially used Tim's copy-to-emmc.sh script to set up the eMMC -- I got a couple of lock reversal errors (still haven't figured out how to disable WITNESS via the make cmd line) and saw this issue. I then rewrote the img to /dev/mmcsd1 and it was able to bring up the eMMC. I tried Tim's script again and this time didn't get lock reversal errors and it's also able to boot from eMMC. So I don't know if there was some corruption ... I'll keep testing. But anyway, I can now boot 10-STABLE from eMMC. Thanks! -W From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 19:05:17 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4609C43; Tue, 29 Apr 2014 19:05:17 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6581ADC5; Tue, 29 Apr 2014 19:05:16 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WfDL9-000BmG-Jm; Tue, 29 Apr 2014 19:05:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3TJ5D5r016623; Tue, 29 Apr 2014 13:05:13 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/oJxB89zhySry6Xr4wy8ei Subject: Re: SMP support for ZEDBOARD From: Ian Lepore To: "Wojciech A. Koszek" In-Reply-To: <20140429180756.GP91461@FreeBSD.org> References: <535EEB12.2050704@sbcglobal.net> <20140429180756.GP91461@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 2014 13:05:13 -0600 Message-ID: <1398798313.22079.31.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 , Thomas Skibo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 19:05:17 -0000 On Tue, 2014-04-29 at 18:07 +0000, Wojciech A. Koszek wrote: > On Mon, Apr 28, 2014 at 04:58:10PM -0700, Thomas Skibo wrote: > > > > Hi, All. > > > > I continue to test FreeBSD on the Zedboard and SMP seems very solid. Can > > I get someone to commit SMP support to head (diffs attached)? > > > > I also have some bug-fixes too, mainly for the ethernet driver. Should > > I just file bugs and provide the patches? > > > > Thomas > > This certainly looks good. Small style nit below. > > > Index: sys/arm/xilinx/zy7_mp.c > > =================================================================== > > --- /dev/null 2014-04-09 08:33:00.000000000 -0700 > > +++ sys/arm/xilinx/zy7_mp.c 2014-04-05 11:28:29.000000000 -0700 > > @@ -0,0 +1,98 @@ > > +/*- > > + * Copyright (c) 2013 Thomas Skibo. All rights reserved. > > + * > > + * Redistribution and use in source and binary forms, with or without > > + * modification, are permitted provided that the following conditions > > + * are met: > > + * 1. Redistributions of source code must retain the above copyright > > + * notice, this list of conditions and the following disclaimer. > > + * 2. Redistributions in binary form must reproduce the above copyright > > + * notice, this list of conditions and the following disclaimer in the > > + * documentation and/or other materials provided with the distribution. > > + * > > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR > > + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES > > + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. > > + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, > > + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > > + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > > + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > + */ > > + > > +#include > > +__FBSDID("$FreeBSD$"); > > You need \n here. > > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > + > > +#include > > + > > +#define ZYNQ7_CPU1_ENTRY 0xfffffff0 > > + > > +void > > +platform_mp_init_secondary(void) > > +{ > > + > > + gic_init_secondary(); > > +} > > + > > +void > > +platform_mp_setmaxid(void) > > +{ > > + > > + mp_maxid = 1; > > You have spaces here instead of TAB for alignment. > > > +} > > + > > +int > > +platform_mp_probe(void) > > +{ > > + > > + mp_ncpus = 2; > > Why does ARM port of FreeBSD need that? Why isn't number of CPUs read from > the SCU register? This method sounds redundant (at least across ARM Cortex > family) > > > + return (1); > > +} > > + > > +void > > +platform_mp_start_ap(void) > > +{ > > + bus_space_handle_t ocm_handle; > > + > > + /* Map in magic location to give entry address to CPU1. */ > > + if (bus_space_map(fdtbus_bs_tag, ZYNQ7_CPU1_ENTRY, 4, > > + 0, &ocm_handle) != 0) > > + panic("platform_mp_start_ap: Couldn't map OCM\n"); > > + > > + /* Write start address for CPU1. */ > > + bus_space_write_4(fdtbus_bs_tag, ocm_handle, 0, > > + pmap_kextract((vm_offset_t)mpentry)); > > + > > + /* The SCU is enabled by the BOOTROM but I think the second CPU > > You probably need to start comments with: > > /* > * ... > > (missing \n) > > > + * doesn't turn on filtering until after the wake-up below. > > + * I think that's why things don't work if I don't put these > > + * cache ops here. Also, the magic location, 0xfffffff0, isn't > > + * in the SCU's filtering range so it needs a write-back too. > > + */ > > + cpu_idcache_wbinv_all(); > > + cpu_l2cache_wbinv_all(); > > + > > + /* Wake up CPU1. */ > > + armv7_sev(); > > + > > + bus_space_unmap(fdtbus_bs_tag, ocm_handle, 4); > > +} > > + > > +void > > +platform_ipi_send(cpuset_t cpus, u_int ipi) > > +{ > > + > > + pic_ipi_send(cpus, ipi); > > +} > > Index: sys/arm/conf/ZEDBOARD > > =================================================================== > > --- sys/arm/conf/ZEDBOARD (revision 264766) > > +++ sys/arm/conf/ZEDBOARD (working copy) > > @@ -56,6 +56,7 @@ > > options _KPOSIX_PRIORITY_SCHEDULING # Posix P1003_1B real-time extensions > > options FREEBSD_BOOT_LOADER > > options VFP # vfp/neon > > +options SMP # Symmetric MultiProcessor Kernel > > I think we have \t\t instead of just \t here. > > > > > # Debugging > > makeoptions DEBUG=-g > > Index: sys/arm/xilinx/files.zynq7 > > =================================================================== > > --- sys/arm/xilinx/files.zynq7 (revision 264766) > > +++ sys/arm/xilinx/files.zynq7 (working copy) > > @@ -21,6 +21,7 @@ > > arm/xilinx/zy7_bus_space.c standard > > arm/xilinx/zy7_slcr.c standard > > arm/xilinx/zy7_devcfg.c standard > > +arm/xilinx/zy7_mp.c optional smp > > > > dev/cadence/if_cgem.c optional if_cgem > > dev/sdhci/sdhci_fdt.c optional sdhci > > Index: sys/arm/xilinx/std.zynq7 > > =================================================================== > > --- sys/arm/xilinx/std.zynq7 (revision 264766) > > +++ sys/arm/xilinx/std.zynq7 (working copy) > > @@ -20,3 +20,5 @@ > > > > options ARM_L2_PIPT > > > > +options IPI_IRQ_START=0 > > +options IPI_IRQ_END=15 > > > > Run with older U-Boot, does it just work? > I tidied up the whitespace nits you noted when I did the commit. About the platform_mp_probe() and multicore startup code in general, I've been thinking we should have generic armv7/mpcore code for doing almost everything except the actual launching of the AP cores, which does tend to be wildly different amongst the various SoCs. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 19:09:38 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40F18D0C for ; Tue, 29 Apr 2014 19:09:38 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13191E06 for ; Tue, 29 Apr 2014 19:09:37 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WfDPM-0007Go-LK; Tue, 29 Apr 2014 19:09:36 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3TJ9YI6016629; Tue, 29 Apr 2014 13:09:34 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/PnAPlyl/JpCXGlVNxLTRQ Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Ian Lepore To: Winston Smith In-Reply-To: References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> <1398732508.61646.245.camel@revolution.hippie.lan> <1398784968.22079.13.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 2014 13:09:34 -0600 Message-ID: <1398798574.22079.34.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 19:09:38 -0000 On Tue, 2014-04-29 at 15:02 -0400, Winston Smith wrote: > On Tue, Apr 29, 2014 at 11:22 AM, Ian Lepore wrote: > > This may be the problem -- ubldr's behavior for finding and using dtb > > files is more complex than it used to be. It may be that it used to > > claim to find and use the u-boot dtb, but it was really using a static > > dtb compiled into the kernel. Now if u-boot provides a valid dtb it'll > > actually get used, even if kernel has a static dtb compiled in. > > After more testing, it appears the eMMC was somehow corrupted. I > initially used Tim's copy-to-emmc.sh script to set up the eMMC -- I > got a couple of lock reversal errors (still haven't figured out how to > disable WITNESS via the make cmd line) and saw this issue. > > I then rewrote the img to /dev/mmcsd1 and it was able to bring up the > eMMC. I tried Tim's script again and this time didn't get lock > reversal errors and it's also able to boot from eMMC. > > So I don't know if there was some corruption ... I'll keep testing. > > But anyway, I can now boot 10-STABLE from eMMC. > > Thanks! > You can't disable WITNESS from the command line, but it should be off by default in the stable branches. In general if there's anything you need to change about a kernel config, you create your own config that includes the standard one and makes changes, like: include BEAGLEBONE nooption WITNESS nodevice usb # and so on -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 20:21:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF31D8F0 for ; Tue, 29 Apr 2014 20:21:21 +0000 (UTC) Received: from nm20.access.bullet.mail.bf1.yahoo.com (nm20.access.bullet.mail.bf1.yahoo.com [216.109.114.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B1DE158B for ; Tue, 29 Apr 2014 20:21:21 +0000 (UTC) Received: from [66.196.81.163] by nm20.access.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 20:21:12 -0000 Received: from [98.139.244.53] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 20:21:12 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 20:21:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1398802872; bh=evXbsSsT7Aq/ahSRkUo4J+jrqnylnCA4CXDmfH6z0lA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ig5lViJiQLNSrN8QDb33+gpBAPYkkXoVYHXFjbAc5GbTfyyEako/s2IakJu8qMABJl5/8o05HGvkoyD+duRurVz0355hbOh0kgM/005FpuQwr/BFyCdx/8WrXc16xU+IflqQwrCC4kDlFK/iAcdGY9a6Gfzvx2ZrC0t63fyeFhk= X-Yahoo-Newman-Id: 872751.76653.bm@smtp115.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: axSBdggVM1kd4Bbbw9C4l.56mMZjFuwJyRxkiwucZkaDrkV aM0xxDm4GVvyyLz6O_8o_HlFJV_z0cksvRdVc8FzRc9vitkiZb43ghGlYJ8i 7qqaQAQhVh3E3_95Bp0MrhvDWOVggx_EMazPm8j7jn0lNkicVzUd2xJmn..g LxqXVCMAfH5c27vP7fUGobcXcfTWFP3C5HrJ5wLSUOH.RSEADOSaVhLCkgxM dNq..wodlx8LwvQFMOAArRZGz8mfODsXuXEcVtP62Pz0ZK9oCNc7o2VMFyTg deT4VY6l8yKNFLOWKROA5evRHUMo1.u17BnCepv.40qLQEP8k4nc6syGrNWh bbfv.TNF6YGrq3FGl.qePijMHgphLzoOxZVGer_TbTIo39gVc77CrZ90hc2r mBj2h3V7tTpzkaNAz4gz1.pRSuaGqCvq5BGsoA48ZNfSOCfGv8L5d17X.AKK NiQ8SyuzZ4RaLfVC2we4qS1oSPNO0r_2VvbvSmidjWxoazzv.TfqbYveRCju qb2CrCfaRzRuf6LUxFmj_SxP39z0xlBMiCB0yZHVshxuSiVeephUj704- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.160.145 with plain [98.139.221.42]) by smtp115.sbc.mail.bf1.yahoo.com with SMTP; 29 Apr 2014 13:21:12 -0700 PDT Message-ID: <536009B1.6040503@sbcglobal.net> Date: Tue, 29 Apr 2014 13:21:05 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ticso@cicely.de Subject: Re: SMP support for ZEDBOARD References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> In-Reply-To: <20140429183404.GU28551@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 20:21:21 -0000 On 4/29/14, 11:34 AM, Bernd Walter wrote: > On Tue, Apr 29, 2014 at 09:40:53AM -0700, Thomas Skibo wrote: >> >> My parallella hasn't shipped but I think I'll get it mid-May. > > Backer or preorder? > I have a rather high 3k backer number. Preorder #2081. Mine is a 7010 and for some reason I think they are going out later than 7020's. >> It will probably require tweaking their version of u-boot. I'm looking >> into that. But the Zedboard image with a few modified boot files should >> work. > > Good to know that you get a parallella as well. > I still struggle a lot with all this Linux influence in u-boot. > I will never get those Linux thinking... > Things had been so much easier without u-boot on RM9200 and Warner > did a so clean, nice and understandable bootcode for it. > I looked at their u-boot code and they don't have the CONFIG_API flag necessary for ubldr to work. I also didn't realize that the Parallella must boot FSBL/u-boot from the QSPI flash. I hate to require reprogramming the QSPI flash and risk bricking the board. -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 20:58:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E8479AB for ; Tue, 29 Apr 2014 20:58:22 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C99EC18C9 for ; Tue, 29 Apr 2014 20:58:21 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3TKvwTw080926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Apr 2014 22:57:59 +0200 (CEST) (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 s3TKvgf4035414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 22:57:43 +0200 (CEST) (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 s3TKvgdB039821; Tue, 29 Apr 2014 22:57:42 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3TKvfIh039820; Tue, 29 Apr 2014 22:57:41 +0200 (CEST) (envelope-from ticso) Date: Tue, 29 Apr 2014 22:57:41 +0200 From: Bernd Walter To: Thomas Skibo Subject: Re: SMP support for ZEDBOARD Message-ID: <20140429205740.GE39364@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> <536009B1.6040503@sbcglobal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536009B1.6040503@sbcglobal.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 20:58:22 -0000 On Tue, Apr 29, 2014 at 01:21:05PM -0700, Thomas Skibo wrote: > > > On 4/29/14, 11:34 AM, Bernd Walter wrote: > >On Tue, Apr 29, 2014 at 09:40:53AM -0700, Thomas Skibo wrote: > >> > >>My parallella hasn't shipped but I think I'll get it mid-May. > > > >Backer or preorder? > >I have a rather high 3k backer number. > > Preorder #2081. Mine is a 7010 and for some reason I think they are > going out later than 7020's. Yes - they likely will :-( They produced 7020 for the backers and I think there are also some or all for preorders, but I didn't hear anything about 7010 in production yet. > >>It will probably require tweaking their version of u-boot. I'm looking > >>into that. But the Zedboard image with a few modified boot files should > >>work. > > > >Good to know that you get a parallella as well. > >I still struggle a lot with all this Linux influence in u-boot. > >I will never get those Linux thinking... > >Things had been so much easier without u-boot on RM9200 and Warner > >did a so clean, nice and understandable bootcode for it. > > > > I looked at their u-boot code and they don't have the CONFIG_API flag > necessary for ubldr to work. > > I also didn't realize that the Parallella must boot FSBL/u-boot from the > QSPI flash. I hate to require reprogramming the QSPI flash and risk > bricking the board. Oh - interesting. I thought it is just booting from SD and assumed we can use what you did for the Zedboard to begin with. Wonder why they added a flash chip, when they could have gone without. Is this a pin strapping configuration, or something, which can be changed? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 21:03:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67B0CA64 for ; Tue, 29 Apr 2014 21:03:48 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EE58C195F for ; Tue, 29 Apr 2014 21:03:47 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3TL3jc7080968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Apr 2014 23:03:45 +0200 (CEST) (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 s3TL3YwS035476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 23:03:34 +0200 (CEST) (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 s3TL3YGK039866; Tue, 29 Apr 2014 23:03:34 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3TL3Ys2039865; Tue, 29 Apr 2014 23:03:34 +0200 (CEST) (envelope-from ticso) Date: Tue, 29 Apr 2014 23:03:34 +0200 From: Bernd Walter To: Thomas Skibo Subject: Re: SMP support for ZEDBOARD Message-ID: <20140429210334.GF39364@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> <536009B1.6040503@sbcglobal.net> <20140429205740.GE39364@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140429205740.GE39364@cicely7.cicely.de> 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 , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:03:48 -0000 On Tue, Apr 29, 2014 at 10:57:41PM +0200, Bernd Walter wrote: > On Tue, Apr 29, 2014 at 01:21:05PM -0700, Thomas Skibo wrote: > > > > > > On 4/29/14, 11:34 AM, Bernd Walter wrote: > > >On Tue, Apr 29, 2014 at 09:40:53AM -0700, Thomas Skibo wrote: > > >> > > >>My parallella hasn't shipped but I think I'll get it mid-May. > > > > > >Backer or preorder? > > >I have a rather high 3k backer number. > > > > Preorder #2081. Mine is a 7010 and for some reason I think they are > > going out later than 7020's. > > Yes - they likely will :-( > They produced 7020 for the backers and I think there are also some > or all for preorders, but I didn't hear anything about 7010 in production > yet. > > > >>It will probably require tweaking their version of u-boot. I'm looking > > >>into that. But the Zedboard image with a few modified boot files should > > >>work. > > > > > >Good to know that you get a parallella as well. > > >I still struggle a lot with all this Linux influence in u-boot. > > >I will never get those Linux thinking... > > >Things had been so much easier without u-boot on RM9200 and Warner > > >did a so clean, nice and understandable bootcode for it. > > > > > > > I looked at their u-boot code and they don't have the CONFIG_API flag > > necessary for ubldr to work. > > > > I also didn't realize that the Parallella must boot FSBL/u-boot from the > > QSPI flash. I hate to require reprogramming the QSPI flash and risk > > bricking the board. > > Oh - interesting. > I thought it is just booting from SD and assumed we can use what you > did for the Zedboard to begin with. > Wonder why they added a flash chip, when they could have gone without. > Is this a pin strapping configuration, or something, which can be > changed? Mmm - ok they have an QSPI Micro Flash in their BOM. Currently printing the schematics. But my Zedboard also has SPI memory - Spansion S25FL256S. Don't know how it is used - didn't care about until now. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 21:19:02 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECBCCCC0 for ; Tue, 29 Apr 2014 21:19:01 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE3911AAB for ; Tue, 29 Apr 2014 21:19:01 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WfFQU-0002KO-G2; Tue, 29 Apr 2014 21:18:54 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3TLIphJ016747; Tue, 29 Apr 2014 15:18:51 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19wsmaFCoXo9ufZ8OgcgpTl Subject: Re: SMP support for ZEDBOARD From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20140429210334.GF39364@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> <536009B1.6040503@sbcglobal.net> <20140429205740.GE39364@cicely7.cicely.de> <20140429210334.GF39364@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 2014 15:18:51 -0600 Message-ID: <1398806331.22079.40.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 , Thomas Skibo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:19:02 -0000 On Tue, 2014-04-29 at 23:03 +0200, Bernd Walter wrote: > On Tue, Apr 29, 2014 at 10:57:41PM +0200, Bernd Walter wrote: > > On Tue, Apr 29, 2014 at 01:21:05PM -0700, Thomas Skibo wrote: > > > > > > > > > On 4/29/14, 11:34 AM, Bernd Walter wrote: > > > >On Tue, Apr 29, 2014 at 09:40:53AM -0700, Thomas Skibo wrote: > > > >> > > > >>My parallella hasn't shipped but I think I'll get it mid-May. > > > > > > > >Backer or preorder? > > > >I have a rather high 3k backer number. > > > > > > Preorder #2081. Mine is a 7010 and for some reason I think they are > > > going out later than 7020's. > > > > Yes - they likely will :-( > > They produced 7020 for the backers and I think there are also some > > or all for preorders, but I didn't hear anything about 7010 in production > > yet. > > > > > >>It will probably require tweaking their version of u-boot. I'm looking > > > >>into that. But the Zedboard image with a few modified boot files should > > > >>work. > > > > > > > >Good to know that you get a parallella as well. > > > >I still struggle a lot with all this Linux influence in u-boot. > > > >I will never get those Linux thinking... > > > >Things had been so much easier without u-boot on RM9200 and Warner > > > >did a so clean, nice and understandable bootcode for it. > > > > > > > > > > I looked at their u-boot code and they don't have the CONFIG_API flag > > > necessary for ubldr to work. > > > > > > I also didn't realize that the Parallella must boot FSBL/u-boot from the > > > QSPI flash. I hate to require reprogramming the QSPI flash and risk > > > bricking the board. > > > > Oh - interesting. > > I thought it is just booting from SD and assumed we can use what you > > did for the Zedboard to begin with. > > Wonder why they added a flash chip, when they could have gone without. > > Is this a pin strapping configuration, or something, which can be > > changed? > > Mmm - ok they have an QSPI Micro Flash in their BOM. > Currently printing the schematics. > > But my Zedboard also has SPI memory - Spansion S25FL256S. > Don't know how it is used - didn't care about until now. > I wonder if a chain-loader is possible? Have the u-boot in flash load a better u-boot from sdcard that has API and other goodies. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 21:20:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9305FD3D for ; Tue, 29 Apr 2014 21:20:25 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F79C1B2A for ; Tue, 29 Apr 2014 21:20:24 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3TLKMw9081084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Apr 2014 23:20:23 +0200 (CEST) (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 s3TLKEM9035611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 23:20:14 +0200 (CEST) (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 s3TLKDAn039929; Tue, 29 Apr 2014 23:20:13 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3TLKDoQ039928; Tue, 29 Apr 2014 23:20:13 +0200 (CEST) (envelope-from ticso) Date: Tue, 29 Apr 2014 23:20:13 +0200 From: Bernd Walter To: Thomas Skibo Subject: Re: SMP support for ZEDBOARD Message-ID: <20140429212013.GG39364@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> <536009B1.6040503@sbcglobal.net> <20140429205740.GE39364@cicely7.cicely.de> <20140429210334.GF39364@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140429210334.GF39364@cicely7.cicely.de> 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 , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:20:25 -0000 On Tue, Apr 29, 2014 at 11:03:34PM +0200, Bernd Walter wrote: > On Tue, Apr 29, 2014 at 10:57:41PM +0200, Bernd Walter wrote: > > On Tue, Apr 29, 2014 at 01:21:05PM -0700, Thomas Skibo wrote: > > > > > > > > > On 4/29/14, 11:34 AM, Bernd Walter wrote: > > > >On Tue, Apr 29, 2014 at 09:40:53AM -0700, Thomas Skibo wrote: > > > >> > > > >>My parallella hasn't shipped but I think I'll get it mid-May. > > > > > > > >Backer or preorder? > > > >I have a rather high 3k backer number. > > > > > > Preorder #2081. Mine is a 7010 and for some reason I think they are > > > going out later than 7020's. > > > > Yes - they likely will :-( > > They produced 7020 for the backers and I think there are also some > > or all for preorders, but I didn't hear anything about 7010 in production > > yet. > > > > > >>It will probably require tweaking their version of u-boot. I'm looking > > > >>into that. But the Zedboard image with a few modified boot files should > > > >>work. > > > > > > > >Good to know that you get a parallella as well. > > > >I still struggle a lot with all this Linux influence in u-boot. > > > >I will never get those Linux thinking... > > > >Things had been so much easier without u-boot on RM9200 and Warner > > > >did a so clean, nice and understandable bootcode for it. > > > > > > > > > > I looked at their u-boot code and they don't have the CONFIG_API flag > > > necessary for ubldr to work. > > > > > > I also didn't realize that the Parallella must boot FSBL/u-boot from the > > > QSPI flash. I hate to require reprogramming the QSPI flash and risk > > > bricking the board. > > > > Oh - interesting. > > I thought it is just booting from SD and assumed we can use what you > > did for the Zedboard to begin with. > > Wonder why they added a flash chip, when they could have gone without. > > Is this a pin strapping configuration, or something, which can be > > changed? > > Mmm - ok they have an QSPI Micro Flash in their BOM. > Currently printing the schematics. > > But my Zedboard also has SPI memory - Spansion S25FL256S. > Don't know how it is used - didn't care about until now. Did I get it right, that the ROMcode loades the FSBL from either JTAG or flash. The FSBL then could load u-boot from whatever it supports, but on the parallella they load u-boot from QSPI, so it has to be updated? I do have a JTAG available, according to the parallella schematics however it is setup via solder pull-up vs pull-down resistor. I also have a hot air soldering station, but still not nice. I also would have to lock up where the JTAG is - probably on one of the Samtec connectors :-( -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 21:25:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC628DFC for ; Tue, 29 Apr 2014 21:25:52 +0000 (UTC) Received: from nm9-vm7.access.bullet.mail.bf1.yahoo.com (nm9-vm7.access.bullet.mail.bf1.yahoo.com [216.109.114.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A7E51B94 for ; Tue, 29 Apr 2014 21:25:52 +0000 (UTC) Received: from [66.196.81.163] by nm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 21:22:56 -0000 Received: from [98.139.244.53] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 21:22:56 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 21:22:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1398806576; bh=/H8zfKg59AFgbWABX8x+kC3ohNFFswMTsEdipSu3Zsg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; b=eiSv6er9Fv3kccl1zqLov1cypmVoYYH6TX2JaeTHQIQIKOb1DOunEYkVhzPTbe/IOvI30SwbrNGXMSVravZCT9oMrU/SBXPqeNGEXoAJCDxxo0ioQkP6J5eq2DbPW3fNkNDeSK7/ldmclk6QzgKeR8Q6L3nBesmG2BHacXSOsBg= X-Yahoo-Newman-Id: 865603.76654.bm@smtp115.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Rkmsd_AVM1mhYV9kta5W4tItTAKt_KZt.Ss2opbp69U0d7q V75K5DTpVmOYbeEgwPNklNxXCUvkz4nWButna57lcSVPlIArxxXvtEZ.pDFD xELOUc6GBjFZcRlj.ZbwvxAAFiOl7UGDJhHOwQKhKymTVXzzm4PzvH0ZkVhE xYRcZknkuFTWeg3hcjlj2z0Lh73AZsR_3oO8TB4PgC6QeAipLtNQnTphN_hK dcGyP366h1AJTT8Tdp.ZauZxHxldErohWngLsXvCwuW4pUfTf4i9B7DCkXFo NjozgxyT9OyqI_6jY1oZIXZwDGGg2NpJsiStk3wdeLc5uNXNdvOz3GKlXZDf gqGZPyrIiyuFWczF6CuPz6NeQgZzQws9Ob5UD3hHwV_BHBilCinJ1MItv7S0 1Fsgxkf_7bL88ON08hBNKVUSvUCpVscxiMikKRzEHpayyoOzPz9kgVFg9tjY Ru8hHrLsUJr4ZdR893EAa_jvkdnXGTxpe7uOVki9Aj2liGv1hgboHpgAkgWI iWVgQWnmY69TQtANMiKqY999EQJz4ZP708cPBKSFhx2UWdU7djSzoOmo- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.160.145 with plain [98.139.221.42]) by smtp115.sbc.mail.bf1.yahoo.com with SMTP; 29 Apr 2014 14:22:56 -0700 PDT Message-ID: <53601828.7030800@sbcglobal.net> Date: Tue, 29 Apr 2014 14:22:48 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm Subject: Microzed bug-fix, Content-Type: multipart/mixed; boundary="------------040700070604040700080101" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:25:52 -0000 This is a multi-part message in MIME format. --------------040700070604040700080101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Another bug-fix. Without this, Microzed or any other Zynq board with 1G of memory panics. It is because of a lack of contiguous virtual space. I moved the mappings of PSIO devices to increase vm_max_kernel_address. I wonder if we'll still have this problem running an ARM board with 2G memory. -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net --------------040700070604040700080101 Content-Type: text/plain; charset=UTF-8; name="patch.1Gprob.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch.1Gprob.txt" Index: zy7_reg.h =================================================================== --- zy7_reg.h (revision 265110) +++ zy7_reg.h (working copy) @@ -44,7 +44,7 @@ #define ZYNQ7_PLGP1_SIZE 0x40000000 /* I/O Peripheral registers. */ -#define ZYNQ7_PSIO_VBASE 0xE0000000 +#define ZYNQ7_PSIO_VBASE 0xF7000000 #define ZYNQ7_PSIO_HWBASE 0xE0000000 #define ZYNQ7_PSIO_SIZE 0x00300000 --------------040700070604040700080101-- From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 21:29:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02584EDE for ; Tue, 29 Apr 2014 21:29:40 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A24B61BB6 for ; Tue, 29 Apr 2014 21:29:39 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3TLTbHx081154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Apr 2014 23:29:37 +0200 (CEST) (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 s3TLTUIW035677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 23:29:31 +0200 (CEST) (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 s3TLTUbl039968; Tue, 29 Apr 2014 23:29:30 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3TLTU8N039967; Tue, 29 Apr 2014 23:29:30 +0200 (CEST) (envelope-from ticso) Date: Tue, 29 Apr 2014 23:29:30 +0200 From: Bernd Walter To: Thomas Skibo Subject: Re: SMP support for ZEDBOARD Message-ID: <20140429212929.GH39364@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> <536009B1.6040503@sbcglobal.net> <20140429205740.GE39364@cicely7.cicely.de> <20140429210334.GF39364@cicely7.cicely.de> <20140429212013.GG39364@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140429212013.GG39364@cicely7.cicely.de> 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 , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:29:40 -0000 On Tue, Apr 29, 2014 at 11:20:13PM +0200, Bernd Walter wrote: > On Tue, Apr 29, 2014 at 11:03:34PM +0200, Bernd Walter wrote: > > On Tue, Apr 29, 2014 at 10:57:41PM +0200, Bernd Walter wrote: > > > On Tue, Apr 29, 2014 at 01:21:05PM -0700, Thomas Skibo wrote: > > > > > > > > > > > > On 4/29/14, 11:34 AM, Bernd Walter wrote: > > > > >On Tue, Apr 29, 2014 at 09:40:53AM -0700, Thomas Skibo wrote: > > > > >> > > > > >>My parallella hasn't shipped but I think I'll get it mid-May. > > > > > > > > > >Backer or preorder? > > > > >I have a rather high 3k backer number. > > > > > > > > Preorder #2081. Mine is a 7010 and for some reason I think they are > > > > going out later than 7020's. > > > > > > Yes - they likely will :-( > > > They produced 7020 for the backers and I think there are also some > > > or all for preorders, but I didn't hear anything about 7010 in production > > > yet. > > > > > > > >>It will probably require tweaking their version of u-boot. I'm looking > > > > >>into that. But the Zedboard image with a few modified boot files should > > > > >>work. > > > > > > > > > >Good to know that you get a parallella as well. > > > > >I still struggle a lot with all this Linux influence in u-boot. > > > > >I will never get those Linux thinking... > > > > >Things had been so much easier without u-boot on RM9200 and Warner > > > > >did a so clean, nice and understandable bootcode for it. > > > > > > > > > > > > > I looked at their u-boot code and they don't have the CONFIG_API flag > > > > necessary for ubldr to work. > > > > > > > > I also didn't realize that the Parallella must boot FSBL/u-boot from the > > > > QSPI flash. I hate to require reprogramming the QSPI flash and risk > > > > bricking the board. > > > > > > Oh - interesting. > > > I thought it is just booting from SD and assumed we can use what you > > > did for the Zedboard to begin with. > > > Wonder why they added a flash chip, when they could have gone without. > > > Is this a pin strapping configuration, or something, which can be > > > changed? > > > > Mmm - ok they have an QSPI Micro Flash in their BOM. > > Currently printing the schematics. > > > > But my Zedboard also has SPI memory - Spansion S25FL256S. > > Don't know how it is used - didn't care about until now. > > Did I get it right, that the ROMcode loades the FSBL from either JTAG > or flash. > The FSBL then could load u-boot from whatever it supports, but on > the parallella they load u-boot from QSPI, so it has to be updated? > I do have a JTAG available, according to the parallella schematics > however it is setup via solder pull-up vs pull-down resistor. > I also have a hot air soldering station, but still not nice. > I also would have to lock up where the JTAG is - probably on one of the > Samtec connectors :-( Ok - JTAG is on the SAMTEC. Bootmode as well - the resistor mode pin was cascaded JTAG vs dedicated. No soldering, but needs some kind of breakout board. I remember having seen 0.1" breakout somewhere already, not sure if it's possible to get one of them. A JTAG defintively should be reachable in case it's bricked. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 21:38:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2CE3B4 for ; Tue, 29 Apr 2014 21:38:23 +0000 (UTC) Received: from nm10-vm4.access.bullet.mail.bf1.yahoo.com (nm10-vm4.access.bullet.mail.bf1.yahoo.com [216.109.114.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 634471C83 for ; Tue, 29 Apr 2014 21:38:23 +0000 (UTC) Received: from [66.196.81.163] by nm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 21:35:34 -0000 Received: from [98.139.244.52] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 21:35:34 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 21:35:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1398807333; bh=lmRbZvWQgHloF53eFkDDHu/xccBx971NwXUlxKMDZgU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; b=Je9m8mynYl9wOoV6pG5eO88qKHk7RxDGPmimbhaSwRlkzs7IdfcSrGmgp9z4O7R++fdlaps9cck3hNN6pfoZoVAsxVjDBHff/3cz4Cnl0C4SIGLbz7DAu1DiNkhwUiaP8zp+Fmm2UFknxFeAtEVrXc83svpPFtAChxB/eEuuwXQ= X-Yahoo-Newman-Id: 991668.79757.bm@smtp114.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: y3gRkWYVM1kYWRf.gBOApm7Pyfy7SN1uhm45NtB3GFklw70 3EMwycgCAQSf3wS2WEyFx.oJluopQa4JDlZ7MNA6kcKc6U7Ta.CFO.Hi5w0p KUBDdhNHHEamVaJjinTIyj7em5hVJCyF_bhx5c9S_SbugAFSvGXBfCag8mR0 556TQcjzs0z85qn2hr17jSuRuwrRBc.pAIR6GmaqO7tcxCpi08u.9A9r1l1e NlMze0Imw0ppd7Rwjju4mbJ9YrI0esWrgBObNCwvAyex8bpLdQKGUzwJPsLB Ixlim32aj.4.8LUR_sL0NJ.OdgUqbtp3fmHCLNe.50log2esEGJV0_2yxpWm s8646906hpaq3JELfhJYe5u1JT99exgf6Wp7GcevdV2RSDasD0nTyF.S1Cs2 T_tnmbuN5JZqPy.EzMBzqnOUljPqNOX1hOtAoliPygkvloxVtBs672ovBFc7 b66s1gL8QOD2Tw4XkxQo0Y484kK8klkSZI2gnsGaED7QMy_gd7TedJIAZYGH KCJDa_NuU0MBq7YKQZH8E8psbdk7SmXo_SVsaJccUEsGO3j99HJE- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.160.145 with plain [98.139.221.42]) by smtp114.sbc.mail.bf1.yahoo.com with SMTP; 29 Apr 2014 14:35:33 -0700 PDT Message-ID: <53601B1D.2090702@sbcglobal.net> Date: Tue, 29 Apr 2014 14:35:25 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm Subject: sdhci_fdt ignores clock-frequency property in .dtb Content-Type: multipart/mixed; boundary="------------080304000006030203030304" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:38:23 -0000 This is a multi-part message in MIME format. --------------080304000006030203030304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Another Zynq bug-fix. One Zynq board out there needs to set this property or else the SD card gets clocked too fast. Thanks, -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net --------------080304000006030203030304 Content-Type: text/plain; charset=UTF-8; name="patch.sdhci_fdt.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch.sdhci_fdt.txt" Index: sys/dev/sdhci/sdhci_fdt.c =================================================================== --- sys/dev/sdhci/sdhci_fdt.c (revision 264766) +++ sys/dev/sdhci/sdhci_fdt.c (working copy) @@ -66,6 +66,7 @@ device_t dev; /* Controller device */ u_int quirks; /* Chip specific quirks */ u_int caps; /* If we override SDHCI_CAPABILITIES */ + uint32_t max_clk; /* Max possible freq */ struct resource *irq_res; /* IRQ resource */ void *intrhand; /* Interrupt handle */ @@ -156,6 +157,7 @@ sc->quirks = 0; sc->num_slots = 1; + sc->max_clk = 0; if (!ofw_bus_status_okay(dev)) return (ENXIO); @@ -170,11 +172,14 @@ node = ofw_bus_get_node(dev); - /* Allow dts to patch quirks and slots. */ - if ((OF_getprop(node, "quirks", &cid, sizeof(cid))) > 0) - sc->quirks = fdt32_to_cpu(cid); - if ((OF_getprop(node, "num-slots", &cid, sizeof(cid))) > 0) - sc->num_slots = fdt32_to_cpu(cid); + /* Allow dts to patch quirks, slots, and clock frequency. */ + if ((OF_getencprop(node, "quirks", &cid, sizeof(cid))) > 0) + sc->quirks = cid; + if ((OF_getencprop(node, "num-slots", &cid, sizeof(cid))) > 0) + sc->num_slots = cid; + if ((OF_getencprop(node, "clock-frequency", &cid, sizeof(cid))) > 0) + sc->max_clk = cid; + return (0); } @@ -214,6 +219,7 @@ slot->quirks = sc->quirks; slot->caps = sc->caps; + slot->max_clk = sc->max_clk; if (sdhci_init_slot(dev, slot, i) != 0) continue; --------------080304000006030203030304-- From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 22:40:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3857D946 for ; Tue, 29 Apr 2014 22:40:46 +0000 (UTC) Received: from nm8-vm8.access.bullet.mail.bf1.yahoo.com (nm8-vm8.access.bullet.mail.bf1.yahoo.com [216.109.114.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB260323 for ; Tue, 29 Apr 2014 22:40:45 +0000 (UTC) Received: from [66.196.81.159] by nm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 22:38:00 -0000 Received: from [98.139.221.157] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 22:38:00 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 22:38:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1398811080; bh=fICDNDdpUeaBVyr/0xyQ9Zp9NB23U/EMSmtzyZZ0wS4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=5aFq4G6TJbeky+GrfwYB/+IfC/5gvmTQ2WtQzGsktkl534La8iLCyJGA546Ra200aynfR1jxGw5mGc0tkRzsMgM2jaJc6sO4HG83f/KL/b/VPoCMQhYn4qqaLe7E+dHce491xWsuyB43P4m4QOSlgQzuvDrbpzPjNQkfcOh5INI= X-Yahoo-Newman-Id: 223938.96998.bm@smtp117.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: z9sGoMcVM1m7b6myMsOPclHCZ8V2pERxyjePPnAIRJuS0UB 4Tfqp5NAs79e_86dzu85LYo6_.lwBSSSioorEEF5eLBnn898pQGQWLbO0UAM 7Zi3j2KU5TQuEjSYnTKxknnHzlLHkpcjMi5PKjpq6J9hd54643oNTjboENW_ OEtP4q_AUTJG9dYRmENNTuaCPwxkgFP12X2lYPLDmyxB8zH.wbMWKA9ugLG3 tpGkO1xMtKoyiH_hqulHPf3snkLAY9ZEsxz6_X4pI7j7dj6PxGqnY2cKGs9N JDKUFK_2lTtKfN4s0oYA9eg8E69vAnAvdd0gTdxLFi53_czg296T9GukPt3s PGboG2kt564Pn8RMKfKUVb6i3BziMsLP9X8rYwJyllvYA03ua05k48WRcsxq E.S74FVLEa7RS9sD8vmbSyyt8Ykj44tkENd1PBDi52ZUTjpU_UZPFLejjMh1 lBvaW1QhaBfFjFe.TJQKzTBAuDf.qXBB86jDk2txgBARm7CqI6P2N7kqJI1D 1.FHnTpBiNvXu4It.uitNJyV83JG0AX.Qi2rxtOL1BjI340MLUVpLp3ckXCg gLkok6t4XbqYVFTCsIdhUjGQ9d.9Uz4vaxzG3z.4ir._3oLkJBreu_VVeqFa MzSal9XdSquDc3sxicZebCoVRCPaT6wVfI6S8VIP9y5T55wtaH.kW6fPXEc6 cconwhroQ.mqM X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.160.145 with plain [98.139.221.42]) by smtp117.sbc.mail.bf1.yahoo.com with SMTP; 29 Apr 2014 22:38:00 +0000 UTC Message-ID: <536029BE.5090108@sbcglobal.net> Date: Tue, 29 Apr 2014 15:37:50 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ticso@cicely.de Subject: Re: SMP support for ZEDBOARD References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> <536009B1.6040503@sbcglobal.net> <20140429205740.GE39364@cicely7.cicely.de> <20140429210334.GF39364@cicely7.cicely.de> <20140429212013.GG39364@cicely7.cicely.de> <20140429212929.GH39364@cicely7.cicely.de> In-Reply-To: <20140429212929.GH39364@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 22:40:46 -0000 On 4/29/14, 2:29 PM, Bernd Walter wrote: >>>> >>>> Oh - interesting. >>>> I thought it is just booting from SD and assumed we can use what you >>>> did for the Zedboard to begin with. >>>> Wonder why they added a flash chip, when they could have gone without. >>>> Is this a pin strapping configuration, or something, which can be >>>> changed? It looks like it can't boot (directly) from the SD card because it is attached to SDIO1 and not SDIO0. I guess it can only boot from SDIO0 and SDIO0 isn't available if you have two USB interfaces and Ethernet. Take a look at the MIO-at-a-Glance Table in the Zynq manual (page 52 in my copy). Hence, the need to boot from the QSPI flash. >> >> Did I get it right, that the ROMcode loades the FSBL from either JTAG >> or flash. >> The FSBL then could load u-boot from whatever it supports, but on >> the parallella they load u-boot from QSPI, so it has to be updated? >> I do have a JTAG available, according to the parallella schematics >> however it is setup via solder pull-up vs pull-down resistor. >> I also have a hot air soldering station, but still not nice. >> I also would have to lock up where the JTAG is - probably on one of the >> Samtec connectors :-( > > Ok - JTAG is on the SAMTEC. > Bootmode as well - the resistor mode pin was cascaded JTAG vs dedicated. > No soldering, but needs some kind of breakout board. > I remember having seen 0.1" breakout somewhere already, not sure if > it's possible to get one of them. > A JTAG defintively should be reachable in case it's bricked. > It should be possible to create a u-boot that will work with either FreeBSD or Linux, program it once, and be done. Xilinx's latest u-boot release can do this because it has CONFIG_API set and allows a uEnv.txt file to customize the boot environment. This is how I can boot FreeBSD with an unmodified u-boot. I think I may already have a config built that might work. Then, it's a matter of reprogramming the QSPI flash. This describes how to program the QSPI flash presumably even if it's blank: https://github.com/parallella/parallella-hw/tree/master/boards/parallella-I/firmware But if the flash is already programmed, I think it might be possible to stop it at a u-boot prompt, skip to step 9 and program the new image. Just hope there's no power failure while rewriting! -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 23:12:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F519CF3 for ; Tue, 29 Apr 2014 23:12:30 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D18C07B7 for ; Tue, 29 Apr 2014 23:12:29 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id hl10so1029180igb.12 for ; Tue, 29 Apr 2014 16:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M5xVo14yjys2NDysOekw/JFkdPLsP/AypxSNjMQz454=; b=06SlFDeDgBSFdtoOc4mo020zbOKa0dKZYEfduPbaBieZvUn2/iOFx1XaJMWeZ2gyRk SSlcg+7qg5NW4qoampUI5QiSKdzLSmnJZCW/Jh0XGj+u1hAsBvx0juJKOjB71GZ9ZOSZ +9bHpW/s2EO4Ia8BkHJZOZWgKFWnMinOcJe4oza4V6UaxynuOZOhxMaXG+4G2xOqoMld nc6Oo/YQ2rp46aZ24ICYqCRkld98TcpBnE6/gkdPzsNK01LUXgLk3PKK79/7A3UL1z1a 9K+swuZ21geAlEPDgUuTZdWhccTjSnoi3G0Z2Q8mbviXXcCyT9xsDsQ5zskLWkY7K+3i Nivg== MIME-Version: 1.0 X-Received: by 10.50.136.229 with SMTP id qd5mr819734igb.48.1398813149171; Tue, 29 Apr 2014 16:12:29 -0700 (PDT) Received: by 10.64.64.5 with HTTP; Tue, 29 Apr 2014 16:12:29 -0700 (PDT) In-Reply-To: <20140429170757.GR28551@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <20140429170757.GR28551@cicely7.cicely.de> Date: Wed, 30 Apr 2014 07:12:29 +0800 Message-ID: Subject: Re: Radxa (was: SMP support for ZEDBOARD) From: Ganbold Tsagaankhuu To: ticso@cicely.de Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "ticso@cicely.de freebsd-arm" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:12:30 -0000 On Wed, Apr 30, 2014 at 1:07 AM, Bernd Walter wrote: > On Tue, Apr 29, 2014 at 12:12:11PM +0800, Ganbold Tsagaankhuu wrote: > > On Tue, Apr 29, 2014 at 11:03 AM, Bernd Walter >wrote: > > > > > And unrelated to Zynq - I got my hands on 2 Radxa Boards based on > > > RK3188 Quad A9 at 1.6GHz. > > > > > > > > > That is cool, we need more drivers in case of Radxa board :) > > What is missing? > I really didn't do anything with those boards yet. > Just saw that some claims are made FreeBSD should basicly work at least. > My personal interesest are basicly ethernet, cores, SD and seriel console. > As you said FreeBSD works basically, however there is no driver or code that enables ethernet, SD/mmc and SMP. Ganbold > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 23:18:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AF90FE9 for ; Tue, 29 Apr 2014 23:18:52 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 369867FC for ; Tue, 29 Apr 2014 23:18:51 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3TNIOYb082052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Apr 2014 01:18:24 +0200 (CEST) (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 s3TNIIKR040373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2014 01:18:18 +0200 (CEST) (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 s3TNIH2D040571; Wed, 30 Apr 2014 01:18:17 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3TNIH56040570; Wed, 30 Apr 2014 01:18:17 +0200 (CEST) (envelope-from ticso) Date: Wed, 30 Apr 2014 01:18:17 +0200 From: Bernd Walter To: Thomas Skibo Subject: Re: SMP support for ZEDBOARD Message-ID: <20140429231817.GK39364@cicely7.cicely.de> References: <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> <536009B1.6040503@sbcglobal.net> <20140429205740.GE39364@cicely7.cicely.de> <20140429210334.GF39364@cicely7.cicely.de> <20140429212013.GG39364@cicely7.cicely.de> <20140429212929.GH39364@cicely7.cicely.de> <536029BE.5090108@sbcglobal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536029BE.5090108@sbcglobal.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:18:52 -0000 On Tue, Apr 29, 2014 at 03:37:50PM -0700, Thomas Skibo wrote: > > > On 4/29/14, 2:29 PM, Bernd Walter wrote: > >>>> > >>>>Oh - interesting. > >>>>I thought it is just booting from SD and assumed we can use what you > >>>>did for the Zedboard to begin with. > >>>>Wonder why they added a flash chip, when they could have gone without. > >>>>Is this a pin strapping configuration, or something, which can be > >>>>changed? > > It looks like it can't boot (directly) from the SD card because it is > attached to SDIO1 and not SDIO0. I guess it can only boot from SDIO0 > and SDIO0 isn't available if you have two USB interfaces and Ethernet. > Take a look at the MIO-at-a-Glance Table in the Zynq manual (page 52 in > my copy). Hence, the need to boot from the QSPI flash. I remember someone on the forum mentioning second SDIO0 when droping the other USB, which isn't really usefull at all it seems. Maybe next board generation, but even then likely still not the primary SDIO. > >>Did I get it right, that the ROMcode loades the FSBL from either JTAG > >>or flash. > >>The FSBL then could load u-boot from whatever it supports, but on > >>the parallella they load u-boot from QSPI, so it has to be updated? > >>I do have a JTAG available, according to the parallella schematics > >>however it is setup via solder pull-up vs pull-down resistor. > >>I also have a hot air soldering station, but still not nice. > >>I also would have to lock up where the JTAG is - probably on one of the > >>Samtec connectors :-( > > > >Ok - JTAG is on the SAMTEC. > >Bootmode as well - the resistor mode pin was cascaded JTAG vs dedicated. > >No soldering, but needs some kind of breakout board. > >I remember having seen 0.1" breakout somewhere already, not sure if > >it's possible to get one of them. > >A JTAG defintively should be reachable in case it's bricked. > > > > It should be possible to create a u-boot that will work with either > FreeBSD or Linux, program it once, and be done. Xilinx's latest u-boot > release can do this because it has CONFIG_API set and allows a uEnv.txt > file to customize the boot environment. This is how I can boot FreeBSD > with an unmodified u-boot. I think I may already have a config built > that might work. > > Then, it's a matter of reprogramming the QSPI flash. This describes how > to program the QSPI flash presumably even if it's blank: > > https://github.com/parallella/parallella-hw/tree/master/boards/parallella-I/firmware > > But if the flash is already programmed, I think it might be possible to > stop it at a u-boot prompt, skip to step 9 and program the new image. > Just hope there's no power failure while rewriting! Looks like they use JTAG to load a u-boot, from which they flash the SPI. Anyway, until things are well tested you could brick the board. I definitively want a breakout board to have JTAG access. Will ask on the forum for options, worst case I will do a layout on myself, but prefer getting something ready. In this description loading u-boot via JTAG is done using Xilinx tools. so you need a Xilinx supported JTAG - which I have. Unclear if it is possible via OpenOCD, which would open more JTAG adapters. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 23:39:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0007691 for ; Tue, 29 Apr 2014 23:39:13 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 665AB992 for ; Tue, 29 Apr 2014 23:39: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 s3TNdBuL082189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Apr 2014 01:39:11 +0200 (CEST) (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 s3TNd5x3040507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2014 01:39:05 +0200 (CEST) (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 s3TNd5CH040664; Wed, 30 Apr 2014 01:39:05 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3TNd5iV040663; Wed, 30 Apr 2014 01:39:05 +0200 (CEST) (envelope-from ticso) Date: Wed, 30 Apr 2014 01:39:05 +0200 From: Bernd Walter To: Ganbold Tsagaankhuu Subject: Re: Radxa (was: SMP support for ZEDBOARD) Message-ID: <20140429233905.GL39364@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <20140429170757.GR28551@cicely7.cicely.de> 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: "ticso@cicely.de freebsd-arm" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:39:14 -0000 On Wed, Apr 30, 2014 at 07:12:29AM +0800, Ganbold Tsagaankhuu wrote: > On Wed, Apr 30, 2014 at 1:07 AM, Bernd Walter wrote: > > > On Tue, Apr 29, 2014 at 12:12:11PM +0800, Ganbold Tsagaankhuu wrote: > > > On Tue, Apr 29, 2014 at 11:03 AM, Bernd Walter > >wrote: > > > > > > > And unrelated to Zynq - I got my hands on 2 Radxa Boards based on > > > > RK3188 Quad A9 at 1.6GHz. > > > > > > > > > > > > > That is cool, we need more drivers in case of Radxa board :) > > > > What is missing? > > I really didn't do anything with those boards yet. > > Just saw that some claims are made FreeBSD should basicly work at least. > > My personal interesest are basicly ethernet, cores, SD and seriel console. > > > > As you said FreeBSD works basically, however there is no driver or code > that enables ethernet, SD/mmc and SMP. I hoped for more to be running already. With neither ethernet nor SD/MMC - did it ever boot into multiuser? I mean there is still ramdisk and USB to hold system. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 23:46:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F18C07FF for ; Tue, 29 Apr 2014 23:46:50 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE57EA2F for ; Tue, 29 Apr 2014 23:46:50 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id lx4so1014782iec.24 for ; Tue, 29 Apr 2014 16:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GGybHorfnhK6DNFTqFzZcqSvTD4yhKUknZwDCFDbRo8=; b=tOvDGkyfuxjKme3psJuWTGu3cOaGfdvOxpD5LM4Djw9QA87nsdXfkanIp4q70t/agg LbXKpm0LXhznCghy5QshCUL6wuW+ZQKkIxSM46436zMPQSEHnqjTKrkIYnZstbHU1jB9 kIVvIbHrjfQmgLoldaYZv0/lv1Y/w4D2CvDbcUoGA1wWH1U2v49t1sVNWe1QrY4xyuNY k/y0FLr916bc64Lr0O0V91666opF2JJb+o7tLaK0ARUebQ7BWurn2KIIAHspjvm8ozWj XPqAaEPw7njXV2fCHFGbjAvdHhYLBwafeNLrFNKKbJYTJQX4WXbmyjlwyJEuB1xJX7X1 NDJA== MIME-Version: 1.0 X-Received: by 10.43.10.131 with SMTP id pa3mr905378icb.18.1398815210053; Tue, 29 Apr 2014 16:46:50 -0700 (PDT) Received: by 10.64.64.5 with HTTP; Tue, 29 Apr 2014 16:46:49 -0700 (PDT) In-Reply-To: <20140429233905.GL39364@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <20140429170757.GR28551@cicely7.cicely.de> <20140429233905.GL39364@cicely7.cicely.de> Date: Wed, 30 Apr 2014 07:46:50 +0800 Message-ID: Subject: Re: Radxa (was: SMP support for ZEDBOARD) From: Ganbold Tsagaankhuu To: ticso@cicely.de Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "ticso@cicely.de freebsd-arm" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:46:51 -0000 On Wed, Apr 30, 2014 at 7:39 AM, Bernd Walter wrote: > On Wed, Apr 30, 2014 at 07:12:29AM +0800, Ganbold Tsagaankhuu wrote: > > On Wed, Apr 30, 2014 at 1:07 AM, Bernd Walter >wrote: > > > > > On Tue, Apr 29, 2014 at 12:12:11PM +0800, Ganbold Tsagaankhuu wrote: > > > > On Tue, Apr 29, 2014 at 11:03 AM, Bernd Walter < > ticso@cicely7.cicely.de > > > >wrote: > > > > > > > > > And unrelated to Zynq - I got my hands on 2 Radxa Boards based on > > > > > RK3188 Quad A9 at 1.6GHz. > > > > > > > > > > > > > > > > > That is cool, we need more drivers in case of Radxa board :) > > > > > > What is missing? > > > I really didn't do anything with those boards yet. > > > Just saw that some claims are made FreeBSD should basicly work at > least. > > > My personal interesest are basicly ethernet, cores, SD and seriel > console. > > > > > > > As you said FreeBSD works basically, however there is no driver or code > > that enables ethernet, SD/mmc and SMP. > > I hoped for more to be running already. > With neither ethernet nor SD/MMC - did it ever boot into multiuser? > I mean there is still ramdisk and USB to hold system. > Yes, USB is supported. Ganbold > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 23:52:27 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77643977 for ; Tue, 29 Apr 2014 23:52:27 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37C03AC1 for ; Tue, 29 Apr 2014 23:52:26 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WfHp3-0002DJ-M0; Tue, 29 Apr 2014 23:52:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3TNqLPt016821; Tue, 29 Apr 2014 17:52:22 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/L5UT70ODCgIJ4xdDMyQfw Subject: Re: Microzed bug-fix, From: Ian Lepore To: Thomas Skibo In-Reply-To: <53601828.7030800@sbcglobal.net> References: <53601828.7030800@sbcglobal.net> Content-Type: multipart/mixed; boundary="=-r7zOGkcStnW0COmiEVzA" Date: Tue, 29 Apr 2014 17:52:21 -0600 Message-ID: <1398815541.22079.46.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:52:27 -0000 --=-r7zOGkcStnW0COmiEVzA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, 2014-04-29 at 14:22 -0700, Thomas Skibo wrote: > Hi, > > Another bug-fix. > > Without this, Microzed or any other Zynq board with 1G of memory panics. > It is because of a lack of contiguous virtual space. I moved the > mappings of PSIO devices to increase vm_max_kernel_address. > > I wonder if we'll still have this problem running an ARM board with 2G > memory. There's a newer way to do this, but I didn't do the xilinx stuff when I set this up last year because I had no way to test it. The new scheme lets you declare the physaddr and size of any regions to be device-mapped, and it dynamically allocates virtual address space for it from the top down, so device mapping doesn't waste any space. Please try the attached patch. The *_VBASE defines are deleted because those things aren't at a fixed address anymore. If it's ever necessary to get a virtual address outside of the bus_space system (like for a debugging uart) you can call arm_devmap_ptov(). Oh -- I have 2G wandboards that have no trouble with memory. -- Ian --=-r7zOGkcStnW0COmiEVzA Content-Disposition: inline; filename="zynq_devmap.diff" Content-Type: text/x-patch; name="zynq_devmap.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/xilinx/zy7_machdep.c =================================================================== --- sys/arm/xilinx/zy7_machdep.c (revision 265110) +++ sys/arm/xilinx/zy7_machdep.c (working copy) @@ -60,7 +60,7 @@ vm_offset_t initarm_lastaddr(void) { - return (ZYNQ7_PSIO_VBASE); + return (arm_devmap_lastaddr()); } void @@ -79,39 +79,18 @@ initarm_late_init(void) { } -#define FDT_DEVMAP_SIZE 3 -static struct arm_devmap_entry fdt_devmap[FDT_DEVMAP_SIZE]; - /* - * Construct pmap_devmap[] with DT-derived config data. + * Set up static device mappings. Not strictly necessary -- simplebus will + * dynamically establish mappings as needed -- but doing it this way gets us + * nice efficient 1MB section mappings. */ int initarm_devmap_init(void) { - int i = 0; - fdt_devmap[i].pd_va = ZYNQ7_PSIO_VBASE; - fdt_devmap[i].pd_pa = ZYNQ7_PSIO_HWBASE; - fdt_devmap[i].pd_size = ZYNQ7_PSIO_SIZE; - fdt_devmap[i].pd_prot = VM_PROT_READ | VM_PROT_WRITE; - fdt_devmap[i].pd_cache = PTE_DEVICE; - i++; + arm_devmap_add_entry(ZYNQ7_PSIO_HWBASE, ZYNQ7_PSIO_SIZE); + arm_devmap_add_entry(ZYNQ7_PSCTL_HWBASE, ZYNQ7_PSCTL_SIZE); - fdt_devmap[i].pd_va = ZYNQ7_PSCTL_VBASE; - fdt_devmap[i].pd_pa = ZYNQ7_PSCTL_HWBASE; - fdt_devmap[i].pd_size = ZYNQ7_PSCTL_SIZE; - fdt_devmap[i].pd_prot = VM_PROT_READ | VM_PROT_WRITE; - fdt_devmap[i].pd_cache = PTE_DEVICE; - i++; - - /* end of table */ - fdt_devmap[i].pd_va = 0; - fdt_devmap[i].pd_pa = 0; - fdt_devmap[i].pd_size = 0; - fdt_devmap[i].pd_prot = 0; - fdt_devmap[i].pd_cache = 0; - - arm_devmap_register_table(&fdt_devmap[0]); return (0); } Index: sys/arm/xilinx/zy7_reg.h =================================================================== --- sys/arm/xilinx/zy7_reg.h (revision 265110) +++ sys/arm/xilinx/zy7_reg.h (working copy) @@ -44,16 +44,13 @@ #define ZYNQ7_PLGP1_SIZE 0x40000000 /* I/O Peripheral registers. */ -#define ZYNQ7_PSIO_VBASE 0xE0000000 #define ZYNQ7_PSIO_HWBASE 0xE0000000 #define ZYNQ7_PSIO_SIZE 0x00300000 /* UART0 and UART1 */ -#define ZYNQ7_UART0_VBASE (ZYNQ7_PSIO_VBASE) #define ZYNQ7_UART0_HWBASE (ZYNQ7_PSIO_HWBASE) #define ZYNQ7_UART0_SIZE 0x1000 -#define ZYNQ7_UART1_VBASE (ZYNQ7_PSIO_VBASE+0x1000) #define ZYNQ7_UART1_HWBASE (ZYNQ7_PSIO_HWBASE+0x1000) #define ZYNQ7_UART1_SIZE 0x1000 @@ -63,15 +60,12 @@ #define ZYNQ7_SMC_SIZE 0x05000000 /* SLCR, PS system, and CPU private registers combined in this region. */ -#define ZYNQ7_PSCTL_VBASE 0xF8000000 #define ZYNQ7_PSCTL_HWBASE 0xF8000000 #define ZYNQ7_PSCTL_SIZE 0x01000000 -#define ZYNQ7_SLCR_VBASE (ZYNQ7_PSCTL_VBASE) #define ZYNQ7_SLCR_HWBASE (ZYNQ7_PSCTL_HWBASE) #define ZYNQ7_SLCR_SIZE 0x1000 -#define ZYNQ7_DEVCFG_VBASE (ZYNQ7_PSCTL_VBASE+0x7000) #define ZYNQ7_DEVCFG_HWBASE (ZYNQ7_PSCTL_HWBASE+0x7000) #define ZYNQ7_DEVCFG_SIZE 0x1000 --=-r7zOGkcStnW0COmiEVzA-- From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 00:05:36 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0155B46 for ; Wed, 30 Apr 2014 00:05:36 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5774B88 for ; Wed, 30 Apr 2014 00:05:36 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WfI1n-000FeZ-4h; Wed, 30 Apr 2014 00:05:35 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3U05Wf5016833; Tue, 29 Apr 2014 18:05:32 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18yzk9plf137ONRP1i0wNuT Subject: Re: sdhci_fdt ignores clock-frequency property in .dtb From: Ian Lepore To: Thomas Skibo In-Reply-To: <53601B1D.2090702@sbcglobal.net> References: <53601B1D.2090702@sbcglobal.net> Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 2014 18:05:32 -0600 Message-ID: <1398816332.22079.49.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 00:05:37 -0000 On Tue, 2014-04-29 at 14:35 -0700, Thomas Skibo wrote: > Another Zynq bug-fix. One Zynq board out there needs to set this > property or else the SD card gets clocked too fast. > > Thanks, > The documented property for this is max-frequency rather than clock-frequency. Is this a completely new property for us, or are you just making the code honor what's in our existing dts files? Either way we should use the documented name, I'm just wondering if we need to fix dts files and give folks a heads-up about the change. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 02:34:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CEC56B7; Wed, 30 Apr 2014 02:34:18 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B47CE183E; Wed, 30 Apr 2014 02:34:17 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x12so205535wgg.30 for ; Tue, 29 Apr 2014 19:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Quhsg+3Ri9Cqz8+K46YY/cnXuFbrMac8s6CGnLGEvs=; b=qdpnpj+mamfHOU4SzjRqjpLQMYcP/geiYaTOtYhzOi7Z2WFzm/3hiq42lDjQznRGdE TYVrSVCPBV8IYqvby3jzeiZOUfUOhBi1q9PKVXbDNnERrigXjJoqOi0VgKhCpgeXPZQS 6s7kln7+zFzMiZuLUww7BvqyrEp7giR9FslIMTpR1c6v/l4Fejp8mZpqM/PKzcjxcfiV ZbOK7Q3RkJtDZz2T0jNHUgFlTZVaR4g4/V34dL2shFwOYZg76GsLGPKuf4gnMZx1QeM/ NIFVjLyywJFpMRNiXW3feBXW/kAKM3qPbnpGlzpP5pxYNOVeGWOa2FI0ubXfcQ04vgic ZHmA== MIME-Version: 1.0 X-Received: by 10.194.84.101 with SMTP id x5mr1299760wjy.52.1398825255138; Tue, 29 Apr 2014 19:34:15 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Tue, 29 Apr 2014 19:34:15 -0700 (PDT) In-Reply-To: <535D1576.6040005@gmail.com> References: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> <746D7AE2-54D1-4758-816F-4954F3F01A5E@gmail.com> <535C7E1B.1090605@hot.ee> <535D1576.6040005@gmail.com> Date: Tue, 29 Apr 2014 22:34:15 -0400 Message-ID: Subject: Re: BBB 1GHz patches for u-boot 2014-01 From: Winston Smith To: Xuebing Wang Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 02:34:18 -0000 On Sun, Apr 27, 2014 at 10:34 AM, Xuebing Wang wrote: > 1) We have 2 packages that concerning u-boot: > > 1a) Crocket > 1b) /usr/ports/sysutils/u-boot-beaglebone-eabi > > Please note: the patches for u-boot in the above 2 packages are different. > > In my humble opinion, I'd think the u-boot patches for the above 2 packages > are better to be identical. > > 2) My patches to the latest u-boot are against above 1b) > /usr/ports/sysutils/u-boot-beaglebone-eabi Now that I have 10-STABLE working from eMMC, I decided to take a look at the 1Ghz patches. I started out with uboot_beaglebone_eabi_port, but although I was able to get it to build (after removing the 0 length patch files), I couldn't seem to get crotchet-freebsd to pick it up. It seems that the `uboot_eabi_port` tools is missing; I'm using pkgng, so maybe that's the problem. I noticed that uboot_beaglebone_eabi_port with the 1Ghz patches builds against u-boot-2014.01 so I downloaded u-boot-2014.01.tar.bz2, unpacked it in the crotchet-freebsd directory and replaced the patches in crotchet-freebsd/boards/BeagleBone/files with the 1Ghz ones and tried a crotchet build. This failed to link with: armv6-freebsd-ld: region .sram is full (u-boot-spl section .data) armv6-freebsd-ld: region .sram is full (u-boot-spl section .data) armv6-freebsd-ld: section .u_boot_list [00000000402f0400 -> 00000000402f0477] overlaps section .text [00000000402f0400 -> 000000004030657b] armv6-freebsd-ld: u-boot-spl: section .text lma 0x402f0400 overlaps previous sections armv6-freebsd-ld: u-boot-spl: section .rodata lma 0x4030657c overlaps previous sections armv6-freebsd-ld: u-boot-spl: section .data lma 0x4030aec8 overlaps previous sections So no luck there. I did try also building Patrick Kelsey's fork of u-boot which failed with very similar errors: armv6-freebsd-ld: region .sram is full (u-boot-spl section .rodata) armv6-freebsd-ld: region .sram is full (u-boot-spl section .rodata) armv6-freebsd-ld: section .data [00000000402f0400 -> 00000000402f1141] overlaps section .text [00000000402f0400 -> 0000000040307257] armv6-freebsd-ld: u-boot-spl: section .text lma 0x402f0400 overlaps previous sections armv6-freebsd-ld: u-boot-spl: section .u_boot_list lma 0x402f1144 overlaps previous sections I did notice that the *original* patches for uboot_beaglebone_eabi_port seem to remove api_net.c from the build, perhaps this was an effort to slim down the binary to avoid this issue (however, the 1Ghz patches nuke the patches that removed api_net.c and it's callers). Finally, I took a look at the patches to see if I could rework them for u-boot-2014.04 (since it was recently released), but it seems that there have been significant changes since 2013.04 so I need to learn more about u-boot before going near that! Thanks, -W. From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 09:14:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1422E324 for ; Wed, 30 Apr 2014 09:14:51 +0000 (UTC) Received: from mail-01.thismonkey.com (220-245-31-196.static.tpgi.com.au [220.245.31.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-01.thismonkey.com", Issuer "Thismonkey IT Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 85B5215E2 for ; Wed, 30 Apr 2014 09:14:49 +0000 (UTC) X-TM-Via-MX: mail-01.thismonkey.com Received: from utility-01.thismonkey.com (utility-01.thismonkey.com [10.1.1.32]) by mail-01.thismonkey.com (8.14.5/8.14.5) with ESMTP id s3U9EKnn070638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Apr 2014 19:14:20 +1000 (EST) (envelope-from scott@utility-01.thismonkey.com) Received: from utility-01.thismonkey.com (localhost [127.0.0.1]) by utility-01.thismonkey.com (8.14.5/8.14.5) with ESMTP id s3U9EKN6045111; Wed, 30 Apr 2014 19:14:20 +1000 (EST) (envelope-from scott@utility-01.thismonkey.com) Received: (from root@localhost) by utility-01.thismonkey.com (8.14.5/8.14.5/Submit) id s3U9ECk8045109; Wed, 30 Apr 2014 19:14:12 +1000 (EST) (envelope-from scott) Date: Wed, 30 Apr 2014 19:14:12 +1000 From: Scott Aitken To: ticso@cicely.de Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined Message-ID: <20140430091411.GA45015@utility-01.thismonkey.com> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140425204134.GA458@cicely7.cicely.de> User-Agent: Mutt/1.5.22 (2013-10-16) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (mail-01.thismonkey.com [10.1.2.50]); Wed, 30 Apr 2014 19:14:20 +1000 (EST) Cc: freebsd-arm@freebsd.org, Scott Aitken X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 09:14:51 -0000 Hi again, good call on the kernel recompile. I added sound and uaudio to the kernel and low and behold things improved: root@raspberry-pi:/mnt # dmesg ... ugen0.4: at usbus0 uaudio0: on usbus0 uaudio0: Play: 96000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 44100 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. uaudio0: No recording. uaudio0: No MIDI sequencer. pcm0: on uaudio0 However, when I play a file to /dev/dsp, I get an error in dmesg: root@raspberry-pi:/mnt # cat /bin/ls > /dev/dsp cat: stdout: Invalid argument root@raspberry-pi:/mnt # dmesg ... pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead Here are some (possibly) relevant sysctls: root@raspberry-pi:/mnt # sysctl -a | egrep '(snd|pcm|sound)' hw.snd.report_soft_formats: 1 hw.snd.report_soft_matrix: 1 hw.snd.latency: 5 hw.snd.latency_profile: 1 hw.snd.vpc_autoreset: 1 hw.snd.vpc_0db: 45 hw.snd.vpc_reset: 0 hw.snd.compat_linux_mmap: 0 hw.snd.feeder_eq_presets: PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000 hw.snd.feeder_eq_exact_rate: 0 hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97 hw.snd.feeder_rate_polyphase_max: 183040 hw.snd.feeder_rate_min: 1 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_quality: 1 hw.snd.vpc_mixer_bypass: 1 hw.snd.verbose: 0 hw.snd.default_auto: 1 hw.snd.version: 2009061500/armv6 hw.snd.default_unit: 0 hw.snd.maxautovchans: 16 dev.pcm.0.%desc: USB audio dev.pcm.0.%driver: pcm dev.pcm.0.%parent: uaudio0 dev.pcm.0.hwvol_step: 5 dev.pcm.0.hwvol_mixer: vol dev.pcm.0.play.vchans: 1 dev.pcm.0.play.vchanmode: fixed dev.pcm.0.play.vchanrate: 48000 dev.pcm.0.play.vchanformat: s16le:2.0 dev.pcm.0.buffersize: 0 dev.pcm.0.bitperfect: 0 dev.pcm.0.mixer.vol_0_0.val: -2892 dev.pcm.0.mixer.vol_0_0.min: -11520 dev.pcm.0.mixer.vol_0_0.max: 0 dev.pcm.0.mixer.vol_0_0.desc: DARED AUDIO dev.pcm.0.mixer.vol_0_1.val: -2892 dev.pcm.0.mixer.vol_0_1.min: -11520 dev.pcm.0.mixer.vol_0_1.max: 0 dev.pcm.0.mixer.vol_0_1.desc: DARED AUDIO dev.pcm.0.mixer.mute_1.val: 0 dev.pcm.0.mixer.mute_1.min: 0 dev.pcm.0.mixer.mute_1.max: 1 dev.pcm.0.mixer.mute_1.desc: DARED AUDIO Any further advice would be appeciated. Thanks, Scott On Fri, Apr 25, 2014 at 10:41:34PM +0200, Bernd Walter wrote: > On Fri, Apr 25, 2014 at 06:18:50PM +0200, Hans Petter Selasky wrote: > > On 04/25/14 17:44, Scott Aitken wrote: > > >Hi all, > > > > > >I'm hoping to use my RPi/FreeBSD as an Airplay device to my amplifier which > > >presents a USB DAC. > > > > > > > Hi, > > > > Audio devices which use ISOCHRONOUS data transport are not supported i > > FreeBSD, because the RPi uses very small buffers and has to handle 8000 > > IRQ/s typically for ISOC transfers. > > This looks more like uaudio module fails to load because it depends > on sound module, which itself then requires ISA bus support in kernel. > The sound.ko shouldn't require ISA when build on ARM. > It might work to compile the drivers into the kernel. > If it uses ISOCHRONOUS, then that's an unrelated problem IMO. > Do all uaudio devices use isochronous endpoints or is it an optional thing? > If it is optional, then he might have a chance. > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 09:20:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44D8E41F for ; Wed, 30 Apr 2014 09:20:54 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 019EA1687 for ; Wed, 30 Apr 2014 09:20:53 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 572171FE029; Wed, 30 Apr 2014 11:20:46 +0200 (CEST) Message-ID: <5360C0A7.9010407@selasky.org> Date: Wed, 30 Apr 2014 11:21:43 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Scott Aitken , ticso@cicely.de Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> In-Reply-To: <20140430091411.GA45015@utility-01.thismonkey.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Scott Aitken X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 09:20:54 -0000 On 04/30/14 11:14, Scott Aitken wrote: > Hi again, > > good call on the kernel recompile. I added sound and uaudio to the kernel > and low and behold things improved: > > > root@raspberry-pi:/mnt # dmesg > ... > ugen0.4: at usbus0 > uaudio0: on usbus0 > uaudio0: Play: 96000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. > uaudio0: Play: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. > uaudio0: Play: 44100 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. > uaudio0: No recording. > uaudio0: No MIDI sequencer. > pcm0: on uaudio0 > > However, when I play a file to /dev/dsp, I get an error in dmesg: > > root@raspberry-pi:/mnt # cat /bin/ls > /dev/dsp > cat: stdout: Invalid argument > root@raspberry-pi:/mnt # dmesg > ... > pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead > Hi, In the "sys/dev/usb/controller/dwc_otg.c" driver the isochronous method which your audio device is using, is not implemented, because it causes excessive interrupts. So the USB transfer simply times out. --HPS From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 09:31:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F16CF8A9 for ; Wed, 30 Apr 2014 09:31:29 +0000 (UTC) Received: from mail-01.thismonkey.com (220-245-31-196.static.tpgi.com.au [220.245.31.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-01.thismonkey.com", Issuer "Thismonkey IT Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 40D1E17B6 for ; Wed, 30 Apr 2014 09:31:28 +0000 (UTC) X-TM-Via-MX: mail-01.thismonkey.com Received: from utility-01.thismonkey.com (utility-01.thismonkey.com [10.1.1.32]) by mail-01.thismonkey.com (8.14.5/8.14.5) with ESMTP id s3U9VH8x071569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Apr 2014 19:31:17 +1000 (EST) (envelope-from scott@thismonkey.com) Received: from utility-01.thismonkey.com (localhost [127.0.0.1]) by utility-01.thismonkey.com (8.14.5/8.14.5) with ESMTP id s3U9VH39045263; Wed, 30 Apr 2014 19:31:17 +1000 (EST) (envelope-from scott@thismonkey.com) Received: (from root@localhost) by utility-01.thismonkey.com (8.14.5/8.14.5/Submit) id s3U9VH18045262; Wed, 30 Apr 2014 19:31:17 +1000 (EST) (envelope-from scott@thismonkey.com) Date: Wed, 30 Apr 2014 19:31:17 +1000 From: Scott Aitken To: Hans Petter Selasky Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined Message-ID: <20140430093116.GA45239@utility-01.thismonkey.com> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5360C0A7.9010407@selasky.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (mail-01.thismonkey.com [10.1.2.50]); Wed, 30 Apr 2014 19:31:17 +1000 (EST) Cc: freebsd-arm@freebsd.org, Scott Aitken , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 09:31:30 -0000 On Wed, Apr 30, 2014 at 11:21:43AM +0200, Hans Petter Selasky wrote: > On 04/30/14 11:14, Scott Aitken wrote: > > Hi again, > > > > good call on the kernel recompile. I added sound and uaudio to the kernel > > and low and behold things improved: > > > > > > root@raspberry-pi:/mnt # dmesg > > ... > > ugen0.4: at usbus0 > > uaudio0: on usbus0 > > uaudio0: Play: 96000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. > > uaudio0: Play: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. > > uaudio0: Play: 44100 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. > > uaudio0: No recording. > > uaudio0: No MIDI sequencer. > > pcm0: on uaudio0 > > > > However, when I play a file to /dev/dsp, I get an error in dmesg: > > > > root@raspberry-pi:/mnt # cat /bin/ls > /dev/dsp > > cat: stdout: Invalid argument > > root@raspberry-pi:/mnt # dmesg > > ... > > pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead > > > > Hi, > > In the "sys/dev/usb/controller/dwc_otg.c" driver the isochronous method > which your audio device is using, is not implemented, because it causes > excessive interrupts. So the USB transfer simply times out. > > --HPS > Ok, many thanks for the info. Scott From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 13:26:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6EC1128; Wed, 30 Apr 2014 13:26:51 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 114DF11D8; Wed, 30 Apr 2014 13:26:50 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id cc10so9127564wib.8 for ; Wed, 30 Apr 2014 06:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/6GjCGuXrFQkGKmh+FsasMKKV41nY2f5xDIokt/yR+4=; b=boKnjvX8Rj++8GdphD+2Z3rPL6ujgZF3XnXhNQa7GqYipd1GHgrQGlrcfIlqYMzc4e qU5DKLLSMh9cSWrigas45vgwJ8Wi4COX3hGCZgUaXoDP56nmcEkz8G/jPoZk8Gx8E4ae DAOxs7X9aqnpOQv/eBsNsIJzmZtZ2ZRQRWAgKFO/c9VDezV+b07z66A2Gqh9gMO5khXU ws5j5ujVwKeHYpYyBvcVUs2jmAaVUWbJOdVoDt3FYDKhbSKyec5kNwtfo3+BanoL+joK 3I1R9lIgML4uZEFpjaS9MQBZaft7yOFsQeocmvbhpfI7N1lTfBbMstNLbeMJwNv1SzuA KPng== X-Received: by 10.180.91.1 with SMTP id ca1mr3764620wib.32.1398864409347; Wed, 30 Apr 2014 06:26:49 -0700 (PDT) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id be3sm36202265wjc.5.2014.04.30.06.26.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 06:26:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: BBB 1GHz patches for u-boot 2014-01 From: fabiodive In-Reply-To: Date: Wed, 30 Apr 2014 14:26:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> <746D7AE2-54D1-4758-816F-4954F3F01A5E@gmail.com> <535C7E1B.1090605@hot.ee> <535D1576.6040005@gmail.com> To: Winston Smith X-Mailer: Apple Mail (2.1510) Cc: FreeBSD ARM , Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 13:26:51 -0000 I also had the same problem during crochet building, in the end I solved it changing the crochet script, I disabled an u-boot checking block and I changed the=20 source path where to install from the u-boot forcing the absolute path of the port, that was a dirty fix because I wanted first to see if the patch set works. thank you f. On Apr 30, 2014, at 3:34 , Winston Smith = wrote: > On Sun, Apr 27, 2014 at 10:34 AM, Xuebing Wang = wrote: >> 1) We have 2 packages that concerning u-boot: >>=20 >> 1a) Crocket >> 1b) /usr/ports/sysutils/u-boot-beaglebone-eabi >>=20 >> Please note: the patches for u-boot in the above 2 packages are = different. >>=20 >> In my humble opinion, I'd think the u-boot patches for the above 2 = packages >> are better to be identical. >>=20 >> 2) My patches to the latest u-boot are against above 1b) >> /usr/ports/sysutils/u-boot-beaglebone-eabi >=20 > Now that I have 10-STABLE working from eMMC, I decided to take a look > at the 1Ghz patches. >=20 > I started out with uboot_beaglebone_eabi_port, but although I was able > to get it to build (after removing the 0 length patch files), I > couldn't seem to get crotchet-freebsd to pick it up. It seems that > the `uboot_eabi_port` tools is missing; I'm using pkgng, so maybe > that's the problem. >=20 > I noticed that uboot_beaglebone_eabi_port with the 1Ghz patches builds > against u-boot-2014.01 so I downloaded u-boot-2014.01.tar.bz2, > unpacked it in the crotchet-freebsd directory and replaced the patches > in crotchet-freebsd/boards/BeagleBone/files with the 1Ghz ones and > tried a crotchet build. This failed to link with: >=20 > armv6-freebsd-ld: region .sram is full (u-boot-spl section .data) > armv6-freebsd-ld: region .sram is full (u-boot-spl section .data) > armv6-freebsd-ld: section .u_boot_list [00000000402f0400 -> > 00000000402f0477] overlaps section .text [00000000402f0400 -> > 000000004030657b] > armv6-freebsd-ld: u-boot-spl: section .text lma 0x402f0400 overlaps > previous sections > armv6-freebsd-ld: u-boot-spl: section .rodata lma 0x4030657c overlaps > previous sections > armv6-freebsd-ld: u-boot-spl: section .data lma 0x4030aec8 overlaps > previous sections >=20 >=20 > So no luck there. I did try also building Patrick Kelsey's fork of > u-boot which failed with very similar errors: >=20 > armv6-freebsd-ld: region .sram is full (u-boot-spl section .rodata) > armv6-freebsd-ld: region .sram is full (u-boot-spl section .rodata) > armv6-freebsd-ld: section .data [00000000402f0400 -> 00000000402f1141] > overlaps section .text [00000000402f0400 -> 0000000040307257] > armv6-freebsd-ld: u-boot-spl: section .text lma 0x402f0400 overlaps > previous sections > armv6-freebsd-ld: u-boot-spl: section .u_boot_list lma 0x402f1144 > overlaps previous sections >=20 >=20 > I did notice that the *original* patches for > uboot_beaglebone_eabi_port seem to remove api_net.c from the build, > perhaps this was an effort to slim down the binary to avoid this issue > (however, the 1Ghz patches nuke the patches that removed api_net.c and > it's callers). >=20 > Finally, I took a look at the patches to see if I could rework them > for u-boot-2014.04 (since it was recently released), but it seems that > there have been significant changes since 2013.04 so I need to learn > more about u-boot before going near that! >=20 > Thanks, >=20 > -W. From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 14:14:40 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 630D51FC for ; Wed, 30 Apr 2014 14:14:40 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 342841712 for ; Wed, 30 Apr 2014 14:14:39 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WfVHM-000BHs-15; Wed, 30 Apr 2014 14:14:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3UEEQ29017624; Wed, 30 Apr 2014 08:14:27 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/DWnLn/nvkfmg6nQYFgKC3 Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <5360C0A7.9010407@selasky.org> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Apr 2014 08:14:26 -0600 Message-ID: <1398867266.22079.51.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, Scott Aitken , Scott Aitken , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:14:40 -0000 On Wed, 2014-04-30 at 11:21 +0200, Hans Petter Selasky wrote: > On 04/30/14 11:14, Scott Aitken wrote: > > Hi again, > > > > good call on the kernel recompile. I added sound and uaudio to the kernel > > and low and behold things improved: > > > > > > root@raspberry-pi:/mnt # dmesg > > ... > > ugen0.4: at usbus0 > > uaudio0: on usbus0 > > uaudio0: Play: 96000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. > > uaudio0: Play: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. > > uaudio0: Play: 44100 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer. > > uaudio0: No recording. > > uaudio0: No MIDI sequencer. > > pcm0: on uaudio0 > > > > However, when I play a file to /dev/dsp, I get an error in dmesg: > > > > root@raspberry-pi:/mnt # cat /bin/ls > /dev/dsp > > cat: stdout: Invalid argument > > root@raspberry-pi:/mnt # dmesg > > ... > > pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead > > > > Hi, > > In the "sys/dev/usb/controller/dwc_otg.c" driver the isochronous method > which your audio device is using, is not implemented, because it causes > excessive interrupts. So the USB transfer simply times out. > > --HPS You mentioned 8k interrupt/sec, while that may be too many in some "it could be better" sense, it shouldn't be enough to cause problems. I was doing some testing on a wandboard (about twice as fast an an rpi) with more than 20k int/sec without having any problems. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 14:21:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1415B43D for ; Wed, 30 Apr 2014 14:21:23 +0000 (UTC) Received: from nm6-vm9.access.bullet.mail.gq1.yahoo.com (nm6-vm9.access.bullet.mail.gq1.yahoo.com [216.39.63.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4B671776 for ; Wed, 30 Apr 2014 14:21:22 +0000 (UTC) Received: from [216.39.60.165] by nm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 14:15:42 -0000 Received: from [67.195.22.119] by tm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 14:15:42 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 14:15:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1398867342; bh=veTKI5Oe7fCh0DPe3VdXzsRjtUJAJCZJLSpzvAKfdgQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=tAXtHEUmDLMCYClwYcTvwUUw13KxDJC5bJcA4L+PRfQCza1Zi+bKAHLQsS0v94TdqZH9AZcFM+Z1IR/MIipfJxV1ZTxP4U/w7tzxexxf3N+yYhBpCvcMzMMSpqL/DMIFUks/T1bP6yQnqubY5yhG7Gv/JP9Ry5P3HkdkmlWHiJY= X-Yahoo-Newman-Id: 263537.41779.bm@smtp114.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: O9IkVpsVM1nn4Z.8tqMndGrhNwxxny5tK0QmNIoV4cKX8jx Ucbc75mv2b__ouCX.L0McqaqGvXGI5gmx8XFMiQG4c4VMOlHU7pn0WFy4S9B wMJWl9wzdt_KSJODw6z1IoWqsel0ssfZDt9oSjWmQ4R2zsjXBIJZhIKEPxbN F_wCshnw6X6ss0_LaNEpRgaGzWo0mMpFF2XNcje_ELqn7wJ1UAWHOkM9p831 B9F8x3yAg39OrKGYyzxgYOWD9uvR6SfP6sRwhQwtiarBlsS8L_NF7XdhcZGW ip87WcajA5wzuhsres4IPiCv2GQoAC.lvTjY3HMpUKdjzEcSWO8ulY6buyD8 SviGf7iz9DMjKdNNh7EsfuiCUlw5enaMaLZgEJ.4v1YefmR0ugscJRdRkXQK zzJlAVfu3Q8zuTpsFhikA0e2F.u.3o_ptFxqiQdhlRj.JMIVnFCCvt3IUcjN .tBEKf.WFUgsgkWlklvJlxkFxqvpGOXyAWIrNRtZc9tU99YRZmLcKuB2tN3h Ey0nM6x.23R4Sqcpm1nquiuwpdemkLsVlSUEvuVizVaqZARa8z_TZgwg- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.160.145 with plain [67.195.15.66]) by smtp114.sbc.mail.gq1.yahoo.com with SMTP; 30 Apr 2014 07:15:42 -0700 PDT Message-ID: <5361058D.4020900@sbcglobal.net> Date: Wed, 30 Apr 2014 07:15:41 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Microzed bug-fix, References: <53601828.7030800@sbcglobal.net> <1398815541.22079.46.camel@revolution.hippie.lan> In-Reply-To: <1398815541.22079.46.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:21:23 -0000 On 4/29/14, 4:52 PM, Ian Lepore wrote: > > There's a newer way to do this, but I didn't do the xilinx stuff when I > set this up last year because I had no way to test it. The new scheme > lets you declare the physaddr and size of any regions to be > device-mapped, and it dynamically allocates virtual address space for it > from the top down, so device mapping doesn't waste any space. > > Please try the attached patch. The *_VBASE defines are deleted because > those things aren't at a fixed address anymore. If it's ever necessary > to get a virtual address outside of the bus_space system (like for a > debugging uart) you can call arm_devmap_ptov(). > > Oh -- I have 2G wandboards that have no trouble with memory. > > -- Ian > Thanks, Ian. I tested the patch and it works. --Thomas -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 14:46:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52A51B47 for ; Wed, 30 Apr 2014 14:46:23 +0000 (UTC) Received: from nm4-vm2.access.bullet.mail.gq1.yahoo.com (nm4-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2EB51A42 for ; Wed, 30 Apr 2014 14:46:22 +0000 (UTC) Received: from [216.39.60.174] by nm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 14:46:16 -0000 Received: from [67.195.22.119] by tm10.access.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 14:46:16 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 14:46:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1398869176; bh=uvuRajwdldYJOSfzQ1TpBAsQaR4P+cDqqIxFrmTHhXo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LZADyzTopCpZMcF4BUu53Hci5u+0NfIot8YZsNc4KV2NUrlG+aIe4L0XVWmH40oAoOM/oFfgWen08vemTRa2/mP3y3PV3rD8xjOuBhfCV+iYPQxSmMivgBCHZvX8E2D4gn/3OQIG42xx86hNsO3BoX+g7nFR2yWApCTOj/CryW4= X-Yahoo-Newman-Id: 411501.96831.bm@smtp114.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zcyLD50VM1kkAXHG9YS6FT.ylNVew56pxvvqG9n_wELggrC P3tIpcZwn.es5S5opVu8eMgtXmxP0tERTjzjBKqYhgc6h8mND4Wt7lr293sb oRGCw3buWBdYJtu1O6T7S087guNqV2QPEKP8RguA4MIQ9oTBSeUaAACQ645G 4_RJrVHvVWF1Ob0sMVAOtR6md.5sbgq3s0DpiaIkoG.KTzdrta53wAidTEg. 5oUfE0VT9_o1Er41WnSn6L6z9SRR5jhviMHByN1Zqh68Qb7LkeJ_rrlf6jzL WSFxDdWR9CeqB9TvA107qQ2CpfdGWNj.QP0aBtnNiHzcXw0NEcXn1BfsHC52 v5Dw5q0rMFKM.0zNcstGblBlTfFjIz3tcGWid7Y7rEKPejpf.YxRo89k.v4y QWyC1saQQ05JepfaIdIRVpbXVmLx05vXyg61PMZypyiBc13ZjHykUvsy129M a7A6V6lUFeZicwKrdmJ29KJqYBz1dLbltb2kZnH28QhoXso0xrWy839T97D8 ImDg2lp8yHlYQ6obZG8FZmsv6qXip4O5wIwdHo_ZH1cNJvn0c7Uc723YT X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.160.145 with plain [67.195.15.66]) by smtp114.sbc.mail.gq1.yahoo.com with SMTP; 30 Apr 2014 07:46:16 -0700 PDT Message-ID: <53610CB6.6000003@sbcglobal.net> Date: Wed, 30 Apr 2014 07:46:14 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: sdhci_fdt ignores clock-frequency property in .dtb References: <53601B1D.2090702@sbcglobal.net> <1398816332.22079.49.camel@revolution.hippie.lan> In-Reply-To: <1398816332.22079.49.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:46:23 -0000 It looks like one other platform uses sdhci_fdt: exynos5250 (Chromebook). See exynos5250.dtsi. The "/* TODO: verify freq */" comment leads me to think they noticed that property wasn't working. I'm okay with max-frequency. I can generate a new patch. On 4/29/14, 5:05 PM, Ian Lepore wrote: > On Tue, 2014-04-29 at 14:35 -0700, Thomas Skibo wrote: >> Another Zynq bug-fix. One Zynq board out there needs to set this >> property or else the SD card gets clocked too fast. >> >> Thanks, >> > > The documented property for this is max-frequency rather than > clock-frequency. Is this a completely new property for us, or are you > just making the code honor what's in our existing dts files? Either way > we should use the documented name, I'm just wondering if we need to fix > dts files and give folks a heads-up about the change. > > -- Ian > > > -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 15:00:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12DC8CB for ; Wed, 30 Apr 2014 15:00:48 +0000 (UTC) Received: from nm7.access.bullet.mail.gq1.yahoo.com (nm7.access.bullet.mail.gq1.yahoo.com [216.39.62.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B09671C01 for ; Wed, 30 Apr 2014 15:00:47 +0000 (UTC) Received: from [216.39.60.174] by nm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 14:53:29 -0000 Received: from [67.195.23.147] by tm10.access.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 14:53:29 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 14:53:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1398869609; bh=QWzw9fHs6mV6kXR3I4R+xiRhUhWjW70FAQbzCRPvVV4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gqI7IQZnevTsrIq09UyH7GwfsTqEZispmeC48S2q5TAnKguUibnEMBWCZOpMDRnFrUv995Z2Dqf39bw5h4rfsJ1gzfGlnWSZIoNFKmDb4Q5UKmVm+zUOZFBc6vs5sacwcsvAUPxEojC+lt8r2svzlkJpVXLUEspGSi22WUo+bH8= X-Yahoo-Newman-Id: 945134.2197.bm@smtp119.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: mT0BD0gVM1nP6qHV2mds6JyeDpVbpN4dJFXus9b.UyzSS1N 2iprp4AW.F8EPttBYMZvAhdYKW4giw64YNy0pDGy3GG4v1ClY2Xq_PDTzRaQ 2S9WEGv_JBBaDXJdZRBb64BvK07vFV8WX0aCIINIT0czcUOE9bAzXWNCPCSA LfjI.lE9Scd1Vu1oc9VjBLyMSHOHY.L2o5eR3cwchN0jDkBPap9WUGfuw.xf fbbImQrKgfXKG_aaO.AnzK39axgqe8U3GBF2LLvMSfMJdnYScQaf.nIJN8vl RZiA_6l7TzBDLvtKPEYI1CvV9LR6iNv6UmIE4RowjE8Jsp4ivT6OVWUDUmnG ZU5ZpeXWsBU6RY8vslxwnHuW9oIuDWV.DyBQmNOsi2DG.1iyprox3e59K9pS oIDkT7RLJWdtZNnZtFfkfzWndt91.0h2sabDG1Ted8Mffp6d9kaHZyHAKTZr Zo3eCL7M8CyJB4MT6EKFlniYfw9zp_MN80taBtE8LHz5slyP9dfX87YJl6G5 JSe3oEZ8Q16W8_Ud0mlqEc8FdjNB6Ceq8FMqBmOySwxO2FhtBXVx4UBTJ X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.160.145 with plain [67.195.15.66]) by smtp119.sbc.mail.gq1.yahoo.com with SMTP; 30 Apr 2014 14:53:29 +0000 UTC Message-ID: <53610E68.3010701@sbcglobal.net> Date: Wed, 30 Apr 2014 07:53:28 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ian Lepore , ticso@cicely.de Subject: Re: SMP support for ZEDBOARD References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> <536009B1.6040503@sbcglobal.net> <20140429205740.GE39364@cicely7.cicely.de> <20140429210334.GF39364@cicely7.cicely.de> <1398806331.22079.40.camel@revolution.hippie.lan> In-Reply-To: <1398806331.22079.40.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:00:48 -0000 The more I think about this, this is probably the way to go rather than risk people bricking their Parallella trying to reprogram the QSPI flash. Cram a new u-boot into a uImage and then have the new u-boot load ubldr. I'll try to prototype this on the Zedboard. On 4/29/14, 2:18 PM, Ian Lepore wrote: > > I wonder if a chain-loader is possible? Have the u-boot in flash load a > better u-boot from sdcard that has API and other goodies. > > -- Ian > > > -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 15:20:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04A123EE; Wed, 30 Apr 2014 15:20:31 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BE761D42; Wed, 30 Apr 2014 15:20:29 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s3UFK2rQ091954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Apr 2014 17:20:02 +0200 (CEST) (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 s3UFJuhE049501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2014 17:19:56 +0200 (CEST) (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 s3UFJuMn045158; Wed, 30 Apr 2014 17:19:56 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s3UFJu99045157; Wed, 30 Apr 2014 17:19:56 +0200 (CEST) (envelope-from ticso) Date: Wed, 30 Apr 2014 17:19:56 +0200 From: Bernd Walter To: Thomas Skibo Subject: Re: SMP support for ZEDBOARD Message-ID: <20140430151956.GA45142@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> <536009B1.6040503@sbcglobal.net> <20140429205740.GE39364@cicely7.cicely.de> <20140429210334.GF39364@cicely7.cicely.de> <1398806331.22079.40.camel@revolution.hippie.lan> <53610E68.3010701@sbcglobal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53610E68.3010701@sbcglobal.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:20:31 -0000 On Wed, Apr 30, 2014 at 07:53:28AM -0700, Thomas Skibo wrote: > > The more I think about this, this is probably the way to go rather than > risk people bricking their Parallella trying to reprogram the QSPI > flash. Cram a new u-boot into a uImage and then have the new u-boot > load ubldr. I'll try to prototype this on the Zedboard. Aren't there problems when u-boot starts with a system, which already has more initialisation done as usual? E.g. first u-boot enabled cache already. > On 4/29/14, 2:18 PM, Ian Lepore wrote: > > > >I wonder if a chain-loader is possible? Have the u-boot in flash load a > >better u-boot from sdcard that has API and other goodies. > > > >-- Ian > > > > > > > > -- > -------- > Thomas Skibo > ThomasSkibo@sbcglobal.net > > _______________________________________________ > 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" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 15:26:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88FFB564 for ; Wed, 30 Apr 2014 15:26:14 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 583531DE6 for ; Wed, 30 Apr 2014 15:26:13 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WfWOi-0007Vq-QC; Wed, 30 Apr 2014 15:26:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3UFQAnb017713; Wed, 30 Apr 2014 09:26:10 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19RbB2ZT+8d3gRCQmmjppH0 Subject: Re: SMP support for ZEDBOARD From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20140430151956.GA45142@cicely7.cicely.de> References: <535EEB12.2050704@sbcglobal.net> <20140429030345.GB28551@cicely7.cicely.de> <35977CB2-45FD-4703-BAAC-87E47688FB3F@netsense.nl> <535FD615.6020500@sbcglobal.net> <20140429183404.GU28551@cicely7.cicely.de> <536009B1.6040503@sbcglobal.net> <20140429205740.GE39364@cicely7.cicely.de> <20140429210334.GF39364@cicely7.cicely.de> <1398806331.22079.40.camel@revolution.hippie.lan> <53610E68.3010701@sbcglobal.net> <20140430151956.GA45142@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Apr 2014 09:26:10 -0600 Message-ID: <1398871570.22079.57.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm , Thomas Skibo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:26:14 -0000 On Wed, 2014-04-30 at 17:19 +0200, Bernd Walter wrote: > On Wed, Apr 30, 2014 at 07:53:28AM -0700, Thomas Skibo wrote: > > > > The more I think about this, this is probably the way to go rather than > > risk people bricking their Parallella trying to reprogram the QSPI > > flash. Cram a new u-boot into a uImage and then have the new u-boot > > load ubldr. I'll try to prototype this on the Zedboard. > > Aren't there problems when u-boot starts with a system, which > already has more initialisation done as usual? > E.g. first u-boot enabled cache already. I was wondering about that too, some of the "first time init" type things that u-boot does may not work if it tries to do them over. The caches should get turned off if the program is launched with bootm or bootelf, but won't be if it's launched with "go xxxxxxxx", but you can work around that using "dcache off; dcache flush; go xxxxxxx". -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 15:44:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99A7B886 for ; Wed, 30 Apr 2014 15:44:56 +0000 (UTC) Received: from nm21-vm6.access.bullet.mail.bf1.yahoo.com (nm21-vm6.access.bullet.mail.bf1.yahoo.com [216.109.115.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C50F1176 for ; Wed, 30 Apr 2014 15:44:56 +0000 (UTC) Received: from [66.196.81.164] by nm21.access.bullet.mail.bf1.yahoo.com with NNFMP; 30 Apr 2014 15:38:04 -0000 Received: from [98.139.244.53] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 30 Apr 2014 15:38:04 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.bf1.yahoo.com with NNFMP; 30 Apr 2014 15:38:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1398872284; bh=xdD3oPybVDO7pkwBdvvS9MgUvXY+Y5Rh4Vv8jStZzys=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=aPuGgUsoeBLmP3ycJRUCudzhavbsNoFbf5CisYnPRTonGTyg8azicN0RPgHed4FdcgsHWRCEyJsjJHyjPJh2TwnslWLabAhRCfDcULb+eqFDF04wcn6rLAGPetCwDRaL0bMZpglrAaNQ4V2i1x6Yx9RaCzbaliZdSIsw7BK/0Cs= X-Yahoo-Newman-Id: 201002.9838.bm@smtp115.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 33ZRKXQVM1kUx9qcsfneUrE_ORnrbFKvQhnmN5kYVX0JmTD EuCGSQYOWyopwXr27x8I8_cTYzA91RKFpm_T4eHHh9YA2HW7RF2V4npw5Fnb BYoO_1jemrH6SPIbuVlGqUbwx6ikLLhwDwP8G763vu8RI0NNCYNT_XkmXp2B x3Vq7weiHsqvaguMt1dKfgRbSkTJbcEv.0aM4Oniy97k4K6d52A7o8MdlyXq K7_8o3hNhRvapuU4WF7N_0FnODffQtoYAODvOG8BpZrcjoKi7jlo.G_TFkRl Vlvw8NJYR2MKGQ5aef68sRwmZJFtCtJcNId6HMw9NGeQoXwQ7f76SoN8ijUd gAiNFdFpZo1Hj8decFPpHKYgo2LrnvHtlhudP9EZkkWaaAu390hBNLgjBny4 kDwp39IqIPdc1rjEsFKNizlWKKI6Y.gevfC9wP.Umrj4bJpLg2Sg4.Xou8hA vgvTOERkj5pRMwo9bWkE8eSPx6pASMJSHv1n4z08pX2xfrNWjOE.qfNOi9IK 9GmtgJJMXyPuz9DJ65RcpllnFTP6cYNfqTo87TRtZyc7pVFV7hg-- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.160.145 with plain [98.139.221.42]) by smtp115.sbc.mail.bf1.yahoo.com with SMTP; 30 Apr 2014 08:38:04 -0700 PDT Message-ID: <536118D9.30902@sbcglobal.net> Date: Wed, 30 Apr 2014 08:38:01 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: sdhci_fdt ignores clock-frequency property in .dtb References: <53601B1D.2090702@sbcglobal.net> <1398816332.22079.49.camel@revolution.hippie.lan> In-Reply-To: <1398816332.22079.49.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="------------010400020803080908070908" Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:44:56 -0000 This is a multi-part message in MIME format. --------------010400020803080908070908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit New patch. On 4/29/14, 5:05 PM, Ian Lepore wrote: > On Tue, 2014-04-29 at 14:35 -0700, Thomas Skibo wrote: >> Another Zynq bug-fix. One Zynq board out there needs to set this >> property or else the SD card gets clocked too fast. >> >> Thanks, >> > > The documented property for this is max-frequency rather than > clock-frequency. Is this a completely new property for us, or are you > just making the code honor what's in our existing dts files? Either way > we should use the documented name, I'm just wondering if we need to fix > dts files and give folks a heads-up about the change. > > -- Ian > > > -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net --------------010400020803080908070908 Content-Type: text/plain; charset=UTF-8; name="patch.sdhci_fdt.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch.sdhci_fdt.txt" Index: sys/boot/fdt/dts/arm/zedboard.dts =================================================================== --- sys/boot/fdt/dts/arm/zedboard.dts (revision 265110) +++ sys/boot/fdt/dts/arm/zedboard.dts (working copy) @@ -183,7 +176,7 @@ reg = <0x100000 0x1000>; interrupts = <56>; interrupt-parent = <&GIC>; - clock-frequency = <50000000>; + max-frequency = <50000000>; }; // QSPI Index: sys/boot/fdt/dts/arm/exynos5250.dtsi =================================================================== --- sys/boot/fdt/dts/arm/exynos5250.dtsi (revision 265110) +++ sys/boot/fdt/dts/arm/exynos5250.dtsi (working copy) @@ -126,7 +126,7 @@ reg = <0x12200000 0x1000>; interrupts = <107>; interrupt-parent = <&GIC>; - clock-frequency = <24000000>; /* TODO: verify freq */ + max-frequency = <24000000>; /* TODO: verify freq */ }; sdhci@12210000 { @@ -134,7 +134,7 @@ reg = <0x12210000 0x1000>; interrupts = <108>; interrupt-parent = <&GIC>; - clock-frequency = <24000000>; + max-frequency = <24000000>; }; sdhci@12220000 { @@ -142,7 +142,7 @@ reg = <0x12220000 0x1000>; interrupts = <109>; interrupt-parent = <&GIC>; - clock-frequency = <24000000>; + max-frequency = <24000000>; }; sdhci@12230000 { @@ -150,7 +150,7 @@ reg = <0x12230000 0x1000>; interrupts = <110>; interrupt-parent = <&GIC>; - clock-frequency = <24000000>; + max-frequency = <24000000>; }; serial0: serial@12C00000 { Index: sys/dev/sdhci/sdhci_fdt.c =================================================================== --- sys/dev/sdhci/sdhci_fdt.c (revision 265110) +++ sys/dev/sdhci/sdhci_fdt.c (working copy) @@ -66,6 +66,7 @@ device_t dev; /* Controller device */ u_int quirks; /* Chip specific quirks */ u_int caps; /* If we override SDHCI_CAPABILITIES */ + uint32_t max_clk; /* Max possible freq */ struct resource *irq_res; /* IRQ resource */ void *intrhand; /* Interrupt handle */ @@ -156,6 +157,7 @@ sc->quirks = 0; sc->num_slots = 1; + sc->max_clk = 0; if (!ofw_bus_status_okay(dev)) return (ENXIO); @@ -170,11 +172,14 @@ node = ofw_bus_get_node(dev); - /* Allow dts to patch quirks and slots. */ - if ((OF_getprop(node, "quirks", &cid, sizeof(cid))) > 0) - sc->quirks = fdt32_to_cpu(cid); - if ((OF_getprop(node, "num-slots", &cid, sizeof(cid))) > 0) - sc->num_slots = fdt32_to_cpu(cid); + /* Allow dts to patch quirks, slots, and max-frequency. */ + if ((OF_getencprop(node, "quirks", &cid, sizeof(cid))) > 0) + sc->quirks = cid; + if ((OF_getencprop(node, "num-slots", &cid, sizeof(cid))) > 0) + sc->num_slots = cid; + if ((OF_getencprop(node, "max-frequency", &cid, sizeof(cid))) > 0) + sc->max_clk = cid; + return (0); } @@ -214,6 +219,7 @@ slot->quirks = sc->quirks; slot->caps = sc->caps; + slot->max_clk = sc->max_clk; if (sdhci_init_slot(dev, slot, i) != 0) continue; --------------010400020803080908070908-- From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 16:19:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDA5420E for ; Wed, 30 Apr 2014 16:19:14 +0000 (UTC) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B6D814C0 for ; Wed, 30 Apr 2014 16:19:14 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id rd3so2216910pab.30 for ; Wed, 30 Apr 2014 09:19:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5LjwgNbOIZAn0Zrymabu1f0bAicMBymuVuOHQQfAD84=; b=DbYRPd0U4Srk6Ih+cZtkrGG4shYiv7QY6AFSl98fSaqWINE8QFngQvq2uQY+AEZ9PB r2u7v0nqphRNnukn91aPSg/reoxcmCyMkcU33kxqN6RnXxLemjxC0HjWMLEu+zhIjAVe /UhApLXbsDtVXIC9IZFXmD/vZdQr8v2d3cpQSmCF06ZJeEf15j/sozVQmhysk/o4aewV /el2JOigU3OQKtjTH+K9m1YAuawj5fvHb+09l3NEv2qyrNdd7/dh66zY0jAxYNa9VWBA bLhPJHtS2Obf0NWNrnxnTCFLlb4oGbyF738c5c/Wh2kvuG2rGCt/E5qv+1xYjMgHmBWi sDnQ== X-Gm-Message-State: ALoCoQmNC6KWiIZdhHSY+ZnxLRUX1teNWge8ki1k2wOEzmsybKN8MlLD4dfbYK1Y4nlGLJJjlJnh X-Received: by 10.66.150.69 with SMTP id ug5mr9685403pab.55.1398871505582; Wed, 30 Apr 2014 08:25:05 -0700 (PDT) Received: from macintosh-3c0754232d17.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id te2sm137736200pac.25.2014.04.30.08.25.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 08:25:03 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_6AB31DAB-4804-4702-852D-D61733E99366"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: sdhci_fdt ignores clock-frequency property in .dtb From: Warner Losh In-Reply-To: <53610CB6.6000003@sbcglobal.net> Date: Wed, 30 Apr 2014 09:24:49 -0600 Message-Id: References: <53601B1D.2090702@sbcglobal.net> <1398816332.22079.49.camel@revolution.hippie.lan> <53610CB6.6000003@sbcglobal.net> To: Thomas Skibo X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 16:19:14 -0000 --Apple-Mail=_6AB31DAB-4804-4702-852D-D61733E99366 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 h= ttp://svnweb.freebsd.org/base/vendor/device-tree/dist/Bindings/mmc/mmc.txt= ?revision=3D262573&view=3Dmarkup has the standard which we try to follow (but sometimes fall short) on. = There=92s several properties we currently ignore, but perhaps shouldn=92t.= Warner On Apr 30, 2014, at 8:46 AM, Thomas Skibo = wrote: >=20 > It looks like one other platform uses sdhci_fdt: exynos5250 = (Chromebook). See exynos5250.dtsi. The "/* TODO: verify freq */" = comment leads me to think they noticed that property wasn't working. >=20 > I'm okay with max-frequency. I can generate a new patch. >=20 > On 4/29/14, 5:05 PM, Ian Lepore wrote: >> On Tue, 2014-04-29 at 14:35 -0700, Thomas Skibo wrote: >>> Another Zynq bug-fix. One Zynq board out there needs to set this >>> property or else the SD card gets clocked too fast. >>>=20 >>> Thanks, >>>=20 >>=20 >> The documented property for this is max-frequency rather than >> clock-frequency. Is this a completely new property for us, or are = you >> just making the code honor what's in our existing dts files? Either = way >> we should use the documented name, I'm just wondering if we need to = fix >> dts files and give folks a heads-up about the change. >>=20 >> -- Ian >>=20 >>=20 >>=20 >=20 > --=20 > -------- > Thomas Skibo > ThomasSkibo@sbcglobal.net >=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" --Apple-Mail=_6AB31DAB-4804-4702-852D-D61733E99366 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTYRXBAAoJEGwc0Sh9sBEA3GYP/0SuS3huBjZ9wfKjYk9ZNlEx pN2qlzCp90eYJy54NgYPJS5jR8vhXYEGvX4rSn81ip4hFTEoNXZ4QWCVZ7zq1l+O uIt7DkvTqzWYa73A3uo6ZwhvCXuzo1jzMYvZXhyFI06/ffRmsPwb37Jc1zcF0AiK UEDwG7eTQQyVoPXbX7awGU8onYprxUjs0Z0UX7jJ8+wEEOAJUVyovavNoFyAovfm BhI+A1Q7bHD73dDUwgNrf4V3usVpaODpVKj91GXfbt/BK14mbrQaSuJ1BSjkHdZV NVOND1mSm2rg0XCBh0F+KE+ce3GAXBNbGML5+gsJFRWreIob8UMQHIke2rF8rQuB 7uA1pqNhYAHIfaUgflHD1kInHe0vxeJtwhALTIkxLnubCsbEdlh3jqILPGkaRe8T VFzMizChfVBC0vQa1h4yBaZZOv9RKoZYufwtmhmLIzhU7kKKN7sT8nYLfGnl209L nUp39vfypASNY536/RQ65qtVXKhzqg0PdsKrH8nussrBQ11AvojKMlRHUdPGXPIK dFT1JwcvaVqCpC2Zp83qv64c4LkDunM26Iee5tO+E5C6xNfKPju+HHBFxTRU7xoP sNkVH0zN6DHcbQ8G9pGJMpGEmhp/q1Raw/ALjdOtP6nr5yeWu6M4iFC+iHFn+ydh gmWUHKC865UAtvcebhcA =AgjB -----END PGP SIGNATURE----- --Apple-Mail=_6AB31DAB-4804-4702-852D-D61733E99366-- From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 18:58:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 154978D9; Wed, 30 Apr 2014 18:58:39 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79B17172A; Wed, 30 Apr 2014 18:58:38 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y10so2170043wgg.12 for ; Wed, 30 Apr 2014 11:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lzrrpZWf6HIK7xccvhmPkvteT/xp8BST0mHFN1o7nLQ=; b=nNuzgYTpJ4p68+PIb0cX0VIb5GjK1qJ4T5JnHfE4Ohlf0NrX1JIxPQI1BuHVqC4GO8 e1aYXhmSbxueFX4htp+W5IfEWrj1L2mo3Y6S22drVGaXeM6j/leBuOPrxkjPny7Z6WT2 ztT3vtkmvSWj3GB+vfXk/wsg8BgZOXcg//qgSOlMuO9SAZbbWHh3CD19T7o7WHNAJD2q bZNvUyT4mzu1aDhUKHygXn4r8Zxww/JwPaldJPsnRR8/MO5ilZcaTgSTgHtQ8chwc8GB 2SOCjfzj3fJrfuwYBx126LQxbpu7HHpMwtqI2cZFZPzw37AFES0tvxU7B+ayAm4W1isL PS8g== MIME-Version: 1.0 X-Received: by 10.194.24.194 with SMTP id w2mr5336552wjf.25.1398884316685; Wed, 30 Apr 2014 11:58:36 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 30 Apr 2014 11:58:36 -0700 (PDT) In-Reply-To: References: <7249A68B-E3D4-4795-BD51-4DF149B4104A@gmail.com> <746D7AE2-54D1-4758-816F-4954F3F01A5E@gmail.com> <535C7E1B.1090605@hot.ee> <535D1576.6040005@gmail.com> Date: Wed, 30 Apr 2014 14:58:36 -0400 Message-ID: Subject: Re: BBB 1GHz patches for u-boot 2014-01 From: Winston Smith To: fabiodive Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM , Xuebing Wang X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 18:58:39 -0000 On Wed, Apr 30, 2014 at 9:26 AM, fabiodive wrote: > I also had the same problem during crochet building, > in the end I solved it changing the crochet script, > I disabled an u-boot checking block and I changed the > source path where to install from the u-boot forcing the > absolute path of the port, that was a dirty fix because I wanted first > to see if the patch set works. After installing u-boot-beaglebone-eabi, it puts the results in /usr/local/share/u-boot/beaglebone-eabi. The problem is that the crotchet scripts are looking for a tool called `u-boot-beaglebone-eabi-install` that appears to install u-boot into the directory specified as the argument. I can't find this script anywhere, so I wrote one: http://pastebin.com/FJfrqThb If you put this somewhere in the path (e.g. /usr/local/bin), and in your crotchet-config you need to: 1) Comment out: BEAGLEBONE_UBOOT_SRC 2) Add the following: BEAGLEBONE_UBOOT_PATCH_VERSION=2014.01 Assuming you've already done `make ; make install` in /usr/ports/sysutils/u-boot-beaglebone-eabi, you should be able to re-run crotchet and it will pick up the u-boot-beaglebone-eabi version (which, if you apply the patches should run at 1Ghz). Hope this helps someone! -W From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 20:14:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D79B6A65 for ; Wed, 30 Apr 2014 20:14:35 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7710B1200 for ; Wed, 30 Apr 2014 20:14:35 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hm4so1618570wib.4 for ; Wed, 30 Apr 2014 13:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4N1z/QEauTH/BrNEsu61rCO65CckLOTjKmGgd5HWYd0=; b=IXmkLWFq5l/H1WzTfF6RiJSzSrjoUg4xzJ4EFo7WOunKDGQ7ZlREE2xKw/EG6Qv9/6 Oe9DfX4uUnyIeSfUJLcqtBizlxjLF/wGMPlKC6/yktlNiKYQPuGzrit3xLXR8b9EGS6n vqGYGWBH9AzIfKKMcvvf6S/iBZBrOTZARcN4E4rZBatlrAzB2fcSv8OKIYVOYwS3eJa8 /ngxLR0mHMeIKZlRaHzm+4ZDAiqruaPAQt7pXj4hrLwo9omxD5OauR3BenYlEWGbFF86 jNjpqS6RcARoc53Ov2T5ljlZe8uJSY2Tb5w3orWjQ+J3beMY42r41maoreG1Zkngnq/U SmSw== MIME-Version: 1.0 X-Received: by 10.180.228.42 with SMTP id sf10mr5212787wic.33.1398888873520; Wed, 30 Apr 2014 13:14:33 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 30 Apr 2014 13:14:33 -0700 (PDT) Date: Wed, 30 Apr 2014 16:14:33 -0400 Message-ID: Subject: FreeBSD-CURRENT/Makefile.inc1 line 1834: "FDT_DTS_FILE must be specified!" From: Winston Smith To: FreeBSD ARM Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:14:35 -0000 Anyone else seeing this (as of r265159) trying to cross compile the tools for ARM (I have run clean on this): [root@freebsd /usr/src/FreeBSD-CURRENT]# make XDEV=arm XDEV_ARCH=armv6 xdev mkdir -p /usr/obj/armv6-freebsd//usr/src/FreeBSD-CURRENT/tmp/usr mtree -deU -f /usr/src/FreeBSD-CURRENT/etc/mtree/BSD.usr.dist -p /usr/obj/armv6-freebsd//usr/src/FreeBSD-CURRENT/tmp/usr >/dev/null ===> lib/clang/libllvmsupport (obj,depend,all,install) ===> lib/clang/libllvmtablegen (obj,depend,all,install) ===> usr.bin/clang/tblgen (obj,depend,all,install) sh /usr/src/FreeBSD-CURRENT/tools/install.sh -s -o root -g wheel -m 555 tblgen /usr/obj/armv6-freebsd//usr/src/FreeBSD-CURRENT/tmp/usr/bin/tblgen ===> usr.bin/clang/clang-tblgen (obj,depend,all,install) sh /usr/src/FreeBSD-CURRENT/tools/install.sh -s -o root -g wheel -m 555 clang-tblgen /usr/obj/armv6-freebsd//usr/src/FreeBSD-CURRENT/tmp/usr/bin/clang-tblgen make[2]: "/usr/src/FreeBSD-CURRENT/Makefile.inc1" line 1834: "FDT_DTS_FILE must be specified!" *** Error code 1 Stop. make[1]: stopped in /usr/src/FreeBSD-CURRENT *** Error code 1 Stop. make: stopped in /usr/src/FreeBSD-CURRENT From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 20:55:46 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DC62711 for ; Wed, 30 Apr 2014 20:55:46 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26A1815EF for ; Wed, 30 Apr 2014 20:55:45 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WfbXc-0008xV-8x; Wed, 30 Apr 2014 20:55:44 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3UKtfjC017927; Wed, 30 Apr 2014 14:55:41 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19YXQ39rPUoRQwmW28UR1T2 Subject: Re: FreeBSD-CURRENT/Makefile.inc1 line 1834: "FDT_DTS_FILE must be specified!" From: Ian Lepore To: Winston Smith In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Apr 2014 14:55:41 -0600 Message-ID: <1398891341.22079.72.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:55:46 -0000 On Wed, 2014-04-30 at 16:14 -0400, Winston Smith wrote: > Anyone else seeing this (as of r265159) trying to cross compile the > tools for ARM (I have run clean on this): > > [root@freebsd /usr/src/FreeBSD-CURRENT]# make XDEV=arm XDEV_ARCH=armv6 xdev > mkdir -p /usr/obj/armv6-freebsd//usr/src/FreeBSD-CURRENT/tmp/usr > mtree -deU -f /usr/src/FreeBSD-CURRENT/etc/mtree/BSD.usr.dist -p > /usr/obj/armv6-freebsd//usr/src/FreeBSD-CURRENT/tmp/usr >/dev/null > ===> lib/clang/libllvmsupport (obj,depend,all,install) > ===> lib/clang/libllvmtablegen (obj,depend,all,install) > ===> usr.bin/clang/tblgen (obj,depend,all,install) > sh /usr/src/FreeBSD-CURRENT/tools/install.sh -s -o root -g wheel -m > 555 tblgen /usr/obj/armv6-freebsd//usr/src/FreeBSD-CURRENT/tmp/usr/bin/tblgen > ===> usr.bin/clang/clang-tblgen (obj,depend,all,install) > sh /usr/src/FreeBSD-CURRENT/tools/install.sh -s -o root -g wheel -m > 555 clang-tblgen > /usr/obj/armv6-freebsd//usr/src/FreeBSD-CURRENT/tmp/usr/bin/clang-tblgen > make[2]: "/usr/src/FreeBSD-CURRENT/Makefile.inc1" line 1834: > "FDT_DTS_FILE must be specified!" > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src/FreeBSD-CURRENT > *** Error code 1 > > Stop. > make: stopped in /usr/src/FreeBSD-CURRENT Yep, there was a bug. Fixed in r265163. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 21:06:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29E2CB00; Wed, 30 Apr 2014 21:06:01 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96060169E; Wed, 30 Apr 2014 21:06:00 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id f8so3625315wiw.15 for ; Wed, 30 Apr 2014 14:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5HwG3/Yq0qzuXSeLsNv77au0vvrAc4YGpxd1HtbNxbM=; b=LvGJZhwIbLRDi1Zt2JWGwqpMH3ruZ76U6yDDZOYj/PxZtImeGpnhCla7mI5v5tCwDb Ji5hWc8MF4bBsy/vxJbtp+7AIEtWDzFg/ny11aeP6TmhWi1OHC+w4pJJ8H6QusHvfSVE +htjF4UcCV29bkYsRnMq8c9lElCEO8eFmPr8sBun9QRPPYoM+e7cxEeYrFEV4QtmR3bV 3DALqbwJMJPDIvG3esr+eCHwpb3rCmfYMc2NVPUAYENSgsyx568GFMnlbtRtnLYgk4ff LXw8MUuB/rMd4QIzLoPwR69Pjs7yGa+ZT4zNT5e7kp1pXRL3Ru2bTujzwTqOV0q/x4d+ ZnaA== MIME-Version: 1.0 X-Received: by 10.180.76.146 with SMTP id k18mr5425045wiw.5.1398891958909; Wed, 30 Apr 2014 14:05:58 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 30 Apr 2014 14:05:58 -0700 (PDT) In-Reply-To: <1398891341.22079.72.camel@revolution.hippie.lan> References: <1398891341.22079.72.camel@revolution.hippie.lan> Date: Wed, 30 Apr 2014 17:05:58 -0400 Message-ID: Subject: Re: FreeBSD-CURRENT/Makefile.inc1 line 1834: "FDT_DTS_FILE must be specified!" From: Winston Smith To: Ian Lepore , Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:06:01 -0000 On Wed, Apr 30, 2014 at 4:41 PM, Warner Losh wrote: > Stupid Makefile Parsing Rules=E2=80=A6 > > I=E2=80=99ll fix it=E2=80=A6 On Wed, Apr 30, 2014 at 4:55 PM, Ian Lepore wrote: > Yep, there was a bug. Fixed in r265163. Excellent, it builds now. Thanks for the quick response! From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 22:24:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D2647DD for ; Wed, 30 Apr 2014 22:24:56 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F1171E6F for ; Wed, 30 Apr 2014 22:24:55 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id f8so2999981wiw.2 for ; Wed, 30 Apr 2014 15:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zSVEDykMbGzyRdSu8JuDatGmpp9VUcUu8IgaT+Q1Kmw=; b=Vn1y/AqHIHVeg0Ymbfv2ZH8hzyMQOOC14AWMxDwoYq90JErKtmbc9YxzEFcrwV0b4s GXdfpvfYmSjEq+57GuB25ertbO816V4lOnSHEA1lgxXhMf5JxGZEH9NSzS6xjTrc/XjR jLlqYrvKV7n3sPtZTDF5GTl0HTSCGgavh6pjFe32EE7CHEbDLTNHTFBmN/JiGy4GDGa8 cU2eVjT5Nhm12tYQXX0wlf1Mzu/KeFMSQ0wttD7as2rfcuh2kU4VEsSN/+4m7M17Z2Ed uv62Yi5CNQyAhI4/GeX/o74kOezqHxPTppBjacrl13/MJtyLSWut+gyQCR9tt1+PH7da LpEw== MIME-Version: 1.0 X-Received: by 10.180.8.136 with SMTP id r8mr5651700wia.60.1398896693494; Wed, 30 Apr 2014 15:24:53 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 30 Apr 2014 15:24:53 -0700 (PDT) Date: Wed, 30 Apr 2014 18:24:53 -0400 Message-ID: Subject: BBB @ 1Ghz hangs with 10-STABLE (11-CURRENT is ok) From: Winston Smith To: FreeBSD ARM Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 22:24:56 -0000 After getting a 2014.01 u-boot built with Xuebing's patches, I found that 10-STABLE hangs at some point after the kernel has configured the usb hubs. The abbreviated console log is below; since the kernel had booted, I was able to get a stack trace (also included below). However, the patched u-boot works ok with 11-CURRENT. Looking at the patches, it wasn't immediately apparent as to what exactly enables the 1Ghz mode ... maybe it's just having a newer u-boot? Is there something specific in 11-CURRENT that enables/supports the 1Ghz operation? Thanks! -W --- -Boot SPL 2014.01 (Apr 29 2014 - 18:25:45) reading args spl: error reading image args, err - -1 reading bb-uboot.img reading bb-uboot.img U-Boot 2014.01 (Apr 29 2014 - 18:25:45) I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment Net: not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading bb-uEnv.txt reading bbubldr 251703 bytes read in 17 ms (14.1 MiB/s) reading bboneblk.dtb 15278 bytes read in 5 ms (2.9 MiB/s) ## Starting application at 0x88000054 ... Consoles: U-Boot console Compatible U-Boot API signature found @9f62b240 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@freebsd, Tue Apr 29 12:08:39 EDT 2014) DRAM: 512MB Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... good. Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x468f08+0x17d8dc syms=[0x4+0x84b30+0x4+0x501f3] /boot/kernel/geom_label.ko text=0x50dc data=0x864+0x30 syms=[0x4+0x1020+0x4+0xfe2] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x0x80000100. Kernel entry at 0x80200100... ... Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 mmcsd0: 4GB at mmc0 48.0MHz/4bit/65535-block uhub0: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered random: unblocking device. KDB: enter: Break to debugger [ thread pid 10 tid 100002 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> trace Tracing pid 10 tid 100002 td 0xc279b320 db_trace_self() at db_trace_self pc = 0xc054086c lr = 0xc022e3c0 (db_stack_trace+0xf4) sp = 0xdbe5da28 fp = 0xdbe5da40 r10 = 0xc07e1850 db_stack_trace() at db_stack_trace+0xf4 pc = 0xc022e3c0 lr = 0xc022dd30 (db_command+0x270) sp = 0xdbe5da48 fp = 0xdbe5dae8 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000063 db_command() at db_command+0x270 pc = 0xc022dd30 lr = 0xc022da94 (db_command_loop+0x60) sp = 0xdbe5daf0 fp = 0xdbe5db00 r4 = 0xc05829b1 r5 = 0xc059dbfc r6 = 0xc07e183c r7 = 0xdbe5dcd0 r8 = 0xc067e3a0 r9 = 0xc067e3a4 r10 = 0xc063b060 db_command_loop() at db_command_loop+0x60 pc = 0xc022da94 lr = 0xc023045c (db_trap+0xd8) sp = 0xdbe5db08 fp = 0xdbe5dc28 r4 = 0x00000000 r5 = 0xc07e1848 r6 = 0xc067e3d0 db_trap() at db_trap+0xd8 pc = 0xc023045c lr = 0xc0399170 (kdb_trap+0xd4) sp = 0xdbe5dc30 fp = 0xdbe5dc50 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc067e3d0 r7 = 0xdbe5dcd0 kdb_trap() at kdb_trap+0xd4 pc = 0xc0399170 lr = 0xc05535a8 (undefinedinstruction+0x2b0) sp = 0xdbe5dc58 fp = 0xdbe5dcc8 r4 = 0x00000000 r5 = 0xc0553240 r6 = 0x00000000 r7 = 0xe7ffffff r8 = 0xc279b320 r9 = 0xdbe5dcd0 r10 = 0xc03989a4 undefinedinstruction() at undefinedinstruction+0x2b0 pc = 0xc05535a8 lr = 0xc0542374 (exception_exit) sp = 0xdbe5dcd0 fp = 0xdbe5dd28 r4 = 0x00000001 r5 = 0xdbe5ddb8 r6 = 0xc2805b74 r7 = 0x00060000 r8 = 0x00000001 r9 = 0xc064014c r10 = 0xc2805a00 exception_exit() at exception_exit pc = 0xc0542374 lr = 0xc0398994 (kdb_break+0x50) sp = 0xdbe5dd24 fp = 0xdbe5dd28 r0 = 0xc067e3b4 r1 = 0x00000000 r2 = 0x00000001 r3 = 0x60000193 r4 = 0x00000001 r5 = 0xdbe5ddb8 r6 = 0xc2805b74 r7 = 0x00060000 r8 = 0x00000001 r9 = 0xc064014c r10 = 0xc2805a00 r12 = 0x00000000 $a() at $a pc = 0xc03989a8 lr = 0xc02612f0 (uart_intr+0x9c) sp = 0xdbe5dd30 fp = 0xdbe5dd70 r4 = 0x00000000 uart_intr() at uart_intr+0x9c pc = 0xc02612f0 lr = 0xc0333050 (intr_event_handle+0x80) sp = 0xdbe5dd78 fp = 0xdbe5dd98 r4 = 0xc267ae00 r5 = 0xdbe5ddb8 r6 = 0xc0666dd0 r7 = 0xc279b320 r8 = 0x00000000 r9 = 0xc0597b05 r10 = 0xc27f2c00 intr_event_handle() at intr_event_handle+0x80 pc = 0xc0333050 lr = 0xc0543598 (arm_handler_execute+0x50) sp = 0xdbe5dda0 fp = 0xdbe5ddb0 r4 = 0xdbe5ddb8 r5 = 0x00000048 r6 = 0xc0666dd0 r7 = 0xc07def68 r8 = 0x00274e80 r9 = 0xc0668184 r10 = 0xc08dd004 arm_handler_execute() at arm_handler_execute+0x50 pc = 0xc0543598 lr = 0xc0561118 (irq_entry+0x6c) sp = 0xdbe5ddb8 fp = 0xdbe5de10 r4 = 0x00000001 r5 = 0xc059fdf3 r6 = 0xc07e3490 r7 = 0xc067df4c irq_entry() at irq_entry+0x6c pc = 0xc0561118 lr = 0xc0543bec (cpu_idle+0x24) sp = 0xdbe5de0c fp = 0xdbe5de10 r0 = 0x00000001 r1 = 0x00015924 r2 = 0x00000002 r3 = 0x00000000 r4 = 0x00000001 r5 = 0xc059fdf3 r6 = 0xc07e3490 r7 = 0xc067df4c r8 = 0x00274e80 r9 = 0xc0668184 r10 = 0xc08dd004 r12 = 0x00000000 sched_runnable() at sched_runnable pc = 0xc038773c lr = 0xc0388a0c (sched_idletd+0xc4) sp = 0xdbe5de18 fp = 0xdbe5de38 sched_idletd() at sched_idletd+0xc4 pc = 0xc0388a0c lr = 0xc03307ac (fork_exit+0x88) sp = 0xdbe5de40 fp = 0xdbe5de58 r4 = 0xc279b320 r5 = 0xc2798320 r6 = 0xc0388948 r7 = 0x00000000 r8 = 0xdbe5de60 r9 = 0x00000000 r10 = 0x00000000 fork_exit() at fork_exit+0x88 pc = 0xc03307ac lr = 0xc0551b0c (fork_trampoline+0x14) sp = 0xdbe5de60 fp = 0x00000000 r4 = 0xc0388948 r5 = 0x00000000 r6 = 0x3bffcfdb r7 = 0xf9fcd7ef r8 = 0x00000000 fork_trampoline() at fork_trampoline+0x14 pc = 0xc0551b0c lr = 0xc0551b0c (fork_trampoline+0x14) sp = 0xdbe5de60 fp = 0x00000000 Unable to unwind further db> From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 22:41:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE307B2E for ; Wed, 30 Apr 2014 22:41:41 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B10C41126 for ; Wed, 30 Apr 2014 22:41:41 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WfdC7-000IS6-Qf; Wed, 30 Apr 2014 22:41:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3UMfbCF018011; Wed, 30 Apr 2014 16:41:37 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19H1E5dSxpiKFDCYo5enfVy Subject: Re: BBB @ 1Ghz hangs with 10-STABLE (11-CURRENT is ok) From: Ian Lepore To: Winston Smith In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Apr 2014 16:41:37 -0600 Message-ID: <1398897697.22079.80.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 22:41:42 -0000 On Wed, 2014-04-30 at 18:24 -0400, Winston Smith wrote: > After getting a 2014.01 u-boot built with Xuebing's patches, I found > that 10-STABLE hangs at some point after the kernel has configured the > usb hubs. The abbreviated console log is below; since the kernel had > booted, I was able to get a stack trace (also included below). > > However, the patched u-boot works ok with 11-CURRENT. Looking at the > patches, it wasn't immediately apparent as to what exactly enables the > 1Ghz mode ... maybe it's just having a newer u-boot? > > Is there something specific in 11-CURRENT that enables/supports the > 1Ghz operation? > > Thanks! > > > -W > --- > > > -Boot SPL 2014.01 (Apr 29 2014 - 18:25:45) > reading args > spl: error reading image args, err - -1 > reading bb-uboot.img > reading bb-uboot.img > > > U-Boot 2014.01 (Apr 29 2014 - 18:25:45) > > I2C: ready > DRAM: 512 MiB > NAND: 0 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > *** Warning - readenv() failed, using default environment > > Net: not set. Validating first E-fuse MAC > cpsw, usb_ether > Hit any key to stop autoboot: 0 > mmc0 is current device > SD/MMC found on device 0 > reading bb-uEnv.txt > reading bbubldr > 251703 bytes read in 17 ms (14.1 MiB/s) > reading bboneblk.dtb > 15278 bytes read in 5 ms (2.9 MiB/s) > ## Starting application at 0x88000054 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @9f62b240 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@freebsd, Tue Apr 29 12:08:39 EDT 2014) > > DRAM: 512MB > Number of U-Boot devices: 2 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=0 slice= partition=... good. > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x468f08+0x17d8dc syms=[0x4+0x84b30+0x4+0x501f3] > /boot/kernel/geom_label.ko text=0x50dc data=0x864+0x30 > syms=[0x4+0x1020+0x4+0xfe2] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by U-Boot at address 0x0x80000100. > Kernel entry at 0x80200100... > > ... > > > Timecounters tick every 10.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > ugen1.1: at usbus1 > uhub0: 1> on usbus1 > ugen0.1: at usbus0 > uhub1: 1> on usbus0 > mmcsd0: 4GB at mmc0 > 48.0MHz/4bit/65535-block > uhub0: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > random: unblocking device. > > KDB: enter: Break to debugger > [ thread pid 10 tid 100002 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> trace > Tracing pid 10 tid 100002 td 0xc279b320 > db_trace_self() at db_trace_self > pc = 0xc054086c lr = 0xc022e3c0 (db_stack_trace+0xf4) > sp = 0xdbe5da28 fp = 0xdbe5da40 > r10 = 0xc07e1850 > db_stack_trace() at db_stack_trace+0xf4 > pc = 0xc022e3c0 lr = 0xc022dd30 (db_command+0x270) > sp = 0xdbe5da48 fp = 0xdbe5dae8 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000063 > db_command() at db_command+0x270 > pc = 0xc022dd30 lr = 0xc022da94 (db_command_loop+0x60) > sp = 0xdbe5daf0 fp = 0xdbe5db00 > r4 = 0xc05829b1 r5 = 0xc059dbfc > r6 = 0xc07e183c r7 = 0xdbe5dcd0 > r8 = 0xc067e3a0 r9 = 0xc067e3a4 > r10 = 0xc063b060 > db_command_loop() at db_command_loop+0x60 > pc = 0xc022da94 lr = 0xc023045c (db_trap+0xd8) > sp = 0xdbe5db08 fp = 0xdbe5dc28 > r4 = 0x00000000 r5 = 0xc07e1848 > r6 = 0xc067e3d0 > db_trap() at db_trap+0xd8 > pc = 0xc023045c lr = 0xc0399170 (kdb_trap+0xd4) > sp = 0xdbe5dc30 fp = 0xdbe5dc50 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc067e3d0 r7 = 0xdbe5dcd0 > kdb_trap() at kdb_trap+0xd4 > pc = 0xc0399170 lr = 0xc05535a8 (undefinedinstruction+0x2b0) > sp = 0xdbe5dc58 fp = 0xdbe5dcc8 > r4 = 0x00000000 r5 = 0xc0553240 > r6 = 0x00000000 r7 = 0xe7ffffff > r8 = 0xc279b320 r9 = 0xdbe5dcd0 > r10 = 0xc03989a4 > undefinedinstruction() at undefinedinstruction+0x2b0 > pc = 0xc05535a8 lr = 0xc0542374 (exception_exit) > sp = 0xdbe5dcd0 fp = 0xdbe5dd28 > r4 = 0x00000001 r5 = 0xdbe5ddb8 > r6 = 0xc2805b74 r7 = 0x00060000 > r8 = 0x00000001 r9 = 0xc064014c > r10 = 0xc2805a00 > exception_exit() at exception_exit > pc = 0xc0542374 lr = 0xc0398994 (kdb_break+0x50) > sp = 0xdbe5dd24 fp = 0xdbe5dd28 > r0 = 0xc067e3b4 r1 = 0x00000000 > r2 = 0x00000001 r3 = 0x60000193 > r4 = 0x00000001 r5 = 0xdbe5ddb8 > r6 = 0xc2805b74 r7 = 0x00060000 > r8 = 0x00000001 r9 = 0xc064014c > r10 = 0xc2805a00 r12 = 0x00000000 > $a() at $a > pc = 0xc03989a8 lr = 0xc02612f0 (uart_intr+0x9c) > sp = 0xdbe5dd30 fp = 0xdbe5dd70 > r4 = 0x00000000 > uart_intr() at uart_intr+0x9c > pc = 0xc02612f0 lr = 0xc0333050 (intr_event_handle+0x80) > sp = 0xdbe5dd78 fp = 0xdbe5dd98 > r4 = 0xc267ae00 r5 = 0xdbe5ddb8 > r6 = 0xc0666dd0 r7 = 0xc279b320 > r8 = 0x00000000 r9 = 0xc0597b05 > r10 = 0xc27f2c00 > intr_event_handle() at intr_event_handle+0x80 > pc = 0xc0333050 lr = 0xc0543598 (arm_handler_execute+0x50) > sp = 0xdbe5dda0 fp = 0xdbe5ddb0 > r4 = 0xdbe5ddb8 r5 = 0x00000048 > r6 = 0xc0666dd0 r7 = 0xc07def68 > r8 = 0x00274e80 r9 = 0xc0668184 > r10 = 0xc08dd004 > arm_handler_execute() at arm_handler_execute+0x50 > pc = 0xc0543598 lr = 0xc0561118 (irq_entry+0x6c) > sp = 0xdbe5ddb8 fp = 0xdbe5de10 > r4 = 0x00000001 r5 = 0xc059fdf3 > r6 = 0xc07e3490 r7 = 0xc067df4c > irq_entry() at irq_entry+0x6c > pc = 0xc0561118 lr = 0xc0543bec (cpu_idle+0x24) > sp = 0xdbe5de0c fp = 0xdbe5de10 > r0 = 0x00000001 r1 = 0x00015924 > r2 = 0x00000002 r3 = 0x00000000 > r4 = 0x00000001 r5 = 0xc059fdf3 > r6 = 0xc07e3490 r7 = 0xc067df4c > r8 = 0x00274e80 r9 = 0xc0668184 > r10 = 0xc08dd004 r12 = 0x00000000 > sched_runnable() at sched_runnable > pc = 0xc038773c lr = 0xc0388a0c (sched_idletd+0xc4) > sp = 0xdbe5de18 fp = 0xdbe5de38 > sched_idletd() at sched_idletd+0xc4 > pc = 0xc0388a0c lr = 0xc03307ac (fork_exit+0x88) > sp = 0xdbe5de40 fp = 0xdbe5de58 > r4 = 0xc279b320 r5 = 0xc2798320 > r6 = 0xc0388948 r7 = 0x00000000 > r8 = 0xdbe5de60 r9 = 0x00000000 > r10 = 0x00000000 > fork_exit() at fork_exit+0x88 > pc = 0xc03307ac lr = 0xc0551b0c (fork_trampoline+0x14) > sp = 0xdbe5de60 fp = 0x00000000 > r4 = 0xc0388948 r5 = 0x00000000 > r6 = 0x3bffcfdb r7 = 0xf9fcd7ef > r8 = 0x00000000 > fork_trampoline() at fork_trampoline+0x14 > pc = 0xc0551b0c lr = 0xc0551b0c (fork_trampoline+0x14) > sp = 0xdbe5de60 fp = 0x00000000 > Unable to unwind further > db> That backtrace is just the idle thread; usually that's a sign that some device driver is waiting for an interrupt to finish configuring the device and it never gets it and just hangs. Often usb is the culprit -- we very often rely on u-boot to set up the usb hardware and if it doesn't the kernel hangs trying to access it. Sometimes you just need a "usb start" in u-boot before launching the kernel or ubldr. Or maybe there are some more fixes in 11 that haven't been merged back to 10 yet. As to the 1ghz stuff, it was my understanding that the patches make u-boot set the clock faster. It would probably be better to just have our kernel code do that, but I haven't had time to look at the patches and see how much work is involved. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 23:04:06 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E77EDB2 for ; Wed, 30 Apr 2014 23:04:06 +0000 (UTC) Received: from lamora.getmail.no (lamora.getmail.no [84.210.184.7]) by mx1.freebsd.org (Postfix) with ESMTP id 08D4012C0 for ; Wed, 30 Apr 2014 23:04:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 068016CD33 for ; Thu, 1 May 2014 00:58:31 +0200 (CEST) Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5eu_l5MECW-6 for ; Thu, 1 May 2014 00:58:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 109D46CE4A for ; Thu, 1 May 2014 00:57:25 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.8.4 lamora.getmail.no 109D46CE4A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1398898645; bh=hYfPMhVky7I2tlOyT18gnyecntb1O+E1rRdR/o7q2N8=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=FgmUXn2g5cpP0+lPtBR8uNwqjROC6oXw1/2rX3gU9oKF4Al0Imr+W9Jou6Kc2WC0W kLSdeAzJkw7TZ7oVbOdndN4MgQwscBiNeH3H+TKEfezWLfy1gHiwdw1/8U9v09g9aY 4a+0uMprYZOkySkIw7IrwIitqFo3xI/HHPF3CdLE= X-Virus-Scanned: amavisd-new at lamora.get.c.bitbit.net Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XmR9trstVeda for ; Thu, 1 May 2014 00:57:24 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by lamora.getmail.no (Postfix) with ESMTPSA id 80EFA6D5A5 for ; Thu, 1 May 2014 00:56:15 +0200 (CEST) Date: Thu, 1 May 2014 00:56:11 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: crochet - why does it (try to) change files in /usr/src? Message-Id: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd8.4) 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:04:06 -0000 I'm (finally) trying crochet today. Ultimate goal is to try and build for Cubieboard, but I'm starting with something easy first - RaspberryPi. First I had to get all the pieces (the script does a very nice job of explaining what what is missing. One possible refinement for a future version would be to list all missing pieces, not just the first one). Next I discovered that my world build failed. Lookiing at the log file work/_.buildworld.armv6.log I can see this: ===> lib/libexpat (cleandir) rm -f bsdxml.h bsdxml_external.h libbsdxml.3.gz libbsdxml.3.cat.gz rm: bsdxml.h: Permission denied rm: bsdxml_external.h: Permission denied *** Error code 1 Stop. make[4]: stopped in /usr/src/lib/libexpat (I wasn't running crochet as root, and I suspect it is the reason for failure) Question 1: it look to me like the script is trying to remove stuff (files) from /usr/src. Why is it doing that? Question 2: why does crochet need root? - all prerequisites (that needs root) are already installed - the script is installed in ~/work/crochet-freebsd and all building takes place there so why does it need root? Details: build machine runs FreeBSD 10.0-release: $ uname -a FreeBSD kg-v7.kg4.no 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 build details: $ sh crochet.sh -b RaspberryPi Starting at Thu May 1 00:18:36 CEST 2014 Board: RaspberryPi Source version is: r265148 Building FreeBSD version: 10.0 Image name is: /usr/home/tingo/work/crochet-freebsd/work/FreeBSD-armv6-10.0-RPI-B-r265148.img Building FreeBSD version: 10.0 Object files are at: /usr/home/tingo/work/crochet-freebsd/work/obj/arm.armv6/usr/src Found suitable FreeBSD source tree in: /usr/src Found FreeBSD xdev tools for armv6 Found U-Boot sources in: /usr/home/tingo/work/crochet-freebsd/u-boot-rpi Building FreeBSD armv6 world at Thu May 1 00:18:36 CEST 2014 (Logging to /usr/home/tingo/work/crochet-freebsd/work/_.buildworld.armv6.log) Failed to build FreeBSD armv6 world. Log in /usr/home/tingo/work/crochet-freebsd/work/_.buildworld.armv6.log Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 23:23:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D101A159 for ; Wed, 30 Apr 2014 23:23:09 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D7931476 for ; Wed, 30 Apr 2014 23:23:09 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u56so1471800wes.23 for ; Wed, 30 Apr 2014 16:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=56tA7J+8PmscsVIJhAhh7lzfv6pUtk5e/PkudrVkjRs=; b=Ro9MY/+iOe2Og8pj+3HYa/miQh/90hWb3+ZZjL6+OqDej3S+ZCen+txfpdQrWHtmim 8RK1CH7VbDMeWCtE01BOtkPpuB7gKuwgMnsAuCrnnaN0lPSM5rsRMDfr5Q1zLDt235SY wSKfN68T60V49HTeT6ZhFOn4j575xMwG7JahWKnCrJJrEhoyRffMHixO7fN0UvpKsccZ rB1ndtAEVvUWOOh+9UREzTBLpb8DbC7emrDBKFRAflJoq16bQXWxTCrEwNNGUlyriCjV 1/f+4FA3Nvnp5fjp9Dy32afpDGcFqmllUvUyJSiKlcuf/54UOunQIml4X3a7zoQL+SSa l47w== MIME-Version: 1.0 X-Received: by 10.180.8.136 with SMTP id r8mr5809648wia.60.1398900187724; Wed, 30 Apr 2014 16:23:07 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 30 Apr 2014 16:23:07 -0700 (PDT) In-Reply-To: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> Date: Wed, 30 Apr 2014 19:23:07 -0400 Message-ID: Subject: Re: crochet - why does it (try to) change files in /usr/src? From: Winston Smith To: Torfinn Ingolfsen Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:23:09 -0000 On Wed, Apr 30, 2014 at 6:56 PM, Torfinn Ingolfsen wrote: > I'm (finally) trying crochet today. Ultimate goal is to try and build for Cubieboard, but I'm starting with something easy first - RaspberryPi. > > Question 1: it look to me like the script is trying to remove stuff (files) from /usr/src. Why is it doing that? > > Question 2: why does crochet need root? > - all prerequisites (that needs root) are already installed > - the script is installed in ~/work/crochet-freebsd and all building takes place there > so why does it need root? I think it's just the FreeBSD way! Does it work if you're root? From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 23:28:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6969D203; Wed, 30 Apr 2014 23:28:54 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D61FA14B3; Wed, 30 Apr 2014 23:28:53 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hm4so1829127wib.17 for ; Wed, 30 Apr 2014 16:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/vJprbSKYDZEkovKFeA8Atcx3qRVdwoMVKqmSue0T0g=; b=vUNJVNrnFaynGz8yYghvqOM7UFMehoqN7/gBn5Dwirmecaxzc6Q6ATHmVu6HA6Bh4W VNV/XGwbVc/VJGSTJq1aB1vH1uSdkmvB88yeFaLygKTZw+l9deVou/4+bDeugaeMRsCl mVYCqgNmMp4sBSqO0ER+rBIXPnYINxg6bmfbM3sVNE7Dloq3NRAczD/XZe0LaUOkCpSt pFDVtCs8oXx5KA8wofsleerzlpb7nCwm3yeyUDcEM4N0lGS3wmQtOJDge0IfjFa3ziX7 5MU/8fQa+GvSvSBdhfDQmGhAHma2QAOeL1+529zW8ntGBqqJobaVcxs07XjUHEPx+KfQ BWbA== MIME-Version: 1.0 X-Received: by 10.194.109.6 with SMTP id ho6mr6310513wjb.21.1398900532140; Wed, 30 Apr 2014 16:28:52 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 30 Apr 2014 16:28:52 -0700 (PDT) In-Reply-To: <1398897697.22079.80.camel@revolution.hippie.lan> References: <1398897697.22079.80.camel@revolution.hippie.lan> Date: Wed, 30 Apr 2014 19:28:52 -0400 Message-ID: Subject: Re: BBB @ 1Ghz hangs with 10-STABLE (11-CURRENT is ok) From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:28:54 -0000 On Wed, Apr 30, 2014 at 6:41 PM, Ian Lepore wrote: > That backtrace is just the idle thread; usually that's a sign that some > device driver is waiting for an interrupt to finish configuring the > device and it never gets it and just hangs. In cases like this, what should I be collecting? (assuming I can break into the debugger) > Often usb is the culprit -- > we very often rely on u-boot to set up the usb hardware and if it > doesn't the kernel hangs trying to access it. Sometimes you just need a > "usb start" in u-boot before launching the kernel or ubldr. Or maybe > there are some more fixes in 11 that haven't been merged back to 10 yet. The u-boot's are the same for both of my tests, so unless ubldr is doing this, it must be something in 11. > As to the 1ghz stuff, it was my understanding that the patches make > u-boot set the clock faster. It would probably be better to just have > our kernel code do that, but I haven't had time to look at the patches > and see how much work is involved. I looked at the patches and didn't see where it's changing the clock. However, it does appear to be changing the clock. Without the patch, I see the following: am335x_prcm0: Clocks: System 24.0 MHz, CPU 550 MHz With the patch, I see this: am335x_prcm0: Clocks: System 24.0 MHz, CPU 1000 MHz So it appears to be running at almost 2x the speed (and the caches appear to be enabled). Cool!!! -W. From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 23:34:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A43B2B3 for ; Wed, 30 Apr 2014 23:34:57 +0000 (UTC) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45B361566 for ; Wed, 30 Apr 2014 23:34:57 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id id10so3145307vcb.17 for ; Wed, 30 Apr 2014 16:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=+jVxIxMQTGe9X7hssPMgLe9Wr/PS06s2MORfV1XPNVw=; b=uvXnG8Gc5p/VfP6Wgi2ag0a/xKyS1Ay1wFNvT4Kx7bcYYBPJuC/MXjDlXYfRr3RFs7 4fL73juVa492K1jgDOIAKhmT+5BdrmMv1aeYhLGdGHPYYvWB7gnnoVtH5hMla1k8ZPG3 SpMGD22hZZHu/IHCqGlrhpuNNerOFwFtc1JXJ3Y1b2DzllGsiN+BlgRkLr86YEOqO+ha gSScDib0NfNwB+3WoQefVANdG88tFIpdqalCJB13JdxilluauWLXOIOH/2/xfk/+4g7c WBb9+Gnda2/jnySrTd32SSO0HwihuMCK/NOFZ0SjeSYqlok9+cO1D1+rK+bAEMlIdxR8 cdUQ== MIME-Version: 1.0 X-Received: by 10.221.58.144 with SMTP id wk16mr5638489vcb.23.1398900896342; Wed, 30 Apr 2014 16:34:56 -0700 (PDT) Sender: johny.mattsson@gmail.com Received: by 10.220.47.131 with HTTP; Wed, 30 Apr 2014 16:34:56 -0700 (PDT) In-Reply-To: <1398867266.22079.51.camel@revolution.hippie.lan> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> Date: Thu, 1 May 2014 09:34:56 +1000 X-Google-Sender-Auth: Cz4Lay6gN_6_aFsQDEgjZD0l5zo Message-ID: Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined From: Johny Mattsson To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:34:57 -0000 On 1 May 2014 00:14, Ian Lepore wrote: > I was doing some testing on a wandboard (about twice as fast an an rpi) > with > more than 20k int/sec without having any problems. > On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k int/sec, on Linux. Admittedly at that point my shell wasn't what you'd call "responsive" however =) The ISR in that scenario was the GPIO handler, so probably a bit more light-weight than an audio ISR. From owner-freebsd-arm@FreeBSD.ORG Wed Apr 30 23:49:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05E4A6D7; Wed, 30 Apr 2014 23:49:27 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 727EE1653; Wed, 30 Apr 2014 23:49:26 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id b13so2388384wgh.28 for ; Wed, 30 Apr 2014 16:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QCvoVweNUWrp4Mu0YZnWw/kZUuiqvNkBWxUE3Ma5X2k=; b=Xyu3zB7StYJ9TVVrOsm94H9gps7n3ls6koeePb05ycZAFcap+wyIXmoK5T3dB1xkM0 yXRHNQoZi9HUrHGhN4qo2Uu/8zmcOLgNoc1xhB6Fk5Vx7NDnzfLXZaINLqfU7f3Dfqme q4hDQIQWBv2ZX2NN4NVgxw8LhunK44FtkGyNmRPUXC3h1pipSNVu8eTgd1dw3pjZmnBA WM8Vx/Z/q+X9FvAOgb4SeKSUiwBsWfs2aUt5o3n0yOGYxB6zrXZcHIIiNYYBGo6qF48w CzeYlVbUls2yrUUTH4N3DxFupOqE1CH3P//UP0mEpP2Sh3VP6YNaPTsTCQ852ToVh87c o39Q== MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr5855034wic.5.1398901764742; Wed, 30 Apr 2014 16:49:24 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 30 Apr 2014 16:49:24 -0700 (PDT) In-Reply-To: <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> References: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> Date: Wed, 30 Apr 2014 19:49:24 -0400 Message-ID: Subject: Re: i2c on RPI-B not working From: Winston Smith To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:49:27 -0000 On Tue, Apr 29, 2014 at 1:07 PM, Rui Paulo wrote: > This is because the controller doesn't support scanning. You need to write your own C program to issue iic ioctls for reading / writing to the i2c bus. I'm in the same process except on a BeagleBone Black (currently running 11-CURRENT). Running `i2c -sv` under `ktrace -t+`, it's returning: 956 i2c CALL ioctl(0x3,I2CRSTCARD,0xbffffcc8) 956 i2c RET ioctl 0 956 i2c CALL ioctl(0x3,I2CSTART,0xbffffcc8) 956 i2c RET ioctl -1 errno 6 Device not configured 956 i2c CALL ioctl(0x3,I2CSTOP,0xbffffcc8) 956 i2c RET ioctl -1 errno 22 Invalid argument I know from Linux on the BBB, that when you run `i2cdetect`, you need to specify the `-r` to use "read byte" commands to probe the i2c bus and indeed I've written i2c code previously using ioctl() with I2CRDWR. So I cobbled together a I2C bus scanner, i2cscan.c: http://pastebin.com/RxpRCyJU root@beaglebone:~ # ./i2cscan /dev/iic0 Checking device: /dev/iic0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Hmmm ... on the BBB it's still not detecting anything; in fact according to `ktrace`, it seems to still return ENXIO (Device not configured): 988 i2cscan CALL ioctl(0x3,I2CRDWR,0xbffffc58) 988 i2cscan RET ioctl -1 errno 6 Device not configured Not entirely sure why it's not detecting anything since I *know* the BBB has an EEPROM at 0x50 on bus 0 (I2C0 @ 44e0b000), which according to ofwdump should be iic0: root@beaglebone:~ # ofwdump -a Node 0x38: Node 0xc4: am335x ... Node 0x1504: i2c@44e0b000 Node 0x1590: pmic@24 ... So: 1) Hopefully, you'll have more luck with the i2cscan.c tool I wrote than I did! 2) Does anyone know why I'm not detecting any i2c devices on the BBB? Thanks! -W From owner-freebsd-arm@FreeBSD.ORG Thu May 1 00:13:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C129C1B; Thu, 1 May 2014 00:13:14 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C7781871; Thu, 1 May 2014 00:13:13 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wfech-000IGM-IA; Thu, 01 May 2014 00:13:11 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s410D839018081; Wed, 30 Apr 2014 18:13:09 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18I3MG2uPQE17u3X5qQ4Tys Subject: Re: i2c on RPI-B not working From: Ian Lepore To: Winston Smith In-Reply-To: References: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Apr 2014 18:13:08 -0600 Message-ID: <1398903188.22079.89.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 , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 00:13:14 -0000 On Wed, 2014-04-30 at 19:49 -0400, Winston Smith wrote: > On Tue, Apr 29, 2014 at 1:07 PM, Rui Paulo wrote: > > This is because the controller doesn't support scanning. You need to write your own C program to issue iic ioctls for reading / writing to the i2c bus. > > I'm in the same process except on a BeagleBone Black (currently > running 11-CURRENT). Running `i2c -sv` under `ktrace -t+`, it's > returning: > > 956 i2c CALL ioctl(0x3,I2CRSTCARD,0xbffffcc8) > 956 i2c RET ioctl 0 > 956 i2c CALL ioctl(0x3,I2CSTART,0xbffffcc8) > 956 i2c RET ioctl -1 errno 6 Device not configured > 956 i2c CALL ioctl(0x3,I2CSTOP,0xbffffcc8) > 956 i2c RET ioctl -1 errno 22 Invalid argument > > > I know from Linux on the BBB, that when you run `i2cdetect`, you need > to specify the `-r` to use "read byte" commands to probe the i2c bus > and indeed I've written i2c code previously using ioctl() with > I2CRDWR. > > So I cobbled together a I2C bus scanner, i2cscan.c: > http://pastebin.com/RxpRCyJU > > root@beaglebone:~ # ./i2cscan /dev/iic0 > Checking device: /dev/iic0 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > Hmmm ... on the BBB it's still not detecting anything; in fact > according to `ktrace`, it seems to still return ENXIO (Device not > configured): > > 988 i2cscan CALL ioctl(0x3,I2CRDWR,0xbffffc58) > 988 i2cscan RET ioctl -1 errno 6 Device not configured > > > Not entirely sure why it's not detecting anything since I *know* the > BBB has an EEPROM at 0x50 on bus 0 (I2C0 @ 44e0b000), which according > to ofwdump should be iic0: > > root@beaglebone:~ # ofwdump -a > Node 0x38: > Node 0xc4: am335x > ... > Node 0x1504: i2c@44e0b000 > Node 0x1590: pmic@24 > ... > > So: > > 1) Hopefully, you'll have more luck with the i2cscan.c tool I wrote than I did! > 2) Does anyone know why I'm not detecting any i2c devices on the BBB? > > Thanks! > > -W I saw it mentioned on irc the other day that i2c(8) isn't very functional on most of our ARM systems. It's expecting a different interface to the i2c hardware in which it sees all the low-level protocol events. Most modern hardware has more of a "do this whole transaction for me" type interface. We probably need to enhance i2c(8) to work (as much as it can) in such a mode. The i2c eeproms, on the other hand, should just work. Add 'device icee' to the kernel config, and in the dts file make an icee entry that's a child of the i2c controller entry. Something like this (this is for wandboard)... i2c@021a4000 { status = "okay"; icee@a0 { compatible = "atmel,24c256"; reg = <0xa0>; status = "okay"; }; }; You'll end up with a /dev/icee0 device which you can read and write and seek and so on. Note that the device will show up even if the hardware isn't there or isn't responding, there's no actual probe for hardware. If you do "dd /dev/icee0 | hd" and it comes up all-bits-one that's usually a sign that there's no hardware (but it could also be a brand new eeprom with nothing written to it). -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 1 00:14:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EEAA6C66 for ; Thu, 1 May 2014 00:14:35 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AE271877 for ; Thu, 1 May 2014 00:14:35 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id b13so2409922wgh.31 for ; Wed, 30 Apr 2014 17:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Bt+BsKCXQoCYR20/YVZd/R7tNKmzBT/fpEy9DwMD+4I=; b=tR1JaroJdGmtU+f8dY0dJKyn29O4tg9gblfDg0ujgVXjPHj3wwaF8C36mdF9nxcIde NrlE+utOEe48JPQ2eZw2PQRb9M6Wriui57+Gu/zRnyZNx9cW6amvfcTvkjfGV++uxhe3 N6UsZU7osMuuyAwFrmlk3MGZhOQAJJUvVrui+9X6UoRkfuV/ZnxbjumkQnFF6loNsiMr NTeRY7SZEZ3oW+OLkGdXqGEhSRg7k/ZXdzarlJ/glpyws+FmWpe/JVsKuhXOu+Z7+iok 2kKNqAXS9Ms+INAlcbZRcDD+m/Q9QMSYsp2Iln1ztJBj0PkXwUFYjf6YC6nGLvdfEzH1 xquA== MIME-Version: 1.0 X-Received: by 10.180.103.5 with SMTP id fs5mr5854448wib.33.1398903273939; Wed, 30 Apr 2014 17:14:33 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 30 Apr 2014 17:14:33 -0700 (PDT) Date: Wed, 30 Apr 2014 20:14:33 -0400 Message-ID: Subject: Status of BeagleBone Black UARTs From: Winston Smith To: FreeBSD ARM Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 00:14:36 -0000 I found an email thread from last year discussing enabling the BBB's additional UARTs: http://freebsd.1045724.n5.nabble.com/Beaglebone-Serial-Ports-Progress-td5787251.html Has there been any update on this? Do I still need to use Ian [Young]'s patch? I do see in the bboneblk.dts that all 5 uarts are listed, however dmesg only mentions uart0 and I don't see any additional tty devices in /dev. Thanks! -W From owner-freebsd-arm@FreeBSD.ORG Thu May 1 00:18:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF17FCE0; Thu, 1 May 2014 00:18:28 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31EF8188B; Thu, 1 May 2014 00:18:28 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hi2so10008744wib.11 for ; Wed, 30 Apr 2014 17:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h8CIUapE3PiHO/FNHQJeA5MRhMnW/W2EX26Cb+XBBP0=; b=VsLuaUlSXa8+fle0Ip3zCl5BjN8sqLah81BZ+u9mFQPElW0XvFSelCfckz2n/wWMc8 r1epMzGDDFXee9IvEdxl8zV4Wp+tCsANON+NPHQ79u1TzsR4UJ4zjGJlMQlc1AJnXrWl 7Mf2u0q2JRghmMi3K57ITao8JvxQVzhg6Ws6J6sU9803fB+8DnyWTmBx4Hnk6klL3MTU Nd+q3L0flb54GuRcKBRVDyzw5fH8x5vgry/Lm0Wkz7uw92U++p1U7vJk1o6/jmemxDED u0R7CCz7t1ZCwgpTJWQW0caQ3LqXw4vUKPH6hkkR36ctXrwq5az4KX8JkI6aSBmjlTeJ 2WFQ== MIME-Version: 1.0 X-Received: by 10.180.100.129 with SMTP id ey1mr5966793wib.60.1398903505985; Wed, 30 Apr 2014 17:18:25 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 30 Apr 2014 17:18:25 -0700 (PDT) In-Reply-To: <1398903188.22079.89.camel@revolution.hippie.lan> References: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> <1398903188.22079.89.camel@revolution.hippie.lan> Date: Wed, 30 Apr 2014 20:18:25 -0400 Message-ID: Subject: Re: i2c on RPI-B not working From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 00:18:28 -0000 On Wed, Apr 30, 2014 at 8:13 PM, Ian Lepore wrote: > I saw it mentioned on irc the other day that i2c(8) isn't very > functional on most of our ARM systems. It's expecting a different > interface to the i2c hardware in which it sees all the low-level > protocol events. Most modern hardware has more of a "do this whole > transaction for me" type interface. We probably need to enhance i2c(8) > to work (as much as it can) in such a mode. i2c(8) being the user-mode utility; is the i2c kernel implementation functional? > The i2c eeproms, on the other hand, should just work. Add 'device icee' > to the kernel config, and in the dts file make an icee entry that's a > child of the i2c controller entry. Something like this (this is for > wandboard)... > > i2c@021a4000 > { > status = "okay"; > icee@a0 { > compatible = "atmel,24c256"; > reg = <0xa0>; > status = "okay"; > }; > }; > > You'll end up with a /dev/icee0 device which you can read and write and > seek and so on. Note that the device will show up even if the hardware > isn't there or isn't responding, there's no actual probe for hardware. > If you do "dd /dev/icee0 | hd" and it comes up all-bits-one that's > usually a sign that there's no hardware (but it could also be a brand > new eeprom with nothing written to it). It sounds very similar to how Linux maps the BBB's EEPROM into /sys/bus/i2c/devices/0-0050/eeprom I also have a DS1307 compatible I2C RTC that I'm hoping to support! Thanks -W From owner-freebsd-arm@FreeBSD.ORG Thu May 1 01:42:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEF8AA4E for ; Thu, 1 May 2014 01:42:29 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63D18109D for ; Thu, 1 May 2014 01:42:29 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id b15so731518eek.26 for ; Wed, 30 Apr 2014 18:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Y7NIWGuTZeeqO8rme8QJG+eRwFiebxUp35eHtbiWt9U=; b=XqAhN18VkZ4QgwAi+iePDLnZch28Z0pcCzaUHQ6kQ95uHZ5ptG3UozAYfWXuvlNkLF vmSNvB3YHRCSIru0RBA/Bx0bWAIzdkrjWSkH0cLEU0h5ki56qtqo4HN6UGr5S4aPEkQX A3GaTDEm0+G74fyw3Trrk/q9WkeZxO/lbzIEA83gMOF67+4epwoLeYldfoQN5DJ5cn8W vAzRxtQhF+jiFHjJawX7zTSyT3s3tG2ujcaZ5dJIhUnAupVBuQZjAhZH2ITLhAWmejWE BFK3kcBJ4xY+8XGYYIi8z9RwKXJaBvVhMFPnOgi9+Si/tNfa8kraAlmkANZsBLWLvKNg xEmQ== X-Received: by 10.14.204.199 with SMTP id h47mr7202552eeo.48.1398908547604; Wed, 30 Apr 2014 18:42:27 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id 48sm72286346eei.24.2014.04.30.18.42.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 18:42:26 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5361A678.4000604@hot.ee> Date: Thu, 01 May 2014 04:42:17 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Winston Smith Subject: Re: Status of BeagleBone Black UARTs References: In-Reply-To: X-TagToolbar-Keys: D20140501044216934 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 01:42:29 -0000 On 2014-05-01 03:14, Winston Smith wrote: > I found an email thread from last year discussing enabling the BBB's > additional UARTs: > > http://freebsd.1045724.n5.nabble.com/Beaglebone-Serial-Ports-Progress-td5787251.html > > Has there been any update on this? Do I still need to use Ian [Young]'s patch? > > I do see in the bboneblk.dts that all 5 uarts are listed, however > dmesg only mentions uart0 and I don't see any additional tty devices > in /dev. > > Thanks! > > -W You need to enable other UARTs, they have status = "disabled" in FDT. dtc is included in base, in case you want to do it directly in BBB. From owner-freebsd-arm@FreeBSD.ORG Thu May 1 01:55:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56A48E9A for ; Thu, 1 May 2014 01:55:13 +0000 (UTC) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DD421177 for ; Thu, 1 May 2014 01:55:12 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id wp4so3014090obc.20 for ; Wed, 30 Apr 2014 18:55:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bQvQPRNsOC5NYtb3HtVN71BTuM7Lsk5vN2tYx2Q1Ti0=; b=OikhN4V3jBItnEGeg3I2uQQ7YaGKlsMb/8kBQmtmP/JmBAw8P85RYOcapCufDmu5ri 0xB7pCzjut7DQ1m81aT1O27xZEWjRyTIohIaPXBgHFp3hh5YbXQMUdp/W524cr9eqm/s 6WxOW9LRQNf9iX2RKFSppRcG626Mo/6VTix3t8coR40W71+OkC8Qui2+Nc7ntOJ0osT1 EP291cKmm2avvURZ67JVG8Z+3IbSit9f1vE9R/FB7qkrSW5ozii0ascr/KmaWelWvO8e gHrvy2Rn8qhIVRJiSwmnR0j3RUHU0n+SV4lMJ50z6T9OjEOsc30LK++Jok5mLjif53iN 7UIg== X-Gm-Message-State: ALoCoQluF3qulorHyWRbgzSfrOghIA+wnFkyiNvP41hxoCG9J1+DxhZ4pk1DjY1erEHBHoPwgo5o MIME-Version: 1.0 X-Received: by 10.182.104.71 with SMTP id gc7mr7054159obb.34.1398909305780; Wed, 30 Apr 2014 18:55:05 -0700 (PDT) Received: by 10.182.246.135 with HTTP; Wed, 30 Apr 2014 18:55:05 -0700 (PDT) In-Reply-To: References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> Date: Wed, 30 Apr 2014 19:55:05 -0600 Message-ID: Subject: Re: crochet - why does it (try to) change files in /usr/src? From: Tom Everett To: Winston Smith Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 01:55:13 -0000 My recollection is that it needs root to create the md devices. On Wed, Apr 30, 2014 at 5:23 PM, Winston Smith wrote: > On Wed, Apr 30, 2014 at 6:56 PM, Torfinn Ingolfsen > wrote: > > I'm (finally) trying crochet today. Ultimate goal is to try and build > for Cubieboard, but I'm starting with something easy first - RaspberryPi. > > > > Question 1: it look to me like the script is trying to remove stuff > (files) from /usr/src. Why is it doing that? > > > > Question 2: why does crochet need root? > > - all prerequisites (that needs root) are already installed > > - the script is installed in ~/work/crochet-freebsd and all building > takes place there > > so why does it need root? > > I think it's just the FreeBSD way! > > Does it work if you're root? > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Thu May 1 01:56:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF8D0EE8 for ; Thu, 1 May 2014 01:56:42 +0000 (UTC) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A70A11180 for ; Thu, 1 May 2014 01:56:42 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id n16so3016634oag.31 for ; Wed, 30 Apr 2014 18:56:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WwizDnZ38HBiKfm8YnRFgHcXAytBsSoz4NrBOe4U6HY=; b=dQvUW60BhZf9e4ER9P+/PEx/vyM7QtsPvH61fGy8wFcc83ZOSR+PYgFil1Zpm+sxpM CJed7AUBdRp70vTfD9HmHoXbeNEw1opcFluwiNhm0BPnRtM7m0aZIT64UcVodEiEsuI6 t5DJPIFefecO7ARCAkRhxiWuwE73sTVrpg6VfwgSvJ5XYSBiLf5oCOHhhTLU3yVPgdOi raE7H4W+vaGd/Y2A1DbllfyiI8dr2PlTlUS3m7tjqIqZTgYpbyef1uJgDvdy2WIDyyID ABwVcdW0gxdVLWVrIzB46SMXWJjku1HJOEnFFh/3PlI6BQugsNCFQXTv7nTxdmWNUeLh ulTQ== X-Gm-Message-State: ALoCoQk95OdGdwk8eTuXI3TMP13/RAqlldWaxrEXFApHadOdin2vKvs70/Q7eYJdv3MT+/KsyChi MIME-Version: 1.0 X-Received: by 10.60.62.34 with SMTP id v2mr8394325oer.37.1398909401600; Wed, 30 Apr 2014 18:56:41 -0700 (PDT) Received: by 10.182.246.135 with HTTP; Wed, 30 Apr 2014 18:56:41 -0700 (PDT) In-Reply-To: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> Date: Wed, 30 Apr 2014 19:56:41 -0600 Message-ID: Subject: Re: crochet - why does it (try to) change files in /usr/src? From: Tom Everett To: Torfinn Ingolfsen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 01:56:42 -0000 The one place that comes to mind where crochet changes the source tree is that in some cases, such as SOEKRIS, it copies a custom kernel config onto the source tree. On Wed, Apr 30, 2014 at 4:56 PM, Torfinn Ingolfsen < torfinn.ingolfsen@getmail.no> wrote: > I'm (finally) trying crochet today. Ultimate goal is to try and build for > Cubieboard, but I'm starting with something easy first - RaspberryPi. > > First I had to get all the pieces (the script does a very nice job of > explaining what what is missing. One possible refinement for a future > version would be to list all missing pieces, not just the first one). > Next I discovered that my world build failed. Lookiing at the log file > work/_.buildworld.armv6.log I can see this: > ===> lib/libexpat (cleandir) > rm -f bsdxml.h bsdxml_external.h libbsdxml.3.gz libbsdxml.3.cat.gz > rm: bsdxml.h: Permission denied > rm: bsdxml_external.h: Permission denied > *** Error code 1 > > Stop. > make[4]: stopped in /usr/src/lib/libexpat > (I wasn't running crochet as root, and I suspect it is the reason for > failure) > > Question 1: it look to me like the script is trying to remove stuff > (files) from /usr/src. Why is it doing that? > > Question 2: why does crochet need root? > - all prerequisites (that needs root) are already installed > - the script is installed in ~/work/crochet-freebsd and all building takes > place there > so why does it need root? > > Details: > build machine runs FreeBSD 10.0-release: > $ uname -a > FreeBSD kg-v7.kg4.no 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu > Jan 16 22:34:59 UTC 2014 > root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > build details: > $ sh crochet.sh -b RaspberryPi > Starting at Thu May 1 00:18:36 CEST 2014 > Board: RaspberryPi > Source version is: r265148 > Building FreeBSD version: 10.0 > Image name is: > > /usr/home/tingo/work/crochet-freebsd/work/FreeBSD-armv6-10.0-RPI-B-r265148.img > Building FreeBSD version: 10.0 > Object files are at: > /usr/home/tingo/work/crochet-freebsd/work/obj/arm.armv6/usr/src > Found suitable FreeBSD source tree in: > /usr/src > Found FreeBSD xdev tools for armv6 > Found U-Boot sources in: > /usr/home/tingo/work/crochet-freebsd/u-boot-rpi > Building FreeBSD armv6 world at Thu May 1 00:18:36 CEST 2014 > (Logging to > /usr/home/tingo/work/crochet-freebsd/work/_.buildworld.armv6.log) > Failed to build FreeBSD armv6 world. > Log in /usr/home/tingo/work/crochet-freebsd/work/_.buildworld.armv6.log > > Stop. > make[2]: stopped in /usr/src > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > -- > Torfinn Ingolfsen > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Thu May 1 02:06:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D93031BA for ; Thu, 1 May 2014 02:06:34 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id AA5F1123B for ; Thu, 1 May 2014 02:06:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 16AA93805B; Wed, 30 Apr 2014 21:06:33 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id RGS9sqL9d7ZO; Wed, 30 Apr 2014 21:06:33 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 918D33805A; Wed, 30 Apr 2014 21:06:32 -0500 (CDT) Message-ID: <5361AC27.8020001@freebsd.org> Date: Wed, 30 Apr 2014 19:06:31 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tom Everett , Winston Smith Subject: Re: crochet - why does it (try to) change files in /usr/src? References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 02:06:34 -0000 With both mkimg and makefs in the tree now, there should be almost no need for md devices for image generation anymore. -Nathan On 04/30/14 18:55, Tom Everett wrote: > My recollection is that it needs root to create the md devices. > > > > On Wed, Apr 30, 2014 at 5:23 PM, Winston Smith > wrote: > >> On Wed, Apr 30, 2014 at 6:56 PM, Torfinn Ingolfsen >> wrote: >>> I'm (finally) trying crochet today. Ultimate goal is to try and build >> for Cubieboard, but I'm starting with something easy first - RaspberryPi. >>> Question 1: it look to me like the script is trying to remove stuff >> (files) from /usr/src. Why is it doing that? >>> Question 2: why does crochet need root? >>> - all prerequisites (that needs root) are already installed >>> - the script is installed in ~/work/crochet-freebsd and all building >> takes place there >>> so why does it need root? >> I think it's just the FreeBSD way! >> >> Does it work if you're root? >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > > From owner-freebsd-arm@FreeBSD.ORG Thu May 1 02:36:55 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 769E27ED for ; Thu, 1 May 2014 02:36:55 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C17714E4 for ; Thu, 1 May 2014 02:36:54 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wfgrg-000Ov5-Fc; Thu, 01 May 2014 02:36:48 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s412akxb018155; Wed, 30 Apr 2014 20:36:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+A5kYMMq3D36zAja/i2q2p Subject: Re: Status of BeagleBone Black UARTs From: Ian Lepore To: Winston Smith In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Apr 2014 20:36:46 -0600 Message-ID: <1398911806.22079.94.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 02:36:55 -0000 On Wed, 2014-04-30 at 20:14 -0400, Winston Smith wrote: > I found an email thread from last year discussing enabling the BBB's > additional UARTs: > > http://freebsd.1045724.n5.nabble.com/Beaglebone-Serial-Ports-Progress-td5787251.html > > Has there been any update on this? Do I still need to use Ian [Young]'s patch? > > I do see in the bboneblk.dts that all 5 uarts are listed, however > dmesg only mentions uart0 and I don't see any additional tty devices > in /dev. > > Thanks! > > -W The kernel is ready to go with the uarts, you just need to adjust the fdt data. Change the status="disabled" to status="okay" for whichever ones you want to enable, and adjust the pad control settings so that devices are connected to the right pins. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 1 02:53:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 630FDCA2; Thu, 1 May 2014 02:53:42 +0000 (UTC) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3BFC163C; Thu, 1 May 2014 02:53:41 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id e49so752433eek.35 for ; Wed, 30 Apr 2014 19:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Qnn0R16lJmtt7rHX4FANknFEDl0Ymyb+swihH4R2q1U=; b=TKjl6i8IExCr70xu6wcC/BktVpYKyU7NDfE45Ggpp9+zk4DxeOUB+iqc53qhfRtj31 AKFQM4lYmtMsI79X7F7u7900ZtZ5RYNcdCASGxe3SHXDKKmZL37lhb/rnApx/TRCY+YC hbTAr4NXj3WKZ3FN4g2a5d9p7R67tIw8nbz+SX8luzm/4A4VaNvikDTxTDfMYHrfKP+2 2aeGOowoWln9ml9eNHbv7GDdGxAb7pgNcisopxgcXJPm6rpVrqIk4DS8gH76Z0uz1HqV 2fmsJ+Xr94/5tJ7K8FjLQ/7AxO6vucQx4R6272O04mvNIMreuOeI/O2t2e/+73iJIt+8 xjjg== X-Received: by 10.15.10.3 with SMTP id f3mr7365421eet.1.1398912819009; Wed, 30 Apr 2014 19:53:39 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id t44sm72638543eeo.6.2014.04.30.19.53.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 19:53:37 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5361B72D.2000506@hot.ee> Date: Thu, 01 May 2014 05:53:33 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Nathan Whitehorn Subject: Re: crochet - why does it (try to) change files in /usr/src? References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> <5361AC27.8020001@freebsd.org> In-Reply-To: <5361AC27.8020001@freebsd.org> X-TagToolbar-Keys: D20140501055333409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 02:53:42 -0000 On 2014-05-01 05:06, Nathan Whitehorn wrote: > With both mkimg and makefs in the tree now, there should be almost no > need for md devices for image generation anymore. > -Nathan That would only work for devices that don't need FAT filesystems. Also, if you want to build image root-less, you need to figure out how to get correct file permissions into your image file. Surely you can get those into file, just you can't do it directly on filesystem. From owner-freebsd-arm@FreeBSD.ORG Thu May 1 03:13:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D66D61FB for ; Thu, 1 May 2014 03:13:01 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id A6799188A for ; Thu, 1 May 2014 03:13:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 6662B3805B; Wed, 30 Apr 2014 22:13:00 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id ftABofTCHfsA; Wed, 30 Apr 2014 22:13:00 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 78C693805A; Wed, 30 Apr 2014 22:12:59 -0500 (CDT) Message-ID: <5361BBB9.9050208@freebsd.org> Date: Wed, 30 Apr 2014 20:12:57 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Sulev-Madis Silber (ketas)" Subject: Re: crochet - why does it (try to) change files in /usr/src? References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> <5361AC27.8020001@freebsd.org> <5361B72D.2000506@hot.ee> In-Reply-To: <5361B72D.2000506@hot.ee> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 03:13:01 -0000 On 04/30/14 19:53, Sulev-Madis Silber (ketas) wrote: > On 2014-05-01 05:06, Nathan Whitehorn wrote: >> With both mkimg and makefs in the tree now, there should be almost no >> need for md devices for image generation anymore. >> -Nathan > > That would only work for devices that don't need FAT filesystems. > > > Also, if you want to build image root-less, you need to figure out how > to get correct file permissions into your image file. Surely you can get > those into file, just you can't do it directly on filesystem. > makefs knows how to do permissions fine, either from the file itself or a manifest, and should be acquiring FAT support from NetBSD shortly. It also supports building opposite-endian UFS file systems, which is very useful for embedded applications. -Nathan From owner-freebsd-arm@FreeBSD.ORG Thu May 1 05:05:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5360124B for ; Thu, 1 May 2014 05:05:28 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F94D180F for ; Thu, 1 May 2014 05:05:28 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id ld10so3097771pab.40 for ; Wed, 30 Apr 2014 22:05:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=7tE56QfaEL5FmuytCEGnJkz67l5tlO6W2JSRtbjwpiQ=; b=E2+pSldVw/7AWFj2UrvOjzopyOtf+XglBzLYGRlkHgkdi9ZYJ2JaEZXqqVjFK9Y89S xUCizhlgbdn1F1KmwPcdVk4zyKy8BrNK2INiAPhzXswen8r/T+vR+kxfcBCTeQF1fyT9 L1j8tjVx26HWbom99LyIRMM4YxZhxOefKDm5NjkwPkitxq88xDzgt9a5TecKN16ml9oJ CqGVLft0kId2qm/2S061zOlcF6v6WzNvjS5+rfKvbzgoJXqVt36Q2n6fXIfXB1FCnKSF 3mKVKNMdIYgQkT03uzjbKiT6GD037+ZpZj3Iv+1GrKzESEzGWAgS9PXp345OZ+H72pMx Ry+g== X-Gm-Message-State: ALoCoQnJaWc5aUSjUtukXxQFNaiHYhMOYohs8eNSVdsIP/TZIFp1+Uk8to+x3/iYFldTx41/9arv X-Received: by 10.66.149.37 with SMTP id tx5mr16680470pab.81.1398920726376; Wed, 30 Apr 2014 22:05:26 -0700 (PDT) Received: from macintosh-3c0754232d17.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id fk4sm147576738pab.23.2014.04.30.22.05.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 22:05:25 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_98253A0C-5BE8-44AB-AF83-774CE1E222DC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: crochet - why does it (try to) change files in /usr/src? From: Warner Losh In-Reply-To: <5361BBB9.9050208@freebsd.org> Date: Wed, 30 Apr 2014 23:05:16 -0600 Message-Id: References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> <5361AC27.8020001@freebsd.org> <5361B72D.2000506@hot.ee> <5361BBB9.9050208@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1874) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 05:05:28 -0000 --Apple-Mail=_98253A0C-5BE8-44AB-AF83-774CE1E222DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 30, 2014, at 9:12 PM, Nathan Whitehorn = wrote: > On 04/30/14 19:53, Sulev-Madis Silber (ketas) wrote: >> On 2014-05-01 05:06, Nathan Whitehorn wrote: >>> With both mkimg and makefs in the tree now, there should be almost = no >>> need for md devices for image generation anymore. >>> -Nathan >>=20 >> That would only work for devices that don't need FAT filesystems. >>=20 >>=20 >> Also, if you want to build image root-less, you need to figure out = how >> to get correct file permissions into your image file. Surely you can = get >> those into file, just you can't do it directly on filesystem. >>=20 >=20 > makefs knows how to do permissions fine, either from the file itself = or a manifest, and should be acquiring FAT support from NetBSD shortly. = It also supports building opposite-endian UFS file systems, which is = very useful for embedded applications. We=92ve also imported the NetBSD code that generates mtree files rather = than setting the actual owner/permissions when installing, and makefs = groks how to use those. Warner --Apple-Mail=_98253A0C-5BE8-44AB-AF83-774CE1E222DC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTYdYMAAoJEGwc0Sh9sBEAoKUQAL3Bn5ubloHqw/nUAvHKNDk9 RLHjOQyPR87omaOIW1GX1JwYXBO7nAjff2kaPosNDWG8tZU6yGoH4UuBrmYeYQIA r68IRJ1VuWiPO545KFA2SI1Sr1zAVIIo+MjpnLXzcP+CwjZ6god/1LCUjdrSaxGg s/GmeYffP8sQh+z4zuy8AFELzk5HJ17lxHLSIDE+gWIP2wqy4RLB1qKvwhFb2fwe sKYS/BJs7wl/+0EwGFxF4LbsN+u/xta2KvxYzCd7NDTYdAxoHoHUirnywTxQjRGw /7IR1g2YPH4X5OtfRvAcrqYaIBjf4HL09ydDXikjbqgVYyR1YIOL0T1gbIVV6Y8j N/XWDuA9s2/VwjJRDxAOh2S9vQS8R02app+AXNxjCz0aZoJn03lJVKBJRhYQlX06 2jZgoXCKSOhxwK9zdxdGRo2ilYaOG1jpN91sIeRlIgNNvfTIse7MnWz/3rtdmaEx jNjWH80IsyKlByR2Udkpj2TsXhbbUtUEifYRjbYoNHF1lcO390u66l6ZX/NNbT6U U4AwhZULnIHMD/F1S4KX5Xgj4wrAFONs+nturYhTU7NHof7nI8gb2/gIynCSAmJ9 PNBHWHJ+70ClbpQE+YK75hisqN3yz+Ts2lttQtI12DsfAFDc0CoJHQ0LXkXvvUc5 mI3e6VslXJXM+JqFRTip =1ySD -----END PGP SIGNATURE----- --Apple-Mail=_98253A0C-5BE8-44AB-AF83-774CE1E222DC-- From owner-freebsd-arm@FreeBSD.ORG Thu May 1 13:53:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1C0DB79; Thu, 1 May 2014 13:53:13 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C8941DAB; Thu, 1 May 2014 13:53:12 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s41DqQvq008149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 May 2014 15:52:27 +0200 (CEST) (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 s41DqL4f064760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 May 2014 15:52:22 +0200 (CEST) (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 s41DqLS2051412; Thu, 1 May 2014 15:52:21 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s41DqLb6051411; Thu, 1 May 2014 15:52:21 +0200 (CEST) (envelope-from ticso) Date: Thu, 1 May 2014 15:52:21 +0200 From: Bernd Walter To: Ian Lepore Subject: Re: i2c on RPI-B not working Message-ID: <20140501135221.GB50185@cicely7.cicely.de> References: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> <1398903188.22079.89.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1398903188.22079.89.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 13:53:13 -0000 On Wed, Apr 30, 2014 at 06:13:08PM -0600, Ian Lepore wrote: > On Wed, 2014-04-30 at 19:49 -0400, Winston Smith wrote: > > On Tue, Apr 29, 2014 at 1:07 PM, Rui Paulo wrote: > > > This is because the controller doesn't support scanning. You need to write your own C program to issue iic ioctls for reading / writing to the i2c bus. > > > > I'm in the same process except on a BeagleBone Black (currently > > running 11-CURRENT). Running `i2c -sv` under `ktrace -t+`, it's > > returning: > > > > 956 i2c CALL ioctl(0x3,I2CRSTCARD,0xbffffcc8) > > 956 i2c RET ioctl 0 > > 956 i2c CALL ioctl(0x3,I2CSTART,0xbffffcc8) > > 956 i2c RET ioctl -1 errno 6 Device not configured > > 956 i2c CALL ioctl(0x3,I2CSTOP,0xbffffcc8) > > 956 i2c RET ioctl -1 errno 22 Invalid argument > > > > > > I know from Linux on the BBB, that when you run `i2cdetect`, you need > > to specify the `-r` to use "read byte" commands to probe the i2c bus > > and indeed I've written i2c code previously using ioctl() with > > I2CRDWR. > > > > So I cobbled together a I2C bus scanner, i2cscan.c: > > http://pastebin.com/RxpRCyJU > > > > root@beaglebone:~ # ./i2cscan /dev/iic0 > > Checking device: /dev/iic0 > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > > > > Hmmm ... on the BBB it's still not detecting anything; in fact > > according to `ktrace`, it seems to still return ENXIO (Device not > > configured): > > > > 988 i2cscan CALL ioctl(0x3,I2CRDWR,0xbffffc58) > > 988 i2cscan RET ioctl -1 errno 6 Device not configured > > > > > > Not entirely sure why it's not detecting anything since I *know* the > > BBB has an EEPROM at 0x50 on bus 0 (I2C0 @ 44e0b000), which according > > to ofwdump should be iic0: > > > > root@beaglebone:~ # ofwdump -a > > Node 0x38: > > Node 0xc4: am335x > > ... > > Node 0x1504: i2c@44e0b000 > > Node 0x1590: pmic@24 > > ... > > > > So: > > > > 1) Hopefully, you'll have more luck with the i2cscan.c tool I wrote than I did! > > 2) Does anyone know why I'm not detecting any i2c devices on the BBB? > > > > Thanks! > > > > -W > > I saw it mentioned on irc the other day that i2c(8) isn't very > functional on most of our ARM systems. It's expecting a different > interface to the i2c hardware in which it sees all the low-level > protocol events. Most modern hardware has more of a "do this whole > transaction for me" type interface. We probably need to enhance i2c(8) > to work (as much as it can) in such a mode. Warner already changed the /dev/iic interface years ago. Don't know about i2c(8) however. For example I access a DS1672 attached to my RM9200 board from userland with: int main(int argc, char *argv[]) { int i, error; struct iic_rdwr_data cmd; struct iic_msg msg[2]; char buf1[16]; char buf2[16]; if (argc == 3 && strcmp(argv[1], "-r") == 0) { int bus = open(argv[2], O_RDWR | O_EXCL); if (bus < 0) { printf("opening I2C bus device %s failed\n", argv[1]); exit(1); } cmd.nmsgs = 2; cmd.msgs = msg; buf1[0] = 0x00; msg[0].slave = 0xd0; msg[0].flags = IIC_M_WR; msg[0].len = 1; msg[0].buf = buf1; msg[1].slave = 0xd0; msg[1].flags = IIC_M_RD; msg[1].len = 6; msg[1].buf = buf2; error = ioctl(bus, I2CRDWR, &cmd); if (error) { printf("device %i error %i\n", i, errno); } uint32_t time = buf2[0] | buf2[1] << 8 | buf2[2] << 16 | buf2[3] << 24; printf ("RTC time = %i\n", time); printf ("RTC control = %i\n", buf2[4]); printf ("RTC charger = %i\n", buf2[5]); //printf ("%i %i %i %i %i %i\n", buf2[0], buf2[1], buf2[2], buf2[3], buf2[4], buf2[5]); return (0); ... This is doing a read of previously written register address in one go. However the TWI controller Atmel use on ARMs has no support for empty writes used in write probing - this would have to be done bit banging. Empty reads are technically not possible with IIC. So the only thing you can do beside bit banging is doing real reads. IIC is not really designed for probing anyway - you better know what to address in advance. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu May 1 15:08:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64D17625 for ; Thu, 1 May 2014 15:08:10 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 202F315EE for ; Thu, 1 May 2014 15:08:09 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 69B061FE029; Thu, 1 May 2014 17:08:02 +0200 (CEST) Message-ID: <5362638B.1080104@selasky.org> Date: Thu, 01 May 2014 17:08:59 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Johny Mattsson , freebsd-arm@freebsd.org Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 15:08:10 -0000 On 05/01/14 01:34, Johny Mattsson wrote: > On 1 May 2014 00:14, Ian Lepore wrote: > >> I was doing some testing on a wandboard (about twice as fast an an rpi) >> with >> more than 20k int/sec without having any problems. >> > > On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k > int/sec, on Linux. Admittedly at that point my shell wasn't what you'd call > "responsive" however =) The ISR in that scenario was the GPIO handler, so > probably a bit more light-weight than an audio ISR. Hi, I'll have a look and see if I can fix it. --HPS From owner-freebsd-arm@FreeBSD.ORG Thu May 1 15:38:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C08BF677; Thu, 1 May 2014 15:38:47 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 373741905; Thu, 1 May 2014 15:38:47 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id f8so929792wiw.3 for ; Thu, 01 May 2014 08:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wjF+bTqpJe4Gtlh7wv0aldvQ20uKOfnmxgposdMcKOk=; b=YQLqcf6pRXVYBuEgzG0rhyUeZXq8EXUKJAFBt8eMBPGAo2dut9dEeYR2Y90h2p/PxP Coe4ay/gBCwaUWd2H/CJjLDVd8fDTH+/4ggwA3U/9JXauke5ZLf+mhuuHnWW94BFJHCj 1YZxTlTNC2U4DlLXu6L21/RHFRMaZnBzrYD6+eKnS8TWOxZXtnY92renRDld995OBoc1 BWoJWFu535Jl2T57GcrdL8OAQLXsfnaW7CkHP1hBfPqg2WtG3t32lvsdyaXes3dyAGwy H+Orj71wn3CgnY9asHgqO8SYfsMbIY4jnNmliZ7dvYZrUMOo+SV9ttVGfxVTzbuXYNi5 HFww== MIME-Version: 1.0 X-Received: by 10.180.100.129 with SMTP id ey1mr2688223wib.60.1398958725499; Thu, 01 May 2014 08:38:45 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Thu, 1 May 2014 08:38:45 -0700 (PDT) In-Reply-To: References: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> Date: Thu, 1 May 2014 11:38:45 -0400 Message-ID: Subject: Re: i2c on RPI-B not working From: Winston Smith To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 15:38:47 -0000 On Wed, Apr 30, 2014 at 7:49 PM, Winston Smith wrote: > 1) Hopefully, you'll have more luck with the i2cscan.c tool I wrote than I did! > 2) Does anyone know why I'm not detecting any i2c devices on the BBB? I fixed the i2cscan.c tool and it's able to detect the various i2c devices (including the EEPROM at 0x50) on the BBB's I2C0 bus: root@beaglebone:~ # ./i2cscan /dev/iic0 Checking device: /dev/iic0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- 24 -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- 34 -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- I have updated the pastebin for this: http://pastebin.com/RxpRCyJU From owner-freebsd-arm@FreeBSD.ORG Thu May 1 15:42:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BACD76C; Thu, 1 May 2014 15:42:30 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0DBB19A0; Thu, 1 May 2014 15:42:29 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id cc10so951112wib.16 for ; Thu, 01 May 2014 08:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GN7snOcGf5gko7vKQUYTGDbUwnjYhmfSdyJHLxzc5go=; b=IWNGe53IHNzkQHdvo4C9Crx2r4ijHBEtHNeoibQk0nB3kvE8Os8INtAtpqPBmQEgQR 3AxpLIKqzB5d97UvGbd44SRITqX+vh1mTgKT+W10VaZZzECCHAqK4YiB4nxWPpnqJVWL lunG8q5LKt1UxWK/+4LP6FGOhQd+m+t5S7ue+hEuBO4o7xOnN6c7mGtKsyx3cG2nbySh 2aOWdPH+5bDggOeG/mp9qsgHsTcmO9Du6QH3j+Yy4fo2SThCxFQyfiIlQWdsqcQP3hI7 7RIQlUjgcUqGsSw8Ezz/0bw6/MpI7L4DkAtNZl5c/3ImdCSiiEHDMcv17P0chu7ftDhe m72w== MIME-Version: 1.0 X-Received: by 10.180.76.146 with SMTP id k18mr2680153wiw.5.1398958947922; Thu, 01 May 2014 08:42:27 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Thu, 1 May 2014 08:42:27 -0700 (PDT) In-Reply-To: <1398903188.22079.89.camel@revolution.hippie.lan> References: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> <1398903188.22079.89.camel@revolution.hippie.lan> Date: Thu, 1 May 2014 11:42:27 -0400 Message-ID: Subject: Re: i2c on RPI-B not working From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 15:42:30 -0000 On Wed, Apr 30, 2014 at 8:13 PM, Ian Lepore wrote: > The i2c eeproms, on the other hand, should just work. Add 'device icee' > to the kernel config, and in the dts file make an icee entry that's a > child of the i2c controller entry. Something like this (this is for > wandboard)... > > i2c@021a4000 > { > status = "okay"; > icee@a0 { > compatible = "atmel,24c256"; > reg = <0xa0>; > status = "okay"; > }; > }; > > You'll end up with a /dev/icee0 device which you can read and write and > seek and so on. Note that the device will show up even if the hardware > isn't there or isn't responding, there's no actual probe for hardware. > If you do "dd /dev/icee0 | hd" and it comes up all-bits-one that's > usually a sign that there's no hardware (but it could also be a brand > new eeprom with nothing written to it). Is there an equivalent for an RTC? I know Linux will detect a DS1307 on the I2C bus and map it to /dev/rtcN from which the system can use the time? Thanks! From owner-freebsd-arm@FreeBSD.ORG Thu May 1 16:46:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09E3A131 for ; Thu, 1 May 2014 16:46:20 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D13B811EB for ; Thu, 1 May 2014 16:46:19 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id z10so2046523pdj.28 for ; Thu, 01 May 2014 09:46:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=aKIq7lQT5rvIag9lXRvFUgtVC7wAp2O+vJC9hvl8qLA=; b=ZNytVtTY2xpcHGFYhwoJA7M5HWMpgvXOF0DKwbaiBOYHwc48EoW8IFUV/MRnEWzk5V lRr1r00Da+5cHBy46Zm33KC0pCg37HIeWFykZqBFThAgdHBMJzUg7EXg8Nha1vyaV4PR 6aPohxizxqAdH0rJJv9aiUUNw+Ov8mzWSzhds8QUYu+q3W+UOHlue8AfU4rLGFfpRniS OTB25gfbPV/bx2x/x7xOkvUf6i4QZsY1afbOdoKrOhtD6I3ZNpfb4iejDt6+bDlzwNli g+vRJRe3YHvbhkerf/6kBKIkjZMJyRwBDN51aH7HiKWLZdLesCgFgJQfuYkaywl7wec1 X+OA== X-Gm-Message-State: ALoCoQkJCL1mD7c2/8PnXY0JoRj7BaezsR9MN9snLIj/LYbs/DhNoSBZ0khroBOJ4NrhQLNNwWUq X-Received: by 10.66.164.165 with SMTP id yr5mr23122328pab.63.1398962778687; Thu, 01 May 2014 09:46:18 -0700 (PDT) Received: from [192.168.1.2] (c-50-156-22-189.hsd1.ca.comcast.net. [50.156.22.189]) by mx.google.com with ESMTPSA id nw13sm138369589pab.37.2014.05.01.09.46.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 09:46:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: crochet - why does it (try to) change files in /usr/src? From: Tim Kientzle In-Reply-To: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> Date: Thu, 1 May 2014 09:45:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> To: Torfinn Ingolfsen X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 16:46:20 -0000 On Apr 30, 2014, at 3:56 PM, Torfinn Ingolfsen = wrote: > =3D=3D=3D> lib/libexpat (cleandir) > rm -f bsdxml.h bsdxml_external.h libbsdxml.3.gz libbsdxml.3.cat.gz > rm: bsdxml.h: Permission denied > rm: bsdxml_external.h: Permission denied > *** Error code 1 >=20 > Stop. > make[4]: stopped in /usr/src/lib/libexpat > (I wasn't running crochet as root, and I suspect it is the reason for = failure) >=20 > Question 1: it look to me like the script is trying to remove stuff = (files) from /usr/src. Why is it doing that? It=92s not. The =91buildworld=92 target is cleaning the appropriate /usr/obj = directories in case there was a previous build there. > Question 2: why does crochet need root? As for requiring root: * In theory, it should not require root. * In practice, Crochet relies on the FreeBSD build infrastructure, = which until recently did require root. * In practice, FreeBSD=92s build infrastructure now has most of the = necessary tools to do full system builds and installs without requiring = root. (As someone else pointed out, we don=92t have tools for = constructing disk images with multiple partitions, nor for creating FAT = partitions.) * In practice, no one has stepped forward with Crochet patches to allow = it to work without requiring root. It should be relatively simple to = get Crochet to compile all the pieces without requiring root. = Assembling the final disk image without root privileges will require = more effort. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Thu May 1 16:47:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 929471A2 for ; Thu, 1 May 2014 16:47:49 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 308571203 for ; Thu, 1 May 2014 16:47:49 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id q58so3370795wes.20 for ; Thu, 01 May 2014 09:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QxNxkPcDcjMescb3icDqw4VedfK5O7M46MnRE2RLjhM=; b=TlKAr2/+iVes+TGPYLBD/MMNZjEQvDM4WIJ8mlFkxEHyu+WAZbTZYQ9jFck8zSt8WP 6m3XUs9TOD4oLrQNaKTJkEHrJzIz3wl/9wS3QEZRaOR9REzafJb8TnnGORuxERF517uI x6YcgtVexnT1ETllFY50J1GvVg78LRXSLGi/CYDG1w03XGLIw41iQbw3K+0NagxNFpZm 6y/qDIOrKalg91l1IclaWC+CgKW6tbjtS1x0gLoKGFoGPrh3BVbHao56rXvYKtej1zXF zMx/t7nRyLKYgz/QnlRzDkgFGwPIgJ1h+QYsZ/Iant75vspz3uIYRZ3NZKCoxj/75gdC teXg== MIME-Version: 1.0 X-Received: by 10.194.92.177 with SMTP id cn17mr9772515wjb.18.1398962867386; Thu, 01 May 2014 09:47:47 -0700 (PDT) Received: by 10.216.241.73 with HTTP; Thu, 1 May 2014 09:47:47 -0700 (PDT) Date: Thu, 1 May 2014 19:47:47 +0300 Message-ID: Subject: Beaglebone black network performance From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 16:47:49 -0000 Hi, Have you tested Beaglebone black network throughput? I wonder that if it performs 100Mbit/s data transfer. Rasberry PI's network performance is about 6-7Mbit/s, and ping latencies are about 10-20 milliseconds. I think it's too high. I used iperf for bandwidth testing. What about Beaglebone black? Best regards, From owner-freebsd-arm@FreeBSD.ORG Thu May 1 17:02:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44585984 for ; Thu, 1 May 2014 17:02:56 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D416D13BD for ; Thu, 1 May 2014 17:02:55 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi5so1066876wib.0 for ; Thu, 01 May 2014 10:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Bg16RAnq+BE/Gk90rtR1Uo4PoB+NRPR+z8F8VCb9SZA=; b=rs8qkAWdUZ9Ak6ogbPJQPP80PXJzJStPWNHyu6oJO9ewi317uU2Mja5xVdL2JSRBud oT0c3kqSqY/XmHHhQTibeFgZYexN8coS0HzKSuzNDN8bxiYinFvL7Cb/ETUNjIDXBCPq IpPWjCBI21/D8b+KPeQo3QwzcyDMZlk1HtT4N1Vi98VrUnJ1wfK/SbDKgybwpWlN5Mkf 05EZj9Ua7dHcE71aov6YBFvcUY16OkgLYXi7uzvDQGlfu7UxSbvMoE8uXz0pzuN0Cty5 HHetH3Y4ho59t+1reJ5+IgZslRk70g1K8KG4p9JhPT/UghjywIJIPba0IxRVJABLVgg+ RqiA== MIME-Version: 1.0 X-Received: by 10.194.82.35 with SMTP id f3mr9958779wjy.36.1398963774178; Thu, 01 May 2014 10:02:54 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Thu, 1 May 2014 10:02:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 May 2014 13:02:54 -0400 Message-ID: Subject: Re: Beaglebone black network performance From: Winston Smith To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 17:02:56 -0000 On Thu, May 1, 2014 at 12:47 PM, =C3=96zkan KIRIK w= rote: > Rasberry PI's network performance is about 6-7Mbit/s, and ping latencies > are about 10-20 milliseconds. I think it's too high. I used iperf for > bandwidth testing. The RPi's 10/100 ethernet controller is connected to the BCM2835 SoC via it's USB controller, so the USB controller has to share it's bandwidth between the peripherals. The BBB also has a 10/100 ethernet, but it's directly supported by the SoC, so the performance *should* be a little better, particularly when there's other USB traffic. From owner-freebsd-arm@FreeBSD.ORG Thu May 1 17:12:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE56AC3C for ; Thu, 1 May 2014 17:12:47 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B77314FF for ; Thu, 1 May 2014 17:12:47 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so1118079wiv.15 for ; Thu, 01 May 2014 10:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8ZCtNcw6qjE3qkPAXtN+fPRbIE9Q1V2colGaFD/G5Wo=; b=EGyEVTbsRpnzkH358bU3aq31fiG8oGYaRUHJlb98ZYGcxZ5pAkTrKVslwW8oG/qF8D mE7fYfCIqdbSkUp0hS/vod7pkncbIPyX7wJjVboD4LqJBmMTizuhkTYHykqYg1p/n31s rzkf4tgHrZOnrJQZN6R3ETdyX56eWadDh7p7wTpa6uLqc9fnaIBdISXBC3SGVxFkqGJa wc5LBVscT7RI7Ks9WWw1egTaRmYjDarJqG7HEiZvRAILt9CABrH7n7QhoUfR2FKFGeGz SGUP9N830Q5/RGAXKvOr7Kzk9pY98QsaNOmqJuGqLB4t/JW7IQx91giHIz75UkU81g6+ LEAA== MIME-Version: 1.0 X-Received: by 10.180.228.42 with SMTP id sf10mr2963105wic.33.1398964365787; Thu, 01 May 2014 10:12:45 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Thu, 1 May 2014 10:12:45 -0700 (PDT) Date: Thu, 1 May 2014 13:12:45 -0400 Message-ID: Subject: BBB/I2C: Using ioctl(I2CRDWR) warns: interrupt storm detected on "intr70:" From: Winston Smith To: FreeBSD ARM Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 17:12:47 -0000 Continuing on with working with the I2C interface on the BBB I wrote a utility to read the BBB's 28 byte system EEPROM on iic0, address 0x50 which contains the model and serial numbers. See pastebin here: http://pastebin.com/p7XwKUGZ However, when I run the utility: root@beaglebone:~ # ./bbb_eeprom Read from slave 50 on /dev/iic0, signature=AA:55:33:EE Model: A335BNLT0A6A Serial: 0214BBBK4321 I see the following warning on the console: interrupt storm detected on "intr70:"; throttling interrupt source Does this mean anything, or is it just a spurious warning. BTW: This is with FreeBSD 11-CURRENT r265163. -W From owner-freebsd-arm@FreeBSD.ORG Thu May 1 17:20:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BDFDD4F; Thu, 1 May 2014 17:20:27 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D229015CE; Thu, 1 May 2014 17:20:26 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s41HJsdh009495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 May 2014 19:19:55 +0200 (CEST) (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 s41HJn1G066293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 May 2014 19:19:49 +0200 (CEST) (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 s41HJnH2052303; Thu, 1 May 2014 19:19:49 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s41HJmL3052302; Thu, 1 May 2014 19:19:48 +0200 (CEST) (envelope-from ticso) Date: Thu, 1 May 2014 19:19:48 +0200 From: Bernd Walter To: Winston Smith Subject: Re: i2c on RPI-B not working Message-ID: <20140501171948.GA52252@cicely7.cicely.de> References: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> <1398903188.22079.89.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm , Mark R V Murray , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 17:20:27 -0000 On Thu, May 01, 2014 at 11:42:27AM -0400, Winston Smith wrote: > On Wed, Apr 30, 2014 at 8:13 PM, Ian Lepore wrote: > > The i2c eeproms, on the other hand, should just work. Add 'device icee' > > to the kernel config, and in the dts file make an icee entry that's a > > child of the i2c controller entry. Something like this (this is for > > wandboard)... > > > > i2c@021a4000 > > { > > status = "okay"; > > icee@a0 { > > compatible = "atmel,24c256"; > > reg = <0xa0>; > > status = "okay"; > > }; > > }; > > > > You'll end up with a /dev/icee0 device which you can read and write and > > seek and so on. Note that the device will show up even if the hardware > > isn't there or isn't responding, there's no actual probe for hardware. > > If you do "dd /dev/icee0 | hd" and it comes up all-bits-one that's > > usually a sign that there's no hardware (but it could also be a brand > > new eeprom with nothing written to it). > > Is there an equivalent for an RTC? > > I know Linux will detect a DS1307 on the I2C bus and map it to > /dev/rtcN from which the system can use the time? I had been using a DS1672 RTC on one of my own boards. But it did use device.hints compiled into the kernel and no DTS. However the RTC driver already existed before I used it. Take a look into src/sys/dev/iicbus/, wheh most or maybe all iic drivers including RTC live, then see if you can find one of them in an existing DTS file. I didn't find a DS1307 driver however - maybe the DS133x is similar enough to base a driver on it. I personally prefered using an RTC with a unix timestamp instead of a wallclock time based. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu May 1 17:26:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FC19E9A for ; Thu, 1 May 2014 17:26:50 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 482AE1610 for ; Thu, 1 May 2014 17:26:49 +0000 (UTC) Received: from zeppelin.tachypleus.net (airbears2-136-152-142-24.AirBears2.Berkeley.EDU [136.152.142.24]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s41HQl2B028717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 1 May 2014 10:26:47 -0700 Message-ID: <536283D7.8070009@freebsd.org> Date: Thu, 01 May 2014 10:26:47 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: crochet - why does it (try to) change files in /usr/src? References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-ID: C;GhvzxVXR4xGpWJxB+Bh/TQ== M;MMcXxlXR4xGpWJxB+Bh/TQ== X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 17:26:50 -0000 On 05/01/14 09:45, Tim Kientzle wrote: > On Apr 30, 2014, at 3:56 PM, Torfinn Ingolfsen wrote: > >> ===> lib/libexpat (cleandir) >> rm -f bsdxml.h bsdxml_external.h libbsdxml.3.gz libbsdxml.3.cat.gz >> rm: bsdxml.h: Permission denied >> rm: bsdxml_external.h: Permission denied >> *** Error code 1 >> >> Stop. >> make[4]: stopped in /usr/src/lib/libexpat >> (I wasn't running crochet as root, and I suspect it is the reason for failure) >> >> Question 1: it look to me like the script is trying to remove stuff (files) from /usr/src. Why is it doing that? > Its not. > > The buildworld target is cleaning the appropriate /usr/obj directories in case there was a previous build there. > >> Question 2: why does crochet need root? > As for requiring root: > > * In theory, it should not require root. > > * In practice, Crochet relies on the FreeBSD build infrastructure, which until recently did require root. > > * In practice, FreeBSDs build infrastructure now has most of the necessary tools to do full system builds and installs without requiring root. (As someone else pointed out, we dont have tools for constructing disk images with multiple partitions, nor for creating FAT partitions.) This is not true. We *do* have tools for creating images with multiple partitions. See mkimg(1). -Nathan > * In practice, no one has stepped forward with Crochet patches to allow it to work without requiring root. It should be relatively simple to get Crochet to compile all the pieces without requiring root. Assembling the final disk image without root privileges will require more effort. > > Cheers, > > 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 Thu May 1 17:29:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62F94FB6 for ; Thu, 1 May 2014 17:29:29 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30D7A1629 for ; Thu, 1 May 2014 17:29:28 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id z10so2095146pdj.14 for ; Thu, 01 May 2014 10:29:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=PGQr0XnKfQ99qbvc+fyzFyhdiod22eKfeuErnDNHmow=; b=NKgQR30qNau1qeI3eHxTEyY6Y7qEG1fD1MHzXOze5OYfL1Ra2qVNykiEpUKTWI51pN 3I7mv+YfTTNu8tNVpT5aKLIgNP1g6M4UH/zDOOce4LiWLuMgyHvstwNKEb0GTEEwm7RL CcDYX1nVCNDn5SgWL0wCUqhuAzvpcW6UukO6KKmQCXqhsDV1zu44F5OMiU2HQMYbsdAJ ayZFCpqt3OQYjZvapf5d7FG3meGjZTqK98hUbkpbsudoN217k27fvbV1nN0wpuIB/9Vd LN/MRj7FHV7Ec+RPKZSOWfyaIPXtLBu5GUPZJBCXp7+8D5J99HgP+thfixuHSg3wzuXI rtdw== X-Gm-Message-State: ALoCoQm/BB08MKzu9FKlcWty401MhajvjZuru6fr7UaCN56FR2J7IL2CxZg0fVmIQAguBSIEriof X-Received: by 10.66.233.9 with SMTP id ts9mr23530918pac.37.1398965368029; Thu, 01 May 2014 10:29:28 -0700 (PDT) Received: from macintosh-3c0754232d17.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id pb7sm161590552pac.10.2014.05.01.10.29.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 10:29:26 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_38479E85-817E-4066-9361-8B1A22B57FEC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: crochet - why does it (try to) change files in /usr/src? From: Warner Losh In-Reply-To: <536283D7.8070009@freebsd.org> Date: Thu, 1 May 2014 11:29:24 -0600 Message-Id: References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> <536283D7.8070009@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 17:29:29 -0000 --Apple-Mail=_38479E85-817E-4066-9361-8B1A22B57FEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 1, 2014, at 11:26 AM, Nathan Whitehorn = wrote: >=20 > On 05/01/14 09:45, Tim Kientzle wrote: >> On Apr 30, 2014, at 3:56 PM, Torfinn Ingolfsen = wrote: >>=20 >>> =3D=3D=3D> lib/libexpat (cleandir) >>> rm -f bsdxml.h bsdxml_external.h libbsdxml.3.gz libbsdxml.3.cat.gz >>> rm: bsdxml.h: Permission denied >>> rm: bsdxml_external.h: Permission denied >>> *** Error code 1 >>>=20 >>> Stop. >>> make[4]: stopped in /usr/src/lib/libexpat >>> (I wasn't running crochet as root, and I suspect it is the reason = for failure) >>>=20 >>> Question 1: it look to me like the script is trying to remove stuff = (files) from /usr/src. Why is it doing that? >> It=92s not. >>=20 >> The =91buildworld=92 target is cleaning the appropriate /usr/obj = directories in case there was a previous build there. >>=20 >>> Question 2: why does crochet need root? >> As for requiring root: >>=20 >> * In theory, it should not require root. >>=20 >> * In practice, Crochet relies on the FreeBSD build infrastructure, = which until recently did require root. >>=20 >> * In practice, FreeBSD=92s build infrastructure now has most of the = necessary tools to do full system builds and installs without requiring = root. (As someone else pointed out, we don=92t have tools for = constructing disk images with multiple partitions, nor for creating FAT = partitions.) >=20 > This is not true. We *do* have tools for creating images with multiple = partitions. See mkimg(1). This is quite recent though... >> * In practice, no one has stepped forward with Crochet patches to = allow it to work without requiring root. It should be relatively simple = to get Crochet to compile all the pieces without requiring root. = Assembling the final disk image without root privileges will require = more effort. This remains the key issue. There=92s lots of pieces that people have = cobbled together other solutions with but nobody has cobbled that = together with crochet (or nanobsd) to generate even one set of images=85 = We need somebody to step up to *that* plate... Warner --Apple-Mail=_38479E85-817E-4066-9361-8B1A22B57FEC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTYoR0AAoJEGwc0Sh9sBEA9QYQAM6FctHSor2AHKa/2MAo/mWt kIlf4IYjmVncmGSq97XN7hsL4N1fuWZN9rBoxzXx6YKvxuyhRYGE7GszTGNOjfST r9zwaXrdQ1agfTmiNZAmPhR6EdUPUBPO7IqXyKGkC4rCoyLXBVjVXTM9EG+pTiQE JVEKkiy1ZG2rkuYdsnp2AoYu7Ap68Zv86F3IZ0DoCxLlrbA/luFBF0IwYBcQg9/q QyhkK/aozvLYBDO5VW07+j697qbn5XzFI49naSixQwv7zjxoJjw9yNLjOtUU/7Sd lgzz9Ok1jsLTtqsOcXfrRCDbwlPh8Uvv0ozxy/oeR7qt+w+qIgmzPy1Z7Z24u2pg MxXXP5UiXteX/Fpw70NlicEY/xar6NPzMEwijBMPPLE5efincDUS9CTjuIQWat0J HLjLzkgxbeJiLqdZi3z97Fpa1wUTOWbr4o8jpihRoGjWbb8x8oP30xyrfd8DCu8E wMPmZdd95/3Pc8X2VQGPJRysNHYLxwcoXYq0HxGWi7tduh9dhedHwp7sOd2eR0rt iYS9TLNK73IX/oOkLppMQfVoTtVb83zmdAdMtQn0AVvzMiZHiIPcjoGmaJfbZRbq 9vwybFMkO2Xm3m1dGULIhuk1TCTdkNtMVpMR1OaV0tr7qoy+xXqv1fLav8z6awsD H+5PNepuvi5WsFxPZ4ul =fuCe -----END PGP SIGNATURE----- --Apple-Mail=_38479E85-817E-4066-9361-8B1A22B57FEC-- From owner-freebsd-arm@FreeBSD.ORG Thu May 1 18:49:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF79958B for ; Thu, 1 May 2014 18:49:31 +0000 (UTC) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id D5E7F1E58 for ; Thu, 1 May 2014 18:49:31 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 1EDBCB827; Thu, 1 May 2014 11:49:25 -0700 (PDT) To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Subject: Re: Beaglebone black network performance In-reply-to: Your message of "Thu, 01 May 2014 19:47:47 +0300." References: Comments: In-reply-to =?UTF-8?B?w5Z6a2FuIEtJUklL?= message dated "Thu, 01 May 2014 19:47:47 +0300." Date: Thu, 01 May 2014 11:49:25 -0700 From: Bakul Shah Message-Id: <20140501184925.1EDBCB827@mail.bitblocks.com> Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:49:32 -0000 On Thu, 01 May 2014 19:47:47 +0300 =?UTF-8?B?w5Z6a2FuIEtJUklL?= wrote: > > Rasberry PI's network performance is about 6-7Mbit/s, and ping latencies > are about 10-20 milliseconds. I think it's too high. I used iperf for > bandwidth testing. Something is wrong with your network if you get 10-20ms ping latencies on the RPi. I don't run freebsd on RPi but with plan9 on it I get about 3.8MB/s. (which is a lot more than 607Mbit/s) and 454 µs ping latency from a freebsd machine. [It is running @ 800Mhz, with the default clock rate (700Mhz?) your numbers will be a bit worse] > What about Beaglebone black? I get about 9.6MB/s (using ttcp) and 173 µs ping latency from another freebsd machine. From owner-freebsd-arm@FreeBSD.ORG Thu May 1 19:45:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F25125D8 for ; Thu, 1 May 2014 19:45:16 +0000 (UTC) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2EEA1569 for ; Thu, 1 May 2014 19:45:16 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id e16so1221711qcx.41 for ; Thu, 01 May 2014 12:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=/v6w1PfiOzQ8nxyLLikwENrCt2ikEd2DLXtrvI7woZI=; b=fzPxuZ4awo8HI66qh7oA2YBvkN3hQ1yXGFG3cAAtY507L1ZokbNBRzKVaIBWKHav+8 I0Uacmk117Z0FVElSmL4uc0q9a8Uh7Q+YNJwKsnmnSlNrdZBRyW1gqhyo3DRyObO9840 8vbD6DomJFJlZ5H8pt5Zb2zN18Y4Pvn/A82cM3qGROUbeqjAX6VPSkxF6fizKtVAXC7V we6CnEPlMwLEAPazbONZjG1LxjmoMRknRdqU9NbiIh+3w3gU0I/EorRbbBHfg0J7/G0R Rntou1Lo/DCXvu+1PHSjFZtLzIlFLazvzNJhFTTiXKaIbEWPxcD1P/E5DShzZFZrVw3H Uk3A== MIME-Version: 1.0 X-Received: by 10.224.129.66 with SMTP id n2mr16567844qas.55.1398973515252; Thu, 01 May 2014 12:45:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Thu, 1 May 2014 12:45:15 -0700 (PDT) In-Reply-To: <20140501184925.1EDBCB827@mail.bitblocks.com> References: <20140501184925.1EDBCB827@mail.bitblocks.com> Date: Thu, 1 May 2014 12:45:15 -0700 X-Google-Sender-Auth: l-wX5_PNcHpcx9lxluTs9XqZPoU Message-ID: Subject: Re: Beaglebone black network performance From: Adrian Chadd To: Bakul Shah Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:45:17 -0000 Does plan9 on the rpi use interrupts and DMA, or just polling? -a On 1 May 2014 11:49, Bakul Shah wrote: > On Thu, 01 May 2014 19:47:47 +0300 =3D?UTF-8?B?w5Z6a2FuIEtJUklL?=3D wrote: >> >> Rasberry PI's network performance is about 6-7Mbit/s, and ping latencies >> are about 10-20 milliseconds. I think it's too high. I used iperf for >> bandwidth testing. > > Something is wrong with your network if you get 10-20ms ping > latencies on the RPi. > > I don't run freebsd on RPi but with plan9 on it I get about > 3.8MB/s. (which is a lot more than 607Mbit/s) and 454 =C2=B5s > ping latency from a freebsd machine. > > [It is running @ 800Mhz, with the default clock rate (700Mhz?) > your numbers will be a bit worse] > >> What about Beaglebone black? > > I get about 9.6MB/s (using ttcp) and 173 =C2=B5s ping latency > from another freebsd machine. > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu May 1 20:22:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A03E3AC7; Thu, 1 May 2014 20:22:10 +0000 (UTC) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 85DF6186B; Thu, 1 May 2014 20:22:10 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 6299FB82A; Thu, 1 May 2014 13:22:09 -0700 (PDT) To: Adrian Chadd Subject: Re: Beaglebone black network performance In-reply-to: Your message of "Thu, 01 May 2014 12:45:15 PDT." References: <20140501184925.1EDBCB827@mail.bitblocks.com> Comments: In-reply-to Adrian Chadd message dated "Thu, 01 May 2014 12:45:15 -0700." Date: Thu, 01 May 2014 13:22:09 -0700 From: Bakul Shah Message-Id: <20140501202209.6299FB82A@mail.bitblocks.com> Cc: Bakul Shah , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 20:22:10 -0000 On Thu, 01 May 2014 12:45:15 PDT Adrian Chadd wrote: > Does plan9 on the rpi use interrupts and DMA, or just polling? Both interrupts and DMA. The code is relatively easy to read. http://plan9.bell-labs.com/sources/plan9/sys/src/9/bcm/ From owner-freebsd-arm@FreeBSD.ORG Thu May 1 21:07:00 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E27B7FD for ; Thu, 1 May 2014 21:07:00 +0000 (UTC) Received: from lamora.getmail.no (lamora.getmail.no [84.210.184.7]) by mx1.freebsd.org (Postfix) with ESMTP id 40D371C3B for ; Thu, 1 May 2014 21:06:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 144886CAAD for ; Thu, 1 May 2014 23:06:40 +0200 (CEST) Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ERm4QAjgazeK for ; Thu, 1 May 2014 23:06:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 3EEE46B73F for ; Thu, 1 May 2014 23:06:36 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.8.4 lamora.getmail.no 3EEE46B73F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1398978396; bh=dgksGSkBfVOInN2zNxrgnk1oUnwr40AojCarN/H89qs=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=JWT8s/eJKAFVi4DYTX1NqV3yvvLCuZKjEoHMoR8RdDCezvN4QonOhD2f0cdQERSUH Wc4Z4DrPqi5ITXoYeLqq3tqjawXjCg9PFohd0Rj03mWrFZXj0GeCFtIaRicDrNOARI V+SD3IAWhtkx2OD1LlAWQTRYGLOiRaHuqhZNnvrI= X-Virus-Scanned: amavisd-new at lamora.get.c.bitbit.net Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id F-wZcvUc51F3 for ; Thu, 1 May 2014 23:06:36 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by lamora.getmail.no (Postfix) with ESMTPSA id 176D869F83 for ; Thu, 1 May 2014 23:06:36 +0200 (CEST) Date: Thu, 1 May 2014 23:06:33 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: crochet - why does it (try to) change files in /usr/src? Message-Id: <20140501230633.5044af70fba9e4d4ed00933e@getmail.no> In-Reply-To: References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd8.4) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 21:07:00 -0000 On Thu, 1 May 2014 09:45:58 -0700 Tim Kientzle wrote: >=20 > On Apr 30, 2014, at 3:56 PM, Torfinn Ingolfsen wrote: >=20 > > =3D=3D=3D> lib/libexpat (cleandir) > > rm -f bsdxml.h bsdxml_external.h libbsdxml.3.gz libbsdxml.3.cat.gz > > rm: bsdxml.h: Permission denied > > rm: bsdxml_external.h: Permission denied > > *** Error code 1 > >=20 > > Stop. > > make[4]: stopped in /usr/src/lib/libexpat > > (I wasn't running crochet as root, and I suspect it is the reason for= failure) > >=20 > > Question 1: it look to me like the script is trying to remove stuff (= files) from /usr/src. Why is it doing that? >=20 > It=E2=80=99s not. >=20 > The =E2=80=98buildworld=E2=80=99 target is cleaning the appropriate /us= r/obj directories in case there was a previous build there. Ok. Given that the appropriate obj directories (in this case) is in the .= /work sub directory of # pwd /usr/home/tingo/work/crochet-freebsd should buildworld really try to touch /usr/obj at all? >=20 > > Question 2: why does crochet need root? >=20 > As for requiring root: This question has resulted in an interesting discussion; it seems like th= is might change in the future (given time and manpower). Thanks to everyone for the answers. --=20 Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Thu May 1 21:29:39 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35B44BE4 for ; Thu, 1 May 2014 21:29:39 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [IPv6:2a02:6b8:0:1819::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA08C1E4C for ; Thu, 1 May 2014 21:29:38 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward4l.mail.yandex.net (Yandex) with ESMTP id 6C5AE1440F22 for ; Fri, 2 May 2014 01:29:35 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 23E9113403D8 for ; Fri, 2 May 2014 01:29:35 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id u6QKU9DFTZ-TYZiJwBe; Fri, 2 May 2014 01:29:34 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 87630618-6c12-4816-bef0-44f64d7df303 Message-ID: <5362BCBE.7050703@passap.ru> Date: Fri, 02 May 2014 01:29:34 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: wandboard-quad (IO related?): Spurious interrupt detected [0x000003ff] X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 21:29:39 -0000 Hi All, I get "Spurious interrupt detected [0x000003ff]" at current system: ----- % uname -a FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r265089M: Thu May 1 16:48:06 SAMT 2014 bsam@wandboard:/usr/obj/usr/src/sys/WANDBOARD-QUAD arm ----- Those messages appear at hard IO (CD read/write, network - iperf). Seems no harm so far. Should I ignore or diagnose them deeper? Thanks. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Thu May 1 23:35:32 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85ACFA15 for ; Thu, 1 May 2014 23:35:32 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57E771A41 for ; Thu, 1 May 2014 23:35:31 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wg0Vg-000Hr5-Oh; Thu, 01 May 2014 23:35:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s41NZM76019332; Thu, 1 May 2014 17:35:22 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18LdnMsmSHTVrV1NjvTmGaK Subject: Re: Beaglebone black network performance From: Ian Lepore To: Winston Smith In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 01 May 2014 17:35:22 -0600 Message-ID: <1398987322.22079.138.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s41NZM76019332 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 23:35:32 -0000 On Thu, 2014-05-01 at 13:02 -0400, Winston Smith wrote: > On Thu, May 1, 2014 at 12:47 PM, =D6zkan KIRIK = wrote: > > Rasberry PI's network performance is about 6-7Mbit/s, and ping latenc= ies > > are about 10-20 milliseconds. I think it's too high. I used iperf for > > bandwidth testing. >=20 > The RPi's 10/100 ethernet controller is connected to the BCM2835 SoC > via it's USB controller, so the USB controller has to share it's > bandwidth between the peripherals. >=20 > The BBB also has a 10/100 ethernet, but it's directly supported by the > SoC, so the performance *should* be a little better, particularly when > there's other USB traffic. It's interesting that reports of the rpi network performance are all over the map. The performance is pretty bad for me, iperf says 17.5mbits/sec and pings are in the 7-10ms range (!). =20 I swap the network cable over to an imx53 board (a 10/100 ethernet in a 1ghz soc) and it gets 77 mbits/sec and 200us pings, for comparison. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 1 23:40:05 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78AB8AB0 for ; Thu, 1 May 2014 23:40:05 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D41D1A70 for ; Thu, 1 May 2014 23:40:04 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wg0aB-000K0s-MK; Thu, 01 May 2014 23:40:03 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s41Ne1kb019339; Thu, 1 May 2014 17:40:01 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+jak8aeK1qgjT8fVmBtluY Subject: Re: BBB/I2C: Using ioctl(I2CRDWR) warns: interrupt storm detected on "intr70:" From: Ian Lepore To: Winston Smith In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 May 2014 17:40:01 -0600 Message-ID: <1398987601.22079.140.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 23:40:05 -0000 On Thu, 2014-05-01 at 13:12 -0400, Winston Smith wrote: > Continuing on with working with the I2C interface on the BBB I wrote a > utility to read the BBB's 28 byte system EEPROM on iic0, address 0x50 > which contains the model and serial numbers. See pastebin here: > > http://pastebin.com/p7XwKUGZ > > However, when I run the utility: > > root@beaglebone:~ # ./bbb_eeprom > Read from slave 50 on /dev/iic0, signature=AA:55:33:EE > Model: A335BNLT0A6A > Serial: 0214BBBK4321 > > > I see the following warning on the console: > > interrupt storm detected on "intr70:"; throttling interrupt source > > > Does this mean anything, or is it just a spurious warning. > Nope, that's not spurious, that's a real problem, usually it's a driver bug. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 1 23:45:13 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3290EB86 for ; Thu, 1 May 2014 23:45:13 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 044D31B05 for ; Thu, 1 May 2014 23:45:12 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wg0f8-000Hvd-Om; Thu, 01 May 2014 23:45:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s41Nj8wj019345; Thu, 1 May 2014 17:45:08 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/jxbWQ049tgLNyayJ1nvwi Subject: Re: crochet - why does it (try to) change files in /usr/src? From: Ian Lepore To: Torfinn Ingolfsen In-Reply-To: <20140501230633.5044af70fba9e4d4ed00933e@getmail.no> References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> <20140501230633.5044af70fba9e4d4ed00933e@getmail.no> Content-Type: text/plain; charset="iso-8859-7" Date: Thu, 01 May 2014 17:45:08 -0600 Message-ID: <1398987908.22079.143.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s41Nj8wj019345 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 23:45:13 -0000 On Thu, 2014-05-01 at 23:06 +0200, Torfinn Ingolfsen wrote: > On Thu, 1 May 2014 09:45:58 -0700 > Tim Kientzle wrote: >=20 > >=20 > > On Apr 30, 2014, at 3:56 PM, Torfinn Ingolfsen wrote: > >=20 > > > =3D=3D=3D> lib/libexpat (cleandir) > > > rm -f bsdxml.h bsdxml_external.h libbsdxml.3.gz libbsdxml.3.cat.gz > > > rm: bsdxml.h: Permission denied > > > rm: bsdxml_external.h: Permission denied > > > *** Error code 1 > > >=20 > > > Stop. > > > make[4]: stopped in /usr/src/lib/libexpat > > > (I wasn't running crochet as root, and I suspect it is the reason f= or failure) > > >=20 > > > Question 1: it look to me like the script is trying to remove stuff= (files) from /usr/src. Why is it doing that? > >=20 > > It=A2s not. > >=20 > > The =A1buildworld=A2 target is cleaning the appropriate /usr/obj dire= ctories in case there was a previous build there. >=20 > Ok. Given that the appropriate obj directories (in this case) is in the= ./work sub directory of > # pwd > /usr/home/tingo/work/crochet-freebsd >=20 > should buildworld really try to touch /usr/obj at all? >=20 It's not, if the obj dir is inside ./work then surely the script has set MKOBJDIRPREFIX to reflect that, and that's where it would be doing the delete. Is it possible you had run the script previously as root, and this time you were not root? If so, the object files from the previous run are owned by root, and you don't have permission to delete them. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 1 23:48:26 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CB1DBE0 for ; Thu, 1 May 2014 23:48:26 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5AC51B1D for ; Thu, 1 May 2014 23:48:25 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wg0iH-000JDL-3m; Thu, 01 May 2014 23:48:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s41NmMDm019352; Thu, 1 May 2014 17:48:22 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+x9BKt/oMf1dkmEuVgt/J2 Subject: Re: wandboard-quad (IO related?): Spurious interrupt detected [0x000003ff] From: Ian Lepore To: Boris Samorodov In-Reply-To: <5362BCBE.7050703@passap.ru> References: <5362BCBE.7050703@passap.ru> Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 May 2014 17:48:22 -0600 Message-ID: <1398988102.22079.146.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 23:48:26 -0000 On Fri, 2014-05-02 at 01:29 +0400, Boris Samorodov wrote: > Hi All, > > I get "Spurious interrupt detected [0x000003ff]" at current system: > ----- > % uname -a > FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r265089M: Thu May > 1 16:48:06 SAMT 2014 > bsam@wandboard:/usr/obj/usr/src/sys/WANDBOARD-QUAD arm > ----- > > Those messages appear at hard IO (CD read/write, network - iperf). > Seems no harm so far. Should I ignore or diagnose them deeper? > > Thanks. They are not harmful, and it's baffling to me why sometimes you get tons of them, other times hardly any at all. It's actually normal and expected to get some on a multi-core system, because two cores may try to respond to a pending interrupt at the same time, and the interrupt controller will dispatch the actual interrupt to one of the cores and the spurious-interrupt 3ff number to the other core. So what we really need to be doing in the code is complaining if a whole lot of them are happening (it might indicate some device driver is misbehaving) but ignore the occasional one. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri May 2 00:16:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61C18DAB; Fri, 2 May 2014 00:16:00 +0000 (UTC) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2A8A1D42; Fri, 2 May 2014 00:15:59 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id c13so2601706eek.37 for ; Thu, 01 May 2014 17:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dvh+GK3aK66bssioQjyKeOZum1G4yn/0IW6d//q3Haw=; b=ct6aPULrVgSZQIHMogKQnluHDFogey7NaU87DAp6O8Sd3zwM6HrF2fhwOnJzROaPKs FBav0+/8rD5ReimKtrLQ4EHOpgvIMPTA1Yzvd8mWupERD+kHIyKpa+3oNxCZ+4+8ppZD 8m4pEFkoqQ8ezD/0COnrNaK4v1xZ0YF7TqM1srRHQ8Okgk0rfVoW1RewsnPtJ8sL6veh OQvtIavD4txM9Hd9pSNWFxaeCgnSszoT5GAH1v/KUs/BcXOnkLthhC6Nm5XXVSr8mSaR lj1kE9Kt8WEmq44yAUMoAgKouheZxqA0K1Pc8cZA/+3wX6a9ywiBWHUMtyJ3GF+ve20q vqLQ== X-Received: by 10.15.91.77 with SMTP id r53mr11899846eez.70.1398989757669; Thu, 01 May 2014 17:15:57 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id 45sm165355eeh.9.2014.05.01.17.15.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 17:15:56 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5362E3B7.6000105@hot.ee> Date: Fri, 02 May 2014 03:15:51 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Nathan Whitehorn Subject: Re: crochet - why does it (try to) change files in /usr/src? References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> <5361AC27.8020001@freebsd.org> <5361B72D.2000506@hot.ee> <5361BBB9.9050208@freebsd.org> In-Reply-To: <5361BBB9.9050208@freebsd.org> X-TagToolbar-Keys: D20140502031549241 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 00:16:00 -0000 On 2014-05-01 06:12, Nathan Whitehorn wrote: > On 04/30/14 19:53, Sulev-Madis Silber (ketas) wrote: >> On 2014-05-01 05:06, Nathan Whitehorn wrote: >>> With both mkimg and makefs in the tree now, there should be almost no >>> need for md devices for image generation anymore. >>> -Nathan >> >> That would only work for devices that don't need FAT filesystems. >> >> >> Also, if you want to build image root-less, you need to figure out how >> to get correct file permissions into your image file. Surely you can get >> those into file, just you can't do it directly on filesystem. >> > > makefs knows how to do permissions fine, either from the file itself or > a manifest, and should be acquiring FAT support from NetBSD shortly. It > also supports building opposite-endian UFS file systems, which is very > useful for embedded applications. > -Nathan Not related much, but lately I tried to create partition table where first partition starts from 512k sector #8192... After multiple tries with gpart and fdisk I found that this is totally impossible. Felt like trying to get square peg into round hole, no matter how I tried, it always realigned the partition into wrong sector. I guess this is because of those stupid C/H/S values (does anything use them these days?)? I even looked the code that does this, but didn't know how to exactly fix this. On 11-CURRENT, gpart even complained about partition not aligned to 4m... but it was impossible to have it aligned properly, no matter how I tried. I wish I could force alignment of partitions. Although... now I checked it again and I'm confused what exactly happens there. Can anyone confirm that indeed is wrong behavior. Because it looks like it is. From owner-freebsd-arm@FreeBSD.ORG Fri May 2 00:48:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D62192DE; Fri, 2 May 2014 00:48:09 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5601121; Fri, 2 May 2014 00:48:09 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id f8so1589806wiw.14 for ; Thu, 01 May 2014 17:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xRsmS+Ny6ohIIzLWatP+DtttUBHR3uYQSEYnfxhVQhU=; b=QC0gNm3piAhVx9k8RKuJR1MIuUC+Rrt+/pqi1MK8YCyEzZYqK2fjfHLCwPPD4pBw10 wI3t2ndexa5vBa1ZKA2GEJ+Fyvhd2Yoxt/IBESAUi/izL69Av6HTRHeRk3y0n/xpOS03 rRmph+KmAhffBpT36HTikhwVeZ8hy6Ida4XdQUyerfkdJq9sFbXcaJR3jew/BqeSHXIr AdVZTYkmbT8wC0AbXu+2NkBe9RQWqG39hvYUDQ7VydXtrQ1ult+e+fYrYZ23yuzb6YbK tjVDjvC/QNMbjlGXl6JZzcK+EnDooAa2nfoqlgC/zy7D3u6R9qMY4zSaz0QFCD8WIJEk sUyQ== MIME-Version: 1.0 X-Received: by 10.180.103.5 with SMTP id fs5mr316553wib.33.1398990278217; Thu, 01 May 2014 17:24:38 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Thu, 1 May 2014 17:24:38 -0700 (PDT) In-Reply-To: <1398987601.22079.140.camel@revolution.hippie.lan> References: <1398987601.22079.140.camel@revolution.hippie.lan> Date: Thu, 1 May 2014 20:24:38 -0400 Message-ID: Subject: Re: BBB/I2C: Using ioctl(I2CRDWR) warns: interrupt storm detected on "intr70:" From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 00:48:09 -0000 On Thu, May 1, 2014 at 7:40 PM, Ian Lepore wrote: > Nope, that's not spurious, that's a real problem, usually it's a driver > bug. It happens every time I run my `bbb_eeprom` utility -- how would I go about further debugging this? From owner-freebsd-arm@FreeBSD.ORG Fri May 2 01:17:05 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A227DD9C for ; Fri, 2 May 2014 01:17:05 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7630814A0 for ; Fri, 2 May 2014 01:17:05 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wg263-000Fhb-Dk; Fri, 02 May 2014 01:17:03 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s421H1Gg019409; Thu, 1 May 2014 19:17:01 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19jQ9DojeRo0QNnYqUUqJHp Subject: Re: BBB/I2C: Using ioctl(I2CRDWR) warns: interrupt storm detected on "intr70:" From: Ian Lepore To: Winston Smith In-Reply-To: References: <1398987601.22079.140.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 May 2014 19:17:01 -0600 Message-ID: <1398993421.22079.160.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 01:17:05 -0000 On Thu, 2014-05-01 at 20:24 -0400, Winston Smith wrote: > On Thu, May 1, 2014 at 7:40 PM, Ian Lepore wrote: > > Nope, that's not spurious, that's a real problem, usually it's a driver > > bug. > > It happens every time I run my `bbb_eeprom` utility -- how would I go > about further debugging this? Typically an interrupt storm will happen when a device driver's interrupt handler fails to clear the condition that triggers the interrupt, so it re-interrupts immediately, continuously. After spending a few minutes looking at arm/ti/ti_i2c.c, there's something that seems not-quite-right... the interrupt handler reads the I2C_STAT register and clears any interrupt bits it finds there, but: #define I2C_REG_STAT 0x88 When I look in the AM335x reference manual that's listed as "I2C interrupt status vector (legacy)." There's another register at 0x28 described as "Per-event enabled interrupt status vector." I wonder if just changing the I2C_REG_STAT 0x28 (in ti_i2c.h) would fix things? If not, I'd recommend doing a more thorough version of what I started doing... compare what you see in the manual with the code in terms of register offsets and which bits are being checked and see if there are other lurking glitches. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri May 2 01:29:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E3A424F for ; Fri, 2 May 2014 01:29:42 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5214A15C7 for ; Fri, 2 May 2014 01:29:41 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wg2IG-000DYY-PT; Fri, 02 May 2014 01:29:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s421Tcs3019424; Thu, 1 May 2014 19:29:38 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Gyp/2qD59nkG1Qk3dH1/3 Subject: Re: sdhci_fdt ignores clock-frequency property in .dtb From: Ian Lepore To: Thomas Skibo In-Reply-To: <536118D9.30902@sbcglobal.net> References: <53601B1D.2090702@sbcglobal.net> <1398816332.22079.49.camel@revolution.hippie.lan> <536118D9.30902@sbcglobal.net> Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 May 2014 19:29:38 -0600 Message-ID: <1398994178.22079.161.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 01:29:42 -0000 On Wed, 2014-04-30 at 08:38 -0700, Thomas Skibo wrote: > New patch. > > On 4/29/14, 5:05 PM, Ian Lepore wrote: > > On Tue, 2014-04-29 at 14:35 -0700, Thomas Skibo wrote: > >> Another Zynq bug-fix. One Zynq board out there needs to set this > >> property or else the SD card gets clocked too fast. > >> > >> Thanks, > >> > > > > The documented property for this is max-frequency rather than > > clock-frequency. Is this a completely new property for us, or are you > > just making the code honor what's in our existing dts files? Either way > > we should use the documented name, I'm just wondering if we need to fix > > dts files and give folks a heads-up about the change. > > > > -- Ian > > This is committed as r265208. Thanks. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri May 2 05:59:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80D13EC6 for ; Fri, 2 May 2014 05:59:35 +0000 (UTC) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15DD91C1C for ; Fri, 2 May 2014 05:59:34 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id d17so2796235eek.1 for ; Thu, 01 May 2014 22:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LcmJBkdTyG5c1LEP2EeztGsKkZh3Tt5cnF9bYe1nDCw=; b=BBeoyhNwK3zar/tUqd58iP3kpdgXkl6HKHAT2PPqmW5LsS1c32AKhDzNAY1PkY4zxw 3cZOeOFxnaAJ7WnN5BaUEblpiO1opQOly4gV597MHYxFLsu7mmFOlb+MxwKaoOWD2PZI FwkW0WB6GyzRAF0sY4y34sP5SkYOVgDPbgwi52cKNQbu1efWOZarFQ2t4uO0aRRFpYMc Vz902bkXtYLe/D2qNZmpWyqvcYJUfXPCUNvJN+EWiTBpg+1ihnBuq2dwgyz/GbAs3Nc5 AtlAOgARjkABGW1sUPnuYqad30vgJlC+hdCzoTbkVj73Tr80Ht/jHNTkWR3mQQXrdd+O VW0A== X-Received: by 10.14.2.68 with SMTP id 44mr12905338eee.63.1399010372485; Thu, 01 May 2014 22:59:32 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id y7sm1912438eev.5.2014.05.01.22.59.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 22:59:30 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53633440.3070702@hot.ee> Date: Fri, 02 May 2014 08:59:28 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Winston Smith Subject: BBB/I2C: Read PMIC data References: In-Reply-To: X-TagToolbar-Keys: D20140502085928676 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 05:59:35 -0000 On 2014-05-01 20:12, Winston Smith wrote: > Continuing on with working with the I2C interface on the BBB I wrote a > utility to read the BBB's 28 byte system EEPROM on iic0, address 0x50 > which contains the model and serial numbers. See pastebin here: > > http://pastebin.com/p7XwKUGZ > > However, when I run the utility: > > root@beaglebone:~ # ./bbb_eeprom > Read from slave 50 on /dev/iic0, signature=AA:55:33:EE > Model: A335BNLT0A6A > Serial: 0214BBBK4321 > > > I see the following warning on the console: > > interrupt storm detected on "intr70:"; throttling interrupt source > > > Does this mean anything, or is it just a spurious warning. > > BTW: This is with FreeBSD 11-CURRENT r265163. > > > -W Could you look into reading data from PMIC? I tried... there is all the code that shows power status on boot... there are PMIC I2C specs... there is your code... however I clearly can't write C enough to get that one byte out of PMIC and displayed in human-readable form. And I would want to see this code ending up in base. So I could read that serial and live power status (+ other things from PMIC) from somewhere. PMIC also has power button monitoring and interrupt firing on power input status change. Also battery-related stuff. I wish the onboard PMIC could also measure voltages of inputs and battery. But sadly you need external components to get those functions. While you're there, try not to blow up system by reconfiguring PMIC output voltages... :P although those are protected a bit. From owner-freebsd-arm@FreeBSD.ORG Fri May 2 09:01:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2FE23EB; Fri, 2 May 2014 09:01:29 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3847E1BFF; Fri, 2 May 2014 09:01:29 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id b15so1785292eek.12 for ; Fri, 02 May 2014 02:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uJWth54i/7xBdV+XRqvwV4Cgv5tJ/1c5NPhRSSdVw9E=; b=MUF5jjfKZIixbiMJDdyu10PmYoi3lirq5IhUgOx893AA0SpdR8rTmftvtEK+IjFDqq c9pUKCy+P/XpXXFxKBcbI8j/TIg0p/8FbIwQK4G8rSKzu+Gp5/c1/4DdQtfu3+yxjZZj Vir44pmQSwI8hBFM0zHfPirGXX7wZaDD0M1tA6VaTLtlb6CkY4lYuKaMQskKA882/lX7 51BSKsHzlhUcOAY9oeMiU3rmC5GrV4e8u9DXyjUVizFq9fH45ng6QfxQ7c047klunmYF nrW0Oanai+Ixt0LZjK+IPalaj2tOkhXV9fL4yxck8vyoCMUcJmARxqsAp2pkAZW8rVBn gLRQ== X-Received: by 10.14.5.135 with SMTP id 7mr13832627eel.86.1399021287411; Fri, 02 May 2014 02:01:27 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id bc51sm2995127eeb.22.2014.05.02.02.01.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 02:01:25 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53635ED5.6060508@hot.ee> Date: Fri, 02 May 2014 12:01:09 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> <1398732508.61646.245.camel@revolution.hippie.lan> <1398784968.22079.13.camel@revolution.hippie.lan> In-Reply-To: <1398784968.22079.13.camel@revolution.hippie.lan> X-TagToolbar-Keys: D20140502120109841 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 09:01:30 -0000 On 2014-04-29 18:22, Ian Lepore wrote: > This may be the problem -- ubldr's behavior for finding and using dtb > files is more complex than it used to be. It may be that it used to > claim to find and use the u-boot dtb, but it was really using a static > dtb compiled into the kernel. Now if u-boot provides a valid dtb it'll > actually get used, even if kernel has a static dtb compiled in. > > If you remove the u-boot env var 'fdtaddr' then it will fall back to > using a compiled-in dtb file instead of a loaded one. > > What I've been doing these days is installing my dtb files > in /boot/modules or /boot/kernel and then setting the dtb file name in a > u-boot env var named fdtfile. That makes ubldr find and load the named > file in the place it finds the kernel. > > -- Ian Nice, good suggestion. Now I have this "hack" in bb-uenv.txt: ------------------------------------------------------ uenvcmd=echo "[environment] delete fdtaddr"; env delete fdtaddr; setenv loadfdt ''; setenv fdtfile "/boot/kernel/${fdtfile}"; echo "[environment] loadfdt=${loadfdt}"; echo "[environment] fdtfile=${fdtfile}" ------------------------------------------------------ Not sure where FDT file should go? First I though maybe /boot/fdt... then /boot/kernel seemed good place... Also, maybe we should use this way of loading FDT in every platform it's possible? No static FDT in kernel too. Ruins NFS boot, however... From owner-freebsd-arm@FreeBSD.ORG Fri May 2 11:00:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85DF3BB6 for ; Fri, 2 May 2014 11:00:52 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F39A18ED for ; Fri, 2 May 2014 11:00:51 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id w62so3463335wes.2 for ; Fri, 02 May 2014 04:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=A+ziSGhEkXMoSvE8Q2VGYNfsV/UuQobbDA5pZesGKPM=; b=miXlqLJVI1qC7o5abI3zE3BmMHRpZYpZPXEZM/U37aBI9uunG0/Dih2We9Exr1idBK EvuqqWwx8h/yYolq5sP+TDRZuX+7EMmVpHwAcEEazk4Biom7mfvHMTQORJ9uRkuzg6M6 PyidVnA07oXmK3zDymR6g6TdTHR2M5UcPv2XGKfBanBUBxPPEt78BwVyvIsqMk0luVVe U04R4egLFDQEYkRKi09Rs3WSSc2fdzKdpTohGvBYVBwVu9GpN00mQoN/QYjsxVYipvYQ nUmMF8gJuNRGbz28URdn3oTjSl3xkpFSHGbjqkfeSqkabjQ31HeuMlia0BDp4ctflz/h S/sQ== X-Received: by 10.194.78.4 with SMTP id x4mr1546718wjw.58.1399028449948; Fri, 02 May 2014 04:00:49 -0700 (PDT) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id cw2sm1598133wjb.39.2014.05.02.04.00.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 04:00:49 -0700 (PDT) From: fabiodive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: eMMC /dev/mmcsd1 doesn't exist on BBB FreeBSD 11 Message-Id: <53BFE8F8-D615-4F4F-BC26-2886A537E134@gmail.com> Date: Fri, 2 May 2014 12:00:47 +0100 To: FreeBSD ARM Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 11:00:52 -0000 Hello all! I installed FreeBSD 11 using crochet and u-boot-from ports, I also patched the u-boot 2014-01 to allow 1GHz cpu clock. Everything is running fine, the only problem I have is the missing eMMC device /dev/mmcsd1, I can't copy the system from the sdcard to the integrated flash. The new u-boot I used could be the cause of the issue. Does anyone have any idea? Thank you f. From owner-freebsd-arm@FreeBSD.ORG Fri May 2 11:03:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4747BD01 for ; Fri, 2 May 2014 11:03:56 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D803E197E for ; Fri, 2 May 2014 11:03:55 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x13so3500082wgg.32 for ; Fri, 02 May 2014 04:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T3rxMO1uAgYGE5L+Duj7z/xZHlSHs2CyCRL0UZZKiBA=; b=B8CSMh2XA0aiL32iNg0VmNVSoMvfAGhG3EAv9iQIIy6ps9paO8Hf1A6yz71F1sDvi6 9U9f7UX9wpbnT34d9q5RcU1I/P499BEzRMlO4WCmD1AUW15A+YVG1p0B3K8eMnSggmm9 TsXJOwl9PqpVgHiTckiqTs+TQyMAqxienGy67RUQNeDSKHqc6B2U40ZI45g3nmwkkNmm DKGH34wM0SrwZx2/ulO5j0LD1H6tBhJr+7QboE3GTCgaos0hbCv4Gdl1a0hw7CyFYBvX VwY8CLpSBmOqYSEGNvqIQHdZ/7xhqj+UPVnTCo7uef2GvntrhEs00k3fNxSoETwFCTS1 +lMw== MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr2412284wic.5.1399028634132; Fri, 02 May 2014 04:03:54 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 2 May 2014 04:03:54 -0700 (PDT) In-Reply-To: <53BFE8F8-D615-4F4F-BC26-2886A537E134@gmail.com> References: <53BFE8F8-D615-4F4F-BC26-2886A537E134@gmail.com> Date: Fri, 2 May 2014 07:03:54 -0400 Message-ID: Subject: Re: eMMC /dev/mmcsd1 doesn't exist on BBB FreeBSD 11 From: Winston Smith To: fabiodive Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 11:03:56 -0000 On Fri, May 2, 2014 at 7:00 AM, fabiodive wrote: > I installed FreeBSD 11 using crochet and u-boot-from ports, > I also patched the u-boot 2014-01 to allow 1GHz cpu clock. > Everything is running fine, the only problem I have is the > missing eMMC device /dev/mmcsd1, I can't copy the system > from the sdcard to the integrated flash. The new u-boot I used > could be the cause of the issue. > Does anyone have any idea? Could you post the bootlog? (ideally from the uart0 since dmesg won't have the u-boot messages). -W From owner-freebsd-arm@FreeBSD.ORG Fri May 2 11:35:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39F4362E for ; Fri, 2 May 2014 11:35:25 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD6341C2E for ; Fri, 2 May 2014 11:35:24 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id q59so2025357wes.38 for ; Fri, 02 May 2014 04:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=upu2tuadKWjIXlwT2ToDnaraBD/InxLKMU+EsJGkab4=; b=V6YEsKo2cQHunDrW7fB5rrHqRKpXVesUoI5Rx2q5suioqGDJcc5M0/BAIFnnZeACAI eyD5plrPsKHnW+4423OzfTDLhlYqCMUdEJGKpkzRf1h+Ck9pzZ209yGdWn4n2WMfjY+T M8SAMkaa2j6ASRCNw01FjJWDJMMLjW9Yzs5JKM65h66r3PaK7FdGivKnq6BnIC7d4sWj d55Cz5yAfMdFFw3JCyPfda7PZvY86Q2lQzLQkwZRaPxKct4M9wBCke1lNqcZ7Pwtv8rh mmlZnZeODcCwLGD+OWKwCkWSsNPFAR1DltSpG4t4HNqxmO2CVjj/Gi9WNwoLn1B/3rAO hYaw== MIME-Version: 1.0 X-Received: by 10.180.8.136 with SMTP id r8mr2550123wia.60.1399030522815; Fri, 02 May 2014 04:35:22 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 2 May 2014 04:35:22 -0700 (PDT) In-Reply-To: <9090E42A-59BE-4DC4-AD1C-72278D9E00DF@gmail.com> References: <53BFE8F8-D615-4F4F-BC26-2886A537E134@gmail.com> <9090E42A-59BE-4DC4-AD1C-72278D9E00DF@gmail.com> Date: Fri, 2 May 2014 07:35:22 -0400 Message-ID: Subject: Re: eMMC /dev/mmcsd1 doesn't exist on BBB FreeBSD 11 From: Winston Smith To: fabiodive , FreeBSD ARM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 11:35:25 -0000 I compared it to my bootlog, this is where it diverges: sdhci_ti1: mem 0x481d8000-0x481d8fff irq 28 on simpl= ebus0 mmc1: on sdhci_ti1 cpsw0: mmc1: No compatible cards found on bus Where as I see: sdhci_ti1: mem 0x481d8000-0x481d8fff irq 28 on simpl= ebus0 mmc1: on sdhci_ti1 cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq 40,41,42,43 on simplebus0 I'm not entirely sure why ... it looks like you have a number of extra ko's being loaded (is that a WLAN adapter?). I'd try: 1) Looks like you last built CURRENT on 4/27, it might be time to update & rebuild 2) Removing the WLAN adapter and any extra kernel modules (could the WLAN adapter be intefering with eMMC?) You haven't changed the stock DTS file right? > On May 2, 2014, at 12:03 , Winston Smith wr= ote: >> Could you post the bootlog? (ideally from the uart0 since dmesg won't >> have the u-boot messages). >> >> -W > > U-Boot SPL 2014.01 (Apr 20 2014 - 20:49:40) > reading args > spl: error reading image args, err - -1 > reading bb-uboot.img > reading bb-uboot.img > > > U-Boot 2014.01 (Apr 20 2014 - 20:49:40) > > I2C: ready > DRAM: 512 MiB > NAND: 0 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > *** Warning - readenv() failed, using default environment > > Net: not set. Validating first E-fuse MAC > cpsw, usb_ether > Hit any key to stop autoboot: 0 > mmc0 is current device > SD/MMC found on device 0 > reading bb-uEnv.txt > reading bbubldr > 251113 bytes read in 17 ms (14.1 MiB/s) > reading bboneblk.dtb > 16072 bytes read in 5 ms (3.1 MiB/s) > ## Starting application at 0x88000054 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @9f62b240 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (seaman@bluewaters, Sun Apr 27 02:56:40 WEST 2014) > > DRAM: 512MB > Number of U-Boot devices: 2 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=3D0 slice=3D partition=3D... good. > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=3D0x513948+0x286b8 syms=3D[0x4+0x76630+0x4+0x50c= ea] > /boot/kernel/geom_label.ko text=3D0x499c data=3D0x854+0x30 syms=3D[0x4+0x= f80+0x4+0xfb6] > /boot/kernel/if_run.ko text=3D0x1b660 data=3D0x3f0+0x18 syms=3D[0x4+0x1a4= 0+0x4+0x101c] > /boot/kernel/runfw.ko text=3D0x504 data=3D0x212c syms=3D[0x4+0x350+0x4+0x= 2a9] > /boot/kernel/wlan_acl.ko text=3D0x117c data=3D0x184+0x4 syms=3D[0x4+0x6d0= +0x4+0x4ab] > /boot/modules/cuse4bsd.ko text=3D0x4308 data=3D0x2e8+0xa20 syms=3D[0x4+0x= b50+0x4+0x74a] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by U-Boot at address 0x0x80000100. > Kernel entry at 0x80200100... > Kernel args: (null) > Copyright (c) 1992-2014 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 11.0-CURRENT #0 r264989: Sun Apr 27 02:49:17 WEST 2014 > seaman@bluewaters:/usr/local/crochet-freebsd/work/obj/arm.armv6/usr/l= ocal/freebsd_src_11/sys/BBBELFARO arm > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > module run already present! > module runfw_fw already present! > CPU: Cortex A8-r3 rev 2 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:2 LoUIS:1 > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > real memory =3D 536870912 (512 MB) > avail memory =3D 515964928 (492 MB) > Texas Instruments AM3358 Processor, Revision ES1.1 > random device not loaded; using insecure entropy > Cuse4BSD v0.1.33 @ /dev/cuse > wlan: mac acl policy registered > random: initialized > ofwbus0: > simplebus0: on ofwbus0 > aintc0: mem 0x48200000-0x48200fff on simp= lebus0 > aintc0: Revision 5.0 > ti_scm0: mem 0x44e10000-0x44e11fff on simplebus0 > am335x_prcm0: mem 0x44e00000-0x44e012= ff on simplebus0 > am335x_prcm0: Clocks: System 24.0 MHz, CPU 1000 MHz > am335x_dmtimer0: mem 0x44e05000-0x44e05fff,0x44e31000-0x= 44e31fff,0x48040000-0x48040fff,0x48042000-0x48042fff,0x48044000-0x48044fff,= 0x48046000-0x48046fff,0x48048000-0x48048fff,0x4804a000-0x4804afff irq 66,67= ,68,69,92,93,94,95 on simplebus0 > Timecounter "AM335x Timecounter" frequency 24000000 Hz quality 1000 > Event timer "AM335x Eventtimer" frequency 24000000 Hz quality 1000 > ti_adc0: mem 0x44e0d000-0x44e0efff irq 16 on simplebu= s0 > ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0 > gpio0: mem 0x44e07000-0x44e07fff,0x4804c0= 00-0x4804cfff,0x481ac000-0x481acfff,0x481ae000-0x481aefff irq 96,97,98,99,3= 2,33,62,63 on simplebus0 > gpioc0: on gpio0 > gpiobus0: on gpio0 > gpioled0: at pin(s) 53 on gpiobus0 > gpioled1: at pin(s) 54 on gpiobus0 > gpioled2: at pin(s) 55 on gpiobus0 > gpioled3: at pin(s) 56 on gpiobus0 > uart0: mem 0x44e09000-0x44e09fff irq 72 on s= implebus0 > uart0: console (115384,n,8,1) > ti_edma30: mem 0x49000000-0x490fffff,0x49800000-0x49= 8fffff,0x49900000-0x499fffff,0x49a00000-0x49afffff irq 12,13,14 on simplebu= s0 > ti_edma30: EDMA revision 40014c00 > sdhci_ti0: mem 0x48060000-0x48060fff irq 64 on sim= plebus0 > mmc0: on sdhci_ti0 > sdhci_ti1: mem 0x481d8000-0x481d8fff irq 28 on sim= plebus0 > mmc1: on sdhci_ti1 > cpsw0: mmc1: No compatible cards found on bus > am335x_pmic0: TPS65217C ver 1.2 powered by AC > random: unblocking device. > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > warning: no time-of-day clock registered, system time will not be set acc= urately > Setting hostuuid: 242cfaba-cdb2-11e3-a4fa-9059af69c1b4. > Setting hostid: 0xd23a31f9. > Entropy harvesting: interrupts ethernet point_to_point swi. > Starting file system checks: > /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mmcsd0s2a: clean, 574113 free (577 frags, 71692 blocks, 0.1% fragmen= tation) > Mounting local file systems:. > Writing entropy file:. > Setting hostname: beaglebone. > cpsw0: link state changed to UP > Starting Network: lo0 cpsw0. > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3D21 > cpsw0: flags=3D8843 metric 0 mtu = 1500 > options=3D8000b > ether 90:59:af:69:c1:b4 > inet 192.168.113.18 netmask 0xffffff00 broadcast 192.168.113.255 > inet6 fe80::9259:afff:fe69:c1b4%cpsw0 prefixlen 64 scopeid 0x1 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=3D29 > Starting devd. > Starting pflogd: > add net default: gateway 192.168.113.1 > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > Creating and/or trimming log files. > NFS access cache time=3D60 > Starting casperd. > Clearing /tmp (X related). > Starting rpcbind. > Starting statd. > Starting lockd. > Updating motd:. > Mounting late file systems:. > Performing sanity check on sshd configuration. > Starting sshd. > Starting hostapd. > Configuration file: /etc/hostapd.conf > Failed to get link-level address for interface 'wlan0'. > bsd driver initialization failed. > /etc/rc: WARNING: failed to start hostapd > Starting background file system checks in 60 seconds. > > Wed Apr 30 21:10:14 UTC 2014 > > FreeBSD/arm (beaglebone) (ttyu0) > > login: > > > From owner-freebsd-arm@FreeBSD.ORG Fri May 2 11:38:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 411656B8 for ; Fri, 2 May 2014 11:38:39 +0000 (UTC) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3C5A1C4B for ; Fri, 2 May 2014 11:38:38 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id t61so4466339wes.11 for ; Fri, 02 May 2014 04:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oSq8cekv6Wm3VvDkwECfPV3gx6Tm+9vptXcaPYpdr8k=; b=rumYM1mDRIgI0T42d4x/uUi6ZuEbk98IrwryQOZj5VyAnOc5cO8dlD1TRYOBBOMkur kBg4faimEfirUrK6cJIjNUGj43oM8qsAPLn9+RUhXZqUC73jgyo+1pfgMUvdo8GTO45J iDSbVnd5oqTh/5EnoEDKAq/LnTAtrx66SxbK5krlQxz5DHKIcAAbhebQ1akvv/3mxPLd o5hZhLq3R03k79xIjIgnEA5/cZVSP6N5TrhvidrTN+hubImL/0PSfc+ittCOxWkjAUWu TrlXPPpVVIzvhgIu+eBfSrkQ9aPFKn9Kw8B5opusKAS7yGPX9ReHrqC+V/rsplLuzMuR kRKA== MIME-Version: 1.0 X-Received: by 10.194.78.4 with SMTP id x4mr1694360wjw.58.1399030716766; Fri, 02 May 2014 04:38:36 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 2 May 2014 04:38:36 -0700 (PDT) Date: Fri, 2 May 2014 07:38:36 -0400 Message-ID: Subject: BBB/11-CURRENT: Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' From: Winston Smith To: FreeBSD ARM Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 11:38:39 -0000 Hmmm ... seem to be getting this when booting from SD using the 1Ghz patched u-boot: musbotg0: mem 0x47400000-0x47400fff,0x47401000-0x474012ff,0x47401300-0x474013ff,0x47401400-0x474017ff,0x47401800-0x47401aff,0x47401b00-0x47401bff,0x47401c00-0x47401fff irq 17,18,19 on simplebus0 musbotg0: TI AM335X USBSS v0.0.13 Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' trapframe: 0xc0792b60 FSR=00001008, FAR=ffa00010, spsr=40000193 r0 =00000000, r1 =ffa00000, r2 =00000010, r3 =c0538810 r4 =c2667e00, r5 =c2751000, r6 =c27533b0, r7 =c27533cc r8 =c0666590, r9 =00000001, r10=00000000, r11=c0792bf0 r12=c0538828, ssp=c0792bb0, slr=c0556f10, pc =c0538810 [ thread pid 0 tid 100000 ] Stopped at generic_bs_r_4: ldr r0, [r1, r2] db> Seems to boot ok from eMMC (I have an unpatched 2013.04 u-boot), but it is booting FreeBSD-11-CURRENT (r265163) from the SD card. Funny, this same SD card booted just fine several times yesterday and the day before. Any ideas? -W From owner-freebsd-arm@FreeBSD.ORG Fri May 2 12:44:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C761F8D4 for ; Fri, 2 May 2014 12:44:11 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 626821360 for ; Fri, 2 May 2014 12:44:11 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id w62so3652970wes.30 for ; Fri, 02 May 2014 05:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WbSL9dh7v6ajU2uXR+UZtGPTP4dZYVEiN+5OglhxLzw=; b=tJ4504hUOd8ud7zUMS01+4VGaPiP90Pv4tkdoTlw6wyBKRBA89hANkv9sb79MR2vh4 7iLwZd7bkV6VxDhplcYoUttrpp40GO/YdnZ9+uNjqZkK2OvFxUpJwCvkMIANcTOFY9+u 43x7++fhzIPjva7WMTrt676EUn/9Ifqf0mYc5j44D8c4RhFENFdDyfZe9sMjXcLqGSb5 IYP1QyQYXaLLVXKwXsc/UkrF/RxH/DEdmVdSQKYFp6wLhMvLhF2tBZvmU35nQszbrBx7 2QLStkfksHJf9NWzdrP78ZHxmxMj4OVkYM0+ZwCugsB3eB3nC0yv55h1z/e0ITJENx6n wTgg== MIME-Version: 1.0 X-Received: by 10.194.92.7 with SMTP id ci7mr13844508wjb.7.1399034649608; Fri, 02 May 2014 05:44:09 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 2 May 2014 05:44:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 May 2014 08:44:09 -0400 Message-ID: Subject: Re: BBB/11-CURRENT: Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' From: Winston Smith To: FreeBSD ARM Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 12:44:11 -0000 On Fri, May 2, 2014 at 7:38 AM, Winston Smith wrote: > Hmmm ... seem to be getting this when booting from SD using the 1Ghz > patched u-boot: > > musbotg0: mem > 0x47400000-0x47400fff,0x47401000-0x474012ff,0x47401300-0x474013ff,0x47401400-0x474017ff,0x47401800-0x47401aff,0x47401b00-0x47401bff,0x47401c00-0x47401fff > irq 17,18,19 on simplebus0 > musbotg0: TI AM335X USBSS v0.0.13 When it boots via eMMC I see this right after "musbotg0: TI AM335X USBSS v0.0.13": ti_pruss0: mem 0x4a300000-0x4a37ffff irq 20,21,22,23,24,25,26,27 on simplebus0 ti_pruss0: AM33xx PRU-ICSS And I found this in the FreeBSD-arm mailing lists: http://freebsd.1045724.n5.nabble.com/External-Non-Linefetch-Abort-S-td5831937.html So maybe the patched u-boot isn't properly initializing this. From owner-freebsd-arm@FreeBSD.ORG Fri May 2 12:50:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B39BA99; Fri, 2 May 2014 12:50:09 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9662513B5; Fri, 2 May 2014 12:50:08 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id f8so2277912wiw.15 for ; Fri, 02 May 2014 05:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FV4VRICq45GUjlZpj3/GHTfQaK5UKQJnS70n2KdRbFc=; b=Hdvr6BVtFP4csrbKszRjE00ZJsSV5wYI3hObvK61fx7K2d5YToJWxmor2mYI63PROZ NwcZPGNQVIEvo2z3uKJ4v3perKxUEA0vKD6RAnC2Yy5L/V/k9e27Jl4cQoyqWjWmt/9R 2XBdjfzXumsTuMswUn+JFgkcuUK6F7H7gjHOzdhvAfSGzoXhMHwhviThwckSTssyvpBu MEL9wew6VAlxuYqjv/uIsudpDd5R2hafWqLWndD/+KZTCF26iMywRCpIO4qCrVXt5u8c GO7SoxSsmxj4vmoXomvT8TeBaZTAQsr4w58g65VlzGenfWYTSMGGJ+vK7F48nfCW2s9p rwbw== MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr2812163wic.5.1399035006797; Fri, 02 May 2014 05:50:06 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 2 May 2014 05:50:06 -0700 (PDT) In-Reply-To: <1398993421.22079.160.camel@revolution.hippie.lan> References: <1398987601.22079.140.camel@revolution.hippie.lan> <1398993421.22079.160.camel@revolution.hippie.lan> Date: Fri, 2 May 2014 08:50:06 -0400 Message-ID: Subject: Re: BBB/I2C: Using ioctl(I2CRDWR) warns: interrupt storm detected on "intr70:" From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 12:50:09 -0000 On Thu, May 1, 2014 at 9:17 PM, Ian Lepore wrote: > Typically an interrupt storm will happen when a device driver's > interrupt handler fails to clear the condition that triggers the > interrupt, so it re-interrupts immediately, continuously. > > After spending a few minutes looking at arm/ti/ti_i2c.c, there's > something that seems not-quite-right... the interrupt handler reads the > I2C_STAT register and clears any interrupt bits it finds there, but: > > #define I2C_REG_STAT 0x88 > > When I look in the AM335x reference manual that's listed as "I2C > interrupt status vector (legacy)." There's another register at 0x28 > described as "Per-event enabled interrupt status vector." > > I wonder if just changing the I2C_REG_STAT 0x28 (in ti_i2c.h) would fix > things? If not, I'd recommend doing a more thorough version of what I > started doing... compare what you see in the manual with the code in > terms of register offsets and which bits are being checked and see if > there are other lurking glitches. I spent some time looking over the documentation and didn't see anything obvious beyond what you pointed out (interesting, the latest version of the TRM doesn't even mention the legacy register at 0x88). I changed I2C_REG_STAT to 0x28, rebuilt and there's no change in behavior from from before, the `bbb_eeprom` tool continues to work and also shows the same "interrupt storm detected". This is the change I made: --- ti_i2c.h 2014-05-02 06:58:17.000000000 -0400 +++ /tmp/ti_i2c.h 2014-05-02 08:44:25.000000000 -0400 @@ -52,7 +52,11 @@ #define I2C_IE_ARDY (1UL << 2) /* Register Access Ready interrupt */ #define I2C_IE_NACK (1UL << 1) /* No Acknowledgment interrupt */ #define I2C_IE_AL (1UL << 0) /* Arbitration Lost interrupt */ +#if defined(SOC_TI_AM335X) +#define I2C_REG_STAT 0x28 +#else #define I2C_REG_STAT 0x88 +#endif #define I2C_STAT_XDR (1UL << 14) #define I2C_STAT_RDR (1UL << 13) #define I2C_STAT_BB (1UL << 12) It may be worth adding it simply to keep the AM335X code up to date (rather than using the legacy register). Interestingly, the ti_i2c code already uses the newer I2C_IRQENABLE_CLR and I2C_IRQENABLE_SET non legacy registers for enabling/disabling the IRQs (vs the old legacy I2C_REG_IE); see ti_i2c_set_intr_enable() in ti_i2c.c. -W From owner-freebsd-arm@FreeBSD.ORG Fri May 2 12:58:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B9B2DE8 for ; Fri, 2 May 2014 12:58:34 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0740114D0 for ; Fri, 2 May 2014 12:58:33 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kp14so869353pab.26 for ; Fri, 02 May 2014 05:58:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=5NxRC4lcOa20+fP5hQYvHshRRLwqclayn/3/2dgWiu4=; b=BSiWqcrv2agSA5nC3NwRyDBj3IHbIQhPnevtO4WP6JmHxucxMh/8Wa7qeS8aNRi89W ALCqQIkO5Mq4FlhWIlToUZvssTODPWsWEDEpDxgN0scF6uvojQP5EJaL4949IasTNSSW 7hA1pnHVIKs13NzXKV54weptsYVDL4CQlNAzFGhZ0jVGLZbxa3HoVqaGKRfArSbOVj1d eEN7SfEV5gwbOtnIUlpv6J/H7z/5Stb6fqTepvPzdsTCjZN3JxTs1auF1qNvGMrL80yq +ISlm4cb8vX+f7uAAkRlnOlavUyl/CRiq0zD/o47LUvgjk6c6cFHUL7JhqGyNzDG8LOY mDHw== X-Gm-Message-State: ALoCoQn0I3N8EjF1o4Z+rBiVMST8Xa1MkmZnrW2/nXFrZ9Ho21+bl1XJmLd+SDRY6hur7nzZd6NK X-Received: by 10.67.5.7 with SMTP id ci7mr33831485pad.99.1399035507206; Fri, 02 May 2014 05:58:27 -0700 (PDT) Received: from [192.168.77.199] (S0106000db92912b0.cg.shawcable.net. [68.146.94.47]) by mx.google.com with ESMTPSA id xg8sm182588033pac.26.2014.05.02.05.58.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 05:58:25 -0700 (PDT) Message-ID: <5363966E.2070005@0x544745.com> Date: Fri, 02 May 2014 06:58:22 -0600 From: Tom Everett User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Tim Kientzle Subject: Re: crochet - why does it (try to) change files in /usr/src? References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 12:58:34 -0000 Previously when I tried to build crochet in an jail I ran into troubles creating md devices. I presume upgrading to these new tools would help that too? > Tim Kientzle > May 1, 2014 at 10:45 AM > On Apr 30, 2014, at 3:56 PM, Torfinn Ingolfsen wrote: > >> ===> lib/libexpat (cleandir) >> rm -f bsdxml.h bsdxml_external.h libbsdxml.3.gz libbsdxml.3.cat.gz >> rm: bsdxml.h: Permission denied >> rm: bsdxml_external.h: Permission denied >> *** Error code 1 >> >> Stop. >> make[4]: stopped in /usr/src/lib/libexpat >> (I wasn't running crochet as root, and I suspect it is the reason for failure) >> >> Question 1: it look to me like the script is trying to remove stuff (files) from /usr/src. Why is it doing that? > > Its not. > > The buildworld target is cleaning the appropriate /usr/obj directories in case there was a previous build there. > >> Question 2: why does crochet need root? > > As for requiring root: > > * In theory, it should not require root. > > * In practice, Crochet relies on the FreeBSD build infrastructure, which until recently did require root. > > * In practice, FreeBSDs build infrastructure now has most of the necessary tools to do full system builds and installs without requiring root. (As someone else pointed out, we dont have tools for constructing disk images with multiple partitions, nor for creating FAT partitions.) > > * In practice, no one has stepped forward with Crochet patches to allow it to work without requiring root. It should be relatively simple to get Crochet to compile all the pieces without requiring root. Assembling the final disk image without root privileges will require more effort. > > Cheers, > > 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" > Torfinn Ingolfsen > April 30, 2014 at 4:56 PM > I'm (finally) trying crochet today. Ultimate goal is to try and build > for Cubieboard, but I'm starting with something easy first - RaspberryPi. > > First I had to get all the pieces (the script does a very nice job of > explaining what what is missing. One possible refinement for a future > version would be to list all missing pieces, not just the first one). > Next I discovered that my world build failed. Lookiing at the log file > work/_.buildworld.armv6.log I can see this: > ===> lib/libexpat (cleandir) > rm -f bsdxml.h bsdxml_external.h libbsdxml.3.gz libbsdxml.3.cat.gz > rm: bsdxml.h: Permission denied > rm: bsdxml_external.h: Permission denied > *** Error code 1 > > Stop. > make[4]: stopped in /usr/src/lib/libexpat > (I wasn't running crochet as root, and I suspect it is the reason for > failure) > > Question 1: it look to me like the script is trying to remove stuff > (files) from /usr/src. Why is it doing that? > > Question 2: why does crochet need root? > - all prerequisites (that needs root) are already installed > - the script is installed in ~/work/crochet-freebsd and all building > takes place there > so why does it need root? > > Details: > build machine runs FreeBSD 10.0-release: > $ uname -a > FreeBSD kg-v7.kg4.no 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu > Jan 16 22:34:59 UTC 2014 > root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > build details: > $ sh crochet.sh -b RaspberryPi > Starting at Thu May 1 00:18:36 CEST 2014 > Board: RaspberryPi > Source version is: r265148 > Building FreeBSD version: 10.0 > Image name is: > /usr/home/tingo/work/crochet-freebsd/work/FreeBSD-armv6-10.0-RPI-B-r265148.img > Building FreeBSD version: 10.0 > Object files are at: > /usr/home/tingo/work/crochet-freebsd/work/obj/arm.armv6/usr/src > Found suitable FreeBSD source tree in: > /usr/src > Found FreeBSD xdev tools for armv6 > Found U-Boot sources in: > /usr/home/tingo/work/crochet-freebsd/u-boot-rpi > Building FreeBSD armv6 world at Thu May 1 00:18:36 CEST 2014 > (Logging to > /usr/home/tingo/work/crochet-freebsd/work/_.buildworld.armv6.log) > Failed to build FreeBSD armv6 world. > Log in /usr/home/tingo/work/crochet-freebsd/work/_.buildworld.armv6.log > > Stop. > make[2]: stopped in /usr/src > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src From owner-freebsd-arm@FreeBSD.ORG Fri May 2 13:27:36 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6382C61D for ; Fri, 2 May 2014 13:27:36 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35093173B for ; Fri, 2 May 2014 13:27:35 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WgDUv-00042l-7x; Fri, 02 May 2014 13:27:29 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s42DRO3E020150; Fri, 2 May 2014 07:27:24 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+kQpFailf3EPxhzWQlidoK Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Ian Lepore To: "Sulev-Madis Silber (ketas)" In-Reply-To: <53635ED5.6060508@hot.ee> References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> <1398732508.61646.245.camel@revolution.hippie.lan> <1398784968.22079.13.camel@revolution.hippie.lan> <53635ED5.6060508@hot.ee> Content-Type: text/plain; charset="us-ascii" Date: Fri, 02 May 2014 07:27:24 -0600 Message-ID: <1399037244.22079.167.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 13:27:36 -0000 On Fri, 2014-05-02 at 12:01 +0300, Sulev-Madis Silber (ketas) wrote: > On 2014-04-29 18:22, Ian Lepore wrote: > > This may be the problem -- ubldr's behavior for finding and using dtb > > files is more complex than it used to be. It may be that it used to > > claim to find and use the u-boot dtb, but it was really using a static > > dtb compiled into the kernel. Now if u-boot provides a valid dtb it'll > > actually get used, even if kernel has a static dtb compiled in. > > > > If you remove the u-boot env var 'fdtaddr' then it will fall back to > > using a compiled-in dtb file instead of a loaded one. > > > > What I've been doing these days is installing my dtb files > > in /boot/modules or /boot/kernel and then setting the dtb file name in a > > u-boot env var named fdtfile. That makes ubldr find and load the named > > file in the place it finds the kernel. > > > > -- Ian > > > Nice, good suggestion. Now I have this "hack" in bb-uenv.txt: > > > ------------------------------------------------------ > uenvcmd=echo "[environment] delete fdtaddr"; env delete fdtaddr; setenv > loadfdt ''; setenv fdtfile "/boot/kernel/${fdtfile}"; echo > "[environment] loadfdt=${loadfdt}"; echo "[environment] fdtfile=${fdtfile}" > ------------------------------------------------------ > Just use the plain filename, not /boot/kernel/filename. ubldr knows where to look for them. > > Not sure where FDT file should go? First I though maybe /boot/fdt... > then /boot/kernel seemed good place... > Right now it searches for dtb files the same way as for modules, so it will look in /boot/kernel and /boot/modules. There's been some talk of adding a /boot/dtb directory as the first place to search, and having the build system never automatically install anything to there. That gives users somewhere to put a customized dtb file that won't get wiped out every time a new kernel is installed. > > Also, maybe we should use this way of loading FDT in every platform it's > possible? No static FDT in kernel too. Ruins NFS boot, however... Yeah, when I started down this path my vision was a single IMX6 image that could boot on any imx6-based system because it comes with a collection of dtb files. The user just has to choose the right dtb file on the first boot by setting an env var. That would also require a pretty flexible u-boot, which may or may not be possible. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri May 2 13:36:07 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AD45931 for ; Fri, 2 May 2014 13:36:07 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DF281815 for ; Fri, 2 May 2014 13:36:06 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WgDdF-00097T-FU; Fri, 02 May 2014 13:36:05 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s42Da3cx020162; Fri, 2 May 2014 07:36:03 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19YX3c1YvWHCIjwJgKgcgm+ Subject: Re: BBB/I2C: Using ioctl(I2CRDWR) warns: interrupt storm detected on "intr70:" From: Ian Lepore To: Winston Smith In-Reply-To: References: <1398987601.22079.140.camel@revolution.hippie.lan> <1398993421.22079.160.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 02 May 2014 07:36:03 -0600 Message-ID: <1399037763.22079.171.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 13:36:07 -0000 On Fri, 2014-05-02 at 08:50 -0400, Winston Smith wrote: > On Thu, May 1, 2014 at 9:17 PM, Ian Lepore wrote: > > Typically an interrupt storm will happen when a device driver's > > interrupt handler fails to clear the condition that triggers the > > interrupt, so it re-interrupts immediately, continuously. > > > > After spending a few minutes looking at arm/ti/ti_i2c.c, there's > > something that seems not-quite-right... the interrupt handler reads the > > I2C_STAT register and clears any interrupt bits it finds there, but: > > > > #define I2C_REG_STAT 0x88 > > > > When I look in the AM335x reference manual that's listed as "I2C > > interrupt status vector (legacy)." There's another register at 0x28 > > described as "Per-event enabled interrupt status vector." > > > > I wonder if just changing the I2C_REG_STAT 0x28 (in ti_i2c.h) would fix > > things? If not, I'd recommend doing a more thorough version of what I > > started doing... compare what you see in the manual with the code in > > terms of register offsets and which bits are being checked and see if > > there are other lurking glitches. > > I spent some time looking over the documentation and didn't see > anything obvious beyond what you pointed out (interesting, the latest > version of the TRM doesn't even mention the legacy register at 0x88). > > I changed I2C_REG_STAT to 0x28, rebuilt and there's no change in > behavior from from before, the `bbb_eeprom` tool continues to work and > also shows the same "interrupt storm detected". This is the change I > made: > > --- ti_i2c.h 2014-05-02 06:58:17.000000000 -0400 > +++ /tmp/ti_i2c.h 2014-05-02 08:44:25.000000000 -0400 > @@ -52,7 +52,11 @@ > #define I2C_IE_ARDY (1UL << 2) /* Register Access Ready interrupt */ > #define I2C_IE_NACK (1UL << 1) /* No Acknowledgment interrupt */ > #define I2C_IE_AL (1UL << 0) /* Arbitration Lost interrupt */ > +#if defined(SOC_TI_AM335X) > +#define I2C_REG_STAT 0x28 > +#else > #define I2C_REG_STAT 0x88 > +#endif > #define I2C_STAT_XDR (1UL << 14) > #define I2C_STAT_RDR (1UL << 13) > #define I2C_STAT_BB (1UL << 12) > > > It may be worth adding it simply to keep the AM335X code up to date > (rather than using the legacy register). Interestingly, the ti_i2c > code already uses the newer I2C_IRQENABLE_CLR and I2C_IRQENABLE_SET > non legacy registers for enabling/disabling the IRQs (vs the old > legacy I2C_REG_IE); see ti_i2c_set_intr_enable() in ti_i2c.c. > > -W The next thing I'd do at this point is start some printf-debugging. For starters, just printing the status value read in the interrupt handler might give a clue on which way to go next. I was going to look into this a bit this weekend. I bought myself one of these to play with: http://www.adafruit.com/products/264 and I was going to assemble it and play around this weekend. But now it looks like I may spend the weekend getting my truck ready for some early-season offroad snowbank-bashing. :) -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri May 2 14:24:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A6EF7E6 for ; Fri, 2 May 2014 14:24:37 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAEE71C82 for ; Fri, 2 May 2014 14:24:36 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id x13so1096160wgg.19 for ; Fri, 02 May 2014 07:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2XPHRaUU6sGnSlRlLJjqJ7GFYMdm84jPURcKWACR4PA=; b=KjHUIQWlpKWxcZewar8Wwh1Aque/Ykj/hoI4o9vKldyjCF2+L0axz/J1QkLyNLKnxo XXmDKwcMgvmgu2yv9EomAoTdgwRrrQ/Bwfe0awGf9zRKEJluI7yHQGeUYu1mnq8Ghpgl pVj6IkREMh0Hm/eBsFCVaerLgJyojWYsYuuu1/zLv307g+eMyVqiZRdg/A1SCOFLfKtW Yze55vdNXZG+yS70ImJQhYNadSZrgIAyEb2T1rvpnQuUE5IX5dz3wJtJt4vjd9Wm+Yek 3jIuTj1wlXV5/t+vW5TXveIXOniPtJn1Bd6aQtNgse4Nez402yODJ7V0QnlHmubViqrk vq0A== MIME-Version: 1.0 X-Received: by 10.180.8.136 with SMTP id r8mr3209575wia.60.1399040675016; Fri, 02 May 2014 07:24:35 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 2 May 2014 07:24:34 -0700 (PDT) In-Reply-To: <53633440.3070702@hot.ee> References: <53633440.3070702@hot.ee> Date: Fri, 2 May 2014 10:24:34 -0400 Message-ID: Subject: Re: BBB/I2C: Read PMIC data From: Winston Smith To: "Sulev-Madis Silber (ketas)" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:24:37 -0000 On Fri, May 2, 2014 at 1:59 AM, Sulev-Madis Silber (ketas) wrote: > Could you look into reading data from PMIC? I tried... there is all the > code that shows power status on boot... there are PMIC I2C specs... > there is your code... however I clearly can't write C enough to get that > one byte out of PMIC and displayed in human-readable form. Hmmm ... I'm reading reg 0x0 (CHIPID) and 0xA (STATUS) from the PMIC @ address 0x24 on I2C0, but I get strange values: root@beaglebone:~ # ./bbb_pmic TPS65217 PMIC @ address 24: ChipID: 3D (Unknown) rev 1.13 Status: 00 0x3D isn't a valid CHIPID according to the TPS65217 datasheet; and 0x00 doesn't look like a valid value for the status register (there should be some 1's in there to indicate the ACPWR or USBPWR). I wonder if the device has been "claimed" by the kernel and is inaccessible? From owner-freebsd-arm@FreeBSD.ORG Fri May 2 14:42:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 915B2D26 for ; Fri, 2 May 2014 14:42:05 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EFB81FB8 for ; Fri, 2 May 2014 14:42:05 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id as1so5194845iec.3 for ; Fri, 02 May 2014 07:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ranahminang.net; s=padang; h=mime-version:date:message-id:subject:from:to:content-type; bh=hRvfZag6UCjkFwU/V6gW7n2l5sD1E7+zgifAcWKY83M=; b=Lu5pZcli9VQkw/yakrRvT4cQ77JoQMpnK93f45tK5d7v9GWiV5qWSGaiErpd9BjS3O Avov23GrtFTlehGPv3yqg7ZDZ8Ur9Vrztvt6hmlxYwi8BYDvNKm7TR/SukYvZFlDKvPR oz3NlmOUZ8pzxC0HgCVe2n9+RwBBkBzPphI+w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=hRvfZag6UCjkFwU/V6gW7n2l5sD1E7+zgifAcWKY83M=; b=iRsBQbKbaU50nCsuxj1AmM0FdOS50Nk47lweqfZq9cazja00I2k3JEwX7s44rKt1jb f9zTl8iScFNU2LyUY+dmUsFTjFMde4hTI1i4vNnizK4IAf4nr1xVEWrOM+FwEhT2Ih0j MTcyHJBq2QZyb1Zb/QAPt5bIhig8MfEfGN+VjrQP3nnNOb6+5s7/QnIC8pwJ4/qaQwnw 753SQUxaqb8d3LZDUtvty+idxKfyHh0NpqlrpMrjD3oCogmK7HsdAIf/0BAY0CIDVLJ6 6LsBUAarKkdeIWsawiiFKuOr4aTsg5MsXd5mAPpgfXE8zEL6sWTMZFcUoec24g0V2DSr GtYw== X-Gm-Message-State: ALoCoQnBpFLChFCuJLV9D7fYrCyI1ky2Z9SNQoGxBpJ7EdJZBv+1KHxuLh8TnzEDDKjrgWIKlECD MIME-Version: 1.0 X-Received: by 10.42.223.202 with SMTP id il10mr2616093icb.65.1399041724752; Fri, 02 May 2014 07:42:04 -0700 (PDT) Received: by 10.64.6.168 with HTTP; Fri, 2 May 2014 07:42:04 -0700 (PDT) X-Originating-IP: [36.76.56.50] Date: Fri, 2 May 2014 21:42:04 +0700 Message-ID: Subject: install or download port collection? From: Paul Darius To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:42:05 -0000 hi there, i just new to fbsd and rpi. the fbsd image downloaded from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.0/FreeBSD-10.0-STABLE-arm-armv6-RPI-B-20140427-r265018.img.bz2 and the image successfully dd into sdcard 32GB. surprise that I can not find sysinstall, but at the end I find bsdinstall question is, how to install or download the port collections ? i try using ftp and http direct but no luck tia P From owner-freebsd-arm@FreeBSD.ORG Fri May 2 14:44:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AA44D97 for ; Fri, 2 May 2014 14:44:10 +0000 (UTC) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18D031FD4 for ; Fri, 2 May 2014 14:44:09 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id jw12so5528149veb.13 for ; Fri, 02 May 2014 07:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omni.co.id; s=padang; h=mime-version:date:message-id:subject:from:to:content-type; bh=Vk70JtieyUq/e4qCZdNp3Rm7f4T9c/Hy8HY1YGcE57U=; b=A5tLtAlSBHVGwF/6ZAHEacEMyrYsO3ssjLisqmiroD0QLMjAgALoEbLy7xwne3OiXn UYtI4IiR7i1xTBVnXqm5MjQBKziBbzrjGkrY8ZqzzLlo/bQVhmiMxY/Z1h85WMUjFA/P 6BT5WGu7n8kk2ZEnh1A/8Kx5Uf/2s3RIfULi0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Vk70JtieyUq/e4qCZdNp3Rm7f4T9c/Hy8HY1YGcE57U=; b=Z8IvgiBbZSOmdv2mQHB6cT90yHXjCvB85yMpoWc9vr0ekWrXD8IQKs08bqbRCVJcMW 1iE8F4KWECSMl80q6PGJKZVkcVSH0XMrVcwgeXwCtBVNi9WlIiyun692SbXfmRuy6h5U o9o09pFIOvsbH/xSeoGqcRzx/1R21TAtdCsaa2R44HVay0L8kpZplBzaumCPoC2biHHr jUtKGYv95s8BkkwRygtCX8AVjDJ+Y+N/z81zQtUJ35DRkXWFQg8Eo1CS1AN0SuZYc10N wNWRNfaP05FNr+ifFcO31eQEMpk61b2OwDWGsqEdu519IKLwBRDaf5AhM8mSlHap1S21 bkjw== X-Gm-Message-State: ALoCoQmT4WhfbvDqrvWu9FbE+8g2S49q9eHoygClac32ZPTVIwCs8HZx/q5Hg1Hyi8zrZ4IcIuGa MIME-Version: 1.0 X-Received: by 10.52.251.136 with SMTP id zk8mr180095vdc.82.1399041848833; Fri, 02 May 2014 07:44:08 -0700 (PDT) Received: by 10.58.19.71 with HTTP; Fri, 2 May 2014 07:44:08 -0700 (PDT) X-Originating-IP: [36.76.56.50] Date: Fri, 2 May 2014 21:44:08 +0700 Message-ID: Subject: is the swap needed ? From: Paul Darius To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:44:10 -0000 hi there, after dd the image info the sdcard, i can not found swap partition is the swap needed ? if so, how to create it ? tia P From owner-freebsd-arm@FreeBSD.ORG Fri May 2 14:44:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B2BEF31 for ; Fri, 2 May 2014 14:44:53 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 292951FEF for ; Fri, 2 May 2014 14:44:53 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id c1so1948699igq.4 for ; Fri, 02 May 2014 07:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ranahminang.net; s=padang; h=mime-version:date:message-id:subject:from:to:content-type; bh=Vk70JtieyUq/e4qCZdNp3Rm7f4T9c/Hy8HY1YGcE57U=; b=GPxo4k9T3I0zrYUOgiZxco3oavJbft8sd7dMQY4T7weBxa2fNeJdC4IUEY42l1q7IJ Pw35TNXOd77OSwjelePfx5bjBunRKgcKgdeU9R3YJDV2Wp4Y8JQnPXjOTl6gYO4SST2y XP85Z2F6fHu5YkFPLMBzMjTqeHbNWbal+z52w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Vk70JtieyUq/e4qCZdNp3Rm7f4T9c/Hy8HY1YGcE57U=; b=Q9jf6bMzk9A4snG+ChdFSN0Hn6mnL94HfUpethLCHfkPegnQwAMQ59p7wrq8Vw5a/p MqB7quWPpI37OVKdt0Qq1M7lRvN/U1AoEW5RFxZDwphV46aqwwjSIBCPtZS8ED5UsrEW ljIrZtDOVDDpuhder+HQmrn4qocxGpmv22LmeWU1SCf0Vsaawl+YOqM8eMLac+Kd94iS TaJk8toEgC+2D/8uilc7NIk3bmcIaqSdEx5Lq7V4ilFZx6Dtvh8YuOZYza18C174dau3 LrG25/OOkSbOn29SgTu5YCl97NAYbPLmDgNW/2x8DTTpuR8tsfpfBdy6a7yLlajWDOgN 3YkA== X-Gm-Message-State: ALoCoQmOygs0zSjovFxVkByr7vmmoFxlGOt08kvszTy55sfJ8ExuCJN1Tq7MZ9qISa+xxQQnOE+5 MIME-Version: 1.0 X-Received: by 10.43.155.84 with SMTP id lh20mr2540697icc.81.1399041892513; Fri, 02 May 2014 07:44:52 -0700 (PDT) Received: by 10.64.6.168 with HTTP; Fri, 2 May 2014 07:44:52 -0700 (PDT) X-Originating-IP: [36.76.56.50] Date: Fri, 2 May 2014 21:44:52 +0700 Message-ID: Subject: is the swap needed ? From: Paul Darius To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:44:53 -0000 hi there, after dd the image info the sdcard, i can not found swap partition is the swap needed ? if so, how to create it ? tia P From owner-freebsd-arm@FreeBSD.ORG Fri May 2 15:02:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EED376AC for ; Fri, 2 May 2014 15:02:32 +0000 (UTC) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC2B51214 for ; Fri, 2 May 2014 15:02:32 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id x10so4870986pdj.15 for ; Fri, 02 May 2014 08:02:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=BvEpacehTzeszZsChfjj4WX65kVHs7Mjw7IfJo07nhI=; b=S5EigCraPdXtxqHIA2ci6DcxMYv7RivlDBL6Jay/wNFaKmMjtAiTKrToBBfsbEZU3N /G5D/SpKilDNePvaUyyld8ONErAI9qHA5mkCUc8sn9ISQxaSlAGSaZ92oQEDZ7B185YW xwhOUrkTbIQzTPhipKXJpEG3e+4i5tw/GWRZevTifRAEU24Y51mM/hL2hHIAxu3viV+S JqKCTQesddYLzFYMYuHN7NUY3cNtwxTrzx797inVpYqZuXCTp2hiIlu9mn8Upi0Wo6kJ 66K+LT+wEbf/k6NGfIAQQrXcsCwv2c54i+0hWSLjiLxpwpDf0wSuaDfsB9VhGX8jkNVW 0wBw== X-Gm-Message-State: ALoCoQkCaRla6L5MRwlZ82Ayh6blVCzoymqs7Dyf5o2gOwVmthyYlrNpQRK3vXTEV+a5sVzn3zlT X-Received: by 10.66.122.1 with SMTP id lo1mr36126394pab.118.1399042951667; Fri, 02 May 2014 08:02:31 -0700 (PDT) Received: from [192.168.77.199] (S0106000db92912b0.cg.shawcable.net. [68.146.94.47]) by mx.google.com with ESMTPSA id kt8sm183899555pab.7.2014.05.02.08.02.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 08:02:29 -0700 (PDT) Message-ID: <5363B383.6080206@0x544745.com> Date: Fri, 02 May 2014 09:02:27 -0600 From: Tom Everett User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Paul Darius Subject: Re: is the swap needed ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:02:33 -0000 Here's a cut-paste from my notes. Basically, "add a swap partition and then enable it" gpart add -s 128M -t freebsd ada0 swapon /dev/ada0s2 It might not be ada0 in your case. > Paul Darius > May 2, 2014 at 8:44 AM > hi there, > > after dd the image info the sdcard, i can not found swap partition > is the swap needed ? if so, how to create it ? > > tia > > P > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri May 2 15:07:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D167AA7 for ; Fri, 2 May 2014 15:07:34 +0000 (UTC) Received: from forward10l.mail.yandex.net (forward10l.mail.yandex.net [IPv6:2a02:6b8:0:1819::a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEB081280 for ; Fri, 2 May 2014 15:07:33 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward10l.mail.yandex.net (Yandex) with ESMTP id 94163BA10D8; Fri, 2 May 2014 19:07:21 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 290C613400CD; Fri, 2 May 2014 19:07:21 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id bmf0oruKFx-7KFK27eX; Fri, 2 May 2014 19:07:20 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 4b606e8f-6d5f-4299-a5f8-277efd573f17 Message-ID: <5363B4A8.1070509@passap.ru> Date: Fri, 02 May 2014 19:07:20 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Darius , freebsd-arm@freebsd.org Subject: Re: install or download port collection? References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:07:34 -0000 02.05.2014 18:42, Paul Darius пишет: > > i just new to fbsd and rpi. > > the fbsd image downloaded from > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.0/FreeBSD-10.0-STABLE-arm-armv6-RPI-B-20140427-r265018.img.bz2 > and the image successfully dd into sdcard 32GB. > > surprise that I can not find sysinstall, but at the end I find bsdinstall > question is, how to install or download the port collections ? > i try using ftp and http direct but no luck It;s covered by the FreeBSD Handbook, Section 5.5 "5.5. Using the Ports Collection": http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Fri May 2 15:13:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7303BD1 for ; Fri, 2 May 2014 15:13:21 +0000 (UTC) Received: from forward2l.mail.yandex.net (forward2l.mail.yandex.net [IPv6:2a02:6b8:0:1819::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87E2D132F for ; Fri, 2 May 2014 15:13:21 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward2l.mail.yandex.net (Yandex) with ESMTP id 070E51AC0F26; Fri, 2 May 2014 19:13:10 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 909612C3867; Fri, 2 May 2014 19:13:10 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id SMYece9wEI-DAtKEQbj; Fri, 2 May 2014 19:13:10 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: eadcb6ef-b8a7-4683-8334-8edd5b109111 Message-ID: <5363B606.6000700@passap.ru> Date: Fri, 02 May 2014 19:13:10 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Darius , freebsd-arm@freebsd.org Subject: Re: is the swap needed ? References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:13:21 -0000 02.05.2014 18:44, Paul Darius пишет: > > after dd the image info the sdcard, i can not found swap partition > is the swap needed ? I'd say it mostly depends upon your needs and your board capabilities. So I'd say just use the board, watch the system and you'll finally know. ;-) > if so, how to create it ? The FreeBSD Handbook, Section 12.12. "Adding Swap Space": http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/adding-swap-space.html -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Fri May 2 15:21:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A52DF88 for ; Fri, 2 May 2014 15:21:09 +0000 (UTC) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C38F613CF for ; Fri, 2 May 2014 15:21:08 +0000 (UTC) Received: from 127.0.0.1 (lumumba.torservers.net [77.247.181.163]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id s42ExJXa075004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 2 May 2014 10:59:25 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Message-ID: <5363B2B8.7010104@ceetonetechnology.com> Date: Fri, 02 May 2014 10:59:04 -0400 From: George Rosamond MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: install or download port collection? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:21:09 -0000 Paul Darius: > hi there, > > i just new to fbsd and rpi. > > the fbsd image downloaded from > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.0/FreeBSD-10.0-STABLE-arm-armv6-RPI-B-20140427-r265018.img.bz2 > and the image successfully dd into sdcard 32GB. > > surprise that I can not find sysinstall, but at the end I find bsdinstall > question is, how to install or download the port collections ? > i try using ftp and http direct but no luck Paul: The likely best route to install the ports tree is to use portsnap(8). >From there, you can use whatever tools you prefer... subversion, svnup, etc to update the source, portmaster or whatever to update the ports. George From owner-freebsd-arm@FreeBSD.ORG Fri May 2 15:30:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 312D73D0 for ; Fri, 2 May 2014 15:30:22 +0000 (UTC) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2A9B1510 for ; Fri, 2 May 2014 15:30:21 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kx10so2812685pab.19 for ; Fri, 02 May 2014 08:30:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=0GARjL7/f37iFYQ5Vr4kJV4sap6ZMvnSQxmRT73HCPU=; b=S6bJLbx0yCx41sxLqNrw45z78SDb0z6cLpKgONdhgpYbnXPa14qHHWndll7ehoHxMP XrkWuhD0zoblotKkBRL6nUp4fGaTMp/3EE9jOCOLPpeeaegV47NT+UbO9hJ11tYzNddr 0tUih0xIWjrkF96zpWcPeGzVrj7swuyr4N7gQ0xez5Hsama3prb4dsmWFuYCZXrErqz+ ii8vc3img73hMz7eTT5PXngS7DaNyy7K5IAuUtHTwd1Lda2fd7lShci58niX37ga4v/j 7OILN/WqUQ+p+dSRimzVlPpef8AiGSIDaIms5xSQCsRRKmlyuTvCAXDcRycqP31GoZkh UZBw== X-Gm-Message-State: ALoCoQlU7JnxhSo1plMLJvKPmWPHyWKLaN7YYpICXNR0j9aSFk+sFORTeTEejVcMHTLATydREMJV X-Received: by 10.66.122.1 with SMTP id lo1mr36394710pab.118.1399044615030; Fri, 02 May 2014 08:30:15 -0700 (PDT) Received: from lgwl-achen.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id fk4sm185340954pab.23.2014.05.02.08.30.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 08:30:13 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_64858297-1955-45FA-A052-B5977587DD8A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: BBB/I2C: Read PMIC data From: Warner Losh In-Reply-To: Date: Fri, 2 May 2014 09:30:11 -0600 Message-Id: References: <53633440.3070702@hot.ee> To: Winston Smith X-Mailer: Apple Mail (2.1874) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:30:22 -0000 --Apple-Mail=_64858297-1955-45FA-A052-B5977587DD8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 2, 2014, at 8:24 AM, Winston Smith = wrote: > On Fri, May 2, 2014 at 1:59 AM, Sulev-Madis Silber (ketas) > wrote: >> Could you look into reading data from PMIC? I tried... there is all = the >> code that shows power status on boot... there are PMIC I2C specs... >> there is your code... however I clearly can't write C enough to get = that >> one byte out of PMIC and displayed in human-readable form. >=20 > Hmmm ... I'm reading reg 0x0 (CHIPID) and 0xA (STATUS) from the PMIC @ > address 0x24 on I2C0, but I get strange values: >=20 > root@beaglebone:~ # ./bbb_pmic > TPS65217 PMIC @ address 24: > ChipID: 3D (Unknown) rev 1.13 > Status: 00 >=20 >=20 > 0x3D isn't a valid CHIPID according to the TPS65217 datasheet; and > 0x00 doesn't look like a valid value for the status register (there > should be some 1's in there to indicate the ACPWR or USBPWR). >=20 > I wonder if the device has been "claimed" by the kernel and is = inaccessible? Only if the kernel is actively accessing them so your transactions are = messed up. In the kernel, all the bridge knows about is transactions of one flavor = or another. This may indicate a more fundamental issue going on, either in your = belief that it is at 24, or in the address (which is 7 bits) gets translated to 8 = bits. Try a left shift 1 bit. Warner --Apple-Mail=_64858297-1955-45FA-A052-B5977587DD8A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTY7oDAAoJEGwc0Sh9sBEAk1AP/imfctYnJ7yiDhqIHNLsMD5A 8ZP6EGSUIz4s2cAlaYH6jRGbL+dtmuXb3VPH8qJgQdmk83pkHK60Arnbiqhwq/ja pdaxAmWJZJnuh/18WFKdsv9VGREwXAXDWWtMjEFHejuH20sa/7VWaS7WAgB41MXj UhMU8Dpjoif9BKhIpO4O+T1nhk1ZVhmH/tq9LpLrr19ae6ezYBmweC0l8pdfq51h 0x2xnKvDCtOodDNBucU3sfJvCIgmBjpWmIP1uG4scnG+GOlx+XlkyPRQ21ZAw+bE DEGgNDlDraHIxjLp1AlLP7gnexZ4pvFcJSgjKqDCV4I/T0p3Hy/ZF9ywx8rthApd rL5yxOZtT6TrnUio5Lintpz0HO1jQjabr+N2RzC1wS+d0ERIGEAqcXtLwrfjJRqv v/8Av3Va69wT+wx7Lj5LRUmKkih64RS3ligc3ve5MSOmwLqMU14UKA/PP8Eg3T+Z bOAg4pzK9n6w5QBv7UCUoxt862C8KRYSGd9eR8sV+yMPbPTAixx/BESI2YygubqG ExOf/haK2A42Hu5WMIniwqWb8v7h+qUqtWY5eHnZ0ZkMsWN+EKYFJpbTbEutrvgt qt0brfqcfMATilTpgVWWv7O6p2UF0RbvcI3j3/ojSheAF7UD8xh8/ZOtdTIMBCA+ dFWRap4a993nuxL4oPyO =zmGe -----END PGP SIGNATURE----- --Apple-Mail=_64858297-1955-45FA-A052-B5977587DD8A-- From owner-freebsd-arm@FreeBSD.ORG Fri May 2 15:30:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D8E846C for ; Fri, 2 May 2014 15:30:42 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 230BE1516 for ; Fri, 2 May 2014 15:30:41 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WgFQ8-000Lhn-LV; Fri, 02 May 2014 15:30:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s42FUbGg020291; Fri, 2 May 2014 09:30:37 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/nA4IZ60mAuhKJ7xme5J74 Subject: Re: install or download port collection? From: Ian Lepore To: George Rosamond In-Reply-To: <5363B2B8.7010104@ceetonetechnology.com> References: <5363B2B8.7010104@ceetonetechnology.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 02 May 2014 09:30:37 -0600 Message-ID: <1399044637.22079.177.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:30:42 -0000 On Fri, 2014-05-02 at 10:59 -0400, George Rosamond wrote: > Paul Darius: > > hi there, > > > > i just new to fbsd and rpi. > > > > the fbsd image downloaded from > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.0/FreeBSD-10.0-STABLE-arm-armv6-RPI-B-20140427-r265018.img.bz2 > > and the image successfully dd into sdcard 32GB. > > > > surprise that I can not find sysinstall, but at the end I find bsdinstall > > question is, how to install or download the port collections ? > > i try using ftp and http direct but no luck > > > Paul: > > The likely best route to install the ports tree is to use portsnap(8). > > From there, you can use whatever tools you prefer... subversion, svnup, > etc to update the source, portmaster or whatever to update the ports. > > George > Portsnap is a painful many-hour process on an RPi. I remember trying it last year and it ran for hours and always crashed or panicked before completion. Hopefully we've got the crash/panic stuff worked out these days, but the time is still going to be bad. I prefer to keep a master ports tree on an nfs server and just mount it on arm boards as needed, and build ports with WRKDIRPREFIX=/tmp. If you're not set up for NFS (and don't want to be) another viable option might be to do the portsnap process on a faster machine with the results placed onto a usb drive that you can attach to the rpi. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri May 2 16:00:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20801456 for ; Fri, 2 May 2014 16:00:03 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D081E1A32 for ; Fri, 2 May 2014 16:00:02 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3AB651FE02B; Fri, 2 May 2014 17:59:55 +0200 (CEST) Message-ID: <5363C133.2000304@selasky.org> Date: Fri, 02 May 2014 18:00:51 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Johny Mattsson , freebsd-arm@freebsd.org Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> In-Reply-To: <5362638B.1080104@selasky.org> 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 16:00:03 -0000 On 05/01/14 17:08, Hans Petter Selasky wrote: > On 05/01/14 01:34, Johny Mattsson wrote: >> On 1 May 2014 00:14, Ian Lepore wrote: >> >>> I was doing some testing on a wandboard (about twice as fast an an rpi) >>> with >>> more than 20k int/sec without having any problems. >>> >> >> On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k >> int/sec, on Linux. Admittedly at that point my shell wasn't what you'd >> call >> "responsive" however =) The ISR in that scenario was the GPIO handler, so >> probably a bit more light-weight than an audio ISR. > > Hi, > > I'll have a look and see if I can fix it. > > --HPS Hi, Here is a patch (work in progress) which you can try: http://home.selasky.org:8192/dwc_otg_isoc_support_wip.diff Still not working 100% reliable. Trying to figure out the last bits and pieces. --HPS From owner-freebsd-arm@FreeBSD.ORG Fri May 2 16:24:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ACE7737 for ; Fri, 2 May 2014 16:24:56 +0000 (UTC) Received: from mail-01.thismonkey.com (220-245-31-196.static.tpgi.com.au [220.245.31.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-01.thismonkey.com", Issuer "Thismonkey IT Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 749B31E49 for ; Fri, 2 May 2014 16:24:54 +0000 (UTC) X-TM-Via-MX: mail-01.thismonkey.com Received: from utility-01.thismonkey.com (utility-01.thismonkey.com [10.1.1.32]) by mail-01.thismonkey.com (8.14.5/8.14.5) with ESMTP id s42GOYQM058203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 May 2014 02:24:34 +1000 (EST) (envelope-from scott@utility-01.thismonkey.com) Received: from utility-01.thismonkey.com (localhost [127.0.0.1]) by utility-01.thismonkey.com (8.14.5/8.14.5) with ESMTP id s42GOYWp079416; Sat, 3 May 2014 02:24:34 +1000 (EST) (envelope-from scott@utility-01.thismonkey.com) Received: (from root@localhost) by utility-01.thismonkey.com (8.14.5/8.14.5/Submit) id s42GOIMH079414; Sat, 3 May 2014 02:24:18 +1000 (EST) (envelope-from scott) Date: Sat, 3 May 2014 02:24:18 +1000 From: Scott Aitken To: freebsd-arm@freebsd.org Subject: Re: freebsd-arm Digest, Vol 419, Issue 7 Message-ID: <20140502162417.GA79349@utility-01.thismonkey.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (mail-01.thismonkey.com [10.1.2.50]); Sat, 03 May 2014 02:24:34 +1000 (EST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 16:24:56 -0000 On Fri, May 02, 2014 at 11:35:27AM +0000, freebsd-arm-request@freebsd.org wrote: > On 05/01/14 01:34, Johny Mattsson wrote: > > On 1 May 2014 00:14, Ian Lepore wrote: > > > >> I was doing some testing on a wandboard (about twice as fast an an rpi) > >> with > >> more than 20k int/sec without having any problems. > >> > > > > On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k > > int/sec, on Linux. Admittedly at that point my shell wasn't what you'd call > > "responsive" however =) The ISR in that scenario was the GPIO handler, so > > probably a bit more light-weight than an audio ISR. > > Hi, > > I'll have a look and see if I can fix it. > > --HPS I'd be happy to test if necessary. Scott From owner-freebsd-arm@FreeBSD.ORG Fri May 2 20:46:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B01252A1 for ; Fri, 2 May 2014 20:46:04 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 497451948 for ; Fri, 2 May 2014 20:46:04 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u56so4123010wes.23 for ; Fri, 02 May 2014 13:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/DbBqwORO3PdV602Y99crbB0gcI4cHxKhG00Uu4EIH8=; b=GnVtCqIp7vFQNLgYcb+GJNrHQbVpmodCCvex0gS2HjCUAZuEKth39CMG/gvXQvXCfE 3Bp7FWrnPOtZe3xKJIhFdqeI4xeIyHgXfb/4OAZ2x2SXVjhzTWhZ19kbYwbumnvCPaOi VmIhybn+U4cZ1REDs2KXqO6aN4PETEq8QZp11hzd64KFsSnvZL84UXKEIpYf8uMLTOj8 huV4yez1/+t5B30rlp/e35+qwCNvp935vbEx8zScwT85Wc5hwdR6PXyYyN3Htb22Y/J3 pEkLN0AFK7Pa1zDrfyCA3JTLfCwoaPL2RWPkaxBrhlqNRwVAGu1Tz8Z+Fs9+6ubC9Vlw gkeg== MIME-Version: 1.0 X-Received: by 10.180.228.42 with SMTP id sf10mr4545334wic.33.1399063562406; Fri, 02 May 2014 13:46:02 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 2 May 2014 13:46:02 -0700 (PDT) In-Reply-To: References: <53633440.3070702@hot.ee> Date: Fri, 2 May 2014 16:46:02 -0400 Message-ID: Subject: Re: BBB/I2C: Read PMIC data From: Winston Smith To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 20:46:04 -0000 On Fri, May 2, 2014 at 11:30 AM, Warner Losh wrote: > Only if the kernel is actively accessing them so your transactions are messed up. > In the kernel, all the bridge knows about is transactions of one flavor or another. > This may indicate a more fundamental issue going on, either in your belief that > it is at 24, or in the address (which is 7 bits) gets translated to 8 bits. Try a left > shift 1 bit. Alright, figured it out. The "dummy" write that precedes the read is not a dummy, you're sending a command to the I2C device. For a EEPROM, you send it a 2 byte address of where to read. For the PMIC, you need to send it a *1-byte* register ID! I've updated the tool and renamed it `bbb_sysutil.c`: http://pastebin.com/NhMy9D7d Here's the output (still working on the "interrupt storm" issue!): root@beaglebone:~ # ./bbb_sysutil TPS65217 PMIC @ address 24: ChipID: E2 TPS65217C rev 1.2 Status: 08 ACPWR interrupt storm detected on "intr70:"; throttling interrupt source EEPROM @ address 50: signature=AA:55:33:EE Model: A335BNLT0A6A Serial: 0214BBBK4321 Let me know if there is any more data you want from the PMIC. -W From owner-freebsd-arm@FreeBSD.ORG Sat May 3 00:10:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28532477 for ; Sat, 3 May 2014 00:10:13 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C4CDA1ABD for ; Sat, 3 May 2014 00:10:12 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s430A0bX027741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 3 May 2014 02:10:00 +0200 (CEST) (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 s4309mmH089301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2014 02:09:48 +0200 (CEST) (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 s4309mTG061179; Sat, 3 May 2014 02:09:48 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s4309l5D061178; Sat, 3 May 2014 02:09:47 +0200 (CEST) (envelope-from ticso) Date: Sat, 3 May 2014 02:09:46 +0200 From: Bernd Walter To: Winston Smith Subject: Re: BBB/I2C: Read PMIC data Message-ID: <20140503000946.GK52252@cicely7.cicely.de> References: <53633440.3070702@hot.ee> 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=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 00:10:13 -0000 On Fri, May 02, 2014 at 04:46:02PM -0400, Winston Smith wrote: > On Fri, May 2, 2014 at 11:30 AM, Warner Losh wrote: > > Only if the kernel is actively accessing them so your transactions are messed up. > > In the kernel, all the bridge knows about is transactions of one flavor or another. > > This may indicate a more fundamental issue going on, either in your belief that > > it is at 24, or in the address (which is 7 bits) gets translated to 8 bits. Try a left > > shift 1 bit. > > Alright, figured it out. The "dummy" write that precedes the read is > not a dummy, you're sending a command to the I2C device. For a > EEPROM, you send it a 2 byte address of where to read. For the PMIC, > you need to send it a *1-byte* register ID! > > I've updated the tool and renamed it `bbb_sysutil.c`: > > http://pastebin.com/NhMy9D7d > > Here's the output (still working on the "interrupt storm" issue!): > > root@beaglebone:~ # ./bbb_sysutil > TPS65217 PMIC @ address 24: > ChipID: E2 TPS65217C rev 1.2 > Status: 08 ACPWR > interrupt storm detected on "intr70:"; throttling interrupt source > EEPROM @ address 50: signature=AA:55:33:EE > Model: A335BNLT0A6A > Serial: 0214BBBK4321 So you get valid data. Sounds like the interupt handler is working for what it needs, but not closing an interrupt down. Since most part of acknowleging an interrupt to the hardware is the same for all interrupt sources I expect the IIC controller isn't made aware that an interrupt was processed. One wild guess - without knowing the Sitara IIC controller at all: You write and read in one transaction, the controller may issue an interrupt on read and write, but only the read is handled, so the write interrupt stays active. It could also bee that the controler signals other states, which are unhandled - e.g. addressed device acknowledge. Just read in the datasheet what kind of interrupts it can send. Usually it is a flag register. Read and printf it in the int service and check if one of the signalled interrupts is unhandled. Some interrupt sources might need manual shutdown, while others do not - e.g. data ready is often automatically done when reading the data register and other need to be cleared by writing into a register. > Let me know if there is any more data you want from the PMIC. > > -W > _______________________________________________ > 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" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat May 3 00:18:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCBB36E5 for ; Sat, 3 May 2014 00:18:25 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 44F311B73 for ; Sat, 3 May 2014 00:18:24 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s430IL9b027800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 3 May 2014 02:18:22 +0200 (CEST) (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 s430I8Pt089372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2014 02:18:08 +0200 (CEST) (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 s430I89s061224; Sat, 3 May 2014 02:18:08 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s430I8OU061223; Sat, 3 May 2014 02:18:08 +0200 (CEST) (envelope-from ticso) Date: Sat, 3 May 2014 02:18:08 +0200 From: Bernd Walter To: Tom Everett Subject: Re: is the swap needed ? Message-ID: <20140503001808.GL52252@cicely7.cicely.de> References: <5363B383.6080206@0x544745.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5363B383.6080206@0x544745.com> 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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 00:18:25 -0000 On Fri, May 02, 2014 at 09:02:27AM -0600, Tom Everett wrote: > Here's a cut-paste from my notes. Basically, "add a swap partition and > then enable it" > > gpart add -s 128M -t freebsd ada0 > swapon /dev/ada0s2 > > It might not be ada0 in your case. Using swap on flash cards or USB flash sticks can be painfull slow. It can help in some cases, but if your system regulary uses a workset bigger than your RAM you are in trouble and you better reduce your requirements or use a board with more RAM. > >Paul Darius > >May 2, 2014 at 8:44 AM > >hi there, > > > >after dd the image info the sdcard, i can not found swap partition > >is the swap needed ? if so, how to create it ? > > > >tia > > > >P > >_______________________________________________ > >freebsd-arm@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat May 3 01:57:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18A19247 for ; Sat, 3 May 2014 01:57:23 +0000 (UTC) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DE98130C for ; Sat, 3 May 2014 01:57:22 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id c13so3585001eek.38 for ; Fri, 02 May 2014 18:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=B4ezrRGSPoS4Upzw1eO0QacoaBN7rRcX5xgHnLX1R9s=; b=LQoA1RH6nveBSOUOjmb3wb9gS66jZyb/WR9bKKV2ZvmiSV4k5+aVVy/pJpBL6t9HuY kLh7wZ9inOGTq2mpCAjEgzqb9BMc7cC9TWiWNODT0ZnyaPmMuu0Z+GdyPGKa1vsIZT4i Xjxq9gWPfcb8UPG1r/GLC5kmJ/r+K2WWn/ojyWjhGwpJIXCyJgwDMbiNexzqNC7tpf2x Eh5cA+FipkLzbwgNJjIqLP3pIQ1+K6zuFU8rZfG9BSO84cL0d70nrYx46XxX/DfPjGik NDiknkJOm9FgIiDUb2TLC4npM/E9mrHtZ67C3ApAcQw0/6Epz/kTwhPitkzTriRv3Spc kVoA== X-Received: by 10.15.42.138 with SMTP id u10mr18123590eev.7.1399082240159; Fri, 02 May 2014 18:57:20 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id w1sm8933183eel.16.2014.05.02.18.57.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 18:57:19 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53644CF7.8050800@hot.ee> Date: Sat, 03 May 2014 04:57:11 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Winston Smith Subject: Re: BBB/I2C: Read PMIC data References: <53633440.3070702@hot.ee> In-Reply-To: X-TagToolbar-Keys: D20140503045710101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 01:57:23 -0000 On 2014-05-02 23:46, Winston Smith wrote: > On Fri, May 2, 2014 at 11:30 AM, Warner Losh wrote: >> Only if the kernel is actively accessing them so your transactions are messed up. >> In the kernel, all the bridge knows about is transactions of one flavor or another. >> This may indicate a more fundamental issue going on, either in your belief that >> it is at 24, or in the address (which is 7 bits) gets translated to 8 bits. Try a left >> shift 1 bit. > > Alright, figured it out. The "dummy" write that precedes the read is > not a dummy, you're sending a command to the I2C device. For a > EEPROM, you send it a 2 byte address of where to read. For the PMIC, > you need to send it a *1-byte* register ID! > > I've updated the tool and renamed it `bbb_sysutil.c`: > > http://pastebin.com/NhMy9D7d > > Here's the output (still working on the "interrupt storm" issue!): > > root@beaglebone:~ # ./bbb_sysutil > TPS65217 PMIC @ address 24: > ChipID: E2 TPS65217C rev 1.2 > Status: 08 ACPWR > interrupt storm detected on "intr70:"; throttling interrupt source > EEPROM @ address 50: signature=AA:55:33:EE > Model: A335BNLT0A6A > Serial: 0214BBBK4321 > > > Let me know if there is any more data you want from the PMIC. > > -W > Oh, awesome! Now I think I know why I didn't get correct results... I would also like to share something, it's a script I use to upgrade my BBB: http://ketas.si.pri.ee/bbb-hotinstaller.sh BTW, you could consider adding such small files as attachments, so they will not disappear somewhere. From owner-freebsd-arm@FreeBSD.ORG Sat May 3 02:22:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A0F74EE for ; Sat, 3 May 2014 02:22:39 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7A4A1511 for ; Sat, 3 May 2014 02:22:38 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id cc10so3197650wib.14 for ; Fri, 02 May 2014 19:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2pxJUMQeFe29MQt7RwK+ydcb+50apQhwomhDquackr4=; b=iHtEiI80hj5q/7APdv6WPPHmfbu2tXr+FoVjZMUW/QhmIm3nPeG2rD5pov1vzUblcH sl282IDYK+Y+COirPCJsbNbxuQDnzEouT6C+88JliTz6mTFwnUFN+lH9Bz95o24e0UuF uflg/h9Ci9QkRBGcXWulH+fJora0OLHkDKQsRq1sFWUY9uf+bgCtArIk27YWWERjbWUt 5G8GqxHxitouoQlo1WvJmO1XlCOP+SCsK1S4I/fCw7P4mF11dDSasVHI/N67yadPqixW GQk9VGnN/vANBJ4CBjoSYW7V/7TzkgsrgCVDYDxpkpLLp2l7ETTs4aABFGFD5XO71KJg IEMA== MIME-Version: 1.0 X-Received: by 10.194.222.227 with SMTP id qp3mr16357984wjc.37.1399083756580; Fri, 02 May 2014 19:22:36 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 2 May 2014 19:22:36 -0700 (PDT) In-Reply-To: <20140503000946.GK52252@cicely7.cicely.de> References: <53633440.3070702@hot.ee> <20140503000946.GK52252@cicely7.cicely.de> Date: Fri, 2 May 2014 22:22:36 -0400 Message-ID: Subject: Re: BBB/I2C: Read PMIC data From: Winston Smith To: ticso@cicely.de Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 02:22:39 -0000 On Fri, May 2, 2014 at 8:09 PM, Bernd Walter wrote: > So you get valid data. > Sounds like the interupt handler is working for what it needs, but not > closing an interrupt down. > Since most part of acknowleging an interrupt to the hardware is the > same for all interrupt sources I expect the IIC controller isn't > made aware that an interrupt was processed. > One wild guess - without knowing the Sitara IIC controller at all: > You write and read in one transaction, the controller may issue > an interrupt on read and write, but only the read is handled, so > the write interrupt stays active. > It could also bee that the controler signals other states, which are > unhandled - e.g. addressed device acknowledge. > Just read in the datasheet what kind of interrupts it can send. > Usually it is a flag register. > Read and printf it in the int service and check if one of the signalled > interrupts is unhandled. > Some interrupt sources might need manual shutdown, while others do > not - e.g. data ready is often automatically done when reading the > data register and other need to be cleared by writing into a register. In my testing, the "interrupt storm" warning only occurs if the transfer size exceeds the FIFO size (which is set at 4). I'm still working through the code and the datasheet, but I think it might be related to how the drain feature works. From owner-freebsd-arm@FreeBSD.ORG Sat May 3 04:59:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8A54838 for ; Sat, 3 May 2014 04:59:53 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B16A7134A for ; Sat, 3 May 2014 04:59:53 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id hn18so2732538igb.12 for ; Fri, 02 May 2014 21:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ranahminang.net; s=padang; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yb/0ZhsdMRKZU9B1zBv0iPV/FOpqQSB8PZd3b+BcIl0=; b=fK8Te8yY9w0SqP6ImhODw/P13BaYNdenXSKlVNasobgPrk90cAP6JFmnKJ0Eimqit7 t0znOeGyr6PQ/zmfh/y9rbi5wrRg76hOC9DZP9XEtNes9fg47b90q7T0YuI9RUpUcMjS /jg3Xe8hOg7euQbgn47gs/QFyU8+Npgji3q0g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yb/0ZhsdMRKZU9B1zBv0iPV/FOpqQSB8PZd3b+BcIl0=; b=fUn/y4y3wVGWMfyiQMeQAZhbUosjaeJfi4oInMRx7Z1ljOdtfXXJIAbsmm0R/Iw6bI 5vVg/wivwgZ8OFWiQpg2dFnNA6P96IkjjAxeHAlXWB6v505zJ07c7/ahRWQgYS9fI0Oq c6ilVTOM6aFBsQq51PUysEiLwu1s/aCzqWvHqBI5rgEhU5pr1zlPpY6BRqaAoeUYpGgd rttqvjGXAno9C+nQgktdab9vcwfCxXPiBBe11+HQP64PeqfXmypc7t7Gk9c6FdEKeMpT hzWK9nH8GT8AhBuY2/65JLqFrJYsPP12ZtK0gHxg+5HUn16MLK3549VD15A9+arqesVS kvOg== X-Gm-Message-State: ALoCoQlBT6DlEd6WZo18zbZ1rdMUIn83SWNno/Bk7gI14MLFayebSyjQMXlykf4cP1Zgl+Q0u4p2 MIME-Version: 1.0 X-Received: by 10.50.109.163 with SMTP id ht3mr9535150igb.4.1399093192498; Fri, 02 May 2014 21:59:52 -0700 (PDT) Received: by 10.64.6.168 with HTTP; Fri, 2 May 2014 21:59:52 -0700 (PDT) X-Originating-IP: [36.76.56.50] In-Reply-To: <1399044637.22079.177.camel@revolution.hippie.lan> References: <5363B2B8.7010104@ceetonetechnology.com> <1399044637.22079.177.camel@revolution.hippie.lan> Date: Sat, 3 May 2014 11:59:52 +0700 Message-ID: Subject: Re: install or download port collection? From: Paul Darius To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: George Rosamond , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 04:59:54 -0000 I just download the ports.tar.gz from ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz can it be used ? no arch dependency on the source ? TIA P On 5/2/14, Ian Lepore wrote: > On Fri, 2014-05-02 at 10:59 -0400, George Rosamond wrote: >> Paul Darius: >> > hi there, >> > >> > i just new to fbsd and rpi. >> > >> > the fbsd image downloaded from >> > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.0/FreeBSD-10.0-STABLE-arm-armv6-RPI-B-20140427-r265018.img.bz2 >> > and the image successfully dd into sdcard 32GB. >> > >> > surprise that I can not find sysinstall, but at the end I find >> > bsdinstall >> > question is, how to install or download the port collections ? >> > i try using ftp and http direct but no luck >> >> >> Paul: >> >> The likely best route to install the ports tree is to use portsnap(8). >> >> From there, you can use whatever tools you prefer... subversion, svnup, >> etc to update the source, portmaster or whatever to update the ports. >> >> George >> > > Portsnap is a painful many-hour process on an RPi. I remember trying it > last year and it ran for hours and always crashed or panicked before > completion. Hopefully we've got the crash/panic stuff worked out these > days, but the time is still going to be bad. > > I prefer to keep a master ports tree on an nfs server and just mount it > on arm boards as needed, and build ports with WRKDIRPREFIX=/tmp. If > you're not set up for NFS (and don't want to be) another viable option > might be to do the portsnap process on a faster machine with the results > placed onto a usb drive that you can attach to the rpi. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Sat May 3 06:07:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1008E30 for ; Sat, 3 May 2014 06:07:31 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE8261810 for ; Sat, 3 May 2014 06:07:31 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id rd18so6111940iec.35 for ; Fri, 02 May 2014 23:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ranahminang.net; s=padang; h=mime-version:date:message-id:subject:from:to:content-type; bh=PMyf7JOmVsf9/7u3z2j2s062dnvqFGGR0pNtNKATkjY=; b=MMiBecDk0VYnU7HDGdx0KTkJjdNmTFR4n6NheNEzD4LSZc00z/+chyg4E/Dh5tseiY tccN6KCRl/c7td7AtzV044AEj8S0IeD0perenHtTVN4XCGGW7DcLBCVPhkkVQTWsebeD nb1/1f+oVkVy6sKtCJKZkcT0rQkzIpzf+jgeY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=PMyf7JOmVsf9/7u3z2j2s062dnvqFGGR0pNtNKATkjY=; b=LVT/Qv3rvWADw5sBMDJHo1SPZyRx5xNhIDT57KFCeIgrwNlNeTbCXxFqviGyTP/Mi3 x2InYkdDoWQ+U+f7PUqk3laBaP87Mihnnta0Kb3wcPs7QycQj0H0Fctyhx/eVuSzujoS XxYse6WYUc6OzdPRCYytmVi3tJ9hRxlDBWGVuiV75uLYEqDjt2NrLG18u81K8EIcRzRB 2fQS6yRwcK7KK4bsIikx0/xzGPvVa8iz7Yt6a46EK5ppGJravyIYBNwqzohoX6Zu3Dc1 rGL256eW0WYJeS7fG8g+aWu+RRyFzQWM9/GJLEN87ECnrMPb7bMbJaj2Prsadpewkyi5 KqoA== X-Gm-Message-State: ALoCoQn/9Pv8GozhQZqC10b8skL2vCX7DU8GvLe+8bL+sVD5zhPWrS0H/IvwTv45ZugTZ8b5owsU MIME-Version: 1.0 X-Received: by 10.50.30.6 with SMTP id o6mr9453513igh.43.1399097250804; Fri, 02 May 2014 23:07:30 -0700 (PDT) Received: by 10.64.6.168 with HTTP; Fri, 2 May 2014 23:07:30 -0700 (PDT) X-Originating-IP: [36.76.56.50] Date: Sat, 3 May 2014 13:07:30 +0700 Message-ID: Subject: ask about manual root filesystem specification From: Paul Darius To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 06:07:32 -0000 hi there, during the first boot after dd into the sdcard, i asked about manual root filesystem specification. the couple lines before that questions are : Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... mountroot: wating for device /dev/mmcsd02a ... Mointing from ufs:/dev/mmcsd0s2a failed with error 19. what should I type at mountroot> ? tia P From owner-freebsd-arm@FreeBSD.ORG Sat May 3 06:14:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14546BA for ; Sat, 3 May 2014 06:14:20 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E555618AD for ; Sat, 3 May 2014 06:14:19 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s436EJhr062995; Sat, 3 May 2014 06:14:19 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id fqu299yjxfrscmzvqp5eum4k32; Sat, 03 May 2014 06:14:19 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: ask about manual root filesystem specification From: Tim Kientzle In-Reply-To: Date: Fri, 2 May 2014 23:14:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: <69B04197-56DF-4801-B241-0C07EE32470A@freebsd.org> References: To: Paul Darius X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 06:14:20 -0000 On May 2, 2014, at 11:07 PM, Paul Darius wrote: > hi there, > > during the first boot after dd into the sdcard, i asked about manual > root filesystem specification. What board are you trying to boot? > the couple lines before that questions are : > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > mountroot: wating for device /dev/mmcsd02a ... > Mointing from ufs:/dev/mmcsd0s2a failed with error 19. > > what should I type at mountroot> ? This generally means that the kernel is unable to access the SD card because of some random timing variation. On some boards, rebooting will usually fix it. Tim From owner-freebsd-arm@FreeBSD.ORG Sat May 3 06:14:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEF05F1 for ; Sat, 3 May 2014 06:14:51 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A44DD18AE for ; Sat, 3 May 2014 06:14:51 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id s7so5260381qap.9 for ; Fri, 02 May 2014 23:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=JXLFgGDCpbeLJfJmnBALn0tUedqP1AqcvaqlqtQaSa8=; b=nXBTEoLey6OU8d8uLBvjNhm5JpQxkKzHJr458Vf4Tb55INZWxRBQnmcWxFxEZJ1Wbz bF3bg+togdG8taAuYebDzmtOCLUaZHP3m3+Vy978sYHx9+QUuocSTwWO+H7faNQR7TE5 gOCM7chHK83l3P+u2dxflLSowfOSRYo1zgAWlecuO7q92wqkjHqisighFFXX4DrlQNgz sodbam3B1UOpQ3hilJyp09seTYdJtPPJXd2fi18My6tEeMG71lUrux6WhQvUe/ygCHXb Ci+4ABltJJvrwzmE7Tvw2m2a/2cFakUOrNJjd8H/zqEGN/gFNh//XwGxzkZ/U5rN1i2e sWnQ== MIME-Version: 1.0 X-Received: by 10.224.38.138 with SMTP id b10mr28053494qae.98.1399097690669; Fri, 02 May 2014 23:14:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Fri, 2 May 2014 23:14:50 -0700 (PDT) Date: Fri, 2 May 2014 23:14:50 -0700 X-Google-Sender-Auth: 3avfFDIY9fd8CVNJaJfSHEkS0oY Message-ID: Subject: required xdev line to build r-pi on crochet? From: Adrian Chadd To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 06:14:51 -0000 hi, With Warners recent changes, the hint from crochet about how to build the xdev environment for the raspberry pi no longer applies. So - how does one build said xdev toolchain now? Thanks! -a From owner-freebsd-arm@FreeBSD.ORG Sat May 3 07:13:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79381571 for ; Sat, 3 May 2014 07:13:20 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E4AC1C7D for ; Sat, 3 May 2014 07:13:20 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id c1so2795704igq.16 for ; Sat, 03 May 2014 00:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ranahminang.net; s=padang; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CVVnUsfrApD4txHql3HmLVcfh/dhPGVdWCqmq2xGxkM=; b=BpgJ74q926eO9m/2KAYg5tcEpesQ3JD9Fw+d9kDIJ2I/Bws6d080KajfzKnh3uumJk Qmp+HoChwfoAjA8MPQcJZdtEoMXrGvKdF9nhB7lz+ySuv35rFHEpfb4Gp4mYfGnSxo5J h/xEQMtclXcPOVDsyg1BF1iujKEdjkhPNOi8c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CVVnUsfrApD4txHql3HmLVcfh/dhPGVdWCqmq2xGxkM=; b=V0nL42mSvtGMWDKvdSr731PjvPA6sexwDwdClYPJ3g//Zuiveik6Ba+jKdiR2zTYcd E5swMjc5ExdbTrAI60MbKB9OqRnZ68YIR5XwBwQdAPDwCUcwk4QKYpgbIyv9+gFTHgtj MCFZFOyaaAOyi2WRr4FKJxnPlsQSMKPjm6YKV6e+7RPr11wZCwuv6TnFIoZRKoN6ZYKV pkt6K8WttJI7kW2ZQtkqHcRvIqZ51DbtFpRGe+0jhXfQIaZOUe6ttOGBwlldrVBEbXQT UqyVXhD2UTjw9JXM34shRm1wgpX14MBy3BZD0ZheWXCGSvzBSk02SWkpdZL0WvFh7Y5c h5+Q== X-Gm-Message-State: ALoCoQmqsKfk7WTqJ8C9va+YP3Cma9b2CHI2RiLARLrP90TQTI2zzdHG8QeQCR+I/s2gHpIOs0ZN MIME-Version: 1.0 X-Received: by 10.50.154.66 with SMTP id vm2mr10030462igb.4.1399101199634; Sat, 03 May 2014 00:13:19 -0700 (PDT) Received: by 10.64.6.168 with HTTP; Sat, 3 May 2014 00:13:18 -0700 (PDT) X-Originating-IP: [36.68.47.185] Received: by 10.64.6.168 with HTTP; Sat, 3 May 2014 00:13:18 -0700 (PDT) In-Reply-To: <69B04197-56DF-4801-B241-0C07EE32470A@freebsd.org> References: <69B04197-56DF-4801-B241-0C07EE32470A@freebsd.org> Date: Sat, 3 May 2014 14:13:18 +0700 Message-ID: Subject: Re: ask about manual root filesystem specification From: Paul Darius To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 07:13:20 -0000 i am using raspberry pi ver b with sd card type 10 couple hard reboot seem solve the problem. but on soft reboot the problem remain the same. P On May 3, 2014 1:14 PM, "Tim Kientzle" wrote: > > On May 2, 2014, at 11:07 PM, Paul Darius wrote: > > > hi there, > > > > during the first boot after dd into the sdcard, i asked about manual > > root filesystem specification. > > What board are you trying to boot? > > > the couple lines before that questions are : > > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > > mountroot: wating for device /dev/mmcsd02a ... > > Mointing from ufs:/dev/mmcsd0s2a failed with error 19. > > > > what should I type at mountroot> ? > > This generally means that the kernel is unable > to access the SD card because of some random > timing variation. > > On some boards, rebooting will usually fix it. > > Tim > > From owner-freebsd-arm@FreeBSD.ORG Sat May 3 08:10:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF267F3F for ; Sat, 3 May 2014 08:10:51 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD3EE11D6 for ; Sat, 3 May 2014 08:10:51 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id as1so6139967iec.17 for ; Sat, 03 May 2014 01:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ranahminang.net; s=padang; h=mime-version:date:message-id:subject:from:to:content-type; bh=dqV2NmU9FB9ZtW9Dotwqxv8nftme1pEtJ0qPVYbmX18=; b=Q00Eb1firwd1PRl9+Dv+B37v0w3LFVW9JvY7UWw2XLOZ0BeinaLvHK2kvuvBufzaW6 F6MYkW+Pyrrl5eJe4gLi9JftGbc5fBu/HA7ZLiidFQkVA+cEpT3hrlzJCU6+AIq+WwEe LuHhAnSFyGLcIMMwNN5D41E8D78ZKxdi2tu1w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=dqV2NmU9FB9ZtW9Dotwqxv8nftme1pEtJ0qPVYbmX18=; b=QGmXVt+cT3wcRyKIagcp7FKBiAvKCEsQoU4dUaU8qZd7fGqO6LnxPEwGahLnIxwzPA 3aSh6ROsFh0COUGOrqnKCS31zIcj81ZJAnwmAhyNVA8bhOi7bEJKES5nXNDEvif78rA+ LZP9zX6NkQ7UltZamLEEHrmwOc1nTLpIzwY7lggYxTq3CKjqUUAEECMQr8a+cPFDIQKb oYIXRlIyD/urGpWo/V89mnDJshxo3nK/60iogVLAy3vsfn7erMfM7ROYrjy2TuHzbuxu QCerBD1FcW5xLDvWHlkpSGcrZT+UMkZ0eE/iGJZMNszLJWsFmwTIwEUSPqFirel5rUVP cTCg== X-Gm-Message-State: ALoCoQnmcfIF+psexZmr3pUHE/KUdBMVTOkPIOmmTj2wC9fryWaeFP01Fm1FR9Et6mNowflq6kva MIME-Version: 1.0 X-Received: by 10.50.30.6 with SMTP id o6mr9910340igh.43.1399104650790; Sat, 03 May 2014 01:10:50 -0700 (PDT) Received: by 10.64.6.168 with HTTP; Sat, 3 May 2014 01:10:50 -0700 (PDT) X-Originating-IP: [36.68.47.185] Date: Sat, 3 May 2014 15:10:50 +0700 Message-ID: Subject: partition resize From: Paul Darius To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 08:10:52 -0000 hi there.. here is the partition created from the fbsd image $ gpart show => 63 61497281 mmcsd0 MBR (29G) 63 34776 1 !12 [active] (17M) 34839 61462485 2 freebsd (29G) 61497324 20 - free - (10K) => 0 1918278 mmcsd0s2 BSD (29G) 0 1918278 1 freebsd-ufs (937M) $ cat /etc/fstab /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 /dev/mmcsd0s2a / ufs rw,noatime 1 1 md /tmp mfs rw,noatime,-s30m 0 0 md /var/log mfs rw,noatime,-s15m 0 0 md /var/tmp mfs rw,noatime,-s5m 0 0 when I do extract the ports.tar.gz into /usr, I end up with file system full how do i know which partition for what and how to resize them ? the /etc/rc.d/autosize start give the result : # /etc/rc.d/autosize start Enlarging root partition mmcsd0s2 resized gpart: autofill: No space left on device growfs: requested size 937MB is not larger than the current filesystem size 937MB tia P From owner-freebsd-arm@FreeBSD.ORG Sat May 3 08:40:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB6B83F7; Sat, 3 May 2014 08:40:57 +0000 (UTC) Received: from kaija.ugh.net.au (kaija.ugh.net.au [IPv6:2a00:1a48:7803:107:65bc:4bde:ff08:1f7f]) by mx1.freebsd.org (Postfix) with ESMTP id 9FFDF14D6; Sat, 3 May 2014 08:40:57 +0000 (UTC) Received: from [10.0.1.10] (77-64-252-112.dynamic.primacom.net [77.64.252.112]) by kaija.ugh.net.au (Postfix) with ESMTPSA id 4051A8D02; Sat, 3 May 2014 08:40:55 +0000 (UTC) References: <5363B2B8.7010104@ceetonetechnology.com> <1399044637.22079.177.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2F1B41C7-EDB5-4C63-B783-9535E5443780@ugh.net.au> X-Mailer: iPhone Mail (11D201) From: Andrew Stevenson Subject: Re: install or download port collection? Date: Sat, 3 May 2014 10:40:54 +0200 To: Paul Darius Cc: George Rosamond , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 08:40:57 -0000 > On 03.05.2014, at 06:59, Paul Darius wrote: >=20 > I just download the ports.tar.gz from > ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz > can it be used ? no arch dependency on the source ? That should be ok. There are not architecture specific versions of the ports= tree.=20 Andrew= From owner-freebsd-arm@FreeBSD.ORG Sat May 3 08:49:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05A2CB48 for ; Sat, 3 May 2014 08:49:47 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1D01568 for ; Sat, 3 May 2014 08:49:46 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h18so2860676igc.8 for ; Sat, 03 May 2014 01:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ranahminang.net; s=padang; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5cjlqrdBnrsSjusJcOZlWuc9/Cg/ezCtV1RBE5VDkYE=; b=CZBBIwGAiadgWJLbJMmYPcQ86LaZASiNC3XKL67G72QqR5qi9vmRIIZ4drxQj0htv7 USTddI1Wnf0OAaNmxcE6ZFrPJ2QjjgMEPddYVhzLQ13TG+fY9x/HqGVYTX85LmiOhkG7 IlA0f20tHtej04aQXuazcBX2ANBDRwVbVw0kk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5cjlqrdBnrsSjusJcOZlWuc9/Cg/ezCtV1RBE5VDkYE=; b=K8Oduj16TcfAQfrfu0TjPh/5Km3VQGpr/XbdlfbaW+IepVgnS4vVRTcAd/jPwxi/jv 9wcU/HFtN6wRHEyx7C0FA9vJ1XGrf6S6C0elEHjUajhfnWpgztK/oAZY3GIQKRCJd1da fgDdfbmXCZtRYZUYx5/pz7MxpPAOs18DTUHeYO1sc79Y9pybfEI64ooec4Ut6dptPxk/ 71k8pzMg+7mC3Zk+4peF06jc9mx9FVhK/E9a2YwQBY/+JqQ1iC45aex5xCUABy2JdfS4 39ks9YU3bvxpMF6NuiPTrhSzfbq4+k7SyDUgh3QujngzapF4/zRfLl+fhPOojq3XJ6Z1 50AA== X-Gm-Message-State: ALoCoQnBdJMiL4an+f7dCD/waAVZjpGj+ghktO9g7iqz30qyaU2ibTpu4aTmzIO3rgKyUIylrS9g MIME-Version: 1.0 X-Received: by 10.50.154.66 with SMTP id vm2mr10406932igb.4.1399106985670; Sat, 03 May 2014 01:49:45 -0700 (PDT) Received: by 10.64.6.168 with HTTP; Sat, 3 May 2014 01:49:45 -0700 (PDT) X-Originating-IP: [36.68.47.185] In-Reply-To: <2F1B41C7-EDB5-4C63-B783-9535E5443780@ugh.net.au> References: <5363B2B8.7010104@ceetonetechnology.com> <1399044637.22079.177.camel@revolution.hippie.lan> <2F1B41C7-EDB5-4C63-B783-9535E5443780@ugh.net.au> Date: Sat, 3 May 2014 15:49:45 +0700 Message-ID: Subject: Re: install or download port collection? From: Paul Darius To: Andrew Stevenson Content-Type: text/plain; charset=ISO-8859-1 Cc: George Rosamond , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 08:49:47 -0000 ok. Tq Andrew On 5/3/14, Andrew Stevenson wrote: > > >> On 03.05.2014, at 06:59, Paul Darius wrote: >> >> I just download the ports.tar.gz from >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz >> can it be used ? no arch dependency on the source ? > > That should be ok. There are not architecture specific versions of the ports > tree. > > Andrew From owner-freebsd-arm@FreeBSD.ORG Sat May 3 12:15:28 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12B8D1C8 for ; Sat, 3 May 2014 12:15:28 +0000 (UTC) Received: from lamora.getmail.no (lamora.getmail.no [84.210.184.7]) by mx1.freebsd.org (Postfix) with ESMTP id 923BE16D6 for ; Sat, 3 May 2014 12:15:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 134686CB46 for ; Sat, 3 May 2014 14:15:13 +0200 (CEST) Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id q6QPFSxhKZxD for ; Sat, 3 May 2014 14:15:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id E883D6C84E for ; Sat, 3 May 2014 14:15:08 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.8.4 lamora.getmail.no E883D6C84E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1399119308; bh=+tLQ1srApWVBz6gvvNbqij7RBXQL5H8o2EClZ5PV2E8=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=ZBwunTuvtYLdMlrxhhnrtgSXrpf6JNNmlYcBdAgTyK0PC6CaHuIehJ3Z8QicXe23A aEbnSH52zV0zXdxNkUIUsUP78H7lultvxJgvpyLFQEXQ8JYPiWGNI5SiMsdUlDjeBv 4uobtBBhFWbWtqdTX5uUYkgb1/hctPvCg2kYb2hs= X-Virus-Scanned: amavisd-new at lamora.get.c.bitbit.net Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gU3DyzG8xDJf for ; Sat, 3 May 2014 14:15:08 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by lamora.getmail.no (Postfix) with ESMTPSA id C1D7261562 for ; Sat, 3 May 2014 14:15:08 +0200 (CEST) Date: Sat, 3 May 2014 14:15:00 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: crochet - why does it (try to) change files in /usr/src? Message-Id: <20140503141500.4221758509cd70232b5b93b9@getmail.no> In-Reply-To: <1398987908.22079.143.camel@revolution.hippie.lan> References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> <20140501230633.5044af70fba9e4d4ed00933e@getmail.no> <1398987908.22079.143.camel@revolution.hippie.lan> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd8.4) 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 12:15:28 -0000 On Thu, 01 May 2014 17:45:08 -0600 Ian Lepore wrote: > > It's not, if the obj dir is inside ./work then surely the script has set > MKOBJDIRPREFIX to reflect that, and that's where it would be doing the > delete. Agreed - it *should* do the delete there. > Is it possible you had run the script previously as root, and this time > you were not root? Possible, but not likely. To be sure, I renamed the work directory and tried one more time: $ mv work work_old $ sh crochet.sh -b RaspberryPi Starting at Sat May 3 12:24:09 CEST 2014 Board: RaspberryPi Source version is: r265148 Building FreeBSD version: 10.0 Image name is: /usr/home/tingo/work/crochet-freebsd/work/FreeBSD-armv6-10.0-RPI-B-r265148.img Building FreeBSD version: 10.0 Object files are at: /usr/home/tingo/work/crochet-freebsd/work/obj/arm.armv6/usr/src Found suitable FreeBSD source tree in: /usr/src Found FreeBSD xdev tools for armv6 Found U-Boot sources in: /usr/home/tingo/work/crochet-freebsd/u-boot-rpi Building FreeBSD armv6 world at Sat May 3 12:24:09 CEST 2014 (Logging to /usr/home/tingo/work/crochet-freebsd/work/_.buildworld.armv6.log) Building FreeBSD armv6-RPI-B kernel at Sat May 3 13:54:03 CEST 2014 (Logging to /usr/home/tingo/work/crochet-freebsd/work/_.buildkernel.armv6-RPI-B.log) Building FreeBSD armv6-RPI-B ubldr at Sat May 3 14:02:04 CEST 2014 (Logging to /usr/home/tingo/work/crochet-freebsd/work/ubldr-armv6-RPI-B/_.ubldr.armv6-RPI-B.build.log) eval: cannot create /usr/home/tingo/work/crochet-freebsd/u-boot-rpi/_.uboot.to.be.configured: Permission denied So something is still amiss here. I'll checkout the FreeBSD source and try again. -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Sat May 3 12:16:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7F0A280 for ; Sat, 3 May 2014 12:16:48 +0000 (UTC) Received: from forward1l.mail.yandex.net (forward1l.mail.yandex.net [84.201.143.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A51E316ED for ; Sat, 3 May 2014 12:16:48 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward1l.mail.yandex.net (Yandex) with ESMTP id C645B1520DBD; Sat, 3 May 2014 16:16:39 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 6CC61E40068; Sat, 3 May 2014 16:16:39 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id MP8mAxTrmS-GdBa83AU; Sat, 3 May 2014 16:16:39 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 6d150152-93d3-49cd-908d-5fbfdd4a32b9 Message-ID: <5364DE26.2090503@passap.ru> Date: Sat, 03 May 2014 16:16:38 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Darius , freebsd-arm Subject: Re: partition resize References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 12:16:49 -0000 03.05.2014 12:10, Paul Darius пишет: > > here is the partition created from the fbsd image Are you sure? Seems that you did some changes to it. > $ gpart show > => 63 61497281 mmcsd0 MBR (29G) > 63 34776 1 !12 [active] (17M) > 34839 61462485 2 freebsd (29G) > 61497324 20 - free - (10K) > > => 0 1918278 mmcsd0s2 BSD (29G) > 0 1918278 1 freebsd-ufs (937M) Seems that you already tryed to do a resize. If I'm not mistaken, you resized only partition 2 of mmcsd0 device (-i 2 mmcsd0). Also partition 1 of mmcsd0s2 device should be resized (-i 1 mmcsd0s2). Then you should use growfs to enlarge the filesystem as well. A note: the last time I did so bsdlabel of mmcsd0s2 (slice c:) was not auto enlarged, so I should do it by hand. > $ cat /etc/fstab > /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 > /dev/mmcsd0s2a / ufs rw,noatime 1 1 > md /tmp mfs rw,noatime,-s30m 0 0 > md /var/log mfs rw,noatime,-s15m 0 0 > md /var/tmp mfs rw,noatime,-s5m 0 0 > > when I do extract the ports.tar.gz into /usr, I end up with file system full > > how do i know which partition for what and how to resize them ? > > the /etc/rc.d/autosize start give the result : > # /etc/rc.d/autosize start > Enlarging root partition > mmcsd0s2 resized > gpart: autofill: No space left on device > growfs: requested size 937MB is not larger than the current filesystem > size 937MB I've never used autosize, so no comments here, sorry. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Sat May 3 12:26:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 435AC6C2 for ; Sat, 3 May 2014 12:26:33 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0885B17D1 for ; Sat, 3 May 2014 12:26:32 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id l13so493551iga.10 for ; Sat, 03 May 2014 05:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ranahminang.net; s=padang; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KliWQqIduL5v9jbN4DEWzvaJV+1g9lSizTTedBcgUXQ=; b=Karf0RHHYDT442WOptwGzhBvdN5onIhYEr9g5pM3J5K4YFboVocVczqcOst5UZJ036 Nj9urt/1ELQNz5b7RJBxq/t4t6u1UNg7paoWX221E81suy2vpuR2aj7OpQWnamhOtdsh r2SnMy/BqtAvubAdU+EzcaGl6hqYZ+MdZRZe0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KliWQqIduL5v9jbN4DEWzvaJV+1g9lSizTTedBcgUXQ=; b=X4+ES6pWqktzOfv1Dp8zeqFP+hMIAWuCXVNwBc7thB4+IYlLKnoPqrWpnkx0FISRsZ jqsead0bNhTQnZYeM+MUiaffs5WrxnZDTOvDfvx9nJjfgVk2Ex1zNH6BzeNIT4hRjWot dbYTMnzsSAp+l/B0TxKUtrLMiAIO3NZVjRHQ5MV8DSfL6cubSzDyIesu0zxmp/UWLygq jIQ8NlqF8iulgoFMa4Bybk2Zkgt0IYN7XeJpIhVz/wp9vCRxATn4d7+IhbcMb+i6ez4i HSh+nTdzXqnQvK/Mk6F80ErEbh/gRf10lJcxuYo3Jzdig5XlpB06bPNbtmG1FZkzSiqf O3HQ== X-Gm-Message-State: ALoCoQlIvIb19xHCAb/RZZMF5/nLXUx9VdBs2WljuUO+De0fsVNTCNFwd6Q/d2jgPq/6Q0vC4roK MIME-Version: 1.0 X-Received: by 10.43.155.84 with SMTP id lh20mr401387icc.81.1399119991548; Sat, 03 May 2014 05:26:31 -0700 (PDT) Received: by 10.64.6.168 with HTTP; Sat, 3 May 2014 05:26:31 -0700 (PDT) X-Originating-IP: [36.68.47.185] Received: by 10.64.6.168 with HTTP; Sat, 3 May 2014 05:26:31 -0700 (PDT) In-Reply-To: <5364DE26.2090503@passap.ru> References: <5364DE26.2090503@passap.ru> Date: Sat, 3 May 2014 19:26:31 +0700 Message-ID: Subject: Re: partition resize From: Paul Darius To: Boris Samorodov Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 12:26:33 -0000 the autosize is automatically called by system on every boot. the file at /etc/rc.d P On May 3, 2014 7:16 PM, "Boris Samorodov" wrote: > 03.05.2014 12:10, Paul Darius =D0=C9=DB=C5=D4: > > > > here is the partition created from the fbsd image > > Are you sure? Seems that you did some changes to it. > > > $ gpart show > > =3D> 63 61497281 mmcsd0 MBR (29G) > > 63 34776 1 !12 [active] (17M) > > 34839 61462485 2 freebsd (29G) > > 61497324 20 - free - (10K) > > > > =3D> 0 1918278 mmcsd0s2 BSD (29G) > > 0 1918278 1 freebsd-ufs (937M) > > Seems that you already tryed to do a resize. If I'm not mistaken, > you resized only partition 2 of mmcsd0 device (-i 2 mmcsd0). Also > partition 1 of mmcsd0s2 device should be resized (-i 1 mmcsd0s2). > Then you should use growfs to enlarge the filesystem as well. > > A note: the last time I did so bsdlabel of mmcsd0s2 (slice c:) > was not auto enlarged, so I should do it by hand. > > > $ cat /etc/fstab > > /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 > > /dev/mmcsd0s2a / ufs rw,noatime 1 1 > > md /tmp mfs rw,noatime,-s30m 0 0 > > md /var/log mfs rw,noatime,-s15m 0 0 > > md /var/tmp mfs rw,noatime,-s5m 0 0 > > > > when I do extract the ports.tar.gz into /usr, I end up with file system > full > > > > how do i know which partition for what and how to resize them ? > > > > the /etc/rc.d/autosize start give the result : > > # /etc/rc.d/autosize start > > Enlarging root partition > > mmcsd0s2 resized > > gpart: autofill: No space left on device > > growfs: requested size 937MB is not larger than the current filesystem > > size 937MB > > I've never used autosize, so no comments here, sorry. > > -- > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > From owner-freebsd-arm@FreeBSD.ORG Sat May 3 12:27:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2AD5700 for ; Sat, 3 May 2014 12:27:12 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68E0217E0 for ; Sat, 3 May 2014 12:27:12 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id uy17so1378120igb.9 for ; Sat, 03 May 2014 05:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ranahminang.net; s=padang; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b97l1KAB4/NeEs6eNhgUBKtD+tZSIUIHxG0/T7m2mS0=; b=Df8uzyNe3+atYINK+cUQ93W0H1F82KD8cmqbkNeoYDXf7MODb9rRWJ4jgwB4ZnuSAC YXWI0cQpcZ6SYWUA2R9hbM3rzT+4Q1xXqoskN3dVV4HNJQCSOGZFJAnGS+8bDd3TUlFc sgtq+Y0jnoa2dlN2norlhhmKnBqltc9COVEC0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b97l1KAB4/NeEs6eNhgUBKtD+tZSIUIHxG0/T7m2mS0=; b=Qpx1zVK1Keh4Ut1xNd0ydTioE2hfaR2Bgi3RcIXtZESSrsiSDKiTS/OQ+pG1Nllkl5 yA0SUWj3iz6UXMJ4soe+LW09trKv7foqwVo4gaS4rxa8y75k968RTGNqiKNUjpNiANgu 2p6iRlYmBnFlA5r8x51Mn/djEh6PrkhYC2pJPDmVoI7T4or5HUfrZYJxhwNeK1hHwb47 fUe+vnYY1pMZDbYN9+dHScifnv0Md1aVL61wdNFwBEqmSQ8kNWatWXu5xk9VB2ijlYG9 hh8cbreh+lHDc4gt8wSGbUkfJYKYLZ7MeMLRbgO2x1XcUpOTxSa0W5AI/awisHeQsqxz BtDQ== X-Gm-Message-State: ALoCoQmO9aQSU5mw0REtPGYICi6w0VCfVQCIK2HyfXNKaq6sYhL3TyROAVh2wiDZMNidt5ecXRVi MIME-Version: 1.0 X-Received: by 10.50.30.6 with SMTP id o6mr11080258igh.43.1399120031874; Sat, 03 May 2014 05:27:11 -0700 (PDT) Received: by 10.64.6.168 with HTTP; Sat, 3 May 2014 05:27:11 -0700 (PDT) X-Originating-IP: [36.68.47.185] Received: by 10.64.6.168 with HTTP; Sat, 3 May 2014 05:27:11 -0700 (PDT) In-Reply-To: <5364DE26.2090503@passap.ru> References: <5364DE26.2090503@passap.ru> Date: Sat, 3 May 2014 19:27:11 +0700 Message-ID: Subject: Re: partition resize From: Paul Darius To: Boris Samorodov Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 12:27:12 -0000 i got 2 pcs sdcard and both give the same result P On May 3, 2014 7:16 PM, "Boris Samorodov" wrote: > 03.05.2014 12:10, Paul Darius =D0=C9=DB=C5=D4: > > > > here is the partition created from the fbsd image > > Are you sure? Seems that you did some changes to it. > > > $ gpart show > > =3D> 63 61497281 mmcsd0 MBR (29G) > > 63 34776 1 !12 [active] (17M) > > 34839 61462485 2 freebsd (29G) > > 61497324 20 - free - (10K) > > > > =3D> 0 1918278 mmcsd0s2 BSD (29G) > > 0 1918278 1 freebsd-ufs (937M) > > Seems that you already tryed to do a resize. If I'm not mistaken, > you resized only partition 2 of mmcsd0 device (-i 2 mmcsd0). Also > partition 1 of mmcsd0s2 device should be resized (-i 1 mmcsd0s2). > Then you should use growfs to enlarge the filesystem as well. > > A note: the last time I did so bsdlabel of mmcsd0s2 (slice c:) > was not auto enlarged, so I should do it by hand. > > > $ cat /etc/fstab > > /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 > > /dev/mmcsd0s2a / ufs rw,noatime 1 1 > > md /tmp mfs rw,noatime,-s30m 0 0 > > md /var/log mfs rw,noatime,-s15m 0 0 > > md /var/tmp mfs rw,noatime,-s5m 0 0 > > > > when I do extract the ports.tar.gz into /usr, I end up with file system > full > > > > how do i know which partition for what and how to resize them ? > > > > the /etc/rc.d/autosize start give the result : > > # /etc/rc.d/autosize start > > Enlarging root partition > > mmcsd0s2 resized > > gpart: autofill: No space left on device > > growfs: requested size 937MB is not larger than the current filesystem > > size 937MB > > I've never used autosize, so no comments here, sorry. > > -- > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > From owner-freebsd-arm@FreeBSD.ORG Sat May 3 12:37:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 689818DF for ; Sat, 3 May 2014 12:37:41 +0000 (UTC) Received: from forward9l.mail.yandex.net (forward9l.mail.yandex.net [IPv6:2a02:6b8:0:1819::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2677318AB for ; Sat, 3 May 2014 12:37:41 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward9l.mail.yandex.net (Yandex) with ESMTP id 51D22E60F62; Sat, 3 May 2014 16:37:37 +0400 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id EBAFF7E0137; Sat, 3 May 2014 16:37:36 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id k34y8po3hF-baRGRA3b; Sat, 3 May 2014 16:37:36 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 04c4b9a5-1bbb-4366-acbf-db0736a5a606 Message-ID: <5364E310.40005@passap.ru> Date: Sat, 03 May 2014 16:37:36 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Darius Subject: Re: partition resize References: <5364DE26.2090503@passap.ru> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 12:37:41 -0000 03.05.2014 16:26, Paul Darius пишет: > On May 3, 2014 7:16 PM, "Boris Samorodov" wrote: > >> 03.05.2014 12:10, Paul Darius пишет: >>> >>> here is the partition created from the fbsd image >> >> Are you sure? Seems that you did some changes to it. >> >>> $ gpart show >>> => 63 61497281 mmcsd0 MBR (29G) >>> 63 34776 1 !12 [active] (17M) >>> 34839 61462485 2 freebsd (29G) >>> 61497324 20 - free - (10K) >>> >>> => 0 1918278 mmcsd0s2 BSD (29G) >>> 0 1918278 1 freebsd-ufs (937M) >> >> Seems that you already tryed to do a resize. If I'm not mistaken, >> you resized only partition 2 of mmcsd0 device (-i 2 mmcsd0). Also >> partition 1 of mmcsd0s2 device should be resized (-i 1 mmcsd0s2). >> Then you should use growfs to enlarge the filesystem as well. >> >> A note: the last time I did so bsdlabel of mmcsd0s2 (slice c:) >> was not auto enlarged, so I should do it by hand. >> >>> $ cat /etc/fstab >>> /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 >>> /dev/mmcsd0s2a / ufs rw,noatime 1 1 >>> md /tmp mfs rw,noatime,-s30m 0 0 >>> md /var/log mfs rw,noatime,-s15m 0 0 >>> md /var/tmp mfs rw,noatime,-s5m 0 0 >>> >>> when I do extract the ports.tar.gz into /usr, I end up with file system >> full >>> >>> how do i know which partition for what and how to resize them ? >>> >>> the /etc/rc.d/autosize start give the result : >>> # /etc/rc.d/autosize start >>> Enlarging root partition >>> mmcsd0s2 resized >>> gpart: autofill: No space left on device >>> growfs: requested size 937MB is not larger than the current filesystem >>> size 937MB >> >> I've never used autosize, so no comments here, sorry. > the autosize is automatically called by system on every boot. the file at > /etc/rc.d Then do a resize by hand. Additional info is at the FreeBSD Handbook, Section 18.3 "Resizing and Growing Disks": http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-growing.html -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Sat May 3 13:19:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EE9D2F8 for ; Sat, 3 May 2014 13:19:05 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BFC411BC5 for ; Sat, 3 May 2014 13:19:04 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s43DIqAR035498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 3 May 2014 15:18:52 +0200 (CEST) (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 s43DIm5e096619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2014 15:18:48 +0200 (CEST) (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 s43DImW7065202; Sat, 3 May 2014 15:18:48 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s43DIlVE065201; Sat, 3 May 2014 15:18:47 +0200 (CEST) (envelope-from ticso) Date: Sat, 3 May 2014 15:18:47 +0200 From: Bernd Walter To: Paul Darius Subject: Re: partition resize Message-ID: <20140503131847.GB64774@cicely7.cicely.de> References: <5364DE26.2090503@passap.ru> 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, FRT_SOMA2=0.001, 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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 13:19:05 -0000 On Sat, May 03, 2014 at 07:27:11PM +0700, Paul Darius wrote: > i got 2 pcs sdcard and both give the same result There is some kind of bug handling the fdisk/bsdlabel chaining. autosize needs at least two calls with reboot in between. > P > On May 3, 2014 7:16 PM, "Boris Samorodov" wrote: > > > 03.05.2014 12:10, Paul Darius ?????: > > > > > > here is the partition created from the fbsd image > > > > Are you sure? Seems that you did some changes to it. > > > > > $ gpart show > > > => 63 61497281 mmcsd0 MBR (29G) > > > 63 34776 1 !12 [active] (17M) > > > 34839 61462485 2 freebsd (29G) > > > 61497324 20 - free - (10K) > > > > > > => 0 1918278 mmcsd0s2 BSD (29G) > > > 0 1918278 1 freebsd-ufs (937M) > > > > Seems that you already tryed to do a resize. If I'm not mistaken, > > you resized only partition 2 of mmcsd0 device (-i 2 mmcsd0). Also > > partition 1 of mmcsd0s2 device should be resized (-i 1 mmcsd0s2). > > Then you should use growfs to enlarge the filesystem as well. > > > > A note: the last time I did so bsdlabel of mmcsd0s2 (slice c:) > > was not auto enlarged, so I should do it by hand. > > > > > $ cat /etc/fstab > > > /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 > > > /dev/mmcsd0s2a / ufs rw,noatime 1 1 > > > md /tmp mfs rw,noatime,-s30m 0 0 > > > md /var/log mfs rw,noatime,-s15m 0 0 > > > md /var/tmp mfs rw,noatime,-s5m 0 0 > > > > > > when I do extract the ports.tar.gz into /usr, I end up with file system > > full > > > > > > how do i know which partition for what and how to resize them ? > > > > > > the /etc/rc.d/autosize start give the result : > > > # /etc/rc.d/autosize start > > > Enlarging root partition > > > mmcsd0s2 resized > > > gpart: autofill: No space left on device > > > growfs: requested size 937MB is not larger than the current filesystem > > > size 937MB > > > > I've never used autosize, so no comments here, sorry. > > > > -- > > WBR, Boris Samorodov (bsam) > > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > > > _______________________________________________ > 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" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat May 3 13:24:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6BF6738; Sat, 3 May 2014 13:24:52 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 36BF81C83; Sat, 3 May 2014 13:24:51 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s43DOnBi035546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 3 May 2014 15:24:50 +0200 (CEST) (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 s43DOiMN096672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2014 15:24:44 +0200 (CEST) (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 s43DOiet065241; Sat, 3 May 2014 15:24:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s43DOiBf065240; Sat, 3 May 2014 15:24:44 +0200 (CEST) (envelope-from ticso) Date: Sat, 3 May 2014 15:24:44 +0200 From: Bernd Walter To: Paul Darius Subject: Re: ask about manual root filesystem specification Message-ID: <20140503132444.GC64774@cicely7.cicely.de> References: <69B04197-56DF-4801-B241-0C07EE32470A@freebsd.org> 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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 13:24:52 -0000 On Sat, May 03, 2014 at 02:13:18PM +0700, Paul Darius wrote: > i am using raspberry pi ver b with sd card type 10 > couple hard reboot seem solve the problem. > but on soft reboot the problem remain the same. There is some kind of probing problem with some cards. I have a bunch of same charge boards and cards - some are probed fine, some never and some sometimes. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat May 3 14:07:06 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE48DF1C for ; Sat, 3 May 2014 14:07:06 +0000 (UTC) Received: from forward2l.mail.yandex.net (forward2l.mail.yandex.net [84.201.143.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CABE10A5 for ; Sat, 3 May 2014 14:07:05 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward2l.mail.yandex.net (Yandex) with ESMTP id 5F1171AC1004 for ; Sat, 3 May 2014 18:07:02 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 19123E40062 for ; Sat, 3 May 2014 18:07:02 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id BjwTzkhSjK-71B8msEW; Sat, 3 May 2014 18:07:01 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 420677ed-2d1a-4404-9976-f409b0152249 Message-ID: <5364F805.2020709@passap.ru> Date: Sat, 03 May 2014 18:07:01 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: zpool create: zap->zap_rwlock X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 14:07:06 -0000 Hi All, Should zfs work at arm? I get a stale job: ----- % uname -a FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r265218M: Fri May 2 18:24:07 SAMT 2014 bsam@wandboard:/usr/obj/usr/src/sys/WANDBOARD-QUAD arm % kldstat Id Refs Address Size Name 1 12 0xc2000000 5d8f48 kernel 2 1 0xc75da000 c000 if_tap.ko 3 1 0xc7760000 175000 zfs.ko 4 1 0xc78d5000 b000 opensolaris.ko % sudo zpool create data01 /dev/mmcsd0 ^tload: 0.10 cmd: zpool 604 [zap->zap_rwlock] 208.39r 0.00u 0.07s 0% 3516k ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Sat May 3 14:17:59 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 048C1405 for ; Sat, 3 May 2014 14:17:59 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE7E0116F for ; Sat, 3 May 2014 14:17:57 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WgalD-0003wW-2E; Sat, 03 May 2014 14:17:51 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s43EHmOE021515; Sat, 3 May 2014 08:17:48 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX193LFBgaigQ4AlievYSl9MN Subject: Re: zpool create: zap->zap_rwlock From: Ian Lepore To: Boris Samorodov In-Reply-To: <5364F805.2020709@passap.ru> References: <5364F805.2020709@passap.ru> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 May 2014 08:17:47 -0600 Message-ID: <1399126667.22079.204.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 14:17:59 -0000 On Sat, 2014-05-03 at 18:07 +0400, Boris Samorodov wrote: > Hi All, > > Should zfs work at arm? I get a stale job: > > ----- > % uname -a > FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r265218M: Fri May > 2 18:24:07 SAMT 2014 > bsam@wandboard:/usr/obj/usr/src/sys/WANDBOARD-QUAD arm > > % kldstat > Id Refs Address Size Name > 1 12 0xc2000000 5d8f48 kernel > 2 1 0xc75da000 c000 if_tap.ko > 3 1 0xc7760000 175000 zfs.ko > 4 1 0xc78d5000 b000 opensolaris.ko > > % sudo zpool create data01 /dev/mmcsd0 > ^tload: 0.10 cmd: zpool 604 [zap->zap_rwlock] 208.39r 0.00u 0.07s 0% 3516k > ----- > As far as I know, you're the first person to ever try it. I just assumed it wouldn't work without some effort/changes and put it on the list of things needed for arm to become tier-1 a few months ago. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat May 3 14:27:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0BBC4BA for ; Sat, 3 May 2014 14:27:38 +0000 (UTC) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF3121211 for ; Sat, 3 May 2014 14:27:38 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id ld10so1771344pab.31 for ; Sat, 03 May 2014 07:27:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=9DVxTa2rUfBmOfR9ikDulJSZUAwBV0VInTDXkmUye3c=; b=MDFnQWHRQOgVl4Xwv4Sfzt2SUfqqoKo9vJR01Ww3Ew+B+pZRre1pnuRloWFOzgP/RS MrccqOewwAU3NJlEq3KvcJnkwDpIKFzZrWbFxJQajna24BOfLFWPWpHgYWlwvVK1B/PE UsDG5CLlyid9/LzEeMj/2NlOzalRm1at+EV1Gh84KQXkKbpbS+1fd2hTpPf2Tqclxj7Z iR57/liO8nBkSjAVl2dZZysZaXAGaBo8ZaI9hy26o4z8oXyxB9rv0PEPEAu/L2/LofAb JQNLTYPVzizbK7JGt2GqWjTMn+SxTaprtdVh+v0PyknFAqnHhyWPeNtFG9goPsMls5Yf NnFg== X-Gm-Message-State: ALoCoQkqA1VEWEVlr6Pigdm6AlsCL15e8Ahn4OLtsQ9MrJtKeCcjXzrJgXJMk2q+vImliGHacKbC X-Received: by 10.66.218.193 with SMTP id pi1mr48415851pac.20.1399127251537; Sat, 03 May 2014 07:27:31 -0700 (PDT) Received: from lgwl-achen.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id z3sm20184150pas.15.2014.05.03.07.27.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 May 2014 07:27:30 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_B0CD1E24-2755-4065-B532-FE57CFF7E06E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: required xdev line to build r-pi on crochet? From: Warner Losh In-Reply-To: Date: Sat, 3 May 2014 08:27:32 -0600 Message-Id: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 14:27:39 -0000 --Apple-Mail=_B0CD1E24-2755-4065-B532-FE57CFF7E06E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On May 3, 2014, at 12:14 AM, Adrian Chadd wrote: > With Warners recent changes, the hint from crochet about how to build > the xdev environment for the raspberry pi no longer applies. > > So - how does one build said xdev toolchain now? Add WITHOUT_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. Warner --Apple-Mail=_B0CD1E24-2755-4065-B532-FE57CFF7E06E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTZPzUAAoJEGwc0Sh9sBEApNEP/jKvkpqSeQSYZY7b446eLNHV biqpNezfPSJOHgFZ5MgQThLm8bTUj2WGmpGUuEWv8NBRhsddrIdUeh3WBUPdqlYv pGMs3zd3UpOAmgCs/yLpX5Phit1hUZy0dOp6nCLXC6+95QOQ7dQ04/McbAJe8zRS OcHavVbps7oYxMV465l+qlgNSllhrAcT44pzZxDuoxQcnPKBDjlitDa1xG5XSFfX 3gUf2tNLDN5P9rl1bdU3k7H/Nk6JmfZlHIqXGSaN+v48zwvnWKwEDgFtnQvYmXwd Jmo2kIxHA66blDF7m2Bk0BGtgTIMF5shpeJigAndUVA7JoOVhrKskftZc8JKDMTy kKkR7kbaq1fhkN2qpA4PYuhP6W52RfM5I2GF9cuhKCE2V0UcLiG1ffUW30v458Xp HT6mEOgYeWJI4vgH6mQBAkoMCDHzqMxPhCvROi+Rwevz3tLZtvF5Veykt13cGkoj fiRcgT+B3OVTOJCRydxR/JJIpwVcFW05fWmnWrcvp4QYkTY0rBlyzWAnhrGTlJnx 71N4xNM0Z19NcaPSo/IhZdCt41BMOIPkO4ya5yGYjeEhbKOerZLUDblK7qROeYhS GCkrWB+tjBrTFSh2GJWCwGKP8uMMX8DLuVjbMj+/9zSXB4RLIXXpi59JphV3l/ir M8s9EV038oCezszLkIBN =b6xY -----END PGP SIGNATURE----- --Apple-Mail=_B0CD1E24-2755-4065-B532-FE57CFF7E06E-- From owner-freebsd-arm@FreeBSD.ORG Sat May 3 14:33:33 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BF5465D; Sat, 3 May 2014 14:33:33 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE20D12CE; Sat, 3 May 2014 14:33:32 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward7l.mail.yandex.net (Yandex) with ESMTP id A7B56BC1038; Sat, 3 May 2014 18:33:29 +0400 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 4EC741B6001D; Sat, 3 May 2014 18:33:29 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id vVr0AGwmFf-XTFO0g2N; Sat, 3 May 2014 18:33:29 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: dc41a73d-082d-4d57-8eca-28866ad62c9e Message-ID: <5364FE38.5050204@passap.ru> Date: Sat, 03 May 2014 18:33:28 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: zpool create: zap->zap_rwlock References: <5364F805.2020709@passap.ru> <1399126667.22079.204.camel@revolution.hippie.lan> In-Reply-To: <1399126667.22079.204.camel@revolution.hippie.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 14:33:33 -0000 03.05.2014 18:17, Ian Lepore пишет: > On Sat, 2014-05-03 at 18:07 +0400, Boris Samorodov wrote: >> Hi All, >> >> Should zfs work at arm? I get a stale job: >> >> ----- >> % uname -a >> FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r265218M: Fri May >> 2 18:24:07 SAMT 2014 >> bsam@wandboard:/usr/obj/usr/src/sys/WANDBOARD-QUAD arm >> >> % kldstat >> Id Refs Address Size Name >> 1 12 0xc2000000 5d8f48 kernel >> 2 1 0xc75da000 c000 if_tap.ko >> 3 1 0xc7760000 175000 zfs.ko >> 4 1 0xc78d5000 b000 opensolaris.ko >> >> % sudo zpool create data01 /dev/mmcsd0 >> ^tload: 0.10 cmd: zpool 604 [zap->zap_rwlock] 208.39r 0.00u 0.07s 0% 3516k >> ----- > > As far as I know, you're the first person to ever try it. I just > assumed it wouldn't work without some effort/changes and put it on the > list of things needed for arm to become tier-1 a few months ago. Thanks, I'll try to ask at current@ then. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Sat May 3 15:36:57 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF2C2B68 for ; Sat, 3 May 2014 15:36:57 +0000 (UTC) Received: from bouvier.getmail.no (bouvier.getmail.no [84.210.184.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED991792 for ; Sat, 3 May 2014 15:36:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id 67BE340354 for ; Sat, 3 May 2014 17:31:23 +0200 (CEST) Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id L6KV4qkruBFV for ; Sat, 3 May 2014 17:31:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id 439BC407D7 for ; Sat, 3 May 2014 17:31:19 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.8.4 bouvier.getmail.no 439BC407D7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1399131079; bh=AfrAHMZIduDLUwtKHO99zx6OWyf+ePnvXmZrKjGanGI=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=j8Vfbq4ll7sd5cnl9smSwgOzwd7xQOs4qyWAntwgAsvQ+Oux5X9mTc2TdAjh0RDc6 gqH0rEnQkBcfdbOz8qujqMpy8dKaYBLiI30ObsQU7IxP2CKemKePNy8bAnNOfvN9Of A1GRyDkDNX5At5fI/C1H52emBg2Yqm57wyOpeZc4= X-Virus-Scanned: amavisd-new at bouvier.get.c.bitbit.net Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0UCWZcNq57mF for ; Sat, 3 May 2014 17:31:19 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by bouvier.getmail.no (Postfix) with ESMTPSA id 1AC6E40467 for ; Sat, 3 May 2014 17:31:19 +0200 (CEST) Date: Sat, 3 May 2014 17:31:16 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: crochet - why does it (try to) change files in /usr/src? Message-Id: <20140503173116.96f1ea5456aeb32edeaf6f03@getmail.no> In-Reply-To: <20140503141500.4221758509cd70232b5b93b9@getmail.no> References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> <20140501230633.5044af70fba9e4d4ed00933e@getmail.no> <1398987908.22079.143.camel@revolution.hippie.lan> <20140503141500.4221758509cd70232b5b93b9@getmail.no> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd8.4) 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 15:36:57 -0000 On Sat, 3 May 2014 14:15:00 +0200 Torfinn Ingolfsen wrote: > I'll checkout the FreeBSD source and try again. and I can't reproduce the initial problem, so it was probably user error. $ sh crochet.sh -b RaspberryPi Starting at Sat May 3 14:21:58 CEST 2014 Board: RaspberryPi Source version is: r265264 Building FreeBSD version: 10.0 Image name is: /usr/home/tingo/work/crochet-freebsd/work/FreeBSD-armv6-10.0-RPI-B-r265264.img Building FreeBSD version: 10.0 Object files are at: /usr/home/tingo/work/crochet-freebsd/work/obj/arm.armv6/usr/src Found suitable FreeBSD source tree in: /usr/src Found FreeBSD xdev tools for armv6 Found U-Boot sources in: /usr/home/tingo/work/crochet-freebsd/u-boot-rpi Building FreeBSD armv6 world at Sat May 3 14:21:58 CEST 2014 (Logging to /usr/home/tingo/work/crochet-freebsd/work/_.buildworld.armv6.log) Building FreeBSD armv6-RPI-B kernel at Sat May 3 15:51:55 CEST 2014 (Logging to /usr/home/tingo/work/crochet-freebsd/work/_.buildkernel.armv6-RPI-B.log) Building FreeBSD armv6-RPI-B ubldr at Sat May 3 15:59:57 CEST 2014 (Logging to /usr/home/tingo/work/crochet-freebsd/work/ubldr-armv6-RPI-B/_.ubldr.armv6-RPI-B.build.log) eval: cannot create /usr/home/tingo/work/crochet-freebsd/u-boot-rpi/_.uboot.to.be.configured: Permission denied HTH -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Sat May 3 16:18:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66EDABFA; Sat, 3 May 2014 16:18:49 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 32CAB1AAE; Sat, 3 May 2014 16:18:48 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 3903C5DEF9; Sat, 3 May 2014 16:12:48 +0000 (UTC) Date: Sat, 3 May 2014 17:12:40 +0100 From: Andrew Turner To: Warner Losh Subject: Re: required xdev line to build r-pi on crochet? Message-ID: <20140503171240.7ea4269e@bender.Home> In-Reply-To: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> References: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/hZWrV6d4MyuOodlau+d16Fq" Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 16:18:49 -0000 --MP_/hZWrV6d4MyuOodlau+d16Fq Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, 3 May 2014 08:27:32 -0600 Warner Losh wrote: > > On May 3, 2014, at 12:14 AM, Adrian Chadd wrote: > > > With Warners recent changes, the hint from crochet about how to > > build the xdev environment for the raspberry pi no longer applies. > > > > So - how does one build said xdev toolchain now? > > Add WITHOUT_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. I created the attached patch this morning. It stops using the xdev toolchain to build U-Boot. I've build an image for RPi with this, but haven't had time to test it yet. It feels like this is a better approach to build U-Boot than keep trying to catch up to changes to the FreeBSD toolchain. The patch needs work before it can be pushed upstream as it will break any platform that still uses xdev to build U-Boot. Andrew --MP_/hZWrV6d4MyuOodlau+d16Fq Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=0001-Build-U-Boot-with-the-arm-eabi-toolchain.patch >From 60cda222479b572cc0809708aa2aee178493ef10 Mon Sep 17 00:00:00 2001 From: Andrew Turner Date: Sat, 3 May 2014 17:03:35 +0100 Subject: [PATCH] Build U-Boot with the arm-eabi- toolchain --- board/RaspberryPi/files/uboot-rpi_patch10_makefile_lc.patch | 13 ------------- lib/uboot.sh | 6 +++--- 2 files changed, 3 insertions(+), 16 deletions(-) delete mode 100644 board/RaspberryPi/files/uboot-rpi_patch10_makefile_lc.patch diff --git a/board/RaspberryPi/files/uboot-rpi_patch10_makefile_lc.patch b/board/RaspberryPi/files/uboot-rpi_patch10_makefile_lc.patch deleted file mode 100644 index 38915e9..0000000 --- a/board/RaspberryPi/files/uboot-rpi_patch10_makefile_lc.patch +++ /dev/null @@ -1,13 +0,0 @@ -diff --git a/Makefile b/Makefile -index 0197239..5db1544 100644 ---- a/Makefile -+++ b/Makefile -@@ -339,7 +339,7 @@ endif - else - PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc - endif --PLATFORM_LIBS += $(PLATFORM_LIBGCC) -+PLATFORM_LIBS += $(PLATFORM_LIBGCC) -lc - export PLATFORM_LIBS - - # Special flags for CPP when processing the linker script. diff --git a/lib/uboot.sh b/lib/uboot.sh index f0b56a2..60e39a5 100644 --- a/lib/uboot.sh +++ b/lib/uboot.sh @@ -45,7 +45,7 @@ _uboot_download_instructions ( ) ( # uboot_test ( ) { # We use FreeBSD xdev tools to build U-Boot - freebsd_xdev_test + #freebsd_xdev_test _uboot_check_patch_version @@ -137,7 +137,7 @@ uboot_configure ( ) { cd "$1" echo "Configuring U-Boot at "`date` echo " (Logging to $1/_.uboot.configure.log)" - if gmake CROSS_COMPILE=${FREEBSD_XDEV_PREFIX} $2 > $1/_.uboot.configure.log 2>&1; then + if gmake CROSS_COMPILE=arm-eabi- $2 > $1/_.uboot.configure.log 2>&1; then # success else echo " Failed to configure U-Boot." @@ -160,7 +160,7 @@ uboot_build ( ) ( cd "$1" echo "Building U-Boot at "`date` echo " (Logging to $1/_.uboot.build.log)" - if gmake SED=gsed HOSTCC=cc CROSS_COMPILE=${FREEBSD_XDEV_PREFIX} > $1/_.uboot.build.log 2>&1; then + if gmake SED=gsed HOSTCC=cc CROSS_COMPILE=arm-eabi- > $1/_.uboot.build.log 2>&1; then # success else echo " Failed to build U-Boot." -- 1.9.0 --MP_/hZWrV6d4MyuOodlau+d16Fq-- From owner-freebsd-arm@FreeBSD.ORG Sat May 3 18:20:59 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 443AEDBA for ; Sat, 3 May 2014 18:20:59 +0000 (UTC) Received: from lamora.getmail.no (lamora.getmail.no [84.210.184.7]) by mx1.freebsd.org (Postfix) with ESMTP id EC89716AB for ; Sat, 3 May 2014 18:20:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 5C1AA6C0C6 for ; Sat, 3 May 2014 20:20:54 +0200 (CEST) Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1t8dFIfsejyc for ; Sat, 3 May 2014 20:20:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 127C76D231 for ; Sat, 3 May 2014 20:20:50 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.8.4 lamora.getmail.no 127C76D231 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1399141250; bh=I+DEq+LoH2n2dd0mJww5a7wNT19MyICQRNLFh+zMfJ4=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=P8t1BW1zsVpP1Xw/Y3IUiFCBJc703hvH7MgEkdDgSqB0luohvoh1w48RraZYc/l8c fwWjGK5Zq2PonOrd4+94JtxycznSmILtcEUBmxtXsSq4xMFU2TsumjY/ZYaTu50X+X CSGeB23aRbo5E+27dsseAUPfgolPyUmLvvu60t8Y= X-Virus-Scanned: amavisd-new at lamora.get.c.bitbit.net Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NTrhJkQ5dj2z for ; Sat, 3 May 2014 20:20:49 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by lamora.getmail.no (Postfix) with ESMTPSA id D4DF26D714 for ; Sat, 3 May 2014 20:20:49 +0200 (CEST) Date: Sat, 3 May 2014 20:20:47 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: FreeBSD on Dockstar: U-Boot / ubldr? Message-Id: <20140503202047.294ad097b30f4240099659e6@getmail.no> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd8.4) 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 18:20:59 -0000 I'm trying to set up a crochet config for the Seagate Dockstar. (For some reason it seems like nobody has done this for Dockstar / Dreamplug already) Anyway, my Dockstar currently uses the built-in U-Boot and loads the kernel directly off a FAT partition. I see that the "modern" way to do it seems to be to load U-Boot and ubldr from a boot partition, then let ubldr figure out how to load the kernel and boot. Show it be this way for Dockstar / Dreamplug too? If so, does the Dockstar need a "special" version of U-Boot, like the RaspberryPi? And how to set that up? -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Sat May 3 18:35:43 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E88B21C3 for ; Sat, 3 May 2014 18:35:43 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD1BA1791 for ; Sat, 3 May 2014 18:35:42 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wgemj-000MS8-Ph; Sat, 03 May 2014 18:35:41 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s43IZd9Y021755; Sat, 3 May 2014 12:35:39 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Pp/smqHlJlBo7PrC2Rmxa Subject: Re: FreeBSD on Dockstar: U-Boot / ubldr? From: Ian Lepore To: Torfinn Ingolfsen In-Reply-To: <20140503202047.294ad097b30f4240099659e6@getmail.no> References: <20140503202047.294ad097b30f4240099659e6@getmail.no> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 May 2014 12:35:39 -0600 Message-ID: <1399142139.22079.222.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 18:35:44 -0000 On Sat, 2014-05-03 at 20:20 +0200, Torfinn Ingolfsen wrote: > I'm trying to set up a crochet config for the Seagate Dockstar. > (For some reason it seems like nobody has done this for Dockstar / Dreamplug already) > Anyway, my Dockstar currently uses the built-in U-Boot and loads the kernel directly off a FAT partition. > I see that the "modern" way to do it seems to be to load U-Boot and ubldr from a boot partition, then let ubldr figure out how to load the kernel and boot. > Show it be this way for Dockstar / Dreamplug too? > > If so, does the Dockstar need a "special" version of U-Boot, like the RaspberryPi? > And how to set that up? Using ubldr requires a u-boot that has the 'API' feature enabled. Virtually no u-boot comes that way from a vendor. I don't think the feature even existed when the kirkwood systems were current. To enable that, all you need to do is add the CONFIG_API option when building u-boot. I'm not sure that's the exact spelling, but look at the patches that get applied to rpi or beaglebone, it'll be like that. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat May 3 18:42:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33D4E22F for ; Sat, 3 May 2014 18:42:52 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0B651833 for ; Sat, 3 May 2014 18:42:51 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id fp1so851542pdb.6 for ; Sat, 03 May 2014 11:42:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=wrWFlDsTrABhmwdRurCrp/4QwGnSZf30skWynqyaaW0=; b=EZOWz7zz/l1qEv9VcTWYHAA7rk1Jdg6RiKODOs+v52bOTGzvCv3Xn20g1UiSe8kVve s4BzrBUwH6c7gvbNR6rtWkeKvpiVmTy5qNDcl+RGC0IqiUazw4MZsBZWLlMVbo7f/Yl1 jcjqbuXCT86xvQHutfeZuMNEHVJrp8gnff5CrkPs0akMRT1nt5jbaMijjjvu0taOuL7J BuyLdGECE3EsbGmjeC9cjSyBfR5za7BcXcK0A0WeM7tzB3j3CnaXXBEUCsXKgjkIFPxd Vq79TwErkkESXIjzJoEW4hgxf9LW8zzkSmeTnoZFuyXdd52NYu1Njo/ouySwo54gRlv6 AnKw== X-Gm-Message-State: ALoCoQmHcQjb6q8GoOGPtc5ilb274HyrYzShK/Zdnhuz6fGSTcrblyDyKTlRe9ofvjj3CIAp8tHx X-Received: by 10.66.148.197 with SMTP id tu5mr50838157pab.108.1399142564208; Sat, 03 May 2014 11:42:44 -0700 (PDT) Received: from [192.168.77.199] (S0106000db92912b0.cg.shawcable.net. [68.146.94.47]) by mx.google.com with ESMTPSA id tu3sm24990803pab.1.2014.05.03.11.42.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 May 2014 11:42:43 -0700 (PDT) Message-ID: <536538A1.70808@0x544745.com> Date: Sat, 03 May 2014 12:42:41 -0600 From: Tom Everett User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Ian Lepore Subject: Re: FreeBSD on Dockstar: U-Boot / ubldr? References: <20140503202047.294ad097b30f4240099659e6@getmail.no> <1399142139.22079.222.camel@revolution.hippie.lan> In-Reply-To: <1399142139.22079.222.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 18:42:52 -0000 For wandboard, I used this patch: https://github.com/kientzle/crochet-freebsd/blob/master/board/Wandboard/files/uboot-2013.10_include_configs_wandboard.h.patch I also chose to use a u-boot scr file rather than apply a pile of patches to u-boot to set the boot config. My hope was that when it came time to move to the next u-boot version I would not have to update as many patch files. The source of the scr file is here: https://github.com/kientzle/crochet-freebsd/blob/master/board/Wandboard/files/boot.txt The code in setup.sh to build the scr file is: # # build the u-boot scr file # strategy_add $PHASE_BOOT_INSTALL uboot_mkimage "files/boot.txt" "boot.scr" > Ian Lepore > May 3, 2014 at 12:35 PM > > Using ubldr requires a u-boot that has the 'API' feature enabled. > Virtually no u-boot comes that way from a vendor. I don't think the > feature even existed when the kirkwood systems were current. > > To enable that, all you need to do is add the CONFIG_API option when > building u-boot. I'm not sure that's the exact spelling, but look at > the patches that get applied to rpi or beaglebone, it'll be like that. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > Torfinn Ingolfsen > May 3, 2014 at 12:20 PM > I'm trying to set up a crochet config for the Seagate Dockstar. > (For some reason it seems like nobody has done this for Dockstar / > Dreamplug already) > Anyway, my Dockstar currently uses the built-in U-Boot and loads the > kernel directly off a FAT partition. > I see that the "modern" way to do it seems to be to load U-Boot and > ubldr from a boot partition, then let ubldr figure out how to load the > kernel and boot. > Show it be this way for Dockstar / Dreamplug too? > > If so, does the Dockstar need a "special" version of U-Boot, like the > RaspberryPi? > And how to set that up? From owner-freebsd-arm@FreeBSD.ORG Sat May 3 18:45:56 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93B3526E for ; Sat, 3 May 2014 18:45:56 +0000 (UTC) Received: from bouvier.getmail.no (bouvier.getmail.no [84.210.184.8]) by mx1.freebsd.org (Postfix) with ESMTP id 44D441838 for ; Sat, 3 May 2014 18:45:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id DA8B6404AE for ; Sat, 3 May 2014 20:45:53 +0200 (CEST) Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id DEbCrGcAuJ2g for ; Sat, 3 May 2014 20:45:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id 838BE4048F for ; Sat, 3 May 2014 20:45:49 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.8.4 bouvier.getmail.no 838BE4048F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1399142749; bh=lJyJAGN3DCVVjc3N+y/0XPhR5REaQ9cHYrjCzdKxUjs=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=RLwIYfFBcZvO0aNgoAaoanVybfJaiQfvnJJ7w8umo4o7D9YuK83DO2R0Hbf8yk0m4 SyKw+rS3N6RCVGKOUs/edNYotjFUgjlp2MdyFxmi68bGkAxuoduiNXBNsPFexclG7R tq2G2iUo/NISV6B5yzdSIxcvklprYnoA5TK+mDrA= X-Virus-Scanned: amavisd-new at bouvier.get.c.bitbit.net Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gkwZKqkDOL02 for ; Sat, 3 May 2014 20:45:49 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by bouvier.getmail.no (Postfix) with ESMTPSA id 4C067403DA for ; Sat, 3 May 2014 20:45:49 +0200 (CEST) Date: Sat, 3 May 2014 20:45:48 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: FreeBSD on Dockstar: U-Boot / ubldr? Message-Id: <20140503204548.a5ebaaddbfb3036e7d74b58a@getmail.no> In-Reply-To: <1399142139.22079.222.camel@revolution.hippie.lan> References: <20140503202047.294ad097b30f4240099659e6@getmail.no> <1399142139.22079.222.camel@revolution.hippie.lan> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd8.4) 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 18:45:56 -0000 On Sat, 03 May 2014 12:35:39 -0600 Ian Lepore wrote: > > Using ubldr requires a u-boot that has the 'API' feature enabled. > Virtually no u-boot comes that way from a vendor. I don't think the > feature even existed when the kirkwood systems were current. Ok, changing my question: is there a "generic" U-boot that I can build for my Dockstar? And would it be ok to have U-boot om the Dockstar load the new U-Boot? -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Sat May 3 18:48:36 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 710592B5 for ; Sat, 3 May 2014 18:48:36 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 455951842 for ; Sat, 3 May 2014 18:48:35 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wgez7-0005eI-1K; Sat, 03 May 2014 18:48:29 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s43ImRdf021772; Sat, 3 May 2014 12:48:27 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19CZ2vuX9S5jDziTFhclBIa Subject: Re: FreeBSD on Dockstar: U-Boot / ubldr? From: Ian Lepore To: Tom Everett In-Reply-To: <536538A1.70808@0x544745.com> References: <20140503202047.294ad097b30f4240099659e6@getmail.no> <1399142139.22079.222.camel@revolution.hippie.lan> <536538A1.70808@0x544745.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 May 2014 12:48:26 -0600 Message-ID: <1399142906.22079.224.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 18:48:36 -0000 On Sat, 2014-05-03 at 12:42 -0600, Tom Everett wrote: > For wandboard, I used this patch: > > https://github.com/kientzle/crochet-freebsd/blob/master/board/Wandboard/files/uboot-2013.10_include_configs_wandboard.h.patch > > I also chose to use a u-boot scr file rather than apply a pile of > patches to u-boot to set the boot config. My hope was that when it came > time to move to the next u-boot version I would not have to update as > many patch files. > > The source of the scr file is here: > > https://github.com/kientzle/crochet-freebsd/blob/master/board/Wandboard/files/boot.txt > > The code in setup.sh to build the scr file is: > > # > # build the u-boot scr file > # > strategy_add $PHASE_BOOT_INSTALL uboot_mkimage "files/boot.txt" "boot.scr" It's crazy how much weird stuff they're cramming into u-boot default environments now. It's almost like they're having some sort of "I'm more clever than you with this primitive scripting language" contest. I tend to go minimal, this is my typical u-boot env: => printenv baudrate=115200 bootcmd=run ubmmc bootdelay=2 fdt_file=wandboard-quad.dtb loadaddr=0x11000000 loaderdev=net ubmmc=fatload mmc 0 ${loadaddr} ubldr; bootelf ubnet=dhcp ${loadaddr} /wand/boot/ubldr;bootelf Environment size: 279/8188 bytes -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat May 3 18:52:59 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF706468 for ; Sat, 3 May 2014 18:52:59 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8355F18D8 for ; Sat, 3 May 2014 18:52:58 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wgf3S-0004xu-0a; Sat, 03 May 2014 18:52:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s43Iqs60021781; Sat, 3 May 2014 12:52:54 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+5mC7EtA+FHRUYu6rF1aXc Subject: Re: FreeBSD on Dockstar: U-Boot / ubldr? From: Ian Lepore To: Torfinn Ingolfsen In-Reply-To: <20140503204548.a5ebaaddbfb3036e7d74b58a@getmail.no> References: <20140503202047.294ad097b30f4240099659e6@getmail.no> <1399142139.22079.222.camel@revolution.hippie.lan> <20140503204548.a5ebaaddbfb3036e7d74b58a@getmail.no> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 May 2014 12:52:54 -0600 Message-ID: <1399143174.22079.228.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 18:52:59 -0000 On Sat, 2014-05-03 at 20:45 +0200, Torfinn Ingolfsen wrote: > On Sat, 03 May 2014 12:35:39 -0600 > Ian Lepore wrote: > > > > > Using ubldr requires a u-boot that has the 'API' feature enabled. > > Virtually no u-boot comes that way from a vendor. I don't think the > > feature even existed when the kirkwood systems were current. > > Ok, changing my question: is there a "generic" U-boot that I can build for my Dockstar? > And would it be ok to have U-boot om the Dockstar load the new U-Boot? > Nope, no generic u-boot, it's got to be customized for the hardware. But the dockstar should have a canned config that you can choose in the port Makefile. Look at the port for sysutils/u-boot-beaglebone-eabi. Using the existing u-boot to chain-load another u-boot with API and other features can at least potentially work. Thomas Skibo has it working for a Parallela board. Because u-boot does strange and mysterious low-level init stuff to the hardware on some platforms, there's a chance that chain-loading it won't work, because tyring to re-init already running hardware could fail. I think it's a good idea in general, it could give us a way for people to "try freebsd" quickly and easily without having to reflash their boards/boxes with a new u-boot if there's flash memory involved. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat May 3 19:58:36 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA8D355B for ; Sat, 3 May 2014 19:58:36 +0000 (UTC) Received: from forward1l.mail.yandex.net (forward1l.mail.yandex.net [84.201.143.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BAF21E73 for ; Sat, 3 May 2014 19:58:35 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward1l.mail.yandex.net (Yandex) with ESMTP id C15961520E31 for ; Sat, 3 May 2014 23:58:32 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 79BC6E400CE for ; Sat, 3 May 2014 23:58:32 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id dNjSvIZcAn-wWB0x2ic; Sat, 3 May 2014 23:58:32 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: b01ef3f0-008d-4201-b8d7-71144ead5dc0 Message-ID: <53654A67.6030605@passap.ru> Date: Sat, 03 May 2014 23:58:31 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: wandboard-quad: ffec performance (about 190 Mbits/sec) X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 19:58:36 -0000 Hi All, My home PC has max perfomance approx. 800 Mbit/sec (measured between two re adapters and a cheap d-link switch in between them). I've just test ffec performance (one of re's is the other side): ----- % ifconfig ffec0 ffec0: flags=8843 metric 0 mtu 1500 options=80008 ether 00:1f:7b:b4:09:8e inet 192.168.100.211 netmask 0xffffff00 broadcast 192.168.100.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 % iperf -c 192.168.100.99 Client connecting to 192.168.100.99, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.100.211 port 11536 connected with 192.168.100.99 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 225 MBytes 188 Mbits/sec ----- Here is the vmstat at the time of iperf test: ----- % vmstat -w1 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr mm0 mm1 in sy cs us sy id 1 0 0 235M 1934M 219 0 1 0 149 5 0 0 687 685 911 0 2 98 0 0 0 235M 1934M 24 0 0 0 44 9 0 0 246 307 91 1 1 99 0 0 0 235M 1934M 32 0 0 0 44 9 0 0 208 280 94 0 1 99 0 0 0 235M 1934M 29 0 0 0 44 9 0 0 288 373 108 0 0 99 1 0 0 256M 1933M 311 0 0 0 87 9 0 0 8309 757 13373 1 26 73 0 0 0 256M 1933M 12 0 0 0 32 9 0 6 11955 465 20366 0 37 63 0 0 0 256M 1933M 22 0 0 0 44 9 0 0 11379 537 19295 0 34 65 1 0 0 256M 1933M 12 0 0 0 24 9 0 1 11171 461 19067 0 34 65 0 0 0 256M 1933M 12 0 0 0 24 9 0 0 11109 476 18945 1 34 65 1 0 0 256M 1933M 12 0 0 0 24 9 0 0 11354 468 19352 0 36 64 0 0 0 256M 1933M 13 0 0 0 24 9 0 0 11162 465 18866 1 34 65 0 0 0 256M 1933M 12 0 0 0 24 9 0 2 11297 471 19165 0 36 64 1 0 0 256M 1933M 12 0 0 0 24 9 0 0 11345 465 19296 1 35 64 0 0 0 256M 1933M 12 0 0 0 24 9 0 0 11044 461 18634 0 35 65 0 0 0 235M 1934M 65 0 0 0 263 9 0 1 3224 602 5060 2 9 89 0 0 0 235M 1934M 12 0 0 0 24 9 0 0 142 206 77 0 0 100 0 0 0 235M 1934M 34 0 0 0 64 9 0 0 260 347 104 0 1 99 0 0 0 235M 1934M 12 0 0 0 24 9 0 0 142 206 79 0 0 100 ----- Is this an expected result? Assuming that the system was about 65% idle, there is a space for improvement. The system: ----- % uname -a FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r265218M: Fri May 2 18:24:07 SAMT 2014 bsam@wandboard:/usr/obj/usr/src/sys/WANDBOARD-QUAD arm ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Sat May 3 20:25:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82B63DC3 for ; Sat, 3 May 2014 20:25:02 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 16534124B for ; Sat, 3 May 2014 20:25:01 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s43KOmn1038170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 3 May 2014 22:24:48 +0200 (CEST) (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 s43KOgM8099615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2014 22:24:42 +0200 (CEST) (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 s43KOgkZ066951; Sat, 3 May 2014 22:24:42 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s43KOgBm066950; Sat, 3 May 2014 22:24:42 +0200 (CEST) (envelope-from ticso) Date: Sat, 3 May 2014 22:24:42 +0200 From: Bernd Walter To: Boris Samorodov Subject: Re: wandboard-quad: ffec performance (about 190 Mbits/sec) Message-ID: <20140503202441.GD64774@cicely7.cicely.de> References: <53654A67.6030605@passap.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53654A67.6030605@passap.ru> 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.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 20:25:02 -0000 On Sat, May 03, 2014 at 11:58:31PM +0400, Boris Samorodov wrote: > Hi All, > > My home PC has max perfomance approx. 800 Mbit/sec (measured between > two re adapters and a cheap d-link switch in between them). > > I've just test ffec performance (one of re's is the other side): > ----- > > Is this an expected result? Assuming that the system was about 65% idle, > there is a space for improvement. Freecale says that the ethernet interface has a 400Mbit/s memory interface, so that's pretty much the physical limit and I think even in summary of both directions. The hardware also has some very fancy IP offloading stuff, of which I don't know how much we already utilize. As an interest off myself, when you already have such a setup running. Can you do a ping test to see what latency you get during bulk traffic and without? Currently I can't easily do such tests myself, since I have a full workbench with unrelated stuff. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat May 3 20:27:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25FCEFED for ; Sat, 3 May 2014 20:27:56 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBCFC1270 for ; Sat, 3 May 2014 20:27:55 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id j5so3140598qaq.15 for ; Sat, 03 May 2014 13:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1JLDEgQ/rAA4szJXxmdSCCPPwy64FtYJayEqq7DIxxo=; b=iqad9RcH8KnbbzrRrXftUjd62wdfUcpegd+lh3q4qLJ5eK9TjQ1yPaGCHBuSwGDu0v qlTWeIWsIdDnYZa2bpGFeQ8vKqs9hSNwvL5r48VRyY2eammJF+iqDEpnp6fObxNeszAy LVQZ8Rl9/A45Im6krqG2oxjeQZvwZd3BiJGN1LM1YOM1UZCrTvBksOWGMnub/O+LkLv8 Qz3/JTNaJhEO5mH0liNbLvYBDmR/Nr2pxWf6jyVH9ezeRgBt+6F/TcLo7LsoPLdYs2yI PQemsTzdKE9Sqkt6L83ED5fJUkXIJ1KNBtul6GJRBUAACEPALADjAna3oRL/ZLUA6mQu lb2Q== MIME-Version: 1.0 X-Received: by 10.229.17.69 with SMTP id r5mr32370559qca.7.1399148875077; Sat, 03 May 2014 13:27:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 3 May 2014 13:27:55 -0700 (PDT) In-Reply-To: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> References: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> Date: Sat, 3 May 2014 13:27:55 -0700 X-Google-Sender-Auth: 5dgbMAbiQbWARmn7s-uTXGGVE58 Message-ID: Subject: Re: required xdev line to build r-pi on crochet? From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 20:27:56 -0000 Do I only need those two, or do I add them to the existing list it tell sme to use? -a On 3 May 2014 07:27, Warner Losh wrote: > > On May 3, 2014, at 12:14 AM, Adrian Chadd wrote: > >> With Warners recent changes, the hint from crochet about how to build >> the xdev environment for the raspberry pi no longer applies. >> >> So - how does one build said xdev toolchain now? > > Add WITHOUT_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. > > Warner > From owner-freebsd-arm@FreeBSD.ORG Sat May 3 21:20:12 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACAF2A0F for ; Sat, 3 May 2014 21:20:12 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 706C916CB for ; Sat, 3 May 2014 21:20:11 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WghLu-000OrJ-6O; Sat, 03 May 2014 21:20:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s43LK7rp021863; Sat, 3 May 2014 15:20:07 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18qo+w2T20P9ztTyn2CAa4z Subject: Re: wandboard-quad: ffec performance (about 190 Mbits/sec) From: Ian Lepore To: Boris Samorodov In-Reply-To: <53654A67.6030605@passap.ru> References: <53654A67.6030605@passap.ru> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 May 2014 15:20:07 -0600 Message-ID: <1399152007.22079.232.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 21:20:12 -0000 On Sat, 2014-05-03 at 23:58 +0400, Boris Samorodov wrote: > Hi All, > > My home PC has max perfomance approx. 800 Mbit/sec (measured between > two re adapters and a cheap d-link switch in between them). > > I've just test ffec performance (one of re's is the other side): > ----- > % ifconfig ffec0 > ffec0: flags=8843 metric 0 mtu 1500 > options=80008 > ether 00:1f:7b:b4:09:8e > inet 192.168.100.211 netmask 0xffffff00 broadcast 192.168.100.255 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > > % iperf -c 192.168.100.99 > Client connecting to 192.168.100.99, TCP port 5001 > TCP window size: 32.5 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.100.211 port 11536 connected with 192.168.100.99 > port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 225 MBytes 188 Mbits/sec > ----- > > Here is the vmstat at the time of iperf test: > ----- > % vmstat -w1 > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr mm0 mm1 in sy cs > us sy id > 1 0 0 235M 1934M 219 0 1 0 149 5 0 0 687 685 911 > 0 2 98 > 0 0 0 235M 1934M 24 0 0 0 44 9 0 0 246 307 91 > 1 1 99 > 0 0 0 235M 1934M 32 0 0 0 44 9 0 0 208 280 94 > 0 1 99 > 0 0 0 235M 1934M 29 0 0 0 44 9 0 0 288 373 108 > 0 0 99 > 1 0 0 256M 1933M 311 0 0 0 87 9 0 0 8309 757 > 13373 1 26 73 > 0 0 0 256M 1933M 12 0 0 0 32 9 0 6 11955 465 > 20366 0 37 63 > 0 0 0 256M 1933M 22 0 0 0 44 9 0 0 11379 537 > 19295 0 34 65 > 1 0 0 256M 1933M 12 0 0 0 24 9 0 1 11171 461 > 19067 0 34 65 > 0 0 0 256M 1933M 12 0 0 0 24 9 0 0 11109 476 > 18945 1 34 65 > 1 0 0 256M 1933M 12 0 0 0 24 9 0 0 11354 468 > 19352 0 36 64 > 0 0 0 256M 1933M 13 0 0 0 24 9 0 0 11162 465 > 18866 1 34 65 > 0 0 0 256M 1933M 12 0 0 0 24 9 0 2 11297 471 > 19165 0 36 64 > 1 0 0 256M 1933M 12 0 0 0 24 9 0 0 11345 465 > 19296 1 35 64 > 0 0 0 256M 1933M 12 0 0 0 24 9 0 0 11044 461 > 18634 0 35 65 > 0 0 0 235M 1934M 65 0 0 0 263 9 0 1 3224 602 5060 > 2 9 89 > 0 0 0 235M 1934M 12 0 0 0 24 9 0 0 142 206 77 > 0 0 100 > 0 0 0 235M 1934M 34 0 0 0 64 9 0 0 260 347 104 > 0 1 99 > 0 0 0 235M 1934M 12 0 0 0 24 9 0 0 142 206 79 > 0 0 100 > ----- > > Is this an expected result? Assuming that the system was about 65% idle, > there is a space for improvement. > > The system: > ----- > % uname -a > FreeBSD wandboard 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r265218M: Fri May > 2 18:24:07 SAMT 2014 > bsam@wandboard:/usr/obj/usr/src/sys/WANDBOARD-QUAD arm > ----- > There is definitely room for improvement. ffec is the first network driver I ever wrote for freebsd, and I was trying for reliability more than performance for the first attempt. Every packet is being copied multiple times, and we can eliminate some of that. Also, the imx6 supports some hardware-assist stuff (but imx5 doesn't, and it's the same driver, so we have to support both). I'm probably too busy to do anything about it for a while, but if anybody else wants to improve it, that would be great. I think its performance could double without too much work, and then further improvements after that will take increasing effort for smaller gains. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun May 4 03:36:37 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07E3F3D4; Sun, 4 May 2014 03:36:37 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D001D16AA; Sun, 4 May 2014 03:36:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s443aaKD053729; Sun, 4 May 2014 03:36:36 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s443aaP2053728; Sun, 4 May 2014 03:36:36 GMT (envelope-from linimon) Date: Sun, 4 May 2014 03:36:36 GMT Message-Id: <201405040336.s443aaP2053728@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-bugs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: bin/188510: [patch] rtadvd(8): "rtadvctl show" crashes on BeagleBone Black due to unaligned access X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 03:36:37 -0000 Old Synopsis: [patch] "rtadvctl show" crashes on BeagleBone Black due to unaligned access New Synopsis: [patch] rtadvd(8): "rtadvctl show" crashes on BeagleBone Black due to unaligned access Responsible-Changed-From-To: freebsd-arm->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 4 03:35:33 UTC 2014 Responsible-Changed-Why: Although the problem is arm-specific, the patch is not. Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=188510 From owner-freebsd-arm@FreeBSD.ORG Sun May 4 03:54:21 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19F1D6AE; Sun, 4 May 2014 03:54:21 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1ED81805; Sun, 4 May 2014 03:54:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s443sKvY061248; Sun, 4 May 2014 03:54:20 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s443sKIW061247; Sun, 4 May 2014 03:54:20 GMT (envelope-from linimon) Date: Sun, 4 May 2014 03:54:20 GMT Message-Id: <201405040354.s443sKIW061247@freefall.freebsd.org> To: onwahe@gmail.com, linimon@FreeBSD.org, freebsd-arm@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: arm/182544: [patch] ARM busdma_machdep-v6.c X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 03:54:21 -0000 Synopsis: [patch] ARM busdma_machdep-v6.c State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun May 4 03:53:36 UTC 2014 State-Changed-Why: Fixed a different way in r256637. Thanks for the patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=182544 From owner-freebsd-arm@FreeBSD.ORG Sun May 4 05:04:24 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 621B4837; Sun, 4 May 2014 05:04:24 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 32A241D08; Sun, 4 May 2014 05:04:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4454OpJ087519; Sun, 4 May 2014 05:04:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4454OmX087518; Sun, 4 May 2014 05:04:24 GMT (envelope-from linimon) Date: Sun, 4 May 2014 05:04:24 GMT Message-Id: <201405040504.s4454OmX087518@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: bin/185617: pfctl(8): 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 05:04:24 -0000 Old Synopsis: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access New Synopsis: pfctl(8): 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Responsible-Changed-From-To: freebsd-arm->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 4 05:03:54 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=185617 From owner-freebsd-arm@FreeBSD.ORG Sun May 4 10:06:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED925B42 for ; Sun, 4 May 2014 10:06:24 +0000 (UTC) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [IPv6:2a02:6b8:0:1819::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA0A814C4 for ; Sun, 4 May 2014 10:06:24 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 8A6A614E0CF6; Sun, 4 May 2014 14:06:20 +0400 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id 31C347E0018; Sun, 4 May 2014 14:06:20 +0400 (MSK) Received: from 78.108.203.86.tel.ru (78.108.203.86.tel.ru [78.108.203.86]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id XAQ8Vf7vtX-6JwGk52w; Sun, 4 May 2014 14:06:19 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 12cf4796-80e1-4cce-bc9a-1bc2296188c7 Message-ID: <5366111B.5070503@passap.ru> Date: Sun, 04 May 2014 14:06:19 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ticso@cicely.de Subject: Re: wandboard-quad: ffec performance (about 190 Mbits/sec) References: <53654A67.6030605@passap.ru> <20140503202441.GD64774@cicely7.cicely.de> In-Reply-To: <20140503202441.GD64774@cicely7.cicely.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 10:06:25 -0000 04.05.2014 00:24, Bernd Walter пишет: > On Sat, May 03, 2014 at 11:58:31PM +0400, Boris Samorodov wrote: >> Hi All, >> >> My home PC has max perfomance approx. 800 Mbit/sec (measured between >> two re adapters and a cheap d-link switch in between them). >> >> I've just test ffec performance (one of re's is the other side): >> ----- >> >> Is this an expected result? Assuming that the system was about 65% idle, >> there is a space for improvement. > > Freecale says that the ethernet interface has a 400Mbit/s memory > interface, so that's pretty much the physical limit and I think even > in summary of both directions. > The hardware also has some very fancy IP offloading stuff, of which I > don't know how much we already utilize. >From the Processor Reference Manual (IMX6DQRM, Rev. 1, 04/2013), Chapter 23 "10/100/1000-Mbps Ethernet MAC (ENET), Section 23.1.1 "Features": ----- The theoretical maximum performance of 1 Gbps ENET is limited to 470 Mbps (total for Tx and Rx)[...] The actual measured performance in an optimized environnment is up to 400 Mbps. ----- So, it seems that 400 Mbps is a real target. > As an interest off myself, when you already have such a setup running. > Can you do a ping test to see what latency you get during bulk traffic > and without? > Currently I can't easily do such tests myself, since I have a full > workbench with unrelated stuff. OK, here it is. Pining wandboard while it generates traffic to iperf server (wandboard runs "iperf -c "). Pinging time window is slightly broader then iperf one: ----- % ping wb2.bb.tel.ru PING wb2 (192.168.100.211): 56 data bytes 64 bytes from 192.168.100.211: icmp_seq=0 ttl=64 time=0.217 ms 64 bytes from 192.168.100.211: icmp_seq=1 ttl=64 time=0.193 ms 64 bytes from 192.168.100.211: icmp_seq=2 ttl=64 time=0.754 ms 64 bytes from 192.168.100.211: icmp_seq=4 ttl=64 time=2.709 ms 64 bytes from 192.168.100.211: icmp_seq=8 ttl=64 time=1.011 ms 64 bytes from 192.168.100.211: icmp_seq=9 ttl=64 time=2.456 ms 64 bytes from 192.168.100.211: icmp_seq=10 ttl=64 time=3.117 ms 64 bytes from 192.168.100.211: icmp_seq=11 ttl=64 time=2.871 ms 64 bytes from 192.168.100.211: icmp_seq=12 ttl=64 time=0.198 ms 64 bytes from 192.168.100.211: icmp_seq=13 ttl=64 time=0.205 ms 64 bytes from 192.168.100.211: icmp_seq=14 ttl=64 time=0.206 ms 64 bytes from 192.168.100.211: icmp_seq=15 ttl=64 time=0.173 ms ^C --- wb2 ping statistics --- 16 packets transmitted, 12 packets received, 25.0% packet loss round-trip min/avg/max/stddev = 0.173/1.176/3.117/1.175 ms ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Sun May 4 11:42:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08A31FE2 for ; Sun, 4 May 2014 11:42:42 +0000 (UTC) Received: from orange.myspectrum.nl (orange.myspectrum.nl [149.210.134.247]) by mx1.freebsd.org (Postfix) with ESMTP id BCF591BC9 for ; Sun, 4 May 2014 11:42:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by orange.myspectrum.nl (Postfix) with ESMTP id 50EDC8ADF1; Sun, 4 May 2014 13:33:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at myspectrum.nl Received: from orange.myspectrum.nl ([127.0.0.1]) by localhost (orange.myspectrum.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2SQSOsQiC06; Sun, 4 May 2014 13:33:32 +0200 (CEST) Received: from [192.168.0.7] (ip136-5-208-87.adsl2.static.versatel.nl [87.208.5.136]) (Authenticated sender: dasuboot@myspectrum.nl) by orange.myspectrum.nl (Postfix) with ESMTPSA id 586658ADEE; Sun, 4 May 2014 13:33:32 +0200 (CEST) Message-ID: <1399203211.1994.25.camel@yellow> Subject: Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD From: Jeroen Hofstee To: Xuebing Wang Date: Sun, 04 May 2014 13:33:31 +0200 In-Reply-To: <5343B8B9.6040607@gmail.com> References: <5343B8B9.6040607@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: trini@ti.com, u-boot@lists.denx.de, vanbaren@cideas.com, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 11:42:42 -0000 Hello Xuebing, (freebsd-arm added on cc), On di, 2014-04-08 at 16:52 +0800, Xuebing Wang wrote: > Hi u-boot community, > > I am trying to port u-boot (release u-boot-2014.04-rc3.tar.bz2) to > FreeBSD on BeagleBone Black. > > In FreeBSD, there is a u-boot loader (named ubldr), which can call > u-boot API to get fdt (Flat Device Tree) data. > > I have to comment out below 3 lines, in order to get correct fdt data in > FreeBSD ubldr from u-boot. Would you please advice what is the best way > to fix this? > > In file common/env_common.c: > const uchar *env_get_addr(int index) > { > // if (gd->env_valid) > // return (uchar *)(gd->env_addr + index); > // else > return &default_environment[index]; > } > Assuming that you checked that your environment is valid you might be facing the fact that the gd pointer is corrupted. gd is a pointer to the "global data" and used for storing globals which are available before and after relocation. On (32bit) ARM this value used to be stored in register r8 but moved to r9 (llvm cannot reserve an arbitrary register, but can reserve r9 for platform specific usage). If ubldr uses r9 you end up with a invalid gd pointer when calling back into u-boot. ubldr now reserves r8 and r9 so a recent version should work fine on an older U-boot as well as current master. Can you check the latest ubldr? Regards, Jeroen From owner-freebsd-arm@FreeBSD.ORG Sun May 4 11:56:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 690A8124 for ; Sun, 4 May 2014 11:56:00 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 156961C6B for ; Sun, 4 May 2014 11:55:59 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s44Btoh2048803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 May 2014 13:55:51 +0200 (CEST) (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 s44BthOG011421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2014 13:55:43 +0200 (CEST) (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 s44BtgPZ071433; Sun, 4 May 2014 13:55:42 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s44BtgB5071432; Sun, 4 May 2014 13:55:42 +0200 (CEST) (envelope-from ticso) Date: Sun, 4 May 2014 13:55:42 +0200 From: Bernd Walter To: Boris Samorodov Subject: Re: wandboard-quad: ffec performance (about 190 Mbits/sec) Message-ID: <20140504115542.GA71303@cicely7.cicely.de> References: <53654A67.6030605@passap.ru> <20140503202441.GD64774@cicely7.cicely.de> <5366111B.5070503@passap.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5366111B.5070503@passap.ru> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 11:56:00 -0000 On Sun, May 04, 2014 at 02:06:19PM +0400, Boris Samorodov wrote: > 04.05.2014 00:24, Bernd Walter ??????????: > > On Sat, May 03, 2014 at 11:58:31PM +0400, Boris Samorodov wrote: > >> Hi All, > >> > >> My home PC has max perfomance approx. 800 Mbit/sec (measured between > >> two re adapters and a cheap d-link switch in between them). > >> > >> I've just test ffec performance (one of re's is the other side): > >> ----- > >> > >> Is this an expected result? Assuming that the system was about 65% idle, > >> there is a space for improvement. > > > > Freecale says that the ethernet interface has a 400Mbit/s memory > > interface, so that's pretty much the physical limit and I think even > > in summary of both directions. > > The hardware also has some very fancy IP offloading stuff, of which I > > don't know how much we already utilize. > > From the Processor Reference Manual (IMX6DQRM, Rev. 1, 04/2013), > Chapter 23 "10/100/1000-Mbps Ethernet MAC (ENET), Section 23.1.1 > "Features": > ----- > The theoretical maximum performance of 1 Gbps ENET is limited to 470 > Mbps (total for Tx and Rx)[...] The actual measured performance in an > optimized environnment is up to 400 Mbps. > ----- > > So, it seems that 400 Mbps is a real target. > > > As an interest off myself, when you already have such a setup running. > > Can you do a ping test to see what latency you get during bulk traffic > > and without? > > Currently I can't easily do such tests myself, since I have a full > > workbench with unrelated stuff. > > OK, here it is. Pining wandboard while it generates traffic to iperf > server (wandboard runs "iperf -c "). Pinging time window is > slightly broader then iperf one: > ----- > % ping wb2.bb.tel.ru > PING wb2 (192.168.100.211): 56 data bytes > 64 bytes from 192.168.100.211: icmp_seq=0 ttl=64 time=0.217 ms > 64 bytes from 192.168.100.211: icmp_seq=1 ttl=64 time=0.193 ms > 64 bytes from 192.168.100.211: icmp_seq=2 ttl=64 time=0.754 ms > 64 bytes from 192.168.100.211: icmp_seq=4 ttl=64 time=2.709 ms > 64 bytes from 192.168.100.211: icmp_seq=8 ttl=64 time=1.011 ms > 64 bytes from 192.168.100.211: icmp_seq=9 ttl=64 time=2.456 ms > 64 bytes from 192.168.100.211: icmp_seq=10 ttl=64 time=3.117 ms > 64 bytes from 192.168.100.211: icmp_seq=11 ttl=64 time=2.871 ms > 64 bytes from 192.168.100.211: icmp_seq=12 ttl=64 time=0.198 ms > 64 bytes from 192.168.100.211: icmp_seq=13 ttl=64 time=0.205 ms > 64 bytes from 192.168.100.211: icmp_seq=14 ttl=64 time=0.206 ms > 64 bytes from 192.168.100.211: icmp_seq=15 ttl=64 time=0.173 ms > ^C > --- wb2 ping statistics --- > 16 packets transmitted, 12 packets received, 25.0% packet loss > round-trip min/avg/max/stddev = 0.173/1.176/3.117/1.175 ms > ----- I was interested for my own project, but it also explains your results. Say 3ms and I remember having seen 32k Socketbuffer. This means you can send at most 32k in a single TCP connection before receiving an ackknowledge. Lets do the math with 3ms and 32k: 32k / 0.003 = 10666k Maybe it is testing bidirectional traffic, so you get doubled values, or the 3ms wasn't accurate and it is more like 1.5ms. To get 40000k with 32k in single stream your latency must be below 0.8ms. You can try using bigger buffers (32k is a traditional TCP limit, but all modern systems allow extended buffer sizes). But I expect this will just increase the latency. I assume there are many unsued features in the driver - should really take a look into the source, but this is quite complex and I never coded for such a complex ethernet hardware. The hardware has a lot of speeding features and it takes a very hughe part in the documentation. The good point is that there is documentation. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sun May 4 12:37:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07341960 for ; Sun, 4 May 2014 12:37:44 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6EF310E7 for ; Sun, 4 May 2014 12:37:43 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s44CbYTl047777; Sun, 4 May 2014 08:37:39 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5366348E.7010905@m5p.com> Date: Sun, 04 May 2014 08:37:34 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: required xdev line to build r-pi on crochet? References: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> In-Reply-To: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> 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]); Sun, 04 May 2014 08:37:39 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 12:37:44 -0000 On 05/03/14 10:27, Warner Losh wrote: > > On May 3, 2014, at 12:14 AM, Adrian Chadd wrote: > >> With Warners recent changes, the hint from crochet about how to build >> the xdev environment for the raspberry pi no longer applies. >> >> So - how does one build said xdev toolchain now? > > Add WITHOUT_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. > > Warner > I interpreted this as meaning I should type this in /usr/src: make XDEV=arm XDEV_ARCH=armv6 WITHOUT_CLANG_BOOTSTRAP=yes WITH_GCC_BOOTSTRAP=yes xdev But I still don't get armv6-freebsd-gcc and armv6-freebsd-ld built in /usr/armv6-freebds/usr/bin, and consequently I can't build uboot. Did I misinterpret your instruction? -- George From owner-freebsd-arm@FreeBSD.ORG Sun May 4 17:30:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70062D7D for ; Sun, 4 May 2014 17:30:18 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CB9D1D2C for ; Sun, 4 May 2014 17:30:18 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s44HTimI049147; Sun, 4 May 2014 13:30:15 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <53667908.2030100@m5p.com> Date: Sun, 04 May 2014 13:29:44 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: required xdev line to build r-pi on crochet? References: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> <5366348E.7010905@m5p.com> In-Reply-To: <5366348E.7010905@m5p.com> 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]); Sun, 04 May 2014 13:30:15 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 17:30:18 -0000 On 05/04/14 08:37, George Mitchell wrote: > On 05/03/14 10:27, Warner Losh wrote: >>[...] >> Add WITHOUT_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. >> >> Warner >> > I interpreted this as meaning I should type this in /usr/src: > > make XDEV=arm XDEV_ARCH=armv6 WITHOUT_CLANG_BOOTSTRAP=yes > WITH_GCC_BOOTSTRAP=yes xdev And I have WITH_GCC=yes in /etc/src.conf. > [...] From owner-freebsd-arm@FreeBSD.ORG Sun May 4 20:44:29 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E957C45; Sun, 4 May 2014 20:44:29 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 54E6C1C5B; Sun, 4 May 2014 20:44:27 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.7/8.14.7) with ESMTP id s44KiEm3084634; Sun, 4 May 2014 22:44:15 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.7/8.14.7/Submit) id s44KiEEB083055; Sun, 4 May 2014 20:44:14 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 4 May 2014 20:44:14 GMT Message-Id: <201405042044.s44KiEEB083055@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 20:44:29 -0000 TB --- 2014-05-04 20:40:47 - tinderbox 2.21 running on worker01.tb.des.no TB --- 2014-05-04 20:40:47 - FreeBSD worker01.tb.des.no 9.2-RELEASE-p4 FreeBSD 9.2-RELEASE-p4 #0: Tue Apr 8 18:08:22 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-04 20:40:47 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-05-04 20:40:47 - cleaning the object tree TB --- 2014-05-04 20:40:47 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-04 20:41:31 - At svn revision 265337 TB --- 2014-05-04 20:41:32 - building world TB --- 2014-05-04 20:41:32 - CROSS_BUILD_TESTING=YES TB --- 2014-05-04 20:41:32 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-04 20:41:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-04 20:41:32 - SRCCONF=/dev/null TB --- 2014-05-04 20:41:32 - TARGET=arm TB --- 2014-05-04 20:41:32 - TARGET_ARCH=arm TB --- 2014-05-04 20:41:32 - TZ=UTC TB --- 2014-05-04 20:41:32 - __MAKE_CONF=/dev/null TB --- 2014-05-04 20:41:32 - cd /src TB --- 2014-05-04 20:41:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun May 4 20:41:42 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] ranlib libllvmtablegen.a ===> usr.bin/clang/tblgen (obj,depend,all,install) /obj/arm.arm/src/tmp/src/usr.bin/clang/tblgen created for /src/usr.bin/clang/tblgen rm -f .depend mkdep -f .depend -a -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -I/obj/arm.arm/src/tmp/legacy/usr/include /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/AsmMatcherEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/AsmWriterEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/AsmWriterInst.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CTagsEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CallingConvEmitter.cpp /src/usr.bi! n/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeEmitterGen.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenDAGPatterns.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenInstruction.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenMapTable.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenRegisters.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenSchedule.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenTarget.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/DAGISelEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/DAGISelMatcher.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/DAGISelMatcherEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/DAGISelMatcherGen.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/DAGISelMatche! rOpt.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils! /TableGen/DFAPacketizerEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/DisassemblerEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/FastISelEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/FixedLenDecoderEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/InstrInfoEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/IntrinsicEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/OptParserEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/PseudoLoweringEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/RegisterInfoEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/SetTheory.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/SubtargetEmitter.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/TGValueTypes.cpp /src/usr.bin/clang/tblge! n/../../../contrib/llvm/utils/TableGen/TableGen.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/X86DisassemblerTables.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/X86ModRMFilters.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/X86RecognizableInstr.cpp echo tblgen: /usr/lib/libc.a /obj/arm.arm/src/tmp/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmtablegen/libllvmtablegen.a /obj/arm.arm/src/tmp/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a /usr/lib/libncurses.a /obj/arm.arm/src/tmp/legacy/usr/lib/libegacy.a >> .depend echo tblgen: >> .depend c++ -O2 -pipe -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/AsmMatcherEmitter.cpp c++ -O2 -pipe -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/AsmWriterEmitter.cpp c++ -O2 -pipe -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/AsmWriterInst.cpp c++ -O2 -pipe -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CTagsEmitter.cpp c++ -O2 -pipe -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CallingConvEmitter.cpp c++ -O2 -pipe -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeEmitterGen.cpp c++ -O2 -pipe -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenDAGPatterns.cpp c++ -O2 -pipe -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenInstruction.cpp /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenInstruction.cpp: In member function 'void llvm::CGIOperandList::ProcessDisableEncoding(std::string)': /src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenInstruction.cpp:270: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[2]: stopped in /src/usr.bin/clang/tblgen *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-05-04 20:44:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-04 20:44:13 - ERROR: failed to build world TB --- 2014-05-04 20:44:13 - 128.23 user 73.23 system 206.60 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon May 5 03:41:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B42BD4 for ; Mon, 5 May 2014 03:41:47 +0000 (UTC) Received: from feith1.FEITH.COM (feith1.FEITH.COM [192.251.93.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F9DC17F0 for ; Mon, 5 May 2014 03:41:46 +0000 (UTC) Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.14.5+Sun/8.12.9) with ESMTP id s453Tpke010530 for ; Sun, 4 May 2014 23:29:51 -0400 (EDT) (envelope-from john@jwlab.FEITH.COM) Received: from jwlab.FEITH.COM (localhost [127.0.0.1]) by jwlab.FEITH.COM (8.14.5+Sun/8.14.5) with ESMTP id s453TpPC014573 for ; Sun, 4 May 2014 23:29:51 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.14.5+Sun/8.14.5/Submit) id s453TpGV014572 for freebsd-arm@freebsd.org; Sun, 4 May 2014 23:29:51 -0400 (EDT) Date: Sun, 4 May 2014 23:29:51 -0400 (EDT) From: John Wehle Message-Id: <201405050329.s453TpGV014572@jwlab.FEITH.COM> To: freebsd-arm@freebsd.org Subject: Amlogic aml8726-m3 / aml8726-m6 SoC status MIME-Version: 1.0 Content-Type: text/plain X-DCC--Metrics: feith1; whitelist X-Scanned-By: MIMEDefang 2.67 on 192.251.93.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 03:41:47 -0000 Here's quick blurb regarding the current status of support for Amlogic aml8726-m3 and aml8726-m6 SoC. In my private source tree I've implemented the following: Done / lightly tested: Basic machdep code Interrupt controller Timer Real time clock UART GPIO SD card USB Watchdog Random number generator PLL / Clock frequency measurement Done / untested: I2C (using manual mode) Work in progress: Ethernet (it seems like the hardware is actually a DesignWare Core so this driver may be useful for supporting other SoC). Frame buffer (needs additional code to program the PLLs ... works if the PLLs are setup by the firmware) Currently FreeBSD successfully boots to the login prompt on an aml8726-m6 board using a SD card and a serial console. Plans: Finish the ethernet driver. SMP Supply a series of patches so the code can be considered for HEAD. Test on a aml8726-m3 board. Revisit the frame buffer driver. Test on an Ainol Elf-2 tablet. Look at supporting flash memory. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From owner-freebsd-arm@FreeBSD.ORG Mon May 5 07:32:23 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 256C6B5A; Mon, 5 May 2014 07:32:23 +0000 (UTC) Received: from server1.xenet.de (server1out.xenet.de [213.221.94.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9191962; Mon, 5 May 2014 07:32:21 +0000 (UTC) Received: from [10.0.0.50] (intern.xenet.de [213.221.94.50]) (authenticated bits=0) by server1.xenet.de (8.12.5/8.12.5) with ESMTP id s457WBdC071373; Mon, 5 May 2014 09:32:13 +0200 (CEST) (envelope-from meyser@xenet.de) Message-ID: <53673E73.6020404@xenet.de> Date: Mon, 05 May 2014 09:32:03 +0200 From: Matthias Meyser Organization: XeNET GmbH, Clausthal-Zellerfeld User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: linimon@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: Re: arm/184078: [xdev] cross installworld missing include files References: <201404202148.s3KLmHuR097162@freefall.freebsd.org> In-Reply-To: <201404202148.s3KLmHuR097162@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.38 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 07:32:23 -0000 Am 20.04.2014 23:48, schrieb linimon@FreeBSD.org: > Old Synopsis: cross installworld missing include files > New Synopsis: [xdev] cross installworld missing include files > > State-Changed-From-To: open->feedback > State-Changed-By: linimon > State-Changed-When: Sun Apr 20 21:47:57 UTC 2014 > State-Changed-Why: > to submitter: xdev has recently been reworked. Is this PR now obsolete? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=184078 > Can be closed. Cross build/install and a native build/install afterwards worked without a glitch. -- Matthias Meyser | XeNET GmbH Tel.: +49-5323-9489050 | 38678 Clausthal-Zellerfeld, Marktstrasse 40 Fax: +49-5323-94014 | Registergericht: Amtsgericht Braunschweig HRB 110823 Email: Meyser@xenet.de | Geschaeftsfuehrer: Matthias Meyser From owner-freebsd-arm@FreeBSD.ORG Mon May 5 08:45:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 156977D0 for ; Mon, 5 May 2014 08:45:29 +0000 (UTC) Received: from mail.naobsd.org (7c294571.i-revonet.jp [124.41.69.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E7B0105D for ; Mon, 5 May 2014 08:45:27 +0000 (UTC) Received: from [192.168.1.149] ([192.168.1.149]) (authenticated bits=0) by mail.naobsd.org (8.13.6.20060614/8.13.6) with ESMTP id s458NHvQ026068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 May 2014 17:23:19 +0900 (JST) Message-ID: <53674A76.4060305@fukaumi.org> Date: Mon, 05 May 2014 17:23:18 +0900 From: FUKAUMI Naoki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Wehle , freebsd-arm@freebsd.org Subject: Re: Amlogic aml8726-m3 / aml8726-m6 SoC status References: <201405050329.s453TpGV014572@jwlab.FEITH.COM> In-Reply-To: <201405050329.s453TpGV014572@jwlab.FEITH.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 08:45:29 -0000 hi On 05/05/2014 12:29 PM, John Wehle wrote: > Here's quick blurb regarding the current status of support for > Amlogic aml8726-m3 and aml8726-m6 SoC. great work! what is your main target device? > Work in progress: > > Ethernet (it seems like the hardware is actually a DesignWare Core > so this driver may be useful for supporting other SoC). is it same as this one? https://www.kernel.org/doc/Documentation/networking/stmmac.txt then, it can be used for Allwinner A20 :) > Look at supporting flash memory. I think it's not open, there is a binary blob in Linux kernel... -- http://androtab.info/ From owner-freebsd-arm@FreeBSD.ORG Mon May 5 11:06:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58A82CE2 for ; Mon, 5 May 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CF251CE1 for ; Mon, 5 May 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s45B6f6C083050 for ; Mon, 5 May 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s45B6ema083048 for freebsd-arm@FreeBSD.org; Mon, 5 May 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 May 2014 11:06:40 GMT Message-Id: <201405051106.s45B6ema083048@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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 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/188933 arm [lor] lock order reversal: backtrace while writing to o arm/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp f arm/184078 arm [xdev] cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o ports/175605 arm devel/binutils: please fix build binutils-2.23.1 in ra 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/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 ports/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 [at91] [patch] Enable at91 booting from SDHC (high cap 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 28 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon May 5 11:56:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 742FFCAC for ; Mon, 5 May 2014 11:56:54 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2EE1014DA for ; Mon, 5 May 2014 11:56:53 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6600C1FE029; Mon, 5 May 2014 13:56:46 +0200 (CEST) Message-ID: <53677CB8.5000800@selasky.org> Date: Mon, 05 May 2014 13:57:44 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Johny Mattsson , freebsd-arm@freebsd.org Subject: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> In-Reply-To: <5363C133.2000304@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 11:56:54 -0000 Hi, To get USB isochronous traffic working with the DWC OTG you need this patch: http://svnweb.freebsd.org/changeset/base/265358 BTW: I see that every second or so there is a glitch. I suspect this is because someone in the kernel is calling DELAY(). Is there an easy way to figure out who is blocking the DWC OTG interrupt routine from executing? I was thinking about adding something like: if (!cold) printf("Using delay\n"); To the DELAY() function to figure out the caller. --HPS From owner-freebsd-arm@FreeBSD.ORG Mon May 5 13:51:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73EAE7B2 for ; Mon, 5 May 2014 13:51:03 +0000 (UTC) Received: from server1.xenet.de (server1out.xenet.de [213.221.94.200]) by mx1.freebsd.org (Postfix) with ESMTP id 051AB1041 for ; Mon, 5 May 2014 13:51:01 +0000 (UTC) Received: from [10.0.0.50] (intern.xenet.de [213.221.94.50]) (authenticated bits=0) by server1.xenet.de (8.12.5/8.12.5) with ESMTP id s45DoudC081067 for ; Mon, 5 May 2014 15:50:58 +0200 (CEST) (envelope-from meyser@xenet.de) Message-ID: <5367973F.20300@xenet.de> Date: Mon, 05 May 2014 15:50:55 +0200 From: Matthias Meyser Organization: XeNET GmbH, Clausthal-Zellerfeld User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> In-Reply-To: <5363C133.2000304@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.38 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 13:51:03 -0000 Am 02.05.2014 18:00, schrieb Hans Petter Selasky: > On 05/01/14 17:08, Hans Petter Selasky wrote: >> On 05/01/14 01:34, Johny Mattsson wrote: >>> On 1 May 2014 00:14, Ian Lepore wrote: >>> >>>> I was doing some testing on a wandboard (about twice as fast an an rpi) >>>> with >>>> more than 20k int/sec without having any problems. >>>> >>> >>> On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k >>> int/sec, on Linux. Admittedly at that point my shell wasn't what you'd >>> call >>> "responsive" however =) The ISR in that scenario was the GPIO handler, so >>> probably a bit more light-weight than an audio ISR. >> >> I'll have a look and see if I can fix it. > Here is a patch (work in progress) which you can try: > http://home.selasky.org:8192/dwc_otg_isoc_support_wip.diff > > Still not working 100% reliable. Trying to figure out the last bits and pieces. For testing it would be very helful if someone could add device sound device snd_uaudio to RPI-B kernel. Having this in BEAGLEBONE would be nice to. Perhaps this schould go in every config that supports usb. > > --HPS > > -- Matthias Meyser | XeNET GmbH Tel.: +49-5323-9489050 | 38678 Clausthal-Zellerfeld, Marktstrasse 40 Fax: +49-5323-94014 | Registergericht: Amtsgericht Braunschweig HRB 110823 Email: Meyser@xenet.de | Geschaeftsfuehrer: Matthias Meyser From owner-freebsd-arm@FreeBSD.ORG Mon May 5 14:33:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B7713DE for ; Mon, 5 May 2014 14:33:02 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35BBE13C4 for ; Mon, 5 May 2014 14:33:01 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AEE401FE029; Mon, 5 May 2014 16:32:59 +0200 (CEST) Message-ID: <5367A154.8010508@selasky.org> Date: Mon, 05 May 2014 16:33:56 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Matthias Meyser , freebsd-arm@freebsd.org Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <5367973F.20300@xenet.de> In-Reply-To: <5367973F.20300@xenet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 14:33:02 -0000 On 05/05/14 15:50, Matthias Meyser wrote: > > Am 02.05.2014 18:00, schrieb Hans Petter Selasky: >> On 05/01/14 17:08, Hans Petter Selasky wrote: >>> On 05/01/14 01:34, Johny Mattsson wrote: >>>> On 1 May 2014 00:14, Ian Lepore wrote: >>>> >>>>> I was doing some testing on a wandboard (about twice as fast an an >>>>> rpi) >>>>> with >>>>> more than 20k int/sec without having any problems. >>>>> >>>> >>>> On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k >>>> int/sec, on Linux. Admittedly at that point my shell wasn't what you'd >>>> call >>>> "responsive" however =) The ISR in that scenario was the GPIO >>>> handler, so >>>> probably a bit more light-weight than an audio ISR. >>> >>> I'll have a look and see if I can fix it. >> Here is a patch (work in progress) which you can try: >> http://home.selasky.org:8192/dwc_otg_isoc_support_wip.diff >> >> Still not working 100% reliable. Trying to figure out the last bits >> and pieces. > > For testing it would be very helful if someone could add > > device sound > device snd_uaudio > > to RPI-B kernel. > > Having this in BEAGLEBONE would be nice to. > Perhaps this schould go in every config that supports usb. > Hi, The following patch should make "devd" load sound.ko and snd_uaudio.ko automatically: http://svnweb.freebsd.org/changeset/base/265359 --HPS From owner-freebsd-arm@FreeBSD.ORG Mon May 5 14:47:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C3D2278 for ; Mon, 5 May 2014 14:47:41 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DCAAE1567 for ; Mon, 5 May 2014 14:47:40 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s45ElOIR064333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 May 2014 16:47:25 +0200 (CEST) (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 s45El5pF028055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2014 16:47:05 +0200 (CEST) (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 s45El537078592; Mon, 5 May 2014 16:47:05 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s45El56j078591; Mon, 5 May 2014 16:47:05 +0200 (CEST) (envelope-from ticso) Date: Mon, 5 May 2014 16:47:05 +0200 From: Bernd Walter To: Hans Petter Selasky Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined Message-ID: <20140505144704.GA78493@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <5367973F.20300@xenet.de> <5367A154.8010508@selasky.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5367A154.8010508@selasky.org> 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, WEIRD_PORT=0.001 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, Matthias Meyser X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 14:47:41 -0000 On Mon, May 05, 2014 at 04:33:56PM +0200, Hans Petter Selasky wrote: > On 05/05/14 15:50, Matthias Meyser wrote: > > > >Am 02.05.2014 18:00, schrieb Hans Petter Selasky: > >>On 05/01/14 17:08, Hans Petter Selasky wrote: > >>>On 05/01/14 01:34, Johny Mattsson wrote: > >>>>On 1 May 2014 00:14, Ian Lepore wrote: > >>>> > >>>>>I was doing some testing on a wandboard (about twice as fast an an > >>>>>rpi) > >>>>>with > >>>>>more than 20k int/sec without having any problems. > >>>>> > >>>> > >>>>On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k > >>>>int/sec, on Linux. Admittedly at that point my shell wasn't what you'd > >>>>call > >>>>"responsive" however =) The ISR in that scenario was the GPIO > >>>>handler, so > >>>>probably a bit more light-weight than an audio ISR. > >>> > >>>I'll have a look and see if I can fix it. > >>Here is a patch (work in progress) which you can try: > >>http://home.selasky.org:8192/dwc_otg_isoc_support_wip.diff > >> > >>Still not working 100% reliable. Trying to figure out the last bits > >>and pieces. > > > >For testing it would be very helful if someone could add > > > >device sound > >device snd_uaudio > > > >to RPI-B kernel. > > > >Having this in BEAGLEBONE would be nice to. > >Perhaps this schould go in every config that supports usb. > > > > Hi, > > The following patch should make "devd" load sound.ko and snd_uaudio.ko > automatically: > > http://svnweb.freebsd.org/changeset/base/265359 This won't work unless sound.ko especting ISA in ARM kernel is fixed as well. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon May 5 15:18:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 351B6D3 for ; Mon, 5 May 2014 15:18:53 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E66B61890 for ; Mon, 5 May 2014 15:18:52 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id q107so3364357qgd.38 for ; Mon, 05 May 2014 08:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mERxIgOsTaLovjIospVR05SBrCMnSEfTE1xst6EQqFQ=; b=gwXvz5ASEPAfizwSqtuLpGgITIbfpFawOQdspPYx96X9Oh+XydrSTWlmOBX9mpoDuG /+24FZnWb8mqv0GsD8vO1/Dlzz7z1+OMwQQvyYiyXg6S7myFxldulYOgfn0mhm3vDX2t Vfy7jMDtDXNTSXW1qTtmwmnGfhAq6xaaBtcY1WiZuglg6QhOthlLBlruYC2VIpMTmyuG BDaLfx4clkL81WWCKXSqkjyx8wh9KJkWUTDz5qgZq3P/V6nOuQDbLeaJIT5PAqHUdZR2 kKMKBj4ra1bMNYhIhdR5HPW+g/qzKZrqVrF7rUO9tpvAoCu95+GllH0NzBXyxw9+/oBn 3oLA== MIME-Version: 1.0 X-Received: by 10.224.47.130 with SMTP id n2mr46307525qaf.26.1399303132074; Mon, 05 May 2014 08:18:52 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Mon, 5 May 2014 08:18:51 -0700 (PDT) In-Reply-To: <53677CB8.5000800@selasky.org> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> Date: Mon, 5 May 2014 08:18:51 -0700 X-Google-Sender-Auth: pn4he6ncyl3K859XokR5mfFuxZs Message-ID: Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:18:53 -0000 evil idea: #define DELAY(ms) _DELAY(ms, __FILE__, __LINE__) .. then modify the relevant arm delay function to take FILE/LINE and KTR log it. :-) -a On 5 May 2014 04:57, Hans Petter Selasky wrote: > Hi, > > To get USB isochronous traffic working with the DWC OTG you need this patch: > > http://svnweb.freebsd.org/changeset/base/265358 > > BTW: I see that every second or so there is a glitch. I suspect this is > because someone in the kernel is calling DELAY(). Is there an easy way to > figure out who is blocking the DWC OTG interrupt routine from executing? > > I was thinking about adding something like: > > if (!cold) > printf("Using delay\n"); > > To the DELAY() function to figure out the caller. > > --HPS > _______________________________________________ > 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 May 5 15:28:21 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9F752EF; Mon, 5 May 2014 15:28:21 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 789BA1991; Mon, 5 May 2014 15:28:21 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WhKoV-000LqS-RD; Mon, 05 May 2014 15:28:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s45FSFaD023763; Mon, 5 May 2014 09:28:15 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX190HgEdne3tHiCramDckn7o Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 05 May 2014 09:28:15 -0600 Message-ID: <1399303695.22079.239.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:28:21 -0000 On Mon, 2014-05-05 at 08:18 -0700, Adrian Chadd wrote: > evil idea: > > #define DELAY(ms) _DELAY(ms, __FILE__, __LINE__) > > .. then modify the relevant arm delay function to take FILE/LINE and > KTR log it. :-) > > > -a Except some uart console output routines are structured like while (!readreg(STATUS) & TXRDY) DELAY(n); I don't know why people think that calling delay in busy loops like that has any value, considering that DELAY is almost always implemented as some form of while (readreg(COUNTER) < target_count) ; I guess maybe it has value only in that it helps you find busy-loops. I'd rather that we had a function just for that purpose, like while (readreg(COUNTER) < target_count) cpu_busy_loop(); (We have something like that that's x86-specific, iirc). -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon May 5 15:34:53 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 810525D7 for ; Mon, 5 May 2014 15:34:53 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFC31A57 for ; Mon, 5 May 2014 15:34:53 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WhKuq-000Pwm-7F; Mon, 05 May 2014 15:34:52 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s45FYmMb023772; Mon, 5 May 2014 09:34:48 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19TRZQkZyc1wNvyFO3C9R5S Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20140505144704.GA78493@cicely7.cicely.de> References: <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <5367973F.20300@xenet.de> <5367A154.8010508@selasky.org> <20140505144704.GA78493@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Mon, 05 May 2014 09:34:48 -0600 Message-ID: <1399304088.22079.242.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, Matthias Meyser X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:34:53 -0000 On Mon, 2014-05-05 at 16:47 +0200, Bernd Walter wrote: > On Mon, May 05, 2014 at 04:33:56PM +0200, Hans Petter Selasky wrote: > > On 05/05/14 15:50, Matthias Meyser wrote: > > > > > >Am 02.05.2014 18:00, schrieb Hans Petter Selasky: > > >>On 05/01/14 17:08, Hans Petter Selasky wrote: > > >>>On 05/01/14 01:34, Johny Mattsson wrote: > > >>>>On 1 May 2014 00:14, Ian Lepore wrote: > > >>>> > > >>>>>I was doing some testing on a wandboard (about twice as fast an an > > >>>>>rpi) > > >>>>>with > > >>>>>more than 20k int/sec without having any problems. > > >>>>> > > >>>> > > >>>>On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k > > >>>>int/sec, on Linux. Admittedly at that point my shell wasn't what you'd > > >>>>call > > >>>>"responsive" however =) The ISR in that scenario was the GPIO > > >>>>handler, so > > >>>>probably a bit more light-weight than an audio ISR. > > >>> > > >>>I'll have a look and see if I can fix it. > > >>Here is a patch (work in progress) which you can try: > > >>http://home.selasky.org:8192/dwc_otg_isoc_support_wip.diff > > >> > > >>Still not working 100% reliable. Trying to figure out the last bits > > >>and pieces. > > > > > >For testing it would be very helful if someone could add > > > > > >device sound > > >device snd_uaudio > > > > > >to RPI-B kernel. > > > > > >Having this in BEAGLEBONE would be nice to. > > >Perhaps this schould go in every config that supports usb. > > > > > > > Hi, > > > > The following patch should make "devd" load sound.ko and snd_uaudio.ko > > automatically: > > > > http://svnweb.freebsd.org/changeset/base/265359 > > This won't work unless sound.ko especting ISA in ARM kernel is fixed > as well. > This shouldn't be a problem. The code that references isa stuff is wrapped in #ifdef DEV_ISA, and an arm kernel build won't have that defined. The problem was that the makefile for building a sound module created an opt_isa.h containing #define DEV_ISA when building for arm so the loadable sound modules had references to isa but the driver in the kernel didn't. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon May 5 15:36:08 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EF3562D; Mon, 5 May 2014 15:36:08 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D7D71A65; Mon, 5 May 2014 15:36:07 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WhKvw-0009E8-Vx; Mon, 05 May 2014 15:36:01 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s45FZvAV023778; Mon, 5 May 2014 09:35:57 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18RxLeguqT7DwvhftD0LvCW Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Adrian Chadd In-Reply-To: <1399303695.22079.239.camel@revolution.hippie.lan> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 05 May 2014 09:35:57 -0600 Message-ID: <1399304157.22079.243.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:36:08 -0000 On Mon, 2014-05-05 at 09:28 -0600, Ian Lepore wrote: > On Mon, 2014-05-05 at 08:18 -0700, Adrian Chadd wrote: > > evil idea: > > > > #define DELAY(ms) _DELAY(ms, __FILE__, __LINE__) > > > > .. then modify the relevant arm delay function to take FILE/LINE and > > KTR log it. :-) > > > > > > -a > > Except some uart console output routines are structured like > > while (!readreg(STATUS) & TXRDY) > DELAY(n); > > I don't know why people think that calling delay in busy loops like that > has any value, considering that DELAY is almost always implemented as > some form of > > while (readreg(COUNTER) < target_count) > ; > > I guess maybe it has value only in that it helps you find busy-loops. > I'd rather that we had a function just for that purpose, like > > while (readreg(COUNTER) < target_count) > cpu_busy_loop(); > > (We have something like that that's x86-specific, iirc). > > -- Ian Oh never mind, I just noticed you said KTR, not printf. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon May 5 15:38:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2119690 for ; Mon, 5 May 2014 15:38:58 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C11D1A7D for ; Mon, 5 May 2014 15:38:58 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id EFEFA1FE029; Mon, 5 May 2014 17:38:56 +0200 (CEST) Message-ID: <5367B0C9.8090407@selasky.org> Date: Mon, 05 May 2014 17:39:53 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: ticso@cicely.de Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined References: <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <5367973F.20300@xenet.de> <5367A154.8010508@selasky.org> <20140505144704.GA78493@cicely7.cicely.de> In-Reply-To: <20140505144704.GA78493@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Matthias Meyser X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:38:59 -0000 On 05/05/14 16:47, Bernd Walter wrote: > On Mon, May 05, 2014 at 04:33:56PM +0200, Hans Petter Selasky wrote: >> On 05/05/14 15:50, Matthias Meyser wrote: >>> >>> Am 02.05.2014 18:00, schrieb Hans Petter Selasky: >>>> On 05/01/14 17:08, Hans Petter Selasky wrote: >>>>> On 05/01/14 01:34, Johny Mattsson wrote: >>>>>> On 1 May 2014 00:14, Ian Lepore wrote: >>>>>> >>>>>>> I was doing some testing on a wandboard (about twice as fast an an >>>>>>> rpi) >>>>>>> with >>>>>>> more than 20k int/sec without having any problems. >>>>>>> >>>>>> >>>>>> On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k >>>>>> int/sec, on Linux. Admittedly at that point my shell wasn't what you'd >>>>>> call >>>>>> "responsive" however =) The ISR in that scenario was the GPIO >>>>>> handler, so >>>>>> probably a bit more light-weight than an audio ISR. >>>>> >>>>> I'll have a look and see if I can fix it. >>>> Here is a patch (work in progress) which you can try: >>>> http://home.selasky.org:8192/dwc_otg_isoc_support_wip.diff >>>> >>>> Still not working 100% reliable. Trying to figure out the last bits >>>> and pieces. >>> >>> For testing it would be very helful if someone could add >>> >>> device sound >>> device snd_uaudio >>> >>> to RPI-B kernel. >>> >>> Having this in BEAGLEBONE would be nice to. >>> Perhaps this schould go in every config that supports usb. >>> >> >> Hi, >> >> The following patch should make "devd" load sound.ko and snd_uaudio.ko >> automatically: >> >> http://svnweb.freebsd.org/changeset/base/265359 > > This won't work unless sound.ko especting ISA in ARM kernel is fixed > as well. > Hi, I think sound.ko does not depend on ISA currently. Maybe that is a bug, because ISA is not a module, but in the kernel typically. dev/sound/isa/sndbuf_dma.c optional sound isa With my RPI snd_uaudio loads like expected now. --HPS From owner-freebsd-arm@FreeBSD.ORG Mon May 5 15:51:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFE6193E; Mon, 5 May 2014 15:51:19 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B1D21C1F; Mon, 5 May 2014 15:51:19 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id e16so5473876qcx.14 for ; Mon, 05 May 2014 08:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wEqHAT/lEJl7TRiglQt8b5mQ1+YxLOE/qYZc3AnxlDs=; b=pNLodv3lZKGDHFD4ARCYiWnvf8KirC6Y1i/XpKVjcyX/+3cKbXmET6lbVMKFvCXJq2 F2jBN2uT+EGz7KrhestfIsfVuaa4QqBVHbE/QNQCE9Gssjuu/u8JnY2w0wpfJa2z0ZO8 tOH4xIdEeEe1bDa0wYVEQdkPW6Brh0v/P2bAXMhsa1rGhMbaGChmwby9G6MmNRXCrfic 8ktwSKGOJ+s60MfCAJLv8cz0V+hw/Px4o3C0yiY3wARVzxcT/XmVLgTR68QW/Bq3/Pe1 O7/tCycV0RK5ZkH+2jXyOEt2lIByT5pWfPDljsQ3wuKgd2wCNmT62NXKE09/6AqPBWh3 wrPA== MIME-Version: 1.0 X-Received: by 10.140.104.195 with SMTP id a61mr25048910qgf.102.1399305078306; Mon, 05 May 2014 08:51:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Mon, 5 May 2014 08:51:18 -0700 (PDT) In-Reply-To: <1399304157.22079.243.camel@revolution.hippie.lan> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> Date: Mon, 5 May 2014 08:51:18 -0700 X-Google-Sender-Auth: XSzt2r-bS82omsygnMwrO5a3c3s Message-ID: Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:51:19 -0000 On 5 May 2014 08:35, Ian Lepore wrote: > Oh never mind, I just noticed you said KTR, not printf. Heh. That's why I like KTR. I bet some devices dislike you doing the "read registers all the time" dance. Espeically if they're on an ISA bus where it's really expensive to do things. But yes, your point is pretty spot on. -a From owner-freebsd-arm@FreeBSD.ORG Mon May 5 16:09:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 023D0E13; Mon, 5 May 2014 16:09:06 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 830671DCB; Mon, 5 May 2014 16:09:05 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s45G8uBI065014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 May 2014 18:08:57 +0200 (CEST) (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 s45G8hVI028792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2014 18:08:43 +0200 (CEST) (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 s45G8hW8078935; Mon, 5 May 2014 18:08:43 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s45G8gGS078934; Mon, 5 May 2014 18:08:42 +0200 (CEST) (envelope-from ticso) Date: Mon, 5 May 2014 18:08:42 +0200 From: Bernd Walter To: Ian Lepore Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined Message-ID: <20140505160842.GC78493@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <5367973F.20300@xenet.de> <5367A154.8010508@selasky.org> <20140505144704.GA78493@cicely7.cicely.de> <1399304088.22079.242.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1399304088.22079.242.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, WEIRD_PORT=0.001 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, Matthias Meyser , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:09:06 -0000 On Mon, May 05, 2014 at 09:34:48AM -0600, Ian Lepore wrote: > On Mon, 2014-05-05 at 16:47 +0200, Bernd Walter wrote: > > On Mon, May 05, 2014 at 04:33:56PM +0200, Hans Petter Selasky wrote: > > > On 05/05/14 15:50, Matthias Meyser wrote: > > > > > > > >Am 02.05.2014 18:00, schrieb Hans Petter Selasky: > > > >>On 05/01/14 17:08, Hans Petter Selasky wrote: > > > >>>On 05/01/14 01:34, Johny Mattsson wrote: > > > >>>>On 1 May 2014 00:14, Ian Lepore wrote: > > > >>>> > > > >>>>>I was doing some testing on a wandboard (about twice as fast an an > > > >>>>>rpi) > > > >>>>>with > > > >>>>>more than 20k int/sec without having any problems. > > > >>>>> > > > >>>> > > > >>>>On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k > > > >>>>int/sec, on Linux. Admittedly at that point my shell wasn't what you'd > > > >>>>call > > > >>>>"responsive" however =) The ISR in that scenario was the GPIO > > > >>>>handler, so > > > >>>>probably a bit more light-weight than an audio ISR. > > > >>> > > > >>>I'll have a look and see if I can fix it. > > > >>Here is a patch (work in progress) which you can try: > > > >>http://home.selasky.org:8192/dwc_otg_isoc_support_wip.diff > > > >> > > > >>Still not working 100% reliable. Trying to figure out the last bits > > > >>and pieces. > > > > > > > >For testing it would be very helful if someone could add > > > > > > > >device sound > > > >device snd_uaudio > > > > > > > >to RPI-B kernel. > > > > > > > >Having this in BEAGLEBONE would be nice to. > > > >Perhaps this schould go in every config that supports usb. > > > > > > > > > > Hi, > > > > > > The following patch should make "devd" load sound.ko and snd_uaudio.ko > > > automatically: > > > > > > http://svnweb.freebsd.org/changeset/base/265359 > > > > This won't work unless sound.ko especting ISA in ARM kernel is fixed > > as well. > > > > This shouldn't be a problem. The code that references isa stuff is > wrapped in #ifdef DEV_ISA, and an arm kernel build won't have that > defined. The problem was that the makefile for building a sound module > created an opt_isa.h containing #define DEV_ISA when building for arm so > the loadable sound modules had references to isa but the driver in the > kernel didn't. Didn't test myself, but this thread started with a problem like this. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon May 5 17:08:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 586E3B5B for ; Mon, 5 May 2014 17:08:58 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 35D596AA for ; Mon, 5 May 2014 17:08:57 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s45H8uHl050788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2014 10:08:57 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s45H8uLa050787; Mon, 5 May 2014 10:08:56 -0700 (PDT) (envelope-from jmg) Date: Mon, 5 May 2014 10:08:56 -0700 From: John-Mark Gurney To: Paul Darius Subject: Re: partition resize Message-ID: <20140505170856.GQ43976@funkthat.com> Mail-Followup-To: Paul Darius , freebsd-arm References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Idd68gPqKLz5+Ci0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 05 May 2014 10:08:57 -0700 (PDT) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:08:58 -0000 --Idd68gPqKLz5+Ci0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Paul Darius wrote this message on Sat, May 03, 2014 at 15:10 +0700: > hi there.. > > here is the partition created from the fbsd image > > $ gpart show > => 63 61497281 mmcsd0 MBR (29G) > 63 34776 1 !12 [active] (17M) > 34839 61462485 2 freebsd (29G) > 61497324 20 - free - (10K) > > => 0 1918278 mmcsd0s2 BSD (29G) > 0 1918278 1 freebsd-ufs (937M) This partition didn't grow for some reason... gpart resize -i 1 mmcsd0s2 Should grow it... > $ cat /etc/fstab > /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 > /dev/mmcsd0s2a / ufs rw,noatime 1 1 > md /tmp mfs rw,noatime,-s30m 0 0 > md /var/log mfs rw,noatime,-s15m 0 0 > md /var/tmp mfs rw,noatime,-s5m 0 0 > > when I do extract the ports.tar.gz into /usr, I end up with file system full > > how do i know which partition for what and how to resize them ? > > the /etc/rc.d/autosize start give the result : > # /etc/rc.d/autosize start > Enlarging root partition > mmcsd0s2 resized > gpart: autofill: No space left on device > growfs: requested size 937MB is not larger than the current filesystem > size 937MB I just recently rewrote crochet's autosize/growfs rc.d script to be able to handle any partitioning scheme to grow /... You could try the attached... just run: "growfs start" and it should run all the necesssary commands... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --Idd68gPqKLz5+Ci0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=growfs #!/bin/sh # PROVIDE: growfs # BEFORE: sysctl # KEYWORD: firstbootonly # Automatically grow / to fill the entire disk. # # This allows us to distribute a single image # and have it work on essentially any sized disk. # # TODO: Figure out a clean way to have this run # only on first boot. (We can't write anything to # disk here since the root disk is still mounted # read-only at this point.) Fortunately, it completes # very quickly if it can't actually grow the partition. # # TODO: Figure out where this should really be ordered. # I suspect it should go just after fsck but before mountcritlocal # but it's hard to tell for sure because of the bug described # below. # . /etc/rc.subr name="growfs" start_cmd="growfs_start" stop_cmd=":" rcvar="growfs_enable" growfs_start () { echo "Growing root partition to fill device" rootdev=$(df / | tail -n 1 | awk '{ sub("/dev/", "", $1); print $1 }') if [ x"$rootdev" = x"${rootdev%/*}" ]; then # raw device rawdev="$rootdev" else rawdev=$(glabel status | awk '$1 == "'"$rootdev"'" { print $3 }') if [ x"$rawdev" = x"" ]; then echo "Can't figure out device for: $rootdev" return fi fi sysctl -b kern.geom.conftxt | awk ' { lvl=$1 device[lvl] = $3 type[lvl] = $2 idx[lvl] = $7 if (dev == $3) { for (i = 1; i <= lvl; i++) { # resize if (type[i] == "PART") { pdev = device[i - 1] cmd[i] = "gpart resize -i " idx[i] " " pdev } else if (type[i] == "LABEL") { continue } else { print "unhandled type: " type[i] exit 1 } } for (i = 1; i <= lvl; i++) { if (cmd[i]) system(cmd[i]) } exit 0 } }' dev="$rawdev" growfs -y /dev/"$rootdev" } load_rc_config $name run_rc_command "$1" --Idd68gPqKLz5+Ci0-- From owner-freebsd-arm@FreeBSD.ORG Mon May 5 17:26:50 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C05E9E71 for ; Mon, 5 May 2014 17:26:50 +0000 (UTC) Received: from galore.getmail.no (galore.getmail.no [84.210.184.6]) by mx1.freebsd.org (Postfix) with ESMTP id 70D87873 for ; Mon, 5 May 2014 17:26:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 1CFDA43FF4 for ; Mon, 5 May 2014 19:18:41 +0200 (CEST) Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BhsD6Km4fC6Z for ; Mon, 5 May 2014 19:18:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id E65BF4401C for ; Mon, 5 May 2014 19:18:16 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.8.4 galore.getmail.no E65BF4401C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1399310296; bh=TYvYMPyYuW6++esTZy1278D7hPoKsUWPUQ33jD0CqU8=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=kPR1VURqky9g0BW0g4mn0HYxwdQ7Whx5o/h/CvAunj1gVJrUH1ZYJwdo7JJ0YbYsw dRRNSXo1Y5cS7QZ1m6jvXZN44ZqPHPTNRb2sINJ/vLLDDRXgMgrjlJ+Jpd1jmUmnlO jAZ+nXTieH8Xptc9jZpmbvqoRSG9YpGTRhOWFcWQ= X-Virus-Scanned: amavisd-new at galore.get.c.bitbit.net Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lHP0mOHpvPPE for ; Mon, 5 May 2014 19:18:16 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by galore.getmail.no (Postfix) with ESMTPSA id 6297B43EE0 for ; Mon, 5 May 2014 19:16:52 +0200 (CEST) Date: Mon, 5 May 2014 19:16:49 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: FreeBSD on Dockstar: U-Boot / ubldr? Message-Id: <20140505191649.3c52b741dc7bbd140764988c@getmail.no> In-Reply-To: <1399143174.22079.228.camel@revolution.hippie.lan> References: <20140503202047.294ad097b30f4240099659e6@getmail.no> <1399142139.22079.222.camel@revolution.hippie.lan> <20140503204548.a5ebaaddbfb3036e7d74b58a@getmail.no> <1399143174.22079.228.camel@revolution.hippie.lan> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd8.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:26:50 -0000 On Sat, 03 May 2014 12:52:54 -0600 Ian Lepore wrote: > I think it's a good idea in general, it could give us a way for people > to "try freebsd" quickly and easily without having to reflash their > boards/boxes with a new u-boot if there's flash memory involved. I managed to build an image for Dockstar with crichet, but then I had a (temporary, hopefully) setback, I managed to brick my Dockstar so that it doesn't even output anything to serial port anymore. it accesses the usb stick on power-on, so it isn't totally dead. I'll have to use a JTAG adapter to revive it. On the positive side; I get to learn about JTAG and the tols to use that. I have a GoodFET42[1] JTAG adapter, but it doesn't seem like it is supported in OpenOCD 0.7.0 (which is the newest version in ports). References: 1) http://goodfet.sourceforge.net/ -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Mon May 5 17:37:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3C43249 for ; Mon, 5 May 2014 17:37:10 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D04B8962 for ; Mon, 5 May 2014 17:37:10 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s45Hb9vN051149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2014 10:37:10 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s45Hb9Gd051148; Mon, 5 May 2014 10:37:09 -0700 (PDT) (envelope-from jmg) Date: Mon, 5 May 2014 10:37:09 -0700 From: John-Mark Gurney To: Hans Petter Selasky Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined Message-ID: <20140505173709.GR43976@funkthat.com> Mail-Followup-To: Hans Petter Selasky , freebsd-arm@freebsd.org References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5362638B.1080104@selasky.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 05 May 2014 10:37:10 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:37:11 -0000 Hans Petter Selasky wrote this message on Thu, May 01, 2014 at 17:08 +0200: > On 05/01/14 01:34, Johny Mattsson wrote: > >On 1 May 2014 00:14, Ian Lepore wrote: > > > >>I was doing some testing on a wandboard (about twice as fast an an rpi) > >>with > >>more than 20k int/sec without having any problems. > >> > > > >On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k > >int/sec, on Linux. Admittedly at that point my shell wasn't what you'd call > >"responsive" however =) The ISR in that scenario was the GPIO handler, so > >probably a bit more light-weight than an audio ISR. > > Hi, > > I'll have a look and see if I can fix it. So, I have both a BBW and a BBB and both devices don't have working USB... If I plug in a device, like a uftdi serial adapter, the blue light flashes briefly but then stays off... It should stay on... Are you up for helping me debug it? I'm currently testing w/ the last BEAGLEBONE snapshot located at: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/ I'm interested in getting USB sound working on one of these. usbconfig: # usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) I do know one of the ports is not host, but a user port... Not sure how to fix this, or if this is because they are sharing an image between both BBW and BBB.... # uname -a FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265054: Tue Apr 29 09:45:24 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm relevant parts of dmesg: musbotg0: mem 0x47400000-0x47400fff,0x 47401000-0x474012ff,0x47401300-0x474013ff,0x47401400-0x474017ff,0x47401800-0x474 01aff,0x47401b00-0x47401bff,0x47401c00-0x47401fff irq 17,18,19 on simplebus0 musbotg0: TI AM335X USBSS v0.0.13 usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus0 on musbotg0 usbus1: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus1 on musbotg0 [...] Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon May 5 18:09:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52551FB3 for ; Mon, 5 May 2014 18:09:32 +0000 (UTC) Received: from server1.xenet.de (server1out.xenet.de [213.221.94.200]) by mx1.freebsd.org (Postfix) with ESMTP id B9013C3E for ; Mon, 5 May 2014 18:09:30 +0000 (UTC) Received: from [10.1.0.50] (tubercel-gate.xenet.de [213.221.94.54]) (authenticated bits=0) by server1.xenet.de (8.12.5/8.12.5) with ESMTP id s45I9PdC089710 for ; Mon, 5 May 2014 20:09:28 +0200 (CEST) (envelope-from meyser@xenet.de) Message-ID: <5367D3D0.9000405@xenet.de> Date: Mon, 05 May 2014 20:09:20 +0200 From: Matthias Meyser Organization: XeNET GmbH User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined References: <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <5367973F.20300@xenet.de> <5367A154.8010508@selasky.org> <20140505144704.GA78493@cicely7.cicely.de> <1399304088.22079.242.camel@revolution.hippie.lan> <20140505160842.GC78493@cicely7.cicely.de> In-Reply-To: <20140505160842.GC78493@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.38 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:09:32 -0000 Am 05.05.2014 18:08, schrieb Bernd Walter: > On Mon, May 05, 2014 at 09:34:48AM -0600, Ian Lepore wrote: >> On Mon, 2014-05-05 at 16:47 +0200, Bernd Walter wrote: >>> On Mon, May 05, 2014 at 04:33:56PM +0200, Hans Petter Selasky wrote: >>>> On 05/05/14 15:50, Matthias Meyser wrote: >>>>> >>>>> Am 02.05.2014 18:00, schrieb Hans Petter Selasky: >>>>>> On 05/01/14 17:08, Hans Petter Selasky wrote: >>>>>>> On 05/01/14 01:34, Johny Mattsson wrote: >>>>>>>> On 1 May 2014 00:14, Ian Lepore wrote: >>>>>>>> >>>>>>>>> I was doing some testing on a wandboard (about twice as fast an an >>>>>>>>> rpi) >>>>>>>>> with >>>>>>>>> more than 20k int/sec without having any problems. >>>>>>>>> >>>>>>>> >>>>>>>> On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k >>>>>>>> int/sec, on Linux. Admittedly at that point my shell wasn't what you'd >>>>>>>> call >>>>>>>> "responsive" however =) The ISR in that scenario was the GPIO >>>>>>>> handler, so >>>>>>>> probably a bit more light-weight than an audio ISR. >>>>>>> >>>>>>> I'll have a look and see if I can fix it. >>>>>> Here is a patch (work in progress) which you can try: >>>>>> http://home.selasky.org:8192/dwc_otg_isoc_support_wip.diff >>>>>> >>>>>> Still not working 100% reliable. Trying to figure out the last bits >>>>>> and pieces. >>>>> >>>>> For testing it would be very helful if someone could add >>>>> >>>>> device sound >>>>> device snd_uaudio >>>>> >>>>> to RPI-B kernel. >>>>> >>>>> Having this in BEAGLEBONE would be nice to. >>>>> Perhaps this schould go in every config that supports usb. >>>>> >>>> >>>> Hi, >>>> >>>> The following patch should make "devd" load sound.ko and snd_uaudio.ko >>>> automatically: >>>> >>>> http://svnweb.freebsd.org/changeset/base/265359 >>> >>> This won't work unless sound.ko especting ISA in ARM kernel is fixed >>> as well. >>> >> >> This shouldn't be a problem. The code that references isa stuff is >> wrapped in #ifdef DEV_ISA, and an arm kernel build won't have that >> defined. The problem was that the makefile for building a sound module >> created an opt_isa.h containing #define DEV_ISA when building for arm so >> the loadable sound modules had references to isa but the driver in the >> kernel didn't. > > Didn't test myself, but this thread started with a problem like this. For clarification. Modules would be fine. But no *sound* and *snd* Modules are build during normal buildworld/kernel or are not installed during installworld on arm/armv6. From owner-freebsd-arm@FreeBSD.ORG Mon May 5 18:27:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEFFF7B0 for ; Mon, 5 May 2014 18:27:37 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 456E6E2A for ; Mon, 5 May 2014 18:27:36 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s45IRSUS067015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 May 2014 20:27:28 +0200 (CEST) (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 s45IRN2W029961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2014 20:27:23 +0200 (CEST) (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 s45IRN62079513; Mon, 5 May 2014 20:27:23 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s45IRMLI079512; Mon, 5 May 2014 20:27:22 +0200 (CEST) (envelope-from ticso) Date: Mon, 5 May 2014 20:27:22 +0200 From: Bernd Walter To: Hans Petter Selasky , freebsd-arm@freebsd.org Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined Message-ID: <20140505182722.GD78493@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <20140505173709.GR43976@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140505173709.GR43976@funkthat.com> 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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:27:37 -0000 On Mon, May 05, 2014 at 10:37:09AM -0700, John-Mark Gurney wrote: > Hans Petter Selasky wrote this message on Thu, May 01, 2014 at 17:08 +0200: > > On 05/01/14 01:34, Johny Mattsson wrote: > > >On 1 May 2014 00:14, Ian Lepore wrote: > > > > > >>I was doing some testing on a wandboard (about twice as fast an an rpi) > > >>with > > >>more than 20k int/sec without having any problems. > > >> > > > > > >On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k > > >int/sec, on Linux. Admittedly at that point my shell wasn't what you'd call > > >"responsive" however =) The ISR in that scenario was the GPIO handler, so > > >probably a bit more light-weight than an audio ISR. > > > > Hi, > > > > I'll have a look and see if I can fix it. > > So, I have both a BBW and a BBB and both devices don't have working > USB... If I plug in a device, like a uftdi serial adapter, the blue > light flashes briefly but then stays off... It should stay on... AFAIK we don't switch any LED at all, so this probably is a power problem. What rating has your power supply? Do you use the barrel or USB plug to power the board? I think you need to use the barrel plug for additional load, since the board has some kind of current limitation for the USB connector. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon May 5 18:53:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6B7164B for ; Mon, 5 May 2014 18:53:06 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 91E2C1209 for ; Mon, 5 May 2014 18:53:05 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s45IquUu052328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2014 11:52:56 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s45Iquat052327; Mon, 5 May 2014 11:52:56 -0700 (PDT) (envelope-from jmg) Date: Mon, 5 May 2014 11:52:56 -0700 From: John-Mark Gurney To: ticso@cicely.de Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined Message-ID: <20140505185256.GU43976@funkthat.com> Mail-Followup-To: ticso@cicely.de, Hans Petter Selasky , freebsd-arm@freebsd.org References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <20140505173709.GR43976@funkthat.com> <20140505182722.GD78493@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140505182722.GD78493@cicely7.cicely.de> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 05 May 2014 11:52:56 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:53:06 -0000 Bernd Walter wrote this message on Mon, May 05, 2014 at 20:27 +0200: > On Mon, May 05, 2014 at 10:37:09AM -0700, John-Mark Gurney wrote: > > Hans Petter Selasky wrote this message on Thu, May 01, 2014 at 17:08 +0200: > > > On 05/01/14 01:34, Johny Mattsson wrote: > > > >On 1 May 2014 00:14, Ian Lepore wrote: > > > > > > > >>I was doing some testing on a wandboard (about twice as fast an an rpi) > > > >>with > > > >>more than 20k int/sec without having any problems. > > > >> > > > > > > > >On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k > > > >int/sec, on Linux. Admittedly at that point my shell wasn't what you'd call > > > >"responsive" however =) The ISR in that scenario was the GPIO handler, so > > > >probably a bit more light-weight than an audio ISR. > > > > > > Hi, > > > > > > I'll have a look and see if I can fix it. > > > > So, I have both a BBW and a BBB and both devices don't have working > > USB... If I plug in a device, like a uftdi serial adapter, the blue > > light flashes briefly but then stays off... It should stay on... > > AFAIK we don't switch any LED at all, so this probably is a power problem. > What rating has your power supply? 2A 5V.. > Do you use the barrel or USB plug to power the board? Yes... > I think you need to use the barrel plug for additional load, since > the board has some kind of current limitation for the USB connector. Oh, just decided to "eliminate" the power problem, and I pluged in a USB powered hub... This time the light stays on on the serial adapter, but neither the hub, nor the serial adapter is seen by the BBB... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon May 5 19:24:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58687C1E for ; Mon, 5 May 2014 19:24:29 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2802B5DE4 for ; Mon, 5 May 2014 19:24:28 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WhOV1-0008Mv-IJ; Mon, 05 May 2014 19:24:27 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s45JOOqs024057; Mon, 5 May 2014 13:24:24 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/IfNjCO2qZbnOGEuDZgoTM Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20140505182722.GD78493@cicely7.cicely.de> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <20140505173709.GR43976@funkthat.com> <20140505182722.GD78493@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Mon, 05 May 2014 13:24:24 -0600 Message-ID: <1399317864.22079.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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 19:24:29 -0000 On Mon, 2014-05-05 at 20:27 +0200, Bernd Walter wrote: > On Mon, May 05, 2014 at 10:37:09AM -0700, John-Mark Gurney wrote: > > Hans Petter Selasky wrote this message on Thu, May 01, 2014 at 17:08 +0200: > > > On 05/01/14 01:34, Johny Mattsson wrote: > > > >On 1 May 2014 00:14, Ian Lepore wrote: > > > > > > > >>I was doing some testing on a wandboard (about twice as fast an an rpi) > > > >>with > > > >>more than 20k int/sec without having any problems. > > > >> > > > > > > > >On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k > > > >int/sec, on Linux. Admittedly at that point my shell wasn't what you'd call > > > >"responsive" however =) The ISR in that scenario was the GPIO handler, so > > > >probably a bit more light-weight than an audio ISR. > > > > > > Hi, > > > > > > I'll have a look and see if I can fix it. > > > > So, I have both a BBW and a BBB and both devices don't have working > > USB... If I plug in a device, like a uftdi serial adapter, the blue > > light flashes briefly but then stays off... It should stay on... > > AFAIK we don't switch any LED at all, so this probably is a power problem. > What rating has your power supply? > Do you use the barrel or USB plug to power the board? > I think you need to use the barrel plug for additional load, since > the board has some kind of current limitation for the USB connector. > That LED behavior is the FDTI adapter hardware. Depending on how you wire them, you can get several behaviors out of FTDI LEDs. If you wired an LED to the PWREN# it would behave like that if the host system told the hub to shutdown port power. I had such a problem with the new FTDI H-series chips once, because their device descriptor says they need up to 150mA (although in normal uart modes they never draw anywhere near that). I was plugging them into a bus-powered hub and it would power up, read the descriptor, and power right back down. When I plugged the hub's power adapter in it started working fine. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon May 5 21:59:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD7A11F3 for ; Mon, 5 May 2014 21:59:37 +0000 (UTC) Received: from feith1.FEITH.COM (feith1.FEITH.COM [192.251.93.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94427AA8 for ; Mon, 5 May 2014 21:59:36 +0000 (UTC) Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.14.5+Sun/8.12.9) with ESMTP id s45LxUfb024558; Mon, 5 May 2014 17:59:30 -0400 (EDT) (envelope-from john@jwlab.FEITH.COM) Received: from jwlab.FEITH.COM (localhost [127.0.0.1]) by jwlab.FEITH.COM (8.14.5+Sun/8.14.5) with ESMTP id s45LxUgo015118; Mon, 5 May 2014 17:59:30 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.14.5+Sun/8.14.5/Submit) id s45LxTaK015117; Mon, 5 May 2014 17:59:29 -0400 (EDT) Date: Mon, 5 May 2014 17:59:29 -0400 (EDT) From: John Wehle Message-Id: <201405052159.s45LxTaK015117@jwlab.FEITH.COM> To: naoki@fukaumi.org Subject: Re: Amlogic aml8726-m3 / aml8726-m6 SoC status MIME-Version: 1.0 Content-Type: text/plain X-DCC-x.dcc-servers-Metrics: feith1; whitelist X-Scanned-By: MIMEDefang 2.67 on 192.251.93.1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 21:59:37 -0000 > what is your main target device? My current development box I purchased from ebay and came without any reliable information regarding the actual make / model. However it appears to be a Visson Tech ATV-102 ... the original Visson specs say aml8726-m3, however my actual unit behaves as if contains the aml8726-m6 (the RTC is slightly different between the m3 and the m6). Some info is at: http://www.vissontech.com/products_detail2/&productId=2677621d-8771-4d59-9722-42cb55d19e1f&comp_stats=comp-FrontProducts_list01-1337323367416.html I have two other Amlogic units from different manufacturers which I'll use for additional testing once I'm happy on the ATV-102. >> Ethernet (it seems like the hardware is actually a DesignWare Core >> so this driver may be useful for supporting other SoC). > > is it same as this one? > https://www.kernel.org/doc/Documentation/networking/stmmac.txt Nothing I've seen references STMicroelectronics, however the register information in the Amlogic linux driver seems to line up with some other documentation I have for the DesignWare Core Ethernet MAC. > then, it can be used for Allwinner A20 :) Quite possibly. >> Look at supporting flash memory. > > I think it's not open, there is a binary blob in Linux kernel... I haven't looked at it yet, so I don't know. Amlogic has supplied some information upon request regarding other things ... we'll see what happens when I start working on the flash memory support. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From owner-freebsd-arm@FreeBSD.ORG Mon May 5 22:58:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7544D14 for ; Mon, 5 May 2014 22:58:12 +0000 (UTC) Received: from mail.naobsd.org (7c294571.i-revonet.jp [124.41.69.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 420D7EA2 for ; Mon, 5 May 2014 22:58:11 +0000 (UTC) Received: from [192.168.1.149] ([192.168.1.149]) (authenticated bits=0) by mail.naobsd.org (8.13.6.20060614/8.13.6) with ESMTP id s45Mw1TR021606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 6 May 2014 07:58:02 +0900 (JST) Message-ID: <53681779.6070303@naobsd.org> Date: Tue, 06 May 2014 07:58:01 +0900 From: FUKAUMI Naoki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Wehle Subject: Re: Amlogic aml8726-m3 / aml8726-m6 SoC status References: <201405052159.s45LxTaK015117@jwlab.FEITH.COM> In-Reply-To: <201405052159.s45LxTaK015117@jwlab.FEITH.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 22:58:12 -0000 hi On 05/06/2014 06:59 AM, John Wehle wrote: >>> Ethernet (it seems like the hardware is actually a DesignWare Core >>> so this driver may be useful for supporting other SoC). >> >> is it same as this one? >> https://www.kernel.org/doc/Documentation/networking/stmmac.txt > > Nothing I've seen references STMicroelectronics, however the register > information in the Amlogic linux driver seems to line up with some other > documentation I have for the DesignWare Core Ethernet MAC. ah, sorry, what I pointed was about "DWC Ether MAC driver" in Linux mainline. I don't have any document about amlogic SoC other than Linux/u-boot code on amlogic's site. I just compared 2 Linux driver. >>> Look at supporting flash memory. >> >> I think it's not open, there is a binary blob in Linux kernel... > > I haven't looked at it yet, so I don't know. Amlogic has supplied > some information upon request regarding other things ... we'll see > what happens when I start working on the flash memory support. nice, I didn't know amlogic answers request ;) I have a aml8726-m1 box and a aml8726-m1 tablet. do you have any information about m1? -- http://androtab.info/ From owner-freebsd-arm@FreeBSD.ORG Mon May 5 23:40:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6BF26D2 for ; Mon, 5 May 2014 23:40:53 +0000 (UTC) Received: from feith1.FEITH.COM (feith1.FEITH.COM [192.251.93.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D41C1FD for ; Mon, 5 May 2014 23:40:53 +0000 (UTC) Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.14.5+Sun/8.12.9) with ESMTP id s45Nem5p027279; Mon, 5 May 2014 19:40:48 -0400 (EDT) (envelope-from john@jwlab.FEITH.COM) Received: from jwlab.FEITH.COM (localhost [127.0.0.1]) by jwlab.FEITH.COM (8.14.5+Sun/8.14.5) with ESMTP id s45Nemxm015291; Mon, 5 May 2014 19:40:48 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.14.5+Sun/8.14.5/Submit) id s45Nem4o015290; Mon, 5 May 2014 19:40:48 -0400 (EDT) Date: Mon, 5 May 2014 19:40:48 -0400 (EDT) From: John Wehle Message-Id: <201405052340.s45Nem4o015290@jwlab.FEITH.COM> To: fun@naobsd.org Subject: Re: Amlogic aml8726-m3 / aml8726-m6 SoC status MIME-Version: 1.0 Content-Type: text/plain X-DCC--Metrics: feith1; whitelist X-Scanned-By: MIMEDefang 2.67 on 192.251.93.1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 23:40:53 -0000 > I have a aml8726-m1 box and a aml8726-m1 tablet. do you have any > information about m1? Some. I do not have / plan on testing on aml8726-m1, however others are certainly welcomed to give it a go. Much of the code I've implemented should also work for the aml8726-m1. In some cases (e.g. the RTC driver) I've included additional configuration flexibility which should support the m1, in other cases (e.g. the UART driver) no additional effort appeared necessary. I'll note that the USB phy changed a bit between the m1 and the later chips ... the current code doesn't attempt to accommodate the m1 flavor (though it's probably easy enough to add the necessary support). -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From owner-freebsd-arm@FreeBSD.ORG Tue May 6 00:30:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5625CE56 for ; Tue, 6 May 2014 00:30:13 +0000 (UTC) Received: from mail.naobsd.org (7c294571.i-revonet.jp [124.41.69.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A81A7D7 for ; Tue, 6 May 2014 00:30:12 +0000 (UTC) Received: from [192.168.1.149] ([192.168.1.149]) (authenticated bits=0) by mail.naobsd.org (8.13.6.20060614/8.13.6) with ESMTP id s460U52p013553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 6 May 2014 09:30:06 +0900 (JST) Message-ID: <53682D0D.20008@naobsd.org> Date: Tue, 06 May 2014 09:30:05 +0900 From: FUKAUMI Naoki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Wehle Subject: Re: Amlogic aml8726-m3 / aml8726-m6 SoC status References: <201405052340.s45Nem4o015290@jwlab.FEITH.COM> In-Reply-To: <201405052340.s45Nem4o015290@jwlab.FEITH.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 00:30:13 -0000 hi On 05/06/2014 08:40 AM, John Wehle wrote: >> I have a aml8726-m1 box and a aml8726-m1 tablet. do you have any >> information about m1? > > Some. > > I do not have / plan on testing on aml8726-m1, however others are > certainly welcomed to give it a go. > > Much of the code I've implemented should also work for the aml8726-m1. > In some cases (e.g. the RTC driver) I've included additional configuration > flexibility which should support the m1, in other cases (e.g. the UART driver) > no additional effort appeared necessary. I'll note that the USB phy > changed a bit between the m1 and the later chips ... the current code > doesn't attempt to accommodate the m1 flavor (though it's probably > easy enough to add the necessary support). very good, it's worth a try :) -- http://androtab.info/ From owner-freebsd-arm@FreeBSD.ORG Tue May 6 01:36:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2691C4BE; Tue, 6 May 2014 01:36:37 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C6106C65; Tue, 6 May 2014 01:36:36 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s461aRxs070792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 May 2014 03:36:28 +0200 (CEST) (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 s461aMU6038517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2014 03:36:22 +0200 (CEST) (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 s461aMUT081845; Tue, 6 May 2014 03:36:22 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s461aMqu081844; Tue, 6 May 2014 03:36:22 +0200 (CEST) (envelope-from ticso) Date: Tue, 6 May 2014 03:36:22 +0200 From: Bernd Walter To: Ian Lepore Subject: Re: USB audio device on Raspberry Pi - link_elf: symbol isa_dmastatus undefined Message-ID: <20140506013622.GA81784@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <20140505173709.GR43976@funkthat.com> <20140505182722.GD78493@cicely7.cicely.de> <1399317864.22079.260.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1399317864.22079.260.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 01:36:37 -0000 On Mon, May 05, 2014 at 01:24:24PM -0600, Ian Lepore wrote: > On Mon, 2014-05-05 at 20:27 +0200, Bernd Walter wrote: > > On Mon, May 05, 2014 at 10:37:09AM -0700, John-Mark Gurney wrote: > > > Hans Petter Selasky wrote this message on Thu, May 01, 2014 at 17:08 +0200: > > > > On 05/01/14 01:34, Johny Mattsson wrote: > > > > >On 1 May 2014 00:14, Ian Lepore wrote: > > > > > > > > > >>I was doing some testing on a wandboard (about twice as fast an an rpi) > > > > >>with > > > > >>more than 20k int/sec without having any problems. > > > > >> > > > > > > > > > >On a similar note, I've pushed an i.MX 283 (400MHz) board to above 300k > > > > >int/sec, on Linux. Admittedly at that point my shell wasn't what you'd call > > > > >"responsive" however =) The ISR in that scenario was the GPIO handler, so > > > > >probably a bit more light-weight than an audio ISR. > > > > > > > > Hi, > > > > > > > > I'll have a look and see if I can fix it. > > > > > > So, I have both a BBW and a BBB and both devices don't have working > > > USB... If I plug in a device, like a uftdi serial adapter, the blue > > > light flashes briefly but then stays off... It should stay on... > > > > AFAIK we don't switch any LED at all, so this probably is a power problem. > > What rating has your power supply? > > Do you use the barrel or USB plug to power the board? > > I think you need to use the barrel plug for additional load, since > > the board has some kind of current limitation for the USB connector. > > > > That LED behavior is the FDTI adapter hardware. Depending on how you > wire them, you can get several behaviors out of FTDI LEDs. If you wired > an LED to the PWREN# it would behave like that if the host system told > the hub to shutdown port power. I had such a problem with the new FTDI > H-series chips once, because their device descriptor says they need up > to 150mA (although in normal uart modes they never draw anywhere near > that). I was plugging them into a bus-powered hub and it would power > up, read the descriptor, and power right back down. When I plugged the > hub's power adapter in it started working fine. Oh - I wasn't thinking about blue LED to be something on the FTDI device, because I thought it to be gerneric uftdi. About the PWREN behavour you describe, there is something wrong as well. If your device claims 150mA - at least according to descriptor - and the OS says no to 150mA. then why is the PWREN enabled at all? It should stay down, because PWREN primary use is not to drive a LED, but to drive power to auxillary logic after the host give his OK. For example in one of my devices with 12V signals I use PWREN to activate the 5V to 12V DC-DC converter. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue May 6 09:19:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EA46145; Tue, 6 May 2014 09:19:03 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45E48969; Tue, 6 May 2014 09:19:02 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 56CD31FE029; Tue, 6 May 2014 11:19:00 +0200 (CEST) Message-ID: <5368A93D.3070608@selasky.org> Date: Tue, 06 May 2014 11:19:57 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd , Ian Lepore Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 09:19:03 -0000 On 05/05/14 17:51, Adrian Chadd wrote: > On 5 May 2014 08:35, Ian Lepore wrote: > >> Oh never mind, I just noticed you said KTR, not printf. > > Heh. > > That's why I like KTR. > > I bet some devices dislike you doing the "read registers all the time" > dance. Espeically if they're on an ISA bus where it's really expensive > to do things. But yes, your point is pretty spot on. > Hi, I've made another patch to reduce the number of interrupts generated by the DWC OTG in host mode: http://svnweb.freebsd.org/changeset/base/265427 Still it is loosing service intervals at fixed rate 8K/second. I added to DELAY(): if (!cold) return; It made no difference. I also tried to set INTR_PRIO_TTY instead of XXX_BIO. No difference either. I'll do some more checking later today. --HPS From owner-freebsd-arm@FreeBSD.ORG Tue May 6 09:30:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B714A529; Tue, 6 May 2014 09:30:52 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73A0BA4B; Tue, 6 May 2014 09:30:52 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A53F01FE029; Tue, 6 May 2014 11:30:50 +0200 (CEST) Message-ID: <5368AC03.8080401@selasky.org> Date: Tue, 06 May 2014 11:31:47 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd , Ian Lepore Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> In-Reply-To: <5368A93D.3070608@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 09:30:52 -0000 On 05/06/14 11:19, Hans Petter Selasky wrote: > > I also tried to set INTR_PRIO_TTY instead of XXX_BIO. ^^^ INTR_TYPE_TTY --HPS From owner-freebsd-arm@FreeBSD.ORG Tue May 6 10:11:00 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E342377; Tue, 6 May 2014 10:11:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60EB1DEE; Tue, 6 May 2014 10:11:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46AArCX093766; Tue, 6 May 2014 06:10:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46AArOQ093764; Tue, 6 May 2014 10:10:53 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 10:10:53 GMT Message-Id: <201405061010.s46AArOQ093764@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 10:11:00 -0000 TB --- 2014-05-06 10:10:47 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 10:10:47 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 10:10:47 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 10:10:47 - cleaning the object tree TB --- 2014-05-06 10:10:47 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 10:10:52 - At svn revision 265431 TB --- 2014-05-06 10:10:53 - building world TB --- 2014-05-06 10:10:53 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 10:10:53 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 10:10:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 10:10:53 - SRCCONF=/dev/null TB --- 2014-05-06 10:10:53 - TARGET=arm TB --- 2014-05-06 10:10:53 - TARGET_ARCH=arm TB --- 2014-05-06 10:10:53 - TZ=UTC TB --- 2014-05-06 10:10:53 - __MAKE_CONF=/dev/null TB --- 2014-05-06 10:10:53 - cd /src TB --- 2014-05-06 10:10:53 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 10:10:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 10:10:53 - ERROR: failed to build world TB --- 2014-05-06 10:10:53 - 1.65 user 3.01 system 5.78 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 10:20:26 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3DB164C; Tue, 6 May 2014 10:20:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D674F05; Tue, 6 May 2014 10:20:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46AKP4b094091; Tue, 6 May 2014 06:20:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46AKPAa094087; Tue, 6 May 2014 10:20:25 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 10:20:25 GMT Message-Id: <201405061020.s46AKPAa094087@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 10:20:26 -0000 TB --- 2014-05-06 10:20:19 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 10:20:19 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 10:20:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 10:20:19 - cleaning the object tree TB --- 2014-05-06 10:20:19 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 10:20:24 - At svn revision 265431 TB --- 2014-05-06 10:20:25 - building world TB --- 2014-05-06 10:20:25 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 10:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 10:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 10:20:25 - SRCCONF=/dev/null TB --- 2014-05-06 10:20:25 - TARGET=arm TB --- 2014-05-06 10:20:25 - TARGET_ARCH=arm TB --- 2014-05-06 10:20:25 - TZ=UTC TB --- 2014-05-06 10:20:25 - __MAKE_CONF=/dev/null TB --- 2014-05-06 10:20:25 - cd /src TB --- 2014-05-06 10:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 10:20:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 10:20:25 - ERROR: failed to build world TB --- 2014-05-06 10:20:25 - 1.66 user 3.00 system 5.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 10:30:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30A2868F; Tue, 6 May 2014 10:30:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5BE87C; Tue, 6 May 2014 10:30:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46AUN5B094414; Tue, 6 May 2014 06:30:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46AUN8W094364; Tue, 6 May 2014 10:30:23 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 10:30:23 GMT Message-Id: <201405061030.s46AUN8W094364@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 10:30:25 -0000 TB --- 2014-05-06 10:30:17 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 10:30:17 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 10:30:17 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 10:30:17 - cleaning the object tree TB --- 2014-05-06 10:30:17 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 10:30:22 - At svn revision 265431 TB --- 2014-05-06 10:30:23 - building world TB --- 2014-05-06 10:30:23 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 10:30:23 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 10:30:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 10:30:23 - SRCCONF=/dev/null TB --- 2014-05-06 10:30:23 - TARGET=arm TB --- 2014-05-06 10:30:23 - TARGET_ARCH=arm TB --- 2014-05-06 10:30:23 - TZ=UTC TB --- 2014-05-06 10:30:23 - __MAKE_CONF=/dev/null TB --- 2014-05-06 10:30:23 - cd /src TB --- 2014-05-06 10:30:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 10:30:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 10:30:23 - ERROR: failed to build world TB --- 2014-05-06 10:30:23 - 1.67 user 2.97 system 5.66 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 10:39:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E28F95B4 for ; Tue, 6 May 2014 10:39:05 +0000 (UTC) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD5A2198 for ; Tue, 6 May 2014 10:39:05 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rd18so9554227iec.1 for ; Tue, 06 May 2014 03:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ranahminang.net; s=padang; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kvuSjiqe6QVt0wGNfKV9abxR+5aAWgBokFZmgexkxFE=; b=aB0Fze6VYqHK+zhobLkJdvIwurm7Xd8nBjRLv3fIyzyC734fwWK65Ykl5cfnYKVWw4 fN9qB3NhSFqVDqr2XOdcTpAsKFqiCS0zMqLX7b7vGqzpnnyC6jrh8kjl8Qirtw51avwW xPBUNYklsiKdYWKP8YL3Uw0eIk2+d6Tb3Kyd4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=kvuSjiqe6QVt0wGNfKV9abxR+5aAWgBokFZmgexkxFE=; b=OfY9jW0IMLOgJRf3EoAWAJfRieJVSskRXdiRAwX06emFqicHGufN9eZZWyqByirYVR Jo8FLven560zOS6iTixIi1WLqLVvNUhNifU+QmicQBs4bG29MIS8tZSt5eN/AICdRgj4 wLts8cYlDEQyVc7Wgj1mZwuNNZK/s//9JzEgxvgt7sOEBQd6MEh38RWaMxY2kTHAGDuL HBzClfftbtRKxSXA8Z79KiuHit8376raclz6ReMNsmUCkZDBtnLCvaERqdJPf/Y+2KFs REGUXFAygvOvlP7zQvn0zreOqTD3kLqD3F1bA+dM+DnP7XuFyKzVz9ze93U9NiAV25lo 4Sww== X-Gm-Message-State: ALoCoQkZrOGkgkfuWSqIzxv9mJ39y+7T+XmSgOJOHkkbA1ZO7Ra32SpfKoQnnolIA4flM1g6puxu MIME-Version: 1.0 X-Received: by 10.42.39.138 with SMTP id h10mr373227ice.92.1399372744885; Tue, 06 May 2014 03:39:04 -0700 (PDT) Received: by 10.64.6.168 with HTTP; Tue, 6 May 2014 03:39:04 -0700 (PDT) X-Originating-IP: [36.68.47.185] In-Reply-To: <20140505170856.GQ43976@funkthat.com> References: <20140505170856.GQ43976@funkthat.com> Date: Tue, 6 May 2014 17:39:04 +0700 Message-ID: Subject: Re: partition resize From: Paul Darius To: Paul Darius , freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 10:39:06 -0000 Tq for the advices... i will try your suggestion as soon as i get the new sd card as the current sdcard (toshiba class 10) always give me error 19 on every startup. P On 5/6/14, John-Mark Gurney wrote: > Paul Darius wrote this message on Sat, May 03, 2014 at 15:10 +0700: >> hi there.. >> >> here is the partition created from the fbsd image >> >> $ gpart show >> => 63 61497281 mmcsd0 MBR (29G) >> 63 34776 1 !12 [active] (17M) >> 34839 61462485 2 freebsd (29G) >> 61497324 20 - free - (10K) >> >> => 0 1918278 mmcsd0s2 BSD (29G) >> 0 1918278 1 freebsd-ufs (937M) > > This partition didn't grow for some reason... > gpart resize -i 1 mmcsd0s2 > > Should grow it... > >> $ cat /etc/fstab >> /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 >> /dev/mmcsd0s2a / ufs rw,noatime 1 1 >> md /tmp mfs rw,noatime,-s30m 0 0 >> md /var/log mfs rw,noatime,-s15m 0 0 >> md /var/tmp mfs rw,noatime,-s5m 0 0 >> >> when I do extract the ports.tar.gz into /usr, I end up with file system >> full >> >> how do i know which partition for what and how to resize them ? >> >> the /etc/rc.d/autosize start give the result : >> # /etc/rc.d/autosize start >> Enlarging root partition >> mmcsd0s2 resized >> gpart: autofill: No space left on device >> growfs: requested size 937MB is not larger than the current filesystem >> size 937MB > > I just recently rewrote crochet's autosize/growfs rc.d script to be > able to handle any partitioning scheme to grow /... You could try the > attached... just run: "growfs start" and it should run all the necesssary > commands... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-arm@FreeBSD.ORG Tue May 6 10:40:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 122AC603; Tue, 6 May 2014 10:40:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF06D209; Tue, 6 May 2014 10:40:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46AeNBm094752; Tue, 6 May 2014 06:40:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46AeN11094749; Tue, 6 May 2014 10:40:23 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 10:40:23 GMT Message-Id: <201405061040.s46AeN11094749@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 10:40:25 -0000 TB --- 2014-05-06 10:40:17 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 10:40:17 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 10:40:17 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 10:40:17 - cleaning the object tree TB --- 2014-05-06 10:40:17 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 10:40:22 - At svn revision 265431 TB --- 2014-05-06 10:40:23 - building world TB --- 2014-05-06 10:40:23 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 10:40:23 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 10:40:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 10:40:23 - SRCCONF=/dev/null TB --- 2014-05-06 10:40:23 - TARGET=arm TB --- 2014-05-06 10:40:23 - TARGET_ARCH=arm TB --- 2014-05-06 10:40:23 - TZ=UTC TB --- 2014-05-06 10:40:23 - __MAKE_CONF=/dev/null TB --- 2014-05-06 10:40:23 - cd /src TB --- 2014-05-06 10:40:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 10:40:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 10:40:23 - ERROR: failed to build world TB --- 2014-05-06 10:40:23 - 1.67 user 3.02 system 5.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 10:50:24 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBF6D92A; Tue, 6 May 2014 10:50:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8529B2D5; Tue, 6 May 2014 10:50:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46AoN2f095078; Tue, 6 May 2014 06:50:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46AoN4b095074; Tue, 6 May 2014 10:50:23 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 10:50:23 GMT Message-Id: <201405061050.s46AoN4b095074@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 10:50:24 -0000 TB --- 2014-05-06 10:50:17 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 10:50:17 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 10:50:17 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 10:50:17 - cleaning the object tree TB --- 2014-05-06 10:50:17 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 10:50:22 - At svn revision 265431 TB --- 2014-05-06 10:50:23 - building world TB --- 2014-05-06 10:50:23 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 10:50:23 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 10:50:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 10:50:23 - SRCCONF=/dev/null TB --- 2014-05-06 10:50:23 - TARGET=arm TB --- 2014-05-06 10:50:23 - TARGET_ARCH=arm TB --- 2014-05-06 10:50:23 - TZ=UTC TB --- 2014-05-06 10:50:23 - __MAKE_CONF=/dev/null TB --- 2014-05-06 10:50:23 - cd /src TB --- 2014-05-06 10:50:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 10:50:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 10:50:23 - ERROR: failed to build world TB --- 2014-05-06 10:50:23 - 1.59 user 3.09 system 5.72 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 11:00:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C48FD94D; Tue, 6 May 2014 11:00:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D65C5F7; Tue, 6 May 2014 11:00:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46B0OaN095419; Tue, 6 May 2014 07:00:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46B0OBC095415; Tue, 6 May 2014 11:00:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 11:00:24 GMT Message-Id: <201405061100.s46B0OBC095415@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 11:00:25 -0000 TB --- 2014-05-06 11:00:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 11:00:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 11:00:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 11:00:18 - cleaning the object tree TB --- 2014-05-06 11:00:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 11:00:23 - At svn revision 265432 TB --- 2014-05-06 11:00:24 - building world TB --- 2014-05-06 11:00:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 11:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 11:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 11:00:24 - SRCCONF=/dev/null TB --- 2014-05-06 11:00:24 - TARGET=arm TB --- 2014-05-06 11:00:24 - TARGET_ARCH=arm TB --- 2014-05-06 11:00:24 - TZ=UTC TB --- 2014-05-06 11:00:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 11:00:24 - cd /src TB --- 2014-05-06 11:00:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 11:00:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 11:00:24 - ERROR: failed to build world TB --- 2014-05-06 11:00:24 - 1.84 user 2.88 system 5.74 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 11:10:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5975293B; Tue, 6 May 2014 11:10:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21F9E843; Tue, 6 May 2014 11:10:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46BANAG095709; Tue, 6 May 2014 07:10:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46BANeO095683; Tue, 6 May 2014 11:10:23 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 11:10:23 GMT Message-Id: <201405061110.s46BANeO095683@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 11:10:25 -0000 TB --- 2014-05-06 11:10:17 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 11:10:17 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 11:10:17 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 11:10:17 - cleaning the object tree TB --- 2014-05-06 11:10:17 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 11:10:22 - At svn revision 265432 TB --- 2014-05-06 11:10:23 - building world TB --- 2014-05-06 11:10:23 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 11:10:23 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 11:10:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 11:10:23 - SRCCONF=/dev/null TB --- 2014-05-06 11:10:23 - TARGET=arm TB --- 2014-05-06 11:10:23 - TARGET_ARCH=arm TB --- 2014-05-06 11:10:23 - TZ=UTC TB --- 2014-05-06 11:10:23 - __MAKE_CONF=/dev/null TB --- 2014-05-06 11:10:23 - cd /src TB --- 2014-05-06 11:10:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 11:10:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 11:10:23 - ERROR: failed to build world TB --- 2014-05-06 11:10:23 - 1.75 user 2.87 system 5.63 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 11:20:28 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4743BBC8; Tue, 6 May 2014 11:20:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D224924; Tue, 6 May 2014 11:20:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46BKQD2096068; Tue, 6 May 2014 07:20:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46BKQ37096065; Tue, 6 May 2014 11:20:26 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 11:20:26 GMT Message-Id: <201405061120.s46BKQ37096065@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 11:20:28 -0000 TB --- 2014-05-06 11:20:20 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 11:20:20 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 11:20:20 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 11:20:20 - cleaning the object tree TB --- 2014-05-06 11:20:20 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 11:20:25 - At svn revision 265433 TB --- 2014-05-06 11:20:26 - building world TB --- 2014-05-06 11:20:26 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 11:20:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 11:20:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 11:20:26 - SRCCONF=/dev/null TB --- 2014-05-06 11:20:26 - TARGET=arm TB --- 2014-05-06 11:20:26 - TARGET_ARCH=arm TB --- 2014-05-06 11:20:26 - TZ=UTC TB --- 2014-05-06 11:20:26 - __MAKE_CONF=/dev/null TB --- 2014-05-06 11:20:26 - cd /src TB --- 2014-05-06 11:20:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 11:20:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 11:20:26 - ERROR: failed to build world TB --- 2014-05-06 11:20:26 - 1.60 user 3.09 system 5.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 11:30:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB411C6F; Tue, 6 May 2014 11:30:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8503AA68; Tue, 6 May 2014 11:30:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46BUOeb096396; Tue, 6 May 2014 07:30:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46BUO7F096392; Tue, 6 May 2014 11:30:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 11:30:24 GMT Message-Id: <201405061130.s46BUO7F096392@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 11:30:25 -0000 TB --- 2014-05-06 11:30:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 11:30:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 11:30:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 11:30:18 - cleaning the object tree TB --- 2014-05-06 11:30:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 11:30:23 - At svn revision 265433 TB --- 2014-05-06 11:30:24 - building world TB --- 2014-05-06 11:30:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 11:30:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 11:30:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 11:30:24 - SRCCONF=/dev/null TB --- 2014-05-06 11:30:24 - TARGET=arm TB --- 2014-05-06 11:30:24 - TARGET_ARCH=arm TB --- 2014-05-06 11:30:24 - TZ=UTC TB --- 2014-05-06 11:30:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 11:30:24 - cd /src TB --- 2014-05-06 11:30:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 11:30:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 11:30:24 - ERROR: failed to build world TB --- 2014-05-06 11:30:24 - 1.58 user 3.09 system 5.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 11:40:26 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10098E38; Tue, 6 May 2014 11:40:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD394B8E; Tue, 6 May 2014 11:40:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46BeOEI096726; Tue, 6 May 2014 07:40:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46BeO3Q096723; Tue, 6 May 2014 11:40:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 11:40:24 GMT Message-Id: <201405061140.s46BeO3Q096723@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 11:40:26 -0000 TB --- 2014-05-06 11:40:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 11:40:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 11:40:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 11:40:18 - cleaning the object tree TB --- 2014-05-06 11:40:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 11:40:23 - At svn revision 265433 TB --- 2014-05-06 11:40:24 - building world TB --- 2014-05-06 11:40:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 11:40:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 11:40:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 11:40:24 - SRCCONF=/dev/null TB --- 2014-05-06 11:40:24 - TARGET=arm TB --- 2014-05-06 11:40:24 - TARGET_ARCH=arm TB --- 2014-05-06 11:40:24 - TZ=UTC TB --- 2014-05-06 11:40:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 11:40:24 - cd /src TB --- 2014-05-06 11:40:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 11:40:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 11:40:24 - ERROR: failed to build world TB --- 2014-05-06 11:40:24 - 1.58 user 3.09 system 5.72 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 11:50:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B17FC309; Tue, 6 May 2014 11:50:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AF22D59; Tue, 6 May 2014 11:50:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46BoOjl097052; Tue, 6 May 2014 07:50:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46BoOqD097048; Tue, 6 May 2014 11:50:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 11:50:24 GMT Message-Id: <201405061150.s46BoOqD097048@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 11:50:25 -0000 TB --- 2014-05-06 11:50:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 11:50:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 11:50:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 11:50:18 - cleaning the object tree TB --- 2014-05-06 11:50:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 11:50:23 - At svn revision 265433 TB --- 2014-05-06 11:50:24 - building world TB --- 2014-05-06 11:50:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 11:50:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 11:50:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 11:50:24 - SRCCONF=/dev/null TB --- 2014-05-06 11:50:24 - TARGET=arm TB --- 2014-05-06 11:50:24 - TARGET_ARCH=arm TB --- 2014-05-06 11:50:24 - TZ=UTC TB --- 2014-05-06 11:50:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 11:50:24 - cd /src TB --- 2014-05-06 11:50:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 11:50:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 11:50:24 - ERROR: failed to build world TB --- 2014-05-06 11:50:24 - 1.72 user 2.95 system 5.69 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 12:00:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 903CD563; Tue, 6 May 2014 12:00:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5927FE58; Tue, 6 May 2014 12:00:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46C0OsV097340; Tue, 6 May 2014 08:00:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46C0OXH097339; Tue, 6 May 2014 12:00:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 12:00:24 GMT Message-Id: <201405061200.s46C0OXH097339@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:00:25 -0000 TB --- 2014-05-06 12:00:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 12:00:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 12:00:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 12:00:18 - cleaning the object tree TB --- 2014-05-06 12:00:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 12:00:23 - At svn revision 265433 TB --- 2014-05-06 12:00:24 - building world TB --- 2014-05-06 12:00:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 12:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 12:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 12:00:24 - SRCCONF=/dev/null TB --- 2014-05-06 12:00:24 - TARGET=arm TB --- 2014-05-06 12:00:24 - TARGET_ARCH=arm TB --- 2014-05-06 12:00:24 - TZ=UTC TB --- 2014-05-06 12:00:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 12:00:24 - cd /src TB --- 2014-05-06 12:00:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 12:00:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 12:00:24 - ERROR: failed to build world TB --- 2014-05-06 12:00:24 - 1.62 user 2.91 system 5.54 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 12:10:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6828510; Tue, 6 May 2014 12:10:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFF7DFD5; Tue, 6 May 2014 12:10:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46CAON6097716; Tue, 6 May 2014 08:10:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46CAOub097713; Tue, 6 May 2014 12:10:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 12:10:24 GMT Message-Id: <201405061210.s46CAOub097713@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:10:26 -0000 TB --- 2014-05-06 12:10:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 12:10:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 12:10:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 12:10:18 - cleaning the object tree TB --- 2014-05-06 12:10:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 12:10:23 - At svn revision 265433 TB --- 2014-05-06 12:10:24 - building world TB --- 2014-05-06 12:10:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 12:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 12:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 12:10:24 - SRCCONF=/dev/null TB --- 2014-05-06 12:10:24 - TARGET=arm TB --- 2014-05-06 12:10:24 - TARGET_ARCH=arm TB --- 2014-05-06 12:10:24 - TZ=UTC TB --- 2014-05-06 12:10:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 12:10:24 - cd /src TB --- 2014-05-06 12:10:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 12:10:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 12:10:24 - ERROR: failed to build world TB --- 2014-05-06 12:10:24 - 1.55 user 3.13 system 5.72 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 12:20:27 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 397DF95B; Tue, 6 May 2014 12:20:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE99B1BB; Tue, 6 May 2014 12:20:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46CKPGw098041; Tue, 6 May 2014 08:20:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46CKPo8098037; Tue, 6 May 2014 12:20:25 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 12:20:25 GMT Message-Id: <201405061220.s46CKPo8098037@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:20:27 -0000 TB --- 2014-05-06 12:20:19 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 12:20:19 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 12:20:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 12:20:19 - cleaning the object tree TB --- 2014-05-06 12:20:19 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 12:20:24 - At svn revision 265435 TB --- 2014-05-06 12:20:25 - building world TB --- 2014-05-06 12:20:25 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 12:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 12:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 12:20:25 - SRCCONF=/dev/null TB --- 2014-05-06 12:20:25 - TARGET=arm TB --- 2014-05-06 12:20:25 - TARGET_ARCH=arm TB --- 2014-05-06 12:20:25 - TZ=UTC TB --- 2014-05-06 12:20:25 - __MAKE_CONF=/dev/null TB --- 2014-05-06 12:20:25 - cd /src TB --- 2014-05-06 12:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 12:20:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 12:20:25 - ERROR: failed to build world TB --- 2014-05-06 12:20:25 - 1.81 user 2.90 system 5.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 12:30:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE463BCB; Tue, 6 May 2014 12:30:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7D63306; Tue, 6 May 2014 12:30:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46CUOdq098369; Tue, 6 May 2014 08:30:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46CUOCq098364; Tue, 6 May 2014 12:30:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 12:30:24 GMT Message-Id: <201405061230.s46CUOCq098364@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:30:26 -0000 TB --- 2014-05-06 12:30:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 12:30:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 12:30:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 12:30:18 - cleaning the object tree TB --- 2014-05-06 12:30:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 12:30:23 - At svn revision 265435 TB --- 2014-05-06 12:30:24 - building world TB --- 2014-05-06 12:30:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 12:30:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 12:30:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 12:30:24 - SRCCONF=/dev/null TB --- 2014-05-06 12:30:24 - TARGET=arm TB --- 2014-05-06 12:30:24 - TARGET_ARCH=arm TB --- 2014-05-06 12:30:24 - TZ=UTC TB --- 2014-05-06 12:30:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 12:30:24 - cd /src TB --- 2014-05-06 12:30:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 12:30:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 12:30:24 - ERROR: failed to build world TB --- 2014-05-06 12:30:24 - 1.50 user 3.16 system 5.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 12:40:27 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C035E48A; Tue, 6 May 2014 12:40:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89D3C655; Tue, 6 May 2014 12:40:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46CeQsQ098704; Tue, 6 May 2014 08:40:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46CeQQx098697; Tue, 6 May 2014 12:40:26 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 12:40:26 GMT Message-Id: <201405061240.s46CeQQx098697@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:40:27 -0000 TB --- 2014-05-06 12:40:20 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 12:40:20 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 12:40:20 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 12:40:20 - cleaning the object tree TB --- 2014-05-06 12:40:20 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 12:40:25 - At svn revision 265439 TB --- 2014-05-06 12:40:26 - building world TB --- 2014-05-06 12:40:26 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 12:40:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 12:40:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 12:40:26 - SRCCONF=/dev/null TB --- 2014-05-06 12:40:26 - TARGET=arm TB --- 2014-05-06 12:40:26 - TARGET_ARCH=arm TB --- 2014-05-06 12:40:26 - TZ=UTC TB --- 2014-05-06 12:40:26 - __MAKE_CONF=/dev/null TB --- 2014-05-06 12:40:26 - cd /src TB --- 2014-05-06 12:40:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 12:40:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 12:40:26 - ERROR: failed to build world TB --- 2014-05-06 12:40:26 - 1.68 user 3.00 system 5.71 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 12:50:26 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3107C58B; Tue, 6 May 2014 12:50:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB7AC803; Tue, 6 May 2014 12:50:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46CoOnj099032; Tue, 6 May 2014 08:50:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46CoOK7099025; Tue, 6 May 2014 12:50:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 12:50:24 GMT Message-Id: <201405061250.s46CoOK7099025@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:50:26 -0000 TB --- 2014-05-06 12:50:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 12:50:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 12:50:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 12:50:18 - cleaning the object tree TB --- 2014-05-06 12:50:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 12:50:23 - At svn revision 265439 TB --- 2014-05-06 12:50:24 - building world TB --- 2014-05-06 12:50:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 12:50:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 12:50:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 12:50:24 - SRCCONF=/dev/null TB --- 2014-05-06 12:50:24 - TARGET=arm TB --- 2014-05-06 12:50:24 - TARGET_ARCH=arm TB --- 2014-05-06 12:50:24 - TZ=UTC TB --- 2014-05-06 12:50:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 12:50:24 - cd /src TB --- 2014-05-06 12:50:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 12:50:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 12:50:24 - ERROR: failed to build world TB --- 2014-05-06 12:50:24 - 1.67 user 2.99 system 5.69 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 13:00:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE6AA54F; Tue, 6 May 2014 13:00:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A51A6952; Tue, 6 May 2014 13:00:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46D0OTW099372; Tue, 6 May 2014 09:00:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46D0Onv099368; Tue, 6 May 2014 13:00:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 13:00:24 GMT Message-Id: <201405061300.s46D0Onv099368@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:00:26 -0000 TB --- 2014-05-06 13:00:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 13:00:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 13:00:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 13:00:18 - cleaning the object tree TB --- 2014-05-06 13:00:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 13:00:23 - At svn revision 265439 TB --- 2014-05-06 13:00:24 - building world TB --- 2014-05-06 13:00:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 13:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 13:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 13:00:24 - SRCCONF=/dev/null TB --- 2014-05-06 13:00:24 - TARGET=arm TB --- 2014-05-06 13:00:24 - TARGET_ARCH=arm TB --- 2014-05-06 13:00:24 - TZ=UTC TB --- 2014-05-06 13:00:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 13:00:24 - cd /src TB --- 2014-05-06 13:00:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 13:00:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 13:00:24 - ERROR: failed to build world TB --- 2014-05-06 13:00:24 - 1.66 user 3.02 system 5.71 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 13:10:26 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3404922; Tue, 6 May 2014 13:10:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B972DB17; Tue, 6 May 2014 13:10:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46DAOjM099689; Tue, 6 May 2014 09:10:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46DAOS2099685; Tue, 6 May 2014 13:10:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 13:10:24 GMT Message-Id: <201405061310.s46DAOS2099685@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:10:26 -0000 TB --- 2014-05-06 13:10:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 13:10:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 13:10:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 13:10:18 - cleaning the object tree TB --- 2014-05-06 13:10:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 13:10:23 - At svn revision 265439 TB --- 2014-05-06 13:10:24 - building world TB --- 2014-05-06 13:10:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 13:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 13:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 13:10:24 - SRCCONF=/dev/null TB --- 2014-05-06 13:10:24 - TARGET=arm TB --- 2014-05-06 13:10:24 - TARGET_ARCH=arm TB --- 2014-05-06 13:10:24 - TZ=UTC TB --- 2014-05-06 13:10:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 13:10:24 - cd /src TB --- 2014-05-06 13:10:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 13:10:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 13:10:24 - ERROR: failed to build world TB --- 2014-05-06 13:10:24 - 1.57 user 3.10 system 5.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 13:20:26 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A734ABB; Tue, 6 May 2014 13:20:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7BD7C3D; Tue, 6 May 2014 13:20:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46DKOMu000120; Tue, 6 May 2014 09:20:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46DKOa0000116; Tue, 6 May 2014 13:20:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 13:20:24 GMT Message-Id: <201405061320.s46DKOa0000116@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:20:26 -0000 TB --- 2014-05-06 13:20:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 13:20:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 13:20:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 13:20:18 - cleaning the object tree TB --- 2014-05-06 13:20:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 13:20:23 - At svn revision 265439 TB --- 2014-05-06 13:20:24 - building world TB --- 2014-05-06 13:20:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 13:20:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 13:20:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 13:20:24 - SRCCONF=/dev/null TB --- 2014-05-06 13:20:24 - TARGET=arm TB --- 2014-05-06 13:20:24 - TARGET_ARCH=arm TB --- 2014-05-06 13:20:24 - TZ=UTC TB --- 2014-05-06 13:20:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 13:20:24 - cd /src TB --- 2014-05-06 13:20:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 13:20:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 13:20:24 - ERROR: failed to build world TB --- 2014-05-06 13:20:24 - 1.48 user 3.20 system 5.72 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 13:30:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB8BEABC; Tue, 6 May 2014 13:30:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92D9AD92; Tue, 6 May 2014 13:30:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46DUOxZ000448; Tue, 6 May 2014 09:30:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46DUOYk000443; Tue, 6 May 2014 13:30:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 13:30:24 GMT Message-Id: <201405061330.s46DUOYk000443@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:30:25 -0000 TB --- 2014-05-06 13:30:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 13:30:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 13:30:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 13:30:18 - cleaning the object tree TB --- 2014-05-06 13:30:18 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 13:30:23 - At svn revision 265439 TB --- 2014-05-06 13:30:24 - building world TB --- 2014-05-06 13:30:24 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 13:30:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 13:30:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 13:30:24 - SRCCONF=/dev/null TB --- 2014-05-06 13:30:24 - TARGET=arm TB --- 2014-05-06 13:30:24 - TARGET_ARCH=arm TB --- 2014-05-06 13:30:24 - TZ=UTC TB --- 2014-05-06 13:30:24 - __MAKE_CONF=/dev/null TB --- 2014-05-06 13:30:24 - cd /src TB --- 2014-05-06 13:30:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 13:30:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 13:30:24 - ERROR: failed to build world TB --- 2014-05-06 13:30:24 - 1.70 user 2.99 system 5.72 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 13:40:27 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0180EB9; Tue, 6 May 2014 13:40:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88972F26; Tue, 6 May 2014 13:40:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46DeQNU000777; Tue, 6 May 2014 09:40:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46DeQV8000773; Tue, 6 May 2014 13:40:26 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 13:40:26 GMT Message-Id: <201405061340.s46DeQV8000773@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:40:27 -0000 TB --- 2014-05-06 13:40:20 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 13:40:20 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 13:40:20 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 13:40:20 - cleaning the object tree TB --- 2014-05-06 13:40:20 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 13:40:25 - At svn revision 265440 TB --- 2014-05-06 13:40:26 - building world TB --- 2014-05-06 13:40:26 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 13:40:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 13:40:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 13:40:26 - SRCCONF=/dev/null TB --- 2014-05-06 13:40:26 - TARGET=arm TB --- 2014-05-06 13:40:26 - TARGET_ARCH=arm TB --- 2014-05-06 13:40:26 - TZ=UTC TB --- 2014-05-06 13:40:26 - __MAKE_CONF=/dev/null TB --- 2014-05-06 13:40:26 - cd /src TB --- 2014-05-06 13:40:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 13:40:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 13:40:26 - ERROR: failed to build world TB --- 2014-05-06 13:40:26 - 1.72 user 2.95 system 5.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 13:50:28 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FDD8F5D; Tue, 6 May 2014 13:50:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC19DD6; Tue, 6 May 2014 13:50:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46DoQfI001117; Tue, 6 May 2014 09:50:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46DoQaB001090; Tue, 6 May 2014 13:50:26 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 13:50:26 GMT Message-Id: <201405061350.s46DoQaB001090@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:50:28 -0000 TB --- 2014-05-06 13:50:20 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 13:50:20 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 13:50:20 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 13:50:20 - cleaning the object tree TB --- 2014-05-06 13:50:20 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 13:50:25 - At svn revision 265441 TB --- 2014-05-06 13:50:26 - building world TB --- 2014-05-06 13:50:26 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 13:50:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 13:50:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 13:50:26 - SRCCONF=/dev/null TB --- 2014-05-06 13:50:26 - TARGET=arm TB --- 2014-05-06 13:50:26 - TARGET_ARCH=arm TB --- 2014-05-06 13:50:26 - TZ=UTC TB --- 2014-05-06 13:50:26 - __MAKE_CONF=/dev/null TB --- 2014-05-06 13:50:26 - cd /src TB --- 2014-05-06 13:50:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 13:50:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 13:50:26 - ERROR: failed to build world TB --- 2014-05-06 13:50:26 - 1.50 user 3.16 system 5.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 14:00:26 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6BE2564; Tue, 6 May 2014 14:00:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AA51235; Tue, 6 May 2014 14:00:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46E0Pt4001470; Tue, 6 May 2014 10:00:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46E0PU1001467; Tue, 6 May 2014 14:00:25 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 14:00:25 GMT Message-Id: <201405061400.s46E0PU1001467@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:00:26 -0000 TB --- 2014-05-06 14:00:19 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 14:00:19 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 14:00:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 14:00:19 - cleaning the object tree TB --- 2014-05-06 14:00:19 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 14:00:24 - At svn revision 265442 TB --- 2014-05-06 14:00:25 - building world TB --- 2014-05-06 14:00:25 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 14:00:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 14:00:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 14:00:25 - SRCCONF=/dev/null TB --- 2014-05-06 14:00:25 - TARGET=arm TB --- 2014-05-06 14:00:25 - TARGET_ARCH=arm TB --- 2014-05-06 14:00:25 - TZ=UTC TB --- 2014-05-06 14:00:25 - __MAKE_CONF=/dev/null TB --- 2014-05-06 14:00:25 - cd /src TB --- 2014-05-06 14:00:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 14:00:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 14:00:25 - ERROR: failed to build world TB --- 2014-05-06 14:00:25 - 1.52 user 3.16 system 5.71 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 14:10:26 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEB26CBB; Tue, 6 May 2014 14:10:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9758F398; Tue, 6 May 2014 14:10:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46EAP8R001790; Tue, 6 May 2014 10:10:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46EAPgp001785; Tue, 6 May 2014 14:10:25 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 14:10:25 GMT Message-Id: <201405061410.s46EAPgp001785@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:10:26 -0000 TB --- 2014-05-06 14:10:19 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 14:10:19 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 14:10:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 14:10:19 - cleaning the object tree TB --- 2014-05-06 14:10:19 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 14:10:24 - At svn revision 265445 TB --- 2014-05-06 14:10:25 - building world TB --- 2014-05-06 14:10:25 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 14:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 14:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 14:10:25 - SRCCONF=/dev/null TB --- 2014-05-06 14:10:25 - TARGET=arm TB --- 2014-05-06 14:10:25 - TARGET_ARCH=arm TB --- 2014-05-06 14:10:25 - TZ=UTC TB --- 2014-05-06 14:10:25 - __MAKE_CONF=/dev/null TB --- 2014-05-06 14:10:25 - cd /src TB --- 2014-05-06 14:10:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 14:10:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 14:10:25 - ERROR: failed to build world TB --- 2014-05-06 14:10:25 - 1.84 user 2.85 system 5.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 14:20:26 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2AF4AD; Tue, 6 May 2014 14:20:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B2956DC; Tue, 6 May 2014 14:20:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46EKP0M002115; Tue, 6 May 2014 10:20:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46EKPlx002111; Tue, 6 May 2014 14:20:25 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 14:20:25 GMT Message-Id: <201405061420.s46EKPlx002111@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:20:26 -0000 TB --- 2014-05-06 14:20:19 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 14:20:19 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 14:20:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 14:20:19 - cleaning the object tree TB --- 2014-05-06 14:20:19 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 14:20:24 - At svn revision 265446 TB --- 2014-05-06 14:20:25 - building world TB --- 2014-05-06 14:20:25 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 14:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 14:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 14:20:25 - SRCCONF=/dev/null TB --- 2014-05-06 14:20:25 - TARGET=arm TB --- 2014-05-06 14:20:25 - TARGET_ARCH=arm TB --- 2014-05-06 14:20:25 - TZ=UTC TB --- 2014-05-06 14:20:25 - __MAKE_CONF=/dev/null TB --- 2014-05-06 14:20:25 - cd /src TB --- 2014-05-06 14:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 14:20:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 14:20:25 - ERROR: failed to build world TB --- 2014-05-06 14:20:25 - 1.55 user 3.13 system 5.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 14:30:27 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16E7D3DE; Tue, 6 May 2014 14:30:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC52E8B1; Tue, 6 May 2014 14:30:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s46EUPHi002443; Tue, 6 May 2014 10:30:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s46EUPA3002439; Tue, 6 May 2014 14:30:25 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 6 May 2014 14:30:25 GMT Message-Id: <201405061430.s46EUPA3002439@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:30:27 -0000 TB --- 2014-05-06 14:30:19 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-06 14:30:19 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-06 14:30:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-06 14:30:19 - cleaning the object tree TB --- 2014-05-06 14:30:19 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-06 14:30:24 - At svn revision 265447 TB --- 2014-05-06 14:30:25 - building world TB --- 2014-05-06 14:30:25 - CROSS_BUILD_TESTING=YES TB --- 2014-05-06 14:30:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-06 14:30:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-06 14:30:25 - SRCCONF=/dev/null TB --- 2014-05-06 14:30:25 - TARGET=arm TB --- 2014-05-06 14:30:25 - TARGET_ARCH=arm TB --- 2014-05-06 14:30:25 - TZ=UTC TB --- 2014-05-06 14:30:25 - __MAKE_CONF=/dev/null TB --- 2014-05-06 14:30:25 - cd /src TB --- 2014-05-06 14:30:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) -------------------------------------------------------------- "Makefile.inc", line 3: Could not find src.opts.mk make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-06 14:30:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-06 14:30:25 - ERROR: failed to build world TB --- 2014-05-06 14:30:25 - 1.62 user 3.09 system 5.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 6 17:35:29 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79978A2C for ; Tue, 6 May 2014 17:35:29 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DE7FD9D for ; Tue, 6 May 2014 17:35:29 +0000 (UTC) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CBE9B1C0B3F66 for ; Tue, 6 May 2014 19:35:25 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Problem with resizing partitions on RPi Message-Id: <6041302A-A4B2-4ACC-8B01-0DA29CEC5DE2@freebsd.org> Date: Tue, 6 May 2014 19:35:24 +0200 To: "freebsd-arm@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 17:35:29 -0000 Dear all, I just installed a freshly build rr265449 on a SD card for a RPi and = wanted to resize the filesystem, as I did a couple of times in the past. However, it doesn't work anymore: root@raspberry-pi:/home/tuexen # uname -a FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #49 r265449M: Tue = May 6 17:25:18 CEST 2014 = root@bsd5.fh-muenster.de:/usr/home/tuexen/obj/arm.armv6/usr/home/tuexen/he= ad/sys/RPI-B arm root@raspberry-pi:/home/tuexen # gpart show =3D> 63 31116225 mmcsd0 MBR (15G) 63 65520 1 !12 [active] (32M) 65583 2031561 2 freebsd (992M) 2097144 29019144 - free - (14G) =3D> 0 2031561 mmcsd0s2 BSD (992M) 0 2031561 1 freebsd-ufs (992M) root@raspberry-pi:/home/tuexen # gpart resize -i 2 mmcsd0 gpart: resizing will lead to unexpected shrinking due to alignment: = Device busy Any idea what is going wrong? Best regards Michael= From owner-freebsd-arm@FreeBSD.ORG Wed May 7 00:50:06 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63DB9D5D; Wed, 7 May 2014 00:50:06 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AF9F990; Wed, 7 May 2014 00:50:05 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s470o4n8077894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2014 17:50:05 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s470o4WK077893; Tue, 6 May 2014 17:50:04 -0700 (PDT) (envelope-from jmg) Date: Tue, 6 May 2014 17:50:04 -0700 From: John-Mark Gurney To: Michael Tuexen Subject: Re: Problem with resizing partitions on RPi Message-ID: <20140507005004.GJ43976@funkthat.com> Mail-Followup-To: Michael Tuexen , "freebsd-arm@freebsd.org" References: <6041302A-A4B2-4ACC-8B01-0DA29CEC5DE2@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6041302A-A4B2-4ACC-8B01-0DA29CEC5DE2@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 06 May 2014 17:50:05 -0700 (PDT) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 00:50:06 -0000 Michael Tuexen wrote this message on Tue, May 06, 2014 at 19:35 +0200: > I just installed a freshly build rr265449 on a SD card for a RPi and wanted > to resize the filesystem, as I did a couple of times in the past. > However, it doesn't work anymore: This is due to a slight regression that ae introduced, but was to protect from a worse failure where root would become unusable because it would shrink... I'm working w/ ae to get a better fix in that should restore the behavior... You can work around it by manually specifying size that is properly aligned... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed May 7 02:09:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A3DB9D9 for ; Wed, 7 May 2014 02:09:27 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F083F48 for ; Wed, 7 May 2014 02:09:27 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id rd3so378784pab.29 for ; Tue, 06 May 2014 19:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7ZtAeYv0NqbE+oUCeGIn7EjQvfOfEEkf9RqqgK+fDmI=; b=v7S4odHq8feHv2L+y4CY9RSZ04SZWAjyyOULEcQBZftFAV6sYc6LkVmDIdN6whLidT sd9mh4F93fk0ETNojsdEhJjXaWE0frvkpK0NEdOxwryF04NT5mtfXysx06hDe7lpcrPO I1x7GsgtXrm5df1YWXRmzkhHt2BXMSY6VN14RApw0vzw8efYbW6WdevMutCjv2DmQ4DK 3a6BcwxNBMo7BeB0CR90/gi1DeKQAMNKulyBRwq7dgwcXoXcxF+gQXm2j6BgqBRZ/NQU zZXbn64ykbOFOVReHMCTWLV5PBCxYo4dHHPzRMKATH2GZwBXp9Ua/VWU2q/g/f3vyWln rWQw== X-Received: by 10.66.249.233 with SMTP id yx9mr13112786pac.3.1399428566624; Tue, 06 May 2014 19:09:26 -0700 (PDT) Received: from [216.131.71.123] ([216.131.71.123]) by mx.google.com with ESMTPSA id sh5sm169668pbc.21.2014.05.06.19.09.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 19:09:25 -0700 (PDT) Message-ID: <536995CF.4060404@gmail.com> Date: Wed, 07 May 2014 10:09:19 +0800 From: Xuebing Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jeroen Hofstee Subject: Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD References: <5343B8B9.6040607@gmail.com> <1399203211.1994.25.camel@yellow> In-Reply-To: <1399203211.1994.25.camel@yellow> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: trini@ti.com, u-boot@lists.denx.de, vanbaren@cideas.com, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 02:09:27 -0000 On 05/04/2014 07:33 PM, Jeroen Hofstee wrote: > Hello Xuebing, (freebsd-arm added on cc), > > On di, 2014-04-08 at 16:52 +0800, Xuebing Wang wrote: >> Hi u-boot community, >> >> I am trying to port u-boot (release u-boot-2014.04-rc3.tar.bz2) to >> FreeBSD on BeagleBone Black. >> >> In FreeBSD, there is a u-boot loader (named ubldr), which can call >> u-boot API to get fdt (Flat Device Tree) data. >> >> I have to comment out below 3 lines, in order to get correct fdt data in >> FreeBSD ubldr from u-boot. Would you please advice what is the best way >> to fix this? >> >> In file common/env_common.c: >> const uchar *env_get_addr(int index) >> { >> // if (gd->env_valid) >> // return (uchar *)(gd->env_addr + index); >> // else >> return &default_environment[index]; >> } >> > Assuming that you checked that your environment is valid you might be > facing the fact that the gd pointer is corrupted. gd is a pointer to the > "global data" and used for storing globals which are available before > and after relocation. On (32bit) ARM this value used to be stored in > register r8 but moved to r9 (llvm cannot reserve an arbitrary register, > but can reserve r9 for platform specific usage). If ubldr uses r9 you > end up with a invalid gd pointer when calling back into u-boot. ubldr > now reserves r8 and r9 so a recent version should work fine on an older > U-boot as well as current master. > > Can you check the latest ubldr? Hi Jeroen, Thanks for your response. 1) Today, I tested ubldr in the snapshot build FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140428-r265054.img.bz2 without commenting out those 3 lines, I still can not get "fdt ls" in ubldr command line. After commenting out those 3 lines and rebuild u-boot, I can get "fdt ls" in ubldr command line. Note: All my previous test was based on FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140323-r263665.img.bz2 2) Would you please point to me which revision that reserves both r8 and r9? Thanks. > Regards, > Jeroen > > > -- Thanks, Xuebing Wang From owner-freebsd-arm@FreeBSD.ORG Wed May 7 05:13:01 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6797B57; Wed, 7 May 2014 05:13:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBF3A1EB; Wed, 7 May 2014 05:13:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s475D11E025832; Wed, 7 May 2014 05:13:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s475D1Lu025829; Wed, 7 May 2014 05:13:01 GMT (envelope-from linimon) Date: Wed, 7 May 2014 05:13:01 GMT Message-Id: <201405070513.s475D1Lu025829@freefall.freebsd.org> To: linimon@FreeBSD.org, Meyser@xenet.de, linimon@FreeBSD.org, freebsd-arm@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: arm/184078: [xdev] cross installworld missing include files X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 05:13:02 -0000 Synopsis: [xdev] cross installworld missing include files State-Changed-From-To: feedback->closed State-Changed-By: linimon State-Changed-When: Wed May 7 05:12:51 UTC 2014 State-Changed-Why: apparently now working. http://www.freebsd.org/cgi/query-pr.cgi?pr=184078 From owner-freebsd-arm@FreeBSD.ORG Wed May 7 05:20:01 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BF7BD29 for ; Wed, 7 May 2014 05:20:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6419F218 for ; Wed, 7 May 2014 05:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s475K18k027466 for ; Wed, 7 May 2014 05:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s475K0UR027465; Wed, 7 May 2014 05:20:00 GMT (envelope-from gnats) Date: Wed, 7 May 2014 05:20:00 GMT Message-Id: <201405070520.s475K0UR027465@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Mark Linimon Subject: Re: arm/184078: [xdev] cross installworld missing include files Reply-To: Mark Linimon X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 05:20:01 -0000 The following reply was made to PR arm/184078; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/184078: [xdev] cross installworld missing include files Date: Wed, 7 May 2014 00:13:52 -0500 ----- Forwarded message from Matthias Meyser ----- Date: Mon, 05 May 2014 09:32:03 +0200 From: Matthias Meyser To: linimon@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: Re: arm/184078: [xdev] cross installworld missing include files User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 > to submitter: xdev has recently been reworked. Is this PR now obsolete? Can be closed. Cross build/install and a native build/install afterwards worked without a glitch. -- Matthias Meyser | XeNET GmbH Tel.: +49-5323-9489050 | 38678 Clausthal-Zellerfeld, Marktstrasse 40 Fax: +49-5323-94014 | Registergericht: Amtsgericht Braunschweig HRB 110823 Email: Meyser@xenet.de | Geschaeftsfuehrer: Matthias Meyser ----- End forwarded message ----- From owner-freebsd-arm@FreeBSD.ORG Wed May 7 11:01:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0BAAC85 for ; Wed, 7 May 2014 11:01:59 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B30209CE for ; Wed, 7 May 2014 11:01:59 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id lx4so814577iec.10 for ; Wed, 07 May 2014 04:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=t27a+cF/rGUcBEifFlgqi1aoqokSVwHrPjR5GewkJGg=; b=X6Rg91TnrGNdzEjs7Zcw904U3D1mkGJBCxbthfeLvyfWaRKkpf6LEDkHesu83glkMo 1a06DiZzAka97qiUO84lkqs2PioX+DZj4ijf+/vfIIn4EvvdHA2JAK7zfyVkroUrergd kWYM8mkkE5j305p75YYsHESMN6GgeDrtgYAiHcYyZ465YuT3fe9TlQRO2MwBPhLgDcgi cw8/Q9nrry+rHgtRmMWowFgARy3XAN5NkChzsyqw/ZRqyRZJpuH9h0MsXidIR6mHe6A8 tt8VK30sB7BvMYB3l6AN3G7YHtVR06zpjE6KpxhLkdaIdb2pM7z36Ba7/v3Gu2VokmPr zLhw== MIME-Version: 1.0 X-Received: by 10.50.154.73 with SMTP id vm9mr42225583igb.14.1399460519160; Wed, 07 May 2014 04:01:59 -0700 (PDT) Received: by 10.64.163.38 with HTTP; Wed, 7 May 2014 04:01:58 -0700 (PDT) Date: Wed, 7 May 2014 12:01:58 +0100 Message-ID: Subject: CubieTruck support From: Paul Webster To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 11:02:00 -0000 Good day all, Has anyone succesfully got freebsd to work on the 'cubietruck' the processor is a: AllWinnerTech SOC A20, ARM=C2=AE Cortex=E2=84=A2-A7 Dual-Core Link to the general tech site: http://www.cubietruck.com/collections/frontpage/products/cubietruck-cubiebo= ard3-cortex-a7-dual-core-2gb-ram-8gb-flash-with-wifi-bt From owner-freebsd-arm@FreeBSD.ORG Wed May 7 11:07:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ADD0D57 for ; Wed, 7 May 2014 11:07:57 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBED8A0E for ; Wed, 7 May 2014 11:07:56 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id lx4so809647iec.37 for ; Wed, 07 May 2014 04:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SfV1GdY+iHBkFDHnMmyBOq8JXSjYo2MbP18BBcGk4WE=; b=arMVhNU4EtzzLVTr87Ldcpuu/CzovaNUzqAISPJ2HurVebw8mvDuJC0pCT3JNp1Zee +PrfziIuJVzIGlejemUhVfBzUEN7ELhG+ofHii0px4wMLoX9DCudEIDPzb1EtVrPuE4m +yfDLvf0LKL4OklevWPBzTurTgAC8dTZP/XFI1a0EeEIscCAl6+F/aByeqiv74NAOIrL s28ZgaIOuYj5tci3zNHV9qLqbHUTmihk6qNRnzt83v7vYvxztI965Q5UfB15mqStZB1r ubyzgfYCo7hDJKVhb4xw+Ye38WaiOKyMwTSqPgq0WLesJNfeqRssy7x0OBF1CPC+t566 M8RQ== MIME-Version: 1.0 X-Received: by 10.50.141.232 with SMTP id rr8mr27761892igb.48.1399460876323; Wed, 07 May 2014 04:07:56 -0700 (PDT) Received: by 10.64.64.5 with HTTP; Wed, 7 May 2014 04:07:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 May 2014 19:07:56 +0800 Message-ID: Subject: Re: CubieTruck support From: Ganbold Tsagaankhuu To: Paul Webster Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 11:07:57 -0000 On Wed, May 7, 2014 at 7:01 PM, Paul Webster wrote: > Good day all, > > Has anyone succesfully got freebsd to work on the 'cubietruck' the > processor is a: > > AllWinnerTech SOC A20, ARM=C2=AE Cortex=E2=84=A2-A7 Dual-Core > This SoC is supported in FreeBSD so most probably it will boot and work, there are couple of people who already have cubietruck so they can comment more on details. Ganbold > > Link to the general tech site: > > http://www.cubietruck.com/collections/frontpage/products/cubietruck-cubie= board3-cortex-a7-dual-core-2gb-ram-8gb-flash-with-wifi-bt > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Wed May 7 11:40:00 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F10DA2FB for ; Wed, 7 May 2014 11:40:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB541C73 for ; Wed, 7 May 2014 11:40:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s47Be0qt089123 for ; Wed, 7 May 2014 11:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s47Be0ip089122; Wed, 7 May 2014 11:40:00 GMT (envelope-from gnats) Resent-Date: Wed, 7 May 2014 11:40:00 GMT Resent-Message-Id: <201405071140.s47Be0ip089122@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, Keith White Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F4E4141 for ; Wed, 7 May 2014 11:30:03 +0000 (UTC) Received: from smtp2.vianet.ca (smtp2.vianet.ca [209.91.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id ED4D4BB5 for ; Wed, 7 May 2014 11:30:02 +0000 (UTC) Received: from localhost.my.domain (unused-69-60-246-88.vianet.ca [69.60.246.88]) by smtp2.vianet.ca (Postfix) with ESMTPS id 779C315BE7B for ; Wed, 7 May 2014 07:20:36 -0400 (EDT) Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.8/8.14.8) with ESMTP id s47BC2Rj012682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 7 May 2014 07:12:02 -0400 (EDT) (envelope-from kwhite@localhost.my.domain) Received: (from root@localhost) by localhost.my.domain (8.14.8/8.14.8/Submit) id s47BC2t6012681; Wed, 7 May 2014 07:12:02 -0400 (EDT) (envelope-from kwhite) Message-Id: <201405071112.s47BC2t6012681@localhost.my.domain> Date: Wed, 7 May 2014 07:12:02 -0400 (EDT) From: Keith White Reply-To: Keith White To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.114 Subject: arm/189415: [patch] mount_smbfs missing from arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 11:40:01 -0000 >Number: 189415 >Category: arm >Synopsis: [patch] mount_smbfs missing from arm >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed May 07 11:40:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Keith White >Release: FreeBSD 11.0-CURRENT arm >Organization: Faculty of Engineering, University of Ottawa >Environment: System: FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #46 r265404M: Mon May 5 19:27:21 EDT 2014 root@beaglebone:/usr/obj/usr/src/sys/BEAGLEBONE arm >Description: mount_smbfs is not included with base arm builds since libsmb uses casts to u_short that result in unaligned access to memory. Patch attached. >How-To-Repeat: >Fix: The following patch replaces potential unaligned access in libsmb with a function call to the internal function memsetw(), and adds libsmb and mount_smbfs to the base build. Index: contrib/smbfs/lib/smb/nb_name.c =================================================================== --- contrib/smbfs/lib/smb/nb_name.c (revision 265468) +++ contrib/smbfs/lib/smb/nb_name.c (working copy) @@ -146,14 +146,26 @@ #define NBENCODE(c) (htole16((u_short)(((u_char)(c) >> 4) | \ (((u_char)(c) & 0xf) << 8)) + 0x4141)) +#ifdef __arm__ static void memsetw(char *dst, int n, u_short word) { while (n--) { + ((u_char*)dst)[0] = word & 0xff; + ((u_char*)dst)[1] = word >> 8; + dst += 2; + } +} +#else +static void +memsetw(char *dst, int n, u_short word) +{ + while (n--) { *(u_short*)dst = word; dst += 2; } } +#endif int nb_name_encode(struct nb_name *np, u_char *dst) @@ -165,18 +177,30 @@ *cp++ = NB_ENCNAMELEN; name = np->nn_name; if (name[0] == '*' && name[1] == 0) { +#ifdef __arm__ + memsetw(cp, 1, NBENCODE('*')); +#else *(u_short*)cp = NBENCODE('*'); +#endif memsetw(cp + 2, NB_NAMELEN - 1, NBENCODE(' ')); cp += NB_ENCNAMELEN; } else { for (i = 0; *name && i < NB_NAMELEN - 1; i++, cp += 2, name++) +#ifdef __arm__ + memsetw(cp, 1, NBENCODE(toupper(*name))); +#else *(u_short*)cp = NBENCODE(toupper(*name)); +#endif i = NB_NAMELEN - i - 1; if (i > 0) { memsetw(cp, i, NBENCODE(' ')); cp += i * 2; } +#ifdef __arm__ + memsetw(cp, 1, NBENCODE(np->nn_type)); +#else *(u_short*)cp = NBENCODE(np->nn_type); +#endif cp += 2; } *cp = 0; Index: lib/Makefile =================================================================== --- lib/Makefile (revision 265468) +++ lib/Makefile (working copy) @@ -217,6 +217,10 @@ _libvmmapi= libvmmapi .endif +.if ${MACHINE_CPUARCH} == "arm" +_libsmb= libsmb +.endif + .if ${MACHINE_CPUARCH} == "ia64" _libefi= libefi _libsmb= libsmb Index: usr.sbin/Makefile.arm =================================================================== --- usr.sbin/Makefile.arm (revision 265468) +++ usr.sbin/Makefile.arm (working copy) @@ -2,3 +2,4 @@ SUBDIR+= ofwdump SUBDIR+= kgmon +SUBDIR+= mount_smbfs >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Wed May 7 14:15:25 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF35CC2F for ; Wed, 7 May 2014 14:15:25 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82AC2D61 for ; Wed, 7 May 2014 14:15:25 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wi2d1-0007lI-TF; Wed, 07 May 2014 14:15:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s47EFKAa027536; Wed, 7 May 2014 08:15:20 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Qdif62kWZyvO8hTbcqcqE Subject: Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD From: Ian Lepore To: Xuebing Wang In-Reply-To: <536995CF.4060404@gmail.com> References: <5343B8B9.6040607@gmail.com> <1399203211.1994.25.camel@yellow> <536995CF.4060404@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 May 2014 08:15:20 -0600 Message-ID: <1399472120.22079.292.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: trini@ti.com, u-boot@lists.denx.de, Jeroen Hofstee , freebsd-arm@FreeBSD.org, vanbaren@cideas.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:15:25 -0000 On Wed, 2014-05-07 at 10:09 +0800, Xuebing Wang wrote: > On 05/04/2014 07:33 PM, Jeroen Hofstee wrote: > > Hello Xuebing, (freebsd-arm added on cc), > > > > On di, 2014-04-08 at 16:52 +0800, Xuebing Wang wrote: > >> Hi u-boot community, > >> > >> I am trying to port u-boot (release u-boot-2014.04-rc3.tar.bz2) to > >> FreeBSD on BeagleBone Black. > >> > >> In FreeBSD, there is a u-boot loader (named ubldr), which can call > >> u-boot API to get fdt (Flat Device Tree) data. > >> > >> I have to comment out below 3 lines, in order to get correct fdt data in > >> FreeBSD ubldr from u-boot. Would you please advice what is the best way > >> to fix this? > >> > >> In file common/env_common.c: > >> const uchar *env_get_addr(int index) > >> { > >> // if (gd->env_valid) > >> // return (uchar *)(gd->env_addr + index); > >> // else > >> return &default_environment[index]; > >> } > >> > > Assuming that you checked that your environment is valid you might be > > facing the fact that the gd pointer is corrupted. gd is a pointer to the > > "global data" and used for storing globals which are available before > > and after relocation. On (32bit) ARM this value used to be stored in > > register r8 but moved to r9 (llvm cannot reserve an arbitrary register, > > but can reserve r9 for platform specific usage). If ubldr uses r9 you > > end up with a invalid gd pointer when calling back into u-boot. ubldr > > now reserves r8 and r9 so a recent version should work fine on an older > > U-boot as well as current master. > > > > Can you check the latest ubldr? > > Hi Jeroen, > > Thanks for your response. > > 1) Today, I tested ubldr in the snapshot build > FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140428-r265054.img.bz2 > without commenting out those 3 lines, I still can not get "fdt ls" in > ubldr command line. > > After commenting out those 3 lines and rebuild u-boot, I can get "fdt > ls" in ubldr command line. > > Note: All my previous test was based on > FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140323-r263665.img.bz2 > > 2) Would you please point to me which revision that reserves both r8 and r9? > > > Thanks. > > > > Regards, > > Jeroen > > > > > > > I think you should be debugging this from the ubldr side. If 'fdt ls' fails to load the dtb when the u-boot global env is present, then what we need to know is what result is being returned when ubldr looks up the fdtaddr and/or fdt_addr variables. Does it get an address for the dtb at all? Is the address invalid? Is it valid but it points to something that doesn't look like a valid dtb header? -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed May 7 15:02:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9225D0 for ; Wed, 7 May 2014 15:02:46 +0000 (UTC) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBF90274 for ; Wed, 7 May 2014 15:02:46 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id y13so1154751pdi.21 for ; Wed, 07 May 2014 08:02:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=THGb+MPUxRELAfFBZYgnRRCPzFe5uAq7V/KlVEqJdIk=; b=KuJhaG54m8MKFhBY9PwlmMCiyNUMJ5iZ/5yu6HMMtKpPt+6TlYLe9T0yJx2aTB2pOV vjWe4QBOhj+S586Uj+qehTqXGV912zwS5n4uIPqjz5OVnrcZ2iha3I3mAe4m8R4KBd9F TCXDpM45gE/njvFQHMYnfOnb+cAe4Xr1VU6WwLAYQsccSV6iq3lN6HITGkuaeIu47Q0+ rKr+hvKh8IipW0JSgvC+QdQx24xCsPn2AekqpshvgfGMIbgM0Lp1pT3jiQa7Bp5u9gzJ eOlSO2Cf0W7c+Lv5h6Z0DIjUbpDdE9Gday2EUQrAbhwCQVsXTAZ34aay8S88kJ4KNN+w MqRg== X-Gm-Message-State: ALoCoQkcR9x9T4rliA1sb5P1d/D5qj6Gj4xbCzBVN1QQ+YowPCeVK6fVJLt9dtbOd7rxT0EQ9v3b X-Received: by 10.66.228.37 with SMTP id sf5mr98519594pac.19.1399474960674; Wed, 07 May 2014 08:02:40 -0700 (PDT) Received: from [192.168.1.2] (c-50-156-22-189.hsd1.ca.comcast.net. [50.156.22.189]) by mx.google.com with ESMTPSA id el14sm115291530pac.31.2014.05.07.08.02.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 08:02:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD From: Tim Kientzle In-Reply-To: <536995CF.4060404@gmail.com> Date: Wed, 7 May 2014 08:02:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <75CA0732-E9B7-4027-9E9A-A24115BC90DC@kientzle.com> References: <5343B8B9.6040607@gmail.com> <1399203211.1994.25.camel@yellow> <536995CF.4060404@gmail.com> To: Xuebing Wang X-Mailer: Apple Mail (2.1874) Cc: trini@ti.com, u-boot@lists.denx.de, Jeroen Hofstee , freebsd-arm@freebsd.org, vanbaren@cideas.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:02:47 -0000 On May 6, 2014, at 7:09 PM, Xuebing Wang wrote: > 2) Would you please point to me which revision that reserves both r8 = and r9? ------------------------------------------------------------------------ r258527 | andrew | 2013-11-24 12:33:38 -0800 (Sun, 24 Nov 2013) | 3 = lines Recent versions of U-Boot require us to also backup and restore r9 for = API calls to work. ------------------------------------------------------------------------ From owner-freebsd-arm@FreeBSD.ORG Wed May 7 15:17:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C444A8D4 for ; Wed, 7 May 2014 15:17:21 +0000 (UTC) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95FEC403 for ; Wed, 7 May 2014 15:17:21 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id fa1so1309910pad.6 for ; Wed, 07 May 2014 08:17:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=C6A1gEz06N+keuWsRtxGBgjM2Tqzz3VvpoW5/YUpq+U=; b=e89xEf6c4+ZPxpS45jOltR+YhJYWjotoGuR+FbAn/BrZbrm+GZq1/Bf3LWmaci7Wa3 xFk+0/aa0biW9otzY1sezn9BGSeMZCgM9dAD+2AO/dPksIGaKNKesiE3ACnpnx8tuD8n dtWilRk4FYcbDZAKnZMwbv6BTwfo2a8CCa7pPab68JZjzVK48fPO3E172hAqEAYfmd3H ud7KiBb41PXs/geAY2YZEBSzxnIRe6suBiQsC4iw5h1Ls5OWjU14N6E51yl4fRUrAi3O i/MH+PDo1UY+SlLNcajujmyOadYHl7qDmPtKbcG3fotnkxl8jFpHMjOK6VDdDBG2U1QE R8Ig== X-Gm-Message-State: ALoCoQnRvfBD/8wx3scxtadIO1QqukxRXqv01r3HllC1wIxHHCJy1O3jsvganHoeXYqRGCY3vpni X-Received: by 10.66.240.4 with SMTP id vw4mr20048663pac.26.1399475840370; Wed, 07 May 2014 08:17:20 -0700 (PDT) Received: from [192.168.1.2] (c-50-156-22-189.hsd1.ca.comcast.net. [50.156.22.189]) by mx.google.com with ESMTPSA id z3sm114458415pas.15.2014.05.07.08.17.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 08:17:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD From: Tim Kientzle In-Reply-To: <75CA0732-E9B7-4027-9E9A-A24115BC90DC@kientzle.com> Date: Wed, 7 May 2014 08:17:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5343B8B9.6040607@gmail.com> <1399203211.1994.25.camel@yellow> <536995CF.4060404@gmail.com> <75CA0732-E9B7-4027-9E9A-A24115BC90DC@kientzle.com> To: Xuebing Wang X-Mailer: Apple Mail (2.1874) Cc: trini@ti.com, u-boot@lists.denx.de, Jeroen Hofstee , freebsd-arm@freebsd.org, vanbaren@cideas.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:17:21 -0000 On May 7, 2014, at 8:02 AM, Tim Kientzle wrote: >=20 > On May 6, 2014, at 7:09 PM, Xuebing Wang wrote: >=20 >> 2) Would you please point to me which revision that reserves both r8 = and r9? >=20 > = ------------------------------------------------------------------------ > r258527 | andrew | 2013-11-24 12:33:38 -0800 (Sun, 24 Nov 2013) | 3 = lines >=20 > Recent versions of U-Boot require us to also backup and restore r9 for = API > calls to work. >=20 > = ------------------------------------------------------------------------ >=20 And MFCed to Stable-10: ------------------------------------------------------------------------ r265064 | ian | 2014-04-28 16:46:04 -0700 (Mon, 28 Apr 2014) | 2 lines MFC r257210, r258527: No hardfloat in ubldr, save/restore r9 for api = calls. ------------------------------------------------------------------------ From owner-freebsd-arm@FreeBSD.ORG Wed May 7 19:13:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 856AE469 for ; Wed, 7 May 2014 19:13:43 +0000 (UTC) Received: from nm6-vm1.access.bullet.mail.gq1.yahoo.com (nm6-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 521FDDA for ; Wed, 7 May 2014 19:13:42 +0000 (UTC) Received: from [216.39.60.165] by nm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 May 2014 19:10:26 -0000 Received: from [67.195.23.145] by tm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 May 2014 19:10:25 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.gq1.yahoo.com with NNFMP; 07 May 2014 19:10:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1399489825; bh=8LyoWzv4kbMcWie3BjFEMaIUFkYqDa8GRYHqBhPqaEQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; b=afJJnqS2AhSuAsIIYGdFHXVgCZfjI5Jh+qg1rI0BWrDbhNJaBYH9t0nNPpqxjFyWXR8U5T9jipZyjE+Dz4heYVqxxUpOmJ0zUH4zWiTnlYkgBk2K6gIzaoRt15RfVVVQ28UzyvIVxHjtIFU2BgXXOV0uBnB2dUle3tbZapNUbIo= X-Yahoo-Newman-Id: 869284.77207.bm@smtp117.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8qNSWn4VM1l_To2Wp_8LoKNH9dPCJh.kBV3NKqKz.xcRzFS gUAMu2B3eWAa.AZ0vHAydrRQwhLrGLOwWbW2XsIz2GbsVaKYHP7ve7ob1are opGa_Tg5riuJqBrz2CazDd1q266_yVkw.YO.ToWrmA9vfQxsZiRdHo9q_NBa H5qJ3Fgr6KsBmJotxPZgCX8kDRnDr_zH_8UXjT37A3Np.A7xBgQ4E00wFTqG 7pCbW2VOOu5k.M7Br.cGa_ZSFJpLM9ffKCOBRriMAWJ9ra54AE9FgzbXL_Tw BMg5eKmGpX0OQIelbfXD6so_07Acbblv8bkNoq1_TeCiHTMqTfXYkX8xkgTX qCYdBHMWjOPkPpexFl.41yDq_yKqIJFVete0e0hNYMamRGiqvE9KnjcuScsf tHGgyeQRSHHWLhuZTXcbEmMoCedZsw2ub90FUqMdajDnKgIo2g2_uqTjeFqM GcLsycpWQ6DmJ1QFrDWI3ce01miVIAl49VGydAIz3nV65gOnMnb6RF9ynTXS o26FK2v0G1T0cJkeRXNWtTl.GrpGia5NylbiUE6BRfwp106daaPmqjoI- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.161.204 with plain [67.195.15.66]) by smtp117.sbc.mail.gq1.yahoo.com with SMTP; 07 May 2014 19:10:25 +0000 UTC Message-ID: <536A851F.4060106@sbcglobal.net> Date: Wed, 07 May 2014 12:10:23 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-arm Subject: Zynq devcfg occasionally fails (patch) Content-Type: multipart/mixed; boundary="------------010801090405090601030809" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 19:13:43 -0000 This is a multi-part message in MIME format. --------------010801090405090601030809 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello. I recently started seeing failures programming the Zynq's PL (FPGA) using the devcfg driver. If the PL happens to be in reset mode already, the INIT signal isn't asserted fast enough causing a time-out. I've attached a fix for this as well as a fix to stop WITNESS from complaining. Thanks, --Thomas -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net --------------010801090405090601030809 Content-Type: text/plain; charset=UTF-8; name="patch.devcfg.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch.devcfg.txt" SW5kZXg6IHN5cy9hcm0veGlsaW54L3p5N19kZXZjZmcuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz eXMvYXJtL3hpbGlueC96eTdfZGV2Y2ZnLmMJKHJldmlzaW9uIDI2NTQwNykKKysrIHN5cy9h cm0veGlsaW54L3p5N19kZXZjZmcuYwkod29ya2luZyBjb3B5KQpAQCAtMjY3LDI0ICsyNjcs MzUgQEAKIAogCWRldmNmZ19jdGwgPSBSRDQoc2MsIFpZN19ERVZDRkdfQ1RSTCk7CiAKKwkv KiBDbGVhciBzdGlja3kgYml0cyBhbmQgc2V0IHVwIElOSVQgc2lnbmFsIHBvc2l0aXZlIGVk Z2UgaW50ZXJydXB0LiAqLworCVdSNChzYywgWlk3X0RFVkNGR19JTlRfU1RBVFVTLCBaWTdf REVWQ0ZHX0lOVF9BTEwpOworCVdSNChzYywgWlk3X0RFVkNGR19JTlRfTUFTSywgflpZN19E RVZDRkdfSU5UX1BDRkdfSU5JVF9QRSk7CisKIAkvKiBEZWFzc2VydCBQUk9HX0IgKGFjdGl2 ZSBsb3cpLiAqLwogCWRldmNmZ19jdGwgfD0gWlk3X0RFVkNGR19DVFJMX1BDRkdfUFJPR19C OwogCVdSNChzYywgWlk3X0RFVkNGR19DVFJMLCBkZXZjZmdfY3RsKTsKIAotCS8qIFdhaXQg Zm9yIElOSVRfQiBkZWFzc2VydGVkIChhY3RpdmUgbG93KS4gKi8KLQl0cmllcyA9IDA7Ci0J d2hpbGUgKChSRDQoc2MsIFpZN19ERVZDRkdfU1RBVFVTKSAmCi0JCVpZN19ERVZDRkdfU1RB VFVTX1BDRkdfSU5JVCkgPT0gMCkgewotCQlpZiAoKyt0cmllcyA+PSAxMDApCi0JCQlyZXR1 cm4gKEVJTyk7Ci0JCURFTEFZKDUpOworCS8qCisJICogV2FpdCBmb3IgSU5JVCB0byBhc3Nl cnQuICBJZiBpdCBpcyBhbHJlYWR5IGFzc2VydGVkLCB3ZSBtYXkgbm90IGdldAorCSAqIGFu IGVkZ2UgaW50ZXJydXB0IHNvIGNhbmNlbCBpdCBhbmQgY29udGludWUuCisJICovCisJaWYg KChSRDQoc2MsIFpZN19ERVZDRkdfU1RBVFVTKSAmCisJICAgICBaWTdfREVWQ0ZHX1NUQVRV U19QQ0ZHX0lOSVQpICE9IDApIHsKKwkJLyogQWxyZWFkeSBhc3NlcnRlZC4gIENhbmNlbCBp bnRlcnJ1cHQuICovCisJCVdSNChzYywgWlk3X0RFVkNGR19JTlRfTUFTSywgfjApOwogCX0K LQotCS8qIFJlYXNzZXJ0IFBST0dfQi4gKi8KKwllbHNlIHsKKwkJLyogV2FpdCBmb3IgcG9z aXRpdmUgZWRnZSBpbnRlcnJ1cHQuICovCisJCWVyciA9IG10eF9zbGVlcChzYywgJnNjLT5z Y19tdHgsIFBDQVRDSCwgInp5N2kxIiwgaHopOworCQlpZiAoZXJyICE9IDApCisJCQlyZXR1 cm4gKGVycik7CisJfQorCQorCS8qIFJlYXNzZXJ0IFBST0dfQiAoYWN0aXZlIGxvdykuICov CiAJZGV2Y2ZnX2N0bCAmPSB+Wlk3X0RFVkNGR19DVFJMX1BDRkdfUFJPR19COwogCVdSNChz YywgWlk3X0RFVkNGR19DVFJMLCBkZXZjZmdfY3RsKTsKIAotCS8qIFdhaXQgZm9yIElOSVRf QiBhc3NlcnRlZC4gKi8KKwkvKiBXYWl0IGZvciBJTklUIGRlYXNzZXJ0ZWQuICBUaGlzIGhh cHBlbnMgYWxtb3N0IGluc3RhbnRseS4gKi8KIAl0cmllcyA9IDA7CiAJd2hpbGUgKChSRDQo c2MsIFpZN19ERVZDRkdfU1RBVFVTKSAmCiAJCVpZN19ERVZDRkdfU1RBVFVTX1BDRkdfSU5J VCkgIT0gMCkgewpAQCAtMjkzLDcgKzMwNCw3IEBACiAJCURFTEFZKDUpOwogCX0KIAotCS8q IENsZWFyIHN0aWNreSBiaXRzIGFuZCBzZXQgdXAgSU5JVF9CIHBvc2l0aXZlIGVkZ2UgaW50 ZXJydXB0LiAqLworCS8qIENsZWFyIHN0aWNreSBiaXRzIGFuZCBzZXQgdXAgSU5JVCBwb3Np dGl2ZSBlZGdlIGludGVycnVwdC4gKi8KIAlXUjQoc2MsIFpZN19ERVZDRkdfSU5UX1NUQVRV UywgWlk3X0RFVkNGR19JTlRfQUxMKTsKIAlXUjQoc2MsIFpZN19ERVZDRkdfSU5UX01BU0ss IH5aWTdfREVWQ0ZHX0lOVF9QQ0ZHX0lOSVRfUEUpOwogCkBAIC0zMDEsMTEgKzMxMiwxMSBA QAogCWRldmNmZ19jdGwgfD0gWlk3X0RFVkNGR19DVFJMX1BDRkdfUFJPR19COwogCVdSNChz YywgWlk3X0RFVkNGR19DVFJMLCBkZXZjZmdfY3RsKTsKIAotCS8qIFdhaXQgZm9yIElOSVRf QiBkZWFzc2VydGVkIGluZGljYXRpbmcgRlBHQSBpbnRlcm5hbCBpbml0aWFsaXphdGlvbgot CSAqIGlzIGNvbXBsZXRlLiAgVGhpcyB0YWtlcyBtdWNoIGxvbmdlciB0aGFuIHRoZSBwcmV2 aW91cyB3YWl0cyBmb3IKLQkgKiBJTklUX0IgdHJhbnNpdGlvbiAob24gdGhlIG9yZGVyIG9m IDcwMHVzKS4KKwkvKgorCSAqIFdhaXQgZm9yIElOSVQgYXNzZXJ0ZWQgaW5kaWNhdGluZyBG UEdBIGludGVybmFsIGluaXRpYWxpemF0aW9uCisJICogaXMgY29tcGxldGUuCiAJICovCi0J ZXJyID0gbXR4X3NsZWVwKHNjLCAmc2MtPnNjX210eCwgUENBVENILCAienk3aW4iLCBoeik7 CisJZXJyID0gbXR4X3NsZWVwKHNjLCAmc2MtPnNjX210eCwgUENBVENILCAienk3aTIiLCBo eik7CiAJaWYgKGVyciAhPSAwKQogCQlyZXR1cm4gKGVycik7CiAKQEAgLTQwNCw3ICs0MTUs OSBAQAogCiAJCS8qIHVpb21vdmUgdGhlIGRhdGEgZnJvbSB1c2VyIGJ1ZmZlciB0byBvdXIg ZG1hIG1hcC4gKi8KIAkJc2Vnc3ogPSBNSU4oUEFHRV9TSVpFLCB1aW8tPnVpb19yZXNpZCk7 CisJCURFVkNGR19TQ19VTkxPQ0soc2MpOwogCQllcnIgPSB1aW9tb3ZlKGRtYV9tZW0sIHNl Z3N6LCB1aW8pOworCQlERVZDRkdfU0NfTE9DSyhzYyk7CiAJCWlmIChlcnIgIT0gMCkKIAkJ CWJyZWFrOwogCg== --------------010801090405090601030809-- From owner-freebsd-arm@FreeBSD.ORG Thu May 8 06:22:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4CA2A80 for ; Thu, 8 May 2014 06:22:46 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABA7C180 for ; Thu, 8 May 2014 06:22:46 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id l6so2405126qcy.3 for ; Wed, 07 May 2014 23:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=E56cqMsGbTdz4P04zCNFQxAlC/aIZBlKguss4Y+oibk=; b=HTmNAMMNfU660s1AN7ORff+MKuSp4zyxlYYbdx1LIhb2BkGl19E70ocMOWXAuMKfNc 4v5JjrbSVP6cHuellxAl+e+syDYTh79+lD/A5ZswTAUI1sS3N6iVi+d7Bu5som10Pa+Q iScp2v3o/sgkagPETxu5dN+FBckea40njjiUOwtyJ0OwqJytv2btS5EQ5mty9zVKzL5P sIS8thPjsnp9YiUKs8MGe3KLvGiQIhNbQkuNG6SPXEjWEERQKbI7S2U0NoRKeKchx5+g BhLCx6arOHNvuafB0aGPkToh2kNOc679/tvSedFO7bynuu1qunHwCXapq5Eke55k9MeW HpcA== MIME-Version: 1.0 X-Received: by 10.140.108.4 with SMTP id i4mr1881753qgf.80.1399530165885; Wed, 07 May 2014 23:22:45 -0700 (PDT) Received: by 10.96.51.38 with HTTP; Wed, 7 May 2014 23:22:45 -0700 (PDT) Date: Thu, 8 May 2014 02:22:45 -0400 Message-ID: Subject: re install or download port collection? From: Alan Corey To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 06:22:47 -0000 I just joined to comment on this. I just hit an issue with GCC not wanting to work on ARM and some programs by default use GCC. My case was mc needing libcrypt which wants GCC and GCC won't build. I posted in freebsd-questions and got an answer from Matthew that a long-term solution is in the works. I've got the ports tree from i386 in my Pi and some things work fine, not everything. I've only had it a few days. Alan -- Credit is the root of all evil. - AB1JX From owner-freebsd-arm@FreeBSD.ORG Thu May 8 07:32:17 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC0F966F; Thu, 8 May 2014 07:32:17 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CAF039CE; Thu, 8 May 2014 07:32:17 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s487WBbU002597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 May 2014 00:32:11 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s487WBWr002596; Thu, 8 May 2014 00:32:11 -0700 (PDT) (envelope-from jmg) Date: Thu, 8 May 2014 00:32:11 -0700 From: John-Mark Gurney To: Michael Tuexen , "freebsd-arm@freebsd.org" Subject: Re: Problem with resizing partitions on RPi Message-ID: <20140508073211.GZ43976@funkthat.com> Mail-Followup-To: Michael Tuexen , "freebsd-arm@freebsd.org" References: <6041302A-A4B2-4ACC-8B01-0DA29CEC5DE2@freebsd.org> <20140507005004.GJ43976@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140507005004.GJ43976@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 08 May 2014 00:32:11 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 07:32:18 -0000 John-Mark Gurney wrote this message on Tue, May 06, 2014 at 17:50 -0700: > Michael Tuexen wrote this message on Tue, May 06, 2014 at 19:35 +0200: > > I just installed a freshly build rr265449 on a SD card for a RPi and wanted > > to resize the filesystem, as I did a couple of times in the past. > > However, it doesn't work anymore: > > This is due to a slight regression that ae introduced, but was to > protect from a worse failure where root would become unusable > because it would shrink... > > I'm working w/ ae to get a better fix in that should restore the > behavior... > > You can work around it by manually specifying size that is properly > aligned... This should be fixed now in r265539. Let me or ae@ know if it isn't. If it isn't, include a gpart list in the email place. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu May 8 07:36:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6876764 for ; Thu, 8 May 2014 07:36:41 +0000 (UTC) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D0AAA0C for ; Thu, 8 May 2014 07:36:41 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id l6so2439737qcy.9 for ; Thu, 08 May 2014 00:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pHdBzekbRDs4ABsnC6fRTjcwMUriMoKtJwfcAGvzZLs=; b=OmInqToywrLtohh8V2y+aca+Fudw7WfVM4nva/K7p/lPxM76bB7SAPnoDQAQymsY8X a0tCkLxLxf7AK1bxLa2p3n8rUvKdE2P5SqEX1GCSBmSl4NW39+P5Drk+Mlshn6GLsk3X YrKzUpWQ607gERN8zTRs1POmB+xqg9zodFjX09MRaOZaSI0xCy6UTCeuWocBnTahKZwp b02BjucVrSXDLENK8Y+Gukv4DZQbf7Vl9e6KMLvK+ViuNjDYYqnGDBqZV8IXrpbTR434 GN1ExTRHP5l30B/GL+z6nIfye06cSWCQS7ARhjcWbbY2/hB4EEsZD5A+j1bTxM1hrswA 2c0w== MIME-Version: 1.0 X-Received: by 10.224.115.139 with SMTP id i11mr2357674qaq.1.1399534600795; Thu, 08 May 2014 00:36:40 -0700 (PDT) Received: by 10.96.51.38 with HTTP; Thu, 8 May 2014 00:36:40 -0700 (PDT) Date: Thu, 8 May 2014 03:36:40 -0400 Message-ID: Subject: Anybody using an Adafruit PiTFT display? From: Alan Corey To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 07:36:41 -0000 Adafruit doesn't support anything but Raspbian officially, but one guy there is a NetBSD user. I'm not really qualified but I bought the display and I'm starting to look into making it work under FreeBSD, but only because OpenBSD doesn't support the Pi and I don't like Linux. I've been using OpenBSD about 14 years, once in a while FreeBSD. It uses a framebuffer which I'm not totally familiar with, and console output and X output can appear on its screen. It's a 2.8 inch TFT LCD with LED backlight and touchscreen, plugs into the GPIO connector. It's supported partly by Adafruit's patches to the Linux kernel, connects mostly to the SPI interface and a couple GPIO pins, sells for about $40. If I do a dmesg to a file, then shut down, plug in the board, boot back up and do a dmesg to another file and compare the files it looks like nothing on the board is recognized. New hobby. Anyone done anything with one? Alan -- Credit is the root of all evil. - AB1JX From owner-freebsd-arm@FreeBSD.ORG Thu May 8 07:46:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FBB9935 for ; Thu, 8 May 2014 07:46:11 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3B41AC2 for ; Thu, 8 May 2014 07:46:10 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id q107so2304943qgd.38 for ; Thu, 08 May 2014 00:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VCEK0VMzt+LUcOJIdpk1fEIMXNFC6PzNx7m7+03Go/A=; b=L4cPLtsRyphsNzsLknaF+ENS2EupHP1u2mVYfdRc/b389gMHbBrIq6QT7pz8TxAm/e RUeimZs6XniE7pA6cLiTp3tcPklEoSO6xsR2qLtwIvRhgGyXexeskM3+aBxTStu6LWdx Kbpj0Xa5RQ6z6HSjUgUeZnYRSli8gEU0Xw51Ex1FLkY/aD4vRHPJB3ewCEDQLajWgANl gr3gUQ3Ma35zqZiY5HMwmWBt3t5M1iOq+0QoJmFu93vwA1uVJzuFUHmDZChQb5vF/bBt RTPkViQVKQJoQtSJMesbzAjuAye7ojj16mRcPJCJqQR+SFS3bcn+RKObQWbvp0Vm0dPT m7Jw== MIME-Version: 1.0 X-Received: by 10.224.16.199 with SMTP id p7mr2521717qaa.76.1399535170066; Thu, 08 May 2014 00:46:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Thu, 8 May 2014 00:46:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 May 2014 00:46:09 -0700 X-Google-Sender-Auth: gSVdV-edMq8fBowuUITWpY2NzJI Message-ID: Subject: Re: Anybody using an Adafruit PiTFT display? From: Adrian Chadd To: Alan Corey Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 07:46:11 -0000 Hm, looks like someone would need to write a VT driver for the thing. I don't know about how to get X onto it though. Do we have any support for X to render to VT console? -a On 8 May 2014 00:36, Alan Corey wrote: > Adafruit doesn't support anything but Raspbian officially, but one guy > there is a NetBSD user. I'm not really qualified but I bought the > display and I'm starting to look into making it work under FreeBSD, > but only because OpenBSD doesn't support the Pi and I don't like > Linux. I've been using OpenBSD about 14 years, once in a while > FreeBSD. > > It uses a framebuffer which I'm not totally familiar with, and console > output and X output can appear on its screen. It's a 2.8 inch TFT LCD > with LED backlight and touchscreen, plugs into the GPIO connector. > It's supported partly by Adafruit's patches to the Linux kernel, > connects mostly to the SPI interface and a couple GPIO pins, sells for > about $40. > > If I do a dmesg to a file, then shut down, plug in the board, boot > back up and do a dmesg to another file and compare the files it looks > like nothing on the board is recognized. New hobby. > > Anyone done anything with one? > > Alan > > -- > Credit is the root of all evil. - AB1JX > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu May 8 08:11:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F266A2D5 for ; Thu, 8 May 2014 08:11:04 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2835D03 for ; Thu, 8 May 2014 08:11:04 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id cm18so2169371qab.36 for ; Thu, 08 May 2014 01:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sdPN5/1vm30KK/8EHw+5aCZnpTDw77/32g9tzb9dKZg=; b=wLAQjk+LcpAWPNDUXOr0tK5kgBfPuQHFzLMTWPlUkaN2zh8qGI+UjCEK40HMwn6TuG XwP4CfeZu6BGw/ipZXGQyEzT1v7WZnsUwB0w417LkH8j9w3loz82UDrDp2cZgq7Bjob1 9EOeQ4ICAJibCNDaBhOdu3AwOhyE+BpmWyZKe43Xch94odbDDm/eiWs3G2JU9j9aSito +oyiUQhGpPZGsskgMM34Idtc2AV1G+lyCV6LyEFw3BKz0SGavr37pwLGoclsKsymexud Q2CmopL2HzqY5adZwXlKuGva1HAlVJVE7GcfCwweHW0o0/zjllGcVmtWD5tkatCxvu/c 2S+g== MIME-Version: 1.0 X-Received: by 10.224.51.2 with SMTP id b2mr2484529qag.49.1399536663851; Thu, 08 May 2014 01:11:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Thu, 8 May 2014 01:11:03 -0700 (PDT) In-Reply-To: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> References: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> Date: Thu, 8 May 2014 01:11:03 -0700 X-Google-Sender-Auth: uRQ3kXvCj14RGoH-eW5huVrL4xE Message-ID: Subject: Re: required xdev line to build r-pi on crochet? From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 08:11:05 -0000 This: ===> lib/clang/libclangcodegen (depend) rm -f .depend CC='cc -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a -I/usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"armv6-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/usr/armv6-freebsd\" /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGAtomic.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGBlocks.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCUDANV.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCUDARuntime.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCXX.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCXXABI.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCall.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGClass.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCleanup.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGDecl.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGDeclCXX.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGException.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExprAgg.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExprCXX.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExprComplex.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExprConstant.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExprScalar.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjC.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjCGNU.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjCMac.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjCRuntime.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGOpenCLRuntime.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGRTTI.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGStmt.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGVTT.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGVTables.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenABITypes.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenModule.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenTBAA.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/ItaniumCXXABI.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/MicrosoftCXXABI.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/MicrosoftVBTables.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/ModuleBuilder.cpp /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory cc: error trying to exec 'cc1plus': execvp: No such file or directory mkdep: compile failed *** Error code 1 from .. # make XDEV=arm XDEV_ARCH=armv6 WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG_BOOTSTRAP=1 WITHOUT_CLANG_IS_CC=1 xdev .. so what am I doing wrong? -a On 3 May 2014 07:27, Warner Losh wrote: > > On May 3, 2014, at 12:14 AM, Adrian Chadd wrote: > >> With Warners recent changes, the hint from crochet about how to build >> the xdev environment for the raspberry pi no longer applies. >> >> So - how does one build said xdev toolchain now? > > Add WITHOUT_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. > > Warner > From owner-freebsd-arm@FreeBSD.ORG Thu May 8 08:46:43 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 981AE2F1 for ; Thu, 8 May 2014 08:46:43 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5968A9A for ; Thu, 8 May 2014 08:46:43 +0000 (UTC) Received: from [192.168.1.103] (p508F057E.dip0.t-ipconnect.de [80.143.5.126]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5E55F1C104817; Thu, 8 May 2014 10:46:39 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Problem with resizing partitions on RPi From: Michael Tuexen In-Reply-To: <20140508073211.GZ43976@funkthat.com> Date: Thu, 8 May 2014 10:46:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9BA69904-108F-490F-A12D-D025511C9D92@freebsd.org> References: <6041302A-A4B2-4ACC-8B01-0DA29CEC5DE2@freebsd.org> <20140507005004.GJ43976@funkthat.com> <20140508073211.GZ43976@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 08:46:43 -0000 On 08 May 2014, at 09:32, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Tue, May 06, 2014 at 17:50 = -0700: >> Michael Tuexen wrote this message on Tue, May 06, 2014 at 19:35 = +0200: >>> I just installed a freshly build rr265449 on a SD card for a RPi and = wanted >>> to resize the filesystem, as I did a couple of times in the past. >>> However, it doesn't work anymore: >>=20 >> This is due to a slight regression that ae introduced, but was to >> protect from a worse failure where root would become unusable >> because it would shrink... >>=20 >> I'm working w/ ae to get a better fix in that should restore the >> behavior... >>=20 >> You can work around it by manually specifying size that is properly >> aligned... >=20 > This should be fixed now in r265539. >=20 > Let me or ae@ know if it isn't. If it isn't, include a gpart list in > the email place. It is fixed. Thank you very much! Best regards Michael >=20 > Thanks. >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." >=20 From owner-freebsd-arm@FreeBSD.ORG Thu May 8 12:56:31 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1079276C; Thu, 8 May 2014 12:56:31 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6CA9C69; Thu, 8 May 2014 12:56:30 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WiNs6-0004Mg-JE; Thu, 08 May 2014 12:56:22 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s48CuJhR028985; Thu, 8 May 2014 06:56:19 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18e18hKVITCDbRkxuK4yMAD Subject: Re: required xdev line to build r-pi on crochet? From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 May 2014 06:56:19 -0600 Message-ID: <1399553779.22079.316.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 12:56:31 -0000 On Thu, 2014-05-08 at 01:11 -0700, Adrian Chadd wrote: > This: > > ===> lib/clang/libclangcodegen (depend) > rm -f .depend > CC='cc -isystem //usr/armv6-freebsd/usr/include > -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6-freebsd/ > -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin > -B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a > -I/usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/include > -I/usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include > -I/usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen > -I. -I/usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-gnueabi-freebsd11.0\" > -DLLVM_HOST_TRIPLE=\"armv6-unknown-freebsd11.0\" > -DDEFAULT_SYSROOT=\"/usr/armv6-freebsd\" > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGAtomic.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGBlocks.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCUDANV.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCUDARuntime.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCXX.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCXXABI.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCall.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGClass.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGCleanup.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGDecl.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGDeclCXX.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGException.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExprAgg.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExprCXX.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExprComplex.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExprConstant.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExprScalar.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjC.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjCGNU.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjCMac.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjCRuntime.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGOpenCLRuntime.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGRTTI.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGStmt.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGVTT.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGVTables.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenABITypes.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenModule.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenTBAA.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/ItaniumCXXABI.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/MicrosoftCXXABI.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/MicrosoftVBTables.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/ModuleBuilder.cpp > /usr/home/adrian/work/freebsd/embedded-arm/head/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > cc: error trying to exec 'cc1plus': execvp: No such file or directory > mkdep: compile failed > *** Error code 1 > > > from .. > > # make XDEV=arm XDEV_ARCH=armv6 WITH_GCC_BOOTSTRAP=1 > WITHOUT_CLANG_BOOTSTRAP=1 WITHOUT_CLANG_IS_CC=1 xdev > > > .. so what am I doing wrong? > > > > -a Change WITHOUT_CLANG_IS_CC to WITHOUT_CLANG and it should work. I don't know why, I think we've still got a bit of a mess with this stuff, but -- determined experimentally -- that works for me. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 8 16:27:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2619AD3F; Thu, 8 May 2014 16:27:15 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA12162D; Thu, 8 May 2014 16:27:14 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id i8so3128532qcq.32 for ; Thu, 08 May 2014 09:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JbtaTZple+IpMfNEQjO5lGxgCK1FXbDWWtCBgrhQ2cg=; b=Asf0Ox2LLwcL/i81UvQh3EF8QZbshs+BTGFQNexUmnYfVcaU2GY0+jzycYRMayOdx1 iXRurYAxvt/PPLhgEBtS/OBkv24PqnICJZO65n1hB9zegjPZkKFbl1eFBBzzmn32AEvF Z/WD//hy+EANrW6iVfFiTEueibOWqYQzre9vvrGyPsBOoaNsiKszsOcTDKZgHubVHkhc BuPPHyGp6pEF2RhwLQ+a2+Psuznd48QE1TGoF1OSEphLUuwXu+kvYW0P7YWPr095Mmq3 pccwbBuD7qtAWncntYkBXNs6wT+68jAQg2LNx+1d4Ke703w3c9dugkKktrWxSDOU1Ze9 U4Kg== MIME-Version: 1.0 X-Received: by 10.224.16.199 with SMTP id p7mr6687718qaa.76.1399566433522; Thu, 08 May 2014 09:27:13 -0700 (PDT) Received: by 10.96.51.38 with HTTP; Thu, 8 May 2014 09:27:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 May 2014 12:27:13 -0400 Message-ID: Subject: Re: Anybody using an Adafruit PiTFT display? From: Alan Corey To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:27:15 -0000 In Linux you define FRAMEBUFFER = /DEV/FB1 On 5/8/14, Adrian Chadd wrote: > Hm, looks like someone would need to write a VT driver for the thing. > > I don't know about how to get X onto it though. Do we have any support > for X to render to VT console? > > > -a > > > On 8 May 2014 00:36, Alan Corey wrote: >> Adafruit doesn't support anything but Raspbian officially, but one guy >> there is a NetBSD user. I'm not really qualified but I bought the >> display and I'm starting to look into making it work under FreeBSD, >> but only because OpenBSD doesn't support the Pi and I don't like >> Linux. I've been using OpenBSD about 14 years, once in a while >> FreeBSD. >> >> It uses a framebuffer which I'm not totally familiar with, and console >> output and X output can appear on its screen. It's a 2.8 inch TFT LCD >> with LED backlight and touchscreen, plugs into the GPIO connector. >> It's supported partly by Adafruit's patches to the Linux kernel, >> connects mostly to the SPI interface and a couple GPIO pins, sells for >> about $40. >> >> If I do a dmesg to a file, then shut down, plug in the board, boot >> back up and do a dmesg to another file and compare the files it looks >> like nothing on the board is recognized. New hobby. >> >> Anyone done anything with one? >> >> Alan >> >> -- >> Credit is the root of all evil. - AB1JX >> _______________________________________________ >> 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" > -- Credit is the root of all evil. - AB1JX From owner-freebsd-arm@FreeBSD.ORG Thu May 8 17:06:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0608C8E; Thu, 8 May 2014 17:06:26 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 808A9A06; Thu, 8 May 2014 17:06:26 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id ih12so2792698qab.12 for ; Thu, 08 May 2014 10:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lRyrWRtENXdL96wZcjyFt8yiANnsRGUr2Cw2SuPtZH0=; b=TMX+tW4O077H71aNQAzbBUf7pDkf103UXpeCUx9BAVvjSKE8R/RFpjWjG/JEMXvgCy OV1lO/5naX3m2DL8l8iJlU7QKWsKve78ilRLxW7sECz2fjf1jN9ZGeTO1ocO8s35HGMu 8NSxVwa1WXj6FHNop9UqdtFz8tQbyICvlGpi/AGMMye/X56r5yZ6SVJ7oFxSSgHceUpT ahoHKTPP+djR1Xe4oujQexMaosjb6NR7IqpQ1fYYv3O+fndb5lzEAhCeHmnZvfC/MFpi t6AbRUPakFr1D3hYm6B3jjubxazXGggl34er3QqLoVGq5sIZ30kxmh61x+NSVBwu9CHf Q8bA== MIME-Version: 1.0 X-Received: by 10.224.38.138 with SMTP id b10mr6864735qae.98.1399568785672; Thu, 08 May 2014 10:06:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Thu, 8 May 2014 10:06:25 -0700 (PDT) In-Reply-To: <1399553779.22079.316.camel@revolution.hippie.lan> References: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> <1399553779.22079.316.camel@revolution.hippie.lan> Date: Thu, 8 May 2014 10:06:25 -0700 X-Google-Sender-Auth: MxreW3Dcz3Bn-4BKochLQNDdu2g Message-ID: Subject: Re: required xdev line to build r-pi on crochet? From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:06:26 -0000 [snip] Ok. Thanks Ian/Warner. The line that currently works for me is: make XDEV=arm XDEV_ARCH=armv6 WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG_BOOTSTRAP=1 WITHOUT_CLANG=1 xdev -a From owner-freebsd-arm@FreeBSD.ORG Fri May 9 02:28:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0212CC2; Fri, 9 May 2014 02:28:57 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 520671F2; Fri, 9 May 2014 02:28:57 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id dc16so3499678qab.14 for ; Thu, 08 May 2014 19:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c38DDeL5umzTcz9ebCFZUyMMvAif+5Jvx8UJ6rt/0yw=; b=wd4JdKDClHgfMavnsciGD0Yo0r8y9jktCjIft284GkD40JyCp8+Wsjk1FBsORVYr7e Dcp9osoGuhdhwYWQja1T8LhIyAHRJPqb5NmgCd7lUIvG1+o/jyFWNrCxHv3ViTBKKAfI oNjQfKSp5wBBPTB3uSd6l7qhDIqdY6i7ctwRqsJXuOFpXw3/nb1i107e8tYUJVl3budY JraDZG2k0AUU++24BUCyIKhUrSnYeq1mDFvdlFAajs8vcOcoCFnTZSsGVaGU6FMLllbz YuzVj8V4tlbsIEkv1vAKKuUsl1OkdbLcyL1LSHYOjhqSjEJxNLvrwulUdrCt2H4pWxOq NrIw== MIME-Version: 1.0 X-Received: by 10.140.28.198 with SMTP id 64mr9959738qgz.49.1399602536499; Thu, 08 May 2014 19:28:56 -0700 (PDT) Received: by 10.96.51.38 with HTTP; Thu, 8 May 2014 19:28:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 May 2014 22:28:56 -0400 Message-ID: Subject: Re: Anybody using an Adafruit PiTFT display? From: Alan Corey To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 02:28:57 -0000 This sent prematurely and wasn't complete. In Linux you define FRAMEBUFFER = /dev/fb1 in the environment, then you can type startx even in an ssh session and X opens on the PiTFT. Seems like some of that has to be kernel stuff to create a /dev/fb device but somehow that connects to X. The touchscreen is handled as an X input. dmesg shows me: dmesg | grep fb fb0: on fdtbus0 fb0: 656x416(0x0@0,0) 16bpp fb0: pitch 1312, base 0x5e006000, screen_size 545792 But I think that's just the Pi, not the TFT. I'm still downloading stuff to look at. On 5/8/14, Alan Corey wrote: > In Linux you define FRAMEBUFFER = /DEV/FB1 > > On 5/8/14, Adrian Chadd wrote: >> Hm, looks like someone would need to write a VT driver for the thing. >> >> I don't know about how to get X onto it though. Do we have any support >> for X to render to VT console? >> >> >> -a >> >> >> On 8 May 2014 00:36, Alan Corey wrote: >>> Adafruit doesn't support anything but Raspbian officially, but one guy >>> there is a NetBSD user. I'm not really qualified but I bought the >>> display and I'm starting to look into making it work under FreeBSD, >>> but only because OpenBSD doesn't support the Pi and I don't like >>> Linux. I've been using OpenBSD about 14 years, once in a while >>> FreeBSD. >>> >>> It uses a framebuffer which I'm not totally familiar with, and console >>> output and X output can appear on its screen. It's a 2.8 inch TFT LCD >>> with LED backlight and touchscreen, plugs into the GPIO connector. >>> It's supported partly by Adafruit's patches to the Linux kernel, >>> connects mostly to the SPI interface and a couple GPIO pins, sells for >>> about $40. >>> >>> If I do a dmesg to a file, then shut down, plug in the board, boot >>> back up and do a dmesg to another file and compare the files it looks >>> like nothing on the board is recognized. New hobby. >>> >>> Anyone done anything with one? >>> >>> Alan >>> >>> -- >>> Credit is the root of all evil. - AB1JX >>> _______________________________________________ >>> 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" >> > > > -- > Credit is the root of all evil. - AB1JX > -- Credit is the root of all evil. - AB1JX From owner-freebsd-arm@FreeBSD.ORG Fri May 9 14:27:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBD069CF; Fri, 9 May 2014 14:27:01 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7284B7B; Fri, 9 May 2014 14:27:01 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 973941FE02B; Fri, 9 May 2014 16:27:00 +0200 (CEST) Message-ID: <536CE5E9.8020408@selasky.org> Date: Fri, 09 May 2014 16:27:53 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd , Ian Lepore Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> In-Reply-To: <5368AC03.8080401@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 14:27:02 -0000 Hi, I've tried to dig through the DWC OTG controller to make it work better in host mode. Can you test the latest code after: http://svnweb.freebsd.org/changeset/base/265777 And report any errors/regression issues when using USB devices? --HPS From owner-freebsd-arm@FreeBSD.ORG Fri May 9 15:06:37 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B578598; Fri, 9 May 2014 15:06:37 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8C80F03; Fri, 9 May 2014 15:06:36 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WimNY-000KID-UJ; Fri, 09 May 2014 15:06:29 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s49F6Q94030467; Fri, 9 May 2014 09:06:26 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX191hyW7KEpDlLyNrT+jsF16 Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <536CE5E9.8020408@selasky.org> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 09 May 2014 09:06:26 -0600 Message-ID: <1399647986.22079.367.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:06:37 -0000 On Fri, 2014-05-09 at 16:27 +0200, Hans Petter Selasky wrote: > Hi, > > I've tried to dig through the DWC OTG controller to make it work better > in host mode. Can you test the latest code after: > > http://svnweb.freebsd.org/changeset/base/265777 > > And report any errors/regression issues when using USB devices? > > --HPS After updating to r265780 and building clean, I consitantly get this when the rpi boots: KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #0 r265780M: Fri May 9 08:44:47 MDT 2014 ilepore@revolution.hippie.lan:/local/build/staging/freebsd/rpi/obj/arm.armv6/local/build/staging/freebsd/rpi/src/sys/RPI-B-serial arm gcc version 4.2.1 20070831 patched [FreeBSD] CPU: ARM1176JZ-S rev 7 (ARM11J core) Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext WB enabled LABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 134213632 (127 MB) avail memory = 123858944 (118 MB) random device not loaded; using insecure entropy random: initialized ofwbus0: simplebus0: mem 0x20000000-0x20ffffff on ofwbus0 intc0: mem 0xb200-0xb3ff on simplebus0 systimer0: mem 0x3000-0x3fff irq 8,9,10,11 on simplebus0 Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000 Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000 bcmwd0: mem 0x10001c-0x100027 on simplebus0 gpio0: mem 0x200000-0x2000af irq 57,59,58,60 on simplebus0 gpio0: read-only pins: 46,47,48,49,50,51,52,53. gpio0: reserved pins: 48,49,50,51,52,53. gpioc0: on gpio0 gpiobus0: on gpio0 gpioled0: at pin(s) 16 on gpiobus0 bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 mbox0: mem 0xb880-0xb8bf irq 1 on simplebus0 sdhci_bcm0: mem 0x300000-0x3000ff irq 70 on simplebus0 mmc0: on sdhci_bcm0 uart0: mem 0x201000-0x201fff irq 65 on simplebus0 uart0: console (115200,n,8,1) dwcotg0: mem 0x980000-0x99ffff irq 17 on simplebus0 usbus0 on dwcotg0 simplebus1: on ofwbus0 simplebus1: could not get ranges device_attach: simplebus1 attach returned 6 Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block bootpc_init: wired to interface 'ue0' mmcsd0: Error indicated: 2 Bad CRC uhub0: 1 port with 1 removable, self powered ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled uhub1: 3 ports with 2 removable, self powered random: unblocking device. ugen0.3: at usbus0 smsc0: on usbus0 uhub_reattach_port: device problem (USB_ERR_STALLED), disabling port 3 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: 1e:b3:27:cd:38:f3 smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN Sending DHCP Discover packet from interface ue0 (1e:b3:27:cd:38:f3) ue0: link state changed to UP Received DHCP Offer packet on ue0 from 0.0.0.0 (accepted) Sending DHCP Request packet from interface ue0 (1e:b3:27:cd:38:f3) Received DHCP Ack packet on ue0 from 0.0.0.0 (accepted) ue0 at 172.22.42.71 server 0.0.0.0 subnet mask 255.255.255.0 router 172.22.42.254 rootfs 172.22.42.240:/rpi Adjusted interface ue0 Trying to mount root from nfs:172.22.42.240:/rpi [ro,noatime]... NFS ROOT: 172.22.42.240:/rpi warning: no time-of-day clock registered, system time will not be set accurately warning: no time-of-day clock registered, system time will not be set accurately smsc0: error: usb error on tx: USB_ERR_IOERROR smsc0: warning: bulk read error, USB_ERR_IOERROR smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy ue0: link state changed to DOWN smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: at uhub1, port 1, addr 3 (disconnected) smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy ukphy0: detached miibus0: detached smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: be:a4:34:6d:c5:2a newnfs server 172.22.42.240:/rpi: not responding newnfs server 172.22.42.240:/rpi: not responding newnfs server 172.22.42.240:/rpi: not responding It's interesting that it worked well enough to mount the nfsroot filesystem, then went bad after that. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri May 9 16:41:39 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A739268F; Fri, 9 May 2014 16:41:39 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 522969AF; Fri, 9 May 2014 16:41:39 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 122551FE02B; Fri, 9 May 2014 18:41:38 +0200 (CEST) Message-ID: <536D0575.1040407@selasky.org> Date: Fri, 09 May 2014 18:42:29 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> In-Reply-To: <1399647986.22079.367.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 16:41:39 -0000 On 05/09/14 17:06, Ian Lepore wrote: > On Fri, 2014-05-09 at 16:27 +0200, Hans Petter Selasky wrote: >> Hi, >> >> I've tried to dig through the DWC OTG controller to make it work better >> in host mode. Can you test the latest code after: >> >> http://svnweb.freebsd.org/changeset/base/265777 >> >> And report any errors/regression issues when using USB devices? >> >> --HPS > > After updating to r265780 and building clean, I consitantly get this > when the rpi boots: > > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2014 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 11.0-CURRENT #0 r265780M: Fri May 9 08:44:47 MDT 2014 > ilepore@revolution.hippie.lan:/local/build/staging/freebsd/rpi/obj/arm.armv6/local/build/staging/freebsd/rpi/src/sys/RPI-B-serial arm > gcc version 4.2.1 20070831 patched [FreeBSD] > CPU: ARM1176JZ-S rev 7 (ARM11J core) > Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext > WB enabled LABT branch prediction enabled > 16KB/32B 4-way instruction cache > 16KB/32B 4-way write-back-locking-C data cache > real memory = 134213632 (127 MB) > avail memory = 123858944 (118 MB) > random device not loaded; using insecure entropy > random: initialized > ofwbus0: > simplebus0: mem 0x20000000-0x20ffffff on ofwbus0 > intc0: mem 0xb200-0xb3ff on simplebus0 > systimer0: mem 0x3000-0x3fff irq 8,9,10,11 on simplebus0 > Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000 > Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000 > bcmwd0: mem 0x10001c-0x100027 on simplebus0 > gpio0: mem 0x200000-0x2000af irq 57,59,58,60 on simplebus0 > gpio0: read-only pins: 46,47,48,49,50,51,52,53. > gpio0: reserved pins: 48,49,50,51,52,53. > gpioc0: on gpio0 > gpiobus0: on gpio0 > gpioled0: at pin(s) 16 on gpiobus0 > bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 > mbox0: mem 0xb880-0xb8bf irq 1 on simplebus0 > sdhci_bcm0: mem 0x300000-0x3000ff irq 70 on simplebus0 > mmc0: on sdhci_bcm0 > uart0: mem 0x201000-0x201fff irq 65 on simplebus0 > uart0: console (115200,n,8,1) > dwcotg0: mem 0x980000-0x99ffff irq 17 on simplebus0 > usbus0 on dwcotg0 > simplebus1: on ofwbus0 > simplebus1: could not get ranges > device_attach: simplebus1 attach returned 6 > Timecounters tick every 10.000 msec > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block > bootpc_init: wired to interface 'ue0' > mmcsd0: Error indicated: 2 Bad CRC > uhub0: 1 port with 1 removable, self powered > ugen0.2: at usbus0 > uhub1: on usbus0 > uhub1: MTT enabled > uhub1: 3 ports with 2 removable, self powered > random: unblocking device. > ugen0.3: at usbus0 > smsc0: on usbus0 > uhub_reattach_port: device problem (USB_ERR_STALLED), disabling port 3 > smsc0: chip 0xec00, rev. 0002 > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: 1e:b3:27:cd:38:f3 > smsc0: chip 0xec00, rev. 0002 > ue0: link state changed to DOWN > Sending DHCP Discover packet from interface ue0 (1e:b3:27:cd:38:f3) > ue0: link state changed to UP > Received DHCP Offer packet on ue0 from 0.0.0.0 (accepted) > Sending DHCP Request packet from interface ue0 (1e:b3:27:cd:38:f3) > Received DHCP Ack packet on ue0 from 0.0.0.0 (accepted) > ue0 at 172.22.42.71 server 0.0.0.0 > subnet mask 255.255.255.0 router 172.22.42.254 rootfs 172.22.42.240:/rpi > Adjusted interface ue0 > Trying to mount root from nfs:172.22.42.240:/rpi [ro,noatime]... > NFS ROOT: 172.22.42.240:/rpi > warning: no time-of-day clock registered, system time will not be set accurately > warning: no time-of-day clock registered, system time will not be set accurately > smsc0: error: usb error on tx: USB_ERR_IOERROR > smsc0: warning: bulk read error, USB_ERR_IOERROR > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > ue0: link state changed to DOWN > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: at uhub1, port 1, addr 3 (disconnected) > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > ukphy0: detached > miibus0: detached > smsc0: on usbus0 > smsc0: chip 0xec00, rev. 0002 > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: be:a4:34:6d:c5:2a > newnfs server 172.22.42.240:/rpi: not responding > newnfs server 172.22.42.240:/rpi: not responding > newnfs server 172.22.42.240:/rpi: not responding > > It's interesting that it worked well enough to mount the nfsroot > filesystem, then went bad after that. > > -- Ian Can you try and upgrade again: http://svnweb.freebsd.org/changeset/base/265783 --HPS From owner-freebsd-arm@FreeBSD.ORG Fri May 9 18:41:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C9E22EC; Fri, 9 May 2014 18:41:41 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF81B38E; Fri, 9 May 2014 18:41:40 +0000 (UTC) Received: from [192.168.1.103] (p508F035A.dip0.t-ipconnect.de [80.143.3.90]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D09241C104983; Fri, 9 May 2014 20:41:36 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Michael Tuexen In-Reply-To: <536D0575.1040407@selasky.org> Date: Fri, 9 May 2014 20:41:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49CC5BC3-1AC9-44A2-A529-CE6C0F2452D5@fh-muenster.de> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 18:41:41 -0000 On 09 May 2014, at 18:42, Hans Petter Selasky wrote: > On 05/09/14 17:06, Ian Lepore wrote: >> On Fri, 2014-05-09 at 16:27 +0200, Hans Petter Selasky wrote: >>> Hi, >>>=20 >>> I've tried to dig through the DWC OTG controller to make it work = better >>> in host mode. Can you test the latest code after: >>>=20 >>> http://svnweb.freebsd.org/changeset/base/265777 >>>=20 >>> And report any errors/regression issues when using USB devices? >>>=20 >>> --HPS >>=20 >> After updating to r265780 and building clean, I consitantly get this >> when the rpi boots: >>=20 >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2014 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 11.0-CURRENT #0 r265780M: Fri May 9 08:44:47 MDT 2014 >> = ilepore@revolution.hippie.lan:/local/build/staging/freebsd/rpi/obj/arm.arm= v6/local/build/staging/freebsd/rpi/src/sys/RPI-B-serial arm >> gcc version 4.2.1 20070831 patched [FreeBSD] >> CPU: ARM1176JZ-S rev 7 (ARM11J core) >> Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext >> WB enabled LABT branch prediction enabled >> 16KB/32B 4-way instruction cache >> 16KB/32B 4-way write-back-locking-C data cache >> real memory =3D 134213632 (127 MB) >> avail memory =3D 123858944 (118 MB) >> random device not loaded; using insecure entropy >> random: initialized >> ofwbus0: >> simplebus0: mem = 0x20000000-0x20ffffff on ofwbus0 >> intc0: mem 0xb200-0xb3ff on simplebus0 >> systimer0: mem 0x3000-0x3fff irq 8,9,10,11 on = simplebus0 >> Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000 >> Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000 >> bcmwd0: mem 0x10001c-0x100027 on simplebus0 >> gpio0: mem 0x200000-0x2000af irq = 57,59,58,60 on simplebus0 >> gpio0: read-only pins: 46,47,48,49,50,51,52,53. >> gpio0: reserved pins: 48,49,50,51,52,53. >> gpioc0: on gpio0 >> gpiobus0: on gpio0 >> gpioled0: at pin(s) 16 on gpiobus0 >> bcm_dma0: mem = 0x7000-0x7fff,0xe05000-0xe05fff irq = 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 >> mbox0: mem 0xb880-0xb8bf irq 1 on = simplebus0 >> sdhci_bcm0: mem 0x300000-0x3000ff = irq 70 on simplebus0 >> mmc0: on sdhci_bcm0 >> uart0: mem 0x201000-0x201fff irq 65 on = simplebus0 >> uart0: console (115200,n,8,1) >> dwcotg0: mem = 0x980000-0x99ffff irq 17 on simplebus0 >> usbus0 on dwcotg0 >> simplebus1: on ofwbus0 >> simplebus1: could not get ranges >> device_attach: simplebus1 attach returned 6 >> Timecounters tick every 10.000 msec >> usbus0: 480Mbps High Speed USB v2.0 >> ugen0.1: at usbus0 >> uhub0: on = usbus0 >> mmcsd0: 8GB at = mmc0 50.0MHz/4bit/65535-block >> bootpc_init: wired to interface 'ue0' >> mmcsd0: Error indicated: 2 Bad CRC >> uhub0: 1 port with 1 removable, self powered >> ugen0.2: at usbus0 >> uhub1: on usbus0 >> uhub1: MTT enabled >> uhub1: 3 ports with 2 removable, self powered >> random: unblocking device. >> ugen0.3: at usbus0 >> smsc0: on = usbus0 >> uhub_reattach_port: device problem (USB_ERR_STALLED), disabling port = 3 >> smsc0: chip 0xec00, rev. 0002 >> miibus0: on smsc0 >> ukphy0: PHY 1 on miibus0 >> ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> ue0: on smsc0 >> ue0: Ethernet address: 1e:b3:27:cd:38:f3 >> smsc0: chip 0xec00, rev. 0002 >> ue0: link state changed to DOWN >> Sending DHCP Discover packet from interface ue0 (1e:b3:27:cd:38:f3) >> ue0: link state changed to UP >> Received DHCP Offer packet on ue0 from 0.0.0.0 (accepted) >> Sending DHCP Request packet from interface ue0 (1e:b3:27:cd:38:f3) >> Received DHCP Ack packet on ue0 from 0.0.0.0 (accepted) >> ue0 at 172.22.42.71 server 0.0.0.0 >> subnet mask 255.255.255.0 router 172.22.42.254 rootfs = 172.22.42.240:/rpi >> Adjusted interface ue0 >> Trying to mount root from nfs:172.22.42.240:/rpi [ro,noatime]... >> NFS ROOT: 172.22.42.240:/rpi >> warning: no time-of-day clock registered, system time will not be set = accurately >> warning: no time-of-day clock registered, system time will not be set = accurately >> smsc0: error: usb error on tx: USB_ERR_IOERROR >> smsc0: warning: bulk read error, USB_ERR_IOERROR >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> ue0: link state changed to DOWN >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: at uhub1, port 1, addr 3 (disconnected) >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> ukphy0: detached >> miibus0: detached >> smsc0: on = usbus0 >> smsc0: chip 0xec00, rev. 0002 >> miibus0: on smsc0 >> ukphy0: PHY 1 on miibus0 >> ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> ue0: on smsc0 >> ue0: Ethernet address: be:a4:34:6d:c5:2a >> newnfs server 172.22.42.240:/rpi: not responding >> newnfs server 172.22.42.240:/rpi: not responding >> newnfs server 172.22.42.240:/rpi: not responding >>=20 >> It's interesting that it worked well enough to mount the nfsroot >> filesystem, then went bad after that. >>=20 >> -- Ian >=20 > Can you try and upgrade again: >=20 > http://svnweb.freebsd.org/changeset/base/265783 I tried it and it resolved the issue for me. Thanks for the quick fix. Best regards Michael >=20 > --HPS >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@FreeBSD.ORG Fri May 9 18:49:43 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E75B8B2 for ; Fri, 9 May 2014 18:49:43 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09A4665F for ; Fri, 9 May 2014 18:49:42 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WiprZ-000FR0-5i; Fri, 09 May 2014 18:49:41 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s49Incg0030597; Fri, 9 May 2014 12:49:38 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19OztuVFsqVNmX6PbcsHDqo Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <536D0575.1040407@selasky.org> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 09 May 2014 12:49:38 -0600 Message-ID: <1399661378.22079.376.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 18:49:43 -0000 On Fri, 2014-05-09 at 18:42 +0200, Hans Petter Selasky wrote: > On 05/09/14 17:06, Ian Lepore wrote: > > On Fri, 2014-05-09 at 16:27 +0200, Hans Petter Selasky wrote: > >> Hi, > >> > >> I've tried to dig through the DWC OTG controller to make it work better > >> in host mode. Can you test the latest code after: > >> > >> http://svnweb.freebsd.org/changeset/base/265777 > >> > >> And report any errors/regression issues when using USB devices? > >> > >> --HPS > > > > After updating to r265780 and building clean, I consitantly get this > > when the rpi boots: > > > > KDB: debugger backends: ddb > > [...] > > smsc0: warning: MII is busy > > smsc0: at uhub1, port 1, addr 3 (disconnected) > > smsc0: warning: Failed to read register 0x114 > > smsc0: warning: MII is busy > > ukphy0: detached > > miibus0: detached > > smsc0: on usbus0 > > smsc0: chip 0xec00, rev. 0002 > > miibus0: on smsc0 > > ukphy0: PHY 1 on miibus0 > > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > ue0: on smsc0 > > ue0: Ethernet address: be:a4:34:6d:c5:2a > > newnfs server 172.22.42.240:/rpi: not responding > > newnfs server 172.22.42.240:/rpi: not responding > > newnfs server 172.22.42.240:/rpi: not responding > > > > It's interesting that it worked well enough to mount the nfsroot > > filesystem, then went bad after that. > > > > -- Ian > > Can you try and upgrade again: > > http://svnweb.freebsd.org/changeset/base/265783 Yep, that fixed it, thanks. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat May 10 07:50:18 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC2408A5; Sat, 10 May 2014 07:50:18 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7184CFA9; Sat, 10 May 2014 07:50:18 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id EF01F1FE02B; Sat, 10 May 2014 09:50:16 +0200 (CEST) Message-ID: <536DDA6D.7060101@selasky.org> Date: Sat, 10 May 2014 09:51:09 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> In-Reply-To: <1399661378.22079.376.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 07:50:18 -0000 Hi, I've made one more patch to the DWC OTG driver. Nice if you can test that too. http://svnweb.freebsd.org/changeset/base/265806 BTW: I think I've found what is causing the glitches when using USB audio devices: diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c index 0490be7..de7f015 100644 --- a/sys/arm/arm/machdep.c +++ b/sys/arm/arm/machdep.c @@ -423,7 +423,7 @@ cpu_est_clockrate(int cpu_id, uint64_t *rate) void cpu_idle(int busy) { - +#if 0 CTR2(KTR_SPARE2, "cpu_idle(%d) at %d", busy, curcpu); #ifndef NO_EVENTTIMERS @@ -442,6 +442,7 @@ cpu_idle(int busy) #endif CTR2(KTR_SPARE2, "cpu_idle(%d) at %d done", busy, curcpu); +#endif } int It appears that cpu_idle() is going to sleep when there are pending interrupts, and then waking up on the next timer IRQ! Can someone familiar with these parts of the kernel comment? Please try for yourself, with and without the patch above, using an USB audio device with the RPI-B! Still when the console is printing, there are significant glitches too :-) That's because the TTY layer is synchronously writing data to the serial line. That's OK for now. --HPS From owner-freebsd-arm@FreeBSD.ORG Sat May 10 07:54:09 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39455AB3 for ; Sat, 10 May 2014 07:54:09 +0000 (UTC) Received: from server1.xenet.de (server1out.xenet.de [213.221.94.200]) by mx1.freebsd.org (Postfix) with ESMTP id A0F169C for ; Sat, 10 May 2014 07:54:07 +0000 (UTC) Received: from [10.0.0.50] (intern.xenet.de [213.221.94.50]) (authenticated bits=0) by server1.xenet.de (8.12.5/8.12.5) with ESMTP id s4A7rudC054589 for ; Sat, 10 May 2014 09:53:59 +0200 (CEST) (envelope-from meyser@xenet.de) Message-ID: <536DDB0B.7040502@xenet.de> Date: Sat, 10 May 2014 09:53:47 +0200 From: Matthias Meyser Organization: XeNET GmbH, Clausthal-Zellerfeld User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: cross compiling & Native installing Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.38 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 07:54:09 -0000 Hi I xcompile armv6 World and kernel (BEAGLEBONE) on an amd64 machine with make buildworld TARGET=arm TARGET_ARCH=armv6 make buildkernel TARGET=arm TARGET_ARCH=armv6 KERNCONF=BEAGLEBONE this works as expected. The I want to install world/kernel on the target machine (Beagelbone black) on the Beagkebone I nfsmount /usr/src /usr/doc /usr/obj exported from the build machine. then I do cd /usr/src make installkernel KERNCONF=BEAGELBONE CROSS_BUILD_TESTING=yes to install the kernel this does not work -------------------------8<--------------------------------------------- -------------------------------------------------------------- >>> Installing kernel BEAGLEBONE -------------------------------------------------------------- cd /usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE; MAKEOBJDIRPREFIX=/usr/obj/arm.armv6 MACHINE_ARCH=armv6 MACHINE=arm CPUTYPE= GROFF_BIN_PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/tmac PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games:/usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/arm.armv6/usr/src/tmp/usr/sbin:/usr/obj/arm.armv6/usr/src/tmp/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install cc: Exec format error make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 12: warning: "cc --version" returned non-zero status make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 20: Unable to determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src -------------------------8<--------------------------------------------- Any hints are welcome. uname Buildsystem: FreeBSD slx00.lan.xenet.de 10.0-STABLE FreeBSD 10.0-STABLE #1 r262074: Tue Feb 18 01:00:39 CET 2014 root@slx00.lan.xenet.de:/usr/obj/usr/src/sys/SLX00 amd64 uname Beaglebone: FreeBSD bbb.lan.xenet.de 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Thu May 8 10:16:09 CEST 2014 root@bbb.lan.xenet.de:/usr/obj/usr/src/sys/BEAGLEBONE arm /usr/src: latest head -- Matthias Meyser | XeNET GmbH Tel.: +49-5323-9489050 | 38678 Clausthal-Zellerfeld, Marktstrasse 40 Fax: +49-5323-94014 | Registergericht: Amtsgericht Braunschweig HRB 110823 Email: Meyser@xenet.de | Geschaeftsfuehrer: Matthias Meyser From owner-freebsd-arm@FreeBSD.ORG Sat May 10 08:08:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DFDEF1E; Sat, 10 May 2014 08:08:47 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C866316F; Sat, 10 May 2014 08:08:46 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j7so5181502qaq.31 for ; Sat, 10 May 2014 01:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1WOc+S5WZJgj92sQJJIXV4U9uohJ2tuFNzZjK7nSYmU=; b=mcfxGl7gQVqEKrjIxOczjTfENUqo+ZDEo+lCFB/ETZjjcsVdATbL6avmwZarE17n/Z DNylXEhkUgOtku7ZzCQ/p3MeY3n5CXKckP201t19cW9kW133uRoQt5F/uh/xgepdxZdY 7TPS6N7OgEdWepWilkw1ChbGY20zu/m3eQOoEKuNmf3UyVrpi92mBZ8BA7xFDZ0zXk/0 b4doHMSMH3BJ1DsoEzbo87flz5h6ignb5vSI1dD6WWpNGH4eryL4LK049zIh709Sjhgm q4Sa9adblNjVJHXNDsZhyy8QX5we5znEWvk1x/YCsdeO+IL+Dl65sU0Pp0Y0YDuK+kd/ S+7Q== MIME-Version: 1.0 X-Received: by 10.140.22.209 with SMTP id 75mr20346250qgn.4.1399709325601; Sat, 10 May 2014 01:08:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 10 May 2014 01:08:45 -0700 (PDT) In-Reply-To: <536DDA6D.7060101@selasky.org> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> Date: Sat, 10 May 2014 01:08:45 -0700 X-Google-Sender-Auth: nsHe4wo8O6Yr_EGW9N3mN1IpC84 Message-ID: Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Adrian Chadd To: Hans Petter Selasky , Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 08:08:47 -0000 +mav, the idle stuff and eventtimer framework is involved. (hi Mav!) -a On 10 May 2014 00:51, Hans Petter Selasky wrote: > Hi, > > I've made one more patch to the DWC OTG driver. Nice if you can test that > too. > > http://svnweb.freebsd.org/changeset/base/265806 > > BTW: I think I've found what is causing the glitches when using USB audio > devices: > > diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c > index 0490be7..de7f015 100644 > --- a/sys/arm/arm/machdep.c > +++ b/sys/arm/arm/machdep.c > @@ -423,7 +423,7 @@ cpu_est_clockrate(int cpu_id, uint64_t *rate) > void > cpu_idle(int busy) > { > - > +#if 0 > CTR2(KTR_SPARE2, "cpu_idle(%d) at %d", > busy, curcpu); > #ifndef NO_EVENTTIMERS > @@ -442,6 +442,7 @@ cpu_idle(int busy) > #endif > CTR2(KTR_SPARE2, "cpu_idle(%d) at %d done", > busy, curcpu); > +#endif > } > > int > > > It appears that cpu_idle() is going to sleep when there are pending > interrupts, and then waking up on the next timer IRQ! Can someone familiar > with these parts of the kernel comment? > > Please try for yourself, with and without the patch above, using an USB > audio device with the RPI-B! > > Still when the console is printing, there are significant glitches too :-) > That's because the TTY layer is synchronously writing data to the serial > line. That's OK for now. > > --HPS > > _______________________________________________ > 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 Sat May 10 11:48:02 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4354A8AA for ; Sat, 10 May 2014 11:48:02 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1904739C for ; Sat, 10 May 2014 11:48:01 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wj5l1-000IuE-ST; Sat, 10 May 2014 11:48:00 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4ABluPl031625; Sat, 10 May 2014 05:47:56 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/YulGlWWrLZTK8xNLaZ1P+ Subject: Re: cross compiling & Native installing From: Ian Lepore To: Matthias Meyser In-Reply-To: <536DDB0B.7040502@xenet.de> References: <536DDB0B.7040502@xenet.de> Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 May 2014 05:47:55 -0600 Message-ID: <1399722475.22079.382.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 11:48:02 -0000 On Sat, 2014-05-10 at 09:53 +0200, Matthias Meyser wrote: > Hi > > I xcompile armv6 World and kernel (BEAGLEBONE) on an amd64 machine with > > make buildworld TARGET=arm TARGET_ARCH=armv6 > make buildkernel TARGET=arm TARGET_ARCH=armv6 KERNCONF=BEAGLEBONE > > this works as expected. > > The I want to install world/kernel on the target machine (Beagelbone black) > > on the Beagkebone I nfsmount /usr/src /usr/doc /usr/obj exported from > the build machine. > > then I do > > cd /usr/src > make installkernel KERNCONF=BEAGELBONE CROSS_BUILD_TESTING=yes > > to install the kernel this does not work > > -------------------------8<--------------------------------------------- > -------------------------------------------------------------- > >>> Installing kernel BEAGLEBONE > -------------------------------------------------------------- > cd /usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE; > MAKEOBJDIRPREFIX=/usr/obj/arm.armv6 MACHINE_ARCH=armv6 MACHINE=arm > CPUTYPE= GROFF_BIN_PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/tmac > PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games:/usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/arm.armv6/usr/src/tmp/usr/sbin:/usr/obj/arm.armv6/usr/src/tmp/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > make KERNEL=kernel install > cc: Exec format error > make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 12: warning: "cc > --version" returned non-zero status > make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 20: Unable to determine > compiler type for cc. Consider setting COMPILER_TYPE. > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > -------------------------8<--------------------------------------------- > > Any hints are welcome. > > uname Buildsystem: > FreeBSD slx00.lan.xenet.de 10.0-STABLE FreeBSD 10.0-STABLE #1 r262074: Tue > Feb 18 01:00:39 CET 2014 > root@slx00.lan.xenet.de:/usr/obj/usr/src/sys/SLX00 amd64 > > uname Beaglebone: > FreeBSD bbb.lan.xenet.de 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Thu May 8 > 10:16:09 CEST 2014 root@bbb.lan.xenet.de:/usr/obj/usr/src/sys/BEAGLEBONE > arm > > /usr/src: latest head > > I think it's the CROSS_BUILD_TESTING that's causing the problem. It's trying to run the x86 cross-tools during the native install. Try replacing that with MAKEOBJDIRPREFIX=/usr/obj/arm.armv6. I'm not sure that'll work, I've never tried to do what you're doing... I do the install on the same machine as the cross-builds, using make installworld TARGET_ARCH=armv6 DESTDIR=/path/to/nfsroot and likewise for installkernel but with KERNCONF added. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat May 10 11:56:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1B57ADD for ; Sat, 10 May 2014 11:56:37 +0000 (UTC) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CF60654 for ; Sat, 10 May 2014 11:56:37 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id t61so4916125wes.25 for ; Sat, 10 May 2014 04:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=qVCYRobxP6TPyBTXDDPgai2MY2dwLKJX+CfjzwhPYAw=; b=eRThK1dkbScN0v2GCQ5avBZ60MM9ooAkJRVdTKndDatLKrUxLCc00FK9Q2VlsfOHg1 U2n4rmmQTReiSbZRp9xNvCxlYUdWBsYa1lf+rDMgirpVGSSmsgtyACghVRiD6wYi21ep 2whWH41te2QeRbiueDBfjL6IsLc9wx5mnKoYmo6F3LKR2GoNKMB58pB7jNG8HGH9bY+O ZcXWfltmFMl+Jkh8rSOIDDFCYDSJRUo38okFqiolyYEpXji4Z8VGzJmO8p2SvBk0695S 2oIzZLXS7uXU2mHvhPQ4RjJS3yxvCSSt6qc8JgewHdAQl/YPlPBM/WN/lWIA2H/drwGy UHaQ== X-Received: by 10.194.84.208 with SMTP id b16mr169724wjz.55.1399722995325; Sat, 10 May 2014 04:56:35 -0700 (PDT) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id ej2sm9245674wjd.21.2014.05.10.04.56.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 May 2014 04:56:34 -0700 (PDT) From: fabiodive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Beaglebone Black. PWM minimum frequency of 1.52KHz Message-Id: Date: Sat, 10 May 2014 12:56:32 +0100 To: freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 11:56:38 -0000 Hello, PWM on Beaglebone Black during my laboratory tests I was not able to setup a frequency suitable = for servo motors. I tried several times with many values but the results was always the = same. The minimal frequency I was able to achieve was 1.52 KHz. Also, I noticed odd results with the most of configuration values, in = this case I lost the PWM output signal. I tried some combinations, measuring the results with an oscilloscope, = the period configuration key appears to loose its nanoseconds meaning beyond a = value:=20 # sysctl dev.am335x_pwm.1.period=3D1500 # sysctl dev.am335x_pwm.1.dutyA=3D300 result frequency: 66 KHz ->should be 666 KHz length of period: 15 us ->should be 1.5 us length of pulse: 2 us # sysctl dev.am335x_pwm.1.period=3D1500000 # sysctl dev.am335x_pwm.1.dutyA=3D10000 result frequency: 1.71 KHz -> should be 666Hz length of period: 585 us length of pulse: 100 us # sysctl dev.am335x_pwm.1.period=3D1800000 # sysctl dev.am335x_pwm.1.dutyA=3D10000 result frequency: 3.24 KHz -> should be 555Hz length of period: 308 us length of pulse: 100 us the testing platform: Beaglebone Black - FreeBSD 11 - uboot 2014.1 root@beaglebone:~ # uname -ar FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265728: Fri May = 9 06:59:54 WEST 2014 (follow dmesg with some sdhci register dumps) root@beaglebone:~ # dmesg Copyright (c) 1992-2014 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 11.0-CURRENT #0 r265728: Fri May 9 06:59:54 WEST 2014 = seaman@bluewaters:/usr/local/crochet-freebsd/work/obj/arm.armv6/usr/local/= freebsd_src_11/sys/BBBELFARO arm FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 module run already present! module runfw_fw already present! CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1=20 Cache level 1:=20 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2:=20 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory =3D 536870912 (512 MB) avail memory =3D 516030464 (492 MB) Texas Instruments AM3358 Processor, Revision ES1.1 wlan: mac acl policy registered random: initialized ofwbus0: simplebus0: on ofwbus0 aintc0: mem 0x48200000-0x48200fff on = simplebus0 aintc0: Revision 5.0 ti_scm0: mem 0x44e10000-0x44e11fff on simplebus0 am335x_prcm0: mem = 0x44e00000-0x44e012ff on simplebus0 am335x_prcm0: Clocks: System 24.0 MHz, CPU 1000 MHz am335x_dmtimer0: mem = 0x44e05000-0x44e05fff,0x44e31000-0x44e31fff,0x48040000-0x48040fff,0x480420= 00-0x48042fff,0x48044000-0x48044fff,0x48046000-0x48046fff,0x48048000-0x480= 48fff,0x4804a000-0x4804afff irq 66,67,68,69,92,93,94,95 on simplebus0 Timecounter "AM335x Timecounter" frequency 24000000 Hz quality 1000 Event timer "AM335x Eventtimer" frequency 24000000 Hz quality 1000 ti_adc0: mem 0x44e0d000-0x44e0efff irq 16 on = simplebus0 ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0 gpio0: mem = 0x44e07000-0x44e07fff,0x4804c000-0x4804cfff,0x481ac000-0x481acfff,0x481ae0= 00-0x481aefff irq 96,97,98,99,32,33,62,63 on simplebus0 gpioc0: on gpio0 gpiobus0: on gpio0 gpioled0: at pin(s) 53 on gpiobus0 gpioled1: at pin(s) 54 on gpiobus0 gpioled2: at pin(s) 55 on gpiobus0 gpioled3: at pin(s) 56 on gpiobus0 uart0: mem 0x44e09000-0x44e09fff irq 72 on = simplebus0 uart0: console (115384,n,8,1) ti_edma30: mem = 0x49000000-0x490fffff,0x49800000-0x498fffff,0x49900000-0x499fffff,0x49a000= 00-0x49afffff irq 12,13,14 on simplebus0 ti_edma30: EDMA revision 40014c00 sdhci_ti0: mem 0x48060000-0x48060fff irq 64 on = simplebus0 mmc0: on sdhci_ti0 sdhci_ti1: mem 0x481d8000-0x481d8fff irq 28 on = simplebus0 mmc1: on sdhci_ti1 cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq = 40,41,42,43 on simplebus0 cpsw0: CPSW SS Version 1.12 (0) cpsw0: Initial queue size TX=3D128 RX=3D384 cpsw0: Ethernet address: 90:59:af:69:c1:b4 miibus0: on cpsw0 smscphy0: PHY 0 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto iichb0: mem 0x44e0b000-0x44e0bfff irq 70 on = simplebus0 iichb0: I2C revision 4.0 iicbus0: on iichb0 iic0: on iicbus0 am335x_pmic0: at addr 0x24 on iicbus0 iichb1: mem 0x4802a000-0x4802afff irq 71 on = simplebus0 iichb1: I2C revision 4.0 iicbus1: on iichb1 iic1: on iicbus1 iichb2: mem 0x4819c000-0x4819cfff irq 30 on = simplebus0 iichb2: I2C revision 4.0 iicbus2: on iichb2 iic2: on iicbus2 am335x_pwm0: mem = 0x48300000-0x483000ff,0x48300100-0x4830017f,0x48300180-0x483001ff,0x483002= 00-0x4830025f irq 86,58 on simplebus0 am335x_pwm1: mem = 0x48302000-0x483020ff,0x48302100-0x4830217f,0x48302180-0x483021ff,0x483022= 00-0x4830225f irq 87,59 on simplebus0 am335x_pwm2: mem = 0x48304000-0x483040ff,0x48304100-0x4830417f,0x48304180-0x483041ff,0x483042= 00-0x4830425f irq 88,60 on simplebus0 musbotg0: mem = 0x47400000-0x47400fff,0x47401000-0x474012ff,0x47401300-0x474013ff,0x474014= 00-0x474017ff,0x47401800-0x47401aff,0x47401b00-0x47401bff,0x47401c00-0x474= 01fff irq 17,18,19 on simplebus0 musbotg0: TI AM335X USBSS v0.0.13 usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus0 on musbotg0 usbus1: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus1 on musbotg0 ti_pruss0: mem = 0x4a300000-0x4a37ffff irq 20,21,22,23,24,25,26,27 on simplebus0 ti_pruss0: AM33xx PRU-ICSS Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: = on usbus0 ugen1.1: at usbus1 uhub1: = on usbus1 mmcsd0: 4GB at mmc0 = 48.0MHz/4bit/65535-block uhub1: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered ugen1.2: at usbus1 run0: <1.0> on usbus1 run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address = bc:f6:85:66:b8:1b random: unblocking device. sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active = command. sdhci_ti1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti1-slot0: =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 sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active = command. sdhci_ti1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti1-slot0: =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 sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active = command. sdhci_ti1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti1-slot0: =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 sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active = command. sdhci_ti1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti1-slot0: =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 am335x_pmic0: TPS65217C ver 1.2 powered by AC Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... warning: no time-of-day clock registered, system time will not be set = accurately wlan0: Ethernet address: bc:f6:85:66:b8:1b run0: firmware RT2870 ver. 0.33 loaded run0: firmware RT2870 ver. 0.33 loaded thank you! cheers, f.= From owner-freebsd-arm@FreeBSD.ORG Sat May 10 12:25:02 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD7A439B; Sat, 10 May 2014 12:25:02 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 265398FE; Sat, 10 May 2014 12:25:02 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wj6Kq-0007Om-Qe; Sat, 10 May 2014 12:25:00 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4ACOvPO031642; Sat, 10 May 2014 06:24:57 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19wvFaFCQ2/t8L6xpHXZJI9 Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <536DDA6D.7060101@selasky.org> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> Content-Type: multipart/mixed; boundary="=-krHKqv4ZbluoRwj6a33k" Date: Sat, 10 May 2014 06:24:57 -0600 Message-ID: <1399724697.22079.386.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 12:25:02 -0000 --=-krHKqv4ZbluoRwj6a33k Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, 2014-05-10 at 09:51 +0200, Hans Petter Selasky wrote: > Hi, > > I've made one more patch to the DWC OTG driver. Nice if you can test > that too. > > http://svnweb.freebsd.org/changeset/base/265806 > > BTW: I think I've found what is causing the glitches when using USB > audio devices: > > diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c > index 0490be7..de7f015 100644 > --- a/sys/arm/arm/machdep.c > +++ b/sys/arm/arm/machdep.c > @@ -423,7 +423,7 @@ cpu_est_clockrate(int cpu_id, uint64_t *rate) > void > cpu_idle(int busy) > { > - > +#if 0 > CTR2(KTR_SPARE2, "cpu_idle(%d) at %d", > busy, curcpu); > #ifndef NO_EVENTTIMERS > @@ -442,6 +442,7 @@ cpu_idle(int busy) > #endif > CTR2(KTR_SPARE2, "cpu_idle(%d) at %d done", > busy, curcpu); > +#endif > } > > int > > > It appears that cpu_idle() is going to sleep when there are pending > interrupts, and then waking up on the next timer IRQ! Can someone > familiar with these parts of the kernel comment? > > Please try for yourself, with and without the patch above, using an USB > audio device with the RPI-B! > > Still when the console is printing, there are significant glitches too > :-) That's because the TTY layer is synchronously writing data to the > serial line. That's OK for now. > > --HPS If there's an interrupt pending when the WaitForInterrupt instruction is executed, the cpu doesn't go to sleep -- it acts like a nop. I think the problem might be that the device write that re-enables the interrupt hasn't yet made it to the device when the cpu clock stops. I don't have any usb audio gear to test with, could you please test the attached patch and see if it fixes the glitches? -- Ian --=-krHKqv4ZbluoRwj6a33k Content-Disposition: inline; filename="cpu_sleep_dsb.diff" Content-Type: text/x-patch; name="cpu_sleep_dsb.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/cpufunc_asm_arm11.S =================================================================== --- sys/arm/arm/cpufunc_asm_arm11.S (revision 265783) +++ sys/arm/arm/cpufunc_asm_arm11.S (working copy) @@ -129,6 +129,7 @@ END(arm11_drain_writebuf) ENTRY_NP(arm11_sleep) mov r0, #0 + mcr p15, 0, r0, c7, c10, 4 /* Drain write buffer / DSB */ mcr p15, 0, r0, c7, c0, 4 /* wait for interrupt */ RET END(arm11_sleep) --=-krHKqv4ZbluoRwj6a33k-- From owner-freebsd-arm@FreeBSD.ORG Sat May 10 13:11:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3252AC5A for ; Sat, 10 May 2014 13:11:23 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC78DC65 for ; Sat, 10 May 2014 13:11:21 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s4ADB6FW051057; Sat, 10 May 2014 15:11:11 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <536E256A.3060003@fgznet.ch> Date: Sat, 10 May 2014 15:11:06 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Matthias Meyser , freebsd-arm@freebsd.org Subject: Re: cross compiling & Native installing References: <536DDB0B.7040502@xenet.de> In-Reply-To: <536DDB0B.7040502@xenet.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 13:11:23 -0000 On 10.05.14 09:53, Matthias Meyser wrote: > Hi > > I xcompile armv6 World and kernel (BEAGLEBONE) on an amd64 machine with > > make buildworld TARGET=arm TARGET_ARCH=armv6 > make buildkernel TARGET=arm TARGET_ARCH=armv6 KERNCONF=BEAGLEBONE > > this works as expected. > > The I want to install world/kernel on the target machine (Beagelbone black) > > on the Beagkebone I nfsmount /usr/src /usr/doc /usr/obj exported from > the build machine. > The other way round it works, at least for me. On the buildmachine mount the / from the beaglebone. And install it there: mount beaglebone:/ /mnt make installworld installkernel KERNCONF=BEAGELBONE TARGET=arm TARGET_ARCH=armv6 DESTDIR /mnt This works fine if you have one partition on the bbb. If you have spread your fs over several partitions you have to mount them under /mnt like this: /mnt/ -> dev1 /mnt/usr -> dev2 ... Andreas From owner-freebsd-arm@FreeBSD.ORG Sat May 10 13:50:01 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F8FE476; Sat, 10 May 2014 13:50:01 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01AA6EB7; Sat, 10 May 2014 13:50:00 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B018D1FE02B; Sat, 10 May 2014 15:49:58 +0200 (CEST) Message-ID: <536E2EBB.7030104@selasky.org> Date: Sat, 10 May 2014 15:50:51 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.lan> In-Reply-To: <1399724697.22079.386.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 13:50:01 -0000 On 05/10/14 14:24, Ian Lepore wrote: > On Sat, 2014-05-10 at 09:51 +0200, Hans Petter Selasky wrote: >> Hi, >> >> I've made one more patch to the DWC OTG driver. Nice if you can test >> that too. >> >> http://svnweb.freebsd.org/changeset/base/265806 >> >> BTW: I think I've found what is causing the glitches when using USB >> audio devices: >> >> diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c >> index 0490be7..de7f015 100644 >> --- a/sys/arm/arm/machdep.c >> +++ b/sys/arm/arm/machdep.c >> @@ -423,7 +423,7 @@ cpu_est_clockrate(int cpu_id, uint64_t *rate) >> void >> cpu_idle(int busy) >> { >> - >> +#if 0 >> CTR2(KTR_SPARE2, "cpu_idle(%d) at %d", >> busy, curcpu); >> #ifndef NO_EVENTTIMERS >> @@ -442,6 +442,7 @@ cpu_idle(int busy) >> #endif >> CTR2(KTR_SPARE2, "cpu_idle(%d) at %d done", >> busy, curcpu); >> +#endif >> } >> >> int >> >> >> It appears that cpu_idle() is going to sleep when there are pending >> interrupts, and then waking up on the next timer IRQ! Can someone >> familiar with these parts of the kernel comment? >> >> Please try for yourself, with and without the patch above, using an USB >> audio device with the RPI-B! >> >> Still when the console is printing, there are significant glitches too >> :-) That's because the TTY layer is synchronously writing data to the >> serial line. That's OK for now. >> >> --HPS > > If there's an interrupt pending when the WaitForInterrupt instruction is > executed, the cpu doesn't go to sleep -- it acts like a nop. I think > the problem might be that the device write that re-enables the interrupt > hasn't yet made it to the device when the cpu clock stops. > > I don't have any usb audio gear to test with, could you please test the > attached patch and see if it fixes the glitches? > > -- Ian > Hi, That code is not used with RPI so it makes no difference. I think we need to do something like they are doing on x86, that the interrupts are enabled the instruction before the sleep instruction. Else we can loose interrupts. Can you write me a correct patch which implements that? diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c index 0490be7..5e43c14 100644 --- a/sys/arm/arm/machdep.c +++ b/sys/arm/arm/machdep.c @@ -423,6 +423,7 @@ cpu_est_clockrate(int cpu_id, uint64_t *rate) void cpu_idle(int busy) { + register_t s; CTR2(KTR_SPARE2, "cpu_idle(%d) at %d", busy, curcpu); @@ -432,8 +433,11 @@ cpu_idle(int busy) cpu_idleclock(); } #endif - if (!sched_runnable()) - cpu_sleep(0); + s = intr_disable(); + if (sched_runnable()) + intr_restore(s); + else + cpu_sleep(0, s); #ifndef NO_EVENTTIMERS if (!busy) { cpu_activeclock(); --- a/sys/arm/arm/cpufunc_asm_arm11x6.S +++ b/sys/arm/arm/cpufunc_asm_arm11x6.S @@ -207,16 +207,21 @@ END(arm11x6_idcache_wbinv_range) ENTRY_NP(arm11x6_sleep) mov r0, #0 - mov r1, #2 -1: - subs r1, #1 +// mov r1, #2 +//1: +// subs r1, #1 nop mcreq p15, 0, r0, c7, c10, 4 /* data sync barrier */ + mrs r1, cpsr +// mov r1, #2 +//1: +// subs r1, #1 nop mcreq p15, 0, r0, c7, c10, 4 /* data sync barrier */ + mrs r1, cpsr + orr r1, r1, #(I32_bit|F32_bit) + eor r1, r1, #(I32_bit|F32_bit) + msr cpsr_c, r1 /* enable interrupts right before waiting */ + mcreq p15, 0, r0, c7, c0, 4 /* wait for interrupt */ nop nop nop - bne 1b +// bne 1b RET END(arm11x6_sleep) --HPS From owner-freebsd-arm@FreeBSD.ORG Sat May 10 15:49:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA1EC886 for ; Sat, 10 May 2014 15:49:04 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99922DF7 for ; Sat, 10 May 2014 15:49:04 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id rd3so5676383pab.29 for ; Sat, 10 May 2014 08:48:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nhZt0feFY6LiQ23ftWm0KCH3HLwd0gbdlB3z3wOvyJY=; b=UP152glSLs3+i0flyZAocIxBZ2aK6zybjTiYpArt46+njeCJB8i3gDufTHqUg4ZttO vodntsZUGNQdfQjSH4YfLgVgOZSdWagra6P9GBUn4eYb9RE2OLRXd7IfMks65zkqPmxN 7gU8DImsW2zIIEjPwHrhQSuIUwwC3oWy8uiO0BqoaxVdwqUZFDyvfsYreIbxnrANJYed iLWee+CRR52Z6FFP/ZASvrx3q8UBBtXNyKSVOo1EKCU8t/QPAOIHi99YyO26pYpJswOl iqswJnmFTovlDokmo1CHVwIaR0ju1Y5RkiDqYUXV0RMTX+UzyC5K8DKQuglze8yYTzLm 9eRQ== X-Gm-Message-State: ALoCoQmT32V86a7c9vKk6qGX3nbeJJfGSZZn+XYVv8nr2fzi2svbzxOL7bcaqd070+7XTGCrwz6F X-Received: by 10.66.147.130 with SMTP id tk2mr34076479pab.125.1399736937829; Sat, 10 May 2014 08:48:57 -0700 (PDT) Received: from lgwl-achen.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id au4sm10860346pbc.10.2014.05.10.08.48.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 May 2014 08:48:56 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_6F295D7B-4A82-492D-830B-2BB02511ED2F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: cross compiling & Native installing From: Warner Losh In-Reply-To: <536DDB0B.7040502@xenet.de> Date: Sat, 10 May 2014 09:48:54 -0600 Message-Id: References: <536DDB0B.7040502@xenet.de> To: Matthias Meyser X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 15:49:05 -0000 --Apple-Mail=_6F295D7B-4A82-492D-830B-2BB02511ED2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 10, 2014, at 1:53 AM, Matthias Meyser wrote: > Hi >=20 > I xcompile armv6 World and kernel (BEAGLEBONE) on an amd64 machine = with >=20 > make buildworld TARGET=3Darm TARGET_ARCH=3Darmv6 > make buildkernel TARGET=3Darm TARGET_ARCH=3Darmv6 KERNCONF=3DBEAGLEBONE >=20 > this works as expected. >=20 > The I want to install world/kernel on the target machine (Beagelbone = black) >=20 > on the Beagkebone I nfsmount /usr/src /usr/doc /usr/obj exported from > the build machine. >=20 > then I do >=20 > cd /usr/src > make installkernel KERNCONF=3DBEAGELBONE CROSS_BUILD_TESTING=3Dyes >=20 > to install the kernel this does not work >=20 > = -------------------------8<--------------------------------------------- > -------------------------------------------------------------- > >>> Installing kernel BEAGLEBONE > -------------------------------------------------------------- > cd /usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE; = MAKEOBJDIRPREFIX=3D/usr/obj/arm.armv6 MACHINE_ARCH=3Darmv6 MACHINE=3Darm= CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin= = GROFF_FONT_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/groff_fo= nt GROFF_TMAC_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/tmac = PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6/u= sr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games:= /usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/arm.armv6/usr/src/tmp/u= sr/sbin:/usr/obj/arm.armv6/usr/src/tmp/usr/bin:/usr/obj/arm.armv6/usr/src/= tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=3Dkernel = install > cc: Exec format error > make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 12: warning: "cc = --version" returned non-zero status > make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 20: Unable to = determine compiler type for cc. Consider setting COMPILER_TYPE. Have you considered setting COMPILER_TYPE to =93clang=94 or something? = The problem is that the cross build is trying to invoke the compiler = that runs on the x86 box. There are likely other issues similar to this, = but give it a try. Or do as Ian suggested and install from the compile host over NFS. Warner > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/src > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src > = -------------------------8<--------------------------------------------- >=20 > Any hints are welcome. >=20 > uname Buildsystem: > FreeBSD slx00.lan.xenet.de 10.0-STABLE FreeBSD 10.0-STABLE #1 r262074: = Tue Feb 18 01:00:39 CET 2014 = root@slx00.lan.xenet.de:/usr/obj/usr/src/sys/SLX00 amd64 >=20 > uname Beaglebone: > FreeBSD bbb.lan.xenet.de 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Thu May = 8 10:16:09 CEST 2014 = root@bbb.lan.xenet.de:/usr/obj/usr/src/sys/BEAGLEBONE arm >=20 > /usr/src: latest head >=20 >=20 > --=20 > Matthias Meyser | XeNET GmbH > Tel.: +49-5323-9489050 | 38678 Clausthal-Zellerfeld, Marktstrasse = 40 > Fax: +49-5323-94014 | Registergericht: Amtsgericht Braunschweig = HRB 110823 > Email: Meyser@xenet.de | Geschaeftsfuehrer: Matthias Meyser > _______________________________________________ > 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" --Apple-Mail=_6F295D7B-4A82-492D-830B-2BB02511ED2F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTbkpmAAoJEGwc0Sh9sBEA63EQAO0vIZxjYasVV97EAVZ3/mrw IOA1fr32r2DzEpDrWCRnF/BWGUeYh0rbWohhVjIMAPC82LdHqnN0xemLrsnRNVUm tQu5UB9YmD3y9ojL0LLf1ss2UiI+N1SjWgD3qLdOGwwlDVoOrvR90cw3Ehj6xvn1 wcUFXP8n9o96JkUpFbw60BzaNLTM/g9jWK729h0V6kfanmo7ETytRKHmFGpx6BCF pFY3BmrjNER0VPOkti51OR8wGVc8x+kIHScd3V9FGa/LHzhjmi3r8Sljl9f2EsOD liGMidKHj1I4LmXQR3np5TglAzPXzzo9Xm13xvvsQBZzJnaiEsDIQiduO8TzxShA uBNVk/JjYYBszXli3PjWrHaHQyBeqNtEtVPB88WGu245oSevmDIvxZsngdd0a68t p2shgiW5cFe7znWR7UEA4neqz3UEYhhttmEVyM2WlzCVzMx3T6N7SFhs94zOeJe7 /+xGm5oHErggYfgA/aN2PXzBESq6ZnOM9xpzKtq7zFO6omYktbtJlzLwH2zx8925 hQGr0vkrxHI/FsOov2PJvfTjTe+unao5uaxXj+1kej+qchULpwkhiQmUfb0C1sN5 4V5jZ33RKdPDpeZVYTF0yvn2bb/o0zr7cj3fE89Yg+/YUgw5X321u4tWhpLAt6kq N/WnSZiMLNh++ZeXKnG1 =f7GY -----END PGP SIGNATURE----- --Apple-Mail=_6F295D7B-4A82-492D-830B-2BB02511ED2F-- From owner-freebsd-arm@FreeBSD.ORG Sat May 10 17:14:27 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFAC0556; Sat, 10 May 2014 17:14:27 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2ADC977E; Sat, 10 May 2014 17:14:27 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WjAqv-0004Kh-Pn; Sat, 10 May 2014 17:14:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4AHEMNp031908; Sat, 10 May 2014 11:14:23 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+fZ68lYhRN6Kl9DpQOeLaV Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <536E2EBB.7030104@selasky.org> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.l an> <536E2EBB.7030104@selasky.org> Content-Type: multipart/mixed; boundary="=-3XSI69yFKe13DEB9+7/x" Date: Sat, 10 May 2014 11:14:22 -0600 Message-ID: <1399742062.22079.403.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 17:14:28 -0000 --=-3XSI69yFKe13DEB9+7/x Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, 2014-05-10 at 15:50 +0200, Hans Petter Selasky wrote: > On 05/10/14 14:24, Ian Lepore wrote: > > On Sat, 2014-05-10 at 09:51 +0200, Hans Petter Selasky wrote: > >> Hi, > >> > >> I've made one more patch to the DWC OTG driver. Nice if you can test > >> that too. > >> > >> http://svnweb.freebsd.org/changeset/base/265806 > >> > >> BTW: I think I've found what is causing the glitches when using USB > >> audio devices: > >> > >> diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c > >> index 0490be7..de7f015 100644 > >> --- a/sys/arm/arm/machdep.c > >> +++ b/sys/arm/arm/machdep.c > >> @@ -423,7 +423,7 @@ cpu_est_clockrate(int cpu_id, uint64_t *rate) > >> void > >> cpu_idle(int busy) > >> { > >> - > >> +#if 0 > >> CTR2(KTR_SPARE2, "cpu_idle(%d) at %d", > >> busy, curcpu); > >> #ifndef NO_EVENTTIMERS > >> @@ -442,6 +442,7 @@ cpu_idle(int busy) > >> #endif > >> CTR2(KTR_SPARE2, "cpu_idle(%d) at %d done", > >> busy, curcpu); > >> +#endif > >> } > >> > >> int > >> > >> > >> It appears that cpu_idle() is going to sleep when there are pending > >> interrupts, and then waking up on the next timer IRQ! Can someone > >> familiar with these parts of the kernel comment? > >> > >> Please try for yourself, with and without the patch above, using an USB > >> audio device with the RPI-B! > >> > >> Still when the console is printing, there are significant glitches too > >> :-) That's because the TTY layer is synchronously writing data to the > >> serial line. That's OK for now. > >> > >> --HPS > > > > If there's an interrupt pending when the WaitForInterrupt instruction is > > executed, the cpu doesn't go to sleep -- it acts like a nop. I think > > the problem might be that the device write that re-enables the interrupt > > hasn't yet made it to the device when the cpu clock stops. > > > > I don't have any usb audio gear to test with, could you please test the > > attached patch and see if it fixes the glitches? > > > > -- Ian > > > > Hi, > > That code is not used with RPI so it makes no difference. Doh! We have so much decoy code in freebsd-arm. > I think we > need to do something like they are doing on x86, that the interrupts are > enabled the instruction before the sleep instruction. Else we can loose > interrupts. Can you write me a correct patch which implements that? > ARM is not x86. From the ARM ARM: When a processor issues a WFI instruction it can suspend execution and enter a low-power state. It can remain in that state until the processor detects a reset or one of the following WFI wake-up events: * an IRQ interrupt, regardless of the value of the CPSR.I bit. * an FIQ interrupt, regardless of the value of the CPSR.F bit. * an asynchronous abort, regardless of the value of the CPSR.A bit. * a debug event, when invasive debug is enabled and the debug event is permitted. Not only is enabling interrupts before WFI not necessary, it may be completely the wrong thing to do... if there's an interrupt pending it will fire as soon as the cpsr.I bit is set, and the handler will run before the WFI executes. Depending on what the handler does maybe putting the CPU to sleep isn't the right thing to do anymore -- the ISR made something runnable that previously wasn't -- but upon return from handling the interrupt we'll unconditionally go to sleep until the next interrupt instead of returning to the scheduler which would now find new non-idle work to do. Note that in the linux implementation they actually go so far as adding a comment to explain that the code doesn't disable interrupts because it's expected that the caller has already done so: https://github.com/torvalds/linux/blob/master/arch/arm/mm/proc-v6.S#L69 I wonder if this is related to some memory ordering trouble I've seen in armv7, which I can't fully explain, but the attached patch makes it go away (preventing spurious interrupts). It'd be interesting to see if it has any effect on this situation. -- Ian --=-3XSI69yFKe13DEB9+7/x Content-Disposition: inline; filename="pmap_device_strongly_ordered.diff" Content-Type: text/x-patch; name="pmap_device_strongly_ordered.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/include/pmap.h =================================================================== --- sys/arm/include/pmap.h (revision 265783) +++ sys/arm/include/pmap.h (working copy) @@ -57,15 +57,15 @@ */ #if ARM_ARCH_6 || ARM_ARCH_7A #ifdef SMP -#define PTE_NOCACHE 2 +#define PTE_NOCACHE 0 #else -#define PTE_NOCACHE 1 +#define PTE_NOCACHE 0 #endif #define PTE_CACHE 6 -#define PTE_DEVICE 2 +#define PTE_DEVICE 0 #define PTE_PAGETABLE 6 #else -#define PTE_NOCACHE 1 +#define PTE_NOCACHE 0 #define PTE_CACHE 2 #define PTE_DEVICE PTE_NOCACHE #define PTE_PAGETABLE 3 --=-3XSI69yFKe13DEB9+7/x-- From owner-freebsd-arm@FreeBSD.ORG Sat May 10 17:39:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A51A3E4B; Sat, 10 May 2014 17:39:31 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 479D48DD; Sat, 10 May 2014 17:39:31 +0000 (UTC) Received: from [2001:470:9174:1:5117:6932:e21:6b24] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WjBF2-000MxX-4G; Sat, 10 May 2014 18:39:28 +0100 From: Mark R V Murray Content-Type: multipart/signed; boundary="Apple-Mail=_49E0B075-E125-464D-B3DE-52759A4DB635"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sat, 10 May 2014 18:39:55 +0100 Subject: Fast cycle counter for ARM chips with SCC - patch for review. To: freebsd-arm Message-Id: <22E12094-E6B2-42F9-94AB-014A702D17F2@FreeBSD.org> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-SA-Score: -1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 17:39:31 -0000 --Apple-Mail=_49E0B075-E125-464D-B3DE-52759A4DB635 Content-Type: multipart/mixed; boundary="Apple-Mail=_2C57E05C-866C-464D-934F-B4E6684D0F0C" --Apple-Mail=_2C57E05C-866C-464D-934F-B4E6684D0F0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi * This patch makes the ARM6 kernels that have an SCC coprocessor (RPI and = WANDBOARD have them) get a MUCH better implementation of = get_cyclecount(9), but not a perfect one. The incrementing rate is good = (+- 1 per instruction), but its only 32 bits. Later, if there is = interest, I may wish to fix that with an overflow interrupt, but for now = its easily good enough for the kernel entropy harvesting service. Also, = its MUUUCH more efficient; a simple read rather can calling the internal = kernel binuptime(9) clock. Comments, please? I=92m keen to commit. M --=20 Mark R V Murray --Apple-Mail=_2C57E05C-866C-464D-934F-B4E6684D0F0C Content-Disposition: attachment; filename=arm_ccnt_counter.diff Content-Type: application/octet-stream; name="arm_ccnt_counter.diff" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/cpufunc.c =================================================================== --- sys/arm/arm/cpufunc.c (revision 265841) +++ sys/arm/arm/cpufunc.c (working copy) @@ -1387,6 +1387,29 @@ } #endif /* CPU_ARM9E || CPU_ARM10 */ +#if defined(CPU_ARM1136) || defined(CPU_ARM1176) \ + || defined(CPU_MV_PJ4B) \ + || defined(CPU_CORTEXA) || defined(CPU_KRAIT) +static __inline void +cpu_scc_setup_ccnt(void) +{ + /* Set up the PMCCNTR register as a cyclecounter: + * Set PMUSERENR[0] to 1 to allow user read + * Set PMINTENCLR to 0x8000000F to block interrupts + * Set PMCR[0] to 1 to enable CCNT + * Set PMCNTENSET to 0x8000000F to enable counters */ + __asm volatile ("mcr p15, 0, %0, c9, c14, 0\n\t" + "mcr p15, 0, %1, c9, c14, 2\n\t" + "mcr p15, 0, %2, c9, c12, 0\n\t" + "mcr p15, 0, %3, c9, c12, 1\n\t" + : + : "r"(0x00000001), + "r"(0x8000000F), + "r"(0x00000007), + "r"(0x8000000F)); +} +#endif + #if defined(CPU_ARM1136) || defined(CPU_ARM1176) struct cpu_option arm11_options[] = { { "cpu.cache", BIC, OR, (CPU_CONTROL_IC_ENABLE | CPU_CONTROL_DC_ENABLE) }, @@ -1490,6 +1513,8 @@ /* And again. */ cpu_idcache_wbinv_all(); + + cpu_scc_setup_ccnt(); } #endif /* CPU_ARM1136 || CPU_ARM1176 */ @@ -1524,6 +1549,8 @@ /* And again. */ cpu_idcache_wbinv_all(); + + cpu_scc_setup_ccnt(); } #endif /* CPU_MV_PJ4B */ @@ -1571,6 +1598,8 @@ #ifdef SMP armv7_auxctrl((1 << 6) | (1 << 0), (1 << 6) | (1 << 0)); /* Enable SMP + TLB broadcasting */ #endif + + cpu_scc_setup_ccnt(); } #endif /* CPU_CORTEXA */ Index: sys/arm/include/cpu.h =================================================================== --- sys/arm/include/cpu.h (revision 265841) +++ sys/arm/include/cpu.h (working copy) @@ -14,11 +14,26 @@ static __inline uint64_t get_cyclecount(void) { +/* This '#if' asks the question 'Do we have a System Control Coprocessor?' */ +#if defined(CPU_ARM1136) || defined(CPU_ARM1176) \ + || defined(CPU_MV_PJ4B) \ + || defined(CPU_CORTEXA) || defined(CPU_KRAIT) + uint32_t ccnt; + uint64_t ccnt64; + + /* + * Read PMCCNTR. Curses! Its only 32 bits. + * TODO: Fix this by catching overflow with interrupt? + */ + __asm __volatile("mrc p15, 0, %0, c9, c13, 0": "=r" (ccnt)); + ccnt64 = (uint64_t)ccnt; + return (ccnt64); +#else /* No SCC, use binuptime(9). This is slooooow */ struct bintime bt; binuptime(&bt); return ((uint64_t)bt.sec << 56 | bt.frac >> 8); - +#endif } #endif --Apple-Mail=_2C57E05C-866C-464D-934F-B4E6684D0F0C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_2C57E05C-866C-464D-934F-B4E6684D0F0C-- --Apple-Mail=_49E0B075-E125-464D-B3DE-52759A4DB635 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU25kb958vKOKE6LNAQrk+wP+PmL6xGV284KMuynxLtUOt27mVoJaefBP Bc3KinklrFEmy25XDszy8JXYB9G/0mzJTSFy5KUL+2w5+4i9JJcnGYqvQSSoAR0o J+0CBtaLq1iGWDa+uDrLx66D2WwHIFnozgOxGfSvpUnlLmm3gMe4iPOxkFB5jwnI gwcq2Zp6+VM= =fJWB -----END PGP SIGNATURE----- --Apple-Mail=_49E0B075-E125-464D-B3DE-52759A4DB635-- From owner-freebsd-arm@FreeBSD.ORG Sat May 10 18:16:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E484B634; Sat, 10 May 2014 18:16:54 +0000 (UTC) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id B156BB85; Sat, 10 May 2014 18:16:54 +0000 (UTC) Received: from [192.168.125.21] (iphone1.bitblocks.com [192.168.125.21]) by mail.bitblocks.com (Postfix) with ESMTP id B2DFDB82A; Sat, 10 May 2014 11:07:42 -0700 (PDT) References: <22E12094-E6B2-42F9-94AB-014A702D17F2@FreeBSD.org> In-Reply-To: <22E12094-E6B2-42F9-94AB-014A702D17F2@FreeBSD.org> Mime-Version: 1.0 (1.0) Message-Id: <7D5EE653-922D-4AF8-92A9-56344148FC7F@bitblocks.com> X-Mailer: iPhone Mail (11D201) From: Bakul Shah Subject: Re: Fast cycle counter for ARM chips with SCC - patch for review. Date: Sat, 10 May 2014 11:07:38 -0700 To: Mark R V Murray Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 18:16:55 -0000 FYI: BCM2835 has a built in h/w RNG (using a reverse biased transistor as an= entropy source). Access to it was enabled in the RPi firmware around Jan 30= , 2013. FWIW, it passes rngtest as well as FreeBSD's /dev/random (on x86/amd= 64) does. For the spec. see http://pastehtml.com/view/crkxyohmp.rtxt Referenced from this thread: http://www.raspberrypi.org/forums/viewtopic.php= ?f=3D29&t=3D19334&p=3D273944#p273944 > On May 10, 2014, at 10:39 AM, Mark R V Murray wrote: >=20 > Hi * >=20 > This patch makes the ARM6 kernels that have an SCC coprocessor (RPI and WA= NDBOARD have them) get a MUCH better implementation of get_cyclecount(9), bu= t not a perfect one. The incrementing rate is good (+- 1 per instruction), b= ut its only 32 bits. Later, if there is interest, I may wish to fix that wit= h an overflow interrupt, but for now its easily good enough for the kernel e= ntropy harvesting service. Also, its MUUUCH more efficient; a simple read ra= ther can calling the internal kernel binuptime(9) clock. >=20 > Comments, please? I=E2=80=99m keen to commit. >=20 > M > --=20 > Mark R V Murray > >=20 From owner-freebsd-arm@FreeBSD.ORG Sat May 10 18:23:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 946D4744; Sat, 10 May 2014 18:23:14 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58DF6C03; Sat, 10 May 2014 18:23:14 +0000 (UTC) Received: from [2001:470:9174:1:5117:6932:e21:6b24] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WjBvR-000N0E-7V; Sat, 10 May 2014 19:23:12 +0100 Subject: Re: Fast cycle counter for ARM chips with SCC - patch for review. Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DBA30987-A955-4F78-BD46-891AFF983820"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <7D5EE653-922D-4AF8-92A9-56344148FC7F@bitblocks.com> Date: Sat, 10 May 2014 19:23:44 +0100 Message-Id: <1EFDD1B3-2B95-4B96-84B1-077E0CEB5BDC@FreeBSD.org> References: <22E12094-E6B2-42F9-94AB-014A702D17F2@FreeBSD.org> <7D5EE653-922D-4AF8-92A9-56344148FC7F@bitblocks.com> To: Bakul Shah X-Mailer: Apple Mail (2.1874) X-SA-Score: -1.0 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 18:23:14 -0000 --Apple-Mail=_DBA30987-A955-4F78-BD46-891AFF983820 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi I=92m aware of this, thanks, but it is not relevant to the cyclecounter = (except distantly). M On 10 May 2014, at 19:07, Bakul Shah wrote: > FYI: BCM2835 has a built in h/w RNG (using a reverse biased transistor = as an entropy source). Access to it was enabled in the RPi firmware = around Jan 30, 2013. FWIW, it passes rngtest as well as FreeBSD's = /dev/random (on x86/amd64) does. > For the spec. see http://pastehtml.com/view/crkxyohmp.rtxt > Referenced from this thread: = http://www.raspberrypi.org/forums/viewtopic.php?f=3D29&t=3D19334&p=3D27394= 4#p273944 >=20 >> On May 10, 2014, at 10:39 AM, Mark R V Murray = wrote: >>=20 >> Hi * >>=20 >> This patch makes the ARM6 kernels that have an SCC coprocessor (RPI = and WANDBOARD have them) get a MUCH better implementation of = get_cyclecount(9), but not a perfect one. The incrementing rate is good = (+- 1 per instruction), but its only 32 bits. Later, if there is = interest, I may wish to fix that with an overflow interrupt, but for now = its easily good enough for the kernel entropy harvesting service. Also, = its MUUUCH more efficient; a simple read rather can calling the internal = kernel binuptime(9) clock. >>=20 >> Comments, please? I=92m keen to commit. >>=20 >> M >> --=20 >> Mark R V Murray >> >>=20 --=20 Mark R V Murray --Apple-Mail=_DBA30987-A955-4F78-BD46-891AFF983820 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBU25utt58vKOKE6LNAQrUWAQAobb8mbeS9SMpEJ1YvLU63jG2ObWRz54I dJclOCaKP5rtXI6YvOuGph3Fy5dIDw1S4D+RUVjuc62qWWqi1G/6shKlqlCYjFHb dDl/tLyX36HPjTMI2pS47XS7U0nELl+xdg7vOBbqT70DQb33kPtAXTJYcYlMcwJe pPrVTd6uVS8= =Tygf -----END PGP SIGNATURE----- --Apple-Mail=_DBA30987-A955-4F78-BD46-891AFF983820-- From owner-freebsd-arm@FreeBSD.ORG Sat May 10 18:43:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9A93BA8; Sat, 10 May 2014 18:43:47 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF834D5F; Sat, 10 May 2014 18:43:46 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s4AIPe7S018193; Sat, 10 May 2014 18:25:40 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id vpyj9cpytnsrjm3qe3a65j7q6s; Sat, 10 May 2014 18:25:40 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Tim Kientzle In-Reply-To: <1399742062.22079.403.camel@revolution.hippie.lan> Date: Sat, 10 May 2014 11:25:40 -0700 Content-Transfer-Encoding: 7bit Message-Id: <690B2DB4-046A-43CE-8AE4-F897E7997707@kientzle.com> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.l an> <536E2EBB.7! 030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 18:43:47 -0000 On May 10, 2014, at 10:14 AM, Ian Lepore wrote: > -- but upon return from > handling the interrupt we'll unconditionally go to sleep until the next > interrupt instead of returning to the scheduler which would now find new > non-idle work to do. Could any of this be related to the regular system stalls that have plagued BeagleBone? Run a heavy load on BBB (buildworld) and watch the CPU idle via top in another ssh session. On about a 30s cycle, you will see the CPU usage vary from completely busy to totally idle. When it goes idle, disk I/O in other logins seems to be stalled, so I've long suspected some problem in the disk I/O path, with recovery tickled by the next sync flush. I suspect this is one of the reasons that buildworld on BBB takes ~40hrs right now. (The other being CPU frequency and cache enabling; I've not yet updated U-Boot on my BBBs.) I've seen this on FreeBSD-CURRENT for as long as FreeBSD-CURRENT has run on BeagleBone. (Almost 2 years now.) Tim From owner-freebsd-arm@FreeBSD.ORG Sat May 10 18:52:27 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19FEACC4; Sat, 10 May 2014 18:52:27 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1B2CDF2; Sat, 10 May 2014 18:52:26 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WjCNl-0007ge-4M; Sat, 10 May 2014 18:52:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4AIqN1S031978; Sat, 10 May 2014 12:52:23 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX187V/oj+ZRcT5IRGHNGKwWY Subject: Re: Fast cycle counter for ARM chips with SCC - patch for review. From: Ian Lepore To: Mark R V Murray In-Reply-To: <22E12094-E6B2-42F9-94AB-014A702D17F2@FreeBSD.org> References: <22E12094-E6B2-42F9-94AB-014A702D17F2@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-7" Date: Sat, 10 May 2014 12:52:23 -0600 Message-ID: <1399747943.22079.415.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s4AIqN1S031978 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 18:52:27 -0000 On Sat, 2014-05-10 at 18:39 +0100, Mark R V Murray wrote: > Hi * >=20 > This patch makes the ARM6 kernels that have an SCC coprocessor (RPI and= WANDBOARD have them) get a MUCH better implementation of get_cyclecount(= 9), but not a perfect one. The incrementing rate is good (+- 1 per instru= ction), but its only 32 bits. Later, if there is interest, I may wish to = fix that with an overflow interrupt, but for now its easily good enough f= or the kernel entropy harvesting service. Also, its MUUUCH more efficient= ; a simple read rather can calling the internal kernel binuptime(9) clock. >=20 > Comments, please? I=A2m keen to commit. >=20 > M The manual says setting the user enable bit doesn't just enable user read, it also grants user write access to most of the registers, including CCNT. The value to write to PMINTENCLR should be 0xffffffff. In theory you should read the ID register to see how many counters are available and set that many of the low-order bits to 1, but the manual says that writes are ignored for the bits 30-N so you can just blindly write all ones. For PMCNTENSET I think the value to write is 0x80000000, no need to enable other counters. The comment says PMCR is set to 1, but it's actually set to 7. The comment=20 This '#if' asks the question 'Do we have a System Control Coprocessor? should read something like 'Does CP15 include performance counters?' all arm chips have a system control coprocessor. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat May 10 19:00:39 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FFEB234; Sat, 10 May 2014 19:00:39 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D16AE40; Sat, 10 May 2014 19:00:38 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WjCVa-000ClB-SF; Sat, 10 May 2014 19:00:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4AJ0Sau031990; Sat, 10 May 2014 13:00:28 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/C7RS4aPvFDNDHRdTvX2ja Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Tim Kientzle In-Reply-To: <690B2DB4-046A-43CE-8AE4-F897E7997707@kientzle.com> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.l an> <536E2EBB.7! 030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> <690B2DB4-046A-43CE-8AE4-F897E7997707@kientzle.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 May 2014 13:00:28 -0600 Message-ID: <1399748428.22079.420.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" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 19:00:39 -0000 On Sat, 2014-05-10 at 11:25 -0700, Tim Kientzle wrote: > On May 10, 2014, at 10:14 AM, Ian Lepore wrote: > > > -- but upon return from > > handling the interrupt we'll unconditionally go to sleep until the next > > interrupt instead of returning to the scheduler which would now find new > > non-idle work to do. > > Could any of this be related to the regular > system stalls that have plagued BeagleBone? > > Run a heavy load on BBB (buildworld) > and watch the CPU idle via top in another > ssh session. > > On about a 30s cycle, you will see the > CPU usage vary from completely busy > to totally idle. > > When it goes idle, disk I/O in other logins > seems to be stalled, so I've long suspected > some problem in the disk I/O path, with > recovery tickled by the next sync flush. > > I suspect this is one of the reasons that > buildworld on BBB takes ~40hrs right now. > (The other being CPU frequency and cache > enabling; I've not yet updated U-Boot on > my BBBs.) > > I've seen this on FreeBSD-CURRENT for > as long as FreeBSD-CURRENT has run > on BeagleBone. (Almost 2 years now.) > > Tim > Is that by any chance with the object files being written to sdcard? If so, I'd expect that that's the usual bad behavior of the vfs buffer layer with slow devices. Eventually all the buffers in the system are full of dirty data waiting to be written, so new reads can't proceed, and it takes a long time to drain that many buffers to an sdcard. Anyway, to directly answer your question... No, what I was describing couldn't be the BB's problem because our code doesn't currently enable interrupts before WFI. I was explaining why I think the patch HPS proposes wouldn't be a good idea. I don't know what you mean by cache enabling... caches have always been enabled on BB. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat May 10 22:17:15 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF98C414; Sat, 10 May 2014 22:17:15 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7079AFAA; Sat, 10 May 2014 22:17:14 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 49C7C1FE02B; Sun, 11 May 2014 00:17:07 +0200 (CEST) Message-ID: <536EA597.3070700@selasky.org> Date: Sun, 11 May 2014 00:17:59 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.l an> <536E2EBB.7030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> In-Reply-To: <1399742062.22079.403.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 22:17:15 -0000 On 05/10/14 19:14, Ian Lepore wrote: > On Sat, 2014-05-10 at 15:50 +0200, Hans Petter Selasky wrote: >> On 05/10/14 14:24, Ian Lepore wrote: >>> On Sat, 2014-05-10 at 09:51 +0200, Hans Petter Selasky wrote: >>>> Hi, >>>> >>>> I've made one more patch to the DWC OTG driver. Nice if you can test >>>> that too. >>>> >>>> http://svnweb.freebsd.org/changeset/base/265806 >>>> >>>> BTW: I think I've found what is causing the glitches when using USB >>>> audio devices: >>>> >>>> diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c >>>> index 0490be7..de7f015 100644 >>>> --- a/sys/arm/arm/machdep.c >>>> +++ b/sys/arm/arm/machdep.c >>>> @@ -423,7 +423,7 @@ cpu_est_clockrate(int cpu_id, uint64_t *rate) >>>> void >>>> cpu_idle(int busy) >>>> { >>>> - >>>> +#if 0 >>>> CTR2(KTR_SPARE2, "cpu_idle(%d) at %d", >>>> busy, curcpu); >>>> #ifndef NO_EVENTTIMERS >>>> @@ -442,6 +442,7 @@ cpu_idle(int busy) >>>> #endif >>>> CTR2(KTR_SPARE2, "cpu_idle(%d) at %d done", >>>> busy, curcpu); >>>> +#endif >>>> } >>>> >>>> int >>>> >>>> >>>> It appears that cpu_idle() is going to sleep when there are pending >>>> interrupts, and then waking up on the next timer IRQ! Can someone >>>> familiar with these parts of the kernel comment? >>>> >>>> Please try for yourself, with and without the patch above, using an USB >>>> audio device with the RPI-B! >>>> >>>> Still when the console is printing, there are significant glitches too >>>> :-) That's because the TTY layer is synchronously writing data to the >>>> serial line. That's OK for now. >>>> >>>> --HPS >>> >>> If there's an interrupt pending when the WaitForInterrupt instruction is >>> executed, the cpu doesn't go to sleep -- it acts like a nop. I think >>> the problem might be that the device write that re-enables the interrupt >>> hasn't yet made it to the device when the cpu clock stops. >>> >>> I don't have any usb audio gear to test with, could you please test the >>> attached patch and see if it fixes the glitches? >>> >>> -- Ian >>> >> >> Hi, >> >> That code is not used with RPI so it makes no difference. > > Doh! We have so much decoy code in freebsd-arm. > >> I think we >> need to do something like they are doing on x86, that the interrupts are >> enabled the instruction before the sleep instruction. Else we can loose >> interrupts. Can you write me a correct patch which implements that? >> > > ARM is not x86. From the ARM ARM: > > When a processor issues a WFI instruction it can suspend > execution and enter a low-power state. It can remain in that > state until the processor detects a reset or one of the > following WFI wake-up events: > * an IRQ interrupt, regardless of the value of the CPSR.I bit. > * an FIQ interrupt, regardless of the value of the CPSR.F bit. > * an asynchronous abort, regardless of the value of the CPSR.A > bit. > * a debug event, when invasive debug is enabled and the debug > event is permitted. > > Not only is enabling interrupts before WFI not necessary, it may be > completely the wrong thing to do... if there's an interrupt pending it > will fire as soon as the cpsr.I bit is set, and the handler will run > before the WFI executes. Depending on what the handler does maybe > putting the CPU to sleep isn't the right thing to do anymore -- the ISR > made something runnable that previously wasn't -- but upon return from > handling the interrupt we'll unconditionally go to sleep until the next > interrupt instead of returning to the scheduler which would now find new > non-idle work to do. > > Note that in the linux implementation they actually go so far as adding > a comment to explain that the code doesn't disable interrupts because > it's expected that the caller has already done so: > > https://github.com/torvalds/linux/blob/master/arch/arm/mm/proc-v6.S#L69 > > I wonder if this is related to some memory ordering trouble I've seen in > armv7, which I can't fully explain, but the attached patch makes it go > away (preventing spurious interrupts). It'd be interesting to see if it > has any effect on this situation. > > -- Ian > Hi, This patch makes no difference. Only the disabling of the cpu_idle() function completely eliminates the problem. --HPS From owner-freebsd-arm@FreeBSD.ORG Sat May 10 22:24:33 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7023B5F5; Sat, 10 May 2014 22:24:33 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27C45AD; Sat, 10 May 2014 22:24:33 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 68E831FE02B; Sun, 11 May 2014 00:24:31 +0200 (CEST) Message-ID: <536EA753.40905@selasky.org> Date: Sun, 11 May 2014 00:25:23 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.l an> <536E2EBB.7030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> <536EA597.3070700@selasky.org> In-Reply-To: <536EA597.3070700@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 22:24:33 -0000 Hi, This patch fixes the problem too: diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c index 0490be7..8d53fab 100644 --- a/sys/arm/arm/machdep.c +++ b/sys/arm/arm/machdep.c @@ -432,8 +432,12 @@ cpu_idle(int busy) cpu_idleclock(); } #endif + register_t s; + s = intr_disable(); if (!sched_runnable()) cpu_sleep(0); + intr_restore(s); + #ifndef NO_EVENTTIMERS if (!busy) { cpu_activeclock(); It appears some IRQ is happening when sched_runnable() is running, and then cpu_sleep(0) is executed even though sched_runnable() is no longer true. --HPS From owner-freebsd-arm@FreeBSD.ORG Sat May 10 23:23:15 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EA72541; Sat, 10 May 2014 23:23:15 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 678681B35; Sat, 10 May 2014 23:23:14 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WjGbp-000BuT-1k; Sat, 10 May 2014 23:23:13 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4ANNA6L032177; Sat, 10 May 2014 17:23:10 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+OCVlyU8Bx9cvW8ReLC1x8 Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <536EA753.40905@selasky.org> References: <20140425154430.GA76168@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.l an> <536E2EBB.7030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> <536EA597.3070700@selasky.org> <536EA753.40905@selasky.org> Content-Type: multipart/mixed; boundary="=-uGWDOLKFIGU7QklY4t93" Date: Sat, 10 May 2014 17:23:10 -0600 Message-ID: <1399764190.22079.425.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 23:23:15 -0000 --=-uGWDOLKFIGU7QklY4t93 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, 2014-05-11 at 00:25 +0200, Hans Petter Selasky wrote: > Hi, > > This patch fixes the problem too: > > diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c > index 0490be7..8d53fab 100644 > --- a/sys/arm/arm/machdep.c > +++ b/sys/arm/arm/machdep.c > @@ -432,8 +432,12 @@ cpu_idle(int busy) > cpu_idleclock(); > } > #endif > + register_t s; > + s = intr_disable(); > if (!sched_runnable()) > cpu_sleep(0); > + intr_restore(s); > + > #ifndef NO_EVENTTIMERS > if (!busy) { > cpu_activeclock(); > > It appears some IRQ is happening when sched_runnable() is running, and > then cpu_sleep(0) is executed even though sched_runnable() is no longer > true. > > --HPS Aha! Now I think you're on to something. Even after explaining why interrupts should be disabled for WFI I didn't notice that we don't disable interrupts before WFI. (I wonder if this is why I sometimes see a lost timer interrupt and have to hit a key to un-wedge things.) Can you try the attached? The spinlock_enter/exit calls are essentially a combination of disabling interrupts and doing a critical_enter(). -- Ian --=-uGWDOLKFIGU7QklY4t93 Content-Disposition: inline; filename="cpu_idle_spinlock.diff" Content-Type: text/x-patch; name="cpu_idle_spinlock.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/machdep.c =================================================================== --- sys/arm/arm/machdep.c (revision 265783) +++ sys/arm/arm/machdep.c (working copy) @@ -426,9 +426,9 @@ cpu_idle(int busy) CTR2(KTR_SPARE2, "cpu_idle(%d) at %d", busy, curcpu); + spinlock_enter(); #ifndef NO_EVENTTIMERS if (!busy) { - critical_enter(); cpu_idleclock(); } #endif @@ -437,9 +437,9 @@ cpu_idle(int busy) #ifndef NO_EVENTTIMERS if (!busy) { cpu_activeclock(); - critical_exit(); } #endif + spinlock_exit(); CTR2(KTR_SPARE2, "cpu_idle(%d) at %d done", busy, curcpu); } --=-uGWDOLKFIGU7QklY4t93-- From owner-freebsd-arm@FreeBSD.ORG Sun May 11 06:23:45 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C9A3E7B; Sun, 11 May 2014 06:23:45 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C321326F6; Sun, 11 May 2014 06:23:43 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 1BBB61FE02B; Sun, 11 May 2014 08:23:41 +0200 (CEST) Message-ID: <536F17A1.8060807@selasky.org> Date: Sun, 11 May 2014 08:24:33 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.l an> <536E2EBB.7030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> <536EA597.3070700@selasky.org> <536EA753.40905@selasky.org> <1399764190.22079.425.camel@revolution.hippie.lan> In-Reply-To: <1399764190.22079.425.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 06:23:45 -0000 On 05/11/14 01:23, Ian Lepore wrote: > On Sun, 2014-05-11 at 00:25 +0200, Hans Petter Selasky wrote: >> Hi, >> >> This patch fixes the problem too: >> >> diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c >> index 0490be7..8d53fab 100644 >> --- a/sys/arm/arm/machdep.c >> +++ b/sys/arm/arm/machdep.c >> @@ -432,8 +432,12 @@ cpu_idle(int busy) >> cpu_idleclock(); >> } >> #endif >> + register_t s; >> + s = intr_disable(); >> if (!sched_runnable()) >> cpu_sleep(0); >> + intr_restore(s); >> + >> #ifndef NO_EVENTTIMERS >> if (!busy) { >> cpu_activeclock(); >> >> It appears some IRQ is happening when sched_runnable() is running, and >> then cpu_sleep(0) is executed even though sched_runnable() is no longer >> true. >> >> --HPS > > Aha! Now I think you're on to something. Even after explaining why > interrupts should be disabled for WFI I didn't notice that we don't > disable interrupts before WFI. (I wonder if this is why I sometimes see > a lost timer interrupt and have to hit a key to un-wedge things.) > > Can you try the attached? The spinlock_enter/exit calls are essentially > a combination of disabling interrupts and doing a critical_enter(). > > -- Ian Hi Ian, Your patch works! BTW: I see the "mips" platform might have a similar issue. --HPS From owner-freebsd-arm@FreeBSD.ORG Sun May 11 06:33:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CA6AED4; Sun, 11 May 2014 06:33:19 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A656C276E; Sun, 11 May 2014 06:33:18 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id ih12so5779683qab.12 for ; Sat, 10 May 2014 23:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2nQpkqi6CNpUjsUnBCaQW9mPqgOfO9eQscOaFIWbpWM=; b=cjYjFs4TdabnkEnSCG3GSgtHTxYARp4k7yquq3v4u8mHaYtm3BTG1WrNZqRswCr7Ui K+S1ihzENXLzd3DTNkgU+Hz+kdw2ou68wHP3m66tPW6VD8iiPu6Pj8g5NiOaaI25XRl8 +h1txLcCuleuOlccU7xBlrLS4vX9de992u/ezvswx48AyL30ymtR6T6T8cbQSucdFTj4 niO6F0p0l3urvilk9mPBEEg4v6VyR8epTbm6q8dDCLlpKsnaDCpi74+IPc0rcFhuGL0k a2r6L7fKsMOeSE5/YRDZqgxcJAl1swS5sMxwC2/495aPBIDBXcA3vCBXgfH9Ffk2zdbS w5yg== MIME-Version: 1.0 X-Received: by 10.229.134.198 with SMTP id k6mr28015384qct.13.1399789997886; Sat, 10 May 2014 23:33:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 10 May 2014 23:33:17 -0700 (PDT) In-Reply-To: <536F17A1.8060807@selasky.org> References: <20140425154430.GA76168@utility-01.thismonkey.com> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <536E2EBB.7030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> <536EA597.3070700@selasky.org> <536EA753.40905@selasky.org> <1399764190.22079.425.camel@revolution.hippie.lan> <536F17A1.8060807@selasky.org> Date: Sat, 10 May 2014 23:33:17 -0700 X-Google-Sender-Auth: wu4kjxLQmaBDnIr4DzBdZDZPEyg Message-ID: Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , Alexander Motin , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 06:33:19 -0000 Nah, we fixed it in mips. there's dirty, dirty assembler in the exception handlr and idle loop calls to skip over the idle loop if an interrupt comes in. -a On 10 May 2014 23:24, Hans Petter Selasky wrote: > On 05/11/14 01:23, Ian Lepore wrote: >> >> On Sun, 2014-05-11 at 00:25 +0200, Hans Petter Selasky wrote: >>> >>> Hi, >>> >>> This patch fixes the problem too: >>> >>> diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c >>> index 0490be7..8d53fab 100644 >>> --- a/sys/arm/arm/machdep.c >>> +++ b/sys/arm/arm/machdep.c >>> @@ -432,8 +432,12 @@ cpu_idle(int busy) >>> cpu_idleclock(); >>> } >>> #endif >>> + register_t s; >>> + s = intr_disable(); >>> if (!sched_runnable()) >>> cpu_sleep(0); >>> + intr_restore(s); >>> + >>> #ifndef NO_EVENTTIMERS >>> if (!busy) { >>> cpu_activeclock(); >>> >>> It appears some IRQ is happening when sched_runnable() is running, and >>> then cpu_sleep(0) is executed even though sched_runnable() is no longer >>> true. >>> >>> --HPS >> >> >> Aha! Now I think you're on to something. Even after explaining why >> interrupts should be disabled for WFI I didn't notice that we don't >> disable interrupts before WFI. (I wonder if this is why I sometimes see >> a lost timer interrupt and have to hit a key to un-wedge things.) >> >> Can you try the attached? The spinlock_enter/exit calls are essentially >> a combination of disabling interrupts and doing a critical_enter(). >> >> -- Ian > > > Hi Ian, > > Your patch works! > > BTW: I see the "mips" platform might have a similar issue. > > > --HPS > > _______________________________________________ > 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 May 11 10:10:02 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96E81B57; Sun, 11 May 2014 10:10:02 +0000 (UTC) Received: from server1.xenet.de (server1out.xenet.de [213.221.94.200]) by mx1.freebsd.org (Postfix) with ESMTP id E1F79257A; Sun, 11 May 2014 10:10:00 +0000 (UTC) Received: from [10.1.0.50] (tubercel-gate.xenet.de [213.221.94.54]) (authenticated bits=0) by server1.xenet.de (8.12.5/8.12.5) with ESMTP id s4BA9oBJ042527; Sun, 11 May 2014 12:09:52 +0200 (CEST) (envelope-from meyser@xenet.de) Message-ID: <536F4C6D.8080907@xenet.de> Date: Sun, 11 May 2014 12:09:49 +0200 From: Matthias Meyser Organization: XeNET GmbH User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: cross compiling & Native installing References: <536DDB0B.7040502@xenet.de> <1399722475.22079.382.camel@revolution.hippie.lan> In-Reply-To: <1399722475.22079.382.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.38 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 10:10:02 -0000 Am 10.05.2014 13:47, schrieb Ian Lepore: > On Sat, 2014-05-10 at 09:53 +0200, Matthias Meyser wrote: >> Hi >> >> I xcompile armv6 World and kernel (BEAGLEBONE) on an amd64 machine with >> >> make buildworld TARGET=arm TARGET_ARCH=armv6 >> make buildkernel TARGET=arm TARGET_ARCH=armv6 KERNCONF=BEAGLEBONE >> [...] >> >> >> Any hints are welcome. >> >> uname Buildsystem: >> FreeBSD slx00.lan.xenet.de 10.0-STABLE FreeBSD 10.0-STABLE #1 r262074: Tue >> Feb 18 01:00:39 CET 2014 >> root@slx00.lan.xenet.de:/usr/obj/usr/src/sys/SLX00 amd64 >> >> uname Beaglebone: >> FreeBSD bbb.lan.xenet.de 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Thu May 8 >> 10:16:09 CEST 2014 root@bbb.lan.xenet.de:/usr/obj/usr/src/sys/BEAGLEBONE >> arm >> >> /usr/src: latest head >> >> > > I think it's the CROSS_BUILD_TESTING that's causing the problem. It's > trying to run the x86 cross-tools during the native install. Try > replacing that with MAKEOBJDIRPREFIX=/usr/obj/arm.armv6. make installkernel KERNCONF=BBB MAKEOBJDIRPREFIX=/usr/obj/arm.armv6 givs the exact same error. > I'm not sure > that'll work, I've never tried to do what you're doing... I do the > install on the same machine as the cross-builds, using > > make installworld TARGET_ARCH=armv6 DESTDIR=/path/to/nfsroot > > and likewise for installkernel but with KERNCONF added. I will use that as a workaround. -- Matthias From owner-freebsd-arm@FreeBSD.ORG Sun May 11 10:22:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73CDFF61 for ; Sun, 11 May 2014 10:22:14 +0000 (UTC) Received: from server1.xenet.de (server1out.xenet.de [213.221.94.200]) by mx1.freebsd.org (Postfix) with ESMTP id DE8ED269F for ; Sun, 11 May 2014 10:22:13 +0000 (UTC) Received: from [10.1.0.50] (tubercel-gate.xenet.de [213.221.94.54]) (authenticated bits=0) by server1.xenet.de (8.12.5/8.12.5) with ESMTP id s4BAM6BJ042782; Sun, 11 May 2014 12:22:10 +0200 (CEST) (envelope-from meyser@xenet.de) Message-ID: <536F4F4E.6050900@xenet.de> Date: Sun, 11 May 2014 12:22:06 +0200 From: Matthias Meyser Organization: XeNET GmbH User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: cross compiling & Native installing References: <536DDB0B.7040502@xenet.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.38 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 10:22:14 -0000 Am 10.05.2014 17:48, schrieb Warner Losh: > > On May 10, 2014, at 1:53 AM, Matthias Meyser wrote: [...] > > Have you considered setting COMPILER_TYPE to clang or something? > The problem is that the cross build is trying to invoke the compiler that runs on the x86 box. > There are likely other issues similar to this, but give it a try. make installkernel KERNCONF=BBB MAKEOBJDIRPREFIX=/usr/obj/arm.armv6 COMPILER_TYPE=clang or make installkernel KERNCONF=BBB CROSS_BUILD_TESTING=yes COMPILER_TYPE=clang gives ------8<-------------------------------8<------------------------- -------------------------------------------------------------- >>> Installing kernel BBB -------------------------------------------------------------- cd /usr/obj/arm.armv6/usr/src/sys/BBB; MAKEOBJDIRPREFIX=/usr/obj/arm.armv6 MACHINE_ARCH=armv6 MACHINE=arm CPUTYPE= GROFF_BIN_PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/tmac PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games:/usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/arm.armv6/usr/src/tmp/usr/sbin:/usr/obj/arm.armv6/usr/src/tmp/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ; if [ ! "`dirname "$thiskernel"`" -ef /boot/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; sysctl kern.bootfile=/boot/kernel.old/"`basename "$thiskernel"`" ; fi mkdir -p /boot/kernel install -p -m 555 -o root -g wheel kernel /boot/kernel /usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin/install: H=/uL=/IE ~4I t+fffff. HHr-H/t uH t: not found PuTTY/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin/install:ELF: not found /usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin/install: 1: Syntax error: Unterminated quoted string /usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin/install: 6: Syntax error: Error in command substitution *** Error code 2 Stop. make[2]: stopped in /usr/obj/arm.armv6/usr/src/sys/BBB *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src ------8<-------------------------------8<------------------------- > Or do as Ian suggested and install from the compile host over NFS. I will do as a workaround. But I still believe this this "schould" work. -- Matthias From owner-freebsd-arm@FreeBSD.ORG Mon May 12 10:39:30 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE1B21A9 for ; Mon, 12 May 2014 10:39:30 +0000 (UTC) Received: from forward5h.mail.yandex.net (forward5h.mail.yandex.net [IPv6:2a02:6b8:0:f05::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0D452428 for ; Mon, 12 May 2014 10:39:29 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward5h.mail.yandex.net (Yandex) with ESMTP id BEE88D007C0 for ; Mon, 12 May 2014 14:39:14 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 81EF21704283 for ; Mon, 12 May 2014 14:39:14 +0400 (MSK) Received: from 93.91.10.182.tel.ru (93.91.10.182.tel.ru [93.91.10.182]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Wm3KGIPgHz-dEOe3Dpe; Mon, 12 May 2014 14:39:14 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: fc8bf2c5-4065-4f65-a605-d5663312ec6a Message-ID: <5370A4D1.5090502@passap.ru> Date: Mon, 12 May 2014 14:39:13 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: wandboard-quad iomux X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 10:39:31 -0000 Hi All, I've made IOMUX driver for WANDBOARD-QUAD. According to docs it should work for WANDBOARD-DUAL. Being this driver compiled kernel into I get: ----- kernel: imx6q_iomux0: mem 0x20e0000-0x20e3fff irq 7 on simplebus1 ----- I'm not including "device iomux" at the kernel config for now. One should include that line to test the driver. For testing purposes it may be build by hand as a module and then kldloaded. Please, keep in mind that this is my first FreeBSD base patch (I'm a ports committer). Thanks for your attention. The patch is here: ftp://ftp.wart.ru/pub/misc/imx6q.diff.txt -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Mon May 12 11:06:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54BD4A53 for ; Mon, 12 May 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27D5F26B6 for ; Mon, 12 May 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4CB6fRK067743 for ; Mon, 12 May 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4CB6eJo067741 for freebsd-arm@FreeBSD.org; Mon, 12 May 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 May 2014 11:06:40 GMT Message-Id: <201405121106.s4CB6eJo067741@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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 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/189415 arm [patch] mount_smbfs missing from arm o arm/188933 arm [lor] lock order reversal: backtrace while writing to o arm/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o ports/175605 arm devel/binutils: please fix build binutils-2.23.1 in ra 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/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 ports/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 [at91] [patch] Enable at91 booting from SDHC (high cap 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 28 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon May 12 13:06:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D548EECD; Mon, 12 May 2014 13:06:29 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1594823E7; Mon, 12 May 2014 13:06:29 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wjpvy-0006zr-Cn; Mon, 12 May 2014 13:06:22 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4CD6Il5034025; Mon, 12 May 2014 07:06:18 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19WbT57vkodSiRuIBj6szS2 Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <536F17A1.8060807@selasky.org> References: <20140425154430.GA76168@utility-01.thismonkey.com> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.l an> <536E2EBB.7030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> <536EA597.3070700@selasky.org> <536EA753.40905@selasky.org> <1399764190.22079.425.camel@revolution.hippie.lan> <536F17A1.8060807@selasky.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 May 2014 07:06:18 -0600 Message-ID: <1399899978.22079.436.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" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 13:06:30 -0000 On Sun, 2014-05-11 at 08:24 +0200, Hans Petter Selasky wrote: > On 05/11/14 01:23, Ian Lepore wrote: > > On Sun, 2014-05-11 at 00:25 +0200, Hans Petter Selasky wrote: > >> Hi, > >> > >> This patch fixes the problem too: > >> > >> diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c > >> index 0490be7..8d53fab 100644 > >> --- a/sys/arm/arm/machdep.c > >> +++ b/sys/arm/arm/machdep.c > >> @@ -432,8 +432,12 @@ cpu_idle(int busy) > >> cpu_idleclock(); > >> } > >> #endif > >> + register_t s; > >> + s = intr_disable(); > >> if (!sched_runnable()) > >> cpu_sleep(0); > >> + intr_restore(s); > >> + > >> #ifndef NO_EVENTTIMERS > >> if (!busy) { > >> cpu_activeclock(); > >> > >> It appears some IRQ is happening when sched_runnable() is running, and > >> then cpu_sleep(0) is executed even though sched_runnable() is no longer > >> true. > >> > >> --HPS > > > > Aha! Now I think you're on to something. Even after explaining why > > interrupts should be disabled for WFI I didn't notice that we don't > > disable interrupts before WFI. (I wonder if this is why I sometimes see > > a lost timer interrupt and have to hit a key to un-wedge things.) > > > > Can you try the attached? The spinlock_enter/exit calls are essentially > > a combination of disabling interrupts and doing a critical_enter(). > > > > -- Ian > > Hi Ian, > > Your patch works! > > BTW: I see the "mips" platform might have a similar issue. > > --HPS Committed as r265913; thanks for tracking this down! -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon May 12 20:31:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 555032E0 for ; Mon, 12 May 2014 20:31:37 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3B82F2CDA for ; Mon, 12 May 2014 20:31:36 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 9AE525DEC1 for ; Mon, 12 May 2014 20:31:29 +0000 (UTC) Date: Mon, 12 May 2014 21:31:21 +0100 From: Andrew Turner To: freebsd-arm@freebsd.org Subject: Early boot code changes Message-ID: <20140512213121.6765ee5e@bender.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 20:31:37 -0000 Hello, I'm planning on committing the patch at [1]. As it affects the early boot process I would like people to review it to make sure I'm not about to break all non-Raspberry Pi boards. The patch has two parts, the first is to create a new platform infrastructure based on the PowerPC platform code. The second is to change the name of functions on platforms that do not yet use this code to make sure they still boot. The platform infrastructure is designed to help get us a GENERIC armv6 kernel. It uses kobj to select on boot which platform class to use. The intention is at some stage in the future this will be merged with the PowerPC code. To help with this there is a base class and an FDT class that inherits from this base. I have ported the bcm2835 to it already. It can be used as an example for the other platforms. Updating the other platforms shouldn't be too difficult as, at this stage, the existing initarm_* functions have a one to one mapping to the new code. Below is a simple example on using this with FDT. static platform_method_t bcm2835_methods[] = { PLATFORMMETHOD(platform_lastaddr, bcm2835_lastaddr), PLATFORMMETHOD_END, }; FDT_PLATFORM_DEF(bcm2835, "bcm2835", 0, "raspberrypi,model-b"); As the platform_lastaddr functions is required it implements this, and creates the platform definition to use the bcm2835_methods with a bcm2835 platform, no softc, and will match an FDT with a compatible string of "raspberrypi,model-b". Alternatively the user could set hw.platform to "bcm2835" in loader to use this platform. As I've renamed the functions on the platforms I haven't ported to the new platform code I don' expect any problems with them. Andrew [1] http://people.freebsd.org/~andrew/arm_platform.diff From owner-freebsd-arm@FreeBSD.ORG Mon May 12 23:24:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C2F0E50; Mon, 12 May 2014 23:24:33 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 796412198; Mon, 12 May 2014 23:24:32 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id a1so7628888wgh.27 for ; Mon, 12 May 2014 16:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4NYD1N4vQJ16T0MoLAHUahhd5eHeqFt+ZYAlo78WMHg=; b=A9fHh8CK/LNxAJRob7M/1OpNumhDqMkkAjNcNCypLoVzFcKB+31Z/RzemuXGZQtW6/ Z7h5IZT5T2eE4om1CFyTUC9qWtfED2wbMZkO02kOoU4Dp1e6/fmo5U+OaSSA1Mkat8if haEK05g3JhlSsU+qWaPRtyyqEt0sEeegKYjGd46OQyMquZ3Q6l5LX96XIZ34mSoS6iB4 iORVIYTt/NLLe/DpjnlhpEXGVHRgjAFjdgYayJ+V2dl4Jc3rAtoltnHSHizrmoH6LCsg EsRsT4tmSOMa8Poa/CqQJOPtiOpyiZIkH2+SRG1LtBocTR0OvRPAf/2gSZ/RWqQXgFUl aV0A== MIME-Version: 1.0 X-Received: by 10.180.103.5 with SMTP id fs5mr17902898wib.33.1399937070543; Mon, 12 May 2014 16:24:30 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Mon, 12 May 2014 16:24:30 -0700 (PDT) In-Reply-To: <1399899978.22079.436.camel@revolution.hippie.lan> References: <20140425154430.GA76168@utility-01.thismonkey.com> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <536E2EBB.7030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> <536EA597.3070700@selasky.org> <536EA753.40905@selasky.org> <1399764190.22079.425.camel@revolution.hippie.lan> <536F17A1.8060807@selasky.org> <1399899978.22079.436.camel@revolution.hippie.lan> Date: Mon, 12 May 2014 19:24:30 -0400 Message-ID: Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 23:24:33 -0000 On Mon, May 12, 2014 at 9:06 AM, Ian Lepore wrote: > Committed as r265913; thanks for tracking this down! I think I lost track of this in the email thread, but: 1) Was this the cause of the stalls Tim described on the BBB? 2) What's the criteria for this to be MFC'd back to 10-STABLE? From owner-freebsd-arm@FreeBSD.ORG Mon May 12 23:45:30 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB12D201; Mon, 12 May 2014 23:45:30 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 452BD2351; Mon, 12 May 2014 23:45:30 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WjzuS-0009sP-EV; Mon, 12 May 2014 23:45:28 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4CNjPJE034492; Mon, 12 May 2014 17:45:26 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ajsmkMzdW1cGOhTWFPnEQ Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Winston Smith In-Reply-To: References: <20140425154430.GA76168@utility-01.thismonkey.com> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <536E2EBB.7030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> <536EA597.3070700@selasky.org> <536EA753.40905@selasky.org> <1399764190.22079.425.camel@revolution.hippie.lan> <536F17A1.8060807@selasky.org> <1399899978.22079.436.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 May 2014 17:45:25 -0600 Message-ID: <1399938325.50937.6.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" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 23:45:31 -0000 On Mon, 2014-05-12 at 19:24 -0400, Winston Smith wrote: > On Mon, May 12, 2014 at 9:06 AM, Ian Lepore wrote: > > Committed as r265913; thanks for tracking this down! > > I think I lost track of this in the email thread, but: > > 1) Was this the cause of the stalls Tim described on the BBB? I don't think so. > 2) What's the criteria for this to be MFC'd back to 10-STABLE? Catching up with MFCs would be the main thing, and I'm getting started on that today. A few things here and there have been merged recently, but in general the arm tree was last sync'd 11->10 in a big way in mid-December. It's a little harder to keep arm stable branches in sync because on -current we've had so much instability for so long that it's a bit scary to MFC a change a few days or even a couple weeks after it goes into head, when you know that change is at best a small piece of fixing the overall stability and might actually de-stabilize the 10-stable branch. I think all that is calming down and things are in pretty good shape on -current right now, so it seems like a good time to get several months worth of work merged to 10-stable all at once (meaning over the next few days, as close as I can get to "at once" and still do some testing along the way). -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue May 13 00:40:57 2014 Return-Path: Delivered-To: FreeBSD-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFB8BB54 for ; Tue, 13 May 2014 00:40:57 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 522982765 for ; Tue, 13 May 2014 00:40:53 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s4D0eptZ008512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 May 2014 02:40:52 +0200 (CEST) (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 s4D0ecpk055064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2014 02:40:38 +0200 (CEST) (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 s4D0ec2D027793; Tue, 13 May 2014 02:40:38 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s4D0ec5l027792; Tue, 13 May 2014 02:40:38 +0200 (CEST) (envelope-from ticso) Date: Tue, 13 May 2014 02:40:38 +0200 From: Bernd Walter To: FreeBSD-arm@freebsd.org Subject: Re: iMX6 based Novena crowd funding project Message-ID: <20140513004037.GB25293@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140402231500.GF30097@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140402231500.GF30097@cicely7.cicely.de> 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: Bernd Walter X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 00:40:57 -0000 On Thu, Apr 03, 2014 at 01:15:00AM +0200, Bernd Walter wrote: > http://www.crowdsupply.com/kosagi/novena-open-laptop > I'm not quite happy with the bundling setup, but have been fascinated > by that board since I've first noticed it mid 2013. > Hope that one day we can run X on iMX6 as I'm not a Linux fan. Recently the Novena funding reached a 300k USD extended goal. This is especially interesting because at this rate some of the money will be used to develop an open source grafic driver for iMX6, which inludes HW acceleration. See above crowdsupply link for details. My main interest for iMX6 don't include display requirements, but I can imagine a few use cases where I want one. Not only as a notebook, but the novena board with its FPGA makes a nice lab platform. If you look a bunnies blog you will notice a digital scope project. http://www.bunniestudios.com/blog/?p=3957 -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue May 13 01:51:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FD2F3E2 for ; Tue, 13 May 2014 01:51:18 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DFA92C7E for ; Tue, 13 May 2014 01:51:18 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id x12so7810260wgg.9 for ; Mon, 12 May 2014 18:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=40SkgGHFZkwallx9o6ni0Bedu5cCuwEu5si5anhewpU=; b=CsBbQ/SSjwEUKE0goV4LmSEhmhQMtm1DLZk84kYCHGhmsOq/RFQfQxE9FFwwz3j/1S Dl/Yh2Y/Z4W+zAipQNu32HcNsTq1BzQG8UQZjjoZKdZ5iyujzdKMXlh9dqYaZk1wuoGw EedgKxV1P/+swNcj1rHkrlt4aKBy3IoE/efVUv+22GHuVpnRsXI1ayjyNleXMhWsdQZv Pidq7LsMLw7Ov6DKT5Pg5KJQmc6aAIJdgn1ZWb13uuU3evErjrGgE67zbg59z0P2VFS7 L/PBTVea1Mt0+slE6f9JjdwV33mywNh7NLabb8qf6Abhu4MQlEKL8Owj1wwSoV1nvqrB nOVw== MIME-Version: 1.0 X-Received: by 10.194.242.66 with SMTP id wo2mr18950208wjc.37.1399945875224; Mon, 12 May 2014 18:51:15 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Mon, 12 May 2014 18:51:15 -0700 (PDT) Date: Mon, 12 May 2014 21:51:15 -0400 Message-ID: Subject: 11-CURRENT: clang/error: no member named 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM' From: Winston Smith To: FreeBSD ARM Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 01:51:18 -0000 Cross compiling the tools for 11-CURRENT at r265941 yields: /usr/src/FreeBSD-CURRENT/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3687:15: error: no member named 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM'; did you mean 'VST1d64TPseudoWB_fixed'? case ARM::VLD1d64TPseudoWB_fixed: ~~~~~^~~~~~~~~~~~~~~~~~~~~~ VST1d64TPseudoWB_fixed ./ARMGenInstrInfo.inc.h:1969:5: note: 'VST1d64TPseudoWB_fixed' declared here VST1d64TPseudoWB_fixed = 1953, ^ /usr/src/FreeBSD-CURRENT/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3704:15: error: no member named 'VLD1d64QPseudoWB_fixed' in namespace 'llvm::ARM'; did you mean 'VST1d64QPseudoWB_fixed'? case ARM::VLD1d64QPseudoWB_fixed: ~~~~~^~~~~~~~~~~~~~~~~~~~~~ VST1d64QPseudoWB_fixed ./ARMGenInstrInfo.inc.h:1963:5: note: 'VST1d64QPseudoWB_fixed' declared here VST1d64QPseudoWB_fixed = 1947, ^ 2 errors generated. *** Error code 1 From owner-freebsd-arm@FreeBSD.ORG Tue May 13 02:01:47 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6849805; Tue, 13 May 2014 02:01:47 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AF862D37; Tue, 13 May 2014 02:01:47 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wk22L-000Gr2-Gk; Tue, 13 May 2014 02:01:45 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4D21hZY034568; Mon, 12 May 2014 20:01:43 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Zt7W5gMSN+kGqcvceAu7R Subject: Re: 11-CURRENT: clang/error: no member named 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM' From: Ian Lepore To: Winston Smith In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 May 2014 20:01:43 -0600 Message-ID: <1399946503.50937.9.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 , Dimitry Andric X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 02:01:47 -0000 On Mon, 2014-05-12 at 21:51 -0400, Winston Smith wrote: > Cross compiling the tools for 11-CURRENT at r265941 yields: > > > /usr/src/FreeBSD-CURRENT/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3687:15: > error: > no member named 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM'; did you > mean 'VST1d64TPseudoWB_fixed'? > case ARM::VLD1d64TPseudoWB_fixed: > ~~~~~^~~~~~~~~~~~~~~~~~~~~~ > VST1d64TPseudoWB_fixed > ./ARMGenInstrInfo.inc.h:1969:5: note: 'VST1d64TPseudoWB_fixed' declared here > VST1d64TPseudoWB_fixed = 1953, > ^ > /usr/src/FreeBSD-CURRENT/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3704:15: > error: > no member named 'VLD1d64QPseudoWB_fixed' in namespace 'llvm::ARM'; did you > mean 'VST1d64QPseudoWB_fixed'? > case ARM::VLD1d64QPseudoWB_fixed: > ~~~~~^~~~~~~~~~~~~~~~~~~~~~ > VST1d64QPseudoWB_fixed > ./ARMGenInstrInfo.inc.h:1963:5: note: 'VST1d64QPseudoWB_fixed' declared here > VST1d64QPseudoWB_fixed = 1947, > ^ > 2 errors generated. > *** Error code 1 I suspect r265925 is a good suspect and reverting it will probably get you moving again for now. Dimitry, was there maybe an updated header file missing from this import? -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue May 13 05:38:58 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3795C7; Tue, 13 May 2014 05:38:58 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E58C2DAD; Tue, 13 May 2014 05:38:57 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::9514:b315:fefb:2ce8] (unknown [IPv6:2001:7b8:3a7:0:9514:b315:fefb:2ce8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 681DC5C43; Tue, 13 May 2014 07:38:52 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_1D08BEF8-9126-4DBB-8D43-9410CFCAB26B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: 11-CURRENT: clang/error: no member named 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM' From: Dimitry Andric In-Reply-To: <1399946503.50937.9.camel@revolution.hippie.lan> Date: Tue, 13 May 2014 07:38:34 +0200 Message-Id: <6F8FBC17-D8BF-4B78-A6E1-6FFEFCC14838@FreeBSD.org> References: <1399946503.50937.9.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 05:38:58 -0000 --Apple-Mail=_1D08BEF8-9126-4DBB-8D43-9410CFCAB26B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 May 2014, at 04:01, Ian Lepore wrote: > On Mon, 2014-05-12 at 21:51 -0400, Winston Smith wrote: >> Cross compiling the tools for 11-CURRENT at r265941 yields: >>=20 >>=20 >> = /usr/src/FreeBSD-CURRENT/lib/clang/libllvmarmcodegen/../../../contrib/llvm= /lib/Target/ARM/ARMBaseInstrInfo.cpp:3687:15: >> error: >> no member named 'VLD1d64TPseudoWB_fixed' in namespace = 'llvm::ARM'; did you >> mean 'VST1d64TPseudoWB_fixed'? >> case ARM::VLD1d64TPseudoWB_fixed: >> ~~~~~^~~~~~~~~~~~~~~~~~~~~~ >> VST1d64TPseudoWB_fixed >> ./ARMGenInstrInfo.inc.h:1969:5: note: 'VST1d64TPseudoWB_fixed' = declared here >> VST1d64TPseudoWB_fixed =3D 1953, >> ^ >> = /usr/src/FreeBSD-CURRENT/lib/clang/libllvmarmcodegen/../../../contrib/llvm= /lib/Target/ARM/ARMBaseInstrInfo.cpp:3704:15: >> error: >> no member named 'VLD1d64QPseudoWB_fixed' in namespace = 'llvm::ARM'; did you >> mean 'VST1d64QPseudoWB_fixed'? >> case ARM::VLD1d64QPseudoWB_fixed: >> ~~~~~^~~~~~~~~~~~~~~~~~~~~~ >> VST1d64QPseudoWB_fixed >> ./ARMGenInstrInfo.inc.h:1963:5: note: 'VST1d64QPseudoWB_fixed' = declared here >> VST1d64QPseudoWB_fixed =3D 1947, >> ^ >> 2 errors generated. >> *** Error code 1 >=20 > I suspect r265925 is a good suspect and reverting it will probably get > you moving again for now. >=20 > Dimitry, was there maybe an updated header file missing from this > import? I don't think so, I built universe succesfully. I suspect that some of the tblgen-generated headers are out of date, and must be regenerated. Unfortunately, the dependency checking for these generated files does not always pick up changes. Probably the easiest way to fix this is to blow away your /usr/obj, and do a clean build. -Dimitry --Apple-Mail=_1D08BEF8-9126-4DBB-8D43-9410CFCAB26B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlNxr+kACgkQsF6jCi4glqMheQCfWJS0+M0qM+Dovzt1FZHRFz7Z 5/gAn0uJMEF3oc/CXnThVZnFrGjuUtBA =3+rN -----END PGP SIGNATURE----- --Apple-Mail=_1D08BEF8-9126-4DBB-8D43-9410CFCAB26B-- From owner-freebsd-arm@FreeBSD.ORG Tue May 13 05:50:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51BB922B; Tue, 13 May 2014 05:50:11 +0000 (UTC) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F4E32E6A; Tue, 13 May 2014 05:50:10 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id e49so5214890eek.35 for ; Mon, 12 May 2014 22:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zSuyqLGDY5EhbZGKJF37O4Lg2zjuAj6ejmcQaTJlOjM=; b=dsYHvNA404rBzRqzybmGJnfCAlaMkr/HMTfT43nck1IAnL1HkhnZA9dVygmSJertyW oIGR3xZ2K4YCe0bNrc2ymdIfKYoqh9GNxakJnGiJqV3LEVdVU0yx5sYacBIakNeQxRiy I6hsH2GXYJckJATgQSv7nntzS5M0x1FFV4AipocOUaF81GV9Mm/pRiE0VQv3wzKQnzrQ Nzy/cZEXbeYAqZB6d1+IMXCTJljNyqJykOD7FgGiiqsJeqyffNG7WzC61jgLfzlnqgp3 44SserePI9zcOq9ASqsXxHL8Dfxlc+TkMYXTUWRI5qbuceBSP/c93xPGq9nUL13gUoT+ u23w== X-Received: by 10.14.209.195 with SMTP id s43mr1276387eeo.69.1399960208733; Mon, 12 May 2014 22:50:08 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id ci54sm37746135eeb.19.2014.05.12.22.50.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 22:50:07 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5371B289.5030409@hot.ee> Date: Tue, 13 May 2014 08:50:01 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: 11-CURRENT: clang/error: no member named 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM' References: <1399946503.50937.9.camel@revolution.hippie.lan> In-Reply-To: <1399946503.50937.9.camel@revolution.hippie.lan> X-TagToolbar-Keys: D20140513085000827 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM , Dimitry Andric X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 05:50:11 -0000 On 2014-05-13 05:01, Ian Lepore wrote: > On Mon, 2014-05-12 at 21:51 -0400, Winston Smith wrote: >> Cross compiling the tools for 11-CURRENT at r265941 yields: >> >> >> /usr/src/FreeBSD-CURRENT/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3687:15: >> error: >> no member named 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM'; did you >> mean 'VST1d64TPseudoWB_fixed'? >> case ARM::VLD1d64TPseudoWB_fixed: >> ~~~~~^~~~~~~~~~~~~~~~~~~~~~ >> VST1d64TPseudoWB_fixed >> ./ARMGenInstrInfo.inc.h:1969:5: note: 'VST1d64TPseudoWB_fixed' declared here >> VST1d64TPseudoWB_fixed = 1953, >> ^ >> /usr/src/FreeBSD-CURRENT/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3704:15: >> error: >> no member named 'VLD1d64QPseudoWB_fixed' in namespace 'llvm::ARM'; did you >> mean 'VST1d64QPseudoWB_fixed'? >> case ARM::VLD1d64QPseudoWB_fixed: >> ~~~~~^~~~~~~~~~~~~~~~~~~~~~ >> VST1d64QPseudoWB_fixed >> ./ARMGenInstrInfo.inc.h:1963:5: note: 'VST1d64QPseudoWB_fixed' declared here >> VST1d64QPseudoWB_fixed = 1947, >> ^ >> 2 errors generated. >> *** Error code 1 > > I suspect r265925 is a good suspect and reverting it will probably get > you moving again for now. > > Dimitry, was there maybe an updated header file missing from this > import? > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > I managed to compile that new clang...?! however I'm on 9.x, so compiler is gcc. From owner-freebsd-arm@FreeBSD.ORG Tue May 13 07:10:01 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3E4F7C8 for ; Tue, 13 May 2014 07:10:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 865B52481 for ; Tue, 13 May 2014 07:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4D7A1Gn050779 for ; Tue, 13 May 2014 07:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4D7A1er050778; Tue, 13 May 2014 07:10:01 GMT (envelope-from gnats) Date: Tue, 13 May 2014 07:10:01 GMT Message-Id: <201405130710.s4D7A1er050778@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Matthias Meyser Subject: Re: arm/182060: make buildworld fails on Raspberry PI Reply-To: Matthias Meyser X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 07:10:01 -0000 The following reply was made to PR arm/182060; it has been noted by GNATS. From: Matthias Meyser To: bug-followup@FreeBSD.org, Meyser@xenet.de Cc: Subject: Re: arm/182060: make buildworld fails on Raspberry PI Date: Tue, 13 May 2014 09:05:51 +0200 Can be closed. Works with latest revision. -- Matthias From owner-freebsd-arm@FreeBSD.ORG Tue May 13 09:12:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B4354ED for ; Tue, 13 May 2014 09:12:29 +0000 (UTC) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7BCB2F88 for ; Tue, 13 May 2014 09:12:28 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id e51so171536eek.23 for ; Tue, 13 May 2014 02:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=/YHlyCRZWjgqwYa8DkaEYoTw1vV3LZ9edb4ulTX63dE=; b=g6bjXYIIaYVIDRYuLXaQDsps2wRu5esX5G1CqXlhDTEM1LBm6LEzAHaZU9LAcX07S6 93XXVssHvqOFoaGnp6oix5Me9qbDuJTz/Q1YvI3f5uIhPnKnNsxNmd8eWdoAtjmLPMuM ++rgF9VBIMoJOPJ0/QuT2kmmncS/k4+CB6zeqtHXzf4nlmPqc6Xoch1ukfr+GBmvBUZI 5cJHq5pe03X85+nglVjl3X3VR/A7LkK+bWJvqyj928Nqs28dZCrwRP9Qp+ZldE2jcWDn AaKO1j7j4JV0a4/KnjEkmrPfEi6Q9nYe8FbXS49p4jO9Mh2tcU9ssLGICbDyWqnk5Rqc GsXA== X-Received: by 10.15.49.8 with SMTP id i8mr37445600eew.33.1399972346886; Tue, 13 May 2014 02:12:26 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id w6sm38830256eej.7.2014.05.13.02.12.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 02:12:25 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5371E1F3.6080002@hot.ee> Date: Tue, 13 May 2014 12:12:19 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-arm Subject: Patch to make BBB properly boot from eMMC every time Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 09:12:29 -0000 On my BBB, I need following patch to boot from eMMC 100% of cases. Without that, device is detected with 1 / 4 bit bus (it's actually 8 bit) or not at all (then boot fails). Actually, that code looks like weird way to implement sleep(), or at least it has such (side) effect. Actually ian@ made that patch, and was confused about results. ------------------------------------------------------------------------- Index: sys/dev/mmc/mmc.c =================================================================== --- sys/dev/mmc/mmc.c (revision 264141) +++ sys/dev/mmc/mmc.c (working copy) @@ -769,8 +769,10 @@ mmc_test_bus_width(struct mmc_softc *sc) data.data = p8; data.len = 8; data.flags = MMC_DATA_WRITE; - mmc_wait_for_cmd(sc, &cmd, 0); - + err = mmc_wait_for_cmd(sc, &cmd, 0); + if (err != 0) + device_printf(sc->dev, "BUSTEST_W err %d\n", err); + memset(&cmd, 0, sizeof(cmd)); memset(&data, 0, sizeof(data)); cmd.opcode = MMC_BUSTEST_R; @@ -782,7 +784,12 @@ mmc_test_bus_width(struct mmc_softc *sc) data.len = 8; data.flags = MMC_DATA_READ; err = mmc_wait_for_cmd(sc, &cmd, 0); - + if (err != 0) + device_printf(sc->dev, "BUSTEST_R err %d\n", err); + + device_printf(sc->dev, "read %02x %02x %02x %02x %02x %02x %02x %02x\n", + buf[0], buf[1], buf[2], buf[3], buf[4], buf[5], buf[6], buf[7]); + mmcbr_set_bus_width(sc->dev, bus_width_1); mmcbr_update_ios(sc->dev); ------------------------------------------------------------------------- From owner-freebsd-arm@FreeBSD.ORG Tue May 13 13:30:20 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEE8C9A5 for ; Tue, 13 May 2014 13:30:20 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9377526C3 for ; Tue, 13 May 2014 13:30:20 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WkCmb-000Ka4-3g; Tue, 13 May 2014 13:30:13 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4DDU8TL035221; Tue, 13 May 2014 07:30:08 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19a6+QdkwttetKvNGoxYVmz Subject: Re: Patch to make BBB properly boot from eMMC every time From: Ian Lepore To: "Sulev-Madis Silber (ketas)" In-Reply-To: <5371E1F3.6080002@hot.ee> References: <5371E1F3.6080002@hot.ee> Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 2014 07:30:08 -0600 Message-ID: <1399987808.56626.2.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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 13:30:20 -0000 On Tue, 2014-05-13 at 12:12 +0300, Sulev-Madis Silber (ketas) wrote: > On my BBB, I need following patch to boot from eMMC 100% of cases. > Without that, device is detected with 1 / 4 bit bus (it's actually 8 > bit) or not at all (then boot fails). > > Actually, that code looks like weird way to implement sleep(), or at > least it has such (side) effect. > > Actually ian@ made that patch, and was confused about results. > > > ------------------------------------------------------------------------- > Index: sys/dev/mmc/mmc.c > =================================================================== > --- sys/dev/mmc/mmc.c (revision 264141) > +++ sys/dev/mmc/mmc.c (working copy) > @@ -769,8 +769,10 @@ mmc_test_bus_width(struct mmc_softc *sc) > data.data = p8; > data.len = 8; > data.flags = MMC_DATA_WRITE; > - mmc_wait_for_cmd(sc, &cmd, 0); > - > + err = mmc_wait_for_cmd(sc, &cmd, 0); > + if (err != 0) > + device_printf(sc->dev, "BUSTEST_W err %d\n", err); > + > memset(&cmd, 0, sizeof(cmd)); > memset(&data, 0, sizeof(data)); > cmd.opcode = MMC_BUSTEST_R; > @@ -782,7 +784,12 @@ mmc_test_bus_width(struct mmc_softc *sc) > data.len = 8; > data.flags = MMC_DATA_READ; > err = mmc_wait_for_cmd(sc, &cmd, 0); > - > + if (err != 0) > + device_printf(sc->dev, "BUSTEST_R err %d\n", err); > + > + device_printf(sc->dev, "read %02x %02x %02x %02x %02x > %02x %02x %02x\n", > + buf[0], buf[1], buf[2], buf[3], buf[4], buf[5], > buf[6], buf[7]); > + > mmcbr_set_bus_width(sc->dev, bus_width_1); > mmcbr_update_ios(sc->dev); > ------------------------------------------------------------------------- Confused about the cause of the results, yes. I think the printf I had you add to help me figure out the problem just changed the timing of the retry to make it work on the second try, but I have no idea why. Does anybody else with a BBB see the device randomly boot up as 1 or 4 or 8 bits, changing from one boot to the next? The bits are reported in the mmcsd0 line: mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block That's from a wandboard, but a BBB eMMC should always be 8 bits. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue May 13 13:58:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC0D4275 for ; Tue, 13 May 2014 13:58:33 +0000 (UTC) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A002C28FE for ; Tue, 13 May 2014 13:58:33 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id tp5so329740ieb.41 for ; Tue, 13 May 2014 06:58:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=6O/pUUs+8hQjhNHlRTi1EvJTAxL8JRKVNZQdOE3r+BM=; b=Cza4gHq8tgP1Sb4/webtQcuWXFgoVQ5AXVJYxR5xanc9KOU0a9nFV5Ki9jvEgnzHWp Oo5M00MI4G8ppdnvBGQgzOjYDxPz9PzsvBF8BZSDqaF+Z3MI5EAj+rzqKq1R6Bjle1WT ETK5I5MHMjOuHT3nEGwyEgb2rMg1gAsqmOcwhib88mn+mfCtZ+pkrHgYxXfUHgmhDJTl 8S/EcnDYMhObC3Q1TIaDBLHeYNes9Ihfyk40Bd3HsIAaGGjTKwiFiSB8KNVZnR8eeai8 72AUktY+u0krVzowIf+4AddE8LoWkh7I3gsG9NPg2uEnUv8LkymCdCaihWxj1z34QKVH NdZg== X-Gm-Message-State: ALoCoQlDuXT2AsAT1FtKu9VzPothzhhEFG19hA7ZgShbgjU80dQLedVtNVmi+c4VTQXLO9lLIqc6 X-Received: by 10.50.22.210 with SMTP id g18mr57111395igf.19.1399989507757; Tue, 13 May 2014 06:58:27 -0700 (PDT) Received: from [172.29.67.66] ([198.202.203.177]) by mx.google.com with ESMTPSA id rt10sm30290805igb.15.2014.05.13.06.58.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 06:58:27 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_1894230F-4BF6-4654-A743-747EFF139E9A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: 11-CURRENT: clang/error: no member named 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM' From: Warner Losh In-Reply-To: <6F8FBC17-D8BF-4B78-A6E1-6FFEFCC14838@FreeBSD.org> Date: Tue, 13 May 2014 07:58:25 -0600 Message-Id: <30ED030F-69E3-4E27-B492-3CBE30356DDE@bsdimp.com> References: <1399946503.50937.9.camel@revolution.hippie.lan> <6F8FBC17-D8BF-4B78-A6E1-6FFEFCC14838@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1874) Cc: FreeBSD ARM , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 13:58:33 -0000 --Apple-Mail=_1894230F-4BF6-4654-A743-747EFF139E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 12, 2014, at 11:38 PM, Dimitry Andric wrote: > On 13 May 2014, at 04:01, Ian Lepore wrote: >> On Mon, 2014-05-12 at 21:51 -0400, Winston Smith wrote: >>> Cross compiling the tools for 11-CURRENT at r265941 yields: >>>=20 >>>=20 >>> = /usr/src/FreeBSD-CURRENT/lib/clang/libllvmarmcodegen/../../../contrib/llvm= /lib/Target/ARM/ARMBaseInstrInfo.cpp:3687:15: >>> error: >>> no member named 'VLD1d64TPseudoWB_fixed' in namespace = 'llvm::ARM'; did you >>> mean 'VST1d64TPseudoWB_fixed'? >>> case ARM::VLD1d64TPseudoWB_fixed: >>> ~~~~~^~~~~~~~~~~~~~~~~~~~~~ >>> VST1d64TPseudoWB_fixed >>> ./ARMGenInstrInfo.inc.h:1969:5: note: 'VST1d64TPseudoWB_fixed' = declared here >>> VST1d64TPseudoWB_fixed =3D 1953, >>> ^ >>> = /usr/src/FreeBSD-CURRENT/lib/clang/libllvmarmcodegen/../../../contrib/llvm= /lib/Target/ARM/ARMBaseInstrInfo.cpp:3704:15: >>> error: >>> no member named 'VLD1d64QPseudoWB_fixed' in namespace = 'llvm::ARM'; did you >>> mean 'VST1d64QPseudoWB_fixed'? >>> case ARM::VLD1d64QPseudoWB_fixed: >>> ~~~~~^~~~~~~~~~~~~~~~~~~~~~ >>> VST1d64QPseudoWB_fixed >>> ./ARMGenInstrInfo.inc.h:1963:5: note: 'VST1d64QPseudoWB_fixed' = declared here >>> VST1d64QPseudoWB_fixed =3D 1947, >>> ^ >>> 2 errors generated. >>> *** Error code 1 >>=20 >> I suspect r265925 is a good suspect and reverting it will probably = get >> you moving again for now. >>=20 >> Dimitry, was there maybe an updated header file missing from this >> import? >=20 > I don't think so, I built universe succesfully. I suspect that some = of > the tblgen-generated headers are out of date, and must be regenerated. > Unfortunately, the dependency checking for these generated files does > not always pick up changes. >=20 > Probably the easiest way to fix this is to blow away your /usr/obj, = and > do a clean build. Any plans on fixing that problem with the build? Having stuff randomly = fail really isn=92t the FreeBSD way.[*] Warner [*] Yes, I know that there=92s at least one bug still with my build = refactor, but I plan on fixing that during BSDcan. --Apple-Mail=_1894230F-4BF6-4654-A743-747EFF139E9A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTciUBAAoJEGwc0Sh9sBEAp6YP/3G3oJERkousPvRA+Gv2Ac9w MrnZEyGuEQXSpof8Bm+dFCmFJytS3EMRyv/B4b1l6oUMFP6jG+zgTT4lQooAbhIp emUDEfe67gBV3XLPhEdFH4rXNHNvdx4d69r/J5KMlGcAoWpS/gOwj4L1J0J1JR/n 5cHiqj5e1mDFHMwvDjjOEG5YqrLhvZynmB7TRCLNi6oKkwosyJLRkaIzt182crg9 eY3wDN84ssU/nZV0NzBtTg+UELcehUMkmV/lo0O65DASjXn04gIz/tCBSt9IVsSd cOAc2HwJoST2DkzbYCcFMt+spi9EG1C2btultF4k0en8w/SPse2BxEuCFTFO0ady Iu5jV8swwowG4MgSaOIO+fsm4LT8X9CDnZ7y/wvTqFB0o65C0VtpwMOen6DLfdbu Vv4EkB9i+flEJpUKEoZOEfud+ifTyT+2vKbn4DYKyBS/LSt9YoypUI4tjU32SFQi 5eE3WXNMXca1FOMYC3KtQ/C05nC6g1gYj9oz1jnLGuBrfayDZ8bkUFlZyMVuQ0kk klKQ3BLLzRQ7ohZypuGP8+u+/CPTcqZcv+bGSfzyg74gBKHKXK0IOoGWwUC6gk47 QxoUp6FT2/l4bnza5cmoPiDXcykaoUurU4vWq+SilA1QNxlmkyH+gbW/L3nMK7wF sPLmuR7kTH2qHVEm0BIf =FBUy -----END PGP SIGNATURE----- --Apple-Mail=_1894230F-4BF6-4654-A743-747EFF139E9A-- From owner-freebsd-arm@FreeBSD.ORG Tue May 13 14:03:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5911506 for ; Tue, 13 May 2014 14:03:36 +0000 (UTC) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC4FA29B1 for ; Tue, 13 May 2014 14:03:36 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id y20so346647ier.20 for ; Tue, 13 May 2014 07:03:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=YW4pi2/NX3LuPiEo1XAm+q1IRlZ8sj/OPsy42xdsuHI=; b=JYLZNUFvoWCsFMdEAiObiAWiHE2P+d3KDW3ZZQe7IpRwGIsn2dLubJWy98kvcbg+Vd 1I5koM9jnVHeXBO+teJj56NIJUXI97LxCdBGWBJLuAnYoEwQhUsJ/4sl+5ezJVKg4BpH 7NW/G/7yL9W7aH+ktXxNnklyRaKrYsFzMSG19UugnH3unR4ouJEIhLYVQZw215x/cAZO jMiWZOM+lqg+0OZFhI0cajeIizzpAUqBXX6kcwTZPPl+GD08AQIhtm7JNM4TzUrEs4a2 Ca1FC7EwpkyszxgFRRMJz/JA+pe+u+ShcFt4NHUGD86APBf7NOyFPnzGxkM2KAG3djGK B9Eg== X-Gm-Message-State: ALoCoQk/HjqjIJ15j3X9PZsTIkDE0C+FXKF0rt3vDh8Ze9tnUgNblkPjqe/mHXWKlPeNOIzbvoEg X-Received: by 10.50.128.162 with SMTP id np2mr58833563igb.22.1399989809903; Tue, 13 May 2014 07:03:29 -0700 (PDT) Received: from [172.29.67.66] (63-156-62-129.dia.static.qwest.net. [63.156.62.129]) by mx.google.com with ESMTPSA id pi3sm30327867igb.5.2014.05.13.07.03.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 07:03:28 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_A3435621-31A0-41D8-837C-F9BFFB27DAA0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Patch to make BBB properly boot from eMMC every time From: Warner Losh In-Reply-To: <5371E1F3.6080002@hot.ee> Date: Tue, 13 May 2014 08:03:27 -0600 Message-Id: <8FE89E4A-1398-4321-BBBC-CA377C7981B1@bsdimp.com> References: <5371E1F3.6080002@hot.ee> To: "Sulev-Madis Silber (ketas)" X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 14:03:37 -0000 --Apple-Mail=_A3435621-31A0-41D8-837C-F9BFFB27DAA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 13, 2014, at 3:12 AM, Sulev-Madis Silber (ketas) = wrote: > On my BBB, I need following patch to boot from eMMC 100% of cases. > Without that, device is detected with 1 / 4 bit bus (it's actually 8 > bit) or not at all (then boot fails). >=20 > Actually, that code looks like weird way to implement sleep(), or at > least it has such (side) effect. So you added a printf and the problem went away. That=92s good info, but = not sufficient. Does the problem go away if you put a DELAY(10) or = something like that instead? That=92s a better fix, or better yet, more = nuanced retry... Warner > Actually ian@ made that patch, and was confused about results. >=20 >=20 > = ------------------------------------------------------------------------- > Index: sys/dev/mmc/mmc.c > =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 > --- sys/dev/mmc/mmc.c (revision 264141) > +++ sys/dev/mmc/mmc.c (working copy) > @@ -769,8 +769,10 @@ mmc_test_bus_width(struct mmc_softc *sc) > data.data =3D p8; > data.len =3D 8; > data.flags =3D MMC_DATA_WRITE; > - mmc_wait_for_cmd(sc, &cmd, 0); > - > + err =3D mmc_wait_for_cmd(sc, &cmd, 0); > + if (err !=3D 0) > + device_printf(sc->dev, "BUSTEST_W err %d\n", = err); > + > memset(&cmd, 0, sizeof(cmd)); > memset(&data, 0, sizeof(data)); > cmd.opcode =3D MMC_BUSTEST_R; > @@ -782,7 +784,12 @@ mmc_test_bus_width(struct mmc_softc *sc) > data.len =3D 8; > data.flags =3D MMC_DATA_READ; > err =3D mmc_wait_for_cmd(sc, &cmd, 0); > - > + if (err !=3D 0) > + device_printf(sc->dev, "BUSTEST_R err %d\n", = err); > + > + device_printf(sc->dev, "read %02x %02x %02x %02x %02x > %02x %02x %02x\n", > + buf[0], buf[1], buf[2], buf[3], buf[4], = buf[5], > buf[6], buf[7]); > + > mmcbr_set_bus_width(sc->dev, bus_width_1); > mmcbr_update_ios(sc->dev); > = ------------------------------------------------------------------------- > _______________________________________________ > 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" --Apple-Mail=_A3435621-31A0-41D8-837C-F9BFFB27DAA0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTciYvAAoJEGwc0Sh9sBEAMw4QALZ3QZ0d1NoEAWpT14L2w5s4 5xmViT2vOMfVan1Uu8LsGoI0th+VY04dD1KhJsKYvYsDb1gREgp2LwOllxwMEa26 N8uMRoXes5/SBjuhXTgTUD8Iz9IjaPH9+UpoNrddU5VhA7OtjUXYgLWMwQc9aL5c dMlTM3r4305xrwoLQnQf4zq36vAPgsvodoiH2TDmac9wTcWdugGPfsCUqC2TnoTG qepbxWDW8uD4IoUwtb3JOfB2HWmnwfFGt6ZUyLpD1C3K2VFKgTRK9HNscqHaKdAL xTcXlyrG3dSaLiHwUCkvMnmWXHT8SOiI1OYXbnzWzRqgD6g1PpUB780yq/84ig2d 8MTeeiib1tEXPcdSZ19YH+nIsrPtpYz+q8wtXjEzO9azyxgYj2FEeLyZYRNQiWDj WMkyl+QPftM2V2H6oofn5DMOjAppQzixGd5+Uw6vpkmxn3MgEE0GC12C6kV0vq1y AS8M4Kv57kzqZlDhhud/v5iN0uwzBPMzuJ/Z86o1iTQLEp6GL9ynH08KxIGPQym6 F5UpBIso+RYY93BrPWDuiCS5N6PjuL43je1LrE8DiUEYNOkeT6RI0qFaCfrVR5T4 TwyQ1FeTOhMJ95fVQjQNElmrW6GosVdBrpPZ25KP3Q2X9V00TdH6xUJ6X85JDUIV Ef/u76dU/ZHrPVtMtNRl =yrhZ -----END PGP SIGNATURE----- --Apple-Mail=_A3435621-31A0-41D8-837C-F9BFFB27DAA0-- From owner-freebsd-arm@FreeBSD.ORG Tue May 13 14:12:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7E5C6D2 for ; Tue, 13 May 2014 14:12:23 +0000 (UTC) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CCA92A84 for ; Tue, 13 May 2014 14:12:23 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h3so423530igd.8 for ; Tue, 13 May 2014 07:12:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=RyK6td3dVh6R3GQkDqFidv+TwSipuEmWdkKPtdrGLNc=; b=dqy4e/cNqR94kpY7QqX9aKibqNSjxLAWJmF2H0kkwkcIy4Bkr8OU0QMMFQFDlo4cpy NYPDh5TNkygvpcjPckK0tr+8fj6OETyLx/NGCVN11SU+xQBwqOJyDpyBszXrhCHWT6Lp 1VDmFm2dzxXXFsDSq7DdDsfG0bXJmlQ3kopKcvvd5kpfwANkXpL2KZwVNRCGhOv6nR3d qD9asTvsvCtwLZ5aMEVfo6RihzX3b5c0AVID7Es21wamaMZogqQohmyqIGATDXPgKWUo ONLNwN6w5uA4wFgUGL1O1HqhDsgm7140qIbHfAAvME1Ext8GQM4J3HymBN1/XYtpfvWu ph3A== X-Gm-Message-State: ALoCoQnH3xm6fDSdCeOzy9J5G/YWKDNTXXMfKa2kUojvDiHPPk+y9l51+fb75rq/sMANxLa3GPqZ X-Received: by 10.50.238.229 with SMTP id vn5mr56747918igc.45.1399989851842; Tue, 13 May 2014 07:04:11 -0700 (PDT) Received: from [172.29.67.66] (63-156-62-129.dia.static.qwest.net. [63.156.62.129]) by mx.google.com with ESMTPSA id pi3sm30327867igb.5.2014.05.13.07.04.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 07:04:11 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_A79B79DD-6A0B-4280-9C9F-20AEC9DADD29"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Patch to make BBB properly boot from eMMC every time From: Warner Losh In-Reply-To: <1399987808.56626.2.camel@revolution.hippie.lan> Date: Tue, 13 May 2014 08:04:10 -0600 Message-Id: References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 14:12:23 -0000 --Apple-Mail=_A79B79DD-6A0B-4280-9C9F-20AEC9DADD29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 13, 2014, at 7:30 AM, Ian Lepore wrote: > On Tue, 2014-05-13 at 12:12 +0300, Sulev-Madis Silber (ketas) wrote: >> On my BBB, I need following patch to boot from eMMC 100% of cases. >> Without that, device is detected with 1 / 4 bit bus (it's actually 8 >> bit) or not at all (then boot fails). >>=20 >> Actually, that code looks like weird way to implement sleep(), or at >> least it has such (side) effect. >>=20 >> Actually ian@ made that patch, and was confused about results. >>=20 >>=20 >> = ------------------------------------------------------------------------- >> Index: sys/dev/mmc/mmc.c >> =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 >> --- sys/dev/mmc/mmc.c (revision 264141) >> +++ sys/dev/mmc/mmc.c (working copy) >> @@ -769,8 +769,10 @@ mmc_test_bus_width(struct mmc_softc *sc) >> data.data =3D p8; >> data.len =3D 8; >> data.flags =3D MMC_DATA_WRITE; >> - mmc_wait_for_cmd(sc, &cmd, 0); >> - >> + err =3D mmc_wait_for_cmd(sc, &cmd, 0); >> + if (err !=3D 0) >> + device_printf(sc->dev, "BUSTEST_W err %d\n", = err); >> + >> memset(&cmd, 0, sizeof(cmd)); >> memset(&data, 0, sizeof(data)); >> cmd.opcode =3D MMC_BUSTEST_R; >> @@ -782,7 +784,12 @@ mmc_test_bus_width(struct mmc_softc *sc) >> data.len =3D 8; >> data.flags =3D MMC_DATA_READ; >> err =3D mmc_wait_for_cmd(sc, &cmd, 0); >> - >> + if (err !=3D 0) >> + device_printf(sc->dev, "BUSTEST_R err %d\n", = err); >> + >> + device_printf(sc->dev, "read %02x %02x %02x %02x %02x >> %02x %02x %02x\n", >> + buf[0], buf[1], buf[2], buf[3], buf[4], = buf[5], >> buf[6], buf[7]); >> + >> mmcbr_set_bus_width(sc->dev, bus_width_1); >> mmcbr_update_ios(sc->dev); >> = ------------------------------------------------------------------------- >=20 > Confused about the cause of the results, yes. I think the printf I = had > you add to help me figure out the problem just changed the timing of = the > retry to make it work on the second try, but I have no idea why. >=20 > Does anybody else with a BBB see the device randomly boot up as 1 or 4 > or 8 bits, changing from one boot to the next? The bits are reported = in > the mmcsd0 line: >=20 > mmcsd0: 8GB at mmc0 > 50.0MHz/4bit/65535-block >=20 > That's from a wandboard, but a BBB eMMC should always be 8 bits. I=92m away from my BBB atm, but I=92ll test this when I get back=85 Warner --Apple-Mail=_A79B79DD-6A0B-4280-9C9F-20AEC9DADD29 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTciZaAAoJEGwc0Sh9sBEAMQUQANejoxbxDy6dpkDKXF4P+OQ5 yzUvqGWgRORGv9qlks88iEWSt/Cz5lgaI1NhFfGt0r+HOPGPrk2WHXnFwxfALm9X Jj7LKzK90jwLAi2YeIGdMQoKceIELIS8c5tZi+C0PnOdWIq3x21c/4pAOCS/Mhxa t7euol7/oCA9kspVerrGHiq2ascRsp93rJlQenmcyedWMg6fChT1/AUqMpcE6qxk /mzL7GFKe8guQvxt+qKhzdC+KyKOSfgo1GPBqfIzHnFoRZbbMWCtQJnaEe0KPhws w2l3mp22e0eiefppal+Du7ql7fsXLMvkvwh5RuXYdR1gDw55TQoH1CIvP1drc4mO k+9us9+aCO2QwR7sgyJUTqDdwyVS+1nVsGiwkNdT7Fe9NSPhktis2xQkV/b+2W1t QcEMLSolK7PH/fFPQsb4X7JoBO6HBJCl8XbC7oKO+hOeer8A006FTDTmeC87hsEg ZNNdTLcSNc/c6BEtgxrIpCQK8Mfy8vKsRTiYE/Ub7OFeCB5aaAZxhfPM6tNWFxAd 8eAH5oSNmNRQtLoyzT89JdolahDWf+43mJ21vEDcXMQiwtUPD27Bjhs08M6QORlu LFxV/MD/ucYvE7NFBS2b8xw1xSbWJpQTbtaJ3RSG7UmU5R8Zf2d6Jxp2G1uZkw4z 2Eh8KZoghXR1AnB7XsRQ =mwjJ -----END PGP SIGNATURE----- --Apple-Mail=_A79B79DD-6A0B-4280-9C9F-20AEC9DADD29-- From owner-freebsd-arm@FreeBSD.ORG Tue May 13 14:17:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88D4C766; Tue, 13 May 2014 14:17:43 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0029B2AB3; Tue, 13 May 2014 14:17:42 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id u56so459872wes.28 for ; Tue, 13 May 2014 07:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EPmXXrkPxtQfstu1so19zJeEwfcN4f5x0gOOxinT4/s=; b=XvMAG0lsOwfzkS0auxuNhzee09ow40lSuNdgz9oqtnU1tr2AJtkdGoceV6WVpQTy41 x6i39dn70RzoYxPSpp8r7b/t6MWLbCz87O6e2EtAVfxidBxNUGNeJ/9cw7FN3434wEeC Uv/je5i/mTU8xkK2TNSYPXYul1z8drKfTylSXmMZlefYGSwYBX5WrHSFJzxI8/SCgNEe JgHR9fEHUFUj7u/iFnTP3isDY8A69MLv4Zi48ZReoPbQ7xU+i6o9RKdBsuTLyTPKMinC DmkJh3FEUq5nV9vHS1CpIp2LhbL+DaVLeWAOoSbh6lHQWtcbFG6nDKBFwqO20CryLFzy JcFQ== MIME-Version: 1.0 X-Received: by 10.180.8.136 with SMTP id r8mr21270092wia.60.1399990661125; Tue, 13 May 2014 07:17:41 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Tue, 13 May 2014 07:17:41 -0700 (PDT) In-Reply-To: <1399987808.56626.2.camel@revolution.hippie.lan> References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> Date: Tue, 13 May 2014 10:17:41 -0400 Message-ID: Subject: Re: Patch to make BBB properly boot from eMMC every time From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 14:17:43 -0000 On Tue, May 13, 2014 at 9:30 AM, Ian Lepore wrote: > Confused about the cause of the results, yes. I think the printf I had > you add to help me figure out the problem just changed the timing of the > retry to make it work on the second try, but I have no idea why. > > Does anybody else with a BBB see the device randomly boot up as 1 or 4 > or 8 bits, changing from one boot to the next? The bits are reported in > the mmcsd0 line: > > mmcsd0: 8GB at mmc0 > 50.0MHz/4bit/65535-block > > That's from a wandboard, but a BBB eMMC should always be 8 bits. BBB rev A6A shows 8-bits (for the eMMC): mmcsd1: 2GB at mmc1 48.0MHz/8bit/65535-block But shows 4-bits for the SD card: mmcsd0: 4GB at mmc0 48.0MHz/4bit/65535-block From owner-freebsd-arm@FreeBSD.ORG Tue May 13 14:26:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01422A19; Tue, 13 May 2014 14:26:40 +0000 (UTC) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.site.uottawa.ca", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE28F2B8E; Tue, 13 May 2014 14:26:38 +0000 (UTC) Received: from admin16.site.uottawa.ca (admin16.site.uottawa.ca [137.122.90.250]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.4) with ESMTP id s4DE3vSj046994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 May 2014 10:03:57 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Tue, 13 May 2014 10:03:57 -0400 (EDT) From: Keith White To: Ian Lepore Subject: Re: Patch to make BBB properly boot from eMMC every time In-Reply-To: <1399987808.56626.2.camel@revolution.hippie.lan> Message-ID: <20140513100155.M27352@admin16.site.uottawa.ca> References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 14:26:40 -0000 On Tue, 13 May 2014, Ian Lepore wrote: > On Tue, 2014-05-13 at 12:12 +0300, Sulev-Madis Silber (ketas) wrote: >> On my BBB, I need following patch to boot from eMMC 100% of cases. >> Without that, device is detected with 1 / 4 bit bus (it's actually 8 >> bit) or not at all (then boot fails). >> >> Actually, that code looks like weird way to implement sleep(), or at >> least it has such (side) effect. >> >> Actually ian@ made that patch, and was confused about results. >> >> >> ------------------------------------------------------------------------- >> Index: sys/dev/mmc/mmc.c >> =================================================================== >> --- sys/dev/mmc/mmc.c (revision 264141) >> +++ sys/dev/mmc/mmc.c (working copy) >> @@ -769,8 +769,10 @@ mmc_test_bus_width(struct mmc_softc *sc) >> data.data = p8; >> data.len = 8; >> data.flags = MMC_DATA_WRITE; >> - mmc_wait_for_cmd(sc, &cmd, 0); >> - >> + err = mmc_wait_for_cmd(sc, &cmd, 0); >> + if (err != 0) >> + device_printf(sc->dev, "BUSTEST_W err %d\n", err); >> + >> memset(&cmd, 0, sizeof(cmd)); >> memset(&data, 0, sizeof(data)); >> cmd.opcode = MMC_BUSTEST_R; >> @@ -782,7 +784,12 @@ mmc_test_bus_width(struct mmc_softc *sc) >> data.len = 8; >> data.flags = MMC_DATA_READ; >> err = mmc_wait_for_cmd(sc, &cmd, 0); >> - >> + if (err != 0) >> + device_printf(sc->dev, "BUSTEST_R err %d\n", err); >> + >> + device_printf(sc->dev, "read %02x %02x %02x %02x %02x >> %02x %02x %02x\n", >> + buf[0], buf[1], buf[2], buf[3], buf[4], buf[5], >> buf[6], buf[7]); >> + >> mmcbr_set_bus_width(sc->dev, bus_width_1); >> mmcbr_update_ios(sc->dev); >> ------------------------------------------------------------------------- > > Confused about the cause of the results, yes. I think the printf I had > you add to help me figure out the problem just changed the timing of the > retry to make it work on the second try, but I have no idea why. > > Does anybody else with a BBB see the device randomly boot up as 1 or 4 > or 8 bits, changing from one boot to the next? The bits are reported in > the mmcsd0 line: > > mmcsd0: 8GB at mmc0 > 50.0MHz/4bit/65535-block > > That's from a wandboard, but a BBB eMMC should always be 8 bits. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Yes, I have the same problem with a BBB. The above patch appears to workaround it. ...keith -- Keith White, genie.uottawa.ca engineering.uottawa.ca kwhite@uottawa.ca [+1 613 562 5800 x6681] From owner-freebsd-arm@FreeBSD.ORG Tue May 13 14:33:56 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C914BE6 for ; Tue, 13 May 2014 14:33:56 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F38E2C3B for ; Tue, 13 May 2014 14:33:55 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WkDmE-000GFp-OA; Tue, 13 May 2014 14:33:54 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4DEXqFn035273; Tue, 13 May 2014 08:33:52 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/dzB0QfU4clB4FWMMPbx2c Subject: Re: Patch to make BBB properly boot from eMMC every time From: Ian Lepore To: Winston Smith In-Reply-To: References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 2014 08:33:52 -0600 Message-ID: <1399991632.56626.7.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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 14:33:56 -0000 On Tue, 2014-05-13 at 10:17 -0400, Winston Smith wrote: > On Tue, May 13, 2014 at 9:30 AM, Ian Lepore wrote: > > Confused about the cause of the results, yes. I think the printf I had > > you add to help me figure out the problem just changed the timing of the > > retry to make it work on the second try, but I have no idea why. > > > > Does anybody else with a BBB see the device randomly boot up as 1 or 4 > > or 8 bits, changing from one boot to the next? The bits are reported in > > the mmcsd0 line: > > > > mmcsd0: 8GB at mmc0 > > 50.0MHz/4bit/65535-block > > > > That's from a wandboard, but a BBB eMMC should always be 8 bits. > > BBB rev A6A shows 8-bits (for the eMMC): > > mmcsd1: 2GB > at mmc1 48.0MHz/8bit/65535-block > > > But shows 4-bits for the SD card: > > mmcsd0: 4GB at mmc0 > 48.0MHz/4bit/65535-block 4 bits is normal for an sdcard, that's all the data lines an sdcard has. An emmc card/chip can have 1, 4, or 8. Does your emmc come up as 8-bit reliably every time? -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue May 13 14:50:00 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D86EB3BB; Tue, 13 May 2014 14:50:00 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AED0C2D5F; Tue, 13 May 2014 14:50:00 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WkE1n-0001QC-Jm; Tue, 13 May 2014 14:49:59 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4DEnvAn035281; Tue, 13 May 2014 08:49:57 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+4IK8f1gQBkrXB562kbhHR Subject: Heads-up: massive MFC from 11->10-stable for (mostly) ARM stuff From: Ian Lepore To: freebsd-arm , freebsd-stable@FreeBSD.org Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 2014 08:49:56 -0600 Message-ID: <1399992596.56626.14.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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 14:50:00 -0000 This is just an fyi that I'm going to spend the new few days doing a massive merge of ARM-related work from -current to 10-stable. This is merging pretty much all the ARM development that has happened since the end of November, so that at the end of it we'll have SMP and hardware floating point and all the bugfixes we've done recently for ARM in 10. All in all I've identified about 450 changesets to merge. In some cases this will touch things outside of sys/arm, mostly powerpc and mips stuff as some FDT/OFW changes come along for the ride. I'm going to do my best to not have any checkins that cause even temporary build breakage, but... you know... it's going to happen. If you run into breakage and it isn't fixed within a few minutes, feel free to let me know and I'll get right on it. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue May 13 14:52:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30EAE516; Tue, 13 May 2014 14:52:47 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74EC12E0B; Tue, 13 May 2014 14:52:46 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id m15so496757wgh.4 for ; Tue, 13 May 2014 07:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=188FdxwGNbQf5Bg2IRM/rM6O6j0CMkhdai4oRZEHQAc=; b=R6HgDhwHtkMqjZq2L/6DgM3RImsi6KJmzG1GNcCuXL3CybGQP1ly8niswsBYQgJc4a xi4c/zI2ohoTjlKv71N3d6y3GaihkaOErU++tLwt0vOkODpVF2pEwxYXmE4revluKeZe sS1nST+3RfXTECAMPCf7pFV2DheDVhtHddwXvikJoQngktgj6jzCaP7dB+Q052wQTCtf aNozykhRNj48d1cFXtrQB38dcjle9ee3jiaCNr7D155WP7xdMMmisWCz6Ty/hkYW1XWa ZrfpPSk7Agm8hwMQB+q0B97fdXLHvnNQ8xjwrM6Q7oq37SzcClkDpF9ZTQQuEsjA+nAL 1Cjg== MIME-Version: 1.0 X-Received: by 10.180.103.5 with SMTP id fs5mr21428910wib.33.1399992764763; Tue, 13 May 2014 07:52:44 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Tue, 13 May 2014 07:52:44 -0700 (PDT) In-Reply-To: <6F8FBC17-D8BF-4B78-A6E1-6FFEFCC14838@FreeBSD.org> References: <1399946503.50937.9.camel@revolution.hippie.lan> <6F8FBC17-D8BF-4B78-A6E1-6FFEFCC14838@FreeBSD.org> Date: Tue, 13 May 2014 10:52:44 -0400 Message-ID: Subject: Re: 11-CURRENT: clang/error: no member named 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM' From: Winston Smith To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 14:52:47 -0000 On Tue, May 13, 2014 at 1:38 AM, Dimitry Andric wrote: > I don't think so, I built universe succesfully. I suspect that some of > the tblgen-generated headers are out of date, and must be regenerated. > Unfortunately, the dependency checking for these generated files does > not always pick up changes. > > Probably the easiest way to fix this is to blow away your /usr/obj, and > do a clean build. That resolved it, thanks! From owner-freebsd-arm@FreeBSD.ORG Tue May 13 15:02:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1DD3AF2; Tue, 13 May 2014 15:02:50 +0000 (UTC) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBECC2F1C; Tue, 13 May 2014 15:02:50 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id rr13so382507pbb.21 for ; Tue, 13 May 2014 08:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=iHCbFV5YNqJ76HK+Sk2nsQ80qVrDiSOlfK29IvL7Xj8=; b=LJF9pJHbvKRCL9uHfSs1wQNwuccGED3L1AeIgGk/fFOny/16RQeVbiZ9U8hp3caeCj WvYWpx8YBoC0FPYUYQV2Ms6WcUXjMcwflN4bBJPxE6wP1//2y72dFpUkjF2/6hhYnyK4 +EOUMleKno4WEKg/PVuRWalyxd0TY6+jn06evaiKLinbuxnfbpVM0PWGe/2s6x6H5yhM UZNZT0/4T9QJODJCp+Ait3OS/Q4FOXsEhiBjelWMNy7GfKwjllz2h3JyEzP4J3aUtd8E A9j56U3p9ya3DkB5J4FwYXcp5XYFi4/DoVbP6agEbPjKC4o4P1M2H08+f4OQxyUd4WZ/ 9Vnw== X-Received: by 10.68.215.3 with SMTP id oe3mr5808425pbc.109.1399993370320; Tue, 13 May 2014 08:02:50 -0700 (PDT) Received: from [192.168.1.118] ([221.232.45.62]) by mx.google.com with ESMTPSA id oz7sm28722081pbc.41.2014.05.13.08.02.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 08:02:49 -0700 (PDT) Message-ID: <53723413.8070306@gmail.com> Date: Tue, 13 May 2014 23:02:43 +0800 From: k simon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ian Lepore , freebsd-arm , freebsd-stable@FreeBSD.org Subject: Re: Heads-up: massive MFC from 11->10-stable for (mostly) ARM stuff References: <1399992596.56626.14.camel@revolution.hippie.lan> In-Reply-To: <1399992596.56626.14.camel@revolution.hippie.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 15:02:51 -0000 Great jobs, Ian. Cheers Simon 于 14-5-13 22:49, Ian Lepore 写道: > This is just an fyi that I'm going to spend the new few days doing a > massive merge of ARM-related work from -current to 10-stable. This is > merging pretty much all the ARM development that has happened since the > end of November, so that at the end of it we'll have SMP and hardware > floating point and all the bugfixes we've done recently for ARM in 10. > All in all I've identified about 450 changesets to merge. > > In some cases this will touch things outside of sys/arm, mostly powerpc > and mips stuff as some FDT/OFW changes come along for the ride. I'm > going to do my best to not have any checkins that cause even temporary > build breakage, but... you know... it's going to happen. If you run > into breakage and it isn't fixed within a few minutes, feel free to let > me know and I'll get right on it. > > -- Ian > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Tue May 13 16:13:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2ADCAF; Tue, 13 May 2014 16:13:02 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AD2325DA; Tue, 13 May 2014 16:13:02 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id w61so636534wes.12 for ; Tue, 13 May 2014 09:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eVf6vt8uSWc3kJjDc2jDMnu2lJ0ftsJjl8ES6UcJ6zU=; b=iRJiI/kOH9d5zVozKgWANSpTfAEZsVzEkFXYC9ZXT5GsMd6/fg5aFgQBZyHVSk0yKG neZCvpak0ZByRsvhsJy11ISqKQ3j3Am3W9cSUBC3ZN2cZQO34SL0Ia30ewxZPgDEcop6 V1k+FrgYubhMpm5Ctmou2NGIRfyxfYeRl8pew4bQpUCFdnW5LjXASR8MNyn0VT5Sjkou VYQH5gj7Qd1Ij9pCCyu2xuGEuwJZXXFWeo/KMS08TjOH2fG+EUeq4g3s557pHqgfxPmP Tk26pxTnfrQEQhxcTnVvJ5bREi4rspVgQawRLMQfSSyRgPFZQFW7c1zU4fe2KGAhTEE0 UfMw== MIME-Version: 1.0 X-Received: by 10.194.57.38 with SMTP id f6mr3319840wjq.59.1399997579607; Tue, 13 May 2014 09:12:59 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Tue, 13 May 2014 09:12:59 -0700 (PDT) In-Reply-To: <1399991632.56626.7.camel@revolution.hippie.lan> References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> <1399991632.56626.7.camel@revolution.hippie.lan> Date: Tue, 13 May 2014 12:12:59 -0400 Message-ID: Subject: Re: Patch to make BBB properly boot from eMMC every time From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:13:02 -0000 On Tue, May 13, 2014 at 10:33 AM, Ian Lepore wrote: > Does your emmc come up as 8-bit reliably every time? I booted 4-5 times and it came up as 8-bit every time. Interestingly, there is a 15 hang right before it prints the emmc msg: uhub1: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered ####### HANGS FOR 15 SECONDS ####### mmcsd1: 2GB at mmc1 48.0MHz/8bit/65535-block This is an older 11-CURRENT build from a week ago (r265338M; the M is from some i2c debugging I was doing). From owner-freebsd-arm@FreeBSD.ORG Tue May 13 16:20:39 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23BD61F7; Tue, 13 May 2014 16:20:39 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4F8E2652; Tue, 13 May 2014 16:20:38 +0000 (UTC) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 92A211C1049AB; Tue, 13 May 2014 18:20:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: svn commit: r265927 - head/sys/dev/vt From: Michael Tuexen In-Reply-To: <201405121929.s4CJTcBx010967@svn.freebsd.org> Date: Tue, 13 May 2014 18:20:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2899E6ED-712E-46BC-960B-9847FD99431C@freebsd.org> References: <201405121929.s4CJTcBx010967@svn.freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" , src-committers@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:20:39 -0000 Hi Aleksandr, could it be that this commit results in the following panic when booting a Raspberry Pi: fb0: 656x416(0x0@0,0) 16bpp fb0: pitch 1312, base 0x5e006000, screen_size 545792 fbd0 on fb0 VT: initialize with new VT driver "fb". panic: mtx_lock() of spin mutex (null) @ = /usr/home/tuexen/head/sys/dev/vt/vt_core.c:2035 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> where=20 Tracing pid 0 tid 100000 td 0xc06648a0 db_trace_self() at db_trace_self pc =3D 0xc0495760 lr =3D 0xc0130fdc (db_stack_trace+0xf4) sp =3D 0xc075ea68 fp =3D 0xc075ea80 r10 =3D 0xc0663930 db_stack_trace() at db_stack_trace+0xf4 pc =3D 0xc0130fdc lr =3D 0xc013094c (db_command+0x270) sp =3D 0xc075ea88 fp =3D 0xc075eb28 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000072 db_command() at db_command+0x270 pc =3D 0xc013094c lr =3D 0xc01306b0 (db_command_loop+0x60) sp =3D 0xc075eb30 fp =3D 0xc075eb40 r4 =3D 0xc04d5176 r5 =3D 0xc04ef7ba r6 =3D 0xc066391c r7 =3D 0xc0590b40 r8 =3D 0xc065a294 r9 =3D 0xc065a290 r10 =3D 0xc075ed10 db_command_loop() at db_command_loop+0x60 pc =3D 0xc01306b0 lr =3D 0xc0133078 (db_trap+0xd8) sp =3D 0xc075eb48 fp =3D 0xc075ec68 r4 =3D 0x00000000 r5 =3D 0xc0663928 r6 =3D 0xc065a2c0 db_trap() at db_trap+0xd8 pc =3D 0xc0133078 lr =3D 0xc028de10 (kdb_trap+0xbc) sp =3D 0xc075ec70 fp =3D 0xc075ec90 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0xc065a2c0 r7 =3D 0xc0590b40 kdb_trap() at kdb_trap+0xbc pc =3D 0xc028de10 lr =3D 0xc04a90e0 = (undefinedinstruction+0x298) sp =3D 0xc075ec98 fp =3D 0xc075ed08 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xc04a8d98 r7 =3D 0xe7ffffff r8 =3D 0xc06648a0 r9 =3D 0xc028d6e0 r10 =3D 0xc075ed10 undefinedinstruction() at undefinedinstruction+0x298 pc =3D 0xc04a90e0 lr =3D 0xc04972dc (exception_exit) sp =3D 0xc075ed10 fp =3D 0xc075ed68 r4 =3D 0xc04ef814 r5 =3D 0xc075edbc r6 =3D 0xc04ed1f1 r7 =3D 0xc064c7d0 r8 =3D 0xc06648a0 r9 =3D 0xc066537c r10 =3D 0xc064c630 exception_exit() at exception_exit pc =3D 0xc04972dc lr =3D 0xc028d6d4 (kdb_enter+0x40) sp =3D 0xc075ed60 fp =3D 0xc075ed68 r0 =3D 0xc065a2a4 r1 =3D 0x00000000 r2 =3D 0xc04f328a r3 =3D 0x000000ab r4 =3D 0xc04ef814 r5 =3D 0xc075edbc r6 =3D 0xc04ed1f1 r7 =3D 0xc064c7d0 r8 =3D 0xc06648a0 r9 =3D 0xc066537c r10 =3D 0xc064c630 r12 =3D 0x00000000 $a() at $a pc =3D 0xc028d6e4 lr =3D 0xc0256eb8 (vpanic+0xb4) sp =3D 0xc075ed70 fp =3D 0xc075ed90 r4 =3D 0x00000100 vpanic() at vpanic+0xb4 pc =3D 0xc0256eb8 lr =3D 0xc0256df4 ($d) sp =3D 0xc075ed98 fp =3D 0xc075edb0 r4 =3D 0xc064c6d0 r5 =3D 0xc04ed1f1 r6 =3D 0xc075edbc r7 =3D 0xc064c630 r8 =3D 0x00000000 r9 =3D 0x000007f3 r10 =3D 0x000007f7 $d() at $d pc =3D 0xc0256df4 lr =3D 0xc0243240 (__mtx_lock_flags+0x134) sp =3D 0xc075edc8 fp =3D 0xc075edf0 r4 =3D 0xc04df462 r5 =3D 0xc05a0f00 r6 =3D 0x000007f3 r7 =3D 0xc05a0f00 __mtx_lock_flags() at __mtx_lock_flags+0x134 pc =3D 0xc0243240 lr =3D 0xc0192008 (vt_resize+0x44) sp =3D 0xc075edf8 fp =3D 0xc075ee18 r4 =3D 0xc05a0e90 r5 =3D 0xc05a0f00 r6 =3D 0xc04df462 r7 =3D 0xc05a0f50 r8 =3D 0x00000000 vt_resize() at vt_resize+0x44 pc =3D 0xc0192008 lr =3D 0xc0191f7c (vt_upgrade+0x38c) sp =3D 0xc075ee20 fp =3D 0xc075ee88 r4 =3D 0x00000001 r5 =3D 0xc0664898 r6 =3D 0xc05a0e90 r7 =3D 0xc0523148 r8 =3D 0xc06650a4 r9 =3D 0xc06650a0 r10 =3D 0x00001bd6 vt_upgrade() at vt_upgrade+0x38c pc =3D 0xc0191f7c lr =3D 0xc0205e14 (mi_startup+0x11c) sp =3D 0xc075ee90 fp =3D 0xc075eea8 r4 =3D 0x00000001 r5 =3D 0xc0664898 r6 =3D 0x00000000 r7 =3D 0xc0523148 r8 =3D 0xc06650a4 r9 =3D 0xc06650a0 r10 =3D 0x00001bd6 mi_startup() at mi_startup+0x11c pc =3D 0xc0205e14 lr =3D 0xc0100238 (virt_done+0x44) sp =3D 0xc075eeb0 fp =3D 0x00000000 r4 =3D 0xc0100268 r5 =3D 0xc066c000 r6 =3D 0x02048740 r7 =3D 0x0010014c r8 =3D 0x00000000 r9 =3D 0xc074d000 virt_done() at virt_done+0x44 pc =3D 0xc0100238 lr =3D 0xc0100238 (virt_done+0x44) sp =3D 0xc075eeb0 fp =3D 0x00000000 Unable to unwind further db> On 12 May 2014, at 21:29, Aleksandr Rybalko wrote: > Author: ray > Date: Mon May 12 19:29:38 2014 > New Revision: 265927 > URL: http://svnweb.freebsd.org/changeset/base/265927 >=20 > Log: > Update terminal sizes in any case when new vt(4) driver arrive. > (Plus remove one unused newline) >=20 > Sponsored by: The FreeBSD Foundation >=20 > Modified: > head/sys/dev/vt/vt_core.c >=20 > Modified: head/sys/dev/vt/vt_core.c > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/sys/dev/vt/vt_core.c Mon May 12 19:11:39 2014 = (r265926) > +++ head/sys/dev/vt/vt_core.c Mon May 12 19:29:38 2014 = (r265927) > @@ -1981,8 +1981,11 @@ vt_upgrade(struct vt_device *vd) > unsigned int i; >=20 > /* Device didn't pass vd_init() or already upgraded. */ > - if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) > + if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) { > + /* Refill settings with new sizes anyway. */ > + vt_resize(vd); > return; > + } > vd->vd_flags |=3D VDF_ASYNC; >=20 > for (i =3D 0; i < VT_MAXWINDOWS; i++) { > @@ -2019,7 +2022,6 @@ vt_upgrade(struct vt_device *vd) >=20 > /* Refill settings with new sizes. */ > vt_resize(vd); > - > } >=20 > static void >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Tue May 13 16:42:12 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC9C1AFB; Tue, 13 May 2014 16:42:12 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A743B28BC; Tue, 13 May 2014 16:42:12 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::716b:f090:3b08:95fd] (unknown [IPv6:2001:7b8:3a7:0:716b:f090:3b08:95fd]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A2CCB5C43; Tue, 13 May 2014 18:42:06 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_9F078423-C97B-4C7C-A576-525D1DC62F8E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: 11-CURRENT: clang/error: no member named 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM' From: Dimitry Andric In-Reply-To: <30ED030F-69E3-4E27-B492-3CBE30356DDE@bsdimp.com> Date: Tue, 13 May 2014 18:41:51 +0200 Message-Id: <206C2734-DF3B-438F-8706-A6059C94AEAB@FreeBSD.org> References: <1399946503.50937.9.camel@revolution.hippie.lan> <6F8FBC17-D8BF-4B78-A6E1-6FFEFCC14838@FreeBSD.org> <30ED030F-69E3-4E27-B492-3CBE30356DDE@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1874) Cc: FreeBSD ARM , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:42:13 -0000 --Apple-Mail=_9F078423-C97B-4C7C-A576-525D1DC62F8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 13 May 2014, at 15:58, Warner Losh wrote: >=20 > On May 12, 2014, at 11:38 PM, Dimitry Andric wrote: ... >> I don't think so, I built universe succesfully. I suspect that some = of >> the tblgen-generated headers are out of date, and must be = regenerated. >> Unfortunately, the dependency checking for these generated files does >> not always pick up changes. ... > Any plans on fixing that problem with the build? Having stuff randomly = fail really isn=92t the FreeBSD way.[*] Yes, this has annoyed me since the beginning, so I'm working on a fix. Between llvm/clang 3.3 and 3.4, the tblgen programs grew an option to output dependency information, so I need to hook that into the Makefiles or .depend files, somehow. -Dimitry --Apple-Mail=_9F078423-C97B-4C7C-A576-525D1DC62F8E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlNyS10ACgkQsF6jCi4glqPqSwCgjtk04dc+AyY6S8oAuOdSfmuu dOEAnA5Xuw71Tm29/gOtZ/baVuXeiIPD =1Nta -----END PGP SIGNATURE----- --Apple-Mail=_9F078423-C97B-4C7C-A576-525D1DC62F8E-- From owner-freebsd-arm@FreeBSD.ORG Tue May 13 17:11:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AA83D6D; Tue, 13 May 2014 17:11:39 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0181E2B99; Tue, 13 May 2014 17:11:38 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id bs8so6637251wib.6 for ; Tue, 13 May 2014 10:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zJcBr2n9GfjASKEkBgXJWNo1mzPAWkaZTQxUe9ybJhI=; b=VANNN5rTN4t9j1En5twukgeJGVj+KrWANzydtX9zvcFQrH+raeLHj+2qHyx92ZbfQS vKK4rk6N7Ti/qPhO3tCUAwLotujtcC11bD3u+yQTSzKiKflZtAKUJFPUJseQm+Zux7mw ASKz0d9RZxV81al9tdz2sPeZi7mR417E7/ygZJFdymtqIGv3ghjy9TAvN2Y7wWMU2imw CEoNmKJF3+czYjMI5uu0cnT8OlaVqVkTywZm2INhWnAzax/L4i3I1ixpWDlkNncGS7xc t5zRIKeHallLLSCgoeHnX3ZrvVhQ1eibKIn7GNi2S0DK08zrPcFmsgth2QuNshmnDOaG 0vjg== MIME-Version: 1.0 X-Received: by 10.194.58.161 with SMTP id s1mr9796113wjq.43.1400001097282; Tue, 13 May 2014 10:11:37 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Tue, 13 May 2014 10:11:37 -0700 (PDT) In-Reply-To: <1399991632.56626.7.camel@revolution.hippie.lan> References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> <1399991632.56626.7.camel@revolution.hippie.lan> Date: Tue, 13 May 2014 13:11:37 -0400 Message-ID: Subject: Re: Patch to make BBB properly boot from eMMC every time From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:11:39 -0000 On Tue, May 13, 2014 at 10:33 AM, Ian Lepore wrote: > Does your emmc come up as 8-bit reliably every time? No, not since I've rebuilt (using 11-CURRENT r265949). I'm using Tim's updated crochet-freebsd which now includes the 1Ghz patches. This time around, instead of the 15 second hang I previously reported, it hung for maybe 60s before generating this message: mmcsd0: 4GB at mmc0 48.0MHz/4bit/65535-block uhub1: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered random: unblocking device. ###### HANGS HERE ... ###### sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active command. sdhci_ti1-slot0: ============== REGISTER DUMP ============== sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti1-slot0: =========================================== sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active command. sdhci_ti1-slot0: ============== REGISTER DUMP ============== sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti1-slot0: =========================================== sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active command. sdhci_ti1-slot0: ============== REGISTER DUMP ============== sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti1-slot0: =========================================== sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active command. sdhci_ti1-slot0: ============== REGISTER DUMP ============== sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 sdhci_ti1-slot0: =========================================== am335x_pmic0: TPS65217C ver 1.2 powered by AC Trying to mount root from ufs:/dev/ufs/sdfreebsd1 [rw,noatime]... It did not appear to detect the eMMC. From owner-freebsd-arm@FreeBSD.ORG Tue May 13 19:55:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E6CA612; Tue, 13 May 2014 19:55:16 +0000 (UTC) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8CF3294D; Tue, 13 May 2014 19:55:15 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id e51so746524eek.38 for ; Tue, 13 May 2014 12:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=D3hkr24+rK9J5YeJ35bsYl0snQA0JH8Ull0cBHJ1lUs=; b=o3H8tuk+dSMlxNgLdJbg4iXamfqlwrDJHKCWV7Gy54s3nKixCYpN7Pxz+1ccqdo4QR DXCMao2qlLQUM7oCCFC20A4IRtd3R8g8vhAhautEtloXJPJZAg8S9KMSb7L2FVLeg4yb LmcZmKx9tHiY8K9Idrla+oVQNJ33oeqDBHvXGxZFH/H1hJs5TLFhwsdUYMJf4jAQQ8+8 WclRfae7sI9XWUlVB7jRfkXwm3iCr2OxufF9LKGmwjlul7oQkRyaQz7/gJzrEsERECzu XxKul/YNGlfL7Q8iOulLPkoOrfV6heLJYuIjCLpvxZacHw0JIboUZvVIXzE30EaF3SLK dVfA== X-Received: by 10.14.108.198 with SMTP id q46mr43484946eeg.31.1400010914161; Tue, 13 May 2014 12:55:14 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id o5sm42399092eeg.8.2014.05.13.12.55.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 12:55:12 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5372789E.8020103@hot.ee> Date: Tue, 13 May 2014 22:55:10 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Winston Smith Subject: Re: Patch to make BBB properly boot from eMMC every time References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> <1399991632.56626.7.camel@revolution.hippie.lan> In-Reply-To: X-TagToolbar-Keys: D20140513225510262 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 19:55:16 -0000 On 2014-05-13 20:11, Winston Smith wrote: > On Tue, May 13, 2014 at 10:33 AM, Ian Lepore wrote: >> Does your emmc come up as 8-bit reliably every time? > > No, not since I've rebuilt (using 11-CURRENT r265949). I'm using > Tim's updated crochet-freebsd which now includes the 1Ghz patches. > This time around, instead of the 15 second hang I previously reported, > it hung for maybe 60s before generating this message: > > mmcsd0: 4GB at mmc0 > 48.0MHz/4bit/65535-block > uhub1: 1 port with 1 removable, self powered > uhub0: 1 port with 1 removable, self powered > random: unblocking device. ###### HANGS HERE ... ###### > sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active command. > sdhci_ti1-slot0: ============== REGISTER DUMP ============== > sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 > sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 > sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b > sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 > sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 > sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 > sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 > sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 > sdhci_ti1-slot0: =========================================== > sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active command. > sdhci_ti1-slot0: ============== REGISTER DUMP ============== > sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 > sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 > sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b > sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 > sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 > sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 > sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 > sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 > sdhci_ti1-slot0: =========================================== > sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active command. > sdhci_ti1-slot0: ============== REGISTER DUMP ============== > sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 > sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 > sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b > sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 > sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 > sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 > sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 > sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 > sdhci_ti1-slot0: =========================================== > sdhci_ti1-slot0: Got data interrupt 0x00000002, but there is no active command. > sdhci_ti1-slot0: ============== REGISTER DUMP ============== > sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101 > sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001 > sdhci_ti1-slot0: Argument: 0x00020000 | Trn mode: 0x0000071b > sdhci_ti1-slot0: Present: 0x01f70000 | Host ctl: 0x00000000 > sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000 > sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007 > sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000000 > sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > sdhci_ti1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_ti1-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 > sdhci_ti1-slot0: =========================================== > am335x_pmic0: TPS65217C ver 1.2 powered by AC > Trying to mount root from ufs:/dev/ufs/sdfreebsd1 [rw,noatime]... > > > It did not appear to detect the eMMC. > _______________________________________________ > 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" > That's bit different issue. I would actually want to have 1GHz WITH eMMC... now it's impossible. First that, then maybe variable freq later (if possible). I certainly have usage for such speeds somewhere. But right now BBB is so stable. I would put snapshot of CURRENT to production right now. I now also have taken all debugging options out. I didn't realize how SLOW things are with WITNESS & others on. Maybe when I get more than one copy of same HW, I could run some of them with WITNESS on too (would it actually give me some useful data I could report back?) From owner-freebsd-arm@FreeBSD.ORG Tue May 13 20:33:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AF6FF1C; Tue, 13 May 2014 20:33:16 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C37D52C60; Tue, 13 May 2014 20:33:15 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hm4so1294307wib.5 for ; Tue, 13 May 2014 13:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UxVrKKmoQKcSPaGhc9Pun0AVEyNX+GnumQt/Zp0wbf4=; b=X0rjDXwLi7w4ebEpoVQvoha7+unX/a3BwyH2gVKSDJg1dDOoUW6KG1yuD6odhAaCbu F8sqPNJLo9Wk7SMvPf53vf3pu6yelLgh2xF6hnyymb2aL7MFODcWctsa70TB6q9MkBIV NKfOH9bGw7yAQuf/+34Z5I37Fx14mtDK9CeKWVR1a2oECUizfLOGbsM2wgJaFYUikPGN N6bzZH97I5kD1KVyJFRmoPRf7u4oDWVXsY7MWnlpr+7wj0vgzNfVxteRR++4bSt0CrUN KPT4la9OWMh/Vr+3j/AAKkAKPYk8LCvQH2Iq89Acwjdn7gL2IcbMbkfdcz0HoxO/9tUN XGeA== MIME-Version: 1.0 X-Received: by 10.194.90.107 with SMTP id bv11mr28576521wjb.11.1400013192904; Tue, 13 May 2014 13:33:12 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Tue, 13 May 2014 13:33:12 -0700 (PDT) In-Reply-To: <5372789E.8020103@hot.ee> References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> <1399991632.56626.7.camel@revolution.hippie.lan> <5372789E.8020103@hot.ee> Date: Tue, 13 May 2014 16:33:12 -0400 Message-ID: Subject: Re: Patch to make BBB properly boot from eMMC every time From: Winston Smith To: "Sulev-Madis Silber (ketas)" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 20:33:16 -0000 On Tue, May 13, 2014 at 3:55 PM, Sulev-Madis Silber (ketas) wrote: > That's bit different issue. I can't help but think the hang here is related, particularly to the subtle timing issues that are plaguing the 4 vs 8 bit detection. Seems like there's just something not right in the eMMC detection/startup? Maybe the [faster] 1GHZ CPU is further throwing off the timing. > I would actually want to have 1GHz WITH eMMC... now it's impossible. > First that, then maybe variable freq later (if possible). I certainly > have usage for such speeds somewhere. Why is it impossible? It seems to work, just not reliably! Seems silly to have the 1GHZ BBB running at only 550Mhz. > But right now BBB is so stable. I would put snapshot of CURRENT to > production right now. I now also have taken all debugging options out. I > didn't realize how SLOW things are with WITNESS & others on. > Maybe when I get more than one copy of same HW, I could run some of them > with WITNESS on too (would it actually give me some useful data I could > report back?) I'm in the same boat. However, Ian is in the process of backporting the CURRENT arm updates to STABLE. If I can get 1GHZ working with 10-STABLE, then I'll be very happy. WITNESS is an easy one, create a config like this: ident MYCONF include BEAGLEBONE nooptions WITNESS And build with it (set KERNCONF if you're using crotchet-freebsd) and you'll get a WITNESS-free kernel. From owner-freebsd-arm@FreeBSD.ORG Tue May 13 22:53:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 242A0DDA; Tue, 13 May 2014 22:53:44 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5D31279D; Tue, 13 May 2014 22:53:43 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id 63so1539728qgz.30 for ; Tue, 13 May 2014 15:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8wf+kMATuNpt+dllc2zh2mSzU35gEb9mjJ3V0OIaDMw=; b=bMG3oohFb4EyLk4KcSRJk+tFqVxxT6KcsBHTDqJailXGwZzK1jIdrJSHuxKxxWyn8Z MZZqizr5I1Esh+qLEoonlmgR+caFqCsIMkiAEJKKyVg3Hrj+sG8FqQWb0jGuH7zfNcY4 OivJWTHLc3HwiwZZ4uCxZcdTl2+4muTTouYWzC2azTmYv9H4fTIEJ5wMZU4GFpdD23O3 gtrevzH/+jw8sfv7lCeijeFJxqc3fOPYLLLOXk4COGfkDz4SUQU2zeUVoxQ0uSIKY5eb 98+8ZQIkeN3x5d51T/uWnfujzItYrK4GfYd9ALpJT+MSRrBcBiDp79mmcW8GxX6nEbzT n2Mg== MIME-Version: 1.0 X-Received: by 10.140.49.208 with SMTP id q74mr41774311qga.103.1400021617759; Tue, 13 May 2014 15:53:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Tue, 13 May 2014 15:53:37 -0700 (PDT) In-Reply-To: References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> <1399991632.56626.7.camel@revolution.hippie.lan> <5372789E.8020103@hot.ee> Date: Tue, 13 May 2014 15:53:37 -0700 X-Google-Sender-Auth: aQK2oFsDWKmxTtcB6XhvfE21iBs Message-ID: Subject: Re: Patch to make BBB properly boot from eMMC every time From: Adrian Chadd To: Winston Smith Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 22:53:44 -0000 Hi, Please don't be afraid to keep running -HEAD on the BBB. A lot of this stuff still needs to shake out there. :-) -a On 13 May 2014 13:33, Winston Smith wrote: > On Tue, May 13, 2014 at 3:55 PM, Sulev-Madis Silber (ketas) > wrote: >> That's bit different issue. > > I can't help but think the hang here is related, particularly to the > subtle timing issues that are plaguing the 4 vs 8 bit detection. > Seems like there's just something not right in the eMMC > detection/startup? Maybe the [faster] 1GHZ CPU is further throwing > off the timing. > >> I would actually want to have 1GHz WITH eMMC... now it's impossible. >> First that, then maybe variable freq later (if possible). I certainly >> have usage for such speeds somewhere. > > Why is it impossible? It seems to work, just not reliably! > > Seems silly to have the 1GHZ BBB running at only 550Mhz. > >> But right now BBB is so stable. I would put snapshot of CURRENT to >> production right now. I now also have taken all debugging options out. I >> didn't realize how SLOW things are with WITNESS & others on. >> Maybe when I get more than one copy of same HW, I could run some of them >> with WITNESS on too (would it actually give me some useful data I could >> report back?) > > I'm in the same boat. However, Ian is in the process of backporting > the CURRENT arm updates to STABLE. If I can get 1GHZ working with > 10-STABLE, then I'll be very happy. > > WITNESS is an easy one, create a config like this: > > ident MYCONF > > include BEAGLEBONE > nooptions WITNESS > > > And build with it (set KERNCONF if you're using crotchet-freebsd) and > you'll get a WITNESS-free kernel. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Wed May 14 05:52:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 418027C4; Wed, 14 May 2014 05:52:20 +0000 (UTC) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A25D92BBB; Wed, 14 May 2014 05:52:19 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id e53so942767eek.39 for ; Tue, 13 May 2014 22:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Qk0KwQ0QfatPELfr5IQHQWTEQAXR9+ezdI0bvQa8eqE=; b=yccTLPDJUhTgVtgwLp0KFnASQ6j856ZwxY9M/OZVQkEbHOQwvNbn67hcVrE9L8PktW 9ZwOk2XVs2yFPsGHoKplYBKE3ZnSrweKwVRVX63jGXVCML7ICsuKb4yWtKqyeG/YNNyT RZRMHXWQ4zlxPWrSqw7kdXUuje4J9A9MWqucDIhdLd33c38EKlCUMKCQNaM901cbnc7/ f528TorQIXUDQCcswMwpT9/MAUbx9L9D1U9kypiYYZHYAjIbvqlstCbGFc63MSbb3ZyJ sgZPut62acEKMqye5n6J5ggtRPVMs3yixf4s7VBtdqnb9fX6aB3NvDJoFJzkz0B6QgXH 3AUA== X-Received: by 10.14.89.70 with SMTP id b46mr604399eef.109.1400046736598; Tue, 13 May 2014 22:52:16 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id 4sm2459792eeq.33.2014.05.13.22.52.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 22:52:15 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5373048C.7030009@hot.ee> Date: Wed, 14 May 2014 08:52:12 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Winston Smith Subject: Re: Patch to make BBB properly boot from eMMC every time References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> <1399991632.56626.7.camel@revolution.hippie.lan> <5372789E.8020103@hot.ee> In-Reply-To: X-TagToolbar-Keys: D20140514085212114 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 05:52:20 -0000 On 2014-05-13 23:33, Winston Smith wrote: > On Tue, May 13, 2014 at 3:55 PM, Sulev-Madis Silber (ketas) > wrote: >> That's bit different issue. > > I can't help but think the hang here is related, particularly to the > subtle timing issues that are plaguing the 4 vs 8 bit detection. > Seems like there's just something not right in the eMMC > detection/startup? Maybe the [faster] 1GHZ CPU is further throwing > off the timing. > >> I would actually want to have 1GHz WITH eMMC... now it's impossible. >> First that, then maybe variable freq later (if possible). I certainly >> have usage for such speeds somewhere. > > Why is it impossible? It seems to work, just not reliably! > So you have uboot that could run BBB 1GHz while booting from eMMC? Indeed, 2014.04 has appeared in crochet... while it should appear in ports as *-devel, meh. I haven't tried that yet. > Seems silly to have the 1GHZ BBB running at only 550Mhz. > >> But right now BBB is so stable. I would put snapshot of CURRENT to >> production right now. I now also have taken all debugging options out. I >> didn't realize how SLOW things are with WITNESS & others on. >> Maybe when I get more than one copy of same HW, I could run some of them >> with WITNESS on too (would it actually give me some useful data I could >> report back?) > > I'm in the same boat. However, Ian is in the process of backporting > the CURRENT arm updates to STABLE. If I can get 1GHZ working with > 10-STABLE, then I'll be very happy. > > WITNESS is an easy one, create a config like this: > > ident MYCONF > > include BEAGLEBONE > nooptions WITNESS > > > And build with it (set KERNCONF if you're using crotchet-freebsd) and > you'll get a WITNESS-free kernel. > No, I'm not using crochet... http://ketas.si.pri.ee/bbb/ There are most of things I use to customize tree for BBB. From owner-freebsd-arm@FreeBSD.ORG Wed May 14 11:22:41 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A049771F; Wed, 14 May 2014 11:22:41 +0000 (UTC) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 02B1825BA; Wed, 14 May 2014 11:22:40 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id B2B70C492D; Wed, 14 May 2014 14:22:33 +0300 (EEST) Date: Wed, 14 May 2014 14:22:52 +0300 From: Aleksandr Rybalko To: Michael Tuexen Subject: Re: svn commit: r265927 - head/sys/dev/vt Message-Id: <20140514142252.8fe1742f90a28e534532b1d5@freebsd.org> In-Reply-To: <2899E6ED-712E-46BC-960B-9847FD99431C@freebsd.org> References: <201405121929.s4CJTcBx010967@svn.freebsd.org> <2899E6ED-712E-46BC-960B-9847FD99431C@freebsd.org> X-Mailer: Sylpheed 3.3.1 (GTK+ 2.24.22; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , src-committers@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 11:22:41 -0000 On Tue, 13 May 2014 18:20:32 +0200 Michael Tuexen wrote: > Hi Aleksandr, Hi Michael, > > could it be that this commit results in the following panic when booting > a Raspberry Pi: > > fb0: 656x416(0x0@0,0) 16bpp > fb0: pitch 1312, base 0x5e006000, screen_size 545792 > fbd0 on fb0 > VT: initialize with new VT driver "fb". > panic: mtx_lock() of spin mutex (null) @ /usr/home/tuexen/head/sys/dev/vt/vt_core.c:2035 > KDB: enter: panic Hmm, looks like here is some memory corruption. It is possible happen due some issue of vt(4), but panic and bt show problem with lock which was used right before that place: vt_upgrade() call VT_LOCK(vd), VT_UNLOCK(vd), then vt_resize(vd) vt_resize(vd) try to VT_LOCK(vd) and fail. Can you please try to do clean rebuild (in case you use incremental build)? > [ thread pid 0 tid 100000 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> where > Tracing pid 0 tid 100000 td 0xc06648a0 > db_trace_self() at db_trace_self > pc = 0xc0495760 lr = 0xc0130fdc (db_stack_trace+0xf4) > sp = 0xc075ea68 fp = 0xc075ea80 > r10 = 0xc0663930 > db_stack_trace() at db_stack_trace+0xf4 > pc = 0xc0130fdc lr = 0xc013094c (db_command+0x270) > sp = 0xc075ea88 fp = 0xc075eb28 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000072 > db_command() at db_command+0x270 > pc = 0xc013094c lr = 0xc01306b0 (db_command_loop+0x60) > sp = 0xc075eb30 fp = 0xc075eb40 > r4 = 0xc04d5176 r5 = 0xc04ef7ba > r6 = 0xc066391c r7 = 0xc0590b40 > r8 = 0xc065a294 r9 = 0xc065a290 > r10 = 0xc075ed10 > db_command_loop() at db_command_loop+0x60 > pc = 0xc01306b0 lr = 0xc0133078 (db_trap+0xd8) > sp = 0xc075eb48 fp = 0xc075ec68 > r4 = 0x00000000 r5 = 0xc0663928 > r6 = 0xc065a2c0 > db_trap() at db_trap+0xd8 > pc = 0xc0133078 lr = 0xc028de10 (kdb_trap+0xbc) > sp = 0xc075ec70 fp = 0xc075ec90 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc065a2c0 r7 = 0xc0590b40 > kdb_trap() at kdb_trap+0xbc > pc = 0xc028de10 lr = 0xc04a90e0 (undefinedinstruction+0x298) > sp = 0xc075ec98 fp = 0xc075ed08 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc04a8d98 r7 = 0xe7ffffff > r8 = 0xc06648a0 r9 = 0xc028d6e0 > r10 = 0xc075ed10 > undefinedinstruction() at undefinedinstruction+0x298 > pc = 0xc04a90e0 lr = 0xc04972dc (exception_exit) > sp = 0xc075ed10 fp = 0xc075ed68 > r4 = 0xc04ef814 r5 = 0xc075edbc > r6 = 0xc04ed1f1 r7 = 0xc064c7d0 > r8 = 0xc06648a0 r9 = 0xc066537c > r10 = 0xc064c630 > exception_exit() at exception_exit > pc = 0xc04972dc lr = 0xc028d6d4 (kdb_enter+0x40) > sp = 0xc075ed60 fp = 0xc075ed68 > r0 = 0xc065a2a4 r1 = 0x00000000 > r2 = 0xc04f328a r3 = 0x000000ab > r4 = 0xc04ef814 r5 = 0xc075edbc > r6 = 0xc04ed1f1 r7 = 0xc064c7d0 > r8 = 0xc06648a0 r9 = 0xc066537c > r10 = 0xc064c630 r12 = 0x00000000 > $a() at $a > pc = 0xc028d6e4 lr = 0xc0256eb8 (vpanic+0xb4) > sp = 0xc075ed70 fp = 0xc075ed90 > r4 = 0x00000100 > vpanic() at vpanic+0xb4 > pc = 0xc0256eb8 lr = 0xc0256df4 ($d) > sp = 0xc075ed98 fp = 0xc075edb0 > r4 = 0xc064c6d0 r5 = 0xc04ed1f1 > r6 = 0xc075edbc r7 = 0xc064c630 > r8 = 0x00000000 r9 = 0x000007f3 > r10 = 0x000007f7 > $d() at $d > pc = 0xc0256df4 lr = 0xc0243240 (__mtx_lock_flags+0x134) > sp = 0xc075edc8 fp = 0xc075edf0 > r4 = 0xc04df462 r5 = 0xc05a0f00 > r6 = 0x000007f3 r7 = 0xc05a0f00 > __mtx_lock_flags() at __mtx_lock_flags+0x134 > pc = 0xc0243240 lr = 0xc0192008 (vt_resize+0x44) > sp = 0xc075edf8 fp = 0xc075ee18 > r4 = 0xc05a0e90 r5 = 0xc05a0f00 > r6 = 0xc04df462 r7 = 0xc05a0f50 > r8 = 0x00000000 > vt_resize() at vt_resize+0x44 > pc = 0xc0192008 lr = 0xc0191f7c (vt_upgrade+0x38c) > sp = 0xc075ee20 fp = 0xc075ee88 > r4 = 0x00000001 r5 = 0xc0664898 > r6 = 0xc05a0e90 r7 = 0xc0523148 > r8 = 0xc06650a4 r9 = 0xc06650a0 > r10 = 0x00001bd6 > vt_upgrade() at vt_upgrade+0x38c > pc = 0xc0191f7c lr = 0xc0205e14 (mi_startup+0x11c) > sp = 0xc075ee90 fp = 0xc075eea8 > r4 = 0x00000001 r5 = 0xc0664898 > r6 = 0x00000000 r7 = 0xc0523148 > r8 = 0xc06650a4 r9 = 0xc06650a0 > r10 = 0x00001bd6 > mi_startup() at mi_startup+0x11c > pc = 0xc0205e14 lr = 0xc0100238 (virt_done+0x44) > sp = 0xc075eeb0 fp = 0x00000000 > r4 = 0xc0100268 r5 = 0xc066c000 > r6 = 0x02048740 r7 = 0x0010014c > r8 = 0x00000000 r9 = 0xc074d000 > virt_done() at virt_done+0x44 > pc = 0xc0100238 lr = 0xc0100238 (virt_done+0x44) > sp = 0xc075eeb0 fp = 0x00000000 > Unable to unwind further > db> > On 12 May 2014, at 21:29, Aleksandr Rybalko wrote: > > > Author: ray > > Date: Mon May 12 19:29:38 2014 > > New Revision: 265927 > > URL: http://svnweb.freebsd.org/changeset/base/265927 > > > > Log: > > Update terminal sizes in any case when new vt(4) driver arrive. > > (Plus remove one unused newline) > > > > Sponsored by: The FreeBSD Foundation > > > > Modified: > > head/sys/dev/vt/vt_core.c > > > > Modified: head/sys/dev/vt/vt_core.c > > ============================================================================== > > --- head/sys/dev/vt/vt_core.c Mon May 12 19:11:39 2014 (r265926) > > +++ head/sys/dev/vt/vt_core.c Mon May 12 19:29:38 2014 (r265927) > > @@ -1981,8 +1981,11 @@ vt_upgrade(struct vt_device *vd) > > unsigned int i; > > > > /* Device didn't pass vd_init() or already upgraded. */ > > - if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) > > + if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) { > > + /* Refill settings with new sizes anyway. */ > > + vt_resize(vd); > > return; > > + } > > vd->vd_flags |= VDF_ASYNC; > > > > for (i = 0; i < VT_MAXWINDOWS; i++) { > > @@ -2019,7 +2022,6 @@ vt_upgrade(struct vt_device *vd) > > > > /* Refill settings with new sizes. */ > > vt_resize(vd); > > - > > } > > > > static void > > > > > Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Wed May 14 11:42:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA3C7CE; Wed, 14 May 2014 11:42:40 +0000 (UTC) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 526AE2739; Wed, 14 May 2014 11:42:40 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id e53so1248527eek.25 for ; Wed, 14 May 2014 04:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vKG6xgJrGV9JHp8f9VeuONgTEvFEu26Gl/utV4rt+78=; b=bfi20ahoR92vDqclAlQiydr6OHbXOtAwV2n1eRHXdus69AkyjVfKd2qHGHuarwQIIW cUjEXtoo8A54B/Kv2XJi6CxaAWh6LM7aWRU8lGslgFWOirdYnDNiTcIDIN6d856PO5w3 NIFLH7TSCJh1rEGwRoghw7I3q1WGrYb56ljCSrbqMNAurXkrEdVEZBaS5/GGnP366WEr EGKc3REeuQTPtC8UYNnn2Ewx5RtF2/A1I5Vb4JvE+NyvdCJ6/J4sg6T6aXFh9mn9LsCH 6I3rD8cQ1txE7sp3lcLTmOWcCZYu1ra6OZzySV2iLJrCxquW3Z0xRrFVruBV6Tm7t8O5 9BAw== X-Received: by 10.15.33.140 with SMTP id c12mr5139538eev.41.1400067758536; Wed, 14 May 2014 04:42:38 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id x45sm4522779eef.15.2014.05.14.04.42.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 04:42:37 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537356AA.9090704@hot.ee> Date: Wed, 14 May 2014 14:42:34 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Sulev-Madis Silber (ketas)" Subject: Re: Patch to make BBB properly boot from eMMC every time References: <5371E1F3.6080002@hot.ee> <1399987808.56626.2.camel@revolution.hippie.lan> <1399991632.56626.7.camel@revolution.hippie.lan> <5372789E.8020103@hot.ee> <5373048C.7030009@hot.ee> In-Reply-To: <5373048C.7030009@hot.ee> X-TagToolbar-Keys: D20140514144234654 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 11:42:41 -0000 On 2014-05-14 08:52, Sulev-Madis Silber (ketas) wrote: > On 2014-05-13 23:33, Winston Smith wrote: >> On Tue, May 13, 2014 at 3:55 PM, Sulev-Madis Silber (ketas) >> wrote: >>> That's bit different issue. >> >> I can't help but think the hang here is related, particularly to the >> subtle timing issues that are plaguing the 4 vs 8 bit detection. >> Seems like there's just something not right in the eMMC >> detection/startup? Maybe the [faster] 1GHZ CPU is further throwing >> off the timing. >> >>> I would actually want to have 1GHz WITH eMMC... now it's impossible. >>> First that, then maybe variable freq later (if possible). I certainly >>> have usage for such speeds somewhere. >> >> Why is it impossible? It seems to work, just not reliably! >> > > So you have uboot that could run BBB 1GHz while booting from eMMC? > Indeed, 2014.04 has appeared in crochet... while it should appear in > ports as *-devel, meh. I haven't tried that yet. > > >> Seems silly to have the 1GHZ BBB running at only 550Mhz. >> >>> But right now BBB is so stable. I would put snapshot of CURRENT to >>> production right now. I now also have taken all debugging options out. I >>> didn't realize how SLOW things are with WITNESS & others on. >>> Maybe when I get more than one copy of same HW, I could run some of them >>> with WITNESS on too (would it actually give me some useful data I could >>> report back?) >> >> I'm in the same boat. However, Ian is in the process of backporting >> the CURRENT arm updates to STABLE. If I can get 1GHZ working with >> 10-STABLE, then I'll be very happy. >> >> WITNESS is an easy one, create a config like this: >> >> ident MYCONF >> >> include BEAGLEBONE >> nooptions WITNESS >> >> >> And build with it (set KERNCONF if you're using crotchet-freebsd) and >> you'll get a WITNESS-free kernel. >> > > No, I'm not using crochet... > > http://ketas.si.pri.ee/bbb/ > > There are most of things I use to customize tree for BBB. > I got it booting from "eMMC". I had to find microsd for that. Only one that was unused was 64MB which was pretty enough to hold 7M /boot & etc/fstab... even 5M /rescue! And I have another partition there which holds same data + one FAT part for future use. So, now I have this silly boot path: ----------------------------------------------------------- eMMC, FAT : small uboot 2014.04 || \/ eMMC, FAT : regular uboot 2014.04 || \/ eMMC, FAT : uboot loader || \/ SD, UFS : loader files, kernel || \/ eMMC, UFS : rootfs ----------------------------------------------------------- Surely ubldr could be fixed for that. I tried to find cause but it's likely somewhere deep. Also, uboot env is absolutely filled with content that's only required for booting Linux kernel. It was even hard to understand what was wrong there. Actually the error was same with previous 1GHz uboot (2014.01). Only I didn't notice that loader actually runs, only it fails to find eMMC. From owner-freebsd-arm@FreeBSD.ORG Wed May 14 15:39:40 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C98068EF; Wed, 14 May 2014 15:39:40 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 580662C08; Wed, 14 May 2014 15:39:40 +0000 (UTC) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6D7351C104980; Wed, 14 May 2014 17:39:35 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: svn commit: r265927 - head/sys/dev/vt From: Michael Tuexen In-Reply-To: <20140514142252.8fe1742f90a28e534532b1d5@freebsd.org> Date: Wed, 14 May 2014 17:39:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82E02840-17EC-4A9F-9856-DA55D9FA3AD6@freebsd.org> References: <201405121929.s4CJTcBx010967@svn.freebsd.org> <2899E6ED-712E-46BC-960B-9847FD99431C@freebsd.org> <20140514142252.8fe1742f90a28e534532b1d5@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" , src-committers@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:39:40 -0000 On 14 May 2014, at 13:22, Aleksandr Rybalko wrote: > On Tue, 13 May 2014 18:20:32 +0200 > Michael Tuexen wrote: >=20 >> Hi Aleksandr, >=20 > Hi Michael, >=20 >>=20 >> could it be that this commit results in the following panic when = booting >> a Raspberry Pi: >>=20 >> fb0: 656x416(0x0@0,0) 16bpp >> fb0: pitch 1312, base 0x5e006000, screen_size 545792 >> fbd0 on fb0 >> VT: initialize with new VT driver "fb". >> panic: mtx_lock() of spin mutex (null) @ = /usr/home/tuexen/head/sys/dev/vt/vt_core.c:2035 >> KDB: enter: panic >=20 >=20 > Hmm, looks like here is some memory corruption. It is possible happen > due some issue of vt(4), but panic and bt show problem with lock which > was used right before that place: > vt_upgrade() call VT_LOCK(vd), VT_UNLOCK(vd), then vt_resize(vd) > vt_resize(vd) try to VT_LOCK(vd) and fail. Well, this is true if the vt_resize() call is done in line 2024. However, this is not true if the call is done in line 1986. Let me try to figure which it is... >=20 > Can you please try to do clean rebuild (in case you use incremental > build)? It was a clean build... Best regards Michael >=20 >> [ thread pid 0 tid 100000 ] >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >> db> where=20 >> Tracing pid 0 tid 100000 td 0xc06648a0 >> db_trace_self() at db_trace_self >> pc =3D 0xc0495760 lr =3D 0xc0130fdc (db_stack_trace+0xf4) >> sp =3D 0xc075ea68 fp =3D 0xc075ea80 >> r10 =3D 0xc0663930 >> db_stack_trace() at db_stack_trace+0xf4 >> pc =3D 0xc0130fdc lr =3D 0xc013094c (db_command+0x270) >> sp =3D 0xc075ea88 fp =3D 0xc075eb28 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0x00000072 >> db_command() at db_command+0x270 >> pc =3D 0xc013094c lr =3D 0xc01306b0 (db_command_loop+0x60) >> sp =3D 0xc075eb30 fp =3D 0xc075eb40 >> r4 =3D 0xc04d5176 r5 =3D 0xc04ef7ba >> r6 =3D 0xc066391c r7 =3D 0xc0590b40 >> r8 =3D 0xc065a294 r9 =3D 0xc065a290 >> r10 =3D 0xc075ed10 >> db_command_loop() at db_command_loop+0x60 >> pc =3D 0xc01306b0 lr =3D 0xc0133078 (db_trap+0xd8) >> sp =3D 0xc075eb48 fp =3D 0xc075ec68 >> r4 =3D 0x00000000 r5 =3D 0xc0663928 >> r6 =3D 0xc065a2c0 >> db_trap() at db_trap+0xd8 >> pc =3D 0xc0133078 lr =3D 0xc028de10 (kdb_trap+0xbc) >> sp =3D 0xc075ec70 fp =3D 0xc075ec90 >> r4 =3D 0x00000000 r5 =3D 0x00000001 >> r6 =3D 0xc065a2c0 r7 =3D 0xc0590b40 >> kdb_trap() at kdb_trap+0xbc >> pc =3D 0xc028de10 lr =3D 0xc04a90e0 = (undefinedinstruction+0x298) >> sp =3D 0xc075ec98 fp =3D 0xc075ed08 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0xc04a8d98 r7 =3D 0xe7ffffff >> r8 =3D 0xc06648a0 r9 =3D 0xc028d6e0 >> r10 =3D 0xc075ed10 >> undefinedinstruction() at undefinedinstruction+0x298 >> pc =3D 0xc04a90e0 lr =3D 0xc04972dc (exception_exit) >> sp =3D 0xc075ed10 fp =3D 0xc075ed68 >> r4 =3D 0xc04ef814 r5 =3D 0xc075edbc >> r6 =3D 0xc04ed1f1 r7 =3D 0xc064c7d0 >> r8 =3D 0xc06648a0 r9 =3D 0xc066537c >> r10 =3D 0xc064c630 >> exception_exit() at exception_exit >> pc =3D 0xc04972dc lr =3D 0xc028d6d4 (kdb_enter+0x40) >> sp =3D 0xc075ed60 fp =3D 0xc075ed68 >> r0 =3D 0xc065a2a4 r1 =3D 0x00000000 >> r2 =3D 0xc04f328a r3 =3D 0x000000ab >> r4 =3D 0xc04ef814 r5 =3D 0xc075edbc >> r6 =3D 0xc04ed1f1 r7 =3D 0xc064c7d0 >> r8 =3D 0xc06648a0 r9 =3D 0xc066537c >> r10 =3D 0xc064c630 r12 =3D 0x00000000 >> $a() at $a >> pc =3D 0xc028d6e4 lr =3D 0xc0256eb8 (vpanic+0xb4) >> sp =3D 0xc075ed70 fp =3D 0xc075ed90 >> r4 =3D 0x00000100 >> vpanic() at vpanic+0xb4 >> pc =3D 0xc0256eb8 lr =3D 0xc0256df4 ($d) >> sp =3D 0xc075ed98 fp =3D 0xc075edb0 >> r4 =3D 0xc064c6d0 r5 =3D 0xc04ed1f1 >> r6 =3D 0xc075edbc r7 =3D 0xc064c630 >> r8 =3D 0x00000000 r9 =3D 0x000007f3 >> r10 =3D 0x000007f7 >> $d() at $d >> pc =3D 0xc0256df4 lr =3D 0xc0243240 (__mtx_lock_flags+0x134) >> sp =3D 0xc075edc8 fp =3D 0xc075edf0 >> r4 =3D 0xc04df462 r5 =3D 0xc05a0f00 >> r6 =3D 0x000007f3 r7 =3D 0xc05a0f00 >> __mtx_lock_flags() at __mtx_lock_flags+0x134 >> pc =3D 0xc0243240 lr =3D 0xc0192008 (vt_resize+0x44) >> sp =3D 0xc075edf8 fp =3D 0xc075ee18 >> r4 =3D 0xc05a0e90 r5 =3D 0xc05a0f00 >> r6 =3D 0xc04df462 r7 =3D 0xc05a0f50 >> r8 =3D 0x00000000 >> vt_resize() at vt_resize+0x44 >> pc =3D 0xc0192008 lr =3D 0xc0191f7c (vt_upgrade+0x38c) >> sp =3D 0xc075ee20 fp =3D 0xc075ee88 >> r4 =3D 0x00000001 r5 =3D 0xc0664898 >> r6 =3D 0xc05a0e90 r7 =3D 0xc0523148 >> r8 =3D 0xc06650a4 r9 =3D 0xc06650a0 >> r10 =3D 0x00001bd6 >> vt_upgrade() at vt_upgrade+0x38c >> pc =3D 0xc0191f7c lr =3D 0xc0205e14 (mi_startup+0x11c) >> sp =3D 0xc075ee90 fp =3D 0xc075eea8 >> r4 =3D 0x00000001 r5 =3D 0xc0664898 >> r6 =3D 0x00000000 r7 =3D 0xc0523148 >> r8 =3D 0xc06650a4 r9 =3D 0xc06650a0 >> r10 =3D 0x00001bd6 >> mi_startup() at mi_startup+0x11c >> pc =3D 0xc0205e14 lr =3D 0xc0100238 (virt_done+0x44) >> sp =3D 0xc075eeb0 fp =3D 0x00000000 >> r4 =3D 0xc0100268 r5 =3D 0xc066c000 >> r6 =3D 0x02048740 r7 =3D 0x0010014c >> r8 =3D 0x00000000 r9 =3D 0xc074d000 >> virt_done() at virt_done+0x44 >> pc =3D 0xc0100238 lr =3D 0xc0100238 (virt_done+0x44) >> sp =3D 0xc075eeb0 fp =3D 0x00000000 >> Unable to unwind further >> db> >> On 12 May 2014, at 21:29, Aleksandr Rybalko wrote: >>=20 >>> Author: ray >>> Date: Mon May 12 19:29:38 2014 >>> New Revision: 265927 >>> URL: http://svnweb.freebsd.org/changeset/base/265927 >>>=20 >>> Log: >>> Update terminal sizes in any case when new vt(4) driver arrive. >>> (Plus remove one unused newline) >>>=20 >>> Sponsored by: The FreeBSD Foundation >>>=20 >>> Modified: >>> head/sys/dev/vt/vt_core.c >>>=20 >>> Modified: head/sys/dev/vt/vt_core.c >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> --- head/sys/dev/vt/vt_core.c Mon May 12 19:11:39 2014 = (r265926) >>> +++ head/sys/dev/vt/vt_core.c Mon May 12 19:29:38 2014 = (r265927) >>> @@ -1981,8 +1981,11 @@ vt_upgrade(struct vt_device *vd) >>> unsigned int i; >>>=20 >>> /* Device didn't pass vd_init() or already upgraded. */ >>> - if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) >>> + if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) { >>> + /* Refill settings with new sizes anyway. */ >>> + vt_resize(vd); >>> return; >>> + } >>> vd->vd_flags |=3D VDF_ASYNC; >>>=20 >>> for (i =3D 0; i < VT_MAXWINDOWS; i++) { >>> @@ -2019,7 +2022,6 @@ vt_upgrade(struct vt_device *vd) >>>=20 >>> /* Refill settings with new sizes. */ >>> vt_resize(vd); >>> - >>> } >>>=20 >>> static void >>>=20 >>>=20 >>=20 >=20 > Thanks! >=20 > WBW > --=20 > Aleksandr Rybalko >=20 From owner-freebsd-arm@FreeBSD.ORG Wed May 14 16:37:18 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1706C2; Wed, 14 May 2014 16:37:18 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70CCE214E; Wed, 14 May 2014 16:37:18 +0000 (UTC) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3253B1C0C0BCC; Wed, 14 May 2014 18:37:16 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: svn commit: r265927 - head/sys/dev/vt From: Michael Tuexen In-Reply-To: <20140514142252.8fe1742f90a28e534532b1d5@freebsd.org> Date: Wed, 14 May 2014 18:37:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <17B3391B-BCE3-4B0D-93AE-D2B377FD9038@freebsd.org> References: <201405121929.s4CJTcBx010967@svn.freebsd.org> <2899E6ED-712E-46BC-960B-9847FD99431C@freebsd.org> <20140514142252.8fe1742f90a28e534532b1d5@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1874) Cc: "freebsd-arm@freebsd.org" , src-committers@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:37:19 -0000 On 14 May 2014, at 13:22, Aleksandr Rybalko wrote: > On Tue, 13 May 2014 18:20:32 +0200 > Michael Tuexen wrote: >=20 >> Hi Aleksandr, >=20 > Hi Michael, >=20 >>=20 >> could it be that this commit results in the following panic when = booting >> a Raspberry Pi: >>=20 >> fb0: 656x416(0x0@0,0) 16bpp >> fb0: pitch 1312, base 0x5e006000, screen_size 545792 >> fbd0 on fb0 >> VT: initialize with new VT driver "fb". >> panic: mtx_lock() of spin mutex (null) @ = /usr/home/tuexen/head/sys/dev/vt/vt_core.c:2035 >> KDB: enter: panic >=20 >=20 > Hmm, looks like here is some memory corruption. It is possible happen > due some issue of vt(4), but panic and bt show problem with lock which > was used right before that place: > vt_upgrade() call VT_LOCK(vd), VT_UNLOCK(vd), then vt_resize(vd) > vt_resize(vd) try to VT_LOCK(vd) and fail. OK, I tested this. the first time vt_upgrade() is called, it calls vt_resize() from line = 2024, and this is not a problem. The second time vt_upgrade is called, it = calls vt_resize from line 1987. This results in the panic. Does this help? Best regards Michael >=20 > Can you please try to do clean rebuild (in case you use incremental > build)? >=20 >> [ thread pid 0 tid 100000 ] >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >> db> where=20 >> Tracing pid 0 tid 100000 td 0xc06648a0 >> db_trace_self() at db_trace_self >> pc =3D 0xc0495760 lr =3D 0xc0130fdc (db_stack_trace+0xf4) >> sp =3D 0xc075ea68 fp =3D 0xc075ea80 >> r10 =3D 0xc0663930 >> db_stack_trace() at db_stack_trace+0xf4 >> pc =3D 0xc0130fdc lr =3D 0xc013094c (db_command+0x270) >> sp =3D 0xc075ea88 fp =3D 0xc075eb28 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0x00000072 >> db_command() at db_command+0x270 >> pc =3D 0xc013094c lr =3D 0xc01306b0 (db_command_loop+0x60) >> sp =3D 0xc075eb30 fp =3D 0xc075eb40 >> r4 =3D 0xc04d5176 r5 =3D 0xc04ef7ba >> r6 =3D 0xc066391c r7 =3D 0xc0590b40 >> r8 =3D 0xc065a294 r9 =3D 0xc065a290 >> r10 =3D 0xc075ed10 >> db_command_loop() at db_command_loop+0x60 >> pc =3D 0xc01306b0 lr =3D 0xc0133078 (db_trap+0xd8) >> sp =3D 0xc075eb48 fp =3D 0xc075ec68 >> r4 =3D 0x00000000 r5 =3D 0xc0663928 >> r6 =3D 0xc065a2c0 >> db_trap() at db_trap+0xd8 >> pc =3D 0xc0133078 lr =3D 0xc028de10 (kdb_trap+0xbc) >> sp =3D 0xc075ec70 fp =3D 0xc075ec90 >> r4 =3D 0x00000000 r5 =3D 0x00000001 >> r6 =3D 0xc065a2c0 r7 =3D 0xc0590b40 >> kdb_trap() at kdb_trap+0xbc >> pc =3D 0xc028de10 lr =3D 0xc04a90e0 = (undefinedinstruction+0x298) >> sp =3D 0xc075ec98 fp =3D 0xc075ed08 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0xc04a8d98 r7 =3D 0xe7ffffff >> r8 =3D 0xc06648a0 r9 =3D 0xc028d6e0 >> r10 =3D 0xc075ed10 >> undefinedinstruction() at undefinedinstruction+0x298 >> pc =3D 0xc04a90e0 lr =3D 0xc04972dc (exception_exit) >> sp =3D 0xc075ed10 fp =3D 0xc075ed68 >> r4 =3D 0xc04ef814 r5 =3D 0xc075edbc >> r6 =3D 0xc04ed1f1 r7 =3D 0xc064c7d0 >> r8 =3D 0xc06648a0 r9 =3D 0xc066537c >> r10 =3D 0xc064c630 >> exception_exit() at exception_exit >> pc =3D 0xc04972dc lr =3D 0xc028d6d4 (kdb_enter+0x40) >> sp =3D 0xc075ed60 fp =3D 0xc075ed68 >> r0 =3D 0xc065a2a4 r1 =3D 0x00000000 >> r2 =3D 0xc04f328a r3 =3D 0x000000ab >> r4 =3D 0xc04ef814 r5 =3D 0xc075edbc >> r6 =3D 0xc04ed1f1 r7 =3D 0xc064c7d0 >> r8 =3D 0xc06648a0 r9 =3D 0xc066537c >> r10 =3D 0xc064c630 r12 =3D 0x00000000 >> $a() at $a >> pc =3D 0xc028d6e4 lr =3D 0xc0256eb8 (vpanic+0xb4) >> sp =3D 0xc075ed70 fp =3D 0xc075ed90 >> r4 =3D 0x00000100 >> vpanic() at vpanic+0xb4 >> pc =3D 0xc0256eb8 lr =3D 0xc0256df4 ($d) >> sp =3D 0xc075ed98 fp =3D 0xc075edb0 >> r4 =3D 0xc064c6d0 r5 =3D 0xc04ed1f1 >> r6 =3D 0xc075edbc r7 =3D 0xc064c630 >> r8 =3D 0x00000000 r9 =3D 0x000007f3 >> r10 =3D 0x000007f7 >> $d() at $d >> pc =3D 0xc0256df4 lr =3D 0xc0243240 (__mtx_lock_flags+0x134) >> sp =3D 0xc075edc8 fp =3D 0xc075edf0 >> r4 =3D 0xc04df462 r5 =3D 0xc05a0f00 >> r6 =3D 0x000007f3 r7 =3D 0xc05a0f00 >> __mtx_lock_flags() at __mtx_lock_flags+0x134 >> pc =3D 0xc0243240 lr =3D 0xc0192008 (vt_resize+0x44) >> sp =3D 0xc075edf8 fp =3D 0xc075ee18 >> r4 =3D 0xc05a0e90 r5 =3D 0xc05a0f00 >> r6 =3D 0xc04df462 r7 =3D 0xc05a0f50 >> r8 =3D 0x00000000 >> vt_resize() at vt_resize+0x44 >> pc =3D 0xc0192008 lr =3D 0xc0191f7c (vt_upgrade+0x38c) >> sp =3D 0xc075ee20 fp =3D 0xc075ee88 >> r4 =3D 0x00000001 r5 =3D 0xc0664898 >> r6 =3D 0xc05a0e90 r7 =3D 0xc0523148 >> r8 =3D 0xc06650a4 r9 =3D 0xc06650a0 >> r10 =3D 0x00001bd6 >> vt_upgrade() at vt_upgrade+0x38c >> pc =3D 0xc0191f7c lr =3D 0xc0205e14 (mi_startup+0x11c) >> sp =3D 0xc075ee90 fp =3D 0xc075eea8 >> r4 =3D 0x00000001 r5 =3D 0xc0664898 >> r6 =3D 0x00000000 r7 =3D 0xc0523148 >> r8 =3D 0xc06650a4 r9 =3D 0xc06650a0 >> r10 =3D 0x00001bd6 >> mi_startup() at mi_startup+0x11c >> pc =3D 0xc0205e14 lr =3D 0xc0100238 (virt_done+0x44) >> sp =3D 0xc075eeb0 fp =3D 0x00000000 >> r4 =3D 0xc0100268 r5 =3D 0xc066c000 >> r6 =3D 0x02048740 r7 =3D 0x0010014c >> r8 =3D 0x00000000 r9 =3D 0xc074d000 >> virt_done() at virt_done+0x44 >> pc =3D 0xc0100238 lr =3D 0xc0100238 (virt_done+0x44) >> sp =3D 0xc075eeb0 fp =3D 0x00000000 >> Unable to unwind further >> db> >> On 12 May 2014, at 21:29, Aleksandr Rybalko wrote: >>=20 >>> Author: ray >>> Date: Mon May 12 19:29:38 2014 >>> New Revision: 265927 >>> URL: http://svnweb.freebsd.org/changeset/base/265927 >>>=20 >>> Log: >>> Update terminal sizes in any case when new vt(4) driver arrive. >>> (Plus remove one unused newline) >>>=20 >>> Sponsored by: The FreeBSD Foundation >>>=20 >>> Modified: >>> head/sys/dev/vt/vt_core.c >>>=20 >>> Modified: head/sys/dev/vt/vt_core.c >>> = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> --- head/sys/dev/vt/vt_core.c Mon May 12 19:11:39 2014 = (r265926) >>> +++ head/sys/dev/vt/vt_core.c Mon May 12 19:29:38 2014 = (r265927) >>> @@ -1981,8 +1981,11 @@ vt_upgrade(struct vt_device *vd) >>> unsigned int i; >>>=20 >>> /* Device didn't pass vd_init() or already upgraded. */ >>> - if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) >>> + if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) { >>> + /* Refill settings with new sizes anyway. */ >>> + vt_resize(vd); >>> return; >>> + } >>> vd->vd_flags |=3D VDF_ASYNC; >>>=20 >>> for (i =3D 0; i < VT_MAXWINDOWS; i++) { >>> @@ -2019,7 +2022,6 @@ vt_upgrade(struct vt_device *vd) >>>=20 >>> /* Refill settings with new sizes. */ >>> vt_resize(vd); >>> - >>> } >>>=20 >>> static void >>>=20 >>>=20 >>=20 >=20 > Thanks! >=20 > WBW > --=20 > Aleksandr Rybalko >=20 From owner-freebsd-arm@FreeBSD.ORG Wed May 14 18:12:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEFFA354 for ; Wed, 14 May 2014 18:12:51 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A9E72A88 for ; Wed, 14 May 2014 18:12:51 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so9128862wib.5 for ; Wed, 14 May 2014 11:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=1r470elFhuq2Wj0qE5E6Fu85Nbmn3sqB7bWSLC8kBJI=; b=HOKIAsMbW87OlFOjbwHhdMVQqhIw0STRQnuxCUQY8Njc5zLrmVTFkwDnGUxs5hU5MH hBrYv8fbbs54F0opI3lAUANveCn2CH48hUUYqoJdjZ4A6ogEXypwd5jE/VLiRRv5mSSP 3nVCQprHGKaPVbybq4MzYGD6rvFwo4j0yfl1i0BPBpLil+WSxyW03TELdGi1XlbB3ZCW fFmGOvxOOeUczKhxSvSq5mt0jACuwm3aP/R3deH2GUnYEOS7B+hUWpP9Tf/087uDa0ft qRdj+hv4dsjVbEHeHzRvDkC7zfw8Rxd/SV2G9GJK1ov0ZOOPlf/ub06LedGLrowoG5xR EBLw== MIME-Version: 1.0 X-Received: by 10.180.82.133 with SMTP id i5mr27440155wiy.50.1400091169747; Wed, 14 May 2014 11:12:49 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.167.197 with HTTP; Wed, 14 May 2014 11:12:49 -0700 (PDT) Date: Wed, 14 May 2014 14:12:49 -0400 X-Google-Sender-Auth: EV_4UJSUwAXEIAO4Mg-n5Xl6llg Message-ID: Subject: Superpages by default From: Zbigniew Bodek To: "freebsd-arm@freebsd.org" Content-Type: multipart/mixed; boundary=f46d04428c98d390b204f9602095 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 18:12:51 -0000 --f46d04428c98d390b204f9602095 Content-Type: text/plain; charset=UTF-8 Hello all, Since we have SMP fixed and it seems that there are no more known bugs in ARM superpages then we could enable superpages by default. I'm attaching the patch that is to be committed to make that happen. If you are not using superpages on your ARM platforms, I will appreciate if you could try them out on the current HEAD and report any negative experience. If there are no objections then I would like to enable this feature in a week from now. Thanks and best regards zbb --f46d04428c98d390b204f9602095 Content-Type: text/plain; charset=US-ASCII; name="sp_default.diff" Content-Disposition: attachment; filename="sp_default.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hv6xzdcu0 ZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL3BtYXAtdjYuYyBiL3N5cy9hcm0vYXJtL3BtYXAtdjYu YwppbmRleCBjZGUyMDhiLi45MzQ4ZWU1IDEwMDY0NAotLS0gYS9zeXMvYXJtL2FybS9wbWFwLXY2 LmMKKysrIGIvc3lzL2FybS9hcm0vcG1hcC12Ni5jCkBAIC00NjMsNyArNDYzLDcgQEAgc3RhdGlj IGNvbnN0IHVpbnQzMl90IHBjX2ZyZWVtYXNrW19OUENNXSA9IHsKIHN0YXRpYyBTWVNDVExfTk9E RShfdm0sIE9JRF9BVVRPLCBwbWFwLCBDVExGTEFHX1JELCAwLCAiVk0vcG1hcCBwYXJhbWV0ZXJz Iik7CiAKIC8qIFN1cGVycGFnZXMgdXRpbGl6YXRpb24gZW5hYmxlZCA9IDEgLyBkaXNhYmxlZCA9 IDAgKi8KLXN0YXRpYyBpbnQgc3BfZW5hYmxlZCA9IDA7CitzdGF0aWMgaW50IHNwX2VuYWJsZWQg PSAxOwogU1lTQ1RMX0lOVChfdm1fcG1hcCwgT0lEX0FVVE8sIHNwX2VuYWJsZWQsIENUTEZMQUdf UkRUVU4sICZzcF9lbmFibGVkLCAwLAogICAgICJBcmUgbGFyZ2UgcGFnZSBtYXBwaW5ncyBlbmFi bGVkPyIpOwogCg== --f46d04428c98d390b204f9602095-- From owner-freebsd-arm@FreeBSD.ORG Thu May 15 01:00:27 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F9A6659; Thu, 15 May 2014 01:00:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9D012D89; Thu, 15 May 2014 01:00:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s4F10Pm4007186; Wed, 14 May 2014 21:00:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s4F10Pl2007182; Thu, 15 May 2014 01:00:25 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 15 May 2014 01:00:25 GMT Message-Id: <201405150100.s4F10Pl2007182@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:00:27 -0000 TB --- 2014-05-15 01:00:19 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-15 01:00:19 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-15 01:00:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-15 01:00:19 - cleaning the object tree TB --- 2014-05-15 01:00:19 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-15 01:00:24 - At svn revision 266102 TB --- 2014-05-15 01:00:25 - building world TB --- 2014-05-15 01:00:25 - CROSS_BUILD_TESTING=YES TB --- 2014-05-15 01:00:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-15 01:00:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-15 01:00:25 - SRCCONF=/dev/null TB --- 2014-05-15 01:00:25 - TARGET=arm TB --- 2014-05-15 01:00:25 - TARGET_ARCH=arm TB --- 2014-05-15 01:00:25 - TZ=UTC TB --- 2014-05-15 01:00:25 - __MAKE_CONF=/dev/null TB --- 2014-05-15 01:00:25 - cd /src TB --- 2014-05-15 01:00:25 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) -------------------------------------------------------------- "Makefile", line 6: Could not find src.opts.mk "Makefile", line 110: Malformed conditional (${MK_TESTS} != no) "Makefile", line 112: if-less endif make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-15 01:00:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-15 01:00:25 - ERROR: failed to build world TB --- 2014-05-15 01:00:25 - 1.62 user 3.09 system 5.76 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu May 15 01:08:00 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7072376B; Thu, 15 May 2014 01:08:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38E1B2EAF; Thu, 15 May 2014 01:07:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s4F0ooQa006846; Wed, 14 May 2014 20:50:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s4F0ooKa006842; Thu, 15 May 2014 00:50:50 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 15 May 2014 00:50:50 GMT Message-Id: <201405150050.s4F0ooKa006842@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:08:00 -0000 TB --- 2014-05-15 00:50:44 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-15 00:50:44 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-15 00:50:44 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-15 00:50:44 - cleaning the object tree TB --- 2014-05-15 00:50:44 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-15 00:50:49 - At svn revision 266100 TB --- 2014-05-15 00:50:50 - building world TB --- 2014-05-15 00:50:50 - CROSS_BUILD_TESTING=YES TB --- 2014-05-15 00:50:50 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-15 00:50:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-15 00:50:50 - SRCCONF=/dev/null TB --- 2014-05-15 00:50:50 - TARGET=arm TB --- 2014-05-15 00:50:50 - TARGET_ARCH=arm TB --- 2014-05-15 00:50:50 - TZ=UTC TB --- 2014-05-15 00:50:50 - __MAKE_CONF=/dev/null TB --- 2014-05-15 00:50:50 - cd /src TB --- 2014-05-15 00:50:50 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) -------------------------------------------------------------- "Makefile", line 6: Could not find src.opts.mk "Makefile", line 110: Malformed conditional (${MK_TESTS} != no) "Makefile", line 112: if-less endif make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-15 00:50:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-15 00:50:50 - ERROR: failed to build world TB --- 2014-05-15 00:50:50 - 1.66 user 2.89 system 5.88 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu May 15 01:10:27 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 328D220A; Thu, 15 May 2014 01:10:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E9B012F11; Thu, 15 May 2014 01:10:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s4F1APgY007506; Wed, 14 May 2014 21:10:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s4F1APs9007502; Thu, 15 May 2014 01:10:25 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 15 May 2014 01:10:25 GMT Message-Id: <201405150110.s4F1APs9007502@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:10:27 -0000 TB --- 2014-05-15 01:10:19 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-15 01:10:19 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-15 01:10:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-15 01:10:19 - cleaning the object tree TB --- 2014-05-15 01:10:19 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-15 01:10:24 - At svn revision 266103 TB --- 2014-05-15 01:10:25 - building world TB --- 2014-05-15 01:10:25 - CROSS_BUILD_TESTING=YES TB --- 2014-05-15 01:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-15 01:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-15 01:10:25 - SRCCONF=/dev/null TB --- 2014-05-15 01:10:25 - TARGET=arm TB --- 2014-05-15 01:10:25 - TARGET_ARCH=arm TB --- 2014-05-15 01:10:25 - TZ=UTC TB --- 2014-05-15 01:10:25 - __MAKE_CONF=/dev/null TB --- 2014-05-15 01:10:25 - cd /src TB --- 2014-05-15 01:10:25 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) -------------------------------------------------------------- "Makefile", line 6: Could not find src.opts.mk "Makefile", line 110: Malformed conditional (${MK_TESTS} != no) "Makefile", line 112: if-less endif make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-15 01:10:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-15 01:10:25 - ERROR: failed to build world TB --- 2014-05-15 01:10:25 - 1.66 user 3.05 system 5.74 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu May 15 01:20:25 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07BD130A; Thu, 15 May 2014 01:20:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1BEA2082; Thu, 15 May 2014 01:20:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s4F1KNLE007893; Wed, 14 May 2014 21:20:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s4F1KNoc007889; Thu, 15 May 2014 01:20:23 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 15 May 2014 01:20:23 GMT Message-Id: <201405150120.s4F1KNoc007889@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:20:25 -0000 TB --- 2014-05-15 01:20:17 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-05-15 01:20:17 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-05-15 01:20:17 - starting HEAD tinderbox run for arm/arm TB --- 2014-05-15 01:20:17 - cleaning the object tree TB --- 2014-05-15 01:20:17 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-05-15 01:20:22 - At svn revision 266103 TB --- 2014-05-15 01:20:23 - building world TB --- 2014-05-15 01:20:23 - CROSS_BUILD_TESTING=YES TB --- 2014-05-15 01:20:23 - MAKEOBJDIRPREFIX=/obj TB --- 2014-05-15 01:20:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-05-15 01:20:23 - SRCCONF=/dev/null TB --- 2014-05-15 01:20:23 - TARGET=arm TB --- 2014-05-15 01:20:23 - TARGET_ARCH=arm TB --- 2014-05-15 01:20:23 - TZ=UTC TB --- 2014-05-15 01:20:23 - __MAKE_CONF=/dev/null TB --- 2014-05-15 01:20:23 - cd /src TB --- 2014-05-15 01:20:23 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) -------------------------------------------------------------- "Makefile", line 6: Could not find src.opts.mk "Makefile", line 110: Malformed conditional (${MK_TESTS} != no) "Makefile", line 112: if-less endif make: fatal errors encountered -- cannot continue *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-05-15 01:20:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-05-15 01:20:23 - ERROR: failed to build world TB --- 2014-05-15 01:20:23 - 1.61 user 3.00 system 5.64 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu May 15 03:24:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3195ACD for ; Thu, 15 May 2014 03:24:06 +0000 (UTC) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87C9629F4 for ; Thu, 15 May 2014 03:24:06 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id c41so194321eek.17 for ; Wed, 14 May 2014 20:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rtAGWDtrlOPEaBKeLGJMkGFmy2IDhRkxkeqIR3VOs1A=; b=XrfDJJ7/4o95U1u1Cl+cmqBRxKdCC3Mtruf5EVg8fI1mO+DFWevcc5kijuH4x7ccti ed1iiNJU+ujf9+QobIXNkUtTlHvWnKnlpI7GFKLSPICVcuBlaKMG3dXQ+LisSCXsbMl1 g06Y0q0BPuOmo5cI5398tfP2YGBb1rJ2tWP0swYFTfKj9pep7iOIU9y0+hxi2HDlUoGt 9PWsRNGAzsaxVZ9mrh8b6wKXCD2nxG8GSymsd5KfFIoAF6egg8gjkClrqvocDFrwCh28 wpJDNIi4yZ0GF1iH13XYozNr4L0dQrea5TpIW02H/+s4Emgd25TTu8Y5/ZDDR0HwDHwF FHBg== X-Received: by 10.14.205.196 with SMTP id j44mr584665eeo.72.1400124244414; Wed, 14 May 2014 20:24:04 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id x45sm9331510eeu.23.2014.05.14.20.24.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 20:24:02 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53743350.6080001@hot.ee> Date: Thu, 15 May 2014 06:24:00 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Warner Losh Subject: Re: Patch to make BBB properly boot from eMMC every time References: <5371E1F3.6080002@hot.ee> <8FE89E4A-1398-4321-BBBC-CA377C7981B1@bsdimp.com> In-Reply-To: <8FE89E4A-1398-4321-BBBC-CA377C7981B1@bsdimp.com> X-TagToolbar-Keys: D20140515062400069 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 03:24:07 -0000 On 2014-05-13 17:03, Warner Losh wrote: > > On May 13, 2014, at 3:12 AM, Sulev-Madis Silber (ketas) wrote: > >> On my BBB, I need following patch to boot from eMMC 100% of cases. >> Without that, device is detected with 1 / 4 bit bus (it's actually 8 >> bit) or not at all (then boot fails). >> >> Actually, that code looks like weird way to implement sleep(), or at >> least it has such (side) effect. > > So you added a printf and the problem went away. That’s good info, but not sufficient. Does the problem go away if you put a DELAY(10) or something like that instead? That’s a better fix, or better yet, more nuanced retry... > I should try. Recently, even printf doesn't fix it (~5 fails already, sometimes repeatedly after hw reset)... it takes tens of seconds and then fails. Probably retry or something entirely different in detection code should be used there. > Warner > >> Actually ian@ made that patch, and was confused about results. >> >> >> ------------------------------------------------------------------------- >> Index: sys/dev/mmc/mmc.c >> =================================================================== >> --- sys/dev/mmc/mmc.c (revision 264141) >> +++ sys/dev/mmc/mmc.c (working copy) >> @@ -769,8 +769,10 @@ mmc_test_bus_width(struct mmc_softc *sc) >> data.data = p8; >> data.len = 8; >> data.flags = MMC_DATA_WRITE; >> - mmc_wait_for_cmd(sc, &cmd, 0); >> - >> + err = mmc_wait_for_cmd(sc, &cmd, 0); >> + if (err != 0) >> + device_printf(sc->dev, "BUSTEST_W err %d\n", err); >> + >> memset(&cmd, 0, sizeof(cmd)); >> memset(&data, 0, sizeof(data)); >> cmd.opcode = MMC_BUSTEST_R; >> @@ -782,7 +784,12 @@ mmc_test_bus_width(struct mmc_softc *sc) >> data.len = 8; >> data.flags = MMC_DATA_READ; >> err = mmc_wait_for_cmd(sc, &cmd, 0); >> - >> + if (err != 0) >> + device_printf(sc->dev, "BUSTEST_R err %d\n", err); >> + >> + device_printf(sc->dev, "read %02x %02x %02x %02x %02x >> %02x %02x %02x\n", >> + buf[0], buf[1], buf[2], buf[3], buf[4], buf[5], >> buf[6], buf[7]); >> + >> mmcbr_set_bus_width(sc->dev, bus_width_1); >> mmcbr_update_ios(sc->dev); >> ------------------------------------------------------------------------- >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Fri May 16 22:13:20 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E10C541 for ; Fri, 16 May 2014 22:13:20 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4E822EC1 for ; Fri, 16 May 2014 22:13:18 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s4GMD2Ne057126 for ; Sat, 17 May 2014 00:13:09 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53768D6E.4030902@fgznet.ch> Date: Sat, 17 May 2014 00:13:02 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: CFT binutils-ports Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 22:13:20 -0000 Hi all, here I have a patchlet to build binutils in ports for arm*. http://people.freebsd.org/~andreast/binutils_ports_20140515.tar I did it on trunk. What you have to do: unpack the tar in the /usr/ports/devel/binutils dir and build on your favorite arm platform. I'm interested in feedback for arm, armv6 and even if one has arm*b-*freebsd*. The plan in to submit/commit it to binutils trunk once the feedback came in ;) TIA, Andreas From owner-freebsd-arm@FreeBSD.ORG Sat May 17 21:40:00 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C77011CF for ; Sat, 17 May 2014 21:40:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B333299E for ; Sat, 17 May 2014 21:40:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4HLe05U027317 for ; Sat, 17 May 2014 21:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4HLe0IL027316; Sat, 17 May 2014 21:40:00 GMT (envelope-from gnats) Resent-Date: Sat, 17 May 2014 21:40:00 GMT Resent-Message-Id: <201405172140.s4HLe0IL027316@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, Marcus Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C91E0EF2 for ; Sat, 17 May 2014 21:36:20 +0000 (UTC) Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7038296F for ; Sat, 17 May 2014 21:36:20 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s4HLaHxG056679 for ; Sat, 17 May 2014 21:36:17 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s4HLaH7D056676; Sat, 17 May 2014 21:36:17 GMT (envelope-from nobody) Message-Id: <201405172136.s4HLaH7D056676@cgiserv.freebsd.org> Date: Sat, 17 May 2014 21:36:17 GMT From: Marcus To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/189899: rpi.dts don't build anymore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 21:40:00 -0000 >Number: 189899 >Category: arm >Synopsis: rpi.dts don't build anymore >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: Sat May 17 21:40:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Marcus >Release: 10 Stable >Organization: >Environment: FreeBSD luke 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Hi, if I build 10 stable (current SVN) for armv6/RPI-B Kernel the /sys/RPI-B/rpi.dtb will not be built. If I use r266250 it works as expected. so long Marcus >How-To-Repeat: svn checkout https://svn0.eu.freebsd.org/base/stable/10 /usr/src/10 cd /usr/src/10 make TARGET=arm TARGET_ARCH=armv6 WITH_FDT=yes build world make TARGET=arm TARGET_ARCH=armv6 WITH_FDT=yes KERNCONF=RPI-B build kernel ls /usr/obj/arm.armv6/usr/src/10/sys/RPI-B/rpi.dtb >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Sat May 17 21:50:01 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 383D36BE for ; Sat, 17 May 2014 21:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 240FA2A65 for ; Sat, 17 May 2014 21:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4HLo0nB039380 for ; Sat, 17 May 2014 21:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4HLo0Fa039379; Sat, 17 May 2014 21:50:00 GMT (envelope-from gnats) Date: Sat, 17 May 2014 21:50:00 GMT Message-Id: <201405172150.s4HLo0Fa039379@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Ian Lepore Subject: Re: arm/189899: rpi.dts don't build anymore Reply-To: Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 21:50:01 -0000 The following reply was made to PR arm/189899; it has been noted by GNATS. From: Ian Lepore To: Marcus Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: arm/189899: rpi.dts don't build anymore Date: Sat, 17 May 2014 15:45:30 -0600 On Sat, 2014-05-17 at 21:36 +0000, Marcus wrote: > >Number: 189899 > >Category: arm > >Synopsis: rpi.dts don't build anymore > >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: Sat May 17 21:40:00 UTC 2014 > >Closed-Date: > >Last-Modified: > >Originator: Marcus > >Release: 10 Stable > >Organization: > >Environment: > FreeBSD luke 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > >Description: > Hi, > > if I build 10 stable (current SVN) for armv6/RPI-B Kernel the /sys/RPI-B/rpi.dtb will not be built. > If I use r266250 it works as expected. > > so long > > Marcus > >How-To-Repeat: > svn checkout https://svn0.eu.freebsd.org/base/stable/10 /usr/src/10 > cd /usr/src/10 > make TARGET=arm TARGET_ARCH=armv6 WITH_FDT=yes build world > make TARGET=arm TARGET_ARCH=armv6 WITH_FDT=yes KERNCONF=RPI-B build kernel > > ls /usr/obj/arm.armv6/usr/src/10/sys/RPI-B/rpi.dtb > > >Fix: > > > >Release-Note: > >Audit-Trail: > >Unformatted: The 10-stable branch is in the process of being synchronized with all the bugfixes from -current right now. It looks like you were unlucky to grab the source at a revision with temporary breakage. I think if you update again you'll get a version that will work. From owner-freebsd-arm@FreeBSD.ORG Sun May 18 03:24:39 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2061C69 for ; Sun, 18 May 2014 03:24:39 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86F0A22E6 for ; Sun, 18 May 2014 03:24:38 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WlriB-0008A6-Cu for freebsd-arm@FreeBSD.org; Sun, 18 May 2014 03:24:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4I3OTaR041110 for ; Sat, 17 May 2014 21:24:29 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+7Nsr+pm6kirmXvpDNh65U Subject: Re: Heads-up: massive MFC from 11->10-stable for (mostly) ARM stuff From: Ian Lepore To: freebsd-arm In-Reply-To: <1399992596.56626.14.camel@revolution.hippie.lan> References: <1399992596.56626.14.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 17 May 2014 21:24:28 -0600 Message-ID: <1400383468.1152.19.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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 03:24:39 -0000 On Tue, 2014-05-13 at 08:49 -0600, Ian Lepore wrote: > This is just an fyi that I'm going to spend the new few days doing a > massive merge of ARM-related work from -current to 10-stable. This is > merging pretty much all the ARM development that has happened since the > end of November, so that at the end of it we'll have SMP and hardware > floating point and all the bugfixes we've done recently for ARM in 10. > All in all I've identified about 450 changesets to merge. > > In some cases this will touch things outside of sys/arm, mostly powerpc > and mips stuff as some FDT/OFW changes come along for the ride. I'm > going to do my best to not have any checkins that cause even temporary > build breakage, but... you know... it's going to happen. If you run > into breakage and it isn't fixed within a few minutes, feel free to let > me know and I'll get right on it. > > -- Ian Just a followup to let everyone know that this is now done. There may be a few changesets I missed or followups to fix any fallout from the mega-merge, but in theory the state of 10-stable for ARM should now be almost the same as -current except for changes made in the past few days. I've been compile-testing as I go; I'll start run-testing on various boards tomorrow morning. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun May 18 10:34:32 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F95355B for ; Sun, 18 May 2014 10:34:32 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C59692E8F for ; Sun, 18 May 2014 10:34:31 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 869101FE029 for ; Sun, 18 May 2014 12:34:30 +0200 (CEST) Message-ID: <53788CE7.2030901@selasky.org> Date: Sun, 18 May 2014 12:35:19 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-arm Subject: DWC OTG optimisations Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 10:34:32 -0000 Hi, I've optimised the DWC OTG driver a bit. If you see any regression issues, report them to me. Thank you! http://svnweb.freebsd.org/changeset/base/266394 --HPS From owner-freebsd-arm@FreeBSD.ORG Sun May 18 10:44:43 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00CFC5F2 for ; Sun, 18 May 2014 10:44:42 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BAD1E2F2E for ; Sun, 18 May 2014 10:44:42 +0000 (UTC) Received: from [192.168.1.102] (p548198EE.dip0.t-ipconnect.de [84.129.152.238]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CBA771C104D87 for ; Sun, 18 May 2014 12:44:38 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Problem building r266396 Message-Id: <4659D059-51DB-4343-B803-E68FAB65C869@fh-muenster.de> Date: Sun, 18 May 2014 12:44:37 +0200 To: "freebsd-arm@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 10:44:43 -0000 Dear all, I'm trying to build r266396 for arm. The result is: --- crunchide --- cc -O2 -pipe -DNLIST_ELF32 -std=3Dgnu99 -Qunused-arguments = -I/home/tuexen/obj/arm.armv6/usr/home/tuexen/head/tmp/legacy/usr/include = -static = -L/home/tuexen/obj/arm.armv6/usr/home/tuexen/head/tmp/legacy/usr/lib -o = crunchide crunchide.o = exec_cy/usr/games:/home/tuexen/obj/arm.armv6/usr/home/tuexen/head/tmp/lega= cy/bin:/home/tuexen/obj/arm.armv6/usr/home/tuexen/head/tmp/usr/sbin:/home/= tuexen/obj/arm.armv6/usr/home/tuexen/head/tmp/usr/bin:/home/tuexen/obj/arm= .armv6/usr/home/tuexen/head/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin = CC=3D"cc " CXX=3D"c++ " CPP=3D"cpp " AS=3D"as" AR=3D"ar" LD=3D"ld" = NM=3Dnm OBJDUMP=3D RANLIB=3Dranlib STRINGS=3D make -j 16 -J 15,16 -m = /usr/home/tuexen/head/share/mk KERNEL=3Dkernel cleandir make[2]: = "/usr/home/tuexen/obj/arm.armv6/usr/home/tuexen/head/sys/RPI-B/Makefile" = line 57: Malformed conditional (${MK_ARM_EABI} !=3D "no") make[2]: Fatal errors encountered -- cannot continue make[2]: stopped in = /usr/home/tuexen/obj/arm.armv6/usr/home/tuexen/head/sys/RPI-B *** [buildkernel] Error code 1 make[1]: stopped in /usr/home/tuexen/head 1 error make[1]: stopped in /usr/home/tuexen/head *** [buildkernel] Error code 2 make: stopped in /usr/home/tuexen/head 1 error make: stopped in /usr/home/tuexen/head Any idea? Best regards Michael= From owner-freebsd-arm@FreeBSD.ORG Sun May 18 13:49:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AC8431D for ; Sun, 18 May 2014 13:49:25 +0000 (UTC) Received: from magneto.web.itd.umich.edu (magneto.web.itd.umich.edu [141.211.145.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD9C42B64 for ; Sun, 18 May 2014 13:49:24 +0000 (UTC) Received: (from www@localhost) by magneto.web.itd.umich.edu (8.12.11.20060308/8.12.9) id s4IDnM87027625; Sun, 18 May 2014 09:49:22 -0400 Date: Sun, 18 May 2014 09:49:22 -0400 To: freebsd-arm@freebsd.org From: =?UTF-8?Q?Robert_Hartwick?= Subject: =?UTF-8?Q?Top_of_the_day_to_you=21=21=21?= Message-ID: <714e09cdfc367731932bcec1bd751112@cases.soe.umich.edu> X-Priority: 3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 13:49:25 -0000 Top of the day to you!!! I have an offer involving large sum of money which= I intend to invest in your country.I need a partner to handle the receivin= g of the funds and investment procedure until I am discharged from the mili= tary.can you get back to me with your email address so that i send you the = full details? thank you.I'm Sgt.Robert Hartwick of the US army. From owner-freebsd-arm@FreeBSD.ORG Sun May 18 18:10:00 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3D95ADC for ; Sun, 18 May 2014 18:10:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 809DB2E8E for ; Sun, 18 May 2014 18:10:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4IIA0ho097097 for ; Sun, 18 May 2014 18:10:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4IIA0I8097096; Sun, 18 May 2014 18:10:00 GMT (envelope-from gnats) Resent-Date: Sun, 18 May 2014 18:10:00 GMT Resent-Message-Id: <201405181810.s4IIA0I8097096@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, Vadim Zaigrin Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F0C2AC2 for ; Sun, 18 May 2014 18:07:30 +0000 (UTC) Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F003D2E79 for ; Sun, 18 May 2014 18:07:29 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s4II7T3d089028 for ; Sun, 18 May 2014 18:07:29 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s4II7TRH089026; Sun, 18 May 2014 18:07:29 GMT (envelope-from nobody) Message-Id: <201405181807.s4II7TRH089026@cgiserv.freebsd.org> Date: Sun, 18 May 2014 18:07:29 GMT From: Vadim Zaigrin To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/189914: i2c(8) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 18:10:00 -0000 >Number: 189914 >Category: arm >Synopsis: i2c(8) >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: Sun May 18 18:10:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Vadim Zaigrin >Release: 10-STABLE >Organization: >Environment: FreeBSD pi 10.0-STABLE FreeBSD 10.0-STABLE #0 r262915: Sat Mar 8 19:44:28 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >Description: Hi i2c(8) utility does not work on Raspberry Pi. It uses syscall ioctl I2CSTART, I2CSTOP, I2CRSTCARD, I2CWRITE and I2CREAD. This syscalls try to call iicbus interfaces iicbus_start, iicbus_stop, iicbus_reset, iicbus_write and iicbus_read. But there is only iicbus_transfer interface in iicbus device. Interface iicbus_transfer is used by syscall ioctl I2CRDWR. >How-To-Repeat: >Fix: I have corrected source code of the i2c(8) utility to work on Raspberry Pi. The patch to the original source code and the updated source code are available here: https://github.com/vzaigrin/newi2c i2c.c.patch is a patch for original source code of the i2c.c newi2c.c is an updated source code of the i2c.c Hope this can help Patch attached with submission follows: 40c40,41 < --- > #include > #include 60,61c61,62 < uint32_t addr; < uint32_t off; --- > uint16_t addr; > uint16_t off; 125c126 < int *tokens, fd, error, i, index, j; --- > int *tokens, fd, i, index, j; 126a128,132 > struct iic_msg msg[2]; > struct iic_rdwr_data rdwr; > int mute; > uint8_t offset, buf; > int found = 0; 156a163,166 > /* To read from non existing device we need first to disable console messages */ > mute = 1; > sysctlbyname("kern.consmute", NULL, NULL, &mute, sizeof(mute) ); > 177,192c187,209 < cmd.slave = i << 1; < cmd.last = 1; < cmd.count = 0; < error = ioctl(fd, I2CRSTCARD, &cmd); < if (error) < goto out; < < cmd.slave = i << 1; < cmd.last = 1; < error = ioctl(fd, I2CSTART, &cmd); < if (!error) < printf("%x ", i); < cmd.slave = i << 1; < cmd.last = 1; < error = ioctl(fd, I2CSTOP, &cmd); < } --- > offset = 0; > msg[0].slave = i; > msg[0].flags = !IIC_M_RD; > msg[0].len = sizeof( offset ); > msg[0].buf = &offset; > msg[1].slave = i; > msg[1].flags = IIC_M_RD; > msg[1].len = sizeof( buf ); > msg[1].buf = &buf; > rdwr.msgs = msg; > rdwr.nmsgs = 2; > if ( ioctl(fd, I2CRDWR, &rdwr) >= 0 ) { > printf("%x ", i); > found = 1; > } > > } > > if ( !found ) printf( "nothing found\n" ); > > /* Now we need to enable console messages */ > mute = 0; > sysctlbyname("kern.consmute", NULL, NULL, &mute, sizeof(mute) ); 195d211 < error = ioctl(fd, I2CRSTCARD, &cmd); 201,206c217 < if (error) { < fprintf(stderr, "Error scanning I2C controller (%s): %s\n", < dev, strerror(errno)); < return (EX_NOINPUT); < } else < return (EX_OK); --- > return (EX_OK); 212d222 < int fd, error; 214,219c224 < fd = open(dev, O_RDWR); < if (fd == -1) { < fprintf(stderr, "Error opening I2C controller (%s) for " < "resetting: %s\n", dev, strerror(errno)); < return (EX_NOINPUT); < } --- > /* We can't reset bus, so do nothing */ 221,231c226 < printf("Resetting I2C controller on %s: ", dev); < error = ioctl(fd, I2CRSTCARD, &cmd); < close (fd); < < if (error) { < printf("error: %s\n", strerror(errno)); < return (EX_IOERR); < } else { < printf("OK\n"); < return (EX_OK); < } --- > return (EX_OK); 234c229 < static char * --- > static uint8_t * 237c232 < char *buf; --- > uint8_t *buf; 254c249 < i2c_write(char *dev, struct options i2c_opt, char *i2c_buf) --- > i2c_write(char *dev, struct options i2c_opt, uint8_t *i2c_buf) 256,258c251,256 < struct iiccmd cmd; < int ch, i, error, fd, bufsize; < char *err_msg, *buf; --- > int ch, i, fd, bufsize; > char *err_msg; > struct iic_msg msg; > struct iic_rdwr_data rdwr; > uint8_t *buf, *dbuf; > 272c270 < i2c_buf[i] = ch; --- > i2c_buf[i] = (uint8_t)ch; 284,289d281 < cmd.slave = i2c_opt.addr; < error = ioctl(fd, I2CSTART, &cmd); < if (error == -1) { < err_msg = "ioctl: error sending start condition"; < goto err1; < } 298,332d289 < < cmd.count = bufsize; < cmd.buf = buf; < error = ioctl(fd, I2CWRITE, &cmd); < free(buf); < if (error == -1) { < err_msg = "ioctl: error when write offset"; < goto err1; < } < } < < /* Mode - stop start */ < if (i2c_opt.mode == I2C_MODE_STOP_START) { < cmd.slave = i2c_opt.addr; < error = ioctl(fd, I2CSTOP, &cmd); < if (error == -1) { < err_msg = "ioctl: error sending stop condition"; < goto err2; < } < cmd.slave = i2c_opt.addr; < error = ioctl(fd, I2CSTART, &cmd); < if (error == -1) { < err_msg = "ioctl: error sending start condition"; < goto err1; < } < } < /* Mode - repeated start */ < if (i2c_opt.mode == I2C_MODE_REPEATED_START) { < cmd.slave = i2c_opt.addr; < error = ioctl(fd, I2CRPTSTART, &cmd); < if (error == -1) { < err_msg = "ioctl: error sending repeated start " < "condition"; < goto err1; < } 338,350c295,313 < cmd.count = i2c_opt.count; < cmd.buf = i2c_buf; < cmd.last = 0; < error = ioctl(fd, I2CWRITE, &cmd); < if (error == -1) { < err_msg = "ioctl: error when write"; < goto err1; < } < cmd.slave = i2c_opt.addr; < error = ioctl(fd, I2CSTOP, &cmd); < if (error == -1) { < err_msg = "ioctl: error sending stop condition"; < goto err2; --- > dbuf = malloc( (bufsize + i2c_opt.count) * sizeof(uint8_t) ); > > for (i = 0; i < bufsize; i++) { > dbuf[i] = buf[i]; > } > > for (i = 0; i < i2c_opt.count; i++ ) { > dbuf[i+bufsize] = i2c_buf[i]; > } > > msg.slave = i2c_opt.addr; > msg.flags = !IIC_M_RD; > msg.len = (bufsize + i2c_opt.count) * sizeof( uint8_t ); > msg.buf = dbuf; > rdwr.msgs = &msg; > rdwr.nmsgs = 1; > if ( ioctl(fd, I2CRDWR, &rdwr) < 0 ) { > err_msg = "ioctl: error when write"; > goto err1; 357,364d319 < cmd.slave = i2c_opt.addr; < error = ioctl(fd, I2CSTOP, &cmd); < if (error == -1) < fprintf(stderr, "error sending stop condtion\n"); < err2: < if (err_msg) < fprintf(stderr, "%s", err_msg); < 370c325 < i2c_read(char *dev, struct options i2c_opt, char *i2c_buf) --- > i2c_read(char *dev, struct options i2c_opt, uint8_t *i2c_buf) 372,374c327,331 < struct iiccmd cmd; < int i, fd, error, bufsize; < char *err_msg, data = 0, *buf; --- > int i, fd, bufsize; > char *err_msg; > struct iic_msg *msg; > struct iic_rdwr_data rdwr; > uint8_t *buf; 380,381d336 < bzero(&cmd, sizeof(cmd)); < 383,391d337 < cmd.slave = i2c_opt.addr; < cmd.count = 1; < cmd.last = 0; < cmd.buf = &data; < error = ioctl(fd, I2CSTART, &cmd); < if (error == -1) { < err_msg = "ioctl: error sending start condition"; < goto err1; < } 397a344 > } 399,407c346 < cmd.count = bufsize; < cmd.buf = buf; < cmd.last = 0; < error = ioctl(fd, I2CWRITE, &cmd); < free(buf); < if (error == -1) { < err_msg = "ioctl: error when write offset"; < goto err1; < } --- > msg = malloc( (bufsize + i2c_opt.count) * sizeof(struct iic_msg) ); 409,414c348,352 < if (i2c_opt.mode == I2C_MODE_STOP_START) { < cmd.slave = i2c_opt.addr; < error = ioctl(fd, I2CSTOP, &cmd); < if (error == -1) < goto err2; < } --- > for (i = 0; i < bufsize; i++) { > msg[i].slave = i2c_opt.addr; > msg[i].flags = !IIC_M_RD; > msg[i].len = sizeof( uint8_t ); > msg[i].buf = &buf[i]; 416,436d353 < cmd.slave = i2c_opt.addr; < cmd.count = 1; < cmd.last = 0; < cmd.buf = &data; < if (i2c_opt.mode == I2C_MODE_STOP_START) { < error = ioctl(fd, I2CSTART, &cmd); < if (error == -1) { < err_msg = "ioctl: error sending start condition"; < goto err1; < } < } else if (i2c_opt.mode == I2C_MODE_REPEATED_START) { < error = ioctl(fd, I2CRPTSTART, &cmd); < if (error == -1) { < err_msg = "ioctl: error sending repeated start " < "condition"; < goto err1; < } < } < error = ioctl(fd, I2CSTOP, &cmd); < if (error == -1) < goto err2; 438,443c355,359 < for (i = 0; i < i2c_opt.count; i++) { < error = read(fd, &i2c_buf[i], 1); < if (error == -1) { < err_msg = "ioctl: error while reading"; < goto err1; < } --- > for (i = 0; i < i2c_opt.count; i++ ) { > msg[i+bufsize].slave = i2c_opt.addr; > msg[i+bufsize].flags = IIC_M_RD; > msg[i+bufsize].len = sizeof( uint8_t ); > msg[i+bufsize].buf = &i2c_buf[i]; 445a362,369 > rdwr.msgs = msg; > rdwr.nmsgs = bufsize + i2c_opt.count; > > if ( ioctl(fd, I2CRDWR, &rdwr) < 0 ) { > err_msg = "ioctl: error while reading"; > goto err1; > } > 450,457d373 < cmd.slave = i2c_opt.addr; < error = ioctl(fd, I2CSTOP, &cmd); < if (error == -1) < fprintf(stderr, "error sending stop condtion\n"); < err2: < if (err_msg) < fprintf(stderr, "%s", err_msg); < 467c383 < char *dev, *skip_addr, *i2c_buf; --- > char *dev, *skip_addr; 468a385 > uint8_t *i2c_buf; 494c411 < i2c_opt.addr = (strtoul(optarg, 0, 16) << 1); --- > sscanf( optarg, "%hX", &i2c_opt.addr); 578c495 < i2c_opt.addr >> 1, i2c_opt.dir, i2c_opt.off, --- > i2c_opt.addr, i2c_opt.dir, i2c_opt.off, 606,609d522 < if (i2c_opt.verbose) < fprintf(stderr, "\nData %s (hex):\n", i2c_opt.dir == 'r' ? < "read" : "written"); < >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Sun May 18 20:30:03 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01942224 for ; Sun, 18 May 2014 20:30:03 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D87742914 for ; Sun, 18 May 2014 20:30:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4IKU2sb065859 for ; Sun, 18 May 2014 20:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4IKU2uL065858; Sun, 18 May 2014 20:30:02 GMT (envelope-from gnats) Date: Sun, 18 May 2014 20:30:02 GMT Message-Id: <201405182030.s4IKU2uL065858@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Marcus Popp Subject: Re: arm/189899: rpi.dts don't build anymore Reply-To: Marcus Popp X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 20:30:03 -0000 The following reply was made to PR arm/189899; it has been noted by GNATS. From: Marcus Popp To: Ian Lepore Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: arm/189899: rpi.dts don't build anymore Date: Sun, 18 May 2014 22:12:48 +0200 --Apple-Mail=_B8621734-2376-4C1F-B386-021CA5904016 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 17.05.2014 um 23:45 schrieb Ian Lepore : > On Sat, 2014-05-17 at 21:36 +0000, Marcus wrote: >>> Number: 189899 >>> Category: arm >>> Synopsis: rpi.dts don't build anymore >>> Confidential: no >>> Severity: non-critical >>> Priority: low >>> Responsible: freebsd-arm >>> State: open >>> Quarter: =20 >>> Keywords: =20 >>> Date-Required: >>> Class: sw-bug >>> Submitter-Id: current-users >>> Arrival-Date: Sat May 17 21:40:00 UTC 2014 >>> Closed-Date: >>> Last-Modified: >>> Originator: Marcus >>> Release: 10 Stable >>> Organization: >>> Environment: >> FreeBSD luke 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 = 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC = amd64 >>=20 >>> Description: >> Hi, >>=20 >> if I build 10 stable (current SVN) for armv6/RPI-B Kernel the = /sys/RPI-B/rpi.dtb will not be built. >> If I use r266250 it works as expected. >>=20 >> so long >>=20 >> Marcus >>> How-To-Repeat: >> svn checkout https://svn0.eu.freebsd.org/base/stable/10 /usr/src/10 >> cd /usr/src/10 >> make TARGET=3Darm TARGET_ARCH=3Darmv6 WITH_FDT=3Dyes build world >> make TARGET=3Darm TARGET_ARCH=3Darmv6 WITH_FDT=3Dyes KERNCONF=3DRPI-B = build kernel >>=20 >> ls /usr/obj/arm.armv6/usr/src/10/sys/RPI-B/rpi.dtb >>=20 >>> Fix: >>=20 >>=20 >>> Release-Note: >>> Audit-Trail: >>> Unformatted: >=20 > The 10-stable branch is in the process of being synchronized with all > the bugfixes from -current right now. It looks like you were unlucky = to > grab the source at a revision with temporary breakage. I think if you > update again you'll get a version that will work. Hi Ian, thank you for your quick reply. Tested it today (again) and it works. so long Marcus= --Apple-Mail=_B8621734-2376-4C1F-B386-021CA5904016 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEijCCBIYw ggJuoAMCAQICAQYwDQYJKoZIhvcNAQELBQAwIzELMAkGA1UEBhMCREUxFDASBgNVBAMMC3BraS5w b3BwLm14MB4XDTEzMTAyMjE5Mjc0MloXDTE0MTAyMjE5Mjc0MlowQjELMAkGA1UEBhMCREUxFDAS BgNVBAMMC01hcmN1cyBQb3BwMR0wGwYJKoZIhvcNAQkBFg5tYXJjdXNAcG9wcC5teDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+iBNSlkhKOUdsD20Bb7gWAViLJiHEMj28u0io/6zdh c/QD9BScIrV1/OqvvRYU0theadcjlc3WofS2xjjdfCpWK/x49SyYCcKHdtx++eN5KioghNAtcdLX RjJq8jFYz5Hut4Pe/Ezh9Mn1omQ6yteV+lS1mr7yIXf5HJTUPDl/bwZh2VBmWd0OhBKR7MbXylR/ OarvPxf3QTRRg56p4MqdtvJl8FQlnVaZldzaG8urJ1T0Zr2KUMUt5wwergmcLGQEEfcjsQIQuEDD UJh7PSt2V/QNRh2WFvajn6RW8bT18DbcY2ZBquSlqD0Utzt3R4plRG7ApnlXvp8P9l6xH88CAwEA AaOBpTCBojAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0 aWZpY2F0ZTAdBgNVHQ4EFgQU/IdeHCVwx9Pf4psWO+S1ub3AG2owHwYDVR0jBBgwFoAUvzZz1Ny3 PDky/U39+P3UVQnz4FkwJwYDVR0lBCAwHgYIKwYBBQUHAwQGCCsGAQUFBwMCBggrBgEFBQcDATAN BgkqhkiG9w0BAQsFAAOCAgEAaZvqOp9Lt3aUWwgJcWWghuIgwXZOLvWL5RwkuUIGEQUcr4XYkiYK wewJRuZoqNLZVvBGD3uMu4zT42UlnOjtz3uPlQiGgkJ7Q25CgwuvoiJ3L7LkUsT2tlU2ahPm3Z6F bpJ9sfLwGHvVQ8yH+MsBoBF6lqiKhnk6+/pzHbkIRuZYSbcNoLbRAZHpKgucidymnY08EyGiW2JW BWa/bqFX4nfmh1eusAzEzTLe9e6X1bvWwtHh+6DLldHr5JK3DIgbwRJosCzkNNYTaVS0PrZhPLXl r5b9Z/1Yj3kA2DSpBUmsQ29vNVagcWOYTr0DK72x31Ylobt7imky0dmIiGMN8Xe+7oxCn0ZvipRr bJDyprpLjbu9UfMRmzFjZ8A1Wj/C6DVqek0CMBY/uq00J5ijEjP6lRkapWVRPMuDsJTr+aGNTFcy H33LhVMcSH2RseIbtZFYv4vpcdLtXtADpOeH7DREogmhw1RAJzx7JJIf9x4qysoNx49ht9WuiWDe CZrTW1ZaBPJD5UetPu6FbaKg1GrfFMpOPy9FUjHD0Nc9UAsmdWdvPVpjQk0qyLlr9ZbcX2vXHx0T pd5oUptaePK7ugQhROrbiyz7h8LbF5izKpFKcycX2BySFv/QBfMv4aFCDA03RxDnI/MxrXNdwkNz 0S7MdjA7dEOARWuWkUjrG2wxggIjMIICHwIBATAoMCMxCzAJBgNVBAYTAkRFMRQwEgYDVQQDDAtw a2kucG9wcC5teAIBBjAJBgUrDgMCGgUAoIHRMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MDUxODIwMTI0OFowIwYJKoZIhvcNAQkEMRYEFIDo9gDaiBVIl7cxphC/ IHaraKGUMDcGCSsGAQQBgjcQBDEqMCgwIzELMAkGA1UEBhMCREUxFDASBgNVBAMMC3BraS5wb3Bw Lm14AgEGMDkGCyqGSIb3DQEJEAILMSqgKDAjMQswCQYDVQQGEwJERTEUMBIGA1UEAwwLcGtpLnBv cHAubXgCAQYwDQYJKoZIhvcNAQEBBQAEggEANdFaY3fzUB4Gx/3XTm7K7/+xJ73PX/gt4sDvLzhI Oes7mq1tzaw70SKI5Ddlo0KjY02HHE4QEISWPSgDK0VzQtB/mMOUcAvrtPKZ1L1AxG6vRgoVXNGS xq1p/eHiXVzWJgqrDZQndwPafYfaNxP03eASEx8AovqNgQq8e0zk6Y9d3bufdFTlUptRiWbgGWke LenjZHeXbL7uSzX+BT6zKkIRaRIQehY2Tv6DoUjUCeDvUpiYWzBo333QuC2csuqeMnMxMFhK0m78 15BVs0+shKpoxP+utQ0X3LG40oNOnwa52WneXONh4/qbsfrri3Ab6rGz4YiCvFNvdWBcq4KtkQAA AAAAAA== --Apple-Mail=_B8621734-2376-4C1F-B386-021CA5904016-- From owner-freebsd-arm@FreeBSD.ORG Mon May 19 11:06:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 970B82BF for ; Mon, 19 May 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6966D2DA5 for ; Mon, 19 May 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4JB6g74079947 for ; Mon, 19 May 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4JB6fuB079945 for freebsd-arm@FreeBSD.org; Mon, 19 May 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 May 2014 11:06:41 GMT Message-Id: <201405191106.s4JB6fuB079945@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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 11:06:42 -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/189914 arm i2c(8) o arm/189899 arm rpi.dts don't build anymore o arm/189415 arm [patch] mount_smbfs missing from arm o arm/188933 arm [lor] lock order reversal: backtrace while writing to o arm/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o ports/175605 arm devel/binutils: please fix build binutils-2.23.1 in ra 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/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 ports/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 [at91] [patch] Enable at91 booting from SDHC (high cap 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 30 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon May 19 13:21:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7702FF2 for ; Mon, 19 May 2014 13:21:10 +0000 (UTC) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F0A22ADE for ; Mon, 19 May 2014 13:21:10 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id d17so3576904eek.16 for ; Mon, 19 May 2014 06:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=4QDTYzMSqoQr4K09MqN63ejd9JSQxoBsZAoxl7L6EAs=; b=dYejdOuXjErzVhvhMP3Hw7Q/odCyy2LlmLJZxjfmRT9Kut2LQ2L9mR4WW8BAm9nlYX DWkY5xy80yQqH0nTfOYVktoz48xaTbHoT8taYBh8UMMB/CWJ8/e8Qi1LuQ554W9nHu8w yyifpJS2xQ1Yt9gH7/2g4uTUxYoeAFztW7qcfS/vdxc2RL4b6pyjvjYXBZJrEp1yXeIN UYhokGBFfx8pqncp3AgFFw/iQK0jrOxbfhInm49E2Rx3c3l2datlySvp4MEgo31/9fJD 1RvlOiiOsa0SzscZrKyU0DG7LZs4dt4Ww84qtphvgyURXEs8LNkVj4Hylqpi19Ki+VF4 yAzQ== X-Received: by 10.14.127.9 with SMTP id c9mr4237693eei.93.1400505668814; Mon, 19 May 2014 06:21:08 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id h49sm41918654eeg.21.2014.05.19.06.21.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 06:21:07 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537A050E.3040804@hot.ee> Date: Mon, 19 May 2014 16:20:14 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-arm Subject: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 13:21:11 -0000 Hello. Although maybe I could write this as reply to some other message, I feel like it might deserve separate one. I use U-Boot 2014.04 which sets CPU frequency to 1GHz, which seems nice. Apart from inability to find eMMC in ubldr (SD card is always fine), now I get whole different issues here. With 2013.04, I get occasional eMMC failure I mentioned earlier. With 2014.04, it's very hard to get SD devices detected at all. And I get all sorts of weird errors (megabytes of boot logs from serial if anyone wishes to see). I'm aware how HW clock changes can affect things like this, but I'm not exactly sure where and what happens when this is done. If I boot with 2013.04, it's ok again, if I switch to 2014.04 again, it's ok again for a while. It really feels like it's overheating. After a while, it gets extremely hard to get thing booted up. Both devices sometimes detect and sometimes not. I get things like "no compatible cards found on bus" (mmc 0/1), or things like "card at relative address x lost". Tried adding delays like suggested earlier, but that doesn't help and now the issue seems different. I get no other issues. System is very stable once it's booted up. There are no hangs, panics... Everything works. I must mention that I always use latest CURRENT. I didn't find a way to make kernel reboot system when root mount fails, so I manually patched that option in. Last time I got 11 failures before it booted up with both SD and eMMC found (they don't fail same way every time, sometimes SD is missing, often eMMC is missing). What would somebody else think about such issues? I don't have experience in HW dev, I can only guess what goes wrong. And again, if it boots, it works. And no component on BBB gets too warm to hold finger there for long time, too (if that matters). I have 5V 2.5A PSU powering it (but the PMIC should fail if voltage drops too much, etc, I read the datasheet for that), I have few LEDs with resistors connected to GPIO pins, two ~30cm wires that sit on table for input testing (resistors there too, of course) and Nokia DKU-5 data cable for USB-TTL serial console. If the board gets any ground, it's via this cable. But I don't see how my HW config is related to this issue. And I don't change this when I try different U-Boot's?! I don't have USB devices connected to host port and nothing to other USB port too. I use old 64MB SD card to help with booting (because of ubldr issues), not sure that matters, though. Thanks. From owner-freebsd-arm@FreeBSD.ORG Mon May 19 15:40:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6232F394 for ; Mon, 19 May 2014 15:40:36 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F1492799 for ; Mon, 19 May 2014 15:40:35 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id hn18so3646447igb.0 for ; Mon, 19 May 2014 08:40:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type :content-transfer-encoding:subject:message-id:date:to:mime-version; bh=M9PNyT8glzWHD5PiI2n9CwjeEXhKJIAN0++JRNDdEic=; b=ALDzHCZVtskn8kCNlkq8dGXZXBANNIeVbaQUUndMA355E7OTjHJj3gSRjYL2xJXnWV bhbPfsQAbJ8xA9I78+t22RdrEvHKmC+wf0FtksejOc4m1QXuZEXO5dSYp3ugH78R9Ri4 pjmR6JK92ZVq9nTPRV5Ee8vEdxh8HZ4TpcNA7kuU10FREbU62Hqc6/rSvlkSfzoEGAU6 Gnp/yor+KxmMjGBIrGN4YX2FSlNN6/PXCdiiM42NwU5vv5Ohi6gCVuG6NB3houKll4AA u6/APK7YoLeOYLDtI1uNGLlV6fS9u3gJsv9ubcQmDujyqCLSHctbLFZNzqS1suO9854h B8/Q== X-Gm-Message-State: ALoCoQnww6IGK21Ou2SxTATGRtvadbTOHdElyrLDa8cFzkBbv6Pw6jijSKygGp0m5kfBQSr6nGft X-Received: by 10.50.32.70 with SMTP id g6mr18244742igi.0.1400514034939; Mon, 19 May 2014 08:40:34 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id g2sm14605330igc.12.2014.05.19.08.40.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 08:40:34 -0700 (PDT) Sender: Warner Losh X-Google-Original-From: Warner Losh From: Warner Losh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: MK_ARM_EABI to retire in current Message-Id: Date: Mon, 19 May 2014 09:40:33 -0600 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 15:40:36 -0000 Greetings, MK_ARM_EABI is going to die in current. It is the default for all = platforms currently. I=92m eliminating it as a build option. It must die = because it invisibly (to uname) effects the ABI. So, to that end, I see two options: (1) Retire and remove oabi support. (2) Retain oabi support, but change its name to armo and armoeb. The rough consensus of arm developers I=92ve polled now, and in the = past, is that we just let oabi support die now that EABI support is = working for everybody. Before I pull the trigger on this, however, I must ask if anybody has a = problem with my doing option (1), and if so, what keeps you using oabi. Comments? Warner From owner-freebsd-arm@FreeBSD.ORG Mon May 19 16:50:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD0A1C6D for ; Mon, 19 May 2014 16:50:23 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F0A02E03 for ; Mon, 19 May 2014 16:50:23 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id x3so9329781qcv.38 for ; Mon, 19 May 2014 09:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=KQV/PXYE3trdDcx48cD/2ksxmlWdHzsv+RfFjq+1Yg4=; b=vGz2MBTqS1GFUB8cwSixISd95zsiBbA2M81s/X04FWNqtdaTeUiskvnAWAAao4r5RT DMi/ZqlpKnqdZc5727Y2hvGY3EDa6o35VrAPzzk25saGImTCxdLwMuqoZ6Eth5TBqsMI 7ygGRF/XtIdNusXIb91CmuwnHo5dueGLDsXNoBRd/SS80B8ms3t01EL/l5AUDTCWO9Tm QjGbddscHcDBeoJQWfr5fgPeh3IDy8eQLc2oEEcVOz4ap8lFQ1a5S0+htmi9bzs1cOQl WysnRFGMurbAPGTweHXPocnr/GHXg1gcxmiTVdeZtQ8Rs8newbZvE4LZYfn2YYYG7LGA p+MA== MIME-Version: 1.0 X-Received: by 10.224.47.130 with SMTP id n2mr49700599qaf.26.1400518221609; Mon, 19 May 2014 09:50:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Mon, 19 May 2014 09:50:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 May 2014 09:50:21 -0700 X-Google-Sender-Auth: YJTs9cMzs8Ry6Lx01q5NdCzfl_s Message-ID: Subject: Re: MK_ARM_EABI to retire in current From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 16:50:23 -0000 isn't eabi on the xscale still broken? -a On 19 May 2014 08:40, Warner Losh wrote: > Greetings, > > MK_ARM_EABI is going to die in current. It is the default for all platfor= ms currently. I=E2=80=99m eliminating it as a build option. It must die bec= ause it invisibly (to uname) effects the ABI. > > So, to that end, I see two options: > > (1) Retire and remove oabi support. > (2) Retain oabi support, but change its name to armo and armoeb. > > The rough consensus of arm developers I=E2=80=99ve polled now, and in the= past, is that we just let oabi support die now that EABI support is workin= g for everybody. > > Before I pull the trigger on this, however, I must ask if anybody has a p= roblem with my doing option (1), and if so, what keeps you using oabi. > > Comments? > > Warner > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Tue May 20 01:52:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85693FB0 for ; Tue, 20 May 2014 01:52:23 +0000 (UTC) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19DA82DFC for ; Tue, 20 May 2014 01:52:22 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id e53so52611eek.11 for ; Mon, 19 May 2014 18:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6m5qFlTaRK/Ng4HInw20eh4dmT/VHH8NBWzd2FlT+cQ=; b=pFGnW3pSxLYsm7mCXWFChoXdUwhzwUzF0jiyn1LF863g6dMe3eHlkY2YR/RPq2zJG+ ka5+Ek70VzuTYza3faIxlYp3Qc0SFblg1+tOvOo3h6MeA97do6R3MenQGvdDSdtyLYk3 3oqRrqc/zNr1lKC/tcEiL+C8XqMfT0tjE7A+b6rx5FXa+MpZK5eOukPWnh/ZYYLeFRSU W96E9irzxEa+Nnns4M5+XNIDtBXgJ/TKvYdBaUS4Mq+dHgYyzOjwL9QEd/e4GLVkjvfl iB9D5xigrhgpWEoVrOxiYRI8+V8eEpry2LW9zbH5cGvvO5EiS13QzpblzEzObLmV5sWa eJaQ== X-Received: by 10.14.202.137 with SMTP id d9mr16232042eeo.10.1400550741259; Mon, 19 May 2014 18:52:21 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id e44sm77916eeg.24.2014.05.19.18.52.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 18:52:19 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537AB550.2090401@hot.ee> Date: Tue, 20 May 2014 04:52:16 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Sulev-Madis Silber (ketas)" Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) References: <537A050E.3040804@hot.ee> In-Reply-To: <537A050E.3040804@hot.ee> X-TagToolbar-Keys: D20140520045216309 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 01:52:23 -0000 On 2014-05-19 16:20, Sulev-Madis Silber (ketas) wrote: > Hello. > > Although maybe I could write this as reply to some other message, I feel > like it might deserve separate one. > > I use U-Boot 2014.04 which sets CPU frequency to 1GHz, which seems nice. > Apart from inability to find eMMC in ubldr (SD card is always fine), now > I get whole different issues here. With 2013.04, I get occasional eMMC > failure I mentioned earlier. With 2014.04, it's very hard to get SD > devices detected at all. And I get all sorts of weird errors (megabytes > of boot logs from serial if anyone wishes to see). I'm aware how HW > clock changes can affect things like this, but I'm not exactly sure > where and what happens when this is done. If I boot with 2013.04, it's > ok again, if I switch to 2014.04 again, it's ok again for a while. It > really feels like it's overheating. After a while, it gets extremely > hard to get thing booted up. Both devices sometimes detect and sometimes > not. I get things like "no compatible cards found on bus" (mmc 0/1), or > things like "card at relative address x lost". Tried adding delays like > suggested earlier, but that doesn't help and now the issue seems > different. I get no other issues. System is very stable once it's booted > up. There are no hangs, panics... Everything works. I must mention that > I always use latest CURRENT. I didn't find a way to make kernel reboot > system when root mount fails, so I manually patched that option in. Last > time I got 11 failures before it booted up with both SD and eMMC found > (they don't fail same way every time, sometimes SD is missing, often > eMMC is missing). > > What would somebody else think about such issues? I don't have > experience in HW dev, I can only guess what goes wrong. And again, if it > boots, it works. And no component on BBB gets too warm to hold finger > there for long time, too (if that matters). I have 5V 2.5A PSU powering > it (but the PMIC should fail if voltage drops too much, etc, I read the > datasheet for that), I have few LEDs with resistors connected to GPIO > pins, two ~30cm wires that sit on table for input testing (resistors > there too, of course) and Nokia DKU-5 data cable for USB-TTL serial > console. If the board gets any ground, it's via this cable. But I don't > see how my HW config is related to this issue. And I don't change this > when I try different U-Boot's?! I don't have USB devices connected to > host port and nothing to other USB port too. I use old 64MB SD card to > help with booting (because of ubldr issues), not sure that matters, though. > > Thanks. > Now I have patch too. I feel much better now. It seems to fix everything. I'm sure that not all of those "delay"'s are needed. I got tired of failures and just put one into each place that seemed to need some waiting before continue. The side effect is that mmc detection doesn't take several seconds now, it's near instant. It also feels like device read speed is faster but I'm not entirely sure about that. So, what happened here? Slower CPU acted as some kind of limiter by itself? What's correct solution here? I'm only guessing but it at least works now. I don't think I've lost devices after this change, both SD card and eMMC device are always there. I should disable reboot on rootfs mount fail to fully confirm it. However that BUSTEST_W still gives error. Now, only ubldr-no-eMMC fix is needed. And / or U-Boot fix? From owner-freebsd-arm@FreeBSD.ORG Tue May 20 01:57:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CC1EA1 for ; Tue, 20 May 2014 01:57:15 +0000 (UTC) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 271F32E15 for ; Tue, 20 May 2014 01:57:15 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id e51so49916eek.38 for ; Mon, 19 May 2014 18:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Z9W6qHagUah35/GcMGvn5ONxwhz78ahcgC0UttVCEg4=; b=tTPY0bfFAsejdqot3wRmlnHiGEnWD2RZCtI0BltuTPCrOeV6/+NJBu3kg8VU0juhC7 2PYyOYiq+fOrsxoVOH92IiVnwAB6qq6qQoaVMbPzqjjV++aSsz/UMY5R+Zi6LkTYdbsA FxwQbxmJ+mkwOGfBmCAWkyH8wf5ogG0SyYzdUhjWZBQkxZQ258W08RaS9igTpB9NZ36L EtBC93E0GAz1lucQhUwBd/5+ayaqGH5NQxDGrwLGxODjEDYROEt+lv+V167WxQd3l93D hbIOOXTqzAtIoDF+1Tu+OU8LDF3imXS4ZqjklCEeag5DbffuRqMgGLn68twKArG9sm+u tCbA== X-Received: by 10.14.94.136 with SMTP id n8mr33843149eef.7.1400551033195; Mon, 19 May 2014 18:57:13 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id 44sm89098eer.35.2014.05.19.18.57.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 18:57:11 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537AB675.1020006@hot.ee> Date: Tue, 20 May 2014 04:57:09 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Sulev-Madis Silber (ketas)" Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) References: <537A050E.3040804@hot.ee> <537AB550.2090401@hot.ee> In-Reply-To: <537AB550.2090401@hot.ee> X-TagToolbar-Keys: D20140520045709764 Content-Type: multipart/mixed; boundary="------------050109040000040606020904" Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 01:57:15 -0000 This is a multi-part message in MIME format. --------------050109040000040606020904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2014-05-20 04:52, Sulev-Madis Silber (ketas) wrote: > On 2014-05-19 16:20, Sulev-Madis Silber (ketas) wrote: >> Hello. >> >> Although maybe I could write this as reply to some other message, I feel >> like it might deserve separate one. >> >> I use U-Boot 2014.04 which sets CPU frequency to 1GHz, which seems nice. >> Apart from inability to find eMMC in ubldr (SD card is always fine), now >> I get whole different issues here. With 2013.04, I get occasional eMMC >> failure I mentioned earlier. With 2014.04, it's very hard to get SD >> devices detected at all. And I get all sorts of weird errors (megabytes >> of boot logs from serial if anyone wishes to see). I'm aware how HW >> clock changes can affect things like this, but I'm not exactly sure >> where and what happens when this is done. If I boot with 2013.04, it's >> ok again, if I switch to 2014.04 again, it's ok again for a while. It >> really feels like it's overheating. After a while, it gets extremely >> hard to get thing booted up. Both devices sometimes detect and sometimes >> not. I get things like "no compatible cards found on bus" (mmc 0/1), or >> things like "card at relative address x lost". Tried adding delays like >> suggested earlier, but that doesn't help and now the issue seems >> different. I get no other issues. System is very stable once it's booted >> up. There are no hangs, panics... Everything works. I must mention that >> I always use latest CURRENT. I didn't find a way to make kernel reboot >> system when root mount fails, so I manually patched that option in. Last >> time I got 11 failures before it booted up with both SD and eMMC found >> (they don't fail same way every time, sometimes SD is missing, often >> eMMC is missing). >> >> What would somebody else think about such issues? I don't have >> experience in HW dev, I can only guess what goes wrong. And again, if it >> boots, it works. And no component on BBB gets too warm to hold finger >> there for long time, too (if that matters). I have 5V 2.5A PSU powering >> it (but the PMIC should fail if voltage drops too much, etc, I read the >> datasheet for that), I have few LEDs with resistors connected to GPIO >> pins, two ~30cm wires that sit on table for input testing (resistors >> there too, of course) and Nokia DKU-5 data cable for USB-TTL serial >> console. If the board gets any ground, it's via this cable. But I don't >> see how my HW config is related to this issue. And I don't change this >> when I try different U-Boot's?! I don't have USB devices connected to >> host port and nothing to other USB port too. I use old 64MB SD card to >> help with booting (because of ubldr issues), not sure that matters, though. >> >> Thanks. >> > > > Now I have patch too. I feel much better now. It seems to fix > everything. I'm sure that not all of those "delay"'s are needed. I got > tired of failures and just put one into each place that seemed to need > some waiting before continue. The side effect is that mmc detection > doesn't take several seconds now, it's near instant. It also feels like > device read speed is faster but I'm not entirely sure about that. So, > what happened here? Slower CPU acted as some kind of limiter by itself? > What's correct solution here? I'm only guessing but it at least works > now. I don't think I've lost devices after this change, both SD card and > eMMC device are always there. I should disable reboot on rootfs mount > fail to fully confirm it. However that BUSTEST_W still gives error. Now, > only ubldr-no-eMMC fix is needed. And / or U-Boot fix? > Early "Send"... patch: http://ketas.si.pri.ee/mmc-detection-hacks2.diff (and attached) --------------050109040000040606020904 Content-Type: text/plain; charset=ISO-8859-15; name="mmc-detection-hacks2.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mmc-detection-hacks2.diff" SW5kZXg6IHN5cy9kZXYvbW1jL21tYy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvbW1j L21tYy5jCShyZXZpc2lvbiAyNjY0NDIpCisrKyBzeXMvZGV2L21tYy9tbWMuYwkod29ya2lu ZyBjb3B5KQpAQCAtNDE0LDYgKzQxNCw3IEBACiAJaW50IGVycjsKIAogCWRvIHsKKwkJbW1j X21zX2RlbGF5KDEwKTsKIAkJbWVtc2V0KCZtcmVxLCAwLCBzaXplb2YobXJlcSkpOwogCQlt ZW1zZXQoY21kLT5yZXNwLCAwLCBzaXplb2YoY21kLT5yZXNwKSk7CiAJCWNtZC0+cmV0cmll cyA9IDA7IC8qIFJldHJpZXMgZG9uZSBoZXJlLCBub3QgaW4gaGFyZHdhcmUuICovCkBAIC00 MzYsNiArNDM3LDcgQEAKIAlpbnQgZXJyOwogCiAJZG8geworCQltbWNfbXNfZGVsYXkoMTAp OwogCQltZW1zZXQoJmFwcGNtZCwgMCwgc2l6ZW9mKGFwcGNtZCkpOwogCQlhcHBjbWQub3Bj b2RlID0gTU1DX0FQUF9DTUQ7CiAJCWFwcGNtZC5hcmcgPSByY2EgPDwgMTY7CkBAIC00NjUs NiArNDY3LDcgQEAKIAlzdHJ1Y3QgbW1jX2NvbW1hbmQgY21kOwogCWludCBlcnI7CiAKKwlt bWNfbXNfZGVsYXkoMTApOwogCW1lbXNldCgmY21kLCAwLCBzaXplb2YoY21kKSk7CiAJY21k Lm9wY29kZSA9IG9wY29kZTsKIAljbWQuYXJnID0gYXJnOwpAQCAtNDg4LDYgKzQ5MSw3IEBA CiAJZGV2aWNlX3QgZGV2OwogCXN0cnVjdCBtbWNfY29tbWFuZCBjbWQ7CiAJCisJbW1jX21z X2RlbGF5KDEwKTsKIAlkZXYgPSBzYy0+ZGV2OwogCW1tY2JyX3NldF9jaGlwX3NlbGVjdChk ZXYsIGNzX2hpZ2gpOwogCW1tY2JyX3VwZGF0ZV9pb3MoZGV2KTsKQEAgLTc2OSw4ICs3NzMs MTUgQEAKIAkJZGF0YS5kYXRhID0gcDg7CiAJCWRhdGEubGVuID0gODsKIAkJZGF0YS5mbGFn cyA9IE1NQ19EQVRBX1dSSVRFOwotCQltbWNfd2FpdF9mb3JfY21kKHNjLCAmY21kLCAwKTsK LQkJCisJCWVyciA9IG1tY193YWl0X2Zvcl9jbWQoc2MsICZjbWQsIDApOworCQlpZiAoZXJy ICE9IDApIHsKKwkJCWRldmljZV9wcmludGYoc2MtPmRldiwgIkJVU1RFU1RfVyBlcnIgJWRc biIsIGVycik7CisJCQltbWNfbXNfZGVsYXkoMTApOworCQkJZXJyID0gbW1jX3dhaXRfZm9y X2NtZChzYywgJmNtZCwgQ01EX1JFVFJJRVMpOworCQkJaWYgKGVyciAhPSAwKQorCQkJCWRl dmljZV9wcmludGYoc2MtPmRldiwgIkJVU1RFU1RfVyBlcnIgJWQgKHJldHJpZWQgJWQgdGlt ZXMpXG4iLCBlcnIsIENNRF9SRVRSSUVTKTsKKwkJfQorCiAJCW1lbXNldCgmY21kLCAwLCBz aXplb2YoY21kKSk7CiAJCW1lbXNldCgmZGF0YSwgMCwgc2l6ZW9mKGRhdGEpKTsKIAkJY21k Lm9wY29kZSA9IE1NQ19CVVNURVNUX1I7CkBAIC03ODIsMTAgKzc5MywxOSBAQAogCQlkYXRh LmxlbiA9IDg7CiAJCWRhdGEuZmxhZ3MgPSBNTUNfREFUQV9SRUFEOwogCQllcnIgPSBtbWNf d2FpdF9mb3JfY21kKHNjLCAmY21kLCAwKTsKLQkJCisJCWlmIChlcnIgIT0gMCkgeworCQkJ ZGV2aWNlX3ByaW50ZihzYy0+ZGV2LCAiQlVTVEVTVF9SIGVyciAlZFxuIiwgZXJyKTsKKwkJ CW1tY19tc19kZWxheSgxMCk7CisJCQllcnIgPSBtbWNfd2FpdF9mb3JfY21kKHNjLCAmY21k LCBDTURfUkVUUklFUyk7CisJCQlpZiAoZXJyICE9IDApCisJCQkJZGV2aWNlX3ByaW50Zihz Yy0+ZGV2LCAiQlVTVEVTVF9SIGVyciAlZCAocmV0cmllZCAlZCB0aW1lcylcbiIsIGVyciwg Q01EX1JFVFJJRVMpOworCQl9CisKKwkJZGV2aWNlX3ByaW50ZihzYy0+ZGV2LCAicmVhZCAl MDJ4ICUwMnggJTAyeCAlMDJ4ICUwMnggJTAyeCAlMDJ4ICUwMnhcbiIsCisJCQlidWZbMF0s IGJ1ZlsxXSwgYnVmWzJdLCBidWZbM10sIGJ1Zls0XSwgYnVmWzVdLCBidWZbNl0sIGJ1Zls3 XSk7CisKIAkJbW1jYnJfc2V0X2J1c193aWR0aChzYy0+ZGV2LCBidXNfd2lkdGhfMSk7CiAJ CW1tY2JyX3VwZGF0ZV9pb3Moc2MtPmRldik7Ci0KIAkJaWYgKGVyciA9PSBNTUNfRVJSX05P TkUgJiYgbWVtY21wKGJ1ZiwgcDhvaywgOCkgPT0gMCkKIAkJCXJldHVybiAoYnVzX3dpZHRo XzgpOwogCX0KQEAgLTEyNjQsNiArMTI4NCw3IEBACiAJaWYgKGJvb3R2ZXJib3NlIHx8IG1t Y19kZWJ1ZykKIAkJZGV2aWNlX3ByaW50ZihzYy0+ZGV2LCAiUHJvYmluZyBjYXJkc1xuIik7 CiAJd2hpbGUgKDEpIHsKKwkJbW1jX21zX2RlbGF5KDEwKTsKIAkJZXJyID0gbW1jX2FsbF9z ZW5kX2NpZChzYywgcmF3X2NpZCk7CiAJCWlmIChlcnIgPT0gTU1DX0VSUl9USU1FT1VUKQog CQkJYnJlYWs7CkBAIC0xNTg2LDcgKzE2MDcsOSBAQAogCQkgICAgKGVyciA/IDAgOiBNTUNf T0NSX0NDUykgfCBtbWNicl9nZXRfb2NyKGRldiksIE5VTEwpOwogCX0gZWxzZQogCQltbWNf c2VuZF9vcF9jb25kKHNjLCBtbWNicl9nZXRfb2NyKGRldiksIE5VTEwpOworCW1tY19tc19k ZWxheSgxMCk7CiAJbW1jX2Rpc2NvdmVyX2NhcmRzKHNjKTsKKwltbWNfbXNfZGVsYXkoMTAp OwogCW1tY19yZXNjYW5fY2FyZHMoc2MpOwogCiAJbW1jYnJfc2V0X2J1c19tb2RlKGRldiwg cHVzaHB1bGwpOwo= --------------050109040000040606020904-- From owner-freebsd-arm@FreeBSD.ORG Tue May 20 02:29:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7086F38D for ; Tue, 20 May 2014 02:29:02 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E9D32026 for ; Tue, 20 May 2014 02:29:01 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bj1so6586587pad.41 for ; Mon, 19 May 2014 19:28:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=/cSFxILNOg9cK6B417ttS0GVx2GOol4jWnvJWhxc3sU=; b=BiYJEYxSuDpM/9jAwkhJD/+eblABPP5hLAGcK2O6TB2kyfhddR88scnNuQ2UN6JnKf 8ieOAj7wWZpqpT0hYcXSEIsEpjiv+jE+PVUgOaSYPSo0Fq/4nxxp2DSSSso7hyFF3iJM 88ZKSGoFh3EKD3ib8Er8InG4bBp3fbM85QL3rELP3qOC+2XNaWBIMfvbYFPSyQVIy0sj VZvgvEzZmfzWf6VdDJ+mOjtin4V7d2HEI5K3+CZImmaHvFIUhCBccS/3mExmDyi+Wtrk qw72QJD+sEAwlm/PPv5zcDC15NmHyPoPOhb46iiCSCHxioP/+OBJ6EQYdVQPG6WDhUPy DsHg== X-Gm-Message-State: ALoCoQkfYHOlp+fGGT00Bt0dLI4Erp7Gi9m319V0E7625h7KuRX53Wbg2cAGigtc3BMxtafhDUlc X-Received: by 10.66.65.225 with SMTP id a1mr35839436pat.139.1400552934870; Mon, 19 May 2014 19:28:54 -0700 (PDT) Received: from [10.64.26.239] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id pr4sm149307pbb.53.2014.05.19.19.28.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 19:28:53 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_38E5F53C-2EE7-4188-B2F9-E43B279E0A36"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Warner Losh In-Reply-To: <537AB675.1020006@hot.ee> Date: Mon, 19 May 2014 20:28:51 -0600 Message-Id: <024F43EF-E299-413E-AE42-2507AEDD0886@bsdimp.com> References: <537A050E.3040804@hot.ee> <537AB550.2090401@hot.ee> <537AB675.1020006@hot.ee> To: "Sulev-Madis Silber (ketas)" X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 02:29:02 -0000 --Apple-Mail=_38E5F53C-2EE7-4188-B2F9-E43B279E0A36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 19, 2014, at 7:57 PM, Sulev-Madis Silber (ketas) = wrote: > On 2014-05-20 04:52, Sulev-Madis Silber (ketas) wrote: >> On 2014-05-19 16:20, Sulev-Madis Silber (ketas) wrote: >>> Hello. >>>=20 >>> Although maybe I could write this as reply to some other message, I = feel >>> like it might deserve separate one. >>>=20 >>> I use U-Boot 2014.04 which sets CPU frequency to 1GHz, which seems = nice. >>> Apart from inability to find eMMC in ubldr (SD card is always fine), = now >>> I get whole different issues here. With 2013.04, I get occasional = eMMC >>> failure I mentioned earlier. With 2014.04, it's very hard to get SD >>> devices detected at all. And I get all sorts of weird errors = (megabytes >>> of boot logs from serial if anyone wishes to see). I'm aware how HW >>> clock changes can affect things like this, but I'm not exactly sure >>> where and what happens when this is done. If I boot with 2013.04, = it's >>> ok again, if I switch to 2014.04 again, it's ok again for a while. = It >>> really feels like it's overheating. After a while, it gets extremely >>> hard to get thing booted up. Both devices sometimes detect and = sometimes >>> not. I get things like "no compatible cards found on bus" (mmc 0/1), = or >>> things like "card at relative address x lost". Tried adding delays = like >>> suggested earlier, but that doesn't help and now the issue seems >>> different. I get no other issues. System is very stable once it's = booted >>> up. There are no hangs, panics... Everything works. I must mention = that >>> I always use latest CURRENT. I didn't find a way to make kernel = reboot >>> system when root mount fails, so I manually patched that option in. = Last >>> time I got 11 failures before it booted up with both SD and eMMC = found >>> (they don't fail same way every time, sometimes SD is missing, often >>> eMMC is missing). >>>=20 >>> What would somebody else think about such issues? I don't have >>> experience in HW dev, I can only guess what goes wrong. And again, = if it >>> boots, it works. And no component on BBB gets too warm to hold = finger >>> there for long time, too (if that matters). I have 5V 2.5A PSU = powering >>> it (but the PMIC should fail if voltage drops too much, etc, I read = the >>> datasheet for that), I have few LEDs with resistors connected to = GPIO >>> pins, two ~30cm wires that sit on table for input testing (resistors >>> there too, of course) and Nokia DKU-5 data cable for USB-TTL serial >>> console. If the board gets any ground, it's via this cable. But I = don't >>> see how my HW config is related to this issue. And I don't change = this >>> when I try different U-Boot's?! I don't have USB devices connected = to >>> host port and nothing to other USB port too. I use old 64MB SD card = to >>> help with booting (because of ubldr issues), not sure that matters, = though. >>>=20 >>> Thanks. >>>=20 >>=20 >>=20 >> Now I have patch too. I feel much better now. It seems to fix >> everything. I'm sure that not all of those "delay"'s are needed. I = got >> tired of failures and just put one into each place that seemed to = need >> some waiting before continue. The side effect is that mmc detection >> doesn't take several seconds now, it's near instant. It also feels = like >> device read speed is faster but I'm not entirely sure about that. So, >> what happened here? Slower CPU acted as some kind of limiter by = itself? >> What's correct solution here? I'm only guessing but it at least works >> now. I don't think I've lost devices after this change, both SD card = and >> eMMC device are always there. I should disable reboot on rootfs mount >> fail to fully confirm it. However that BUSTEST_W still gives error. = Now, >> only ubldr-no-eMMC fix is needed. And / or U-Boot fix? >>=20 >=20 >=20 > Early "Send"... >=20 > patch: >=20 > http://ketas.si.pri.ee/mmc-detection-hacks2.diff Wow! That=92s a lot of added 10ms delays=85 Do we have a theory of the = crime for why they are needed? Usually they suggest to me that we=92re doing = something wrong (either not checking the right bits in the bridge, having a fixed = retry count rather than a timed limit and having some bridges fail more slowly than = others so the delays are effecting the same thing). Warner --Apple-Mail=_38E5F53C-2EE7-4188-B2F9-E43B279E0A36 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTer3jAAoJEGwc0Sh9sBEAVFsP/A5retE8sUNyre8C1tNH27Sc 6reKp6LZAi5Vyzfd+s3dJy8Y8icziANWFeFc2Jb0Nh3967LaFo5MJ9Y8BrCYsLwY Zd2/tBaiv53L/dX9JTV/kn+QU0QUqXFSB6ZH+rloBYLN3A/pnKArhNH1edoS/x8u 1Sm3TF5LUZ0oJjp2Tz58em/bc4eQrp+traue0sTCHjx/qgCaeub6DMnRyRTebHUc 618R+xh1Wm0I8ZrhrQqVty72GT0aZN+KQAtvzl2OmU2qIjeOf4VoVTf5R2HYUwJm X66Sa+gWxFRfxemNrCeezAf8z9yObKfWO2Z0jPrMHq1pETw4hvtZjL4qTrBNrxND Rw0RHTARu07d7qUkDKO/HG7avec6M/PJQyuzZoZ44kIqZ4uIZdmlJ+EpLmmUy/kG op4IcWRa87e/SnpmkXt8Ls101Y1U3hjVJhjO8ql1a04XBzFqqgtzv4ob2oo9Exwj vxjUICjTF28RCEfeq/8ZEQWZGyvNt1+fd5INjWXxlaO2HO1xexg4KUHVmV3qFeiE REO/8+uRuB3Y6MX/eJ5tuAqg36ebBwpUseluz+vxYdenvz/p6vBO8Ph/LYqtvTrJ MoJDfuK0npiIizaqsi6i75+4TvRZYXEtXDojyy47I9Bneor5CVWR629ls1RM9mX1 36bDGY+Nni9wPJxCGu2N =EMQ1 -----END PGP SIGNATURE----- --Apple-Mail=_38E5F53C-2EE7-4188-B2F9-E43B279E0A36-- From owner-freebsd-arm@FreeBSD.ORG Tue May 20 02:39:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67C85493 for ; Tue, 20 May 2014 02:39:49 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0132220FC for ; Tue, 20 May 2014 02:39:48 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u56so6429878wes.9 for ; Mon, 19 May 2014 19:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=syaRjb4SCLJyN80GgvAdHNM/pT1KT05UFX1FFTHn9Cs=; b=PBybUwZuG8iWsfXItTz7oib9z++uME8ue2OtxaSMSAd3Urdd5qCp8TGSBPpzK8IbHB lBD4YEcuL+0jmaqFDKuIIyWY9IwXLtcOChsERtr3IUHZrQnW9y7HHaHXdYk6YTyutPg3 OS5g9H+7cRfhvNW9UujMrhm5VbD19KPGCAOUlI9K3jQhP1NKQOXm0KR5makvhs6A4jyF gIYDNjzxf/2w9NMR0eufEwJlebMYr+MUQV2aIokH4QZsAZr9AjhTz46v1VNEWQtXNqRt 2tSH0Lxyhq/7x8gFkXTyOkXhilKrC3Mpdk+j0eRBmV64h7zFf7fgOxYVjoZRa8JbBmq8 tS3Q== MIME-Version: 1.0 X-Received: by 10.194.57.38 with SMTP id f6mr7452475wjq.59.1400553587303; Mon, 19 May 2014 19:39:47 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Mon, 19 May 2014 19:39:47 -0700 (PDT) In-Reply-To: <024F43EF-E299-413E-AE42-2507AEDD0886@bsdimp.com> References: <537A050E.3040804@hot.ee> <537AB550.2090401@hot.ee> <537AB675.1020006@hot.ee> <024F43EF-E299-413E-AE42-2507AEDD0886@bsdimp.com> Date: Mon, 19 May 2014 22:39:47 -0400 Message-ID: Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Winston Smith To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 02:39:49 -0000 On Mon, May 19, 2014 at 10:28 PM, Warner Losh wrote: > Wow! That=E2=80=99s a lot of added 10ms delays=E2=80=A6 Do we have a the= ory of the crime > for why they are needed? Usually they suggest to me that we=E2=80=99re do= ing something > wrong (either not checking the right bits in the bridge, having a fixed r= etry count > rather than a timed limit and having some bridges fail more slowly than o= thers > so the delays are effecting the same thing). It's a good start (since the BBB is really flakey at 1Ghz), but yes, more delays aren't good! For what it's worth, I'm working in parallel with both FreeBSD and Debian Wheezy images on the BBB, and it is quite apparent that the BBB running FreeBSD is *much* slower to boot than the BBB running Debian; which currently boots to the login prompt in about 15 seconds from power up. FreeBSD has a 15-20 second delay just to detect the eMMC, let alone everything else. Comparatively, my x64 FreeBSD VM boots much more quickly than my Ubuntu x64= VM. -W. From owner-freebsd-arm@FreeBSD.ORG Tue May 20 03:36:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEF7C10D for ; Tue, 20 May 2014 03:36:25 +0000 (UTC) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50A3425E2 for ; Tue, 20 May 2014 03:36:25 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id e51so73428eek.10 for ; Mon, 19 May 2014 20:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jGPdCx/oaERbRfN+kfnkt4JH6ZLSVzwLHKRHrbBVXJ0=; b=qkZrlVOEaG6/GnurAj/Dta9kaorPUb7bToGqho5CKotmM2GS8awItslDr2p0G8N0yn oEONy0z6i1cLkNAIP0y+3ZVkzXfgFTB+fQ3dbho49+BTMgjIJPUird/7XTV35n5ViWxG JQomJPChxdA6V7A4kVBBqhAyEkXmUTL8xFme2iBqh8fS+ssDmUK5bUt5kHh9njSJO6RY HuQjM7kMzVdkxvAfrjnmnvJBNndP8wJblAL5tutpiaQnZF6YDA7DL95cyRzv4/3nJorr ET8mGkpN8+GwK0ck6tHHAl7uX9ITlzDnkbnDAILaqNsYR2wFfwocOImyASRkXZkWecGB DOVg== X-Received: by 10.14.104.9 with SMTP id h9mr31071185eeg.4.1400556982785; Mon, 19 May 2014 20:36:22 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id x43sm519863eeo.18.2014.05.19.20.36.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 20:36:21 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537ACDB2.9080808@hot.ee> Date: Tue, 20 May 2014 06:36:18 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Winston Smith Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) References: <537A050E.3040804@hot.ee> <537AB550.2090401@hot.ee> <537AB675.1020006@hot.ee> <024F43EF-E299-413E-AE42-2507AEDD0886@bsdimp.com> In-Reply-To: X-TagToolbar-Keys: D20140520063618397 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 03:36:25 -0000 On 2014-05-20 05:39, Winston Smith wrote: > On Mon, May 19, 2014 at 10:28 PM, Warner Losh wrote: >> Wow! That’s a lot of added 10ms delays… Do we have a theory of the crime >> for why they are needed? Usually they suggest to me that we’re doing something >> wrong (either not checking the right bits in the bridge, having a fixed retry count >> rather than a timed limit and having some bridges fail more slowly than others >> so the delays are effecting the same thing). > > It's a good start (since the BBB is really flakey at 1Ghz), but yes, > more delays aren't good! > > For what it's worth, I'm working in parallel with both FreeBSD and > Debian Wheezy images on the BBB, and it is quite apparent that the BBB > running FreeBSD is *much* slower to boot than the BBB running Debian; > which currently boots to the login prompt in about 15 seconds from > power up. FreeBSD has a 15-20 second delay just to detect the eMMC, > let alone everything else. > > Comparatively, my x64 FreeBSD VM boots much more quickly than my Ubuntu x64 VM. > > -W. > "really flakey" sounds like "unstable, panics 1000 times a day". I don't see any of that here (as of 11.0-CURRENT r266442). Boot, hmm... yea, 1min (just measured) to fully boot up and connect to server (I'm using ethernet, DHCP, loader boot delay = 3, huge Perl program) might be too slow if you have some embedded system which constantly loses power or something... I haven't tried to do any boot time optimizations yet. Compress kernel? Compress userland? Execute something in parallel on init (NOTE: *DON'T* even think about porting Linux init replacements here)? Use rescue-like static binary? Heavily customize / patch kernel? Use own init? Use rootfs inside kernel? Actually I guess many people might think like me... "HELL, optimizing boot time of 1min?! I have more important tasks to do than this". From owner-freebsd-arm@FreeBSD.ORG Tue May 20 04:13:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 278E1436 for ; Tue, 20 May 2014 04:13:31 +0000 (UTC) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E907A28A7 for ; Tue, 20 May 2014 04:13:30 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id lj1so6658213pab.36 for ; Mon, 19 May 2014 21:13:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=A2YnWwXv9cq2lfscCYA1J0pAogQPrGlemCzxq33bU6c=; b=TxNMaU7K4A74PgH53WiTeMiDjL9a/5uoX2DhtysCLoOctRDhCCOOChUCVX4mCTXlCF icxZaulp0gAyvpFpNLADj9xqXOd1DP+jLjyIyEVCyJci9KcJarAgTmcGvJb03m7KTrMW pwipRXNPXFLv9l9t9d39y2h7lJwzkz0RS5+EanDhv03njNO5maei3mD8UUU0cxu3bZe7 GQUQPXwD+STzOeaWq/CB89KKRZ6Z9vDmEq2GZxV0N/4jG+Gllc8lLURp8YYc+MWqPxK/ 72uHdRkDjpy07nxakzi7Dzw/nC7hTHgTtXx5igxU08PBTvMUOHHJ4Izy13lJ7VqZgJuJ PtRg== X-Gm-Message-State: ALoCoQnY1lIGMfX2UFcJ32vtoepg4aDlPU+O1PY+jB8ltp/TdWzgHWMEzUlMh5GlaZ8tPWT6LfJI X-Received: by 10.67.29.204 with SMTP id jy12mr8279117pad.37.1400558879422; Mon, 19 May 2014 21:07:59 -0700 (PDT) Received: from [10.64.26.239] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id gu11sm498532pbd.38.2014.05.19.21.07.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 21:07:53 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_8B59F4D9-69FC-4DA7-82CB-E9C8F74E21FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Warner Losh In-Reply-To: <537ACDB2.9080808@hot.ee> Date: Mon, 19 May 2014 22:07:52 -0600 Message-Id: References: <537A050E.3040804@hot.ee> <537AB550.2090401@hot.ee> <537AB675.1020006@hot.ee> <024F43EF-E299-413E-AE42-2507AEDD0886@bsdimp.com> <537ACDB2.9080808@hot.ee> To: "Sulev-Madis Silber (ketas)" X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 04:13:31 -0000 --Apple-Mail=_8B59F4D9-69FC-4DA7-82CB-E9C8F74E21FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 19, 2014, at 9:36 PM, Sulev-Madis Silber (ketas) = wrote: > On 2014-05-20 05:39, Winston Smith wrote: >> On Mon, May 19, 2014 at 10:28 PM, Warner Losh wrote: >>> Wow! That=92s a lot of added 10ms delays=85 Do we have a theory of = the crime >>> for why they are needed? Usually they suggest to me that we=92re = doing something >>> wrong (either not checking the right bits in the bridge, having a = fixed retry count >>> rather than a timed limit and having some bridges fail more slowly = than others >>> so the delays are effecting the same thing). >>=20 >> It's a good start (since the BBB is really flakey at 1Ghz), but yes, >> more delays aren't good! >>=20 >> For what it's worth, I'm working in parallel with both FreeBSD and >> Debian Wheezy images on the BBB, and it is quite apparent that the = BBB >> running FreeBSD is *much* slower to boot than the BBB running Debian; >> which currently boots to the login prompt in about 15 seconds from >> power up. FreeBSD has a 15-20 second delay just to detect the eMMC, >> let alone everything else. >>=20 >> Comparatively, my x64 FreeBSD VM boots much more quickly than my = Ubuntu x64 VM. >>=20 >> -W. >>=20 >=20 >=20 > "really flakey" sounds like "unstable, panics 1000 times a day". I = don't > see any of that here (as of 11.0-CURRENT r266442). >=20 > Boot, hmm... yea, 1min (just measured) to fully boot up and connect to > server (I'm using ethernet, DHCP, loader boot delay =3D 3, huge Perl > program) might be too slow if you have some embedded system which > constantly loses power or something... I haven't tried to do any boot > time optimizations yet. Compress kernel? Compress userland? Execute > something in parallel on init (NOTE: *DON'T* even think about porting > Linux init replacements here)? Use rescue-like static binary? Heavily > customize / patch kernel? Use own init? Use rootfs inside kernel? > Actually I guess many people might think like me... "HELL, optimizing > boot time of 1min?! I have more important tasks to do than this=94. Make MMC faster, and a lot of this will go away. When I was doing Atmel, I got more milage out of optimizing the I/O path for slow boots than I = did for just about anything else. Another quick hack: delete all files in /etc/rc.d that aren=92t used. Warner --Apple-Mail=_8B59F4D9-69FC-4DA7-82CB-E9C8F74E21FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTetUYAAoJEGwc0Sh9sBEASacP/1QMabYYqfMhPsQ0bsMYA9q2 Dkr0JhSeHtp9KeLWMfezjfCYcrhJBJY+VL1RBj50dDXtNyYYXDrUtGL7c1TzhbTp tAXUnVyutwxaD10HSskxA0EVJlPY6wfZxSMdGzT1FI2ZJw1sqzUQEyimwaIWJX4A S/70Ce5SnqSSBsTPwk1d4YHFzd3C7GYHApHQ/NmP5YNgAhAC30h/VY+15HWkM78j K7lUKm9dkbvP+94hOrHoTaq/BuVgXSu1LsthOTzzWa8ZJZHQlddp0kU4deb5DkZM xrW9y2IDopm9LSkBR6cBKYNHouE01nVeO2FLAwf3wVWkdFxS1TLkL5rqcBE1A86F CoJzwI23jXlMqKAd1Bw4ymEnGYTTA3fuUsn9mFUI5PdDGkJakTFp2R/74DQQpxe8 vExAkrOfKUv1U2gp+TyfULuhu4Zhv6anrqpWrCnPo6jyyHFmzlssqydrUTlw4Jtx 2xHzD7kK+ASVNP815+jswtGokQC6onPxiFXKkfWF+ZvuwD0T++BN0c0IJO2Oje7k d0rdPT4JXaptNsJepIH+Rc1tYdQUoqM1EWOjuqLaC4djfZK1IcmQMMf1rM+QyX5V r5p6lY5braH/doSiM2F//hRijPmTAWq6jPwogDDLmtPJ/5c+XPD/08F4bY5ihv// TmRrkfDlQwHJtAnI2eXh =5qoi -----END PGP SIGNATURE----- --Apple-Mail=_8B59F4D9-69FC-4DA7-82CB-E9C8F74E21FC-- From owner-freebsd-arm@FreeBSD.ORG Tue May 20 06:06:47 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A13E7E5; Tue, 20 May 2014 06:06:47 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 785AB2FF9; Tue, 20 May 2014 06:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4K66llw087138; Tue, 20 May 2014 06:06:47 GMT (envelope-from jmg@freefall.freebsd.org) Received: (from jmg@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4K66kNM087137; Tue, 20 May 2014 06:06:46 GMT (envelope-from jmg) Date: Tue, 20 May 2014 06:06:46 GMT Message-Id: <201405200606.s4K66kNM087137@freefall.freebsd.org> To: Meyser@xenet.de, jmg@FreeBSD.org, freebsd-arm@FreeBSD.org From: jmg@FreeBSD.org Subject: Re: arm/182060: make buildworld fails on Raspberry PI X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 06:06:47 -0000 Synopsis: make buildworld fails on Raspberry PI State-Changed-From-To: open->closed State-Changed-By: jmg State-Changed-When: Tue May 20 06:06:16 UTC 2014 State-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=182060 From owner-freebsd-arm@FreeBSD.ORG Tue May 20 10:10:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71345520 for ; Tue, 20 May 2014 10:10:03 +0000 (UTC) Received: from msgw002-01.ocn.ad.jp (msgw002-01.ocn.ad.jp [180.37.203.76]) by mx1.freebsd.org (Postfix) with ESMTP id 41C2323B6 for ; Tue, 20 May 2014 10:10:02 +0000 (UTC) Received: from localhost (p11104-ipngn100303sizuokaden.shizuoka.ocn.ne.jp [114.176.34.104]) by msgw002-01.ocn.ad.jp (Postfix) with ESMTP id ED8175F5098; Tue, 20 May 2014 19:10:01 +0900 (JST) Date: Tue, 20 May 2014 19:10:01 +0900 (JST) Message-Id: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> To: madis555@hot.ee Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <537ACDB2.9080808@hot.ee> References: <024F43EF-E299-413E-AE42-2507AEDD0886@bsdimp.com> <537ACDB2.9080808@hot.ee> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 10:10:03 -0000 In message: <537ACDB2.9080808@hot.ee> "Sulev-Madis Silber (ketas)" writes: > > Actually I guess many people might think like me... "HELL, optimizing > boot time of 1min?! I have more important tasks to do than this". If you have ``device sdhci'' line in conf/BEAGLEBONE, is there any differences by changing mmchs to sdhci in am335x.dtsi and beaglebone-black.dts? And also remove ``status = "disabled"'' It's needed for me to detect eMMC, and the perfomance is better: http://lists.freebsd.org/pipermail/freebsd-arm/2013-August/006332.html But I don't success to boot from eMMC yet with u-boot-2014.04. I need to change u-boot. -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Tue May 20 11:11:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 520CC380 for ; Tue, 20 May 2014 11:11:34 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 122F728C8 for ; Tue, 20 May 2014 11:11:33 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s4KBBP59090911 for ; Tue, 20 May 2014 07:11:31 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <537B385D.5080805@m5p.com> Date: Tue, 20 May 2014 07:11:25 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Closer to building u-boot 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]); Tue, 20 May 2014 07:11:31 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 11:11:34 -0000 I updated my amd64 build machine over the weekend: 10.0-STABLE FreeBSD 10.0-STABLE #0 r266422M: Sun May 18 22:17:20 EDT 2014 and updated crochet and u-boot to yesterday's versions with git pull. With this combination, I am much closer to being able to build an RPi image again. The u-boot build gets fairly far along, but dumps core while linking. The build log and the core file are at: http://www.m5p.com/~george/pi/u-boot-log-core.tbz Backtrace: This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `ld'. Program terminated with signal 11, Segmentation fault. #0 0x000000000042364c in elf32_arm_finish_dynamic_sections () (gdb) where #0 0x000000000042364c in elf32_arm_finish_dynamic_sections () #1 0x000000000044828a in bfd_elf_final_link () #2 0x0000000000417ec8 in ldwrite () #3 0x0000000000415499 in main () (gdb) My thanks to all who helped get us here. Is there any other data I can provide to help debug this? -- George From owner-freebsd-arm@FreeBSD.ORG Tue May 20 11:26:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BDC66A5 for ; Tue, 20 May 2014 11:26:51 +0000 (UTC) Received: from mail-pa0-x246.google.com (mail-pa0-x246.google.com [IPv6:2607:f8b0:400e:c03::246]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 17A932A43 for ; Tue, 20 May 2014 11:26:51 +0000 (UTC) Received: by mail-pa0-f70.google.com with SMTP id lj1so877748pab.5 for ; Tue, 20 May 2014 04:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:message-id:date:subject:from:to:content-type; bh=3oqwFIeVnDh1K8gNMaHIaOrx+uuH43kXuGee0K8zDzE=; b=HmrAIA+BG8nhpz1xsW0R756Kzdu3dchf7WKIg6gLaTxQxbjbgp1NQfMBVTkeiBeLxs 30mugd6KSnnqU26blAkkxJE9UIehEbAc23bPgwZQyoer0PDE7w9/oDY9HL8R1uX8LP72 soPHjFLXNxQFWCa9TNMx5y9sOl2wM71oXPicyGuyi/Yu0qPjhz6JDctBmozIlhMgHecR KNTGHOwM48k9Vr/fvpdrnAwn0TXnDZ1r8+KRdugSuWATS0CDjZVDhINvl8zBcMt9LWTm W9DSwqfieupnmyomkuPBqyo1UrJpkI2OWg3NKmI7cD5+IUxdP7hJ72WhkTgj4CCrTFVr HWXA== MIME-Version: 1.0 X-Received: by 10.66.216.130 with SMTP id oq2mr5925692pac.44.1400585210783; Tue, 20 May 2014 04:26:50 -0700 (PDT) Message-ID: <047d7b5d98bff76d6304f9d32769@google.com> Date: Tue, 20 May 2014 11:26:50 +0000 Subject: www.freebsd.org From: Angel To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 11:26:51 -0000 Hi, I found your contact over the web and wanted to shoot you a quick note. With Search Engine Optimization (SEO) and Web Development, I can help your business achieve better ranking on prominent search engines like Google, Bing & others to generate more leads/sales (No Offense: SEO is the process of affecting the visibility of a website or a web page in a search engine's "natural" or un-paid "organic" search through indexing, preventing crawling & increasing prominence) This may look like one of those spurious foreign emails you get in your inbox every day that promise big but delivers nothing. Just to be upfront we are happy to discuss your requirement free of cost. So, let me know if you are interested in receiving further information/quote with no strings attached from our team of SEO & Web experts & if you are all ok than simply reply with an "UNSUBSCRIBE" header and I promise not to waste your time ever again (kind apology). Thank you and have a nice day. Regards, Angel SEO / WEB Specialist *HUBSCOPE SEO* Cth | ACT | NSW | NT | Qld | SA | Tas | Vic | WA Disclaimer: If you are not the intended recipient of this mailer please mail us back & we will stop emailing you any further. From owner-freebsd-arm@FreeBSD.ORG Tue May 20 12:20:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 598C3A75 for ; Tue, 20 May 2014 12:20:05 +0000 (UTC) Received: from msgw001-03.ocn.ad.jp (msgw001-03.ocn.ad.jp [180.37.203.72]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0902F1D for ; Tue, 20 May 2014 12:20:04 +0000 (UTC) Received: from localhost (p11104-ipngn100303sizuokaden.shizuoka.ocn.ne.jp [114.176.34.104]) by msgw001-03.ocn.ad.jp (Postfix) with ESMTP id AB147AE293A; Tue, 20 May 2014 21:20:03 +0900 (JST) Date: Tue, 20 May 2014 21:20:03 +0900 (JST) Message-Id: <20140520.212003.232778263.toshi@ruby.ocn.ne.jp> To: madis555@hot.ee Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> References: <537ACDB2.9080808@hot.ee> <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 12:20:05 -0000 In message: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> SAITOU Toshihide writes: > In message: <537ACDB2.9080808@hot.ee> > "Sulev-Madis Silber (ketas)" writes: >> >> Actually I guess many people might think like me... "HELL, optimizing >> boot time of 1min?! I have more important tasks to do than this". > > If you have ``device sdhci'' line in conf/BEAGLEBONE, is there any > differences by changing mmchs to sdhci in am335x.dtsi and > beaglebone-black.dts? And also remove ``status = "disabled"'' > > It's needed for me to detect eMMC, and the perfomance is > better: http://lists.freebsd.org/pipermail/freebsd-arm/2013-August/006332.html > > But I don't success to boot from eMMC yet with u-boot-2014.04. I need > to change u-boot. It was booted from eMMC, though it failed sometimes. u-boot-2014.04.tar.bz2 patch 1. apply these patches: http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007922.html ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_api_api_storage.c.patch ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_drivers_mmc_mmc.c.patch patch -p1 or edit. 2. add followings to include/configs/am335x_evm.h: #ifndef CONFIG_SPL_BUILD #define CONFIG_CMD_ELF #define CONFIG_API #define CONFIG_SYS_MMC_MAX_DEVICE 2 #endif 3. comment WATCHDOG in include/configs/ti_am335x_common.h: #define CONFIG_HW_WATCHDOG #define CONFIG_OMAP_WATCHDOG #define CONFIG_SPL_WATCHDOG_SUPPORT build gmake CROSS_COMPILE=arm-eabi- am335x_boneblack_config gmake CROSS_COMPILE=arm-eabi- uEnv.txt bootdelay=2 fdtaddr=0x80000100 loadaddr=0x88000000 loaderdev=disk fdtfile=beaglebo.dtb bootdir= bootfile=ubldr mmcdev=1 mmcloados=mmc rescan loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv} importbootenv=env import -t $loadaddr $filesize findfdt=setenv fdtfile beaglebo.dtb loadimage=fatload mmc ${mmcdev} ${loadaddr} ${bootfile} loadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}; fdt addr ${fdtaddr} mmcboot=bootelf ${loadaddr} nandboot=run mmcboot Please ignore ``Card did not respond to voltage select!'' message. -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Tue May 20 14:12:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8EDAE69 for ; Tue, 20 May 2014 14:12:41 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1A529EF for ; Tue, 20 May 2014 14:12:41 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id c13so613812eek.26 for ; Tue, 20 May 2014 07:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=x2+xswbsybB7JM3Pq+xOMLOu0W3xbmTk2JWnMlgPS2U=; b=xU73LN0sXgvCKA4P2/Zjo4u1BIqEq7Do25TMYZs7+V4yoCwygnUJTqBFbrB7APiQnV VgVaaw5jNer30QlOzbuolwwJ3KVaIXI6qHaj4vMLyRoI+aj3wipjuKuBMIw+wFf0NgEV gtiMWqpUjvbfLPYyLmcZMZCUaDt6nlZ+qB2iCw1+6YLDOV9IswFuayvqbpott5ODkUdH v63FHI94NMr3/dM9k8M3pZoL7xJbe5nsT71Yovl0GChif0+U28Zh0xfhxvKaQRAWB2iU Pa2raWxBqrnnrB9vXLegl/XFQJCcpDgWBI35lKJFAiV7RZoC7d+5tybv9wk4GsjeRWmC z7dA== X-Received: by 10.14.179.136 with SMTP id h8mr4592136eem.57.1400595158208; Tue, 20 May 2014 07:12:38 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id i4sm4165924eeg.28.2014.05.20.07.12.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 07:12:36 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537B62D1.4090901@hot.ee> Date: Tue, 20 May 2014 17:12:33 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: SAITOU Toshihide Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) References: <537ACDB2.9080808@hot.ee> <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> <20140520.212003.232778263.toshi@ruby.ocn.ne.jp> In-Reply-To: <20140520.212003.232778263.toshi@ruby.ocn.ne.jp> X-TagToolbar-Keys: D20140520171233804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:12:41 -0000 On 2014-05-20 15:20, SAITOU Toshihide wrote: > In message: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> > SAITOU Toshihide writes: >> In message: <537ACDB2.9080808@hot.ee> >> "Sulev-Madis Silber (ketas)" writes: >>> >>> Actually I guess many people might think like me... "HELL, optimizing >>> boot time of 1min?! I have more important tasks to do than this". >> >> If you have ``device sdhci'' line in conf/BEAGLEBONE, is there any >> differences by changing mmchs to sdhci in am335x.dtsi and >> beaglebone-black.dts? And also remove ``status = "disabled"'' Don't edit am335x.dtsi And beaglebone-black.dts already has proper config. >> >> It's needed for me to detect eMMC, and the perfomance is >> better: http://lists.freebsd.org/pipermail/freebsd-arm/2013-August/006332.html >> >> But I don't success to boot from eMMC yet with u-boot-2014.04. I need >> to change u-boot. > > It was booted from eMMC, though it failed sometimes. Are you sure it booted from eMMC? Like, I can't find eMMC in loader (ubldr). So I need SD to complete this part of boot. Not sure what I need to patch, probably loader? Hopefully the old uboot can be used as well. Version check or something... > > > u-boot-2014.04.tar.bz2 > > patch > > 1. apply these patches: > > http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007922.html > ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_api_api_storage.c.patch > ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_drivers_mmc_mmc.c.patch > > patch -p1 or edit. > > 2. add followings to include/configs/am335x_evm.h: > > #ifndef CONFIG_SPL_BUILD > #define CONFIG_CMD_ELF > #define CONFIG_API > #define CONFIG_SYS_MMC_MAX_DEVICE 2 > #endif > > 3. comment WATCHDOG in include/configs/ti_am335x_common.h: > > #define CONFIG_HW_WATCHDOG > #define CONFIG_OMAP_WATCHDOG > > #define CONFIG_SPL_WATCHDOG_SUPPORT > > build > > gmake CROSS_COMPILE=arm-eabi- am335x_boneblack_config > gmake CROSS_COMPILE=arm-eabi- > > > uEnv.txt > > bootdelay=2 > fdtaddr=0x80000100 > loadaddr=0x88000000 > loaderdev=disk > fdtfile=beaglebo.dtb > bootdir= > bootfile=ubldr > mmcdev=1 > mmcloados=mmc rescan > loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv} > importbootenv=env import -t $loadaddr $filesize > findfdt=setenv fdtfile beaglebo.dtb > loadimage=fatload mmc ${mmcdev} ${loadaddr} ${bootfile} > loadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}; fdt addr ${fdtaddr} > mmcboot=bootelf ${loadaddr} > nandboot=run mmcboot > > Please ignore ``Card did not respond to voltage select!'' message. > Crochet already has all those patches, so I use uboot from there. From owner-freebsd-arm@FreeBSD.ORG Tue May 20 14:42:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2D33B10 for ; Tue, 20 May 2014 14:42:47 +0000 (UTC) Received: from msgw001-05.ocn.ad.jp (msgw001-05.ocn.ad.jp [180.37.203.74]) by mx1.freebsd.org (Postfix) with ESMTP id 751792CD4 for ; Tue, 20 May 2014 14:42:47 +0000 (UTC) Received: from localhost (p11104-ipngn100303sizuokaden.shizuoka.ocn.ne.jp [114.176.34.104]) by msgw001-05.ocn.ad.jp (Postfix) with ESMTP id 2413AA82C1D; Tue, 20 May 2014 23:42:46 +0900 (JST) Date: Tue, 20 May 2014 23:42:45 +0900 (JST) Message-Id: <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> To: madis555@hot.ee Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <537B62D1.4090901@hot.ee> References: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> <20140520.212003.232778263.toshi@ruby.ocn.ne.jp> <537B62D1.4090901@hot.ee> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:42:47 -0000 In message: <537B62D1.4090901@hot.ee> "Sulev-Madis Silber (ketas)" writes: > On 2014-05-20 15:20, SAITOU Toshihide wrote: >> In message: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> >> SAITOU Toshihide writes: >>> In message: <537ACDB2.9080808@hot.ee> >>> "Sulev-Madis Silber (ketas)" writes: >>>> >>>> Actually I guess many people might think like me... "HELL, optimizing >>>> boot time of 1min?! I have more important tasks to do than this". >>> >>> If you have ``device sdhci'' line in conf/BEAGLEBONE, is there any >>> differences by changing mmchs to sdhci in am335x.dtsi and >>> beaglebone-black.dts? And also remove ``status = "disabled"'' > > Don't edit am335x.dtsi > > And beaglebone-black.dts already has proper config. In this case, how does ``device sdhci'' driver know the register address? I thought that there is an inconsistency in BEAGLEBONE config and dts file for the SD/MMC driver. >>> It's needed for me to detect eMMC, and the perfomance is >>> better: http://lists.freebsd.org/pipermail/freebsd-arm/2013-August/006332.html >>> >>> But I don't success to boot from eMMC yet with u-boot-2014.04. I need >>> to change u-boot. >> >> It was booted from eMMC, though it failed sometimes. > > Are you sure it booted from eMMC? Like, I can't find eMMC in loader > (ubldr). So I need SD to complete this part of boot. > > Not sure what I need to patch, probably loader? Hopefully the old uboot > can be used as well. Version check or something... Yes sure, because SD card is detached. The pach is for u-boot. >> u-boot-2014.04.tar.bz2 >> >> patch >> >> 1. apply these patches: >> >> http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007922.html >> ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_api_api_storage.c.patch >> ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_drivers_mmc_mmc.c.patch >> >> patch -p1 or edit. >> >> 2. add followings to include/configs/am335x_evm.h: >> >> #ifndef CONFIG_SPL_BUILD >> #define CONFIG_CMD_ELF >> #define CONFIG_API >> #define CONFIG_SYS_MMC_MAX_DEVICE 2 >> #endif >> >> 3. comment WATCHDOG in include/configs/ti_am335x_common.h: >> >> #define CONFIG_HW_WATCHDOG >> #define CONFIG_OMAP_WATCHDOG >> >> #define CONFIG_SPL_WATCHDOG_SUPPORT >> >> build >> >> gmake CROSS_COMPILE=arm-eabi- am335x_boneblack_config >> gmake CROSS_COMPILE=arm-eabi- >> >> >> uEnv.txt >> >> bootdelay=2 >> fdtaddr=0x80000100 >> loadaddr=0x88000000 >> loaderdev=disk >> fdtfile=beaglebo.dtb >> bootdir= >> bootfile=ubldr >> mmcdev=1 >> mmcloados=mmc rescan >> loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv} >> importbootenv=env import -t $loadaddr $filesize >> findfdt=setenv fdtfile beaglebo.dtb >> loadimage=fatload mmc ${mmcdev} ${loadaddr} ${bootfile} >> loadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}; fdt addr ${fdtaddr} >> mmcboot=bootelf ${loadaddr} >> nandboot=run mmcboot >> >> Please ignore ``Card did not respond to voltage select!'' message. >> > > Crochet already has all those patches, so I use uboot from there. Yes, I use patches of crochet for u-boot-2014.04. -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Tue May 20 15:58:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DE3BCD for ; Tue, 20 May 2014 15:58:40 +0000 (UTC) Received: from msgw002-05.ocn.ad.jp (msgw002-05.ocn.ad.jp [180.37.203.80]) by mx1.freebsd.org (Postfix) with ESMTP id 30CAE2416 for ; Tue, 20 May 2014 15:58:39 +0000 (UTC) Received: from localhost (p11104-ipngn100303sizuokaden.shizuoka.ocn.ne.jp [114.176.34.104]) by msgw002-05.ocn.ad.jp (Postfix) with ESMTP id 7AA46A42E16; Wed, 21 May 2014 00:58:38 +0900 (JST) Date: Wed, 21 May 2014 00:58:37 +0900 (JST) Message-Id: <20140521.005837.00935147.toshi@ruby.ocn.ne.jp> To: freebsd-arm@freebsd.org Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> References: <20140520.212003.232778263.toshi@ruby.ocn.ne.jp> <537B62D1.4090901@hot.ee> <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_May_21_00_58_37_2014_732)--" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 15:58:40 -0000 ----Next_Part(Wed_May_21_00_58_37_2014_732)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit In message: <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> SAITOU Toshihide writes: >>> u-boot-2014.04.tar.bz2 >>> >>> patch >>> >>> 1. apply these patches: >>> >>> http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007922.html >>> ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_api_api_storage.c.patch >>> ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_drivers_mmc_mmc.c.patch I forgot to mention that I had changed uboot-2013.04_drivers_mmc_mmc.c.patch a bit. Sorry for bother you -- SAITOU Toshihide ----Next_Part(Wed_May_21_00_58_37_2014_732)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="uboot-2014.04_drivers_mmc_mmc.c.patch" --- mmc.c.orig 2014-05-21 00:52:57.000000000 +0900 +++ mmc.c 2014-05-20 23:52:09.000000000 +0900 @@ -1225,9 +1225,14 @@ block_dev_desc_t *mmc_get_dev(int dev) { struct mmc *mmc = find_mmc_device(dev); - if (!mmc || mmc_init(mmc)) + if (!mmc) return NULL; + /* If mmc_init fails, mmc->block_dev will be of type + * DEV_TYPE_UNKNOWN with blksz and lba set to zero. + */ + mmc_init(mmc); + return &mmc->block_dev; } #endif @@ -1252,7 +1257,7 @@ err = mmc->cfg->ops->init(mmc); if (err) - return err; + goto done; mmc_set_bus_width(mmc, 1); mmc_set_clock(mmc, 1); @@ -1261,7 +1266,7 @@ err = mmc_go_idle(mmc); if (err) - return err; + goto done; /* The internal partition reset to user partition(0) at every CMD0*/ mmc->part_num = 0; @@ -1280,13 +1285,24 @@ #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT) printf("Card did not respond to voltage select!\n"); #endif - return UNUSABLE_ERR; +// return UNUSABLE_ERR; + goto done; } } if (err == IN_PROGRESS) mmc->init_in_progress = 1; +done: + if (err) { + mmc->has_init = 0; + mmc->block_dev.type = DEV_TYPE_UNKNOWN; + mmc->block_dev.blksz = 0; + mmc->block_dev.lba = 0; + } else { + mmc->has_init = 1; + } + return err; } ----Next_Part(Wed_May_21_00_58_37_2014_732)---- From owner-freebsd-arm@FreeBSD.ORG Tue May 20 17:16:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79F2AB65 for ; Tue, 20 May 2014 17:16:48 +0000 (UTC) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D57B2BCA for ; Tue, 20 May 2014 17:16:47 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id d49so818764eek.29 for ; Tue, 20 May 2014 10:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nZHXUXSlrQm/gFhJ/amG53YBzQCBRV3Pwrr+PrnoAjM=; b=S7b8zpI4GJqQjWRGqildNscW7jBFCDS6Y1ztW2fvj1v/H8TEf6lkurC32OuSTWJmXy ch9dIJrll7RKPENpWPMyaOWdstBYPTM7i5D8ALkTDTLllhpuNaWZhnmTW1HzHJReNbUU gFriGonmR6ASRon6HlqPQ+UacJUHIaElYE7vuqakZb6C7gabCh9fLqvgcqVnxvgmbxAk N5pEYdTR1rMFAGxQywvM1Z1jZaUbSB7ICv81zmqJxYnru/U32WJ+jfx3pFTVMRBIOHA8 dFSGyUYD94b0TgYYhmHSprCJLocR4E9gvR9CgIUf1SIs4YDTwRegWOtJcNe70dslMvtM BOmA== X-Received: by 10.14.1.69 with SMTP id 45mr5303509eec.104.1400606206350; Tue, 20 May 2014 10:16:46 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id h6sm5251021eew.38.2014.05.20.10.16.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 10:16:45 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537B8DFA.3000603@hot.ee> Date: Tue, 20 May 2014 20:16:42 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: SAITOU Toshihide Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) References: <20140520.212003.232778263.toshi@ruby.ocn.ne.jp> <537B62D1.4090901@hot.ee> <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> <20140521.005837.00935147.toshi@ruby.ocn.ne.jp> In-Reply-To: <20140521.005837.00935147.toshi@ruby.ocn.ne.jp> X-TagToolbar-Keys: D20140520201642308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 17:16:48 -0000 On 2014-05-20 18:58, SAITOU Toshihide wrote: > In message: <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> > SAITOU Toshihide writes: >>>> u-boot-2014.04.tar.bz2 >>>> >>>> patch >>>> >>>> 1. apply these patches: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007922.html >>>> ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_api_api_storage.c.patch >>>> ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_drivers_mmc_mmc.c.patch > > I forgot to mention that I had changed uboot-2013.04_drivers_mmc_mmc.c.patch a bit. > > Sorry for bother you Hmm, that doesn't seem to fix it. I have different uboot env but that should not matter here. Is this CURRENT? I'm on CURRENT and that patch doesn't get me two SD devices in loader. It's quite mysterious code there too... Could you explain where and how exactly did you manage to get both devices found in loader. I'm not exactly sure uboot needs patch. I might start hacking loader next. All the things I use with BBB are here: http://ketas.si.pri.ee/bbb/ From owner-freebsd-arm@FreeBSD.ORG Tue May 20 20:11:12 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A18BD26; Tue, 20 May 2014 20:11:12 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3C3A2D10; Tue, 20 May 2014 20:11:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4KKBBJ0045928; Tue, 20 May 2014 20:11:11 GMT (envelope-from loos@freefall.freebsd.org) Received: (from loos@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4KKBBI0045927; Tue, 20 May 2014 20:11:11 GMT (envelope-from loos) Date: Tue, 20 May 2014 20:11:11 GMT Message-Id: <201405202011.s4KKBBI0045927@freefall.freebsd.org> To: loos@FreeBSD.org, freebsd-arm@FreeBSD.org, loos@FreeBSD.org From: loos@FreeBSD.org Subject: Re: arm/189914: i2c(8) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:11:12 -0000 Synopsis: i2c(8) Responsible-Changed-From-To: freebsd-arm->loos Responsible-Changed-By: loos Responsible-Changed-When: Tue May 20 20:11:11 UTC 2014 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=189914 From owner-freebsd-arm@FreeBSD.ORG Tue May 20 20:19:11 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 780A6409; Tue, 20 May 2014 20:19:11 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B8CB2E20; Tue, 20 May 2014 20:19:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4KKJBpg047363; Tue, 20 May 2014 20:19:11 GMT (envelope-from loos@freefall.freebsd.org) Received: (from loos@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4KKJ9Kb047362; Tue, 20 May 2014 20:19:09 GMT (envelope-from loos) Date: Tue, 20 May 2014 20:19:09 GMT Message-Id: <201405202019.s4KKJ9Kb047362@freefall.freebsd.org> To: marcus@popp.mx, loos@FreeBSD.org, freebsd-arm@FreeBSD.org From: loos@FreeBSD.org Subject: Re: arm/189899: rpi.dts don't build anymore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:19:11 -0000 Synopsis: rpi.dts don't build anymore State-Changed-From-To: open->closed State-Changed-By: loos State-Changed-When: Tue May 20 20:19:09 UTC 2014 State-Changed-Why: The by the OP and it is already fixed. http://www.freebsd.org/cgi/query-pr.cgi?pr=189899 From owner-freebsd-arm@FreeBSD.ORG Wed May 21 10:40:46 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38AF5B18 for ; Wed, 21 May 2014 10:40:46 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [84.201.143.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA6CA2A21 for ; Wed, 21 May 2014 10:40:44 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward8l.mail.yandex.net (Yandex) with ESMTP id AA8FE1A4137D for ; Wed, 21 May 2014 14:40:35 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 6260613408A1 for ; Wed, 21 May 2014 14:40:35 +0400 (MSK) Received: from 93.91.10.182.tel.ru (93.91.10.182.tel.ru [93.91.10.182]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id EQVmiDLbSN-eYxKMqsA; Wed, 21 May 2014 14:40:35 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 701957b0-5f23-4c63-ae96-cb537b6d2320 Message-ID: <537C82A2.3020502@passap.ru> Date: Wed, 21 May 2014 14:40:34 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: [crochet, wandboard] newfs_msdos: 12762 clusters too few clusters for FAT32, need 65525 X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 10:40:46 -0000 Hi All, Using crochet to create an image for wandboard: ----- [...] Creating a 3900MB raw disk image in: /home/bsam/crochet-freebsd-master/work/FreeBSD-armv6-11.0-IMX6-r266491.img Partitioning the raw disk image at среда, 21 мая 2014 г. 13:24:15 (SAMT) gpart create -s MBR md1 md1 created Installing U-Boot to /dev/md1 582+0 records in 582+0 records out 297984 bytes transferred in 6.019639 secs (49502 bytes/sec) Creating a 50m FAT partition at среда, 21 мая 2014 г. 13:24:21 (SAMT) with start block 16384 and label BOOT active set on md1s1 newfs_msdos: 12762 clusters too few clusters for FAT32, need 65525 ----- The line from board/Wandboard/setup.sh "disk_fat_create 50m 32 16384" uses FA32 and fails. After I change the line to "disk_fat_create 50m 16 16384" (use FAT16) the command succeeds. This change seems to be in par with code at lib/disk.sh: ----- _FAT_TYPE=$2 if [ -z "${_FAT_TYPE}" -o \( "${_FAT_TYPE}" = "-1" \) ]; then case $1 in *k | [1-9]m | 1[0-6]m) _FAT_TYPE=12 ;; *m) _FAT_TYPE=16 ;; *g) _FAT_TYPE=32 ;; esac ----- I.e. if a partition is set in megabytes, use FAT16. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Wed May 21 12:43:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9784B526 for ; Wed, 21 May 2014 12:43:59 +0000 (UTC) Received: from msgw001-03.ocn.ad.jp (msgw001-03.ocn.ad.jp [180.37.203.72]) by mx1.freebsd.org (Postfix) with ESMTP id 41EF02406 for ; Wed, 21 May 2014 12:43:58 +0000 (UTC) Received: from localhost (p3014-ipngn100303sizuokaden.shizuoka.ocn.ne.jp [180.4.34.14]) by msgw001-03.ocn.ad.jp (Postfix) with ESMTP id E6155AE2916; Wed, 21 May 2014 21:43:56 +0900 (JST) Date: Wed, 21 May 2014 21:43:56 +0900 (JST) Message-Id: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> To: madis555@hot.ee Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <537B8DFA.3000603@hot.ee> References: <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> <20140521.005837.00935147.toshi@ruby.ocn.ne.jp> <537B8DFA.3000603@hot.ee> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 12:43:59 -0000 In message: <537B8DFA.3000603@hot.ee> "Sulev-Madis Silber (ketas)" writes: > On 2014-05-20 18:58, SAITOU Toshihide wrote: >> In message: <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> >> SAITOU Toshihide writes: >>>>> u-boot-2014.04.tar.bz2 >>>>> >>>>> patch >>>>> >>>>> 1. apply these patches: >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007922.html >>>>> ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_api_api_storage.c.patch >>>>> ~/crochet-freebsd/board/BeagleBone/files/uboot-2013.04_drivers_mmc_mmc.c.patch >> >> I forgot to mention that I had changed uboot-2013.04_drivers_mmc_mmc.c.patch a bit. >> >> Sorry for bother you > > Hmm, that doesn't seem to fix it. I have different uboot env but that > should not matter here. Is this CURRENT? I'm on CURRENT and that patch > doesn't get me two SD devices in loader. It's quite mysterious code > there too... > > Could you explain where and how exactly did you manage to get both > devices found in loader. I'm not exactly sure uboot needs patch. I might > start hacking loader next. I'm using current 265876 and did not change the source code except for am335x.dtsi and beaglebone-black.dts. ubldr is built to change the load address as follows: # cat ubldr_make.sh buildenv=`make -C /usr/src TARGET=arm TARGET_ARCH=armv6 buildenvvars` eval $buildenv make -C /usr/src/sys/boot obj eval $buildenv make -C /usr/src/sys/boot UBLDR_LOADADDR=0x88000000 all # sh ubldr_make.sh # cp /usr/obj/arm.armv6/usr/src/sys/boot/arm/uboot/ubldr \ /mnt/ubldr (maybe need to cp /usr/src/share/mk/src.opts.mk /usr/share/mk/) u-boot (MLO, u-boot.img) is u-boot-2014.04 and apply these patch: http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007922.html uboot-2013.04_api_api_storage.c.patch uboot-2014.04_drivers_mmc_mmc.c.patch According to the third patch, it seems to retry when mmc_send_op_cond is failed. I don't know why it failed. -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Wed May 21 15:20:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F2B0359 for ; Wed, 21 May 2014 15:20:53 +0000 (UTC) Received: from msgw002-05.ocn.ad.jp (msgw002-05.ocn.ad.jp [180.37.203.80]) by mx1.freebsd.org (Postfix) with ESMTP id E671920ED for ; Wed, 21 May 2014 15:20:52 +0000 (UTC) Received: from localhost (p3014-ipngn100303sizuokaden.shizuoka.ocn.ne.jp [180.4.34.14]) by msgw002-05.ocn.ad.jp (Postfix) with ESMTP id 6497EA42E10; Thu, 22 May 2014 00:20:51 +0900 (JST) Date: Thu, 22 May 2014 00:20:51 +0900 (JST) Message-Id: <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> To: madis555@hot.ee Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> References: <20140521.005837.00935147.toshi@ruby.ocn.ne.jp> <537B8DFA.3000603@hot.ee> <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:20:53 -0000 In message: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> SAITOU Toshihide writes: > > I'm using current 265876 and did not change the source code except for > am335x.dtsi and beaglebone-black.dts. If abort like musbotg0: TI AM335X USBSS v0.0.13 Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' trapframe: 0xc0a2eb60 add device_printf("!\n") before ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of am335x_usbss.c. -- SAITOU Toshihide <(__)> From owner-freebsd-arm@FreeBSD.ORG Wed May 21 15:49:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CA7EDBE for ; Wed, 21 May 2014 15:49:38 +0000 (UTC) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22810230D for ; Wed, 21 May 2014 15:49:37 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id l6so2467067oag.32 for ; Wed, 21 May 2014 08:49:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DpO2G+qYOogLwAVeqaSCzl6SMPK5j2lymJTD2+iiHWA=; b=hmsOqhboZ22orWAcj0U6XMpKiKAXk0waYvSLkrqJwC/mPkqLj0Km12VSfyFvhIYe0a TxoB50RMlx3Jw+Z6fuxKiq6Pr5DPTXlqpD99GrKPyu+YEKeBYH/zj03T18fuSZCFdMcb fbMYygl6LQJW3B3RXa402YIsiG70ctMBAaW0HZKcCSweNX2M+Piy0doyNrfHiA1C5YlR neMtWZ5eQ18+QAVdXPTrnfv5zs3rQfwAIzl6qs++yelJKxV2iyOkRcgxiFTFINWfwX2o D55TQ6oJPQUdJhFaUPMV3Ak1ghtCviSjO2sTxK/myUKiEz1fehuCtC3zywPD440s88jS 6dWA== X-Gm-Message-State: ALoCoQn0HbIZRM0lNRTIrAPoBpzgrUy+uwSdOTHkUeGhduf2gYd3r823QquHizv56cte7IGbr1fk MIME-Version: 1.0 X-Received: by 10.60.44.165 with SMTP id f5mr30927726oem.38.1400687022722; Wed, 21 May 2014 08:43:42 -0700 (PDT) Received: by 10.182.246.135 with HTTP; Wed, 21 May 2014 08:43:42 -0700 (PDT) In-Reply-To: <537C82A2.3020502@passap.ru> References: <537C82A2.3020502@passap.ru> Date: Wed, 21 May 2014 09:43:42 -0600 Message-ID: Subject: Re: [crochet, wandboard] newfs_msdos: 12762 clusters too few clusters for FAT32, need 65525 From: Tom Everett To: Boris Samorodov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:49:38 -0000 Hello Boris. I believe that is my bug you've found. are you planning to submit a patch? On Wed, May 21, 2014 at 4:40 AM, Boris Samorodov wrote: > Hi All, > > Using crochet to create an image for wandboard: > ----- > [...] > Creating a 3900MB raw disk image in: > > /home/bsam/crochet-freebsd-master/work/FreeBSD-armv6-11.0-IMX6-r266491.im= g > Partitioning the raw disk image at =D1=81=D1=80=D0=B5=D0=B4=D0=B0, 21 =D0= =BC=D0=B0=D1=8F 2014 =D0=B3. 13:24:15 (SAMT) > gpart create -s MBR md1 > md1 created > Installing U-Boot to /dev/md1 > 582+0 records in > 582+0 records out > 297984 bytes transferred in 6.019639 secs (49502 bytes/sec) > Creating a 50m FAT partition at =D1=81=D1=80=D0=B5=D0=B4=D0=B0, 21 =D0=BC= =D0=B0=D1=8F 2014 =D0=B3. 13:24:21 (SAMT) > with start block 16384 and label BOOT > active set on md1s1 > newfs_msdos: 12762 clusters too few clusters for FAT32, need 65525 > ----- > > The line from board/Wandboard/setup.sh "disk_fat_create 50m 32 16384" > uses FA32 and fails. After I change the line to "disk_fat_create 50m 16 > 16384" (use FAT16) the command succeeds. > > This change seems to be in par with code at lib/disk.sh: > ----- > _FAT_TYPE=3D$2 > if [ -z "${_FAT_TYPE}" -o \( "${_FAT_TYPE}" =3D "-1" \) ]; then > case $1 in > *k | [1-9]m | 1[0-6]m) _FAT_TYPE=3D12 > ;; > *m) _FAT_TYPE=3D16 > ;; > *g) _FAT_TYPE=3D32 > ;; > esac > ----- > > I.e. if a partition is set in megabytes, use FAT16. > > -- > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > _______________________________________________ > 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 A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Wed May 21 16:52:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4593679A for ; Wed, 21 May 2014 16:52:11 +0000 (UTC) Received: from forward1l.mail.yandex.net (forward1l.mail.yandex.net [IPv6:2a02:6b8:0:1819::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02E7F2979 for ; Wed, 21 May 2014 16:52:10 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward1l.mail.yandex.net (Yandex) with ESMTP id 3B2C41520D61; Wed, 21 May 2014 20:51:55 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id C42D91B43C22; Wed, 21 May 2014 20:51:54 +0400 (MSK) Received: from 93.91.10.182.tel.ru (93.91.10.182.tel.ru [93.91.10.182]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id y1AwZJ83X5-psBaAX6w; Wed, 21 May 2014 20:51:54 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: aec1f41a-6e39-4a9e-a812-35832ce51a7a Message-ID: <537CD9AA.3030200@passap.ru> Date: Wed, 21 May 2014 20:51:54 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tom Everett Subject: Re: [crochet, wandboard] newfs_msdos: 12762 clusters too few clusters for FAT32, need 65525 References: <537C82A2.3020502@passap.ru> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:52:11 -0000 Hi Tom, All, 21.05.2014 19:43, Tom Everett пишет: > Hello Boris. I believe that is my bug you've found. are you planning to > submit a patch? Sure: ----- --- board/Wandboard/setup.sh.orig 2014-05-21 20:49:02.907014085 +0400 +++ board/Wandboard/setup.sh 2014-05-21 20:49:17.266011383 +0400 @@ -13,7 +13,7 @@ wandboard_partition_image ( ) { disk_partition_mbr wandboard_uboot_install - disk_fat_create 50m 32 16384 + disk_fat_create 50m 16 16384 disk_ufs_create } ----- Thanks! > > > On Wed, May 21, 2014 at 4:40 AM, Boris Samorodov wrote: > >> Hi All, >> >> Using crochet to create an image for wandboard: >> ----- >> [...] >> Creating a 3900MB raw disk image in: >> >> /home/bsam/crochet-freebsd-master/work/FreeBSD-armv6-11.0-IMX6-r266491.img >> Partitioning the raw disk image at среда, 21 мая 2014 г. 13:24:15 (SAMT) >> gpart create -s MBR md1 >> md1 created >> Installing U-Boot to /dev/md1 >> 582+0 records in >> 582+0 records out >> 297984 bytes transferred in 6.019639 secs (49502 bytes/sec) >> Creating a 50m FAT partition at среда, 21 мая 2014 г. 13:24:21 (SAMT) >> with start block 16384 and label BOOT >> active set on md1s1 >> newfs_msdos: 12762 clusters too few clusters for FAT32, need 65525 >> ----- >> >> The line from board/Wandboard/setup.sh "disk_fat_create 50m 32 16384" >> uses FA32 and fails. After I change the line to "disk_fat_create 50m 16 >> 16384" (use FAT16) the command succeeds. >> >> This change seems to be in par with code at lib/disk.sh: >> ----- >> _FAT_TYPE=$2 >> if [ -z "${_FAT_TYPE}" -o \( "${_FAT_TYPE}" = "-1" \) ]; then >> case $1 in >> *k | [1-9]m | 1[0-6]m) _FAT_TYPE=12 >> ;; >> *m) _FAT_TYPE=16 >> ;; >> *g) _FAT_TYPE=32 >> ;; >> esac >> ----- >> >> I.e. if a partition is set in megabytes, use FAT16. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Wed May 21 17:22:06 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1402E482 for ; Wed, 21 May 2014 17:22:06 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDDA32BF6 for ; Wed, 21 May 2014 17:22:05 +0000 (UTC) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 522C11C1049B0 for ; Wed, 21 May 2014 19:22:02 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: FreeBSD doesn't boot anymore on RPi Message-Id: Date: Wed, 21 May 2014 19:22:01 +0200 To: "freebsd-arm@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:22:06 -0000 Dear all, I just built r266500 and when booting that on a Raspberry Pi the booting = stalls after displaying Kernel args: (null). Any idea? Best regards Michael= From owner-freebsd-arm@FreeBSD.ORG Wed May 21 19:28:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CF6DB00; Wed, 21 May 2014 19:28:12 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id F2F36276F; Wed, 21 May 2014 19:28:11 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 09CE9B828; Wed, 21 May 2014 21:28:08 +0200 (SAST) Date: Wed, 21 May 2014 21:28:07 +0200 From: John Hay To: Adrian Chadd Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140521192807.GA48338@zibbi.meraka.csir.co.za> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:28:12 -0000 On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: > isn't eabi on the xscale still broken? It might still be broken. But there are more brokenness than that. :-( By defining WITHOUT_ARM_EABI=yes in src.conf, I can get an AVILA kernel built that boots with src from head at around mid December. Latest 10 and head just give no output, with or without WITHOUT_ARM_EABI defined. John > > > -a > > > On 19 May 2014 08:40, Warner Losh wrote: > > Greetings, > > > > MK_ARM_EABI is going to die in current. It is the default for all platforms currently. I???m eliminating it as a build option. It must die because it invisibly (to uname) effects the ABI. > > > > So, to that end, I see two options: > > > > (1) Retire and remove oabi support. > > (2) Retain oabi support, but change its name to armo and armoeb. > > > > The rough consensus of arm developers I???ve polled now, and in the past, is that we just let oabi support die now that EABI support is working for everybody. > > > > Before I pull the trigger on this, however, I must ask if anybody has a problem with my doing option (1), and if so, what keeps you using oabi. > > > > Comments? > > > > Warner > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Wed May 21 19:44:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0074B102; Wed, 21 May 2014 19:44:13 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B8D462929; Wed, 21 May 2014 19:44:13 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4LJi5RN079991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2014 12:44:05 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4LJi5UK079990; Wed, 21 May 2014 12:44:05 -0700 (PDT) (envelope-from jmg) Date: Wed, 21 May 2014 12:44:05 -0700 From: John-Mark Gurney To: Adrian Chadd Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140521194405.GG43976@funkthat.com> Mail-Followup-To: Adrian Chadd , Warner Losh , freebsd-arm References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 21 May 2014 12:44:05 -0700 (PDT) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:44:14 -0000 Adrian Chadd wrote this message on Mon, May 19, 2014 at 09:50 -0700: > isn't eabi on the xscale still broken? I don't think it's EABI that is broken, though I will admit that I haven't ever tried to boot AVILA w/ OABI (that I can remember)... I have managed to decode the vm_page as requested and provided the info to various parties, but no one has looked at it, or at least come up with request for additional data... I would like to see it fixed, but w/o support to figure out why a page is being wired when it shouldn't, it isn't going to happen... > On 19 May 2014 08:40, Warner Losh wrote: > > Greetings, > > > > MK_ARM_EABI is going to die in current. It is the default for all platforms currently. I???m eliminating it as a build option. It must die because it invisibly (to uname) effects the ABI. > > > > So, to that end, I see two options: > > > > (1) Retire and remove oabi support. > > (2) Retain oabi support, but change its name to armo and armoeb. > > > > The rough consensus of arm developers I???ve polled now, and in the past, is that we just let oabi support die now that EABI support is working for everybody. > > > > Before I pull the trigger on this, however, I must ask if anybody has a problem with my doing option (1), and if so, what keeps you using oabi. > > > > Comments? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed May 21 19:46:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB6B9167; Wed, 21 May 2014 19:46:44 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CAE52946; Wed, 21 May 2014 19:46:44 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4LJkhpc080049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2014 12:46:43 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4LJkhaf080048; Wed, 21 May 2014 12:46:43 -0700 (PDT) (envelope-from jmg) Date: Wed, 21 May 2014 12:46:43 -0700 From: John-Mark Gurney To: John Hay Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140521194643.GH43976@funkthat.com> Mail-Followup-To: John Hay , Adrian Chadd , freebsd-arm References: <20140521192807.GA48338@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140521192807.GA48338@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 21 May 2014 12:46:43 -0700 (PDT) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:46:44 -0000 John Hay wrote this message on Wed, May 21, 2014 at 21:28 +0200: > On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: > > isn't eabi on the xscale still broken? > > It might still be broken. But there are more brokenness than that. :-( > By defining WITHOUT_ARM_EABI=yes in src.conf, I can get an AVILA kernel > built that boots with src from head at around mid December. Latest 10 > and head just give no output, with or without WITHOUT_ARM_EABI defined. Did you apply the patch I referenced in: https://www.freebsd.org/cgi/mid.cgi?20140219172938.GH34851@funkthat.com that was sent to you? This should fix 10, and HEAD should be fine unless there has been a regression in the last few months... I haven't worked on the AVILA since no one is interested in helping me... > > On 19 May 2014 08:40, Warner Losh wrote: > > > Greetings, > > > > > > MK_ARM_EABI is going to die in current. It is the default for all platforms currently. I???m eliminating it as a build option. It must die because it invisibly (to uname) effects the ABI. > > > > > > So, to that end, I see two options: > > > > > > (1) Retire and remove oabi support. > > > (2) Retain oabi support, but change its name to armo and armoeb. > > > > > > The rough consensus of arm developers I???ve polled now, and in the past, is that we just let oabi support die now that EABI support is working for everybody. > > > > > > Before I pull the trigger on this, however, I must ask if anybody has a problem with my doing option (1), and if so, what keeps you using oabi. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed May 21 20:00:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B92A5809 for ; Wed, 21 May 2014 20:00:18 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44C7A2A55 for ; Wed, 21 May 2014 20:00:18 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id mc6so1980837lab.35 for ; Wed, 21 May 2014 13:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=stvDxuaXIj2ncsiOGJ5oiqWoTjLfSwBgRoxPHZUS/F0=; b=PWdSKSYq4F8dhED8B32Z/4NKojOVPMcC0pVaOm9ljx+HUhgJuOvJvxLNuVAnLpXY8A +JW7AbZKSASkcrLEkPKJBkKOonosmgWJLsqqfUL7T0GZRcNgSkmmoGyAd9bHio8LWlFx OxXfk7CMvT6Krq9jXAoEfIth8Mm1NXoHd0Mk1JzNYEbpxWtmUPwRaceXxrmcq4cFm3af SlVFafu+gNDmFdfhhd77fLOrB8Xys1Gsau4VPLAVjW1BK88mThkvm9PMbS1oa9abcFYX xPR7e85N4bpPMSoRI4YFEQjKM8zJOsvd1LYXvQHL9NLHE6C+GzFBws4t7vF5oEkIAI0x glNA== MIME-Version: 1.0 X-Received: by 10.152.43.8 with SMTP id s8mr2947450lal.81.1400702416025; Wed, 21 May 2014 13:00:16 -0700 (PDT) Received: by 10.112.230.5 with HTTP; Wed, 21 May 2014 13:00:15 -0700 (PDT) In-Reply-To: <1397618162.1484.26.camel@fbsd-laptop> References: <1397618162.1484.26.camel@fbsd-laptop> Date: Wed, 21 May 2014 17:00:15 -0300 Message-ID: Subject: Re: Plans for standardizing digital/analog I/O? From: Luiz Otavio O Souza To: Brian McGovern Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 20:00:18 -0000 On 16 April 2014 00:16, Brian J. McGovern wrote: > This is probably best suited for a more generic list, but given digital > and analog I/O are at the core of many of the ARM based development > boards out there, I figured I'd ask here first... > > Is anyone talking about standardizing the various I/O framworks that > exist/are being built? Or, perhaps more correctly,standardizing the > _interfaces_ to the various I/O frameworks? > > To use the BBB as an example platform, the digital I/O work seems to use > the gpio[ctl] framework, while the ADC uses sysctl under the new/current > driver. I haven't looked at PWM outputs yet. Finally, given that I have > passthrough driver for the various Velleman I/O boards (the 110, 140, > and 167) which allow the application to speak the various protocols to > the boards (not to mention allowing me to plug in 5V and 12V things in > to the 1.8V BBB world without much modification), I'm discovering there > are at least 6 ways to do I/O in my world, and I'm guessing there are a > lot more if I were to keep digging. > > So, I'm curious if anyone is working on or proposing a more generic, or > at least standard, kernel interface to plug in to? Perhaps sysctls are a > way to go, or a set of /dev/hwio/* entries. I'd also be interested in > hearing anyone's thoughts on the matter, should I decide to go off and > build something, either in kernel or user space, to unify these spaces > for the ease of application programming. > -B > Hi Brian, Yes, i do think we could benefit from having such standards for the various I/O options. I have been thinking on this and have some ideas that i would like to see implemented. That being said, i don't know when i will be able to tackle with this. But sure, help is very welcome. Regards, Luiz From owner-freebsd-arm@FreeBSD.ORG Wed May 21 20:01:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C059A867 for ; Wed, 21 May 2014 20:01:49 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D92A2ADA for ; Wed, 21 May 2014 20:01:49 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id md12so1722121pbc.12 for ; Wed, 21 May 2014 13:01:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=iaoDJDGMjIrINmDfqwV6bKFtohd/oSsWq8JSZMINZ44=; b=I+gBSIIMC5+RzvvpGaNNHCiIvRapeldd+rUgeJW/PfSs9/TTDAinTxYoE9ZH3Q4eIi 0aOq1PgoR45a0nYs3S0ID9IqKK4/6JF0RvqQJ9DstRWLIF+lumP4Ik2srvmkLQLd3NTb 8oO1rqOtyIvlo5WEwffw8TL3SiJpf1mp/gDjkRtiNHiCmtAlfURPvpmeVOQa0G3C7lPE LxBhh8VRpIgDLTixZ/hpKG2SLoGr4QKhhuKTxIpRnU4E450WSAGSnxLto2xLS44GC1JZ RenQKG3tfshkNYNI72Eu9DLvoTIJBkXdycPbsxxX1DE4IKX15TOyM/hcekYHC7Vi7AL7 ZTGA== X-Gm-Message-State: ALoCoQnak/Y0+AbDluqvOET2EnnBCD6XiRdhJwqAkuUiOmWoEKFza1CLDKL5npDPqJzQEhhsAZmO X-Received: by 10.68.202.8 with SMTP id ke8mr61691343pbc.86.1400702502958; Wed, 21 May 2014 13:01:42 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id zv3sm109222198pab.20.2014.05.21.13.01.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 13:01:42 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_A8FC32A3-D51C-4D62-B98E-152C950A91E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: MK_ARM_EABI to retire in current From: Warner Losh In-Reply-To: <20140521192807.GA48338@zibbi.meraka.csir.co.za> Date: Wed, 21 May 2014 14:01:42 -0600 Message-Id: <95AD97BA-AA48-4BBF-845C-D0CB585ACAA3@bsdimp.com> References: <20140521192807.GA48338@zibbi.meraka.csir.co.za> To: John Hay X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 20:01:49 -0000 --Apple-Mail=_A8FC32A3-D51C-4D62-B98E-152C950A91E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 21, 2014, at 1:28 PM, John Hay wrote: > On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: >> isn't eabi on the xscale still broken? >=20 > It might still be broken. But there are more brokenness than that. :-( > By defining WITHOUT_ARM_EABI=3Dyes in src.conf, I can get an AVILA = kernel > built that boots with src from head at around mid December. Latest 10 > and head just give no output, with or without WITHOUT_ARM_EABI = defined. Does the same thing happen with make.conf instead of src.conf? Warner > John >=20 >>=20 >>=20 >> -a >>=20 >>=20 >> On 19 May 2014 08:40, Warner Losh wrote: >>> Greetings, >>>=20 >>> MK_ARM_EABI is going to die in current. It is the default for all = platforms currently. I???m eliminating it as a build option. It must die = because it invisibly (to uname) effects the ABI. >>>=20 >>> So, to that end, I see two options: >>>=20 >>> (1) Retire and remove oabi support. >>> (2) Retain oabi support, but change its name to armo and armoeb. >>>=20 >>> The rough consensus of arm developers I???ve polled now, and in the = past, is that we just let oabi support die now that EABI support is = working for everybody. >>>=20 >>> Before I pull the trigger on this, however, I must ask if anybody = has a problem with my doing option (1), and if so, what keeps you using = oabi. >>>=20 >>> Comments? >>>=20 >>> Warner >>>=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" >> _______________________________________________ >> 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" --Apple-Mail=_A8FC32A3-D51C-4D62-B98E-152C950A91E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTfQYmAAoJEGwc0Sh9sBEAxXkP/RBwo9yg97eBGf07SITcTCt4 85josysqg4FDKUWYa0fLoZRZ3d6vUzKXvAlMh2GzsuL9rNRh1wWT2me95PjlfUrE SSctSPe0e2CQbmDrPvuerQe++R5jPI/5+T9UQJSxC+Ij0QolBur+sKxAhPdSIuAs rlyqqnTwF0qSJK5lhJk3I36pSz1BypNyzTZcJopB6HV7vfU5nEJ/cLMcqxOOiNKz mgze6CD+7LD2b0h0Ym3Iy7HwVKD5rW5HHLxByDWvpJL+myEMzfBLfmCXfOscrkPh UtqAwhGcXf3DYt8ySLg8+r/mgpbLAkt0CJLpI1SBUW/QMA/UpAqKtKWDgXUx/BN+ X+RR95JxkPnPNCmPyHv5nLV8dPnI3w+S00sln70eWEpE+bpD+G1mbyL8VCYb/Bad WMWi4MGeZyrmYeZfX+PK+1tQQky5V4aQm5+d4LAZehVD5UosvimwKW9GMESHh5yr 3Y9qpxp7d96jX1M+8ap9OrkHEriVLHB7ToM0V5bPxrppZWhwthYujlt4ZCtFWDP9 L3makivhX558s+PtRZ5D3irq7EDh369CkSulL4XDZZIFcVjcrYDBY6qD8HaP59KS 0QMCEKTqfsP2KLFTJJPrPUBCKjljgo5bpOR5V3m+NUoT2zFc4NMXezGAzl4UI/sK vNkwO+cLgs15TjoynPat =lheu -----END PGP SIGNATURE----- --Apple-Mail=_A8FC32A3-D51C-4D62-B98E-152C950A91E4-- From owner-freebsd-arm@FreeBSD.ORG Wed May 21 20:15:03 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6858CDB3; Wed, 21 May 2014 20:15:03 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2608B2BD3; Wed, 21 May 2014 20:15:03 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 64E081FE026; Wed, 21 May 2014 22:15:02 +0200 (CEST) Message-ID: <537D0975.4040703@selasky.org> Date: Wed, 21 May 2014 22:15:49 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Michael Tuexen , "freebsd-arm@freebsd.org" , Ian Lepore , markm , ray@freebsd.org Subject: Re: FreeBSD doesn't boot anymore on RPi References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 20:15:03 -0000 On 05/21/14 19:22, Michael Tuexen wrote: > Dear all, > > I just built r266500 and when booting that on a Raspberry Pi the booting stalls > after displaying Kernel args: (null). > > Any idea? > Hi, If you revert: r266083 You get until: VT: initialize with new VT driver "fb". panic: mtx_lock() of spin mutex (null) @ /usr/img/freebsd/sys/dev/vt/vt_core.c:2037 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! __mtx_lock_flags() at vt_resize() at vt_upgrade() at mi_startup() at mi_startup+0x11c --HPS From owner-freebsd-arm@FreeBSD.ORG Wed May 21 20:21:21 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F4CD123; Wed, 21 May 2014 20:21:21 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51BC72C8B; Wed, 21 May 2014 20:21:21 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6C7011FE027; Wed, 21 May 2014 22:21:19 +0200 (CEST) Message-ID: <537D0AEE.5050502@selasky.org> Date: Wed, 21 May 2014 22:22:06 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Michael Tuexen , "freebsd-arm@freebsd.org" , Ian Lepore , markm , ray@freebsd.org Subject: Re: FreeBSD doesn't boot anymore on RPi References: <537D0975.4040703@selasky.org> In-Reply-To: <537D0975.4040703@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 20:21:21 -0000 Summed up: Revert r265927 and r266083. Then it boots again. --HPS From owner-freebsd-arm@FreeBSD.ORG Wed May 21 21:29:05 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B85B735 for ; Wed, 21 May 2014 21:29:05 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39C5C2243 for ; Wed, 21 May 2014 21:29:05 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WnE4H-000GpS-Sb; Wed, 21 May 2014 21:28:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4LLSt72045491; Wed, 21 May 2014 15:28:55 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+8S5rve06jmWAubg11E1Pu Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Ian Lepore To: Warner Losh In-Reply-To: References: <537A050E.3040804@hot.ee> <537AB550.2090401@hot.ee> <537AB675.1020006@hot.ee> <024F43EF-E299-413E-AE42-2507AEDD0886@bsdimp.com> <537ACDB2.9080808@hot.ee> Content-Type: text/plain; charset="windows-1251" Date: Wed, 21 May 2014 15:28:55 -0600 Message-ID: <1400707735.1152.194.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s4LLSt72045491 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 21:29:05 -0000 On Mon, 2014-05-19 at 22:07 -0600, Warner Losh wrote: > On May 19, 2014, at 9:36 PM, Sulev-Madis Silber (ketas) wrote: >=20 > > On 2014-05-20 05:39, Winston Smith wrote: > >> On Mon, May 19, 2014 at 10:28 PM, Warner Losh wrote= : > >>> Wow! That=92s a lot of added 10ms delays=85 Do we have a theory of= the crime > >>> for why they are needed? Usually they suggest to me that we=92re do= ing something > >>> wrong (either not checking the right bits in the bridge, having a f= ixed retry count > >>> rather than a timed limit and having some bridges fail more slowly = than others > >>> so the delays are effecting the same thing). > >>=20 > >> It's a good start (since the BBB is really flakey at 1Ghz), but yes, > >> more delays aren't good! > >>=20 > >> For what it's worth, I'm working in parallel with both FreeBSD and > >> Debian Wheezy images on the BBB, and it is quite apparent that the B= BB > >> running FreeBSD is *much* slower to boot than the BBB running Debian= ; > >> which currently boots to the login prompt in about 15 seconds from > >> power up. FreeBSD has a 15-20 second delay just to detect the eMMC, > >> let alone everything else. > >>=20 > >> Comparatively, my x64 FreeBSD VM boots much more quickly than my Ubu= ntu x64 VM. > >>=20 > >> -W. > >>=20 > >=20 > >=20 > > "really flakey" sounds like "unstable, panics 1000 times a day". I do= n't > > see any of that here (as of 11.0-CURRENT r266442). > >=20 > > Boot, hmm... yea, 1min (just measured) to fully boot up and connect t= o > > server (I'm using ethernet, DHCP, loader boot delay =3D 3, huge Perl > > program) might be too slow if you have some embedded system which > > constantly loses power or something... I haven't tried to do any boot > > time optimizations yet. Compress kernel? Compress userland? Execute > > something in parallel on init (NOTE: *DON'T* even think about porting > > Linux init replacements here)? Use rescue-like static binary? Heavily > > customize / patch kernel? Use own init? Use rootfs inside kernel? > > Actually I guess many people might think like me... "HELL, optimizing > > boot time of 1min?! I have more important tasks to do than this=94. >=20 > Make MMC faster, and a lot of this will go away. When I was doing Atmel= , > I got more milage out of optimizing the I/O path for slow boots than I = did > for just about anything else. >=20 It's not the actual MMC IO that's slow, it's the card detection and init stuff. It's the age-old problem... if you have no card in slot 0 you really don't want to wait for 10 seconds worth of retries with timeouts. On the other hand, if your favorite data lives on that card, you want the system to try as hard as possible to get at it, not give up too early. I think the real problem is that neither of the mmc/sd drivers we've got for the TI hardware is very good. I created the ti_sdhci glue layer using the original ti_mmchs driver as a guide, so it has all the original's problems plus any I introduced. I had a quick glance at the linux driver yesterday, and they're dealing with a variety of things we don't, such as the MMC "80 clock cycles for init" stuff that may be quite significant for the problems people are seeing now. They also do some tricky-looking things with calculating the command and data timeouts that's different than anything we do. I think the driver could use a full-time owner/caretaker, and I don't have the time to be that person right now, although I could certainly help someone who had good driver skills and just needed info on its current state and history, and our general mmc/sd layers. > Another quick hack: delete all files in /etc/rc.d that aren=92t used. That works around the poor performance we have with fork/exec on arm. On armv4 some of that trouble is unavoidable because of hardware limitations dictating expensive page-tracking stuff in the pmap code. On armv6 I think it more reflects the poor state of the pmap code, which is not because the hardware requires it, but because the code is long overdue for a complete rewrite that throws away all of its v4 heritage. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed May 21 21:38:04 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96412D25 for ; Wed, 21 May 2014 21:38:04 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 69439232C for ; Wed, 21 May 2014 21:38:03 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WnED4-000IZd-Rk; Wed, 21 May 2014 21:38:02 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4LLc0op045506; Wed, 21 May 2014 15:38:00 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+td6BDOaLe1QCbHYiggPba Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Ian Lepore To: SAITOU Toshihide In-Reply-To: <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> References: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> <20140520.212003.232778263.toshi@ruby.ocn.ne.jp> <537B62D1.4090901@hot.ee> <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 2014 15:38:00 -0600 Message-ID: <1400708280.1152.199.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 21:38:04 -0000 On Tue, 2014-05-20 at 23:42 +0900, SAITOU Toshihide wrote: > In message: <537B62D1.4090901@hot.ee> > "Sulev-Madis Silber (ketas)" writes: > > On 2014-05-20 15:20, SAITOU Toshihide wrote: > >> In message: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> > >> SAITOU Toshihide writes: > >>> In message: <537ACDB2.9080808@hot.ee> > >>> "Sulev-Madis Silber (ketas)" writes: > >>>> > >>>> Actually I guess many people might think like me... "HELL, optimizing > >>>> boot time of 1min?! I have more important tasks to do than this". > >>> > >>> If you have ``device sdhci'' line in conf/BEAGLEBONE, is there any > >>> differences by changing mmchs to sdhci in am335x.dtsi and > >>> beaglebone-black.dts? And also remove ``status = "disabled"'' > > > > Don't edit am335x.dtsi > > > > And beaglebone-black.dts already has proper config. > > In this case, how does ``device sdhci'' driver know the register address? > I thought that there is an inconsistency in BEAGLEBONE config and > dts file for the SD/MMC driver. > The name@address tag in the dts[i] files doesn't have to match the driver name in the kernel config. What matters for matching the driver to the right entry in the dts is the "compatible=" property. The ti_sdhci driver looks for an entry with any one of these compatible strings: "ti,omap3-hsmmc", "ti,omap4-hsmmc", "ti,mmchs" -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 22 00:40:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4A7C16B for ; Thu, 22 May 2014 00:40:31 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E2D821C5 for ; Thu, 22 May 2014 00:40:31 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id x13so2726662wgg.22 for ; Wed, 21 May 2014 17:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zei4QYv9nkkdmOC16c1MyZoSNfSzGUXEcZhsvBICKhY=; b=izV6DTNe/uI14bhKwDZ81Z7I7vKu+Ef+WNnBPKS8a8SGYHgwOg8FYCmf2MDTjEE9og T6FjJgctS3hPca0dycYAJU812WtlWxTHjUqyPO6zWi5z7k+bfc3U2qaJhIfbGBIyfFr+ on0yurDckMO3w/yhqoa0cryN4VAXBqux8lztR5jC9I3ii23jmUrKHmN6T6xXeBoF5QjU ojvgkBaBsp9W/uuTq9NbmxO1JTbXYAOPhOWRY/tULa72Ebu/woPNy6tdXxEu49ztbX+d y6rZ2jcE4HKVIiXSH0yG1bGo9XEzDNN9gILXJBE89XEDJFawtfvu1oiprzgCp+bFJ6J6 LGeA== MIME-Version: 1.0 X-Received: by 10.194.60.114 with SMTP id g18mr20074873wjr.61.1400719229598; Wed, 21 May 2014 17:40:29 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 21 May 2014 17:40:29 -0700 (PDT) In-Reply-To: <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> References: <20140521.005837.00935147.toshi@ruby.ocn.ne.jp> <537B8DFA.3000603@hot.ee> <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> Date: Wed, 21 May 2014 20:40:29 -0400 Message-ID: Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Winston Smith To: SAITOU Toshihide Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 00:40:31 -0000 On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: > If abort like > > musbotg0: TI AM335X USBSS v0.0.13 > Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' > trapframe: 0xc0a2eb60 I see this with the 1Ghz uboot, it occurs about 50% of the time, see: http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 From owner-freebsd-arm@FreeBSD.ORG Thu May 22 03:24:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C897CEE for ; Thu, 22 May 2014 03:24:30 +0000 (UTC) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 200D22DA3 for ; Thu, 22 May 2014 03:24:29 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id n16so3280403oag.38 for ; Wed, 21 May 2014 20:24:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TNWaLrx3A9OO7iaiS/RFTCtYj8dHESy7Zzeh37UAGZA=; b=jOGtT45divgi0HFWUcFP8XTVeHmggJOKrC2CBukfY+P2zkOvsg0Z6UjYcUoG99+kbV 3QmwVofmYqoiT1RIJ8esLlmcesW/8lUQ08doAZNBr3wY7q6T9Z2qf14fG/tMlxc3ThIj nvPP8N3w3wVmq7zQ4QGEpysYXUPcVlcuf3d+XXi6wCxzTwCDTlgiEWJA5MWSo6H813RD LWU8sbhag/gyi0I2+BjiHh5Ca/7+NwtYXKEQBFrDEltKpdEhXCwoCInNBIoU89eBSksQ sMzAbhXfdIEjQi8Wh7IvWbta2Knbefw3GvbBMBExrPMGCE4jMWJ3G+waJD+YfeyFd0q+ MY2g== X-Gm-Message-State: ALoCoQnfOUHxS/vm3r8s+ftMNpg2M9CAFxWbkIfmQP7rpkm4Z3d/LhQbzvOZpJagQzNstGt+05FA MIME-Version: 1.0 X-Received: by 10.182.214.41 with SMTP id nx9mr56050865obc.15.1400729062919; Wed, 21 May 2014 20:24:22 -0700 (PDT) Received: by 10.182.246.135 with HTTP; Wed, 21 May 2014 20:24:22 -0700 (PDT) In-Reply-To: <537CD9AA.3030200@passap.ru> References: <537C82A2.3020502@passap.ru> <537CD9AA.3030200@passap.ru> Date: Wed, 21 May 2014 21:24:22 -0600 Message-ID: Subject: Re: [crochet, wandboard] newfs_msdos: 12762 clusters too few clusters for FAT32, need 65525 From: Tom Everett To: Boris Samorodov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 03:24:30 -0000 This, and a bit of other stuff is pull request #65 on the crochet github. On Wed, May 21, 2014 at 10:51 AM, Boris Samorodov wrote: > Hi Tom, All, > > 21.05.2014 19:43, Tom Everett =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > Hello Boris. I believe that is my bug you've found. are you planning = to > > submit a patch? > > Sure: > ----- > --- board/Wandboard/setup.sh.orig 2014-05-21 20:49:02.907014085 +04= 00 > +++ board/Wandboard/setup.sh 2014-05-21 20:49:17.266011383 +0400 > @@ -13,7 +13,7 @@ > wandboard_partition_image ( ) { > disk_partition_mbr > wandboard_uboot_install > - disk_fat_create 50m 32 16384 > + disk_fat_create 50m 16 16384 > disk_ufs_create > } > ----- > > Thanks! > > > > > > > On Wed, May 21, 2014 at 4:40 AM, Boris Samorodov wrote= : > > > >> Hi All, > >> > >> Using crochet to create an image for wandboard: > >> ----- > >> [...] > >> Creating a 3900MB raw disk image in: > >> > >> > /home/bsam/crochet-freebsd-master/work/FreeBSD-armv6-11.0-IMX6-r266491.im= g > >> Partitioning the raw disk image at =D1=81=D1=80=D0=B5=D0=B4=D0=B0, 21 = =D0=BC=D0=B0=D1=8F 2014 =D0=B3. 13:24:15 (SAMT) > >> gpart create -s MBR md1 > >> md1 created > >> Installing U-Boot to /dev/md1 > >> 582+0 records in > >> 582+0 records out > >> 297984 bytes transferred in 6.019639 secs (49502 bytes/sec) > >> Creating a 50m FAT partition at =D1=81=D1=80=D0=B5=D0=B4=D0=B0, 21 =D0= =BC=D0=B0=D1=8F 2014 =D0=B3. 13:24:21 (SAMT) > >> with start block 16384 and label BOOT > >> active set on md1s1 > >> newfs_msdos: 12762 clusters too few clusters for FAT32, need 65525 > >> ----- > >> > >> The line from board/Wandboard/setup.sh "disk_fat_create 50m 32 16384" > >> uses FA32 and fails. After I change the line to "disk_fat_create 50m 1= 6 > >> 16384" (use FAT16) the command succeeds. > >> > >> This change seems to be in par with code at lib/disk.sh: > >> ----- > >> _FAT_TYPE=3D$2 > >> if [ -z "${_FAT_TYPE}" -o \( "${_FAT_TYPE}" =3D "-1" \) ]; then > >> case $1 in > >> *k | [1-9]m | 1[0-6]m) _FAT_TYPE=3D12 > >> ;; > >> *m) _FAT_TYPE=3D16 > >> ;; > >> *g) _FAT_TYPE=3D32 > >> ;; > >> esac > >> ----- > >> > >> I.e. if a partition is set in megabytes, use FAT16. > > -- > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > --=20 A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Thu May 22 03:46:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2D3E131; Thu, 22 May 2014 03:46:02 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F8012F26; Thu, 22 May 2014 03:46:02 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi2so3709408wib.1 for ; Wed, 21 May 2014 20:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DZpGfpkVl5kI015gzesISXCZWNDnBiL4ukWTynPENZg=; b=BCN/kfj/KHc4NqDwpZMhPx2O0Xsidhc0GYf/wIVumC76twddtYdc2xt8+8Gpum6NKc OlJ1WZ0ZgoCMsCK9r0/o1bsQTfS6PDpT+1rqIDZY7YuEZvjAfJuWVPh3N6Q2kcxg648o R84nmQbRJsAC4WQ4UlWyhMuFFvNRlaj831f6Ss9OSVBwNg4HO7/PLYF7qsPn9NkJG+Hm ahX3kFWj9rIfPBmd1CtLzwKDCM65Vi2+tDqnOnw/gUWRhGI+6SHpyRY+vJddRD4gv/VQ cjiFld5WMVAw8rPRvSm9nY4c64nwqg7o4HU3zKQwJ8QlMznrR+hWF3cvq3mnjflyKBOK oTxQ== MIME-Version: 1.0 X-Received: by 10.194.6.166 with SMTP id c6mr149756wja.64.1400730359569; Wed, 21 May 2014 20:45:59 -0700 (PDT) Received: by 10.217.153.193 with HTTP; Wed, 21 May 2014 20:45:59 -0700 (PDT) Date: Thu, 22 May 2014 00:45:59 -0300 Message-ID: Subject: BeagleBone-black GPIO pins use on FreeBSD From: Luiz Otavio O Souza To: freebsd-arm@freebsd.org, "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 03:46:02 -0000 Hi, I've updated the BeagleBone-black Wiki page (https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack) with the default settings for the GPIO expansion headers on FreeBSD. It has all the pins used for ADC (AIN), I2C, PWMs and MMC1. Please let me know if i have missed something. I hope this saves some time for people who is going to work with GPIO. Regards, Luiz From owner-freebsd-arm@FreeBSD.ORG Thu May 22 04:32:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3985B28; Thu, 22 May 2014 04:32:08 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2001:470:1:2d5:26:3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id D4FA9230A; Thu, 22 May 2014 04:32:08 +0000 (UTC) Received: from [IPv6:2601:9:8280:426:4442:e054:8003:6e68] (unknown [IPv6:2601:9:8280:426:4442:e054:8003:6e68]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 236B634A9E7; Wed, 21 May 2014 21:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1400733128; bh=YJ1XMiIGqTOjnwDslVUZWOPkSzMfRZaIgYOrIOFT2XU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dkVYSHsajD7kAJnZlYdxUlgJtb12Ph8CvnQl96xxhbI68jYbFQci6cloXrtTjD0Yc pa53ZjwVFECRipSw/dCcqQg6QUtFGTIO/yAHa+p1wvdUb8WiZTen7g3k7mnn6cF/H+ YtBx1n71yH5oSBAkZ0eZEWppzWdxx1HG5Xsg4Yfw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: BeagleBone-black GPIO pins use on FreeBSD From: Rui Paulo In-Reply-To: Date: Wed, 21 May 2014 21:32:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C8FC523-0FB1-4C84-8276-D297373874BB@felyko.com> References: To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org, "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 04:32:09 -0000 On May 21, 2014, at 20:45, Luiz Otavio O Souza = wrote: > Hi, >=20 > I've updated the BeagleBone-black Wiki page > (https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack) with the > default settings for the GPIO expansion headers on FreeBSD. >=20 > It has all the pins used for ADC (AIN), I2C, PWMs and MMC1. >=20 > Please let me know if i have missed something. >=20 > I hope this saves some time for people who is going to work with GPIO. This is good, but I always wished some information was present on dmesg. = This could be added to the FDT and printed automatically, e.g.: i2c1 {=20 location =3D "SDA header P9 pin 18, SCL header P9 pin 17"; }; That would print: ti_i2c1: SDA header P9 pin 18, SCL header P9 pin 17 If we don't want to put this in the kernel, we could at least put it in = a man page. However, a lot of embedded systems don't even have man = pages... -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Thu May 22 05:00:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2149F574 for ; Thu, 22 May 2014 05:00:29 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3BE724AD for ; Thu, 22 May 2014 05:00:28 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id md12so2094833pbc.26 for ; Wed, 21 May 2014 22:00:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hzGz3Vujp9ugJ7QfSPfrZqRXUuXY1atOBdIRjrW00nI=; b=hRwtnIPYrK0PTmZDAScTA4Ep9EXACFNzOiOIcdyNYdXMbHjYCRVDdt3zdEsn+/JtyC edmAkN25QhYf6Xo7mFb7HqdpIcr0H5nasCjKJOA7F2Lra5WaZ2t7fNR9U2KjQxfHVxvO Tkw49TYyknwgMnvZ9ZYA/KXBaAtIhiQfkq8w9GdQKXMdBze7Q60OvezeO3AK0B5QKSex lDnG16cpWPJYvHDGWnlRwGYkRoZl6vqmkzaEMeLVnwrdn9q7s2wJF8a5J5decyGifI7e YlQY6WaKsyJKTchk3qzpDjss7n7bvx3OA6NeRgO3guZYCmvEn57vvmGfPHa9vHO6hbaY zcAA== X-Gm-Message-State: ALoCoQnaJWMDSyuBbwbwHIzNoWniskIr02qHw4G/XlY3njd7T1dib9usE+6Qbr6zen0upP46blJU X-Received: by 10.67.14.69 with SMTP id fe5mr65341054pad.120.1400734827764; Wed, 21 May 2014 22:00:27 -0700 (PDT) Received: from [10.64.24.150] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id gr10sm10783416pbc.84.2014.05.21.22.00.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 22:00:26 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_09466805-1F4B-4B40-95DE-D9A1BF02154B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: BeagleBone-black GPIO pins use on FreeBSD From: Warner Losh In-Reply-To: <5C8FC523-0FB1-4C84-8276-D297373874BB@felyko.com> Date: Wed, 21 May 2014 23:00:28 -0600 Message-Id: <88BF1D4E-001B-44F9-BEEB-7846BDF6A2E7@bsdimp.com> References: <5C8FC523-0FB1-4C84-8276-D297373874BB@felyko.com> To: Rui Paulo X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org, "freebsd-embedded@freebsd.org" , Luiz Otavio O Souza X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 05:00:29 -0000 --Apple-Mail=_09466805-1F4B-4B40-95DE-D9A1BF02154B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 21, 2014, at 10:32 PM, Rui Paulo wrote: > On May 21, 2014, at 20:45, Luiz Otavio O Souza = wrote: >=20 >> Hi, >>=20 >> I've updated the BeagleBone-black Wiki page >> (https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack) with the >> default settings for the GPIO expansion headers on FreeBSD. >>=20 >> It has all the pins used for ADC (AIN), I2C, PWMs and MMC1. >>=20 >> Please let me know if i have missed something. >>=20 >> I hope this saves some time for people who is going to work with = GPIO. >=20 > This is good, but I always wished some information was present on = dmesg. This could be added to the FDT and printed automatically, e.g.: >=20 > i2c1 {=20 > location =3D "SDA header P9 pin 18, SCL header P9 pin 17"; > }; >=20 > That would print: >=20 > ti_i2c1: SDA header P9 pin 18, SCL header P9 pin 17 >=20 > If we don't want to put this in the kernel, we could at least put it = in a man page. However, a lot of embedded systems don't even have man = pages... This information can be derived mostly from the pinmux stuff that = (should be) in our .dts files. However, there=92s no standard way to = communicate these things. So the strongest we could do for this = non-standard property is =93freebsd,location=94, even though it is a = strong candidate for having it without since that describes hardware. = I=92d squirrel this away in the dev sysctl tree though, since otherwise = the boot will get rather uncomfortably chatty. Warner --Apple-Mail=_09466805-1F4B-4B40-95DE-D9A1BF02154B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTfYRsAAoJEGwc0Sh9sBEASm4P+QHO4jhLgnfFn/QMoXnxEZ0G AlkR3UYwXdO7y6SMCjYbei/5AE05CfExlrWEnBgF/+UNRlOzIdqFDq2b3SDtc5oB d8lNNZ39xQblGYNcyHPgGZak1j9dzGmSpCOVNLZHQr4CZnAVTDx1IUghZ22uySUF +CAAKj/qGGGX9DE3hyRF/oSKDwyfN8ZsKw7t4tBHmaE5Z4GfgCBPWU8MXqJaWmsd uDoGkfhtCkAfpMhtmVleA2u9zNDAQWZ8wV0ro++8ExH8Ps7X/b2szvFH0I0YvOaq 7/olJlz/fmkZb7G1lI5vmG1KVrlJGhp1H4pHxcrzUaB7HdEnT2O/wNaZJKlb1kgK WWk+kMpyYzRRnJfuPPXXBP8xoSuJhOVs10NuEzjuMHG/Nmz5TCJpfe49budzJUcW ur+cfgGCcuZahEisFCI6dRYXlYxdd9KRCBoG+QI1ThBhqc3nKXI0Uxo9H6XIltsC L1P6l9v6m44Hg3JYCLxAfkQjGbOwpH6xIQk51ZFpKJtVuuN7OS7dcB4lmzV0MaGo n4a9USPXJO7D3NgtnBvdk/AsbbPx4LKRLOeY45OQqPLXulh4ILXRrL3VHbMUpog/ 2RLZkQUuMfOO8nCSBRVe5qPAsB42TQLh/O6zR8Err9mccDh0krFF0UUl6vY3bTjW ng+W2AalKDTgCbsE72tA =xASl -----END PGP SIGNATURE----- --Apple-Mail=_09466805-1F4B-4B40-95DE-D9A1BF02154B-- From owner-freebsd-arm@FreeBSD.ORG Thu May 22 06:49:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC59A967; Thu, 22 May 2014 06:49:11 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE022EEF; Thu, 22 May 2014 06:49:11 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 6FAD5B834; Thu, 22 May 2014 08:48:58 +0200 (SAST) Date: Thu, 22 May 2014 08:48:58 +0200 From: John Hay To: Adrian Chadd , freebsd-arm Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140522064858.GA93919@zibbi.meraka.csir.co.za> References: <20140521192807.GA48338@zibbi.meraka.csir.co.za> <20140521194643.GH43976@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140521194643.GH43976@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 06:49:11 -0000 On Wed, May 21, 2014 at 12:46:43PM -0700, John-Mark Gurney wrote: > John Hay wrote this message on Wed, May 21, 2014 at 21:28 +0200: > > On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: > > > isn't eabi on the xscale still broken? > > > > It might still be broken. But there are more brokenness than that. :-( > > By defining WITHOUT_ARM_EABI=yes in src.conf, I can get an AVILA kernel > > built that boots with src from head at around mid December. Latest 10 > > and head just give no output, with or without WITHOUT_ARM_EABI defined. > > Did you apply the patch I referenced in: > https://www.freebsd.org/cgi/mid.cgi?20140219172938.GH34851@funkthat.com > > that was sent to you? This should fix 10, and HEAD should be fine > unless there has been a regression in the last few months... I haven't > worked on the AVILA since no one is interested in helping me... I did, although I did not seem to need it anymore in -current/HEAD. Like I said above, by defining WITHOUT_ARM_EABI=yes I could get an AVILA kernel that boots with src from head at around mid December. I did most of my testing there because I thought that if I could get that to work, one could figure out what is missing in 10. I just tried 10 again just now because of all the arm merges that happened. I got distracted by other work a bit, but would really like to have AVILA and CAMBRIA working. I must still test where after mid December it broke. I know it was broken in Feb. John > > > > On 19 May 2014 08:40, Warner Losh wrote: > > > > Greetings, > > > > > > > > MK_ARM_EABI is going to die in current. It is the default for all platforms currently. I???m eliminating it as a build option. It must die because it invisibly (to uname) effects the ABI. > > > > > > > > So, to that end, I see two options: > > > > > > > > (1) Retire and remove oabi support. > > > > (2) Retain oabi support, but change its name to armo and armoeb. > > > > > > > > The rough consensus of arm developers I???ve polled now, and in the past, is that we just let oabi support die now that EABI support is working for everybody. > > > > > > > > Before I pull the trigger on this, however, I must ask if anybody has a problem with my doing option (1), and if so, what keeps you using oabi. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu May 22 09:05:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93586942; Thu, 22 May 2014 09:05:07 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 34DCD2B00; Thu, 22 May 2014 09:05:07 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 9E91AB828; Thu, 22 May 2014 11:05:04 +0200 (SAST) Date: Thu, 22 May 2014 11:05:04 +0200 From: John Hay To: Warner Losh Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140522090504.GA22488@zibbi.meraka.csir.co.za> References: <20140521192807.GA48338@zibbi.meraka.csir.co.za> <95AD97BA-AA48-4BBF-845C-D0CB585ACAA3@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95AD97BA-AA48-4BBF-845C-D0CB585ACAA3@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 09:05:07 -0000 On Wed, May 21, 2014 at 02:01:42PM -0600, Warner Losh wrote: > > On May 21, 2014, at 1:28 PM, John Hay wrote: > > > On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: > >> isn't eabi on the xscale still broken? > > > > It might still be broken. But there are more brokenness than that. :-( > > By defining WITHOUT_ARM_EABI=yes in src.conf, I can get an AVILA kernel > > built that boots with src from head at around mid December. Latest 10 > > and head just give no output, with or without WITHOUT_ARM_EABI defined. > > Does the same thing happen with make.conf instead of src.conf? Yes, I have tried both 10 and head with WITHOUT_ARM_EABI=yes and no output after go in redboot. My compile lines look like this: make TARGET_ARCH=armeb TARGET_CPUTYPE=xscale toolchain make TARGET=arm TARGET_ARCH=armeb buildkernel KERNCONF=AVILA DESTDIR=/arm/ And then in redboot "load -b 0x200000 kernel" to load it with tftp. And then "go". The "no output" happened somewhere between mid December and beginning of Feb. I determined that before getting side tracked. I'll see in the next day or two if I can narrow that down. If someone have patches so that WITHOUT_ARM_EABI=yes is not needed anymore, I'll test that too. John > > Warner > > > John > > > >> > >> > >> -a > >> > >> > >> On 19 May 2014 08:40, Warner Losh wrote: > >>> Greetings, > >>> > >>> MK_ARM_EABI is going to die in current. It is the default for all platforms currently. I???m eliminating it as a build option. It must die because it invisibly (to uname) effects the ABI. > >>> > >>> So, to that end, I see two options: > >>> > >>> (1) Retire and remove oabi support. > >>> (2) Retain oabi support, but change its name to armo and armoeb. > >>> > >>> The rough consensus of arm developers I???ve polled now, and in the past, is that we just let oabi support die now that EABI support is working for everybody. > >>> > >>> Before I pull the trigger on this, however, I must ask if anybody has a problem with my doing option (1), and if so, what keeps you using oabi. > >>> > >>> Comments? > >>> > >>> Warner > >>> > >>> _______________________________________________ > >>> freebsd-arm@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu May 22 11:39:27 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6385230; Thu, 22 May 2014 11:39:27 +0000 (UTC) Received: from msgw002-03.ocn.ad.jp (msgw002-03.ocn.ad.jp [180.37.203.78]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA8B2826; Thu, 22 May 2014 11:39:26 +0000 (UTC) Received: from localhost (p12095-ipngn100104sizuokaden.shizuoka.ocn.ne.jp [153.185.230.95]) by msgw002-03.ocn.ad.jp (Postfix) with ESMTP id D506FA4ADDB; Thu, 22 May 2014 20:39:24 +0900 (JST) Date: Thu, 22 May 2014 20:39:23 +0900 (JST) Message-Id: <20140522.203923.240655619.toshi@ruby.ocn.ne.jp> To: ian@FreeBSD.org Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <1400708280.1152.199.camel@revolution.hippie.lan> References: <537B62D1.4090901@hot.ee> <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> <1400708280.1152.199.camel@revolution.hippie.lan> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 11:39:27 -0000 In message: <1400708280.1152.199.camel@revolution.hippie.lan> Ian Lepore writes: > On Tue, 2014-05-20 at 23:42 +0900, SAITOU Toshihide wrote: >> In message: <537B62D1.4090901@hot.ee> >> "Sulev-Madis Silber (ketas)" writes: >> > On 2014-05-20 15:20, SAITOU Toshihide wrote: >> >> In message: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> >> >> SAITOU Toshihide writes: >> >>> In message: <537ACDB2.9080808@hot.ee> >> >>> "Sulev-Madis Silber (ketas)" writes: >> >>>> >> >>>> Actually I guess many people might think like me... "HELL, optimizing >> >>>> boot time of 1min?! I have more important tasks to do than this". >> >>> >> >>> If you have ``device sdhci'' line in conf/BEAGLEBONE, is there any >> >>> differences by changing mmchs to sdhci in am335x.dtsi and >> >>> beaglebone-black.dts? And also remove ``status = "disabled"'' >> > >> > Don't edit am335x.dtsi >> > >> > And beaglebone-black.dts already has proper config. >> >> In this case, how does ``device sdhci'' driver know the register address? >> I thought that there is an inconsistency in BEAGLEBONE config and >> dts file for the SD/MMC driver. > > The name@address tag in the dts[i] files doesn't have to match the > driver name in the kernel config. What matters for matching the driver > to the right entry in the dts is the "compatible=" property. The > ti_sdhci driver looks for an entry with any one of these compatible > strings: > > "ti,omap3-hsmmc", "ti,omap4-hsmmc", "ti,mmchs" Ah! I see ti_sdhci.c has ofw_bus_is_compatible(dev, "ti,mmchs"). (Why I felt difference of eMMC detection... Hmm...) On the other hand, u-boot's MMC/SD driver has problem when using eMMC. Crochet has patch for this. The card detection and init problem is exist not only for FreeBSD but also u-boot's MMC operation. -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Thu May 22 11:46:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76349429 for ; Thu, 22 May 2014 11:46:59 +0000 (UTC) Received: from msgw002-03.ocn.ad.jp (msgw002-03.ocn.ad.jp [180.37.203.78]) by mx1.freebsd.org (Postfix) with ESMTP id 45B0B28F4 for ; Thu, 22 May 2014 11:46:59 +0000 (UTC) Received: from localhost (p12095-ipngn100104sizuokaden.shizuoka.ocn.ne.jp [153.185.230.95]) by msgw002-03.ocn.ad.jp (Postfix) with ESMTP id 4C1D1A4ADFB; Thu, 22 May 2014 20:46:58 +0900 (JST) Date: Thu, 22 May 2014 20:46:56 +0900 (JST) Message-Id: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> To: smith.winston.101@gmail.com Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: References: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 11:46:59 -0000 In message: Winston Smith writes: > On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: >> If abort like >> >> musbotg0: TI AM335X USBSS v0.0.13 >> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' >> trapframe: 0xc0a2eb60 > > I see this with the 1Ghz uboot, it occurs about 50% of the time, see: > > http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 Although it is an ad hoc workaround but ``usb start'' at u-boot command prompt (someone mentioned before) or add device_printf("!\n") before ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of am335x_usbss.c prevent this panic for me. Anyway I understand my procedure is workaround, and is working by chance or side effect, but eMMC boot and 1000 MHz operation is fun. -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Thu May 22 12:58:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6A43D4B for ; Thu, 22 May 2014 12:58:12 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67DC42F60 for ; Thu, 22 May 2014 12:58:12 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id c13so2642856eek.12 for ; Thu, 22 May 2014 05:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sZCwI7xl6zGrIawbbKh+hhXlVznCil/xbvKtnbETJ3c=; b=wnjN/TvoD5xjZh/ATP8+tfA9zuTik+iEUtYUjIg8SR6wrjnzCB+v9B19zK/R0jnnR9 e4UJG1EvDph3B6uuFWth+PUQATiVQMcRzEuh4kurQn7Yz1aeDBTB6R0ejrSJ5/sxtwHm 3DxTsl9X/MLcHtCZWrVtxH7XpQIsr5N7s7XZgf6t4m3u7wSFDK3lI38G4PlY/Wo/+wK5 1wYZmOien01EQVmkQpJiROjcRdmcyWReFkoDhe5Xtkx7eo42/7LfYiR8QoPqPb2R7MDr nEGnejG0lr33weUnK+jofeP1gkfXv5MCap7wTaHVaCkIbMtsaJS5FTbwex0k4KkA/0oj kPIA== X-Received: by 10.15.56.65 with SMTP id x41mr23275132eew.13.1400763489521; Thu, 22 May 2014 05:58:09 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id h49sm344235eeg.21.2014.05.22.05.58.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 05:58:08 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537DF45D.8010304@hot.ee> Date: Thu, 22 May 2014 15:58:05 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: SAITOU Toshihide Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) References: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> In-Reply-To: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> X-TagToolbar-Keys: D20140522155805355 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 12:58:12 -0000 On 2014-05-22 14:46, SAITOU Toshihide wrote: > In message: > Winston Smith writes: >> On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: >>> If abort like >>> >>> musbotg0: TI AM335X USBSS v0.0.13 >>> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' >>> trapframe: 0xc0a2eb60 >> >> I see this with the 1Ghz uboot, it occurs about 50% of the time, see: >> >> http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 > > Although it is an ad hoc workaround but ``usb start'' at u-boot command > prompt (someone mentioned before) or add device_printf("!\n") before > ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of > am335x_usbss.c prevent this panic for me. > > Anyway I understand my procedure is workaround, and is working by > chance or side effect, but eMMC boot and 1000 MHz operation is fun. > I wish I could get that working too... I tried to trace device detection path in loader but only found that the problem must be in uboot. Since loader is program that runs in uboot. At least now I know how that works a bit more. But actual issue remains unresolved. What's weird is how I actually boot from eMMC and it's present in uboot... Loader comes from eMMC and then loader suddenly has no devices inside it. The hell is that. From owner-freebsd-arm@FreeBSD.ORG Thu May 22 13:18:10 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28DE6394 for ; Thu, 22 May 2014 13:18:10 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F01FD2119 for ; Thu, 22 May 2014 13:18:09 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WnSsq-000BUo-34; Thu, 22 May 2014 13:18:08 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4MDI49T046348; Thu, 22 May 2014 07:18:05 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/sS602mDBb1HHnnbJIjml3 Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Ian Lepore To: SAITOU Toshihide In-Reply-To: <20140522.203923.240655619.toshi@ruby.ocn.ne.jp> References: <537B62D1.4090901@hot.ee> <20140520.234245.38709064.toshi@ruby.ocn.ne.jp> <1400708280.1152.199.camel@revolution.hippie.lan> <20140522.203923.240655619.toshi@ruby.ocn.ne.jp> Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 2014 07:18:04 -0600 Message-ID: <1400764684.1152.218.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 13:18:10 -0000 On Thu, 2014-05-22 at 20:39 +0900, SAITOU Toshihide wrote: > In message: <1400708280.1152.199.camel@revolution.hippie.lan> > Ian Lepore writes: > > On Tue, 2014-05-20 at 23:42 +0900, SAITOU Toshihide wrote: > >> In message: <537B62D1.4090901@hot.ee> > >> "Sulev-Madis Silber (ketas)" writes: > >> > On 2014-05-20 15:20, SAITOU Toshihide wrote: > >> >> In message: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> > >> >> SAITOU Toshihide writes: > >> >>> In message: <537ACDB2.9080808@hot.ee> > >> >>> "Sulev-Madis Silber (ketas)" writes: > >> >>>> > >> >>>> Actually I guess many people might think like me... "HELL, optimizing > >> >>>> boot time of 1min?! I have more important tasks to do than this". > >> >>> > >> >>> If you have ``device sdhci'' line in conf/BEAGLEBONE, is there any > >> >>> differences by changing mmchs to sdhci in am335x.dtsi and > >> >>> beaglebone-black.dts? And also remove ``status = "disabled"'' > >> > > >> > Don't edit am335x.dtsi > >> > > >> > And beaglebone-black.dts already has proper config. > >> > >> In this case, how does ``device sdhci'' driver know the register address? > >> I thought that there is an inconsistency in BEAGLEBONE config and > >> dts file for the SD/MMC driver. > > > > The name@address tag in the dts[i] files doesn't have to match the > > driver name in the kernel config. What matters for matching the driver > > to the right entry in the dts is the "compatible=" property. The > > ti_sdhci driver looks for an entry with any one of these compatible > > strings: > > > > "ti,omap3-hsmmc", "ti,omap4-hsmmc", "ti,mmchs" > > Ah! I see ti_sdhci.c has ofw_bus_is_compatible(dev, "ti,mmchs"). > (Why I felt difference of eMMC detection... Hmm...) What version of source code are you using to see that? You should be seeing a ofw_bus_search_compatible() call using a table of compatible strings that has those entries I listed. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 22 13:27:24 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72439597 for ; Thu, 22 May 2014 13:27:24 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44B1021DD for ; Thu, 22 May 2014 13:27:23 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WnT1g-000218-U9; Thu, 22 May 2014 13:27:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4MDRE9n046354; Thu, 22 May 2014 07:27:14 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Iv7VZXSVNd5d6gaSHb40D Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Ian Lepore To: SAITOU Toshihide In-Reply-To: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> References: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 2014 07:27:14 -0600 Message-ID: <1400765234.1152.224.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 13:27:24 -0000 On Thu, 2014-05-22 at 20:46 +0900, SAITOU Toshihide wrote: > In message: > Winston Smith writes: > > On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: > >> If abort like > >> > >> musbotg0: TI AM335X USBSS v0.0.13 > >> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' > >> trapframe: 0xc0a2eb60 > > > > I see this with the 1Ghz uboot, it occurs about 50% of the time, see: > > > > http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 > > Although it is an ad hoc workaround but ``usb start'' at u-boot command > prompt (someone mentioned before) or add device_printf("!\n") before > ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of > am335x_usbss.c prevent this panic for me. An 'external non-linefetch abort' on a TI chip usually means that the clocks for a device never got turned on and you attempted to read or write a register in that device. If 'usb start' makes the problem go away, that tends to confirm that thought. The thing is, I don't understand why adding a printf to the code with no other changes would help in any way. I though maybe it was adding some delay to allow the clock-start call to take effect, but the clock enable call is after the USBSS_REVREG read, and that seems wrong. Does it fix the problem to move the ti_prcm_clk_enable() call to be before the USBSS_REVREG read in attach? -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 22 13:37:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30DD875D for ; Thu, 22 May 2014 13:37:59 +0000 (UTC) Received: from msgw001-03.ocn.ad.jp (msgw001-03.ocn.ad.jp [180.37.203.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7AF22B8 for ; Thu, 22 May 2014 13:37:58 +0000 (UTC) Received: from localhost (p12095-ipngn100104sizuokaden.shizuoka.ocn.ne.jp [153.185.230.95]) by msgw001-03.ocn.ad.jp (Postfix) with ESMTP id 72D32AE2936; Thu, 22 May 2014 22:37:51 +0900 (JST) Date: Thu, 22 May 2014 22:36:52 +0900 (JST) Message-Id: <20140522.223652.98861093.toshi@ruby.ocn.ne.jp> To: madis555@hot.ee Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <537DF45D.8010304@hot.ee> References: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <537DF45D.8010304@hot.ee> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: base64 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 13:37:59 -0000 SW4gbWVzc2FnZTogPDUzN0RGNDVELjgwMTAzMDRAaG90LmVlPg0KICAgICAgICAgICAgIlN1bGV2 LU1hZGlzIFNpbGJlciAoa2V0YXMpIiA8bWFkaXM1NTVAaG90LmVlPiB3cml0ZXM6DQo+IE9uIDIw MTQtMDUtMjIgMTQ6NDYsIFNBSVRPVSBUb3NoaWhpZGUgd3JvdGU6DQo+PiBJbiBtZXNzYWdlOiA8 Q0FESC1Bd0diMzZFVWtuTm9mZGNoMVE0UG44R0FOK0VwOVNkaUpfZjdRMnY5ZTRrVzFnQG1haWwu Z21haWwuY29tPg0KPj4gICAgICAgICAgICAgV2luc3RvbiBTbWl0aCA8c21pdGgud2luc3Rvbi4x MDFAZ21haWwuY29tPiB3cml0ZXM6DQo+Pj4gT24gV2VkLCBNYXkgMjEsIDIwMTQgYXQgMTE6MjAg QU0sIFNBSVRPVSBUb3NoaWhpZGUgPHRvc2hpQHJ1Ynkub2NuLm5lLmpwPiB3cm90ZToNCj4+Pj4g SWYgYWJvcnQgbGlrZQ0KPj4+Pg0KPj4+PiAgIG11c2JvdGcwOiBUSSBBTTMzNVggVVNCU1MgdjAu MC4xMw0KPj4+PiAgIEZhdGFsIGtlcm5lbCBtb2RlIGRhdGEgYWJvcnQ6ICdFeHRlcm5hbCBOb24t TGluZWZldGNoIEFib3J0IChTKScNCj4+Pj4gICB0cmFwZnJhbWU6IDB4YzBhMmViNjANCj4+Pg0K Pj4+IEkgc2VlIHRoaXMgd2l0aCB0aGUgMUdoeiB1Ym9vdCwgaXQgb2NjdXJzIGFib3V0IDUwJSBv ZiB0aGUgdGltZSwgc2VlOg0KPj4+DQo+Pj4gaHR0cDovL2NvbW1lbnRzLmdtYW5lLm9yZy9nbWFu ZS5vcy5mcmVlYnNkLmRldmVsLmFybS84MjAwDQo+PiANCj4+IEFsdGhvdWdoIGl0IGlzIGFuIGFk IGhvYyB3b3JrYXJvdW5kIGJ1dCBgYHVzYiBzdGFydCcnIGF0IHUtYm9vdCBjb21tYW5kDQo+PiBw cm9tcHQgKHNvbWVvbmUgbWVudGlvbmVkIGJlZm9yZSkgb3IgYWRkIGRldmljZV9wcmludGYoIiFc biIpIGJlZm9yZQ0KPj4gYGByZXYgPSBVU0JTU19SRUFENChzYywgVVNCU1NfUkVWUkVHKTsnJyBp biB0aGUgbXVzYm90Z19hdHRhY2ggb2YNCj4+IGFtMzM1eF91c2Jzcy5jIHByZXZlbnQgdGhpcyBw YW5pYyBmb3IgbWUuDQo+PiANCj4+IEFueXdheSBJIHVuZGVyc3RhbmQgbXkgcHJvY2VkdXJlIGlz IHdvcmthcm91bmQsIGFuZCBpcyB3b3JraW5nIGJ5DQo+PiBjaGFuY2Ugb3Igc2lkZSBlZmZlY3Qs IGJ1dCBlTU1DIGJvb3QgYW5kIDEwMDAgTUh6IG9wZXJhdGlvbiBpcyBmdW4uDQo+IA0KPiBJIHdp c2ggSSBjb3VsZCBnZXQgdGhhdCB3b3JraW5nIHRvby4uLiBJIHRyaWVkIHRvIHRyYWNlIGRldmlj ZSBkZXRlY3Rpb24NCj4gcGF0aCBpbiBsb2FkZXIgYnV0IG9ubHkgZm91bmQgdGhhdCB0aGUgcHJv YmxlbSBtdXN0IGJlIGluIHVib290LiBTaW5jZQ0KPiBsb2FkZXIgaXMgcHJvZ3JhbSB0aGF0IHJ1 bnMgaW4gdWJvb3QuIEF0IGxlYXN0IG5vdyBJIGtub3cgaG93IHRoYXQgd29ya3MNCj4gYSBiaXQg bW9yZS4gQnV0IGFjdHVhbCBpc3N1ZSByZW1haW5zIHVucmVzb2x2ZWQuIFdoYXQncyB3ZWlyZCBp cyBob3cgSQ0KPiBhY3R1YWxseSBib290IGZyb20gZU1NQyBhbmQgaXQncyBwcmVzZW50IGluIHVi b290Li4uIExvYWRlciBjb21lcyBmcm9tDQo+IGVNTUMgYW5kIHRoZW4gbG9hZGVyIHN1ZGRlbmx5 IGhhcyBubyBkZXZpY2VzIGluc2lkZSBpdC4gVGhlIGhlbGwgaXMgdGhhdC4NCg0KDQpqRllJIG15 IGJvb3QgbG9nIGlzIGhlcmU6DQoNCihub3RlKSANCg0KMS4gYGBDYXJkIGRpZCBub3QgcmVzcG9u ZCB0byB2b2x0YWdlIHNlbGVjdCEnJyBpcyBzaG9ydGVuZWQgdG8gdi4NCjIuIFNEIGNhcmQgaXMg ZGV0YWNoZWQgYW5kIEkgZG9uJ3QgY2hhbmdlIHRoZQ0KICAgQ09ORklHX0VYVFJBX0VOVl9TRVRU SU5HUyBvZiBpbmNsdWRlL2NvbmZpZ3MvYW0zMzV4X2V2bS5oLCBzbw0KICAgdS1ib290IHRyeSB0 byBib290IGZyb20gU0QgLT4gZmFpbGVkIC0+IGNoYW5nZSBtbWNkZXYgMSAtPiBydW4NCiAgIG1t Y2Jvb3QgKGV2YWx1YXRlIHVFbnYudHh0KSAtPiBydW4gbmFuZGJvb3QgKGFjdHVhbGx5IHJ1biBt bWNib290DQogICBzZWUgbXkgcHJldmlvdXMgbWFpbCkuDQozLiBhZGQgc29tZSBjb21tZW50Lg0K DQoNClUtQm9vdCBTUEwgMjAxNC4wNCAoTWF5IDIyIDIwMTQgLSAxMDoyOTozMikNCnJlYWRpbmcg YXJncyAgICAgICAgICAgICA8LSBmaWxlIG5hbWVkIGFyZ3Mgd2l0aCB3aGl0ZSBzcGFjZS4NCnJl YWRpbmcgdS1ib290LmltZyAgICAgICA8LSB0d28gc2FtZSBtZXNzYWdlLiA/DQpyZWFkaW5nIHUt Ym9vdC5pbWcNCg0KDQpVLUJvb3QgMjAxNC4wNCAoTWF5IDIyIDIwMTQgLSAxMDoyOTozMikNCg0K STJDOiAgIHJlYWR5DQpEUkFNOiAgNTEyIE1pQg0KTU1DOiAgIE9NQVAgU0QvTU1DOiAwLCBPTUFQ IFNEL01NQzogMQ0KVXNpbmcgZGVmYXVsdCBlbnZpcm9ubWVudA0KDQpOZXQ6ICAgPGV0aGFkZHI+ IG5vdCBzZXQuIFZhbGlkYXRpbmcgZmlyc3QgRS1mdXNlIE1BQyAgPC0gY2FibGUgaXMgZGV0YWNo ZWQuDQpjcHN3LCB1c2JfZXRoZXINCkhpdCBhbnkga2V5IHRvIHN0b3AgYXV0b2Jvb3Q6ICAwIA0K dm1tYzAocGFydCAwKSBpcyBjdXJyZW50IGRldmljZSAgICAgPC0gdS1ib290LmltZyBzdGVwIGlu IGF0IGBgdicnLg0Kdm1tYzEocGFydCAwKSBpcyBjdXJyZW50IGRldmljZSAgICAgPC0gdS1ib290 LmltZyBzdGVwIGluIGF0IGBgdicnLg0KU0QvTU1DIGZvdW5kIG9uIGRldmljZSAxDQpyZWFkaW5n IHVFbnYudHh0DQo0NjIgYnl0ZXMgcmVhZCBpbiA0IG1zICgxMTIuMyBLaUIvcykNCkxvYWRlZCBl bnZpcm9ubWVudCBmcm9tIHVFbnYudHh0DQpJbXBvcnRpbmcgZW52aXJvbm1lbnQgZnJvbSBtbWMg Li4uDQpyZWFkaW5nIHVibGRyDQoyNDkxNzUgYnl0ZXMgcmVhZCBpbiAzMCBtcyAoNy45IE1pQi9z KQ0KIyMgU3RhcnRpbmcgYXBwbGljYXRpb24gYXQgMHg4ODAwMDA1NCAuLi4NCkNvbnNvbGVzOiBV LUJvb3QgY29uc29sZSAgDQpDb21wYXRpYmxlIFUtQm9vdCBBUEkgc2lnbmF0dXJlIGZvdW5kIEA5 ZjYzODUxMA0KDQpGcmVlQlNEL2FybXY2IFUtQm9vdCBsb2FkZXIsIFJldmlzaW9uIDEuMg0KKHRv c2hpQGZic2QsIFdlZCBNYXkgMjEgMjM6MzM6MjYgSlNUIDIwMTQpDQoNCkRSQU06IDUxMk1CDQp2 dnZ2dnZ2dnZ2dnZOdW1iZXIgb2YgVS1Cb290IGRldmljZXM6IDMgIDwtIGRldGVjdCBTRCwgZU1N QywgbmV0LiB0aGFua3MgY3JvY2hldCBmb3IgcGF0Y2hlcyENClUtQm9vdCBlbnY6IGxvYWRlcmRl dj0nZGlzaycNCkZvdW5kIFUtQm9vdCBkZXZpY2U6IGRpc2sNCiAgUHJvYmluZyBhbGwgZGlzayBk ZXZpY2VzLi4uDQogIENoZWNraW5nIHVuaXQ9MCBzbGljZT08YXV0bz4gcGFydGl0aW9uPTxhdXRv Pi4uLnZ2ZGlzazA6IGRldmljZSBvcGVuIGZhaWxlZCB3aXRoIGVycm9yPTIsIGhhbmRsZT0xDQoN CiAgQ2hlY2tpbmcgdW5pdD0xIHNsaWNlPTxhdXRvPiBwYXJ0aXRpb249PGF1dG8+Li4udnYudnZ2 di52dnZ2LnZ2dnYudnZ2diBnb29kLg0KLnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2 dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2 LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52 dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2 di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYu dnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2 dnYudnZ2di52dnZ2TG9hZGluZyAvYm9vdC9kZWZhdWx0cy9sb2FkZXIuY29uZiANCi52dnZ2LnZ2 dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2 LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52 dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2 di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYu dnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2 dnYudnZ2di52dnZ2L2Jvb3Qva2VybmVsL2tlcm5lbCBkYXRhPTB4NDZmYmM4KzB4MmM0NDM4IC52 dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2 di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYu dnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2 dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2 LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52 dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2 di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYu dnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2 dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2 LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52 dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2 di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYu dnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnZzeW1zPVsweDQrMHg4NWY0MC52dnZ2LnZ2dnYu dnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2 dnYudnZ2di52dnZ2LnZ2dnYrMHg0KzB4NTBkZDUudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2 dnYudnZ2di52dnZ2LnZ2dnYudnZ2dl0NCi52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52 dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2 di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2L2Jvb3Qva2VybmVsL2dlb21fbGFi ZWwua28gdGV4dD0weDUwNTQgZGF0YT0weDg1YysweDMwIHN5bXM9WzB4NCsweDEwMjArMHg0KzB4 ZmUyLnZ2dnZdDQoNCkhpdCBbRW50ZXJdIHRvIGJvb3QgaW1tZWRpYXRlbHksIG9yIGFueSBvdGhl ciBrZXkgZm9yIGNvbW1hbmQgcHJvbXB0Lg0KQm9vdGluZyBbL2Jvb3Qva2VybmVsL2tlcm5lbF0u Li4gICAgICAgICAgICAgICANCi52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2 dnYudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnZVc2luZyBEVEIgY29tcGlsZWQgaW50byBr ZXJuZWwuDQoudnZ2di52dnZ2LnZ2dnYudnZ2di52dnZ2LnZ2dnYudnZ2dktlcm5lbCBlbnRyeSBh dCAweDgwMjAwMTAwLi4uDQpLZXJuZWwgYXJnczogKG51bGwpDQpLREI6IGRlYnVnZ2VyIGJhY2tl bmRzOiBkZGINCktEQjogY3VycmVudCBiYWNrZW5kOiBkZGINCkNvcHlyaWdodCAoYykgMTk5Mi0y MDE0IFRoZSBGcmVlQlNEIFByb2plY3QuDQpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMs IDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQNCglUaGUgUmVnZW50cyBv ZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KRnJl ZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24u DQpGcmVlQlNEIDExLjAtQ1VSUkVOVCAjNDEgcjI2NTg3NjoyNjY0OTRNOiBUaHUgTWF5IDIyIDA4 OjE4OjQ5IEpTVCAyMDE0DQogICAgdG9zaGlAZmJzZDovdXNyL29iai9hcm0uYXJtdjYvdXNyL3Ny Yy9zeXMvQkVBR0xFQk9ORSBhcm0NCkZyZWVCU0QgY2xhbmcgdmVyc2lvbiAzLjQgKHRhZ3MvUkVM RUFTRV8zNC9maW5hbCAxOTc5NTYpIDIwMTQwMjE2DQpXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBl bmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4NCkNQVTogQ29ydGV4IEE4LXIzIHJl diAyIChDb3J0ZXgtQSBjb3JlKQ0KIFN1cHBvcnRlZCBmZWF0dXJlczogQVJNX0lTQSBUSFVNQjIg SkFaRUxMRSBUSFVNQkVFIEFSTXY0IFNlY3VyaXR5X0V4dA0KIFdCIGRpc2FibGVkIEVBQlQgYnJh bmNoIHByZWRpY3Rpb24gZW5hYmxlZA0KTG9VVToyIExvQzoyIExvVUlTOjEgDQpDYWNoZSBsZXZl bCAxOiANCiAzMktCLzY0QiA0LXdheSBkYXRhIGNhY2hlIFdUIFdCIFJlYWQtQWxsb2MNCiAzMktC LzY0QiA0LXdheSBpbnN0cnVjdGlvbiBjYWNoZSBSZWFkLUFsbG9jDQpDYWNoZSBsZXZlbCAyOiAN CiAyNTZLQi82NEIgOC13YXkgdW5pZmllZCBjYWNoZSBXVCBXQiBSZWFkLUFsbG9jIFdyaXRlLUFs bG9jDQpyZWFsIG1lbW9yeSAgPSA1MzY4NzA5MTIgKDUxMiBNQikNCmF2YWlsIG1lbW9yeSA9IDUx NDA0MzkwNCAoNDkwIE1CKQ0KVGV4YXMgSW5zdHJ1bWVudHMgQU0zMzU4IFByb2Nlc3NvciwgUmV2 aXNpb24gRVMxLjENCnJhbmRvbSBkZXZpY2Ugbm90IGxvYWRlZDsgdXNpbmcgaW5zZWN1cmUgZW50 cm9weQ0KcmFuZG9tOiA8U29mdHdhcmUsIFlhcnJvdz4gaW5pdGlhbGl6ZWQNCm9md2J1czA6IDxP cGVuIEZpcm13YXJlIERldmljZSBUcmVlPg0Kc2ltcGxlYnVzMDogPEZsYXR0ZW5lZCBkZXZpY2Ug dHJlZSBzaW1wbGUgYnVzPiBvbiBvZndidXMwDQphaW50YzA6IDxUSSBBSU5UQyBJbnRlcnJ1cHQg Q29udHJvbGxlcj4gbWVtIDB4NDgyMDAwMDAtMHg0ODIwMGZmZiBvbiBzaW1wbGVidXMwDQphaW50 YzA6IFJldmlzaW9uIDUuMA0KdGlfc2NtMDogPFRJIENvbnRyb2wgTW9kdWxlPiBtZW0gMHg0NGUx MDAwMC0weDQ0ZTExZmZmIG9uIHNpbXBsZWJ1czANCmFtMzM1eF9wcmNtMDogPEFNMzM1eCBQb3dl ciBhbmQgQ2xvY2sgTWFuYWdlbWVudD4gbWVtIDB4NDRlMDAwMDAtMHg0NGUwMTJmZiBvbiBzaW1w bGVidXMwDQphbTMzNXhfcHJjbTA6IENsb2NrczogU3lzdGVtIDI0LjAgTUh6LCBDUFUgMTAwMCBN SHoNCmFtMzM1eF9kbXRpbWVyMDogPEFNMzM1eCBETVRpbWVyPiBtZW0gMHg0NGUwNTAwMC0weDQ0 ZTA1ZmZmLDB4NDRlMzEwMDAtMHg0NGUzMWZmZiwweDQ4MDQwMDAwLTB4NDgwNDBmZmYsMHg0ODA0 MjAwMC0weDQ4MDQyZmZmLDB4NDgwNDQwMDAtMHg0ODA0NGZmZiwweDQ4MDQ2MDAwLTB4NDgwNDZm ZmYsMHg0ODA0ODAwMC0weDQ4MDQ4ZmZmLDB4NDgwNGEwMDAtMHg0ODA0YWZmZiBpcnEgNjYsNjcs NjgsNjksOTIsOTMsOTQsOTUgb24gc2ltcGxlYnVzMA0KVGltZWNvdW50ZXIgIkFNMzM1eCBUaW1l Y291bnRlciIgZnJlcXVlbmN5IDI0MDAwMDAwIEh6IHF1YWxpdHkgMTAwMA0KRXZlbnQgdGltZXIg IkFNMzM1eCBFdmVudHRpbWVyIiBmcmVxdWVuY3kgMjQwMDAwMDAgSHogcXVhbGl0eSAxMDAwDQp0 aV9hZGMwOiA8VEkgQURDIGNvbnRyb2xsZXI+IG1lbSAweDQ0ZTBkMDAwLTB4NDRlMGVmZmYgaXJx IDE2IG9uIHNpbXBsZWJ1czANCnRpX2FkYzA6IHNjaGVtZTogMHgxIGZ1bmM6IDB4NzMwIHJ0bDog MCByZXY6IDAuMSBjdXN0b20gcmV2OiAwDQpncGlvMDogPFRJIEdlbmVyYWwgUHVycG9zZSBJL08g KEdQSU8pPiBtZW0gMHg0NGUwNzAwMC0weDQ0ZTA3ZmZmLDB4NDgwNGMwMDAtMHg0ODA0Y2ZmZiww eDQ4MWFjMDAwLTB4NDgxYWNmZmYsMHg0ODFhZTAwMC0weDQ4MWFlZmZmIGlycSA5Niw5Nyw5OCw5 OSwzMiwzMyw2Miw2MyBvbiBzaW1wbGVidXMwDQpncGlvYzA6IDxHUElPIGNvbnRyb2xsZXI+IG9u IGdwaW8wDQpncGlvYnVzMDogPE9GVyBHUElPIGJ1cz4gb24gZ3BpbzANCmdwaW9sZWQwOiA8R1BJ TyBsZWQ+IGF0IHBpbihzKSA1MyBvbiBncGlvYnVzMA0KZ3Bpb2xlZDE6IDxHUElPIGxlZD4gYXQg cGluKHMpIDU0IG9uIGdwaW9idXMwDQpncGlvbGVkMjogPEdQSU8gbGVkPiBhdCBwaW4ocykgNTUg b24gZ3Bpb2J1czANCmdwaW9sZWQzOiA8R1BJTyBsZWQ+IGF0IHBpbihzKSA1NiBvbiBncGlvYnVz MA0KdWFydDA6IDxUSSBVQVJUICgxNjU1MCBjb21wYXRpYmxlKT4gbWVtIDB4NDRlMDkwMDAtMHg0 NGUwOWZmZiBpcnEgNzIgb24gc2ltcGxlYnVzMA0KdWFydDA6IGNvbnNvbGUgKDExNTM4NCxuLDgs MSkNCnRpX2VkbWEzMDogPFRJIEVETUEgQ29udHJvbGxlcj4gbWVtIDB4NDkwMDAwMDAtMHg0OTBm ZmZmZiwweDQ5ODAwMDAwLTB4NDk4ZmZmZmYsMHg0OTkwMDAwMC0weDQ5OWZmZmZmLDB4NDlhMDAw MDAtMHg0OWFmZmZmZiBpcnEgMTIsMTMsMTQgb24gc2ltcGxlYnVzMA0KdGlfZWRtYTMwOiBFRE1B IHJldmlzaW9uIDQwMDE0YzAwDQpzZGhjaV90aTA6IDxUSSBNTUNIUyAoU0RIQ0kgMi4wKT4gbWVt IDB4NDgwNjAwMDAtMHg0ODA2MGZmZiBpcnEgNjQgb24gc2ltcGxlYnVzMA0Kc2RoY2lfdGkxOiA8 VEkgTU1DSFMgKFNESENJIDIuMCk+IG1lbSAweDQ4MWQ4MDAwLTB4NDgxZDhmZmYgaXJxIDI4IG9u IHNpbXBsZWJ1czANCm1tYzA6IDxNTUMvU0QgYnVzPiBvbiBzZGhjaV90aTENCmNwc3cwOiA8My1w b3J0IFN3aXRjaCBFdGhlcm5ldCBTdWJzeXN0ZW0+IG1lbSAweDRhMTAwMDAwLTB4NGExMDNmZmYg aXJxIDQwLDQxLDQyLDQzIG9uIHNpbXBsZWJ1czANCmNwc3cwOiBDUFNXIFNTIFZlcnNpb24gMS4x MiAoMCkNCmNwc3cwOiBJbml0aWFsIHF1ZXVlIHNpemUgVFg9MTI4IFJYPTM4NA0KY3BzdzA6IEV0 aGVybmV0IGFkZHJlc3M6IGM4OmEwOjMwOmFmOmE3OjM0DQptaWlidXMwOiA8TUlJIGJ1cz4gb24g Y3BzdzANCnNtc2NwaHkwOiA8U01DIExBTjg3MTBBIDEwLzEwMCBpbnRlcmZhY2U+IFBIWSAwIG9u IG1paWJ1czANCnNtc2NwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAw YmFzZVRYLUZEWCwgYXV0bw0KaWljaGIwOiA8VEkgSTJDIENvbnRyb2xsZXI+IG1lbSAweDQ0ZTBi MDAwLTB4NDRlMGJmZmYgaXJxIDcwIG9uIHNpbXBsZWJ1czANCmlpY2hiMDogSTJDIHJldmlzaW9u IDQuMA0KaWljYnVzMDogPE9GVyBJMkMgYnVzPiBvbiBpaWNoYjANCmlpYzA6IDxJMkMgZ2VuZXJp YyBJL08+IG9uIGlpY2J1czANCmFtMzM1eF9wbWljMDogPFRJIFRQUzY1MjE3IFBvd2VyIE1hbmFn ZW1lbnQgSUM+IGF0IGFkZHIgMHgyNCBvbiBpaWNidXMwDQppaWNoYjE6IDxUSSBJMkMgQ29udHJv bGxlcj4gbWVtIDB4NDgwMmEwMDAtMHg0ODAyYWZmZiBpcnEgNzEgb24gc2ltcGxlYnVzMA0KaWlj aGIxOiBJMkMgcmV2aXNpb24gNC4wDQppaWNidXMxOiA8T0ZXIEkyQyBidXM+IG9uIGlpY2hiMQ0K aWljMTogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVzMQ0KaWljaGIyOiA8VEkgSTJDIENvbnRy b2xsZXI+IG1lbSAweDQ4MTljMDAwLTB4NDgxOWNmZmYgaXJxIDMwIG9uIHNpbXBsZWJ1czANCmlp Y2hiMjogSTJDIHJldmlzaW9uIDQuMA0KaWljYnVzMjogPE9GVyBJMkMgYnVzPiBvbiBpaWNoYjIN CmlpYzI6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czINCmFtMzM1eF9wd20wOiA8QU0zMzV4 IFBXTT4gbWVtIDB4NDgzMDAwMDAtMHg0ODMwMDBmZiwweDQ4MzAwMTAwLTB4NDgzMDAxN2YsMHg0 ODMwMDE4MC0weDQ4MzAwMWZmLDB4NDgzMDAyMDAtMHg0ODMwMDI1ZiBpcnEgODYsNTggb24gc2lt cGxlYnVzMA0KYW0zMzV4X3B3bTE6IDxBTTMzNXggUFdNPiBtZW0gMHg0ODMwMjAwMC0weDQ4MzAy MGZmLDB4NDgzMDIxMDAtMHg0ODMwMjE3ZiwweDQ4MzAyMTgwLTB4NDgzMDIxZmYsMHg0ODMwMjIw MC0weDQ4MzAyMjVmIGlycSA4Nyw1OSBvbiBzaW1wbGVidXMwDQphbTMzNXhfcHdtMjogPEFNMzM1 eCBQV00+IG1lbSAweDQ4MzA0MDAwLTB4NDgzMDQwZmYsMHg0ODMwNDEwMC0weDQ4MzA0MTdmLDB4 NDgzMDQxODAtMHg0ODMwNDFmZiwweDQ4MzA0MjAwLTB4NDgzMDQyNWYgaXJxIDg4LDYwIG9uIHNp bXBsZWJ1czANCm11c2JvdGcwOiA8VEkgQU0zM3h4IGludGVncmF0ZWQgVVNCIE9URyBjb250cm9s bGVyPiBtZW0gMHg0NzQwMDAwMC0weDQ3NDAwZmZmLDB4NDc0MDEwMDAtMHg0NzQwMTJmZiwweDQ3 NDAxMzAwLTB4NDc0MDEzZmYsMHg0NzQwMTQwMC0weDQ3NDAxN2ZmLDB4NDc0MDE4MDAtMHg0NzQw MWFmZiwweDQ3NDAxYjAwLTB4NDc0MDFiZmYsMHg0NzQwMWMwMC0weDQ3NDAxZmZmIGlycSAxNywx OCwxOSBvbiBzaW1wbGVidXMwDQptdXNib3RnMDogIQ0KbXVzYm90ZzA6IFRJIEFNMzM1WCBVU0JT UyB2MC4wLjEzDQp1c2J1czA6IER5bmFtaWMgRklGTyBzaXppbmcgZGV0ZWN0ZWQsIGFzc3VtaW5n IDE2S2J5dGVzIG9mIEZJRk8gUkFNDQp1c2J1czAgb24gbXVzYm90ZzANCnVzYnVzMTogRHluYW1p YyBGSUZPIHNpemluZyBkZXRlY3RlZCwgYXNzdW1pbmcgMTZLYnl0ZXMgb2YgRklGTyBSQU0NCnVz YnVzMSBvbiBtdXNib3RnMA0KdGlfcHJ1c3MwOiA8VEkgUHJvZ3JhbW1hYmxlIFJlYWx0aW1lIFVu aXQgU3Vic3lzdGVtPiBtZW0gMHg0YTMwMDAwMC0weDRhMzdmZmZmIGlycSAyMCwyMSwyMiwyMywy NCwyNSwyNiwyNyBvbiBzaW1wbGVidXMwDQp0aV9wcnVzczA6IEFNMzN4eCBQUlUtSUNTUw0KVGlt ZWNvdW50ZXJzIHRpY2sgZXZlcnkgMTAuMDAwIG1zZWMNCnVzYnVzMDogNDgwTWJwcyBIaWdoIFNw ZWVkIFVTQiB2Mi4wDQp1c2J1czE6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMA0KdWdlbjEu MTogPE1lbnRvciBHcmFwaGljcz4gYXQgdXNidXMxDQp1aHViMDogPE1lbnRvciBHcmFwaGljcyBP VEcgUm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEN CnVnZW4wLjE6IDxNZW50b3IgR3JhcGhpY3M+IGF0IHVzYnVzMA0KdWh1YjE6IDxNZW50b3IgR3Jh cGhpY3MgT1RHIFJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXMwDQp1aHViMTogMSBwb3J0IHdpdGggMSByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1 YjA6IDEgcG9ydCB3aXRoIDEgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCm1tY3NkMDogMkdCIDxN TUMgTU1DMDJHIDMuMTAgU04gNDA0MjQ1NzU2IE1GRyAxMi8yMDEyIGJ5IDI1NCAweDAwNGU+IGF0 IG1tYzAgNDguME1Iei84Yml0LzY1NTM1LWJsb2NrDQphbTMzNXhfcG1pYzA6IFRQUzY1MjE3QyB2 ZXIgMS4yIHBvd2VyZWQgYnkgQUMNCnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuDQpXQVJOSU5H OiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4NClRy eWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvdWZzL2VNTUNyb290IFtydyxub2F0aW1l XS4uLg0Kd2FybmluZzogbm8gdGltZS1vZi1kYXkgY2xvY2sgcmVnaXN0ZXJlZCwgc3lzdGVtIHRp bWUgd2lsbCBub3QgYmUgc2V0IGFjY3VyYXRlbHkNClNldHRpbmcgaG9zdHV1aWQ6IGIzYTc3Yzk1 LWRhYWEtMTFlMy04OWRlLWM4YTAzMGFmYTczNC4NClNldHRpbmcgaG9zdGlkOiAweDUzOTFhMzBm Lg0KTm8gc3VpdGFibGUgZHVtcCBkZXZpY2Ugd2FzIGZvdW5kLg0KRW50cm9weSBoYXJ2ZXN0aW5n OiBpbnRlcnJ1cHRzIGV0aGVybmV0IHBvaW50X3RvX3BvaW50IHN3aS4NClN0YXJ0aW5nIGZpbGUg c3lzdGVtIGNoZWNrczoNCi9kZXYvdWZzL2VNTUNyb290OiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJ UFBJTkcgQ0hFQ0tTDQovZGV2L3Vmcy9lTU1Dcm9vdDogY2xlYW4sIDM1Mjk1OSBmcmVlICgyMTI3 IGZyYWdzLCA0Mzg1NCBibG9ja3MsIDAuNSUgZnJhZ21lbnRhdGlvbikNCk1vdW50aW5nIGxvY2Fs IGZpbGUgc3lzdGVtczouDQpXcml0aW5nIGVudHJvcHkgZmlsZTouDQpTZXR0aW5nIGhvc3RuYW1l OiBiZWFnbGVib25lLg0KY3BzdzA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQpTdGFydGlu ZyBOZXR3b3JrOiBsbzAgY3BzdzAuDQpsbzA6IGZsYWdzPTgwNDk8VVAsTE9PUEJBQ0ssUlVOTklO RyxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNjM4NA0KCW9wdGlvbnM9NjAwMDAzPFJYQ1NVTSxU WENTVU0sUlhDU1VNX0lQVjYsVFhDU1VNX0lQVjY+DQoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjgg DQoJaW5ldDYgZmU4MDo6MSVsbzAgcHJlZml4bGVuIDY0IHNjb3BlaWQgMHgyIA0KCWluZXQgMTI3 LjAuMC4xIG5ldG1hc2sgMHhmZjAwMDAwMCANCgluZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFV VE9fTElOS0xPQ0FMPg0KY3BzdzA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lN UExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwDQoJb3B0aW9ucz04MDAwYjxSWENTVU0s VFhDU1VNLFZMQU5fTVRVLExJTktTVEFURT4NCglldGhlciBjODphMDozMDphZjphNzozNA0KCW1l ZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0IChub25lKQ0KCXN0YXR1czogbm8gY2Fycmllcg0KCW5k NiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4NClN0YXJ0 aW5nIGRldmQuDQpTdGFydGluZyBwZmxvZ2Q6IA0KYWRkIG5ldCBmZTgwOjo6IGdhdGV3YXkgOjox DQphZGQgbmV0IGZmMDI6OjogZ2F0ZXdheSA6OjENCmFkZCBuZXQgOjpmZmZmOjAuMC4wLjA6IGdh dGV3YXkgOjoxDQphZGQgbmV0IDo6MC4wLjAuMDogZ2F0ZXdheSA6OjENCldhaXRpbmcgMzBzIGZv ciB0aGUgZGVmYXVsdCByb3V0ZSBpbnRlcmZhY2U6IC4uLi4uKG5vIGNhcnJpZXIpDQpDcmVhdGlu ZyBhbmQvb3IgdHJpbW1pbmcgbG9nIGZpbGVzLg0KU3RhcnRpbmcgc3lzbG9nZC4NCkVMRiBsZGNv bmZpZyBwYXRoOiAvbGliIC91c3IvbGliIC91c3IvbGliL2NvbXBhdA0KU3RhcnRpbmcgY2FzcGVy ZC4NCkNsZWFyaW5nIC90bXAgKFggcmVsYXRlZCkuDQpVcGRhdGluZyBtb3RkOi4NCk1vdW50aW5n IGxhdGUgZmlsZSBzeXN0ZW1zOi4NClBlcmZvcm1pbmcgc2FuaXR5IGNoZWNrIG9uIHNzaGQgY29u ZmlndXJhdGlvbi4NClN0YXJ0aW5nIHNzaGQuDQpTdGFydGluZyBjcm9uLg0KU3RhcnRpbmcgYmFj a2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVja3MgaW4gNjAgc2Vjb25kcy4NCg0KVGh1IE1heSAyMiAw MDowOTozNCBVVEMgMjAxNA0KDQpGcmVlQlNEL2FybSAoYmVhZ2xlYm9uZSkgKHR0eXUwKQ0KDQps b2dpbjogDQoNCi0tIA0KU0FJVE9VIFRvc2hpaGlkZQ0K From owner-freebsd-arm@FreeBSD.ORG Thu May 22 14:07:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31329C9 for ; Thu, 22 May 2014 14:07:41 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8DED2582 for ; Thu, 22 May 2014 14:07:40 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id tp5so3602416ieb.17 for ; Thu, 22 May 2014 07:07:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LczVCx5BMuP+rR2c47x5bCJk7lGYm9rNmfVoVLV8R4Q=; b=U76pBNrcF/sm05ak7kam11kNmJg8OnkHk5lUnLPX5/buiJfSRj8c70wyHa2IRxAKuF vFwL3YFvQr477QvDh9ZsjEMv0fnowU5k8BFrht5Z+KUfWNS8/tUcVmmP7KRu1g0QAIm5 nzYh2EOzU+j8nVp4U3g00v0LHPhJ8dag1KbUgF8vaAd42YRujLgvLp9GatpdvC8uBKH5 GKtWd3fIseH5SPd/Ch/frJNt5Hz9Sn7SnwRvfGg6Gcjbk54X3s/7SjwtSFCYHJI8iPS7 ugeJ8jrTJBK3ey+Vdbjv4wpLmLs+qm7KNAsEdCHzvv53XDl3+N7dUga4DAaYdGB84L4h 39YA== X-Gm-Message-State: ALoCoQkER2khhMGyXKjb2H2dSCOP3psv3MWHVxAvt38djKo4sdj8iPxCeQaC9QhRqkTS4/f6oTQy X-Received: by 10.42.93.193 with SMTP id y1mr43808515icm.12.1400767653992; Thu, 22 May 2014 07:07:33 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ie20sm716496igb.10.2014.05.22.07.07.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 07:07:32 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_A896CEBB-6B77-4AC3-A02C-044A35641B1A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: MK_ARM_EABI to retire in current From: Warner Losh In-Reply-To: <20140522090504.GA22488@zibbi.meraka.csir.co.za> Date: Thu, 22 May 2014 08:07:34 -0600 Message-Id: <5D4F0BD5-89DA-421F-B095-A5F2C49F3DF9@bsdimp.com> References: <20140521192807.GA48338@zibbi.meraka.csir.co.za> <95AD97BA-AA48-4BBF-845C-D0CB585ACAA3@bsdimp.com> <20140522090504.GA22488@zibbi.meraka.csir.co.za> To: John Hay X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:07:41 -0000 --Apple-Mail=_A896CEBB-6B77-4AC3-A02C-044A35641B1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 22, 2014, at 3:05 AM, John Hay wrote: > On Wed, May 21, 2014 at 02:01:42PM -0600, Warner Losh wrote: >>=20 >> On May 21, 2014, at 1:28 PM, John Hay wrote: >>=20 >>> On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: >>>> isn't eabi on the xscale still broken? >>>=20 >>> It might still be broken. But there are more brokenness than that. = :-( >>> By defining WITHOUT_ARM_EABI=3Dyes in src.conf, I can get an AVILA = kernel >>> built that boots with src from head at around mid December. Latest = 10 >>> and head just give no output, with or without WITHOUT_ARM_EABI = defined. >>=20 >> Does the same thing happen with make.conf instead of src.conf? >=20 > Yes, I have tried both 10 and head with WITHOUT_ARM_EABI=3Dyes and no > output after go in redboot. My compile lines look like this: >=20 > make TARGET_ARCH=3Darmeb TARGET_CPUTYPE=3Dxscale toolchain > make TARGET=3Darm TARGET_ARCH=3Darmeb buildkernel KERNCONF=3DAVILA = DESTDIR=3D/arm/ >=20 > And then in redboot "load -b 0x200000 kernel" to load it with tftp. = And > then "go". >=20 > The "no output" happened somewhere between mid December and beginning > of Feb. I determined that before getting side tracked. I'll see in the > next day or two if I can narrow that down. >=20 > If someone have patches so that WITHOUT_ARM_EABI=3Dyes is not needed > anymore, I'll test that too. This is with gcc, not clang, right? Warner > John >=20 >>=20 >> Warner >>=20 >>> John >>>=20 >>>>=20 >>>>=20 >>>> -a >>>>=20 >>>>=20 >>>> On 19 May 2014 08:40, Warner Losh wrote: >>>>> Greetings, >>>>>=20 >>>>> MK_ARM_EABI is going to die in current. It is the default for all = platforms currently. I???m eliminating it as a build option. It must die = because it invisibly (to uname) effects the ABI. >>>>>=20 >>>>> So, to that end, I see two options: >>>>>=20 >>>>> (1) Retire and remove oabi support. >>>>> (2) Retain oabi support, but change its name to armo and armoeb. >>>>>=20 >>>>> The rough consensus of arm developers I???ve polled now, and in = the past, is that we just let oabi support die now that EABI support is = working for everybody. >>>>>=20 >>>>> Before I pull the trigger on this, however, I must ask if anybody = has a problem with my doing option (1), and if so, what keeps you using = oabi. >>>>>=20 >>>>> Comments? >>>>>=20 >>>>> Warner >>>>>=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" >>>> _______________________________________________ >>>> 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" --Apple-Mail=_A896CEBB-6B77-4AC3-A02C-044A35641B1A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTfgSmAAoJEGwc0Sh9sBEA1n0QAKczRTEdF0GnlH+NjqqlgQt0 FVsKAyB3CNCuC9xjqv9pTfcMH6NwBIjRGbtfDdqlp77JEjR4Os7WjIc/OIWMD3dF C1q2bkn8RHq4jafguaGfPjnVFF2AaSroHE1ICT3YXcpIAaZ237UKN7++zIN2QEbw K9mzf33RWs+U+N1tPJ31nHG8w1Yzeu5QF83vURQLE1Iq9bZ7oBONHI3MZhjibheK 3aIvpzTis0ctmvyI8KXoRzH7UhuDCnmIbE2UMaz5RzEwEzIb0bDxVlCCF9/F8B6i iqCTkubS4BBzucEK0MPPwwN2oQ5qhKg1+5W/nKKwWSZTwZ5UnAPcpqFrU+2Y3iW5 bcN98iE/nwx/mshDBCxFt67ymQ7/oH+LWIpOFFobiutSbKV6w/LuvkH262U6Q0+7 +eLZ1+LlogIsK0nWGvaTnjwEXn9k0xLJKgDKleXFmI/1a0fygPhQBO/D5CwPQIKb L8DDnH/yW3bPE5GXJ9jMobfPzP+SGkfi4/BNpculsurtpwrqSjwdapyjyv6lNc2G /GSBz5Fjvqn+oXrJyPp1GUwee3Gs1Ob9qccpAE9E/xwwP0F9kB/n5GwyRkwZq0Zu 0MQ/+k1e99X+CmApoX9bgU4vk5n7SMrTMFmwzO5muE0yce9G3Bxd1LxXTvbIt1+s F2i00pqdO0TVqGbQ5GwO =WpTB -----END PGP SIGNATURE----- --Apple-Mail=_A896CEBB-6B77-4AC3-A02C-044A35641B1A-- From owner-freebsd-arm@FreeBSD.ORG Thu May 22 14:14:09 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFDDA5F7; Thu, 22 May 2014 14:14:09 +0000 (UTC) Received: from msgw001-05.ocn.ad.jp (msgw001-05.ocn.ad.jp [180.37.203.74]) by mx1.freebsd.org (Postfix) with ESMTP id 72AA9264A; Thu, 22 May 2014 14:14:09 +0000 (UTC) Received: from localhost (p12095-ipngn100104sizuokaden.shizuoka.ocn.ne.jp [153.185.230.95]) by msgw001-05.ocn.ad.jp (Postfix) with ESMTP id D81E4A82C2B; Thu, 22 May 2014 23:14:07 +0900 (JST) Date: Thu, 22 May 2014 23:14:04 +0900 (JST) Message-Id: <20140522.231404.174358702.toshi@ruby.ocn.ne.jp> To: ian@FreeBSD.org Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <1400764684.1152.218.camel@revolution.hippie.lan> References: <1400708280.1152.199.camel@revolution.hippie.lan> <20140522.203923.240655619.toshi@ruby.ocn.ne.jp> <1400764684.1152.218.camel@revolution.hippie.lan> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:14:09 -0000 In message: <1400764684.1152.218.camel@revolution.hippie.lan> Ian Lepore writes: > On Thu, 2014-05-22 at 20:39 +0900, SAITOU Toshihide wrote: >> In message: <1400708280.1152.199.camel@revolution.hippie.lan> >> Ian Lepore writes: >> > On Tue, 2014-05-20 at 23:42 +0900, SAITOU Toshihide wrote: >> >> In message: <537B62D1.4090901@hot.ee> >> >> "Sulev-Madis Silber (ketas)" writes: >> >> > On 2014-05-20 15:20, SAITOU Toshihide wrote: >> >> >> In message: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> >> >> >> SAITOU Toshihide writes: >> >> >>> In message: <537ACDB2.9080808@hot.ee> >> >> >>> "Sulev-Madis Silber (ketas)" writes: >> >> >>>> >> >> >>>> Actually I guess many people might think like me... "HELL, optimizing >> >> >>>> boot time of 1min?! I have more important tasks to do than this". >> >> >>> >> >> >>> If you have ``device sdhci'' line in conf/BEAGLEBONE, is there any >> >> >>> differences by changing mmchs to sdhci in am335x.dtsi and >> >> >>> beaglebone-black.dts? And also remove ``status = "disabled"'' >> >> > >> >> > Don't edit am335x.dtsi >> >> > >> >> > And beaglebone-black.dts already has proper config. >> >> >> >> In this case, how does ``device sdhci'' driver know the register address? >> >> I thought that there is an inconsistency in BEAGLEBONE config and >> >> dts file for the SD/MMC driver. >> > >> > The name@address tag in the dts[i] files doesn't have to match the >> > driver name in the kernel config. What matters for matching the driver >> > to the right entry in the dts is the "compatible=" property. The >> > ti_sdhci driver looks for an entry with any one of these compatible >> > strings: >> > >> > "ti,omap3-hsmmc", "ti,omap4-hsmmc", "ti,mmchs" >> >> Ah! I see ti_sdhci.c has ofw_bus_is_compatible(dev, "ti,mmchs"). >> (Why I felt difference of eMMC detection... Hmm...) > > What version of source code are you using to see that? You should be > seeing a ofw_bus_search_compatible() call using a table of compatible > strings that has those entries I listed. FreeBSD 11.0-CURRENT #41 r265876:266494M: Thu May 22 08:18:49 JST 2014 but ti_sdhci.c is 254559 I am suprised. I will try at the weekend. -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Thu May 22 14:15:55 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1BCE685; Thu, 22 May 2014 14:15:55 +0000 (UTC) Received: from msgw002-04.ocn.ad.jp (msgw002-04.ocn.ad.jp [180.37.203.79]) by mx1.freebsd.org (Postfix) with ESMTP id 9F489266E; Thu, 22 May 2014 14:15:55 +0000 (UTC) Received: from localhost (p12095-ipngn100104sizuokaden.shizuoka.ocn.ne.jp [153.185.230.95]) by msgw002-04.ocn.ad.jp (Postfix) with ESMTP id 2EC37FFD1; Thu, 22 May 2014 23:15:54 +0900 (JST) Date: Thu, 22 May 2014 23:15:53 +0900 (JST) Message-Id: <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> To: ian@FreeBSD.org Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <1400765234.1152.224.camel@revolution.hippie.lan> References: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <1400765234.1152.224.camel@revolution.hippie.lan> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:15:55 -0000 In message: <1400765234.1152.224.camel@revolution.hippie.lan> Ian Lepore writes: > On Thu, 2014-05-22 at 20:46 +0900, SAITOU Toshihide wrote: >> In message: >> Winston Smith writes: >> > On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: >> >> If abort like >> >> >> >> musbotg0: TI AM335X USBSS v0.0.13 >> >> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' >> >> trapframe: 0xc0a2eb60 >> > >> > I see this with the 1Ghz uboot, it occurs about 50% of the time, see: >> > >> > http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 >> >> Although it is an ad hoc workaround but ``usb start'' at u-boot command >> prompt (someone mentioned before) or add device_printf("!\n") before >> ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of >> am335x_usbss.c prevent this panic for me. > > An 'external non-linefetch abort' on a TI chip usually means that the > clocks for a device never got turned on and you attempted to read or > write a register in that device. If 'usb start' makes the problem go > away, that tends to confirm that thought. > > The thing is, I don't understand why adding a printf to the code with no > other changes would help in any way. I though maybe it was adding some > delay to allow the clock-start call to take effect, but the clock enable > call is after the USBSS_REVREG read, and that seems wrong. > > Does it fix the problem to move the ti_prcm_clk_enable() call to be > before the USBSS_REVREG read in attach? I will try ti_prcm_clk_enable() at the weekend. But someone's report would be appriciated because I remove the src and svn up now. -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Thu May 22 14:19:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F703996 for ; Thu, 22 May 2014 14:19:20 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C42B62695 for ; Thu, 22 May 2014 14:19:19 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id z12so3515584wgg.24 for ; Thu, 22 May 2014 07:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K+6UoSqJ6vlfLiyBLjMXW339p9JgJZxnyYO5uaUGtcM=; b=dtExBHOrPFp1e8m0TBWLHp16YppV5A8JS4V3Qfb1E+iXab/68dD1BJsbbffffC92OH rqzvvHEPr6I6iSLNwilY1iCFYKnyh3meOvlvanJKIPgEgsJBBCAo7/J988b1eqOJiUJX t4+7KQ0fSzwxKSK+3munnkdMsajXTFeGMtZwFjkSHzBNDvlLBpJmojDETesr3t2UQCg+ AQrr18Z++1XdUBJUDndCVI1zOXNsNHhaQjQxrOpKAaydKZOem62sQgnVga7eMSUG64cr DZK3sRrxo4/gKVWroCLvKuusDA3iq4X+a9sShs6bvST0tE9a9MIAMIDgpYBqGAJFQtMk jung== MIME-Version: 1.0 X-Received: by 10.180.12.238 with SMTP id b14mr16965965wic.16.1400768357921; Thu, 22 May 2014 07:19:17 -0700 (PDT) Received: by 10.216.40.72 with HTTP; Thu, 22 May 2014 07:19:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 11:19:17 -0300 Message-ID: Subject: Re: Beaglebone Black. PWM minimum frequency of 1.52KHz From: Luiz Otavio O Souza To: fabiodive Content-Type: multipart/mixed; boundary=001a11c3669263125b04f9fdcc1b Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:19:20 -0000 --001a11c3669263125b04f9fdcc1b Content-Type: text/plain; charset=UTF-8 On 10 May 2014 08:56, fabiodive wrote: > Hello, > > PWM on Beaglebone Black > > during my laboratory tests I was not able to setup a frequency suitable for servo motors. > I tried several times with many values but the results was always the same. > The minimal frequency I was able to achieve was 1.52 KHz. > Also, I noticed odd results with the most of configuration values, in this case > I lost the PWM output signal. > > I tried some combinations, measuring the results with an oscilloscope, the period > configuration key appears to loose its nanoseconds meaning beyond a value: Hi Fabio! The PWM frequency is determined as SYSCLKOUT (100Mhz) / prescaler settings / period. As the current code uses 1 for the prescaler and the period is a 16bit value the lower frequency you can have is actually 1.529Khz. > # sysctl dev.am335x_pwm.1.period=1500 > # sysctl dev.am335x_pwm.1.dutyA=300 > result frequency: 66 KHz ->should be 666 KHz > length of period: 15 us ->should be 1.5 us > length of pulse: 2 us As above, this is correct: 100Mhz / 1 / 1500 = 66Khz. > > # sysctl dev.am335x_pwm.1.period=1500000 > # sysctl dev.am335x_pwm.1.dutyA=10000 > result frequency: 1.71 KHz -> should be 666Hz > length of period: 585 us > length of pulse: 100 us > > # sysctl dev.am335x_pwm.1.period=1800000 > # sysctl dev.am335x_pwm.1.dutyA=10000 > result frequency: 3.24 KHz -> should be 555Hz > length of period: 308 us > length of pulse: 100 us These two examples are overflowing the period variable. I've the attached patch which enforces the maximum values where needed (to avoid such overflows) and two new sysctls, one allows you to set the prescaler for the PWM module and the other (which is probably more interesting) allows you to check the actual PWM frequency. The sysctl.am335x_pwm.X.freq can also be use to set an desired frequency directly, it will try to get you the better setting it can find for the desired frequency, which usually means get the bigger period it can find to give the better PWM resolution that is possible for a given frequency. I've been able to drive R/C servos directly with this patch and the following set: sysctl.am335x_pwm.X.freq = 50 (digital servos may operate at higher frequencies) And then, for the cheap chinese servo i have here, i can get it to travel almost 180o using duty values from 2000 to 6000 (YMMV). I've checked the frequencies with a scope and they look fine for me. Regards, Luiz --001a11c3669263125b04f9fdcc1b Content-Type: text/plain; charset=US-ASCII; name="am335x_pwm.diff" Content-Disposition: attachment; filename="am335x_pwm.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hvi58ht70 SW5kZXg6IHN5cy9hcm0vdGkvYW0zMzV4L2FtMzM1eF9wd20uYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv YXJtL3RpL2FtMzM1eC9hbTMzNXhfcHdtLmMJKHJldmlzaW9uIDI2NjUxNikKKysrIHN5cy9hcm0v dGkvYW0zMzV4L2FtMzM1eF9wd20uYwkod29ya2luZyBjb3B5KQpAQCAtMjksMTAgKzI5LDExIEBA CiAKICNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KICNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKyNpbmNs dWRlIDxzeXMvYnVzLmg+CiAjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1ZGUgPHN5cy9s aW1pdHMuaD4KKyNpbmNsdWRlIDxzeXMvbG9jay5oPgogI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4K LSNpbmNsdWRlIDxzeXMvYnVzLmg+Ci0jaW5jbHVkZSA8c3lzL2xvY2suaD4KICNpbmNsdWRlIDxz eXMvbXV0ZXguaD4KICNpbmNsdWRlIDxzeXMvcmVzb3VyY2UuaD4KICNpbmNsdWRlIDxzeXMvcm1h bi5oPgpAQCAtNTMsNiArNTQsNyBAQAogCiAvKiBJbiB0aWNrcyAqLwogI2RlZmluZQlERUZBVUxU X1BXTV9QRVJJT0QJMTAwMAorI2RlZmluZQlQV01fQ0xPQ0sJCTEwMDAwMDAwMAogCiAjZGVmaW5l CVBXTV9MT0NLKF9zYykJCW10eF9sb2NrKCYoX3NjKS0+c2NfbXR4KQogI2RlZmluZQlQV01fVU5M T0NLKF9zYykJCW10eF91bmxvY2soJihfc2MpLT5zY19tdHgpCkBAIC0xNzAsNiArMTcyLDggQEAK IHN0YXRpYyBkZXZpY2VfcHJvYmVfdCBhbTMzNXhfcHdtX3Byb2JlOwogc3RhdGljIGRldmljZV9h dHRhY2hfdCBhbTMzNXhfcHdtX2F0dGFjaDsKIHN0YXRpYyBkZXZpY2VfZGV0YWNoX3QgYW0zMzV4 X3B3bV9kZXRhY2g7CisgICAgICAgIAorc3RhdGljIGludCBhbTMzNXhfcHdtX2Nsa2Rpdls4XSA9 IHsgMSwgMiwgNCwgOCwgMTYsIDMyLCA2NCwgMTI4IH07CiAKIHN0cnVjdCBhbTMzNXhfcHdtX3Nv ZnRjIHsKIAlkZXZpY2VfdAkJc2NfZGV2OwpAQCAtMTc3LDYgKzE4MSwxMCBAQAogCXN0cnVjdCBy ZXNvdXJjZQkJKnNjX21lbV9yZXNbNF07CiAJaW50CQkJc2NfaWQ7CiAJLyogc3lzY3RsIGZvciBj b25maWd1cmF0aW9uICovCisJaW50CQkJc2NfcHdtX2Nsa2RpdjsKKwlpbnQJCQlzY19wd21fZnJl cTsKKwlzdHJ1Y3Qgc3lzY3RsX29pZAkqc2NfY2xrZGl2X29pZDsKKwlzdHJ1Y3Qgc3lzY3RsX29p ZAkqc2NfZnJlcV9vaWQ7CiAJc3RydWN0IHN5c2N0bF9vaWQJKnNjX3BlcmlvZF9vaWQ7CiAJc3Ry dWN0IHN5c2N0bF9vaWQJKnNjX2NoYW5BX29pZDsKIAlzdHJ1Y3Qgc3lzY3RsX29pZAkqc2NfY2hh bkJfb2lkOwpAQCAtMjQxLDcgKzI0OSw5OSBAQAogCXJldHVybiAoMCk7CiB9CiAKK3N0YXRpYyB2 b2lkCithbTMzNXhfcHdtX2ZyZXEoc3RydWN0IGFtMzM1eF9wd21fc29mdGMgKnNjKQoreworCWlu dCBjbGtkaXY7CisKKwljbGtkaXYgPSBhbTMzNXhfcHdtX2Nsa2RpdltzYy0+c2NfcHdtX2Nsa2Rp dl07CisJc2MtPnNjX3B3bV9mcmVxID0gUFdNX0NMT0NLIC8gKDEgKiBjbGtkaXYpIC8gc2MtPnNj X3B3bV9wZXJpb2Q7Cit9CisKIHN0YXRpYyBpbnQKK2FtMzM1eF9wd21fc3lzY3RsX2ZyZXEoU1lT Q1RMX0hBTkRMRVJfQVJHUykKK3sKKwlpbnQgY2xrZGl2LCBlcnJvciwgZnJlcSwgaSwgcGVyaW9k OworCXN0cnVjdCBhbTMzNXhfcHdtX3NvZnRjICpzYzsKKwl1aW50MzJfdCByZWc7CisKKwlzYyA9 IChzdHJ1Y3QgYW0zMzV4X3B3bV9zb2Z0YyAqKWFyZzE7CisKKwlQV01fTE9DSyhzYyk7CisJZnJl cSA9IHNjLT5zY19wd21fZnJlcTsKKwlQV01fVU5MT0NLKHNjKTsKKworCWVycm9yID0gc3lzY3Rs X2hhbmRsZV9pbnQob2lkcCwgJmZyZXEsIHNpemVvZihmcmVxKSwgcmVxKTsKKwlpZiAoZXJyb3Ig IT0gMCB8fCByZXEtPm5ld3B0ciA9PSBOVUxMKQorCQlyZXR1cm4gKGVycm9yKTsKKworCWlmIChm cmVxID4gUFdNX0NMT0NLKQorCQlmcmVxID0gUFdNX0NMT0NLOworCisJUFdNX0xPQ0soc2MpOwor CWlmIChmcmVxICE9IHNjLT5zY19wd21fZnJlcSkgeworCQlmb3IgKGkgPSBuaXRlbXMoYW0zMzV4 X3B3bV9jbGtkaXYpIC0gMTsgaSA+PSAwOyBpLS0pIHsKKwkJCWNsa2RpdiA9IGFtMzM1eF9wd21f Y2xrZGl2W2ldOworCQkJcGVyaW9kID0gUFdNX0NMT0NLIC8gY2xrZGl2IC8gZnJlcTsKKwkJCWlm IChwZXJpb2QgPiBVU0hSVF9NQVgpCisJCQkJYnJlYWs7CisJCQlzYy0+c2NfcHdtX2Nsa2RpdiA9 IGk7CisJCQlzYy0+c2NfcHdtX3BlcmlvZCA9IHBlcmlvZDsKKwkJfQorCQkvKiBSZXNldCB0aGUg ZHV0eSBjeWNsZSBzZXR0aW5ncy4gKi8KKwkJc2MtPnNjX3B3bV9kdXR5QSA9IDA7CisJCXNjLT5z Y19wd21fZHV0eUIgPSAwOworCQlFUFdNX1dSSVRFMihzYywgRVBXTV9DTVBBLCBzYy0+c2NfcHdt X2R1dHlBKTsKKwkJRVBXTV9XUklURTIoc2MsIEVQV01fQ01QQiwgc2MtPnNjX3B3bV9kdXR5Qik7 CisJCS8qIFVwZGF0ZSB0aGUgY2xrZGl2IHNldHRpbmdzLiAqLworCQlyZWcgPSBFUFdNX1JFQUQy KHNjLCBFUFdNX1RCQ1RMKTsKKwkJcmVnICY9IH5UQkNUTF9DTEtESVZfTUFTSzsKKwkJcmVnIHw9 IFRCQ1RMX0NMS0RJVihzYy0+c2NfcHdtX2Nsa2Rpdik7CisJCUVQV01fV1JJVEUyKHNjLCBFUFdN X1RCQ1RMLCByZWcpOworCQkvKiBVcGRhdGUgdGhlIHBlcmlvZCBzZXR0aW5ncy4gKi8KKwkJRVBX TV9XUklURTIoc2MsIEVQV01fVEJQUkQsIHNjLT5zY19wd21fcGVyaW9kIC0gMSk7CisJCWFtMzM1 eF9wd21fZnJlcShzYyk7CisJfQorCVBXTV9VTkxPQ0soc2MpOworCisJcmV0dXJuICgwKTsKK30K Kworc3RhdGljIGludAorYW0zMzV4X3B3bV9zeXNjdGxfY2xrZGl2KFNZU0NUTF9IQU5ETEVSX0FS R1MpCit7CisJaW50IGVycm9yLCBpLCBjbGtkaXY7CisJc3RydWN0IGFtMzM1eF9wd21fc29mdGMg KnNjOworCXVpbnQzMl90IHJlZzsKKworCXNjID0gKHN0cnVjdCBhbTMzNXhfcHdtX3NvZnRjICop YXJnMTsKKworCVBXTV9MT0NLKHNjKTsKKwljbGtkaXYgPSBhbTMzNXhfcHdtX2Nsa2RpdltzYy0+ c2NfcHdtX2Nsa2Rpdl07CisJUFdNX1VOTE9DSyhzYyk7CisKKwllcnJvciA9IHN5c2N0bF9oYW5k bGVfaW50KG9pZHAsICZjbGtkaXYsIHNpemVvZihjbGtkaXYpLCByZXEpOworCWlmIChlcnJvciAh PSAwIHx8IHJlcS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVybiAoZXJyb3IpOworCisJUFdNX0xP Q0soc2MpOworCWlmIChjbGtkaXYgIT0gYW0zMzV4X3B3bV9jbGtkaXZbc2MtPnNjX3B3bV9jbGtk aXZdKSB7CisJCWZvciAoaSA9IDA7IGkgPCBuaXRlbXMoYW0zMzV4X3B3bV9jbGtkaXYpOyBpKysp CisJCQlpZiAoY2xrZGl2ID49IGFtMzM1eF9wd21fY2xrZGl2W2ldKQorCQkJCXNjLT5zY19wd21f Y2xrZGl2ID0gaTsKKworCQlyZWcgPSBFUFdNX1JFQUQyKHNjLCBFUFdNX1RCQ1RMKTsKKwkJcmVn ICY9IH5UQkNUTF9DTEtESVZfTUFTSzsKKwkJcmVnIHw9IFRCQ1RMX0NMS0RJVihzYy0+c2NfcHdt X2Nsa2Rpdik7CisJCUVQV01fV1JJVEUyKHNjLCBFUFdNX1RCQ1RMLCByZWcpOworCQlhbTMzNXhf cHdtX2ZyZXEoc2MpOworCX0KKwlQV01fVU5MT0NLKHNjKTsKKworCXJldHVybiAoMCk7Cit9CisK K3N0YXRpYyBpbnQKIGFtMzM1eF9wd21fc3lzY3RsX2R1dHkoU1lTQ1RMX0hBTkRMRVJfQVJHUykK IHsKIAlzdHJ1Y3QgYW0zMzV4X3B3bV9zb2Z0YyAqc2MgPSAoc3RydWN0IGFtMzM1eF9wd21fc29m dGMqKWFyZzE7CkBAIC0yOTIsMTUgKzM5MiwxOSBAQAogCWlmIChwZXJpb2QgPCAxKQogCQlyZXR1 cm4gKEVJTlZBTCk7CiAKLQlpZiAoKHBlcmlvZCA8IHNjLT5zY19wd21fZHV0eUEpIHx8IChwZXJp b2QgPCBzYy0+c2NfcHdtX2R1dHlCKSkgewotCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsICJQ ZXJpb2QgY2FuJ3QgYmUgbGVzcyB0aGVuIGR1dHkgY3ljbGVcbiIpOwotCQlyZXR1cm4gKEVJTlZB TCk7Ci0JfQorCWlmIChwZXJpb2QgPiBVU0hSVF9NQVgpCisJCXBlcmlvZCA9IFVTSFJUX01BWDsK IAotCiAJUFdNX0xPQ0soc2MpOworCS8qIFJlc2V0IHRoZSBkdXR5IGN5Y2xlIHNldHRpbmdzLiAq LworCXNjLT5zY19wd21fZHV0eUEgPSAwOworCXNjLT5zY19wd21fZHV0eUIgPSAwOworCUVQV01f V1JJVEUyKHNjLCBFUFdNX0NNUEEsIHNjLT5zY19wd21fZHV0eUEpOworCUVQV01fV1JJVEUyKHNj LCBFUFdNX0NNUEIsIHNjLT5zY19wd21fZHV0eUIpOworCS8qIFVwZGF0ZSB0aGUgcGVyaW9kIHNl dHRpbmdzLiAqLwogCXNjLT5zY19wd21fcGVyaW9kID0gcGVyaW9kOwogCUVQV01fV1JJVEUyKHNj LCBFUFdNX1RCUFJELCBwZXJpb2QgLSAxKTsKKwlhbTMzNXhfcHdtX2ZyZXEoc2MpOwogCVBXTV9V TkxPQ0soc2MpOwogCiAJcmV0dXJuIChlcnJvcik7CkBAIC0zNjAsNiArNDY0LDE0IEBACiAJY3R4 ID0gZGV2aWNlX2dldF9zeXNjdGxfY3R4KHNjLT5zY19kZXYpOwogCXRyZWUgPSBkZXZpY2VfZ2V0 X3N5c2N0bF90cmVlKHNjLT5zY19kZXYpOwogCisJc2MtPnNjX2Nsa2Rpdl9vaWQgPSBTWVNDVExf QUREX1BST0MoY3R4LCBTWVNDVExfQ0hJTERSRU4odHJlZSksIE9JRF9BVVRPLAorCSAgICAiY2xr ZGl2IiwgQ1RMVFlQRV9JTlQgfCBDVExGTEFHX1JXLCBzYywgMCwKKwkgICAgYW0zMzV4X3B3bV9z eXNjdGxfY2xrZGl2LCAiSSIsICJQV00gY2xvY2sgcHJlc2NhbGVyIik7CisKKwlzYy0+c2NfZnJl cV9vaWQgPSBTWVNDVExfQUREX1BST0MoY3R4LCBTWVNDVExfQ0hJTERSRU4odHJlZSksIE9JRF9B VVRPLAorCSAgICAiZnJlcSIsIENUTFRZUEVfSU5UIHwgQ1RMRkxBR19SVywgc2MsIDAsCisJICAg IGFtMzM1eF9wd21fc3lzY3RsX2ZyZXEsICJJIiwgIlBXTSBmcmVxdWVuY3kiKTsKKwogCXNjLT5z Y19wZXJpb2Rfb2lkID0gU1lTQ1RMX0FERF9QUk9DKGN0eCwgU1lTQ1RMX0NISUxEUkVOKHRyZWUp LCBPSURfQVVUTywKIAkgICAgInBlcmlvZCIsIENUTFRZUEVfSU5UIHwgQ1RMRkxBR19SVywgc2Ms IDAsCiAJICAgIGFtMzM1eF9wd21fc3lzY3RsX3BlcmlvZCwgIkkiLCAiUFdNIHBlcmlvZCIpOwpA QCAtMzcyLDcgKzQ4NCw2IEBACiAJICAgICJkdXR5QiIsIENUTFRZUEVfSU5UIHwgQ1RMRkxBR19S Vywgc2MsIDAsCiAJICAgIGFtMzM1eF9wd21fc3lzY3RsX2R1dHksICJJIiwgIkNoYW5uZWwgQiBk dXR5IGN5Y2xlcyIpOwogCi0KIAkvKiBDT05GSUdVUkUgRVBXTTEgKi8KIAlyZWcgPSBFUFdNX1JF QUQyKHNjLCBFUFdNX1RCQ1RMKTsKIAlyZWcgJj0gfihUQkNUTF9DTEtESVZfTUFTSyB8IFRCQ1RM X0hTUENMS0RJVl9NQVNLKTsKQEAgLTM4MSw2ICs0OTIsNyBAQAogCXNjLT5zY19wd21fcGVyaW9k ID0gREVGQVVMVF9QV01fUEVSSU9EOwogCXNjLT5zY19wd21fZHV0eUEgPSAwOwogCXNjLT5zY19w d21fZHV0eUIgPSAwOworCWFtMzM1eF9wd21fZnJlcShzYyk7CiAKIAlFUFdNX1dSSVRFMihzYywg RVBXTV9UQlBSRCwgc2MtPnNjX3B3bV9wZXJpb2QgLSAxKTsKIAlFUFdNX1dSSVRFMihzYywgRVBX TV9DTVBBLCBzYy0+c2NfcHdtX2R1dHlBKTsK --001a11c3669263125b04f9fdcc1b-- From owner-freebsd-arm@FreeBSD.ORG Thu May 22 14:27:51 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CE2AA0 for ; Thu, 22 May 2014 14:27:51 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 411C32777 for ; Thu, 22 May 2014 14:27:51 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WnTyH-0006xa-QF; Thu, 22 May 2014 14:27:50 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4MERkF0046436; Thu, 22 May 2014 08:27:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18RU3XJjtt3a15o0iZXCJCp Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Ian Lepore To: SAITOU Toshihide In-Reply-To: <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> References: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 2014 08:27:46 -0600 Message-ID: <1400768866.1152.231.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:27:51 -0000 On Thu, 2014-05-22 at 23:15 +0900, SAITOU Toshihide wrote: > In message: <1400765234.1152.224.camel@revolution.hippie.lan> > Ian Lepore writes: > > On Thu, 2014-05-22 at 20:46 +0900, SAITOU Toshihide wrote: > >> In message: > >> Winston Smith writes: > >> > On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: > >> >> If abort like > >> >> > >> >> musbotg0: TI AM335X USBSS v0.0.13 > >> >> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' > >> >> trapframe: 0xc0a2eb60 > >> > > >> > I see this with the 1Ghz uboot, it occurs about 50% of the time, see: > >> > > >> > http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 > >> > >> Although it is an ad hoc workaround but ``usb start'' at u-boot command > >> prompt (someone mentioned before) or add device_printf("!\n") before > >> ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of > >> am335x_usbss.c prevent this panic for me. > > > > An 'external non-linefetch abort' on a TI chip usually means that the > > clocks for a device never got turned on and you attempted to read or > > write a register in that device. If 'usb start' makes the problem go > > away, that tends to confirm that thought. > > > > The thing is, I don't understand why adding a printf to the code with no > > other changes would help in any way. I though maybe it was adding some > > delay to allow the clock-start call to take effect, but the clock enable > > call is after the USBSS_REVREG read, and that seems wrong. > > > > Does it fix the problem to move the ti_prcm_clk_enable() call to be > > before the USBSS_REVREG read in attach? > > I will try ti_prcm_clk_enable() at the weekend. But someone's report > would be appriciated because I remove the src and svn up now. > If you have done svn up -rnnnnn on individual files, I think svn will then leave those files at that revision when you do future updates. Doing 'svn revert -R .' in the src directory should get everything reset so that 'svn up' will pull the latest versions of everything again. Of course, it will also revert *every* change you've made under src, so use it carefully! It should be faster than checking out a fresh copy, and you can still do a -DNO_CLEAN build and rebuild just the things that have changed. Of course you can also use svn revert on a single file or directory too. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 22 14:34:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C14A2B1; Thu, 22 May 2014 14:34:52 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7DF12832; Thu, 22 May 2014 14:34:51 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id y10so3427392wgg.13 for ; Thu, 22 May 2014 07:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cLT1g73OhciMDOC8luFl4vcJkGx7hn5FBplQBCO8U/w=; b=sUFq2gDj2PyPGSghfyFx/VGKVfmlCZNv8GKQJclbppUjBY9CHKKNHbDQlLrvwehSni 8wIQzWGRZtVe6ckyC2XFZ0L9wS7Z1TfQKEY4RfiBWRcbPKGT9ZxP0+0GA8Qo3CI6sVB5 PYNGI1GpANbgzhtIunGWmdNaMblxGeDC3o14LWAkcXnSM6GtRBMXJx7wW+EIhYIpY0YG FYaqIMQv3ihf0YJjuankq8YG83/spZ7ziLPuqgoi1K8wKaFHibI1WBaLKEH5a9/lAd34 HmUV2qrB4CdoxNKmhVO8z1T4EUtBsk5T7f++SA79JEIpILSYUQFN57mynTIyZEemWfRa N0pw== MIME-Version: 1.0 X-Received: by 10.194.184.179 with SMTP id ev19mr2306367wjc.85.1400769290217; Thu, 22 May 2014 07:34:50 -0700 (PDT) Received: by 10.216.40.72 with HTTP; Thu, 22 May 2014 07:34:50 -0700 (PDT) In-Reply-To: <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> References: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> Date: Thu, 22 May 2014 11:34:50 -0300 Message-ID: Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Luiz Otavio O Souza To: SAITOU Toshihide Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:34:52 -0000 Just picking one email to reply... This is probably unrelated, but i can consistently corrupt my SD Card data if i connect (and use) a very small R/C servo (the 9g ones, used on foam planes) to the 3.3v on the expansion headers. I'm not sure if it is because of noise or the power consumption, but looks like the BBB is really picky about the power conditions here. Connecting the servo to the VDD_5V on the same header makes the problem go away. So be careful about what you connect on your boards :) Regards, Luiz From owner-freebsd-arm@FreeBSD.ORG Thu May 22 14:53:10 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DEA3A40 for ; Thu, 22 May 2014 14:53:10 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0125129D4 for ; Thu, 22 May 2014 14:53:09 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WnUMm-000OZf-KR; Thu, 22 May 2014 14:53:08 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4MEr5RD046454; Thu, 22 May 2014 08:53:05 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/L+RiJoLZzccUvz+m1SvpU Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Ian Lepore To: Luiz Otavio O Souza In-Reply-To: References: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 2014 08:53:05 -0600 Message-ID: <1400770385.1152.233.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:53:10 -0000 On Thu, 2014-05-22 at 11:34 -0300, Luiz Otavio O Souza wrote: > Just picking one email to reply... > > This is probably unrelated, but i can consistently corrupt my SD Card > data if i connect (and use) a very small R/C servo (the 9g ones, used > on foam planes) to the 3.3v on the expansion headers. > > I'm not sure if it is because of noise or the power consumption, but > looks like the BBB is really picky about the power conditions here. > > Connecting the servo to the VDD_5V on the same header makes the problem go away. > > So be careful about what you connect on your boards :) > It looks like the 3v3b rail comes off a 500mA LDO and is already powering several of the onboard chips (including eMMC and at least part of the ethernet phy), so it may be power consumption. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 22 14:56:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 983ADBDE for ; Thu, 22 May 2014 14:56:43 +0000 (UTC) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A02929F6 for ; Thu, 22 May 2014 14:56:43 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id e49so2729706eek.35 for ; Thu, 22 May 2014 07:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Oslb5nt5T6W0Ci9qJK0U6PTkV9Ru78/G+oFIMmvidPY=; b=PosEhriXSwKVEAq5fIMZKOT2pdz+RSdNd0JhzTSjpJ8GLHZAjfSL7k1Q+ZmFhPDjDc EO1sFpc/q59tHwzDIMtopCcZo96KanJavwj5vM6Uwn/2JL/S/F2DzOF7MankDecvEeVL dOpaz71rKHGjDDL1r7hEen4NboCcGXKJBxddk2BZyDRIiO9LrctbNyGmjC86sO2IGyhZ DakmDb2DnbYa1LmYPJz0rxTCZEuu+B2oXLLOdl4vHqunUcZxOQL06jvBcMRfjPDcYkOy uIRFslO9FtoMLUGAHCI/cNdSRcoeL0Z1z94EGkI/ERWPEsnxB3KUj93qM7aoHzYFd0j+ 7A+Q== X-Received: by 10.14.179.136 with SMTP id h8mr14675622eem.57.1400770600804; Thu, 22 May 2014 07:56:40 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id e44sm1032130eeg.24.2014.05.22.07.56.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 07:56:39 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537E1024.1020806@hot.ee> Date: Thu, 22 May 2014 17:56:36 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Sulev-Madis Silber (ketas)" Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) References: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <537DF45D.8010304@hot.ee> In-Reply-To: <537DF45D.8010304@hot.ee> X-TagToolbar-Keys: D20140522175635997 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:56:43 -0000 On 2014-05-22 15:58, Sulev-Madis Silber (ketas) wrote: > On 2014-05-22 14:46, SAITOU Toshihide wrote: >> In message: >> Winston Smith writes: >>> On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: >>>> If abort like >>>> >>>> musbotg0: TI AM335X USBSS v0.0.13 >>>> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' >>>> trapframe: 0xc0a2eb60 >>> >>> I see this with the 1Ghz uboot, it occurs about 50% of the time, see: >>> >>> http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 >> >> Although it is an ad hoc workaround but ``usb start'' at u-boot command >> prompt (someone mentioned before) or add device_printf("!\n") before >> ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of >> am335x_usbss.c prevent this panic for me. >> >> Anyway I understand my procedure is workaround, and is working by >> chance or side effect, but eMMC boot and 1000 MHz operation is fun. >> > > > I wish I could get that working too... I tried to trace device detection > path in loader but only found that the problem must be in uboot. Since > loader is program that runs in uboot. At least now I know how that works > a bit more. But actual issue remains unresolved. What's weird is how I > actually boot from eMMC and it's present in uboot... Loader comes from > eMMC and then loader suddenly has no devices inside it. The hell is that. > Works now... I didn't change code but the way how uboot is configured through crochet. I think if you want to really piss yourself off then messing with crochet is good way to do this. I wish those several versions (normal, devel) of uboot can be added to ports instead (one is already there), once we get good version. Maybe I should start maintaining port myself because I hate the situation right now. Hmm... now, how do I change frequency... lower frequency can be useful sometimes. From owner-freebsd-arm@FreeBSD.ORG Thu May 22 15:26:55 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4546B45 for ; Thu, 22 May 2014 15:26:55 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9609B2D2E for ; Thu, 22 May 2014 15:26:55 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WnUtS-000Mtx-Ji; Thu, 22 May 2014 15:26:54 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4MFQqG4046492; Thu, 22 May 2014 09:26:52 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+KaIj67j5tL15koEuQhPto Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Ian Lepore To: "Sulev-Madis Silber (ketas)" In-Reply-To: <537DF45D.8010304@hot.ee> References: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <537DF45D.8010304@hot.ee> Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 2014 09:26:52 -0600 Message-ID: <1400772412.1152.250.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:26:55 -0000 On Thu, 2014-05-22 at 15:58 +0300, Sulev-Madis Silber (ketas) wrote: > On 2014-05-22 14:46, SAITOU Toshihide wrote: > > In message: > > Winston Smith writes: > >> On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: > >>> If abort like > >>> > >>> musbotg0: TI AM335X USBSS v0.0.13 > >>> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' > >>> trapframe: 0xc0a2eb60 > >> > >> I see this with the 1Ghz uboot, it occurs about 50% of the time, see: > >> > >> http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 > > > > Although it is an ad hoc workaround but ``usb start'' at u-boot command > > prompt (someone mentioned before) or add device_printf("!\n") before > > ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of > > am335x_usbss.c prevent this panic for me. > > > > Anyway I understand my procedure is workaround, and is working by > > chance or side effect, but eMMC boot and 1000 MHz operation is fun. > > > > > I wish I could get that working too... I tried to trace device detection > path in loader but only found that the problem must be in uboot. Since > loader is program that runs in uboot. At least now I know how that works > a bit more. But actual issue remains unresolved. What's weird is how I > actually boot from eMMC and it's present in uboot... Loader comes from > eMMC and then loader suddenly has no devices inside it. The hell is that. I vaguely remember Patrick Kelsey mentioning something a while back about having u-boot patches to fix some problem in device enumeration API so that ubldr could see all the devices properly. Maybe that's needed to fix this problem? I've added him to the cc list. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 22 15:52:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DC09D3C; Thu, 22 May 2014 15:52:14 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id CB3F82010; Thu, 22 May 2014 15:52:13 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id CB86AB828; Thu, 22 May 2014 17:52:10 +0200 (SAST) Date: Thu, 22 May 2014 17:52:10 +0200 From: John Hay To: Warner Losh Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140522155210.GA57720@zibbi.meraka.csir.co.za> References: <20140521192807.GA48338@zibbi.meraka.csir.co.za> <95AD97BA-AA48-4BBF-845C-D0CB585ACAA3@bsdimp.com> <20140522090504.GA22488@zibbi.meraka.csir.co.za> <5D4F0BD5-89DA-421F-B095-A5F2C49F3DF9@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D4F0BD5-89DA-421F-B095-A5F2C49F3DF9@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:52:14 -0000 On Thu, May 22, 2014 at 08:07:34AM -0600, Warner Losh wrote: > > On May 22, 2014, at 3:05 AM, John Hay wrote: > > > On Wed, May 21, 2014 at 02:01:42PM -0600, Warner Losh wrote: > >> > >> On May 21, 2014, at 1:28 PM, John Hay wrote: > >> > >>> On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: > >>>> isn't eabi on the xscale still broken? > >>> > >>> It might still be broken. But there are more brokenness than that. :-( > >>> By defining WITHOUT_ARM_EABI=yes in src.conf, I can get an AVILA kernel > >>> built that boots with src from head at around mid December. Latest 10 > >>> and head just give no output, with or without WITHOUT_ARM_EABI defined. > >> > >> Does the same thing happen with make.conf instead of src.conf? > > > > Yes, I have tried both 10 and head with WITHOUT_ARM_EABI=yes and no > > output after go in redboot. My compile lines look like this: > > > > make TARGET_ARCH=armeb TARGET_CPUTYPE=xscale toolchain > > make TARGET=arm TARGET_ARCH=armeb buildkernel KERNCONF=AVILA DESTDIR=/arm/ > > > > And then in redboot "load -b 0x200000 kernel" to load it with tftp. And > > then "go". > > > > The "no output" happened somewhere between mid December and beginning > > of Feb. I determined that before getting side tracked. I'll see in the > > next day or two if I can narrow that down. > > > > If someone have patches so that WITHOUT_ARM_EABI=yes is not needed > > anymore, I'll test that too. > > This is with gcc, not clang, right? The default that the tree will do for the above commands. I did not force it one way or the other. The kernels that did boot, reported gcc 4.2.1 John > > Warner > > > > John > > > >> > >> Warner > >> > >>> John > >>> > >>>> > >>>> > >>>> -a > >>>> > >>>> > >>>> On 19 May 2014 08:40, Warner Losh wrote: > >>>>> Greetings, > >>>>> > >>>>> MK_ARM_EABI is going to die in current. It is the default for all platforms currently. I???m eliminating it as a build option. It must die because it invisibly (to uname) effects the ABI. > >>>>> > >>>>> So, to that end, I see two options: > >>>>> > >>>>> (1) Retire and remove oabi support. > >>>>> (2) Retain oabi support, but change its name to armo and armoeb. > >>>>> > >>>>> The rough consensus of arm developers I???ve polled now, and in the past, is that we just let oabi support die now that EABI support is working for everybody. > >>>>> > >>>>> Before I pull the trigger on this, however, I must ask if anybody has a problem with my doing option (1), and if so, what keeps you using oabi. > >>>>> > >>>>> Comments? > >>>>> > >>>>> Warner > >>>>> > >>>>> _______________________________________________ > >>>>> freebsd-arm@freebsd.org mailing list > >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >>>> _______________________________________________ > >>>> freebsd-arm@freebsd.org mailing list > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu May 22 16:21:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29F3D803; Thu, 22 May 2014 16:21:53 +0000 (UTC) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87CFD22E2; Thu, 22 May 2014 16:21:52 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id e53so2792452eek.22 for ; Thu, 22 May 2014 09:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Xbk16vfvwzynKTMIDFoOlXVkS4VmkkofMjU7QaEYO6k=; b=t762V0xIa+LTo4QWi99UE39788BR9umhzXbRr4uruem06bLR072TqDOEkhNEPIxvkQ KoJ1TsP6yqIPOUpm48YHw94Zts1hr3fMu3gikawOzxJve46ut++Bg06iqYUNj00z4CBa MJYvFv6MqtKeS34uDI3U8aqPXyahhDl+GJTAr7MaMuD97Ty3ku7sH0IzRuyRfCMR3qwX vCNUv5tS3RTE1M/Ootz5tEVNwFlOvt/84Ykw3wGNkh9hVtCTsjK9LiEsrvWzg53T1DbU QF0QlLKl0N+P8ExxDqBX5Xtrr5OWDdconV5K4YYt0kYVU7CZq6r0Nf7or4YDONjVZDvr erNA== X-Received: by 10.14.100.133 with SMTP id z5mr5704932eef.85.1400775710797; Thu, 22 May 2014 09:21:50 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id s46sm1556667ees.3.2014.05.22.09.21.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 09:21:49 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537E241B.6060602@hot.ee> Date: Thu, 22 May 2014 19:21:47 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) References: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> <1400770385.1152.233.camel@revolution.hippie.lan> In-Reply-To: <1400770385.1152.233.camel@revolution.hippie.lan> X-TagToolbar-Keys: D20140522192147342 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 16:21:53 -0000 On 2014-05-22 17:53, Ian Lepore wrote: > On Thu, 2014-05-22 at 11:34 -0300, Luiz Otavio O Souza wrote: >> Just picking one email to reply... >> >> This is probably unrelated, but i can consistently corrupt my SD Card >> data if i connect (and use) a very small R/C servo (the 9g ones, used >> on foam planes) to the 3.3v on the expansion headers. >> >> I'm not sure if it is because of noise or the power consumption, but >> looks like the BBB is really picky about the power conditions here. >> >> Connecting the servo to the VDD_5V on the same header makes the problem go away. >> >> So be careful about what you connect on your boards :) >> > > It looks like the 3v3b rail comes off a 500mA LDO and is already > powering several of the onboard chips (including eMMC and at least part > of the ethernet phy), so it may be power consumption. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > It's somehow related... Why does the ADC driver discard the input #8 (measures VDD_3V3B)? I don't know why exactly board designers decided to connect it there (instead of PMIC ADC mux or just header), but I have some ideas why and what to do with it. I can patch it locally too, if absolutely required. Maybe you could measure LDO status that way a bit. That of course doesn't mean you should run motors off IC power rails. Voltage measurements can't really help there. Even shared GND can sometimes be problem... From owner-freebsd-arm@FreeBSD.ORG Thu May 22 16:56:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3DAC771; Thu, 22 May 2014 16:56:04 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 199E925A5; Thu, 22 May 2014 16:56:03 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id ec20so1268084lab.19 for ; Thu, 22 May 2014 09:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jw5n9B2wyqZXA3xQaHHAk9J2W/CyUfsXLrSoC2c3yT0=; b=Co1sar9UEjIikE5n/4+ocVu8Nv+sgT0KzGqc1aj2RJxdNEMZ5ZxsmfiKhHaFEpOuKR Lrkc8fc/uFabgWwR5anlJftBSVlE5fyJmhZr1wMc+Aa1Kk+w+N5cj1t/CEvbyQ2mC/4k 5eck1NI/LDe1C9mZgHACbdPtfAXPi7tLZxbv8q4wESfmYQuM4mDO13JzC9SsOqyCkE8S UUEG10Hmh6bic238BudrXj098Dtz7Q2sYDGn4tp4RzPzNI2DljIWboSNVzRF5DjkWKsL aY22rUfOnpUR7BFQumglbxFLdmWFkx1374Zw8OIqeZvsbaH8JjZgFN/CLl/tU/M6f/YX tbVA== MIME-Version: 1.0 X-Received: by 10.152.43.98 with SMTP id v2mr2152933lal.83.1400777761899; Thu, 22 May 2014 09:56:01 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.141.196 with HTTP; Thu, 22 May 2014 09:56:01 -0700 (PDT) In-Reply-To: <1400772412.1152.250.camel@revolution.hippie.lan> References: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <537DF45D.8010304@hot.ee> <1400772412.1152.250.camel@revolution.hippie.lan> Date: Thu, 22 May 2014 12:56:01 -0400 X-Google-Sender-Auth: q25cFOGVMjM_bYtSZ4cYXPO0nLw Message-ID: Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Patrick Kelsey To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 16:56:04 -0000 On Thu, May 22, 2014 at 11:26 AM, Ian Lepore wrote: > On Thu, 2014-05-22 at 15:58 +0300, Sulev-Madis Silber (ketas) wrote: > > On 2014-05-22 14:46, SAITOU Toshihide wrote: > > > In message: < > CADH-AwGb36EUknNofdch1Q4Pn8GAN+Ep9SdiJ_f7Q2v9e4kW1g@mail.gmail.com> > > > Winston Smith writes: > > >> On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide < > toshi@ruby.ocn.ne.jp> wrote: > > >>> If abort like > > >>> > > >>> musbotg0: TI AM335X USBSS v0.0.13 > > >>> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' > > >>> trapframe: 0xc0a2eb60 > > >> > > >> I see this with the 1Ghz uboot, it occurs about 50% of the time, see: > > >> > > >> http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 > > > > > > Although it is an ad hoc workaround but ``usb start'' at u-boot command > > > prompt (someone mentioned before) or add device_printf("!\n") before > > > ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of > > > am335x_usbss.c prevent this panic for me. > > > > > > Anyway I understand my procedure is workaround, and is working by > > > chance or side effect, but eMMC boot and 1000 MHz operation is fun. > > > > > > > > > I wish I could get that working too... I tried to trace device detection > > path in loader but only found that the problem must be in uboot. Since > > loader is program that runs in uboot. At least now I know how that works > > a bit more. But actual issue remains unresolved. What's weird is how I > > actually boot from eMMC and it's present in uboot... Loader comes from > > eMMC and then loader suddenly has no devices inside it. The hell is that. > > I vaguely remember Patrick Kelsey mentioning something a while back > about having u-boot patches to fix some problem in device enumeration > API so that ubldr could see all the devices properly. Maybe that's > needed to fix this problem? > > I've added him to the cc list. > The u-boot device enumeration patches I developed were against u-boot 2013.04 and they are part of crochet builds if you build for that u-boot version. https://github.com/kientzle/crochet-freebsd/blob/master/board/BeagleBone/files/uboot-2013.04_api_api_storage.c.patch The above patch changes storage device enumeration in two ways. The first is that it correctly sets the 'more' flag when starting enumeration, so it is actually possible to enumerate more than one storage device. The second is that it treats a found block device of type DEV_TYPE_UNKNOWN as a block device of size zero, instead of a failure to find anything. This second change allows storage drivers, such as the mmc driver, to report an empty card slot as a zero-sized block device of unknown type and have it appear in the enumeration results. https://github.com/kientzle/crochet-freebsd/blob/master/board/BeagleBone/files/uboot-2013.04_drivers_mmc_mmc.c.patch The above patch patch changes the mmc driver so it reports empty card slots (really, any failing device) as zero-sized devices of type DEV_TYPE_UNKNOWN. These two patches together result in the enumeration of both the SD card slot and the eMMC device on the BBB no matter where you booted from and no matter whether the SD card slot is empty or occupied. The other patches for 2013.04 in crochet make sure the full u-boot image knows which device was booted from so that ubldr is loaded from the same device. I found this to be important for my sanity when valid, but differing, images were present on both the SD card and the eMMC. If you aren't running u-boot code with the above fixes or something functionally equivalent, you can wind up with some frustrating outcomes, as outlined below. When booting from SD or eMMC, the first thing that the ROM code runs is the SPL, which is a stripped down u-boot that is configured to use whatever MMC controller the ROM code told it was used to boot from. So for the SPL, the storage/mmc device enumeration code never comes into play. If the processor boots from the eMMC, the SPL will see the eMMC and load the full u-boot from there. This part is pretty much foolproof. Next, the full u-boot is running, and what happens next depends on what kind of device enumeration code you have in u-boot, and possibly also what you have in the SD card slot. The unmodified 2013.04 code will fail if there is nothing in the SD card slot, because it will only look there and find nothing (this is my guess as to what is being described above). If there is something in the SD card slot, it will find it and try to continue with what is on it. Either way though, it is actually unaware of the eMMC device from which it was loaded. In other words, the best case for eMMC booting with unmodified 2013.04 u-boot is that you run the SPL off of eMMC, load the full u-boot from the eMMC, then proceed with what is on the SD card. I haven't yet taken a look at what is new and different, if anything, in storage device enumeration in 2014.04, and thus which of my 2013.04 patches need to be applied there as well. -Patrick From owner-freebsd-arm@FreeBSD.ORG Thu May 22 17:30:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFFE9FDE; Thu, 22 May 2014 17:30:27 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C23C282E; Thu, 22 May 2014 17:30:26 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s4MH4Sb0078411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 May 2014 19:04:28 +0200 (CEST) (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 s4MH4FbV016932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2014 19:04:15 +0200 (CEST) (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 s4MH4FUI092581; Thu, 22 May 2014 19:04:15 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s4MH4Ebi092580; Thu, 22 May 2014 19:04:14 +0200 (CEST) (envelope-from ticso) Date: Thu, 22 May 2014 19:04:14 +0200 From: Bernd Walter To: Luiz Otavio O Souza Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) Message-ID: <20140522170414.GA92212@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> 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=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" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:30:28 -0000 On Thu, May 22, 2014 at 11:34:50AM -0300, Luiz Otavio O Souza wrote: > Just picking one email to reply... > > This is probably unrelated, but i can consistently corrupt my SD Card > data if i connect (and use) a very small R/C servo (the 9g ones, used > on foam planes) to the 3.3v on the expansion headers. R/C servos usually are extremly harsh on power sources. I know this because decades ago I'd build LED based akku charge displays for R/C helicopters and I needed a lot of input filtering to not sweep over the full display range when servos had been active. > I'm not sure if it is because of noise or the power consumption, but > looks like the BBB is really picky about the power conditions here. It is the noise on the power consumption. I don't know how good the 3.3V rail is stabilized, but I wouldn't be surrised the the servo would produce a noise level of way more than 3.3V, so your rail even can be negative or more than doubled. This can even damage components as they are not designed to handle such voltages. > Connecting the servo to the VDD_5V on the same header makes the problem go away. The 5V rail is likely not directly used in any digital circuitry beside the volatage regulators input and their output are influenced. The volatage regultaors however are also designed for small input voltage ranges and can be damaged by invalid input voltages on the 5V rail. An inductive load can be a power sink or a power source! Effectively you are connecting something to the 3.3V or 5V rail, which sometimes act as a high voltage battery. > So be careful about what you connect on your boards :) Absolutely. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu May 22 17:34:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8769023C; Thu, 22 May 2014 17:34:18 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1909F28D1; Thu, 22 May 2014 17:34:17 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s4MHYFwR078604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 May 2014 19:34:16 +0200 (CEST) (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 s4MHYAwd017164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2014 19:34:10 +0200 (CEST) (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 s4MHYARG092725; Thu, 22 May 2014 19:34:10 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s4MHYAp9092724; Thu, 22 May 2014 19:34:10 +0200 (CEST) (envelope-from ticso) Date: Thu, 22 May 2014 19:34:10 +0200 From: Bernd Walter To: Luiz Otavio O Souza Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) Message-ID: <20140522173410.GB92212@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> <20140522170414.GA92212@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140522170414.GA92212@cicely7.cicely.de> 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" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:34:18 -0000 On Thu, May 22, 2014 at 07:04:14PM +0200, Bernd Walter wrote: > On Thu, May 22, 2014 at 11:34:50AM -0300, Luiz Otavio O Souza wrote: > > Just picking one email to reply... > > > > This is probably unrelated, but i can consistently corrupt my SD Card > > data if i connect (and use) a very small R/C servo (the 9g ones, used > > on foam planes) to the 3.3v on the expansion headers. > > R/C servos usually are extremly harsh on power sources. > I know this because decades ago I'd build LED based akku charge displays > for R/C helicopters and I needed a lot of input filtering to not sweep > over the full display range when servos had been active. > > > I'm not sure if it is because of noise or the power consumption, but > > looks like the BBB is really picky about the power conditions here. > > It is the noise on the power consumption. > I don't know how good the 3.3V rail is stabilized, but I wouldn't > be surrised the the servo would produce a noise level of way more than > 3.3V, so your rail even can be negative or more than doubled. > This can even damage components as they are not designed to handle > such voltages. > > > Connecting the servo to the VDD_5V on the same header makes the problem go away. > > The 5V rail is likely not directly used in any digital circuitry > beside the volatage regulators input and their output are > influenced. uninfluenced... > The volatage regultaors however are also designed for small input voltage Doing low level stuff makes one type volatile too often. Amazing how often I misstype voltage now. Stupid fingers... > ranges and can be damaged by invalid input voltages on the 5V rail. > An inductive load can be a power sink or a power source! > Effectively you are connecting something to the 3.3V or 5V rail, > which sometimes act as a high voltage battery. > > > So be careful about what you connect on your boards :) > > Absolutely. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu May 22 18:39:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FCBCADA for ; Thu, 22 May 2014 18:39:22 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 602AC2E98 for ; Thu, 22 May 2014 18:39:22 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 8E4155DEBC; Thu, 22 May 2014 18:39:14 +0000 (UTC) Date: Thu, 22 May 2014 19:39:08 +0100 From: Andrew Turner To: Warner Losh Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140522193908.04737bec@bender.Home> In-Reply-To: <5D4F0BD5-89DA-421F-B095-A5F2C49F3DF9@bsdimp.com> References: <20140521192807.GA48338@zibbi.meraka.csir.co.za> <95AD97BA-AA48-4BBF-845C-D0CB585ACAA3@bsdimp.com> <20140522090504.GA22488@zibbi.meraka.csir.co.za> <5D4F0BD5-89DA-421F-B095-A5F2C49F3DF9@bsdimp.com> 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 18:39:22 -0000 On Thu, 22 May 2014 08:07:34 -0600 Warner Losh wrote: > > On May 22, 2014, at 3:05 AM, John Hay wrote: > > > On Wed, May 21, 2014 at 02:01:42PM -0600, Warner Losh wrote: > >> > >> On May 21, 2014, at 1:28 PM, John Hay wrote: > >> > >>> On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: > >>>> isn't eabi on the xscale still broken? > >>> > >>> It might still be broken. But there are more brokenness than > >>> that. :-( By defining WITHOUT_ARM_EABI=yes in src.conf, I can get > >>> an AVILA kernel built that boots with src from head at around mid > >>> December. Latest 10 and head just give no output, with or without > >>> WITHOUT_ARM_EABI defined. > >> > >> Does the same thing happen with make.conf instead of src.conf? > > > > Yes, I have tried both 10 and head with WITHOUT_ARM_EABI=yes and no > > output after go in redboot. My compile lines look like this: > > > > make TARGET_ARCH=armeb TARGET_CPUTYPE=xscale toolchain > > make TARGET=arm TARGET_ARCH=armeb buildkernel KERNCONF=AVILA > > DESTDIR=/arm/ > > > > And then in redboot "load -b 0x200000 kernel" to load it with tftp. > > And then "go". > > > > The "no output" happened somewhere between mid December and > > beginning of Feb. I determined that before getting side tracked. > > I'll see in the next day or two if I can narrow that down. > > > > If someone have patches so that WITHOUT_ARM_EABI=yes is not needed > > anymore, I'll test that too. > > This is with gcc, not clang, right? Clang doesn't support armeb. Andrew From owner-freebsd-arm@FreeBSD.ORG Thu May 22 18:51:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 325A9D7A for ; Thu, 22 May 2014 18:51:19 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCF382F72 for ; Thu, 22 May 2014 18:51:18 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id t60so3882365wes.13 for ; Thu, 22 May 2014 11:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zb6k6dU7MEzTvCi0pvwb7GimzLRak8x1jLhieCEfX4w=; b=g4bkjGioAoNUYcRtiZ8pZaAWZznu/HMQp6NXDlzk3Xx/Oe58j6wsL2oRZVynjeduHT hrtLXLI2sw/Q3zUAF566jt1MsU2fSZQV6/J/+78s9lSfD3P/jEqNB8xA3MdCL8qF9dTH nhZqbzkMiRQs2LKknkPGEl+iV8jUYMKbCRs3snZ2hXk9VGORBbMhnQUr6kaDZEe5uHgX tu+ZZbrAWF7Mo7Uq57CpF7MiAtZ6FMW6Ri5+dbO96Vjs1qv+BvuNGCdhqUSPDWJLmT4C j+G/XNXoPFaJy+VEIEX0ruh93OGoZ2P4yFWy9Iev6On5gilYmqV8kbdVAQJXR2rHVH4p /ITQ== X-Received: by 10.194.179.9 with SMTP id dc9mr3761009wjc.74.1400784676904; Thu, 22 May 2014 11:51:16 -0700 (PDT) Received: from [192.168.113.40] (142.Red-83-56-26.staticIP.rima-tde.net. [83.56.26.142]) by mx.google.com with ESMTPSA id go1sm1735565wib.7.2014.05.22.11.51.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 11:51:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Beaglebone Black. PWM minimum frequency of 1.52KHz From: fabiodive In-Reply-To: Date: Thu, 22 May 2014 19:51:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1510) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 18:51:19 -0000 Hello Luiz, hello all my friends, Luiz, it is a real pleasure for me to hear you! I didn't try yet your work but I will do that tomorrow, actually your modifications sounds really well done. I will report here,=20 thank you! cheers, Fabio On May 22, 2014, at 15:19 , Luiz Otavio O Souza = wrote: > On 10 May 2014 08:56, fabiodive wrote: >> Hello, >>=20 >> PWM on Beaglebone Black >>=20 >> during my laboratory tests I was not able to setup a frequency = suitable for servo motors. >> I tried several times with many values but the results was always the = same. >> The minimal frequency I was able to achieve was 1.52 KHz. >> Also, I noticed odd results with the most of configuration values, in = this case >> I lost the PWM output signal. >>=20 >> I tried some combinations, measuring the results with an = oscilloscope, the period >> configuration key appears to loose its nanoseconds meaning beyond a = value: >=20 > Hi Fabio! >=20 > The PWM frequency is determined as SYSCLKOUT (100Mhz) / prescaler > settings / period. As the current code uses 1 for the prescaler and > the period is a 16bit value the lower frequency you can have is > actually 1.529Khz. >=20 >> # sysctl dev.am335x_pwm.1.period=3D1500 >> # sysctl dev.am335x_pwm.1.dutyA=3D300 >> result frequency: 66 KHz ->should be 666 KHz >> length of period: 15 us ->should be 1.5 us >> length of pulse: 2 us >=20 > As above, this is correct: 100Mhz / 1 / 1500 =3D 66Khz. >=20 >>=20 >> # sysctl dev.am335x_pwm.1.period=3D1500000 >> # sysctl dev.am335x_pwm.1.dutyA=3D10000 >> result frequency: 1.71 KHz -> should be 666Hz >> length of period: 585 us >> length of pulse: 100 us >>=20 >> # sysctl dev.am335x_pwm.1.period=3D1800000 >> # sysctl dev.am335x_pwm.1.dutyA=3D10000 >> result frequency: 3.24 KHz -> should be 555Hz >> length of period: 308 us >> length of pulse: 100 us >=20 > These two examples are overflowing the period variable. >=20 > I've the attached patch which enforces the maximum values where needed > (to avoid such overflows) and two new sysctls, one allows you to set > the prescaler for the PWM module and the other (which is probably more > interesting) allows you to check the actual PWM frequency. >=20 > The sysctl.am335x_pwm.X.freq can also be use to set an desired > frequency directly, it will try to get you the better setting it can > find for the desired frequency, which usually means get the bigger > period it can find to give the better PWM resolution that is possible > for a given frequency. >=20 > I've been able to drive R/C servos directly with this patch and the > following set: >=20 > sysctl.am335x_pwm.X.freq =3D 50 (digital servos may operate at higher = frequencies) >=20 > And then, for the cheap chinese servo i have here, i can get it to > travel almost 180o using duty values from 2000 to 6000 (YMMV). >=20 > I've checked the frequencies with a scope and they look fine for me. >=20 > Regards, > Luiz > From owner-freebsd-arm@FreeBSD.ORG Thu May 22 19:42:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40E091FE for ; Thu, 22 May 2014 19:42:51 +0000 (UTC) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C65EF2462 for ; Thu, 22 May 2014 19:42:50 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id c41so2963617eek.31 for ; Thu, 22 May 2014 12:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DnklLEqTFc0hIAm92/hps9pRWNtfK/xmnkrBJV5VCaE=; b=ERsyMEdyjlnjSGgBmzimYdtqEX4JM8wKDShg7EchHO3zl6avA6OTI1eEUH2ySkGwyk HrLyxuA43GLK876iXGCqF64rU23Nr/qtVmGe8ClbXknstv2Yyh7LJwmDwtnteOQoXVNy HNH94sq/G+vP8z3ffTjVn3UBE7xnQOcUOJRzChCcjCTcpZhloBnBD1w4HX4H67NDImpx GIFtmwe2DXbIS6XkU70z/F0wrBKb/4dg5SFngRP3aoaeyh2O1dnENWcxescAIB3INpbx e9kE9nQaN2UTWD8hXrn3jJsrRV42248RsLmcB9XDsG6yd5r485CFM+53y9xeaL9iNeT/ STbw== X-Received: by 10.14.209.3 with SMTP id r3mr844614eeo.27.1400787768975; Thu, 22 May 2014 12:42:48 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id b12sm2637832eeh.45.2014.05.22.12.42.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 12:42:48 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <537E5336.9000006@hot.ee> Date: Thu, 22 May 2014 22:42:46 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Sulev-Madis Silber (ketas)" Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) References: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <537DF45D.8010304@hot.ee> <537E1024.1020806@hot.ee> In-Reply-To: <537E1024.1020806@hot.ee> X-TagToolbar-Keys: D20140522224246034 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 19:42:51 -0000 On 2014-05-22 17:56, Sulev-Madis Silber (ketas) wrote: > On 2014-05-22 15:58, Sulev-Madis Silber (ketas) wrote: >> On 2014-05-22 14:46, SAITOU Toshihide wrote: >>> In message: >>> Winston Smith writes: >>>> On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: >>>>> If abort like >>>>> >>>>> musbotg0: TI AM335X USBSS v0.0.13 >>>>> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' >>>>> trapframe: 0xc0a2eb60 >>>> >>>> I see this with the 1Ghz uboot, it occurs about 50% of the time, see: >>>> >>>> http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 >>> >>> Although it is an ad hoc workaround but ``usb start'' at u-boot command >>> prompt (someone mentioned before) or add device_printf("!\n") before >>> ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of >>> am335x_usbss.c prevent this panic for me. >>> >>> Anyway I understand my procedure is workaround, and is working by >>> chance or side effect, but eMMC boot and 1000 MHz operation is fun. >>> >> >> >> I wish I could get that working too... I tried to trace device detection >> path in loader but only found that the problem must be in uboot. Since >> loader is program that runs in uboot. At least now I know how that works >> a bit more. But actual issue remains unresolved. What's weird is how I >> actually boot from eMMC and it's present in uboot... Loader comes from >> eMMC and then loader suddenly has no devices inside it. The hell is that. >> > > > Works now... I didn't change code but the way how uboot is configured > through crochet. I think if you want to really piss yourself off then > messing with crochet is good way to do this. I wish those several > versions (normal, devel) of uboot can be added to ports instead (one is > already there), once we get good version. Maybe I should start > maintaining port myself because I hate the situation right now. > > Hmm... now, how do I change frequency... lower frequency can be useful > sometimes. > Now, if only I can get rid of massive "Card did not respond to voltage select!" flood when I remove SD and boot with eMMC only... I got like 1256 lines of that before kernel booted. It's almost impossible to see what else is printed there. Honestly, that mmc related patch looks lot like hack. But at least now the device is found... From owner-freebsd-arm@FreeBSD.ORG Thu May 22 20:01:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7D8E4B1 for ; Thu, 22 May 2014 20:01:13 +0000 (UTC) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68F0125EB for ; Thu, 22 May 2014 20:01:13 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id y20so3922032ier.8 for ; Thu, 22 May 2014 13:01:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8jtwETfT61tld33/fxaqwORhX6saPIVNi3IU8P2kryE=; b=TSa2tg3BKTM4bJ+dcjIAvxHp/Y+c+BXxKeQRs3Dvaq7gKvCmz6cIPT4zS/fBVJMYdX 50M9jP2eFfKg/D/R/tRXyRVQ39Ax8ydTqPdtbKqqjkVY6ArEq5d83qS0IzZGHREh4YO1 0BEFI7ZnUHIkSvym6nRRH4hXbqJxFyabbbBiHFMtkAzHT+4Zsa9jQEqMWSMXm7b50Pn5 00Ag1+O6eR3hgGEpj4RhCGSMqwfhXGivWDGP0p2FHbqO4CQlQgtkq4D1lTBedo3DrafG s4kN4bipRabYtseyJRwg5CqWJq5+X0wbZB42eXcqJx35OVKhkpojggUaaPOug7JFf1Cy Qi+w== X-Gm-Message-State: ALoCoQk+nLcmnIUARQFxsWWXmKUOhDxwPvKyIoQR+8NnU/L0ILHhsp5aSfYm+b8/libzNuM6VOAw X-Received: by 10.50.25.105 with SMTP id b9mr24955723igg.28.1400788872148; Thu, 22 May 2014 13:01:12 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qh3sm15586808igb.17.2014.05.22.13.01.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 13:01:11 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_569B3D00-6DD1-4E20-9843-EFE08DC09FB6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: MK_ARM_EABI to retire in current From: Warner Losh In-Reply-To: <20140522155210.GA57720@zibbi.meraka.csir.co.za> Date: Thu, 22 May 2014 14:00:50 -0600 Message-Id: References: <20140521192807.GA48338@zibbi.meraka.csir.co.za> <95AD97BA-AA48-4BBF-845C-D0CB585ACAA3@bsdimp.com> <20140522090504.GA22488@zibbi.meraka.csir.co.za> <5D4F0BD5-89DA-421F-B095-A5F2C49F3DF9@bsdimp.com> <20140522155210.GA57720@zibbi.meraka.csir.co.za> To: John Hay X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:01:13 -0000 --Apple-Mail=_569B3D00-6DD1-4E20-9843-EFE08DC09FB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 22, 2014, at 9:52 AM, John Hay wrote: > On Thu, May 22, 2014 at 08:07:34AM -0600, Warner Losh wrote: >>=20 >> On May 22, 2014, at 3:05 AM, John Hay wrote: >>=20 >>> On Wed, May 21, 2014 at 02:01:42PM -0600, Warner Losh wrote: >>>>=20 >>>> On May 21, 2014, at 1:28 PM, John Hay wrote: >>>>=20 >>>>> On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: >>>>>> isn't eabi on the xscale still broken? >>>>>=20 >>>>> It might still be broken. But there are more brokenness than that. = :-( >>>>> By defining WITHOUT_ARM_EABI=3Dyes in src.conf, I can get an AVILA = kernel >>>>> built that boots with src from head at around mid December. Latest = 10 >>>>> and head just give no output, with or without WITHOUT_ARM_EABI = defined. >>>>=20 >>>> Does the same thing happen with make.conf instead of src.conf? >>>=20 >>> Yes, I have tried both 10 and head with WITHOUT_ARM_EABI=3Dyes and = no >>> output after go in redboot. My compile lines look like this: >>>=20 >>> make TARGET_ARCH=3Darmeb TARGET_CPUTYPE=3Dxscale toolchain >>> make TARGET=3Darm TARGET_ARCH=3Darmeb buildkernel KERNCONF=3DAVILA = DESTDIR=3D/arm/ >>>=20 >>> And then in redboot "load -b 0x200000 kernel" to load it with tftp. = And >>> then "go". >>>=20 >>> The "no output" happened somewhere between mid December and = beginning >>> of Feb. I determined that before getting side tracked. I'll see in = the >>> next day or two if I can narrow that down. >>>=20 >>> If someone have patches so that WITHOUT_ARM_EABI=3Dyes is not needed >>> anymore, I'll test that too. >>=20 >> This is with gcc, not clang, right? >=20 > The default that the tree will do for the above commands. I did not = force > it one way or the other. The kernels that did boot, reported gcc 4.2.1 OK. Just making sure. Warner >> Warner >>=20 >>=20 >>> John >>>=20 >>>>=20 >>>> Warner >>>>=20 >>>>> John >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -a >>>>>>=20 >>>>>>=20 >>>>>> On 19 May 2014 08:40, Warner Losh wrote: >>>>>>> Greetings, >>>>>>>=20 >>>>>>> MK_ARM_EABI is going to die in current. It is the default for = all platforms currently. I???m eliminating it as a build option. It must = die because it invisibly (to uname) effects the ABI. >>>>>>>=20 >>>>>>> So, to that end, I see two options: >>>>>>>=20 >>>>>>> (1) Retire and remove oabi support. >>>>>>> (2) Retain oabi support, but change its name to armo and armoeb. >>>>>>>=20 >>>>>>> The rough consensus of arm developers I???ve polled now, and in = the past, is that we just let oabi support die now that EABI support is = working for everybody. >>>>>>>=20 >>>>>>> Before I pull the trigger on this, however, I must ask if = anybody has a problem with my doing option (1), and if so, what keeps = you using oabi. >>>>>>>=20 >>>>>>> Comments? >>>>>>>=20 >>>>>>> Warner >>>>>>>=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" >>>>>> _______________________________________________ >>>>>> 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" --Apple-Mail=_569B3D00-6DD1-4E20-9843-EFE08DC09FB6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTfldyAAoJEGwc0Sh9sBEAnOIQAJctv+P1ctfUQ5H1FXpyJnWJ KKyaV116oka+IfTDis+7n5viDE/fA0+l6QBUZGk4Z1+yxO+vWPWuj5NBp1ol9aib +/yq2eKEzy5LxwCypXnYa65Ib40JPxANi1ftDYazBIAXX89o1ZmfrH7ulOc1bJQY VmEmbGXRlAAR3cSG/ubhLxIH593vtvtT7qKX8q8QkaYebX/qpf8JfytlJjefGgiH BsbJ7ddHjUzKRuKoqNsGUt9YT+5MZMzjhyGDcSbYZwMR8ARDI5RpnIhMAGBOEE1y +8BRA7EUmyHX0Jc6EUELBE6okV54G7sd0Xn1mb14NeWH+YBfUsJ6WV2nPU+VdVKJ 15I0asi4elGbmxqIeiX0LaW76kBpgh7Qc7t2RM6LV5juFEbRTiB3XEqVvKQLynar MjcU4rtOjMpMDsuOKnN/fLN1B7NjGCV23KBCYWGUY01P8P8ho8JLL8c5Biia0ijV IbBDUpFmRu8x7uIhvbbbQxObIHcWO/F2IOKc0REUopA9x4I+I7h4BJZAWkhYFsEx hF3EgEfJsyo+SzsbsK/1+ydTyHI3Ez+EtWWdKHleXr+5JOtA/SvPfRvstt3LOqXb GJzdz5dYREUEElkUE4zpVu34GPy1wuElavHk+pKGAMyXeByq8XeNcS8VNWnO4Gzk SKbfDXn6XmRhKdKBvdNX =d8VS -----END PGP SIGNATURE----- --Apple-Mail=_569B3D00-6DD1-4E20-9843-EFE08DC09FB6-- From owner-freebsd-arm@FreeBSD.ORG Thu May 22 21:45:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFE5D2BB for ; Thu, 22 May 2014 21:45:41 +0000 (UTC) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.wp.pl", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 576C52EF4 for ; Thu, 22 May 2014 21:45:40 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 10223 invoked from network); 22 May 2014 23:18:55 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1400793535; bh=eRBQlaHNlX2YhfFExfMpKM1YxfBmRNODr3j/f1I0JCo=; h=From:To:Subject; b=ORxkRYAP2JXBWT5O/M+T+5jBw/9iZX5EmpOCViS78cbPhgNHhua+I9lNUh0hsl45m giY51q8K5kBPmmUnbZMlluqLFP0Z51rRW2Ic9dXB5VST3QrplYkXH3/vVRe+0FeXxg lEi3RNOxWPIZbYtXspqXV2D2X8QoybxjSh1ssT0Y= Received: from 250-210-250-178.ftth.cust.kwaoo.net (HELO [192.168.1.105]) (marek_sal@[178.250.210.250]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES128-SHA encrypted SMTP for ; 22 May 2014 23:18:55 +0200 Message-ID: <537E69BD.1010103@wp.pl> Date: Thu, 22 May 2014 23:18:53 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: WiFi USB dongle for RPi? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [oROk] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 21:45:41 -0000 Hi list, I would like to ask you about the good WiFi USB dongle for Raspberry Pi B model. Mine colleague has been using the WiPi dongle (based on RT5370 chipset) with success on Raspbian, but I am not sure about how is it supported under FreeBSD ? Could you recommend me some WiFi USB dongles that work good under FreeBSD ? regards, Marek From owner-freebsd-arm@FreeBSD.ORG Fri May 23 01:44:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 616C6C38 for ; Fri, 23 May 2014 01:44:20 +0000 (UTC) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C514B213C for ; Fri, 23 May 2014 01:44:19 +0000 (UTC) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.8/8.14.8) with ESMTP id s4N1i9H4036029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 May 2014 09:44:10 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.8/8.14.8/Submit) id s4N1i8PX036028; Fri, 23 May 2014 09:44:08 +0800 (CST) (envelope-from kevlo) Date: Fri, 23 May 2014 09:44:08 +0800 From: Kevin Lo To: Marek Salwerowicz Subject: Re: WiFi USB dongle for RPi? Message-ID: <20140523014408.GA36004@ns.kevlo.org> References: <537E69BD.1010103@wp.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <537E69BD.1010103@wp.pl> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 01:44:20 -0000 On Thu, May 22, 2014 at 11:18:53PM +0200, Marek Salwerowicz wrote: > > Hi list, Hi Marek, > > I would like to ask you about the good WiFi USB dongle for Raspberry Pi > B model. > > Mine colleague has been using the WiPi dongle (based on RT5370 chipset) > with success on Raspbian, but I am not sure about how is it supported > under FreeBSD ? > > Could you recommend me some WiFi USB dongles that work good under FreeBSD ? The run(4) driver supports RT5370-based wifi dongles. > regards, > Marek Kevin From owner-freebsd-arm@FreeBSD.ORG Fri May 23 12:52:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A49EF2C5 for ; Fri, 23 May 2014 12:52:23 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4AED22995 for ; Fri, 23 May 2014 12:52:23 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id CA676B828; Fri, 23 May 2014 14:52:19 +0200 (SAST) Date: Fri, 23 May 2014 14:52:19 +0200 From: John Hay To: freebsd-arm@freebsd.org Subject: AVILA panic: vm_fault: fault on nofault entry Message-ID: <20140523125219.GA60793@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 12:52:23 -0000 Hi Guys, Rather than abuse Warner's MK_ARM_EABI thread, I thought I'll start a new one. It seems that svn r259999 cause a variety of panics. It normally happens close to the end of the rc scripts or just after login if I do something like "dhclient npe0". ############ Starting cron. Segmentation fault vm_fault(0xc07aa4e4, 0, 2, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (P)' trapframe: 0xc091e510 FSR=00000017, FAR=00000000, spsr=a0000013 r0 =40000013, r1 =c0fcc000, r2 =00000000, r3 =00000000 r4 =c0d3e970, r5 =00000000, r6 =c06c5de0, r7 =c06f9140 r8 =c06f9100, r9 =c0d4f6d8, r10=c06c65a8, r11=c091e59c r12=00000001, ssp=c091e564, slr=c03f9368, pc =c0598cc0 [ thread pid 833 tid 100046 ] Stopped at getpbuf+0x110: str r2, [r3] ############ dhclient npe0 Segmentation fault # execve (/sbin/dhclient-script, ...): Exec format error exiting. panic: vm_radix_remove: impossible to locate the key KDB: enter: panic [ thread pid 12 tid 100008 ] Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! ############ panic: vm_fault: fault on nofault entry, addr: c092e000 KDB: enter: panic [ thread pid 872 tid 100052 ] Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! ############ The commit was: r259999 | alc | 2013-12-28 06:28:35 +0200 (Sat, 28 Dec 2013) | 8 lines MFp4 alc_popmap Change the way that reservations keep track of which pages are in use. Instead of using the page's PG_CACHED and PG_FREE flags, maintain a bit vector within the reservation. This approach has a couple benefits. First, it makes breaking reservations much cheaper because there are fewer cache misses to identify the unused pages. Second, it is a pre- requisite for supporting two or more reservation sizes. The changes was to sys/vm/vm_reserv.c and it does not look like there was any "fixes" later to that file, just some asserts added. Anyone have a clue why the AVILAs are so unhappy with this change, while it seems that all the other archs are ok with it? Or did it need some change in another file maybe? That commit did not touch other files. Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Fri May 23 13:04:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41D0154F for ; Fri, 23 May 2014 13:04:25 +0000 (UTC) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C65112AB7 for ; Fri, 23 May 2014 13:04:23 +0000 (UTC) Received: from [98.139.215.142] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 23 May 2014 13:04:17 -0000 Received: from [98.139.213.12] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 23 May 2014 13:04:17 -0000 Received: from [127.0.0.1] by smtp112.mail.bf1.yahoo.com with NNFMP; 23 May 2014 13:04:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s1024; t=1400850256; bh=LRtkeDOj3y36g6pgzKg1RZAdBAK2+VftskogpEmnQZs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=iaKNUJjpaddg9RW0Cs0HBSsc4YhAS8baiZO9/2VVJtnfeYAkijhdh+RRSkcuzHn5zYO27DpQIZ4pjfGCQVPEB7oTPALsGhpRneEaN+3EOUuA8cIIMl9nL+OYndU8WaSLTmjAgeFzR9NfdGuBfr6lH1eaNFMsF8K5rzE21nVmabY= X-Yahoo-Newman-Id: 998993.28409.bm@smtp112.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: QGk_.qMVM1nmXMCH8Ia2uQu7MPG7L2n1FbLUXfUnwtLEAGd XKh9qA8hD7qC43v.g_RQ9E_e9WqfGgGIrQzZHMjgj6yFYIK9Emm7lHUvECzq ueqVKTzB1zSGSsbcuvg8qsIJ10ByqW5JGIXeIVWEdVWyuZ33khnC6W6GAbog kBV_DkmGACAGOL29ew.Hvr6_HEffRCzOLSRQ9UHvYEqbMRJcpLHKYt3OUqod s8O.E79.l0VCQmWAtjl.0H0zUD6X5Bczi.4G3G8tNrxbuQ7YRhUC72qRImv5 1acgiELl.G2OArffWEX87PqWQVatHiW5GkhM87C6iUGTIMi4UTAWxipcHfvS fn.PmpkPo5fQK1tWUXjoFkkTPtT8XMe3hUT26JOQhxTk2M8_R4XGSIWlN_lr bg.zU1vTFHi8TIP0wo_ol7Nj0wir5Fr4IU.i_YCwY5AGm1.zAzLltbwWE_yw wK1DGBo_NEj7zTeyc0TOvTFp3f2VZypWiJXn8Y5J1qEBY3JX0RxFQGt1AjEj 8iOFu_I8pb_dOojlE8NGZ40ywWMM- X-Yahoo-SMTP: 51p0rh2swBCh3zxf6sJkNseoFwQzw1o- X-Rocket-Received: from [192.168.0.106] (daniloegea@177.34.241.163 with plain [98.138.105.21]) by smtp112.mail.bf1.yahoo.com with SMTP; 23 May 2014 06:04:16 -0700 PDT Message-ID: <537F4774.6010804@yahoo.com.br> Date: Fri, 23 May 2014 10:04:52 -0300 From: Danilo Egea User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: WiFi USB dongle for RPi? References: <537E69BD.1010103@wp.pl> In-Reply-To: <537E69BD.1010103@wp.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:04:25 -0000 On 05/22/14 18:18, Marek Salwerowicz wrote: > Hi list, > > I would like to ask you about the good WiFi USB dongle for Raspberry Pi > B model. > > Mine colleague has been using the WiPi dongle (based on RT5370 chipset) > with success on Raspbian, but I am not sure about how is it supported > under FreeBSD ? > > Could you recommend me some WiFi USB dongles that work good under FreeBSD ? > > regards, > Marek > _______________________________________________ > 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" > Hello, I'm using this adapter on FreeBSD current and 10 stable, works fine. From owner-freebsd-arm@FreeBSD.ORG Sat May 24 11:02:12 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C49BFEC5; Sat, 24 May 2014 11:02:12 +0000 (UTC) Received: from msgw001-05.ocn.ad.jp (msgw001-05.ocn.ad.jp [180.37.203.74]) by mx1.freebsd.org (Postfix) with ESMTP id 761B421B0; Sat, 24 May 2014 11:02:12 +0000 (UTC) Received: from localhost (p12095-ipngn100104sizuokaden.shizuoka.ocn.ne.jp [153.185.230.95]) by msgw001-05.ocn.ad.jp (Postfix) with ESMTP id 2E363A82C14; Sat, 24 May 2014 20:02:10 +0900 (JST) Date: Sat, 24 May 2014 20:02:09 +0900 (JST) Message-Id: <20140524.200209.80875877.toshi@ruby.ocn.ne.jp> To: ian@FreeBSD.org Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <20140522.231404.174358702.toshi@ruby.ocn.ne.jp> References: <20140522.203923.240655619.toshi@ruby.ocn.ne.jp> <1400764684.1152.218.camel@revolution.hippie.lan> <20140522.231404.174358702.toshi@ruby.ocn.ne.jp> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 11:02:12 -0000 In message: <20140522.231404.174358702.toshi@ruby.ocn.ne.jp> SAITOU Toshihide writes: > In message: <1400764684.1152.218.camel@revolution.hippie.lan> > Ian Lepore writes: >> On Thu, 2014-05-22 at 20:39 +0900, SAITOU Toshihide wrote: >>> In message: <1400708280.1152.199.camel@revolution.hippie.lan> >>> Ian Lepore writes: >>> > On Tue, 2014-05-20 at 23:42 +0900, SAITOU Toshihide wrote: >>> >> In message: <537B62D1.4090901@hot.ee> >>> >> "Sulev-Madis Silber (ketas)" writes: >>> >> > On 2014-05-20 15:20, SAITOU Toshihide wrote: >>> >> >> In message: <20140520.191001.03109216.toshi@ruby.ocn.ne.jp> >>> >> >> SAITOU Toshihide writes: >>> >> >>> In message: <537ACDB2.9080808@hot.ee> >>> >> >>> "Sulev-Madis Silber (ketas)" writes: >>> >> >>>> >>> >> >>>> Actually I guess many people might think like me... "HELL, optimizing >>> >> >>>> boot time of 1min?! I have more important tasks to do than this". >>> >> >>> >>> >> >>> If you have ``device sdhci'' line in conf/BEAGLEBONE, is there any >>> >> >>> differences by changing mmchs to sdhci in am335x.dtsi and >>> >> >>> beaglebone-black.dts? And also remove ``status = "disabled"'' >>> >> > >>> >> > Don't edit am335x.dtsi >>> >> > >>> >> > And beaglebone-black.dts already has proper config. >>> >> >>> >> In this case, how does ``device sdhci'' driver know the register address? >>> >> I thought that there is an inconsistency in BEAGLEBONE config and >>> >> dts file for the SD/MMC driver. >>> > >>> > The name@address tag in the dts[i] files doesn't have to match the >>> > driver name in the kernel config. What matters for matching the driver >>> > to the right entry in the dts is the "compatible=" property. The >>> > ti_sdhci driver looks for an entry with any one of these compatible >>> > strings: >>> > >>> > "ti,omap3-hsmmc", "ti,omap4-hsmmc", "ti,mmchs" >>> >>> Ah! I see ti_sdhci.c has ofw_bus_is_compatible(dev, "ti,mmchs"). >>> (Why I felt difference of eMMC detection... Hmm...) >> >> What version of source code are you using to see that? You should be >> seeing a ofw_bus_search_compatible() call using a table of compatible >> strings that has those entries I listed. > > FreeBSD 11.0-CURRENT #41 r265876:266494M: Thu May 22 08:18:49 JST 2014 > but ti_sdhci.c is 254559 I am suprised. I will try at the weekend. Without changing dts, SD/eMMC is fairly working. It seems that my feeling was caused by source contamination. -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Sat May 24 11:08:40 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FD66F27; Sat, 24 May 2014 11:08:40 +0000 (UTC) Received: from msgw001-03.ocn.ad.jp (msgw001-03.ocn.ad.jp [180.37.203.72]) by mx1.freebsd.org (Postfix) with ESMTP id 2FA1B21C8; Sat, 24 May 2014 11:08:39 +0000 (UTC) Received: from localhost (p12095-ipngn100104sizuokaden.shizuoka.ocn.ne.jp [153.185.230.95]) by msgw001-03.ocn.ad.jp (Postfix) with ESMTP id CEF0AAE2913; Sat, 24 May 2014 20:08:38 +0900 (JST) Date: Sat, 24 May 2014 20:08:37 +0900 (JST) Message-Id: <20140524.200837.142870524.toshi@ruby.ocn.ne.jp> To: ian@FreeBSD.org Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <1400768866.1152.231.camel@revolution.hippie.lan> References: <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> <1400768866.1152.231.camel@revolution.hippie.lan> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 11:08:40 -0000 In message: <1400768866.1152.231.camel@revolution.hippie.lan> Ian Lepore writes: > On Thu, 2014-05-22 at 23:15 +0900, SAITOU Toshihide wrote: >> In message: <1400765234.1152.224.camel@revolution.hippie.lan> >> Ian Lepore writes: >> > On Thu, 2014-05-22 at 20:46 +0900, SAITOU Toshihide wrote: >> >> In message: >> >> Winston Smith writes: >> >> > On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: >> >> >> If abort like >> >> >> >> >> >> musbotg0: TI AM335X USBSS v0.0.13 >> >> >> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' >> >> >> trapframe: 0xc0a2eb60 >> >> > >> >> > I see this with the 1Ghz uboot, it occurs about 50% of the time, see: >> >> > >> >> > http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 >> >> >> >> Although it is an ad hoc workaround but ``usb start'' at u-boot command >> >> prompt (someone mentioned before) or add device_printf("!\n") before >> >> ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of >> >> am335x_usbss.c prevent this panic for me. >> > >> > An 'external non-linefetch abort' on a TI chip usually means that the >> > clocks for a device never got turned on and you attempted to read or >> > write a register in that device. If 'usb start' makes the problem go >> > away, that tends to confirm that thought. >> > >> > The thing is, I don't understand why adding a printf to the code with no >> > other changes would help in any way. I though maybe it was adding some >> > delay to allow the clock-start call to take effect, but the clock enable >> > call is after the USBSS_REVREG read, and that seems wrong. >> > >> > Does it fix the problem to move the ti_prcm_clk_enable() call to be >> > before the USBSS_REVREG read in attach? >> >> I will try ti_prcm_clk_enable() at the weekend. But someone's report >> would be appriciated because I remove the src and svn up now. > > If you have done svn up -rnnnnn on individual files, I think svn will > then leave those files at that revision when you do future updates. > Doing 'svn revert -R .' in the src directory should get everything reset > so that 'svn up' will pull the latest versions of everything again. Of > course, it will also revert *every* change you've made under src, so use > it carefully! It should be faster than checking out a fresh copy, and > you can still do a -DNO_CLEAN build and rebuild just the things that > have changed. Of course you can also use svn revert on a single file or > directory too. Thankyou for your infomation, I could revert back and svn up. But after that I lost .svn repository accidentally, so I can't tell a revision number (about ~two days before I think) for this report sorry. Anyway I will never do that. BEAGLEBONE config is changed to include beaglebone-black.dts, boot from SD by pressing S2, repeat power cycle and hit enter key randomly when ``Hit [Enter] to boot immediately''. result: 'external non-linefetch abort' was disappeared, and very few 'translation fault' was observed. vm_fault(0xc092d960, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc0a26b30 FSR=00000005, FAR=00000018, spsr=80000193 r0 =c288d380, r1 =00000000, r2 =00000019, r3 =60000193 r4 =00000000, r5 =c288d380, r6 =00000006, r7 =c053e8fc r8 =c288d380, r9 =c28e928c, r10=c28e70c8, r11=c0a26b90 r12=00000000, ssp=c0a26b80, slr=c055fedc, pc =c0391098 [ thread pid 0 tid 100000 ] Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] It maybe that the test has lost the meagning but tried. without change: 3 error / 20 trial with change: 1 error / 20 trial I think operation bias exist from halfway through because the error disappear against my expectation (it's a happy thing though). -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Sat May 24 16:49:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34A1ACAA; Sat, 24 May 2014 16:49:29 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FB5F2A22; Sat, 24 May 2014 16:49:28 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id bs8so2265496wib.6 for ; Sat, 24 May 2014 09:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4rfUF6F8jp7W2NuBTjGMGmze8RgrfACjYQeNjZYt/zg=; b=oh0q9P8CqcIzMUdNwLveb4PXejHntawYdR6oX306wTim3cQgVM1ychY3Npu/mp2Lg8 OMkQ8gScKkdfKQLDEuT+YPZL/JryTyMyqnDxS3+StLetLQFa3PITkwuOiAlT2KYitCM4 qrM/5lM9FG2YsEugnwj8nnU8DgVcbYm6JydO4wuL+U+I3saZdBapl4BhotpaaGplVKGg IajDw4Jt4Ke3jUQ/HSNkbLiYJme/KFqkmJ2OvcV+n5EeclntsLePEc21qkAprqDHx0qG QKc1gcoMreny3rYUahpMoBZioqojzeaErEnijOp6o27lOE37oDv0Q7tj5h7Hb3NlY/O0 v56g== MIME-Version: 1.0 X-Received: by 10.194.57.38 with SMTP id f6mr12362954wjq.59.1400950166857; Sat, 24 May 2014 09:49:26 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Sat, 24 May 2014 09:49:26 -0700 (PDT) In-Reply-To: <20140524.200837.142870524.toshi@ruby.ocn.ne.jp> References: <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> <1400768866.1152.231.camel@revolution.hippie.lan> <20140524.200837.142870524.toshi@ruby.ocn.ne.jp> Date: Sat, 24 May 2014 12:49:26 -0400 Message-ID: Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Winston Smith To: SAITOU Toshihide Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 16:49:29 -0000 On Sat, May 24, 2014 at 7:08 AM, SAITOU Toshihide wrote: >>> > Does it fix the problem to move the ti_prcm_clk_enable() call to be >>> > before the USBSS_REVREG read in attach? >>> >>> I will try ti_prcm_clk_enable() at the weekend. But someone's report >>> would be appriciated because I remove the src and svn up now. Just to clarify; you applied the ti_prcm_clk_enable() to fix the 'non-linefetch abort' (above). > BEAGLEBONE config is changed to include beaglebone-black.dts, boot > from SD by pressing S2, repeat power cycle and hit enter key randomly > when ``Hit [Enter] to boot immediately''. > > result: > > 'external non-linefetch abort' was disappeared, and very few > 'translation fault' was observed. > > vm_fault(0xc092d960, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc0a26b30 > FSR=00000005, FAR=00000018, spsr=80000193 > r0 =c288d380, r1 =00000000, r2 =00000019, r3 =60000193 > r4 =00000000, r5 =c288d380, r6 =00000006, r7 =c053e8fc > r8 =c288d380, r9 =c28e928c, r10=c28e70c8, r11=c0a26b90 > r12=00000000, ssp=c0a26b80, slr=c055fedc, pc =c0391098 > > [ thread pid 0 tid 100000 ] > Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] But now you're running into these 'translation fault' traps? From owner-freebsd-arm@FreeBSD.ORG Sat May 24 17:23:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8034A62; Sat, 24 May 2014 17:23:30 +0000 (UTC) Received: from msgw002-04.ocn.ad.jp (msgw002-04.ocn.ad.jp [180.37.203.79]) by mx1.freebsd.org (Postfix) with ESMTP id B468F2CF4; Sat, 24 May 2014 17:23:30 +0000 (UTC) Received: from localhost (p12095-ipngn100104sizuokaden.shizuoka.ocn.ne.jp [153.185.230.95]) by msgw002-04.ocn.ad.jp (Postfix) with ESMTP id BF2A4FFD7; Sun, 25 May 2014 02:23:28 +0900 (JST) Date: Sun, 25 May 2014 02:23:27 +0900 (JST) Message-Id: <20140525.022327.158424841.toshi@ruby.ocn.ne.jp> To: smith.winston.101@gmail.com Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: References: <1400768866.1152.231.camel@revolution.hippie.lan> <20140524.200837.142870524.toshi@ruby.ocn.ne.jp> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, ian@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 17:23:31 -0000 In message: Winston Smith writes: > On Sat, May 24, 2014 at 7:08 AM, SAITOU Toshihide wrote: >>>> > Does it fix the problem to move the ti_prcm_clk_enable() call to be >>>> > before the USBSS_REVREG read in attach? >>>> >>>> I will try ti_prcm_clk_enable() at the weekend. But someone's report >>>> would be appriciated because I remove the src and svn up now. > > Just to clarify; you applied the ti_prcm_clk_enable() to fix the > 'non-linefetch abort' (above). No. I revert back and update the source about two days before, and so far, I can't reproduce the above failure. >> BEAGLEBONE config is changed to include beaglebone-black.dts, boot >> from SD by pressing S2, repeat power cycle and hit enter key randomly >> when ``Hit [Enter] to boot immediately''. >> >> result: >> >> 'external non-linefetch abort' was disappeared, and very few >> 'translation fault' was observed. >> >> vm_fault(0xc092d960, 0, 1, 0) -> 1 >> Fatal kernel mode data abort: 'Translation Fault (S)' >> trapframe: 0xc0a26b30 >> FSR=00000005, FAR=00000018, spsr=80000193 >> r0 =c288d380, r1 =00000000, r2 =00000019, r3 =60000193 >> r4 =00000000, r5 =c288d380, r6 =00000006, r7 =c053e8fc >> r8 =c288d380, r9 =c28e928c, r10=c28e70c8, r11=c0a26b90 >> r12=00000000, ssp=c0a26b80, slr=c055fedc, pc =c0391098 >> >> [ thread pid 0 tid 100000 ] >> Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] > > But now you're running into these 'translation fault' traps? But only very few, plus I may have a bias when operating power cycle (for expecting the same result). -- SAITOU Toshihide From owner-freebsd-arm@FreeBSD.ORG Sat May 24 22:47:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 980D19A2 for ; Sat, 24 May 2014 22:47:20 +0000 (UTC) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 644F82494 for ; Sat, 24 May 2014 22:47:20 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id i7so7080055oag.6 for ; Sat, 24 May 2014 15:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=LKwWpCk9tA8G/G6jeG2DG+bJJWQCYJs4INnAYDXxsak=; b=YkyKdEYEdhBMw9x7FLXxSmmFgffk5t4y8wh+KITnBNSWwxy1PsFV67rCBpjkQF1ulB zJ8a1s+SexVuWezvyqIkTmjzJ0I+zIjuN+yiiZcz+ZO1MUfJp+NfzpUS5PPugfDHcTJY zKkMdSpyulPPTMsf2U7kCm5CgEKnwmd8kfPjubpcgLG5yHXMBV7tqeA6JWB4gAcJ7ibS W2nGyiFZq5UxEwPmDo/P+6nyqmgHN6W6fp6t+ax76oSsSjM7BUmISg8qC+HPNgcUhErJ Jw96p6DJJNkcEel9UAE0okQYIsjdJ1nXxEMo/Y3fmk66s2t1MXl0h38nx7pupOf420O0 M46A== MIME-Version: 1.0 X-Received: by 10.182.18.102 with SMTP id v6mr13310089obd.71.1400971639672; Sat, 24 May 2014 15:47:19 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.76.10.101 with HTTP; Sat, 24 May 2014 15:47:19 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 May 2014 00:47:19 +0200 X-Google-Sender-Auth: 9CyJWL4klwH0qhnq0R3qK0Mmywg Message-ID: Subject: Re: Superpages by default From: Zbigniew Bodek To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 22:47:20 -0000 2014-05-14 20:12 GMT+02:00 Zbigniew Bodek : > Hello all, > > Since we have SMP fixed and it seems that there are no more known bugs > in ARM superpages then we could enable superpages by default. > I'm attaching the patch that is to be committed to make that happen. > > If you are not using superpages on your ARM platforms, I will > appreciate if you could try them out on the current HEAD and report > any negative experience. > > If there are no objections then I would like to enable this feature in > a week from now. > > Thanks and best regards > zbb Hi again. It's done: r266631 Thanks and best regards zbb From owner-freebsd-arm@FreeBSD.ORG Mon May 26 11:06:43 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A0B1D68 for ; Mon, 26 May 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C86E24D1 for ; Mon, 26 May 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4QB6gUL031953 for ; Mon, 26 May 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4QB6gJU031951 for freebsd-arm@FreeBSD.org; Mon, 26 May 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 May 2014 11:06:42 GMT Message-Id: <201405261106.s4QB6gJU031951@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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 11:06:43 -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/189415 arm [patch] mount_smbfs missing from arm o arm/188933 arm [lor] lock order reversal: backtrace while writing to o arm/187223 arm omap4 clock frequency computation overflow o arm/186486 arm WPS authentication is failing o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o ports/175605 arm devel/binutils: please fix build binutils-2.23.1 in ra 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/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 ports/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 [at91] [patch] Enable at91 booting from SDHC (high cap 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/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 27 problems total. From owner-freebsd-arm@FreeBSD.ORG Tue May 27 11:15:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D130CE8 for ; Tue, 27 May 2014 11:15:46 +0000 (UTC) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48A222CBC for ; Tue, 27 May 2014 11:15:46 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id wm4so9075265obc.4 for ; Tue, 27 May 2014 04:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v53Ai5gJ1cf6+pv7Vpgab6pgBgq31YISc2K4tvyZrxE=; b=RERaC1FgC/i6EesyKC7HTLgPFg67Np1dt1QPKhEs1D0xphbVfkOdZ75+PyM9Hj/pl/ oo4PhkrHOHipQnfeS2nvUP9KmHGCTAm9zrBKZdUpjPvykW84CL6E6QMz3jTZMlh8yrDC 1AdtdkMNuAw7jHwZCx/5fvK8yn0wvJpSiqXEt5mg2hBmz6WFmJOfVYAfZ205b9KVt/Fe pw1nDj1nmBbOhGru/Gw+b7jb7vCH2NhsY/MOPX5fh1q7pSN03Swj6Vnk8f5X7KfQmtAp ILBHxnuP5W8z03HrvIhY5E5Wg4JtUAlLxzlbGB+jo7rcx9eAKeWzAmuSq3sHblMzJtKV T9cg== X-Received: by 10.182.229.34 with SMTP id sn2mr32190959obc.6.1401189345581; Tue, 27 May 2014 04:15:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.123.178 with HTTP; Tue, 27 May 2014 04:15:15 -0700 (PDT) In-Reply-To: <20130926034416.c2977781.mail@ulrich-grey.de> References: <201309251442.r8PEgq5J013369@m5p.com> <20130925233822.563e344b.usenet@ulrich-grey.de> <20130926034416.c2977781.mail@ulrich-grey.de> From: Jia-Shiun Li Date: Tue, 27 May 2014 19:15:15 +0800 Message-ID: Subject: Re: Raspberry Pi crashes in random() To: Ulrich Grey Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 11:15:46 -0000 On Thu, Sep 26, 2013 at 9:44 AM, Ulrich Grey wrote: > Here some additional infos: > > #16 bugdro...@chromium.org > > Commit: d2127269301823f547129ac486f4fa5f0d2e0d2a > Email: cwolfe@chromium.org > > fontconfig: Reduce optimization level > Hi all, -O0 work for me on BBB for fontconfig. Is it ok to you to file a PR for this? Previously it was worked around by depending on gcc [1], and another PR attempt by patching fontconfig for clang [2]. IMO -O0 is better for now because it does not require gcc or patching fontconfig. Looks binutils patches exist too but i'd leave those to experts. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/181372 [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/183536 -Jia-Shiun From owner-freebsd-arm@FreeBSD.ORG Tue May 27 21:32:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24A7CD8A for ; Tue, 27 May 2014 21:32:50 +0000 (UTC) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.wp.pl", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A28462826 for ; Tue, 27 May 2014 21:32:49 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 12655 invoked from network); 27 May 2014 23:32:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1401226360; bh=6Xlzi1PfG5jk4PQZtJG0ER2Sr0dj3QEE2AiXJx8PoCw=; h=From:To:Subject; b=KkPCF3lASxeJn9DipIxm7RX03aPe7Yzd6y7Is+q9cVXefL1dP19+xANO0IwFOeu0A slTbgSYioIrsF/2UkVh+lRrXiVG+ZKLdhhjf5XiPokIY82+YBcUwv3oj6ochJ2fjvD /rGcvXsATApvrHrkF7DkK/gs90m1yuOgGsjKTW00= Received: from 250-210-250-178.ftth.cust.kwaoo.net (HELO [192.168.1.104]) (marek_sal@[178.250.210.250]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES128-SHA encrypted SMTP for ; 27 May 2014 23:32:40 +0200 Message-ID: <53850478.3080302@wp.pl> Date: Tue, 27 May 2014 23:32:40 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: RPi + FreeBSD + Xorg + XBMC player ? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [8TNU] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 21:32:50 -0000 Hi list, I was wondering if anyone has succeeded in installing the X Server, simple window manager and XBMC software under FreeBSD? I would like to use my RPi as XBMC media player. So far I have realised I would need to compile everything from ports (As there is no binary packages repository..?) that would take a lot of time because of RPi's performance.. Looking forward for any comments if that setup is worth my effort ? Regards, Marek -- Marek Salwerowicz From owner-freebsd-arm@FreeBSD.ORG Wed May 28 02:18:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE2D1548 for ; Wed, 28 May 2014 02:18:22 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 543FD2E76 for ; Wed, 28 May 2014 02:18:22 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id n15so2752314wiw.9 for ; Tue, 27 May 2014 19:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bedy+Cel/2v095R7BNFSIJKAbzNQpuNhT6MUzZCa+YY=; b=TH2skZiYSXkL9fMytSt/CfgIhuUfEXJkWeC2bgkBDalvWr+1Vt+X4ef6mujE0EvZbA 4wrGozpbEaGZi00UGyz+bdYuu/XoDhrYHD3pzmgZ5zEol4C5X3GyhTuHVZTHtUuNGjTh RdqamVGtyBFoP3jOEOEXq/O6Unnz1or+kIf0YGJReTiJMwgn+WBVppUXSb9KHJYeO8G1 dCFLubvyHGdZzFWClFyNNOHQMxMX5lQe+MkrWzIt59TYXE0GFsfery3R+Yw0w51voHUc p6+y+W0VI3IwlIkY+fU4Nxg9GZhkRgb3j+/nMYJ05A5Rs56g0QWTkMd+SAY71V/RjHC4 g13w== X-Received: by 10.194.179.9 with SMTP id dc9mr45366215wjc.74.1401243500543; Tue, 27 May 2014 19:18:20 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id l5sm39383613wja.12.2014.05.27.19.18.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 19:18:19 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <53854768.1020904@hot.ee> Date: Wed, 28 May 2014 05:18:16 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Marek Salwerowicz Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? References: <53850478.3080302@wp.pl> In-Reply-To: <53850478.3080302@wp.pl> X-TagToolbar-Keys: D20140528051816303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 02:18:22 -0000 On 2014-05-28 00:32, Marek Salwerowicz wrote: > Hi list, > > I was wondering if anyone has succeeded in installing the X Server, > simple window manager and XBMC software under FreeBSD? > > I would like to use my RPi as XBMC media player. Should be possible. I've heard that X works there, but I haven't tried it by myself. RPi is something I would like to avoid. But there aren't much more other ARM choices right now. Chromebook is another thing that can somewhat output video. And BBB could maybe output something to graphic LCD (direct connection, no HMDI). But IIRC currently RPi is only thing where FB works? Apart from "Efika" hardware, maybe. > > So far I have realised I would need to compile everything from ports (As > there is no binary packages repository..?) that would take a lot of > time because of RPi's performance.. You can have emulated environment where you can compile things. > > Looking forward for any comments if that setup is worth my effort ? > > Regards, > Marek > From owner-freebsd-arm@FreeBSD.ORG Thu May 29 00:31:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CECE987 for ; Thu, 29 May 2014 00:31:54 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A09812636 for ; Thu, 29 May 2014 00:31:53 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id w62so12291738wes.30 for ; Wed, 28 May 2014 17:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=c7QFF3SdvT/QWxh24r6KI1LL0nSeIZiZjay/RgcJXIs=; b=cvgv7+as9KLMK6fCmT7oVTCw3hZJop5KrkFhMOQW4+ZoKQq8GMLvIAAwY0QMftAJ57 sw3VX3jY/7VoyfpE9H5YxNkdNxcH/j+HpcFcUW5+tr1FjbQKvTART91j64eISW8xEY4b TznO2FsvcL3CTIseJeEz5fdrfCK+cbcnD2bQja8auvm8wQWT4T+VHLahhyxPu+oSjMK+ 2xUeszigx2QSRtPQAYU9nPfzubMRwOyBBDXs+dlQQT8Y46K6XiyG3FChaSUgSG7/r84s YPsFk4ax3K13YtBz5sBtXGlXlUISBIlJpH4swe8nrfi8c4Nc6ri8vQpP132Mu2f5dk7T wDJA== MIME-Version: 1.0 X-Received: by 10.180.8.136 with SMTP id r8mr5916502wia.60.1401323511962; Wed, 28 May 2014 17:31:51 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 28 May 2014 17:31:51 -0700 (PDT) Date: Wed, 28 May 2014 20:31:51 -0400 Message-ID: Subject: BSDCan 2014: BSD/ARM Kernel Internals Video From: Winston Smith To: FreeBSD ARM Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 00:31:54 -0000 Arun Thomas did a great presentation on BSDARM Kernel Internals at this year's BSDCon; there's a video up on Youtube: https://www.youtube.com/watch?v=ZAM7fqhGRr8 The BSD of choice for this topic was FreeBSD-11-CURRENT on a BeagleBone Black. Arun's talk was very interesting! There's also a talk by Warner Losh on NAND Flash and FreeBSD (haven't had time to watch it yet), and a number of other interesting looking talks; see this list of other BSDCon '14 videos are here: http://undeadly.org/cgi?action=article&sid=20140528143344 -W From owner-freebsd-arm@FreeBSD.ORG Thu May 29 01:14:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EDF11E2 for ; Thu, 29 May 2014 01:14:44 +0000 (UTC) Received: from up-mx2.det.nsw.edu.au (up-mx2.det.nsw.edu.au [153.107.105.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECBF12931 for ; Thu, 29 May 2014 01:14:43 +0000 (UTC) Received: from itfsmtp5.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-mx2.det.nsw.edu.au (8.13.8/8.13.8) with ESMTP id s4T1358m023814; Thu, 29 May 2014 11:03:06 +1000 Received: from UGPEXHT01.central.det.win (Not Verified[153.107.78.56]) by itfsmtp5.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Thu, 29 May 2014 11:03:05 +1000 Received: from UGPEXHUB01.central.det.win (153.107.78.92) by UGPEXHT01.central.det.win (153.107.78.56) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 29 May 2014 11:03:05 +1000 Received: from WPEXCHMBUG1062.central.det.win ([169.254.5.130]) by ugpexhub01.central.det.win ([153.107.78.92]) with mapi id 14.03.0174.001; Thu, 29 May 2014 11:03:04 +1000 From: "Scott, Brian" To: "'Sulev-Madis Silber (ketas)'" , "'Marek Salwerowicz'" Subject: RE: RPi + FreeBSD + Xorg + XBMC player ? Thread-Topic: RPi + FreeBSD + Xorg + XBMC player ? Thread-Index: AQHPehsgU7brCgjM0E6IlF1NPIOQ/JtWvMCw Date: Thu, 29 May 2014 01:03:04 +0000 Message-ID: <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> References: <53850478.3080302@wp.pl> <53854768.1020904@hot.ee> In-Reply-To: <53854768.1020904@hot.ee> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.107.87.221] x-route: TAFECORP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 01:14:44 -0000 -----Original Message----- From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freebsd.org= ] On Behalf Of Sulev-Madis Silber (ketas) Sent: Wednesday, 28 May 2014 12:18 PM To: Marek Salwerowicz Cc: freebsd-arm@freebsd.org Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? >On 2014-05-28 00:32, Marek Salwerowicz wrote: >> Hi list, >>=20 >> I was wondering if anyone has succeeded in installing the X Server, >> simple window manager and XBMC software under FreeBSD? >>=20 >> I would like to use my RPi as XBMC media player. > >Should be possible. I've heard that X works there, but I haven't tried >it by myself.=20 Has anyone actually got X running recently? I've just been trying to buil= d a few packages on the Pi and it looks like things have moved on since t= he various tutorials on the web were written. The scfb video driver is in= cluded in ports now but other broken-ness in xorg-server (dri) stops it = being built. Haven't even started trying to get applications like XBMC going. Brian ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-arm@FreeBSD.ORG Thu May 29 17:14:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF640B8B; Thu, 29 May 2014 17:14:54 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8502C2037; Thu, 29 May 2014 17:14:54 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id i50so1867628qgf.7 for ; Thu, 29 May 2014 10:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=3Wm9BZQEdr4zEHVATHQBzumdqUNNFRRJt0SijpR0Msc=; b=Ja0mbX7dmOGVP2gtsQjxG97Zh+oqjfqRYCYWA7BEQ9ckdIjsDBvL2BbKXrrcdRXCsz pe14bG0e8nUYl0KOdtUuCE+WRr1EfZGmpeKS5DL8fWNSSkVBpAlDTd04BtsAYqXLHixS GFDV3crLbONqKiiab2Cn8LE0pwlViSwf1QeWSkynGnxuYhLrra6yIUDa37GJ5UrhxZUX b20zT4pvE1OyGacWJusYLXUDkgqhkiyIamvyhQPMvOnJ2Ea0cxu2nGdADPXKt7YTUErw 4Rr9EjWY+VOCFs2a00c0+U4fnxvvNoMdltmYY9W/y8/WaMZbnw1KE+wQWOJLfIcPK2Oi ZW0Q== MIME-Version: 1.0 X-Received: by 10.224.37.10 with SMTP id v10mr12129510qad.98.1401383693659; Thu, 29 May 2014 10:14:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Thu, 29 May 2014 10:14:53 -0700 (PDT) In-Reply-To: <201405291656.s4TGudoD002868@svn.freebsd.org> References: <201405291656.s4TGudoD002868@svn.freebsd.org> Date: Thu, 29 May 2014 10:14:53 -0700 X-Google-Sender-Auth: 10ReKvgYZhor1pTClRx8teYXVy8 Message-ID: Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa From: Adrian Chadd To: Olivier Houchard , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:14:55 -0000 Have you tested this on xscale hardware? -a On 29 May 2014 09:56, Olivier Houchard wrote: > Author: cognet > Date: Thu May 29 16:56:39 2014 > New Revision: 266850 > URL: http://svnweb.freebsd.org/changeset/base/266850 > > Log: > Do not hand the VM the memory used for stacks/page tables/etc. > > Modified: > head/sys/arm/xscale/i80321/ep80219_machdep.c > head/sys/arm/xscale/i80321/iq31244_machdep.c > head/sys/arm/xscale/i8134x/crb_machdep.c > head/sys/arm/xscale/ixp425/avila_machdep.c > head/sys/arm/xscale/pxa/pxa_machdep.c > > Modified: head/sys/arm/xscale/i80321/ep80219_machdep.c > ============================================================================== > --- head/sys/arm/xscale/i80321/ep80219_machdep.c Thu May 29 16:54:15 2014 (r266849) > +++ head/sys/arm/xscale/i80321/ep80219_machdep.c Thu May 29 16:56:39 2014 (r266850) > @@ -341,6 +341,10 @@ initarm(struct arm_boot_params *abp) > * Prepare the list of physical memory available to the vm subsystem. > */ > arm_physmem_hardware_region(IQ80321_SDRAM_START, memsize); > + arm_physmem_exclude_region(freemem_pt, KERNPHYSADDR - > + freemem_pt, EXFLAG_NOALLOC); > + arm_physmem_exclude_region(freemempos, KERNPHYSADDR - 0x100000 - > + freemempos, EXFLAG_NOALLOC); > arm_physmem_exclude_region(abp->abp_physaddr, > virtual_avail - KERNVIRTADDR, EXFLAG_NOALLOC); > arm_physmem_init_kernel_globals(); > > Modified: head/sys/arm/xscale/i80321/iq31244_machdep.c > ============================================================================== > --- head/sys/arm/xscale/i80321/iq31244_machdep.c Thu May 29 16:54:15 2014 (r266849) > +++ head/sys/arm/xscale/i80321/iq31244_machdep.c Thu May 29 16:56:39 2014 (r266850) > @@ -343,6 +343,10 @@ initarm(struct arm_boot_params *abp) > * Prepare the list of physical memory available to the vm subsystem. > */ > arm_physmem_hardware_region(SDRAM_START, memsize); > + arm_physmem_exclude_region(freemem_pt, KERNPHYSADDR - > + freemem_pt, EXFLAG_NOALLOC); > + arm_physmem_exclude_region(freemempos, KERNPHYSADDR - 0x100000 - > + freemempos, EXFLAG_NOALLOC); > arm_physmem_exclude_region(abp->abp_physaddr, > virtual_avail - KERNVIRTADDR, EXFLAG_NOALLOC); > arm_physmem_init_kernel_globals(); > > Modified: head/sys/arm/xscale/i8134x/crb_machdep.c > ============================================================================== > --- head/sys/arm/xscale/i8134x/crb_machdep.c Thu May 29 16:54:15 2014 (r266849) > +++ head/sys/arm/xscale/i8134x/crb_machdep.c Thu May 29 16:56:39 2014 (r266850) > @@ -323,6 +323,10 @@ initarm(struct arm_boot_params *abp) > * Prepare the list of physical memory available to the vm subsystem. > */ > arm_physmem_hardware_region(SDRAM_START, memsize); > + arm_physmem_exclude_region(freemem_pt, KERNPHYSADDR - > + freemem_pt, EXFLAG_NOALLOC); > + arm_physmem_exclude_region(freemempos, KERNPHYSADDR - 0x100000 - > + freemempos, EXFLAG_NOALLOC); > arm_physmem_exclude_region(abp->abp_physaddr, > virtual_avail - KERNVIRTADDR, EXFLAG_NOALLOC); > arm_physmem_init_kernel_globals(); > > Modified: head/sys/arm/xscale/ixp425/avila_machdep.c > ============================================================================== > --- head/sys/arm/xscale/ixp425/avila_machdep.c Thu May 29 16:54:15 2014 (r266849) > +++ head/sys/arm/xscale/ixp425/avila_machdep.c Thu May 29 16:56:39 2014 (r266850) > @@ -413,6 +413,10 @@ initarm(struct arm_boot_params *abp) > * Prepare the list of physical memory available to the vm subsystem. > */ > arm_physmem_hardware_region(PHYSADDR, memsize); > + arm_physmem_exclude_region(freemem_pt, KERNPHYSADDR - > + freemem_pt, EXFLAG_NOALLOC); > + arm_physmem_exclude_region(freemempos, KERNPHYSADDR - 0x100000 - > + freemempos, EXFLAG_NOALLOC); > arm_physmem_exclude_region(abp->abp_physaddr, > virtual_avail - KERNVIRTADDR, EXFLAG_NOALLOC); > arm_physmem_init_kernel_globals(); > > Modified: head/sys/arm/xscale/pxa/pxa_machdep.c > ============================================================================== > --- head/sys/arm/xscale/pxa/pxa_machdep.c Thu May 29 16:54:15 2014 (r266849) > +++ head/sys/arm/xscale/pxa/pxa_machdep.c Thu May 29 16:56:39 2014 (r266850) > @@ -335,6 +335,10 @@ initarm(struct arm_boot_params *abp) > if (memsize[j] > 0) > arm_physmem_hardware_region(memstart[j], memsize[j]); > } > + arm_physmem_exclude_region(freemem_pt, KERNPHYSADDR - > + freemem_pt, EXFLAG_NOALLOC); > + arm_physmem_exclude_region(freemempos, KERNPHYSADDR - 0x100000 - > + freemempos, EXFLAG_NOALLOC); > arm_physmem_exclude_region(abp->abp_physaddr, > virtual_avail - KERNVIRTADDR, EXFLAG_NOALLOC); > arm_physmem_init_kernel_globals(); > From owner-freebsd-arm@FreeBSD.ORG Thu May 29 17:16:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D73CBF5; Thu, 29 May 2014 17:16:54 +0000 (UTC) Received: from kanar.ci0.org (kanar.ci0.org [IPv6:2001:bc8:35e6::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8F7E2051; Thu, 29 May 2014 17:16:53 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.8/8.14.8) with ESMTP id s4THGf58005258; Thu, 29 May 2014 19:16:41 +0200 (CEST) (envelope-from cognet@ci0.org) Received: (from doginou@localhost) by kanar.ci0.org (8.14.8/8.14.8/Submit) id s4THGfJN005257; Thu, 29 May 2014 19:16:41 +0200 (CEST) (envelope-from cognet@ci0.org) X-Authentication-Warning: kanar.ci0.org: doginou set sender to cognet@ci0.org using -f Date: Thu, 29 May 2014 19:16:41 +0200 From: Olivier Houchard To: Adrian Chadd Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140529171641.GA5246@ci0.org> References: <201405291656.s4TGudoD002868@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:16:54 -0000 On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > Have you tested this on xscale hardware? Yeah, my two last commits were an attempt to get the AVILA kernel to boot again. Olivier > > On 29 May 2014 09:56, Olivier Houchard wrote: > > Author: cognet > > Date: Thu May 29 16:56:39 2014 > > New Revision: 266850 > > URL: http://svnweb.freebsd.org/changeset/base/266850 > > > > Log: > > Do not hand the VM the memory used for stacks/page tables/etc. > > > > Modified: > > head/sys/arm/xscale/i80321/ep80219_machdep.c > > head/sys/arm/xscale/i80321/iq31244_machdep.c > > head/sys/arm/xscale/i8134x/crb_machdep.c > > head/sys/arm/xscale/ixp425/avila_machdep.c > > head/sys/arm/xscale/pxa/pxa_machdep.c > > > > Modified: head/sys/arm/xscale/i80321/ep80219_machdep.c > > ============================================================================== > > --- head/sys/arm/xscale/i80321/ep80219_machdep.c Thu May 29 16:54:15 2014 (r266849) > > +++ head/sys/arm/xscale/i80321/ep80219_machdep.c Thu May 29 16:56:39 2014 (r266850) > > @@ -341,6 +341,10 @@ initarm(struct arm_boot_params *abp) > > * Prepare the list of physical memory available to the vm subsystem. > > */ > > arm_physmem_hardware_region(IQ80321_SDRAM_START, memsize); > > + arm_physmem_exclude_region(freemem_pt, KERNPHYSADDR - > > + freemem_pt, EXFLAG_NOALLOC); > > + arm_physmem_exclude_region(freemempos, KERNPHYSADDR - 0x100000 - > > + freemempos, EXFLAG_NOALLOC); > > arm_physmem_exclude_region(abp->abp_physaddr, > > virtual_avail - KERNVIRTADDR, EXFLAG_NOALLOC); > > arm_physmem_init_kernel_globals(); > > > > Modified: head/sys/arm/xscale/i80321/iq31244_machdep.c > > ============================================================================== > > --- head/sys/arm/xscale/i80321/iq31244_machdep.c Thu May 29 16:54:15 2014 (r266849) > > +++ head/sys/arm/xscale/i80321/iq31244_machdep.c Thu May 29 16:56:39 2014 (r266850) > > @@ -343,6 +343,10 @@ initarm(struct arm_boot_params *abp) > > * Prepare the list of physical memory available to the vm subsystem. > > */ > > arm_physmem_hardware_region(SDRAM_START, memsize); > > + arm_physmem_exclude_region(freemem_pt, KERNPHYSADDR - > > + freemem_pt, EXFLAG_NOALLOC); > > + arm_physmem_exclude_region(freemempos, KERNPHYSADDR - 0x100000 - > > + freemempos, EXFLAG_NOALLOC); > > arm_physmem_exclude_region(abp->abp_physaddr, > > virtual_avail - KERNVIRTADDR, EXFLAG_NOALLOC); > > arm_physmem_init_kernel_globals(); > > > > Modified: head/sys/arm/xscale/i8134x/crb_machdep.c > > ============================================================================== > > --- head/sys/arm/xscale/i8134x/crb_machdep.c Thu May 29 16:54:15 2014 (r266849) > > +++ head/sys/arm/xscale/i8134x/crb_machdep.c Thu May 29 16:56:39 2014 (r266850) > > @@ -323,6 +323,10 @@ initarm(struct arm_boot_params *abp) > > * Prepare the list of physical memory available to the vm subsystem. > > */ > > arm_physmem_hardware_region(SDRAM_START, memsize); > > + arm_physmem_exclude_region(freemem_pt, KERNPHYSADDR - > > + freemem_pt, EXFLAG_NOALLOC); > > + arm_physmem_exclude_region(freemempos, KERNPHYSADDR - 0x100000 - > > + freemempos, EXFLAG_NOALLOC); > > arm_physmem_exclude_region(abp->abp_physaddr, > > virtual_avail - KERNVIRTADDR, EXFLAG_NOALLOC); > > arm_physmem_init_kernel_globals(); > > > > Modified: head/sys/arm/xscale/ixp425/avila_machdep.c > > ============================================================================== > > --- head/sys/arm/xscale/ixp425/avila_machdep.c Thu May 29 16:54:15 2014 (r266849) > > +++ head/sys/arm/xscale/ixp425/avila_machdep.c Thu May 29 16:56:39 2014 (r266850) > > @@ -413,6 +413,10 @@ initarm(struct arm_boot_params *abp) > > * Prepare the list of physical memory available to the vm subsystem. > > */ > > arm_physmem_hardware_region(PHYSADDR, memsize); > > + arm_physmem_exclude_region(freemem_pt, KERNPHYSADDR - > > + freemem_pt, EXFLAG_NOALLOC); > > + arm_physmem_exclude_region(freemempos, KERNPHYSADDR - 0x100000 - > > + freemempos, EXFLAG_NOALLOC); > > arm_physmem_exclude_region(abp->abp_physaddr, > > virtual_avail - KERNVIRTADDR, EXFLAG_NOALLOC); > > arm_physmem_init_kernel_globals(); > > > > Modified: head/sys/arm/xscale/pxa/pxa_machdep.c > > ============================================================================== > > --- head/sys/arm/xscale/pxa/pxa_machdep.c Thu May 29 16:54:15 2014 (r266849) > > +++ head/sys/arm/xscale/pxa/pxa_machdep.c Thu May 29 16:56:39 2014 (r266850) > > @@ -335,6 +335,10 @@ initarm(struct arm_boot_params *abp) > > if (memsize[j] > 0) > > arm_physmem_hardware_region(memstart[j], memsize[j]); > > } > > + arm_physmem_exclude_region(freemem_pt, KERNPHYSADDR - > > + freemem_pt, EXFLAG_NOALLOC); > > + arm_physmem_exclude_region(freemempos, KERNPHYSADDR - 0x100000 - > > + freemempos, EXFLAG_NOALLOC); > > arm_physmem_exclude_region(abp->abp_physaddr, > > virtual_avail - KERNVIRTADDR, EXFLAG_NOALLOC); > > arm_physmem_init_kernel_globals(); > > From owner-freebsd-arm@FreeBSD.ORG Thu May 29 17:19:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC96DC62 for ; Thu, 29 May 2014 17:19:19 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DBAD206A for ; Thu, 29 May 2014 17:19:19 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id z60so1868838qgd.4 for ; Thu, 29 May 2014 10:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vXZDNbmw2niCJFaSrby6F0C+r+BDra/4TmKN+GNpzhQ=; b=0Zu9/bK2c/eFZk7fNT/7j+2UTGXRxEogVQ6uhwVvYvsqI+uqdHERpf+XyU140wOo4f tdxDMHSONwNsOQbkUFRuHkrKa5etoRXl+g6fKlPMCVXUWrQa8w9D/rpqSqNwLsp0HJzU 31oZXfIJc7ekCuCKB6GqPBRVxbQyJ3OnAyQk04GRXlD+fg0QqfajK3OvBzNLHNdQuW4A HwN7/ZKnrw5AbNF01Z064g8bXqjSSxigDH8RBc5bcsSLa9wXqGbpo+IyYXnR2zneOGgF kNJOCJ/gEdvzNqtDjw3mGftKfn0anCFkI4PZg2/wf0GRPXuZBWIOTkPnqO28X9hbGtGJ y8Jg== MIME-Version: 1.0 X-Received: by 10.224.43.148 with SMTP id w20mr12624761qae.26.1401383958775; Thu, 29 May 2014 10:19:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Thu, 29 May 2014 10:19:18 -0700 (PDT) In-Reply-To: <20140529171641.GA5246@ci0.org> References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> Date: Thu, 29 May 2014 10:19:18 -0700 X-Google-Sender-Auth: lAitJ2G1mIelRfy6N0atgnwuR6s Message-ID: Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa From: Adrian Chadd To: Olivier Houchard Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:19:19 -0000 On 29 May 2014 10:16, Olivier Houchard wrote: > On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: >> Have you tested this on xscale hardware? > > > Yeah, my two last commits were an attempt to get the AVILA kernel to boot > again. Woo! What can I provide to help you do this? :-) (Drinks? Food? Donations?) -a From owner-freebsd-arm@FreeBSD.ORG Thu May 29 17:28:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4CAD1F1; Thu, 29 May 2014 17:28:18 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB021212B; Thu, 29 May 2014 17:28:18 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4THS7D4046657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 10:28:07 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4THS7XQ046656; Thu, 29 May 2014 10:28:07 -0700 (PDT) (envelope-from jmg) Date: Thu, 29 May 2014 10:28:07 -0700 From: John-Mark Gurney To: Adrian Chadd Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140529172807.GX43976@funkthat.com> Mail-Followup-To: Adrian Chadd , Olivier Houchard , "freebsd-arm@freebsd.org" References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 29 May 2014 10:28:08 -0700 (PDT) Cc: "freebsd-arm@freebsd.org" , Olivier Houchard X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:28:18 -0000 Adrian Chadd wrote this message on Thu, May 29, 2014 at 10:19 -0700: > On 29 May 2014 10:16, Olivier Houchard wrote: > > On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > >> Have you tested this on xscale hardware? > > > > > > Yeah, my two last commits were an attempt to get the AVILA kernel to boot > > again. > > Woo! What can I provide to help you do this? :-) > > (Drinks? Food? Donations?) Yeh, me too! I have a board I can test with... Does this fix the page is wired panic? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu May 29 17:38:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30308407; Thu, 29 May 2014 17:38:15 +0000 (UTC) Received: from kanar.ci0.org (kanar.ci0.org [IPv6:2001:bc8:35e6::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C36302209; Thu, 29 May 2014 17:38:14 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.8/8.14.8) with ESMTP id s4THc3X0005389; Thu, 29 May 2014 19:38:03 +0200 (CEST) (envelope-from doginou@kanar.ci0.org) Received: (from doginou@localhost) by kanar.ci0.org (8.14.8/8.14.8/Submit) id s4THc3ah005388; Thu, 29 May 2014 19:38:03 +0200 (CEST) (envelope-from doginou) Date: Thu, 29 May 2014 19:38:03 +0200 From: Olivier Houchard To: Adrian Chadd Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140529173803.GA5294@ci0.org> References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:38:15 -0000 On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: > On 29 May 2014 10:16, Olivier Houchard wrote: > > On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > >> Have you tested this on xscale hardware? > > > > > > Yeah, my two last commits were an attempt to get the AVILA kernel to boot > > again. > > Woo! What can I provide to help you do this? :-) > > (Drinks? Food? Donations?) > > Drinks and food are always appreciated ;) It almost boots for me now, except a few userland programs gets SIGSEGV or SIGILL along the way, trying to figure out why. Olivier From owner-freebsd-arm@FreeBSD.ORG Fri May 30 06:32:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB8A9973; Fri, 30 May 2014 06:32:35 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 84438245E; Fri, 30 May 2014 06:32:35 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4U6WSf3057079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 23:32:29 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4U6WS4K057078; Thu, 29 May 2014 23:32:28 -0700 (PDT) (envelope-from jmg) Date: Thu, 29 May 2014 23:32:28 -0700 From: John-Mark Gurney To: Olivier Houchard Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140530063228.GD43976@funkthat.com> Mail-Followup-To: Olivier Houchard , Adrian Chadd , "freebsd-arm@freebsd.org" , alc@FreeBSD.org, kib@FreeBSD.org References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> <20140529173803.GA5294@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140529173803.GA5294@ci0.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 29 May 2014 23:32:29 -0700 (PDT) Cc: alc@freebsd.org, kib@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 06:32:35 -0000 Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: > On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: > > On 29 May 2014 10:16, Olivier Houchard wrote: > > > On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > > >> Have you tested this on xscale hardware? > > > > > > > > > Yeah, my two last commits were an attempt to get the AVILA kernel to boot > > > again. > > > > Woo! What can I provide to help you do this? :-) > > > > (Drinks? Food? Donations?) > > > > > > Drinks and food are always appreciated ;) > It almost boots for me now, except a few userland programs gets SIGSEGV or > SIGILL along the way, trying to figure out why. Thanks for fixing ddb... I'm getting panic messages again... bad news is that my panic is still around: panic: vm_page_alloc: page 0xc07e73b0 is wired Though, interestingly, it looks like sparc64 has a similar panic: https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 kib, Alan, any clue to why this is happening? Any suggestions as to help track it down? Lastest dump of the vm_page from a tree from today is: {'act_count': '\x00', 'aflags': '\x00', 'busy_lock': 1, 'dirty': '\xff', 'flags': 0, 'hold_count': 0, 'listq': {'tqe_next': 0xc07e7400, 'tqe_prev': 0xc06e63a0}, 'md': {'pv_kva': 3235893248, 'pv_list': {'tqh_first': 0x0, 'tqh_last': 0xc07e73e0}, 'pv_memattr': '\x00', 'pvh_attrs': 0}, 'object': 0xc06e6378, 'oflags': '\x04', 'order': '\t', 'phys_addr': 9424896, 'pindex': 3581, 'plinks': {'memguard': {'p': 0, 'v': 3228461644}, 'q': {'tqe_next': 0x0, 'tqe_prev': 0xc06e6a4c}, 's': {'pv': 0xc06e6a4c, 'ss': {'sle_next': 0x0}}}, 'pool': '\x00', 'queue': '\xff', 'segind': '\x02', 'valid': '\xff', 'wire_count': 1} This appears to be on the kmem_object list as: c06e62d8 B kernel_object_store c06e6378 B kmem_object_store c06e6418 b old_msync and you can see the tqh_last would be part of kmem_object_store... Could this be something bad happening w/ when memory is low? The board I'm testing on has only 64MB (54MB avail), so it hits that pretty quickly... Thanks for any help you can provide. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Fri May 30 07:21:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D485A3D3 for ; Fri, 30 May 2014 07:21:01 +0000 (UTC) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9589C27E4 for ; Fri, 30 May 2014 07:21:01 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id jz11so1650088veb.7 for ; Fri, 30 May 2014 00:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=izRYl6ej/l4iNHkLC2ixVIM7XmwEYVUlRNGZVTNiLto=; b=sobfsYA4YeHTuhQqbHfJZolRUynx9Dom+zWravrc/xqvE3l30jRWs5HEDUtDAqxX8t TB9OkKQAf9gehSfWoshKijUS8+c0p6q4B/Y/W3QkqakwDUUVrpQRIMQhbvIRFiPQ0U8a 7RpnpCJy7uLl590dFKAwzwS4TZeI6dmbioB/1E3yOc5S/3GJMMsgQOzVlHLbQxzlB3HY 2pR1m0v5fcawYGEAs8Cf34Xh6OWQfGkdlm3U6jfu7vI4PMz7j9JohNSq2t3K/+CHd97t X8WqMz2TKN9oe/JyFRdIE6oL8B2FQNgzC/5573HdaLYGJYVVNZ7jAA7kxXpKah0EEYEp /3mQ== X-Received: by 10.52.255.65 with SMTP id ao1mr10012067vdd.43.1401434460585; Fri, 30 May 2014 00:21:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.238.169 with HTTP; Fri, 30 May 2014 00:20:30 -0700 (PDT) In-Reply-To: <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> References: <53850478.3080302@wp.pl> <53854768.1020904@hot.ee> <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> From: Matthias Gamsjager Date: Fri, 30 May 2014 09:20:30 +0200 Message-ID: Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 07:21:01 -0000 I know this is the freebsd list but why not use things like OpenElec? From owner-freebsd-arm@FreeBSD.ORG Fri May 30 11:16:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B235EAB2 for ; Fri, 30 May 2014 11:16:32 +0000 (UTC) Received: from wp376.webpack.hosteurope.de (wp376.webpack.hosteurope.de [IPv6:2a01:488:42::50ed:8591]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 722692A63 for ; Fri, 30 May 2014 11:16:31 +0000 (UTC) Received: from xdsl-78-34-186-231.netcologne.de ([78.34.186.231] helo=dijkstra-old.hb22.cruwe.de); authenticated by wp376.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1WqKnR-000106-5W; Fri, 30 May 2014 13:16:28 +0200 Date: Fri, 30 May 2014 13:16:19 +0200 From: "Christopher J. Ruwe" To: freebsd-arm@freebsd.org Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? Message-ID: <20140530131619.1450b2fc@dijkstra-old.hb22.cruwe.de> In-Reply-To: <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> References: <53850478.3080302@wp.pl> <53854768.1020904@hot.ee> <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;cjr@cruwe.de;1401448592;da60ee10; X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 11:16:32 -0000 On Thu, 29 May 2014 01:03:04 +0000 "Scott, Brian" wrote: > -----Original Message----- > From: owner-freebsd-arm@freebsd.org > [mailto:owner-freebsd-arm@freebsd.org] On Behalf Of Sulev-Madis > Silber (ketas) Sent: Wednesday, 28 May 2014 12:18 PM To: Marek > Salwerowicz Cc: freebsd-arm@freebsd.org > Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? > > >On 2014-05-28 00:32, Marek Salwerowicz wrote: > >> Hi list, > >> > >> I was wondering if anyone has succeeded in installing the X Server, > >> simple window manager and XBMC software under FreeBSD? > >> > >> I would like to use my RPi as XBMC media player. > > > >Should be possible. I've heard that X works there, but I haven't > >tried it by myself. > > Has anyone actually got X running recently? I've just been trying to > build a few packages on the Pi and it looks like things have moved on > since the various tutorials on the web were written. The scfb video > driver is included in ports now but other broken-ness in xorg-server > (dri) stops it being built. > > Haven't even started trying to get applications like XBMC going. > > Brian > ********************************************************************** > This message is intended for the addressee named and may contain > privileged information or confidential information or both. If you > are not the intended recipient please delete it and notify the sender. > ********************************************************************** > _______________________________________________ > 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" > My experiences with the RPi are that bad that I consider the setup as unusable: - ports do not compile (PostgreSQL) - ports compile but coredump (mit-krb5) - machine crashes frequently The only instance runnuing so far is an RPi setup for bind99 and isc-dhcpd. I cannot assert that the RPi is at fault, could be the SD-Card. I have given up, though, $ENOTIME. Cheers, -- Christopher TZ: GMT + 1h GnuPG/GPG: 0xE8DE2C14 FreeBSD 10.0-STABLE #5 r265586+b9bac26(stable/10): Sat May 10 20:45:36 CEST 2014 cjr@dijkstra-old.hb22.cruwe.de:/usr/obj/usr/src/sys/GENERIC Punctuation matters: "Lets eat Grandma or Lets eat, Grandma" - Punctuation saves lives. "A panda eats shoots and leaves" or "A panda eats, shoots, and leaves" - Punctuation teaches proper biology. "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." (RFC 1925) From owner-freebsd-arm@FreeBSD.ORG Fri May 30 12:48:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C7F8430 for ; Fri, 30 May 2014 12:48:06 +0000 (UTC) Received: from mail.agsec.de (mail.kts.org [IPv6:2a00:14b0:f000:1::222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 255722317 for ; Fri, 30 May 2014 12:48:05 +0000 (UTC) Received: from hh01.agsec.de (localhost [127.0.0.1]) by mail.agsec.de (Postfix) with ESMTP id 37624892A7 for ; Fri, 30 May 2014 14:47:53 +0200 (CEST) X-Virus-Scanned-AGSEC: MailMurkxDeScraCxler at agsec.de Received: from mail.agsec.de ([194.55.156.222]) by hh01.agsec.de (hh01.agsec.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX5DdoJ0hmbT for ; Fri, 30 May 2014 14:47:50 +0200 (CEST) Received: from ernie.int.kts.org (ernie.xnet.kts.org [IPv6:2001:6f8:1c56:200::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.agsec.de (Postfix) with ESMTPS id 4754789284 for ; Fri, 30 May 2014 14:47:50 +0200 (CEST) X-Virus-Scanned-KTS: Mail-UnWroks-U-Laksler at KTS.ORG Received: from frazzle.int.kts.org (frazzle.int.kts.org [172.31.42.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ernie.int.kts.org (Postfix) with ESMTPSA id C1A3ED4C74 for ; Fri, 30 May 2014 14:47:32 +0200 (CEST) From: Hellmuth Michaelis Content-Type: multipart/signed; boundary="Apple-Mail=_DCA1561F-F3B4-4C6A-B2A5-81A5410D3C57"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <6585F7BE-4398-4062-A8F8-184BC049A6C2@hellmuth-michaelis.de> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? Date: Fri, 30 May 2014 14:46:58 +0200 References: <53850478.3080302@wp.pl> <53854768.1020904@hot.ee> <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> <20140530131619.1450b2fc@dijkstra-old.hb22.cruwe.de> To: freebsd-arm@freebsd.org In-Reply-To: <20140530131619.1450b2fc@dijkstra-old.hb22.cruwe.de> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 12:48:06 -0000 --Apple-Mail=_DCA1561F-F3B4-4C6A-B2A5-81A5410D3C57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Am 30.05.2014 um 13:16 schrieb Christopher J. Ruwe : > On Thu, 29 May 2014 01:03:04 +0000 > "Scott, Brian" wrote: >=20 >> -----Original Message----- >> From: owner-freebsd-arm@freebsd.org >> [mailto:owner-freebsd-arm@freebsd.org] On Behalf Of Sulev-Madis >> Silber (ketas) Sent: Wednesday, 28 May 2014 12:18 PM To: Marek >> Salwerowicz Cc: freebsd-arm@freebsd.org >> Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? >>=20 >>> On 2014-05-28 00:32, Marek Salwerowicz wrote: >>>> Hi list, >>>>=20 >>>> I was wondering if anyone has succeeded in installing the X Server, >>>> simple window manager and XBMC software under FreeBSD? >>>>=20 >>>> I would like to use my RPi as XBMC media player. >>>=20 >>> Should be possible. I've heard that X works there, but I haven't >>> tried it by myself.=20 >>=20 >> Has anyone actually got X running recently? I've just been trying to >> build a few packages on the Pi and it looks like things have moved on >> since the various tutorials on the web were written. The scfb video >> driver is included in ports now but other broken-ness in xorg-server >> (dri) stops it being built. >>=20 >> Haven't even started trying to get applications like XBMC going. >>=20 >> Brian >> = ********************************************************************** >> This message is intended for the addressee named and may contain >> privileged information or confidential information or both. If you >> are not the intended recipient please delete it and notify the = sender. >> = ********************************************************************** >> _______________________________________________ >> 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 >=20 > My experiences with the RPi are that bad that I consider the setup as > unusable: >=20 > - ports do not compile (PostgreSQL) > - ports compile but coredump (mit-krb5) > - machine crashes frequently >=20 > The only instance runnuing so far is an RPi setup for bind99 and > isc-dhcpd. I cannot assert that the RPi is at fault, could be the > SD-Card. >=20 > I have given up, though, $ENOTIME. >=20 > Cheers, > --=20 > Christopher > TZ: GMT + 1h > GnuPG/GPG: 0xE8DE2C14 >=20 > FreeBSD 10.0-STABLE #5 r265586+b9bac26(stable/10): Sat May 10 20:45:36 > CEST 2014 cjr@dijkstra-old.hb22.cruwe.de:/usr/obj/usr/src/sys/GENERIC=20= >=20 > Punctuation matters: > "Lets eat Grandma or Lets eat, Grandma" - Punctuation saves lives. > "A panda eats shoots and leaves" or "A panda eats, shoots, and leaves" = - > Punctuation teaches proper biology. >=20 > "With sufficient thrust, pigs fly just fine. However, this is not > necessarily a good idea. It is hard to be sure where they are going to > land, and it could be dangerous sitting under them as they fly > overhead." (RFC 1925) > _______________________________________________ > 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=93= Just a datapoint, i cannot quite confirm this, i have a rpi running: FreeBSD pisix.xx.yy.zz 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r259179M: = Mon Dec 30 12:55:26 CET 2013 = root@vfbcur.xx.yy.zz:/usr/obj-rpi/arm.armv6/usr/src/sys/RPI-B-CUST arm as a router to sixxs. uptime says: 2:37PM up 71 days, 2:27, 1 user, load averages: 0.02, 0.06, 0.07 I had to apply the USB DMA patches to get acceptable network performance = and - you are right - some ports don=92t compile (i.e. pftop) or crash = (don=92t remeber which one it was) but all in all it runs now for half a = year without noticable problems. Hellmuth --=20 Hellmuth Michaelis Hallstra=DFe 20 25462 Rellingen Mobil: +49-160-9645 5696 Telefon: +49-4101-85299-20 Telefax: +49-4101-85299-21 web: www.hellmuth-michaelis.de mail: hm@hellmuth-michaelis.de --Apple-Mail=_DCA1561F-F3B4-4C6A-B2A5-81A5410D3C57 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTiH3DAAoJEDc16e0fOQ8BEW4IAJ7AuDcl2YFJRhK4eIer3DIx xnd3PTkYHAa2MH/DQvOoxvxGJm1z+6WjryEVJECZDc5WKKAsRR/XwfXj8vxiSVwq YuOHzmGOClp+eM0FK+w32aP/hiKNaHmZeK4+OBal5v8RwZS83T0YBxKb/IIkqjCn vDXm2vIErRB/sxeZ9h4rPDijIRphhRTXoiph0jbM/bdtJv/nYXJni09k39fnSMPx 3fS35fCJaMWP8U9D+G8bHr1tAdmC98YB4vJwFZXWEAfHGHb2RkgUe+wDBJR+SJWa 6TMsKLTjknXe1PoDUSDQr9vTPhjOB6QOhHmzedm31yYrrilHo2bAmJiHK/J/6+E= =Z/SR -----END PGP SIGNATURE----- --Apple-Mail=_DCA1561F-F3B4-4C6A-B2A5-81A5410D3C57-- From owner-freebsd-arm@FreeBSD.ORG Fri May 30 13:01:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6779272F for ; Fri, 30 May 2014 13:01:53 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2488F2462 for ; Fri, 30 May 2014 13:01:52 +0000 (UTC) Received: from laptop015.home.selasky.org (c124.sec.cl.cam.ac.uk [128.232.18.124]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F2A551FE026; Fri, 30 May 2014 15:01:50 +0200 (CEST) Message-ID: <53888166.2080407@selasky.org> Date: Fri, 30 May 2014 15:02:30 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Hellmuth Michaelis , freebsd-arm@freebsd.org Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? References: <53850478.3080302@wp.pl> <53854768.1020904@hot.ee> <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> <20140530131619.1450b2fc@dijkstra-old.hb22.cruwe.de> <6585F7BE-4398-4062-A8F8-184BC049A6C2@hellmuth-michaelis.de> In-Reply-To: <6585F7BE-4398-4062-A8F8-184BC049A6C2@hellmuth-michaelis.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:01:53 -0000 Hi, The DMA patches might have to be redone to work with my recent code changes ... > > I had to apply the USB DMA patches to get acceptable network performance and - you are right - some ports dont compile (i.e. pftop) or crash (dont remeber which one it was) but all in all it runs now for half a year without noticable problems. > > Hellmuth > --HPS From owner-freebsd-arm@FreeBSD.ORG Fri May 30 16:37:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 256E95A4; Fri, 30 May 2014 16:37:55 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8EA42839; Fri, 30 May 2014 16:37:53 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s4UFvG3x007695; Fri, 30 May 2014 11:04:02 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 1m6977rg44-1; Fri, 30 May 2014 11:04:02 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 048C2500122; Fri, 30 May 2014 11:04:01 -0500 (CDT) Message-ID: <5388ABF1.3030200@rice.edu> Date: Fri, 30 May 2014 11:04:01 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Olivier Houchard , Adrian Chadd , "freebsd-arm@freebsd.org" , alc@FreeBSD.org, kib@FreeBSD.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com> In-Reply-To: <20140530063228.GD43976@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=10 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405300201 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:37:55 -0000 On 05/30/2014 01:32, John-Mark Gurney wrote: > Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: >> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: >>> On 29 May 2014 10:16, Olivier Houchard wrote: >>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: >>>>> Have you tested this on xscale hardware? >>>> >>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot >>>> again. >>> Woo! What can I provide to help you do this? :-) >>> >>> (Drinks? Food? Donations?) >>> >>> >> Drinks and food are always appreciated ;) >> It almost boots for me now, except a few userland programs gets SIGSEGV or >> SIGILL along the way, trying to figure out why. > Thanks for fixing ddb... I'm getting panic messages again... bad > news is that my panic is still around: > panic: vm_page_alloc: page 0xc07e73b0 is wired > > Though, interestingly, it looks like sparc64 has a similar panic: > https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 > > kib, Alan, any clue to why this is happening? Any suggestions as to > help track it down? I'm afraid not. The dump below shows a perfectly normal, in-use page. If this page had actually been free prior to the vm_page_alloc() call, then other fields, like dirty, would have been different. In other words, this isn't just a problem with the wire count. What object is vm_page_alloc() being performed on? > Lastest dump of the vm_page from a tree from today is: > {'act_count': '\x00', > 'aflags': '\x00', > 'busy_lock': 1, > 'dirty': '\xff', > 'flags': 0, > 'hold_count': 0, > 'listq': {'tqe_next': 0xc07e7400, 'tqe_prev': 0xc06e63a0}, > 'md': {'pv_kva': 3235893248, > 'pv_list': {'tqh_first': 0x0, 'tqh_last': 0xc07e73e0}, > 'pv_memattr': '\x00', > 'pvh_attrs': 0}, > 'object': 0xc06e6378, > 'oflags': '\x04', > 'order': '\t', > 'phys_addr': 9424896, > 'pindex': 3581, > 'plinks': {'memguard': {'p': 0, 'v': 3228461644}, > 'q': {'tqe_next': 0x0, 'tqe_prev': 0xc06e6a4c}, > 's': {'pv': 0xc06e6a4c, 'ss': {'sle_next': 0x0}}}, > 'pool': '\x00', > 'queue': '\xff', > 'segind': '\x02', > 'valid': '\xff', > 'wire_count': 1} > > This appears to be on the kmem_object list as: > c06e62d8 B kernel_object_store > c06e6378 B kmem_object_store > c06e6418 b old_msync > > and you can see the tqh_last would be part of kmem_object_store... > > Could this be something bad happening w/ when memory is low? The > board I'm testing on has only 64MB (54MB avail), so it hits that > pretty quickly... > > Thanks for any help you can provide. > From owner-freebsd-arm@FreeBSD.ORG Sat May 31 00:53:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CF278C8 for ; Sat, 31 May 2014 00:53:57 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 542F92197 for ; Sat, 31 May 2014 00:53:57 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s4V0rmjc003907; Fri, 30 May 2014 20:53:54 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5389281C.1070508@m5p.com> Date: Fri, 30 May 2014 20:53:48 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? References: <53850478.3080302@wp.pl> <53854768.1020904@hot.ee> <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> <20140530131619.1450b2fc@dijkstra-old.hb22.cruwe.de> <6585F7BE-4398-4062-A8F8-184BC049A6C2@hellmuth-michaelis.de> <53888166.2080407@selasky.org> In-Reply-To: <53888166.2080407@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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]); Fri, 30 May 2014 20:53:54 -0400 (EDT) Cc: Hellmuth Michaelis X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 00:53:57 -0000 On 05/30/14 09:02, Hans Petter Selasky wrote: > Hi, > > The DMA patches might have to be redone to work with my recent code > changes ... > >> >> I had to apply the USB DMA patches to get acceptable network >> performance and - you are right - some ports dont compile (i.e. >> pftop) or crash (dont remeber which one it was) but all in all it >> runs now for half a year without noticable problems. >> >> Hellmuth >> > > --HPS > It was back in January 2013 when I bought a Pi, downloaded a prebuilt image, compiled print/cups-base, and started using it as a print server. Unfortunately, a bug (which Mr Selasky fixed for me) kept it from talking to my Lexmark printer (though my HP printer worked with no problem). It was a long time before I was able to build a custom image, by which time we had EABI, clang, etc.; and to this day I still haven't been able to build a working print server. -- George From owner-freebsd-arm@FreeBSD.ORG Sat May 31 01:00:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40E9A1E4 for ; Sat, 31 May 2014 01:00:29 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A99A321C9 for ; Sat, 31 May 2014 01:00:27 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s4V0hF9r011639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 31 May 2014 02:43:15 +0200 (CEST) (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 s4V0h7xH054141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 02:43:07 +0200 (CEST) (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 s4V0h6fm047661; Sat, 31 May 2014 02:43:06 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s4V0h6Cb047660; Sat, 31 May 2014 02:43:06 +0200 (CEST) (envelope-from ticso) Date: Sat, 31 May 2014 02:43:06 +0200 From: Bernd Walter To: freebsd-arm@freebsd.org Subject: TRIM on SD cards Message-ID: <20140531004306.GI26883@cicely7.cicely.de> Reply-To: ticso@cicely.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Bernd Walter X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 01:00:29 -0000 It seems SD cards support a delete command, which FreeBSD supports with the mmcsd driver. newfs and tunefs support TRIM in that new filesystems are trim'ed and the filesystems automatically trim free'ed blocks. So far so good. On the practical side with SD based ARM you don't write filesystems directly via mmcsd. We either create an image, which id dd'ed onto SD or in some cases we use an USB SD drive. With dd the unused blocks are written as well, which effectively hurts by writing data. Is there some kind of dd, which actually don't write zero blocks, or even better does a trim call for them? Is there a tool to trim a filesystem after creation? Ok - even then there is the option to directly newfs on the SD card. But in any case I need to be able to issue trim requests to the card. It seems there is support in our da driver, but will it be transported to the USB reader and even if - how can I find out if my reader actually supports trim commands? A newfs -t -E with my older transcend multireader and a new class10 Intenso micro-SD issues no error. But is it save to assume the card actually got trim'ed? Trim is enabled on the filesystem, but not shown in mount list: [189]gw1# tunefs -t enable /dev/da0 tunefs: issue TRIM to the disk remains unchanged as enabled [190]gw1# mount /dev/da0 /mnt [191]gw1# mount | grep mnt /dev/da0 on /mnt (ufs, local, soft-updates) FreeBSD gw1.cicely.de 10.0-STABLE FreeBSD 10.0-STABLE #0: Thu Apr 17 11:47:45 CEST 2014 ticso@gw1.cicely.de:/usr/obj/home/builder/gw1/10/sys/GW1 i386 -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat May 31 03:00:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B0041D1 for ; Sat, 31 May 2014 03:00:14 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2AA72953 for ; Sat, 31 May 2014 03:00:13 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WqZWm-000ENu-MC; Sat, 31 May 2014 03:00:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4V30ADk004121; Fri, 30 May 2014 21:00:10 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/go3Zsk7HyJ+3nngtDswvU Subject: Re: TRIM on SD cards From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20140531004306.GI26883@cicely7.cicely.de> References: <20140531004306.GI26883@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 May 2014 21:00:09 -0600 Message-ID: <1401505209.20883.34.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, Bernd Walter X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 03:00:14 -0000 On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: > It seems SD cards support a delete command, which FreeBSD supports > with the mmcsd driver. > newfs and tunefs support TRIM in that new filesystems are trim'ed > and the filesystems automatically trim free'ed blocks. > So far so good. > On the practical side with SD based ARM you don't write filesystems > directly via mmcsd. > We either create an image, which id dd'ed onto SD or in some cases > we use an USB SD drive. > With dd the unused blocks are written as well, which effectively > hurts by writing data. > Is there some kind of dd, which actually don't write zero blocks, > or even better does a trim call for them? I don't think dd can safely do that. If it finds a block of zeroes on the input side, how does it know it's okay to do a DELETE for those (which sets the block to all-bits-on on most flash media). Maybe it's important for that data to really be zero; dd doesn't know. That's one of the reasons why I recently mentioned a desire for a /dev/ones to go with /dev/zero as a way of pre-init'ing an image to be more friendly to flash media. The idea was not well-received by other freebsd folks. Maybe if the image was sparse, dd could tell the difference between an missing segment and a segment populated with zeroes and do a DELETE for missing data. I never do the image creation thing, I mostly tend to use nfsroot and at $work we use tar to copy files to sdcards with a usb burner rather than preformatting images into files. -- Ian > Is there a tool to trim a filesystem after creation? > Ok - even then there is the option to directly newfs on the SD card. > But in any case I need to be able to issue trim requests to the card. > It seems there is support in our da driver, but will it be transported > to the USB reader and even if - how can I find out if my reader actually > supports trim commands? > A newfs -t -E with my older transcend multireader and a new class10 > Intenso micro-SD issues no error. > But is it save to assume the card actually got trim'ed? > > Trim is enabled on the filesystem, but not shown in mount list: > [189]gw1# tunefs -t enable /dev/da0 > tunefs: issue TRIM to the disk remains unchanged as enabled > [190]gw1# mount /dev/da0 /mnt > [191]gw1# mount | grep mnt > /dev/da0 on /mnt (ufs, local, soft-updates) > FreeBSD gw1.cicely.de 10.0-STABLE FreeBSD 10.0-STABLE #0: Thu Apr 17 11:47:45 CEST 2014 ticso@gw1.cicely.de:/usr/obj/home/builder/gw1/10/sys/GW1 i386 > From owner-freebsd-arm@FreeBSD.ORG Sat May 31 03:21:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 332C85A3; Sat, 31 May 2014 03:21:56 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D91782C0F; Sat, 31 May 2014 03:21:55 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id f51so7551045qge.26 for ; Fri, 30 May 2014 20:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6CmQjsdbiU2AQxRa7LJGMizxM5IGmjg9iemt6LuJccI=; b=oEB8k54x/Pq2i7hWh3gfso03fMRLov0W8c9NZsYn5YJRqonchth24SgTr8whdxKkod eREbr73b1CEn9rg/emgtnubBTA9kMtynEq10e6H8z2qwhdkhp2/hBQGdUj7ag/7TQsNS vOuoj0pH1c79VmF6yIxrXBxsJm/D9c1JHTrhDmMHU5sbXnFjz/YiZY+fmavg4HG+koAx kmQFXwNai/q2IsVIAAbu8gUSVZG43pceyR1+xSjN7L9rHhkpllwXjy87nPFtysknXp8g k/OnUkoEsNA0KE40vRZL8HAdNFE+0T9QXbeTjsXgLQ3BHCsagHo/KPskdEhQUMB6Ilnk zcvA== MIME-Version: 1.0 X-Received: by 10.224.16.199 with SMTP id p7mr27545819qaa.76.1401506514733; Fri, 30 May 2014 20:21:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Fri, 30 May 2014 20:21:54 -0700 (PDT) In-Reply-To: <1401505209.20883.34.camel@revolution.hippie.lan> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> Date: Fri, 30 May 2014 20:21:54 -0700 X-Google-Sender-Auth: _H1hz2JpelfhH9qKf8H0pJHtZ8M Message-ID: Subject: Re: TRIM on SD cards From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 03:21:56 -0000 On 30 May 2014 20:00, Ian Lepore wrote: > On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: >> It seems SD cards support a delete command, which FreeBSD supports >> with the mmcsd driver. >> newfs and tunefs support TRIM in that new filesystems are trim'ed >> and the filesystems automatically trim free'ed blocks. >> So far so good. >> On the practical side with SD based ARM you don't write filesystems >> directly via mmcsd. >> We either create an image, which id dd'ed onto SD or in some cases >> we use an USB SD drive. >> With dd the unused blocks are written as well, which effectively >> hurts by writing data. >> Is there some kind of dd, which actually don't write zero blocks, >> or even better does a trim call for them? > > I don't think dd can safely do that. If it finds a block of zeroes on > the input side, how does it know it's okay to do a DELETE for those > (which sets the block to all-bits-on on most flash media). Maybe it's > important for that data to really be zero; dd doesn't know. > > That's one of the reasons why I recently mentioned a desire for > a /dev/ones to go with /dev/zero as a way of pre-init'ing an image to be > more friendly to flash media. The idea was not well-received by other > freebsd folks. > > Maybe if the image was sparse, dd could tell the difference between an > missing segment and a segment populated with zeroes and do a DELETE for > missing data. I never do the image creation thing, I mostly tend to use > nfsroot and at $work we use tar to copy files to sdcards with a usb > burner rather than preformatting images into files. Well, what about writing some TLV style archive format for raw images that included information like that? And then a tool to blat that sparse image TLV thing to some underlying media? That way the dd utility could recover "this could be TRIMed" from regions in the image that are stated to be TRIM-friendly. Double points if it understands things like "hey, before you dd this into this partition, it'd be really cool if you laid down this partition table first." -a From owner-freebsd-arm@FreeBSD.ORG Sat May 31 03:22:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22BAC5DE for ; Sat, 31 May 2014 03:22:03 +0000 (UTC) Received: from up-smx-s1.dmz.det.nsw.edu.au (up-smx-s1.det.nsw.edu.au [153.107.41.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB6C72C12 for ; Sat, 31 May 2014 03:22:01 +0000 (UTC) Received: from slppmxmm02.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-smx-s1.dmz.det.nsw.edu.au (8.14.4/8.14.4) with ESMTP id s4V2n7vm028074; Sat, 31 May 2014 12:49:08 +1000 Received: from SLPEXHT01.central.det.win (Not Verified[153.107.14.60]) by slppmxmm02.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Sat, 31 May 2014 12:49:07 +1000 Received: from WPEXCHHTUG1052.central.det.win (153.107.78.169) by SLPEXHT01.central.det.win (153.107.14.60) with Microsoft SMTP Server (TLS) id 8.3.342.0; Sat, 31 May 2014 12:49:07 +1000 Received: from WPEXCHMBUG1062.central.det.win ([169.254.5.130]) by WPEXCHHTUG1052.central.det.win ([153.107.78.169]) with mapi id 14.03.0174.001; Sat, 31 May 2014 12:49:06 +1000 From: "Scott, Brian" To: George Mitchell Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? Thread-Topic: RPi + FreeBSD + Xorg + XBMC player ? Thread-Index: AQHPe/iUU7brCgjM0E6IlF1NPIOQ/JtYaugAgAAEVwCAAMa8AIAAx9rw Date: Sat, 31 May 2014 02:49:05 +0000 Message-ID: References: <53850478.3080302@wp.pl> <53854768.1020904@hot.ee> <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> <20140530131619.1450b2fc@dijkstra-old.hb22.cruwe.de> <6585F7BE-4398-4062-A8F8-184BC049A6C2@hellmuth-michaelis.de> <53888166.2080407@selasky.org>,<5389281C.1070508@m5p.com> In-Reply-To: <5389281C.1070508@m5p.com> Accept-Language: en-AU, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-route: TAFECORP Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-arm@freebsd.org" , Hellmuth Michaelis X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 03:22:03 -0000 I find myself agreeing with this. In particular, lack of sound support ma= kes it a poor choice for the OP. The lack of packages makes it difficult to do anything non-trivial. Build= ing ports is very slow and requires a high level of technical expertise t= o correct makefiles when things break. Still, if we don't keep tinkering with it, it won't get any better. Brian On 31/05/2014, at 10:54 AM, "George Mitchell" wr= ote: > On 05/30/14 09:02, Hans Petter Selasky wrote: >> Hi, >>=20 >> The DMA patches might have to be redone to work with my recent code >> changes ... >>=20 >>>=20 >>> I had to apply the USB DMA patches to get acceptable network >>> performance and - you are right - some ports don=92t compile (i.e. >>> pftop) or crash (don=92t remeber which one it was) but all in all it >>> runs now for half a year without noticable problems. >>>=20 >>> Hellmuth >>>=20 >>=20 >> --HPS >>=20 > It was back in January 2013 when I bought a Pi, downloaded a prebuilt > image, compiled print/cups-base, and started using it as a print > server. Unfortunately, a bug (which Mr Selasky fixed for me) kept it > from talking to my Lexmark printer (though my HP printer worked with > no problem). It was a long time before I was able to build a custom > image, by which time we had EABI, clang, etc.; and to this day I still > haven't been able to build a working print server. -- George >=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" ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-arm@FreeBSD.ORG Sat May 31 04:00:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31A08AD9 for ; Sat, 31 May 2014 04:00:22 +0000 (UTC) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F381F2E70 for ; Sat, 31 May 2014 04:00:21 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id md12so2393583pbc.1 for ; Fri, 30 May 2014 21:00:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=gzdFM+IocDH2ZOIXjeRFfNouCfcbt2jN4oW+GFw66dc=; b=e02453e1l8BvLksCtLBKMPrznPHMYNILRQq3jlA2vuIxrHwAtNZaq6Y32nWT4AXtBO DTXpReXIaTZhQZ4RUUI8zhospeQU2dVttCmbf9kKP1inMDgrajTUFxdeJITCr0qKADYG cbPl2RISBDEEejM4mjq6eKoHvmQy/Kb1ugdjaOkEcsvRgrGcnUCEV13XhxnCY5AErpdg 33+9x2yltVuUCfbSzS/vXRKELlY/hiKIuBYVR0MFjA6VUqfZ6x4lTZZptRUvfPUPWp7V VKxIBOSJnqQ3f3BdZfyXmZFLjEeVkEOHmowARSWKZXeoBjdXQ47yJ6L3LhYXshNR/M6t QGKw== X-Gm-Message-State: ALoCoQmZl32bP+K2wAkDcJ8LTAltjh5ydKra+3f/2HZizUjJRrNF+9GdHaKX0r/pwiS06D/azUWl X-Received: by 10.68.196.168 with SMTP id in8mr24050771pbc.132.1401508503643; Fri, 30 May 2014 20:55:03 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id iq10sm8907912pbc.14.2014.05.30.20.55.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 20:55:02 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_9C453B3F-2FC5-4690-8559-A26EA57512CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: <1401505209.20883.34.camel@revolution.hippie.lan> Date: Fri, 30 May 2014 21:55:02 -0600 Message-Id: References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@FreeBSD.org, Bernd Walter , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 04:00:22 -0000 --Apple-Mail=_9C453B3F-2FC5-4690-8559-A26EA57512CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 30, 2014, at 9:00 PM, Ian Lepore wrote: > On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: >> It seems SD cards support a delete command, which FreeBSD supports >> with the mmcsd driver. >> newfs and tunefs support TRIM in that new filesystems are trim'ed >> and the filesystems automatically trim free'ed blocks. >> So far so good. >> On the practical side with SD based ARM you don't write filesystems >> directly via mmcsd. >> We either create an image, which id dd'ed onto SD or in some cases >> we use an USB SD drive. >> With dd the unused blocks are written as well, which effectively >> hurts by writing data. >> Is there some kind of dd, which actually don't write zero blocks, >> or even better does a trim call for them? >=20 > I don't think dd can safely do that. If it finds a block of zeroes on > the input side, how does it know it's okay to do a DELETE for those > (which sets the block to all-bits-on on most flash media). Maybe it's > important for that data to really be zero; dd doesn't know. >=20 > That's one of the reasons why I recently mentioned a desire for > a /dev/ones to go with /dev/zero as a way of pre-init'ing an image to = be > more friendly to flash media. The idea was not well-received by other > freebsd folks. >=20 > Maybe if the image was sparse, dd could tell the difference between an > missing segment and a segment populated with zeroes and do a DELETE = for > missing data. I never do the image creation thing, I mostly tend to = use > nfsroot and at $work we use tar to copy files to sdcards with a usb > burner rather than preformatting images into files. Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent = blocks are, by definition, all zeros. The only time there=92s a problem = is when the TRIM doesn=92t really TRIM=85 You don=92t need it to be = sparse at all. Zeros are zeros. Warner > -- Ian >=20 >> Is there a tool to trim a filesystem after creation? >> Ok - even then there is the option to directly newfs on the SD card. >> But in any case I need to be able to issue trim requests to the card. >> It seems there is support in our da driver, but will it be = transported >> to the USB reader and even if - how can I find out if my reader = actually >> supports trim commands? >> A newfs -t -E with my older transcend multireader and a new class10 >> Intenso micro-SD issues no error. >> But is it save to assume the card actually got trim'ed? >>=20 >> Trim is enabled on the filesystem, but not shown in mount list: >> [189]gw1# tunefs -t enable /dev/da0 >> tunefs: issue TRIM to the disk remains unchanged as enabled >> [190]gw1# mount /dev/da0 /mnt >> [191]gw1# mount | grep mnt >> /dev/da0 on /mnt (ufs, local, soft-updates) >> FreeBSD gw1.cicely.de 10.0-STABLE FreeBSD 10.0-STABLE #0: Thu Apr 17 = 11:47:45 CEST 2014 = ticso@gw1.cicely.de:/usr/obj/home/builder/gw1/10/sys/GW1 i386 >>=20 >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --Apple-Mail=_9C453B3F-2FC5-4690-8559-A26EA57512CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTiVKWAAoJEGwc0Sh9sBEA1IcP/jjkqOFlK8eMf9F3Hx3GE5qi cggpcYAJfd3afUV599L55dAhM7aEJSvJRyb9jwb57MtJhpJlmv46kV/fKpfgPwpR DZRfm7G/kBbW6XWHEiKZw3BXLiXgvNRrco4gPpfCINeG/oKXq99ZGdoQ5aXH8Gys zxWtFc72Q5i56NXwIcZH9W2PGA0+ygmv8pxVxjpXl3OIYdC4PyzsLHvmdvCrP/XO PXD6F1p2vEc3NXPdkgbDbHyfZYiLmi3umfkQVYWLsR4WYaA/QA0v+V9Z5/VBHJ5y LTfnhrAcxqUNT8cVJwqEMxsDDk8TnHcmMv6xT5s0CqHY00XZ2dDp4MXdzJPpehgj 59YRn/L+OaNPGoWKLSQu2cmbXU1JgbRhUnLHqUrzgXvJvAQnIrMgnRpMdX88J6sP dyjjiJWaYBR9m64USz1ZVplhbxeLXiebsks91G5AG2iUZC+51fNz9LDbJ1C24qaT JdfdF7VZ/M8QaGtvf4u75P+J6TJjsKje/jp112Sql5beQWRRFLQwiH0e6pj8809w /XoR6EeuRV4Qqd6/LUTxjYvzJRJrQqQn7TOo1h5kbsPFkjQXXu+0fqPK5Ua3nizI C0HSP0WxE/Wb83Bs00WOV3/MVJ8+OCj6f5BtO560UwFH04rsgP2YpqkzH8vZoHtB twDnUZcFnsGQJvaIgWqx =p8J5 -----END PGP SIGNATURE----- --Apple-Mail=_9C453B3F-2FC5-4690-8559-A26EA57512CE-- From owner-freebsd-arm@FreeBSD.ORG Sat May 31 04:42:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C505F231; Sat, 31 May 2014 04:42:05 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 952CD2254; Sat, 31 May 2014 04:42:04 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4V4frb7074554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 21:41:54 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4V4frvP074553; Fri, 30 May 2014 21:41:53 -0700 (PDT) (envelope-from jmg) Date: Fri, 30 May 2014 21:41:53 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: TRIM on SD cards Message-ID: <20140531044152.GK43976@funkthat.com> Mail-Followup-To: Warner Losh , Ian Lepore , freebsd-arm@freebsd.org, Bernd Walter , ticso@cicely.de References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 30 May 2014 21:41:54 -0700 (PDT) Cc: freebsd-arm@freebsd.org, Bernd Walter , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 04:42:05 -0000 Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: > On May 30, 2014, at 9:00 PM, Ian Lepore wrote: > > > On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: > >> It seems SD cards support a delete command, which FreeBSD supports > >> with the mmcsd driver. > >> newfs and tunefs support TRIM in that new filesystems are trim'ed > >> and the filesystems automatically trim free'ed blocks. > >> So far so good. > >> On the practical side with SD based ARM you don't write filesystems > >> directly via mmcsd. > >> We either create an image, which id dd'ed onto SD or in some cases > >> we use an USB SD drive. > >> With dd the unused blocks are written as well, which effectively > >> hurts by writing data. > >> Is there some kind of dd, which actually don't write zero blocks, > >> or even better does a trim call for them? > > > > I don't think dd can safely do that. If it finds a block of zeroes on > > the input side, how does it know it's okay to do a DELETE for those > > (which sets the block to all-bits-on on most flash media). Maybe it's > > important for that data to really be zero; dd doesn't know. > > > > That's one of the reasons why I recently mentioned a desire for > > a /dev/ones to go with /dev/zero as a way of pre-init'ing an image to be > > more friendly to flash media. The idea was not well-received by other > > freebsd folks. > > > > Maybe if the image was sparse, dd could tell the difference between an > > missing segment and a segment populated with zeroes and do a DELETE for > > missing data. I never do the image creation thing, I mostly tend to use > > nfsroot and at $work we use tar to copy files to sdcards with a usb > > burner rather than preformatting images into files. > > Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent blocks are, by definition, all zeros. The only time there?s a problem is when the TRIM doesn?t really TRIM? You don?t need it to be sparse at all. Zeros are zeros. Are you sure? TRIM'd space may or may not have a defined value to return upon read, and what happens if one of those blocks of zeros belongs to a file that needs those zeros to be zero? There are bits that declare if the drive returns zeros or not, so this would only be safe on those drives.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat May 31 05:06:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B6946CA for ; Sat, 31 May 2014 05:06:35 +0000 (UTC) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCB2123D7 for ; Sat, 31 May 2014 05:06:34 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id lj1so2399374pab.31 for ; Fri, 30 May 2014 22:06:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=XvLOHYEp60fuUTjbIglbrJ/cszZ+PF+DrE9Zz8dr25M=; b=RZ3zthlJtP78JB+c058ORQPEMax2LS+uroJsoEqEFC9tETltVCE1jJWtLfIQsBFdmv MTuVPLQIFYZAXtY89DdjoyMKv7pGbWrzMC2MwcxiNw0fmm6Ga1HJFND95iIe8Ru3UWwS ai4+wjFeXY0TXtBEX4w+dwfd69qaNOFXRxXzayGKqAxaX5n7DPJd9/JI49kCekibUAW5 LIN6RmmuLKMe0OtWFxqa9gOVCERkKCGq1mjMB+6AnOw2MgJ651o8FB3lha+X7VK+1VIE o4GQeXon3VEQtzlI0ckO7zZrEY2xK2S4hJhX8rQnbG5aX8mr0ETmX/V1x3ULAK3/KOz0 3t5w== X-Gm-Message-State: ALoCoQnKH4f33zrcFdHbl0xBrTmAVn1cZTHSdHIGJx2gagtgFRl4Sqhd8ywwDWeyU8HPGwPWeIkx X-Received: by 10.66.180.34 with SMTP id dl2mr24257363pac.124.1401512793741; Fri, 30 May 2014 22:06:33 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id h5sm9119259pbw.81.2014.05.30.22.06.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 22:06:32 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_1CB88EAE-69A3-45B2-A07B-4DAC790C960C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: <20140531044152.GK43976@funkthat.com> Date: Fri, 30 May 2014 23:06:33 -0600 Message-Id: <54E44307-F5AF-4ED5-9566-18C5A3AF86DD@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531044152.GK43976@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm , Bernd Walter , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 05:06:35 -0000 --Apple-Mail=_1CB88EAE-69A3-45B2-A07B-4DAC790C960C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 30, 2014, at 10:41 PM, John-Mark Gurney wrote: > Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: >> On May 30, 2014, at 9:00 PM, Ian Lepore wrote: >>=20 >>> On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: >>>> It seems SD cards support a delete command, which FreeBSD supports >>>> with the mmcsd driver. >>>> newfs and tunefs support TRIM in that new filesystems are trim'ed >>>> and the filesystems automatically trim free'ed blocks. >>>> So far so good. >>>> On the practical side with SD based ARM you don't write filesystems >>>> directly via mmcsd. >>>> We either create an image, which id dd'ed onto SD or in some cases >>>> we use an USB SD drive. >>>> With dd the unused blocks are written as well, which effectively >>>> hurts by writing data. >>>> Is there some kind of dd, which actually don't write zero blocks, >>>> or even better does a trim call for them? >>>=20 >>> I don't think dd can safely do that. If it finds a block of zeroes = on >>> the input side, how does it know it's okay to do a DELETE for those >>> (which sets the block to all-bits-on on most flash media). Maybe = it's >>> important for that data to really be zero; dd doesn't know. >>>=20 >>> That's one of the reasons why I recently mentioned a desire for >>> a /dev/ones to go with /dev/zero as a way of pre-init'ing an image = to be >>> more friendly to flash media. The idea was not well-received by = other >>> freebsd folks. >>>=20 >>> Maybe if the image was sparse, dd could tell the difference between = an >>> missing segment and a segment populated with zeroes and do a DELETE = for >>> missing data. I never do the image creation thing, I mostly tend to = use >>> nfsroot and at $work we use tar to copy files to sdcards with a usb >>> burner rather than preformatting images into files. >>=20 >> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent = blocks are, by definition, all zeros. The only time there?s a problem is = when the TRIM doesn?t really TRIM? You don?t need it to be sparse at = all. Zeros are zeros. >=20 > Are you sure? TRIM'd space may or may not have a defined value to > return upon read, and what happens if one of those blocks of zeros > belongs to a file that needs those zeros to be zero? TRIM unmaps the block. Unmapped blocks are required by the standard to = return 0=92s. But the problem is there whether the images are written = out sparse or not: blocks of zeros are the same as blocks of missing = data (which return zeros). > There are bits that declare if the drive returns zeros or not, so this > would only be safe on those drives.. On the drives where they don=92t, we don=92t do TRIM, if I=92m reading = the code correctly=85 But it would be worth a check. Let me check the SD = card standard=85 Warner --Apple-Mail=_1CB88EAE-69A3-45B2-A07B-4DAC790C960C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTiWNZAAoJEGwc0Sh9sBEAFDQP/AsGQwLsMGFMaTGZQzXxrnLU Fh90RTyVjCo9dvN5928LhZoy0cAKW7nwbW+qjOw8o7vPEGKedxlnAC6NF+ew2t28 WA9Sy+Xl/etRU8qK9UmgQfxoTBKFJh1fGNoCMyV4TUEv9pg1wzQdnjABKG7GPBGH fFPgylBtCFEpOijqn/sH9QmWOGEr6jU1I3Z4vWPgiiGY/VPx57jTLBEZ2k+Xt17X f1MhfEbtfSSvmi3zgeyuKnkGNQikE6HlWptzmtmY+i0uAFP0Bm4L5Wnew2Gly0lf +afrqs+JbfZDh/XXCmEdPEoVJA58Mmj8ZTVQFN+lnze0hlwwZ6xgQO3LUPkzCH/g 8RHPTCo6BeY6W5IPSk+0b/Bpfy+bbdK49yTN8j99TPPe4sVkOd9ksv0ENwWdhqHG yWwwkmIFhU0DjiFeoP+/O1aPY7m4vThqGvNoV2rKMSHc9XEatDCgzxk96RODgazo r969F6iUfAzuRjP3hm49UxZMW3PKMyZcGNv5fW/KWfds3eY347UZCL/PHWI3iQjQ WlE9Xec1XrzFxWoJrqLuYUlISLo+EHUUprZ2Txplg8cuANICF5FcKR3ifb/KeOqV +t4I0MBNiJ7uQXOqD9UHJe2GwZGJ69gtypKbtwQ4EdfL27N3SI6SjbTAQ1UdeBy6 7sJm6CmfR20pz3798c+y =tTlK -----END PGP SIGNATURE----- --Apple-Mail=_1CB88EAE-69A3-45B2-A07B-4DAC790C960C-- From owner-freebsd-arm@FreeBSD.ORG Sat May 31 05:22:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04A69F39; Sat, 31 May 2014 05:22:16 +0000 (UTC) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B77712538; Sat, 31 May 2014 05:22:15 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id eb12so2706759oac.25 for ; Fri, 30 May 2014 22:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=k7Hj6KeZMTmdcJBf12a+/JDkIMiQYixBIdADovOfj5c=; b=oifFIQQAUdXom4+4/+vFBvGjV4uLi/jQd4xrKR2ntrBRk4/5egXdS3AbdXifrHgyel hGQBe0dUqH/1p95bSiORf6SloKHgD5mqy0TLOBJH6GIeYFyqEDoYuhAFkh6dI0ZyXN9m Ra8a/SPsDuD/F4XnghAX9vVBTXkQBQ+l2SMk2Vuhv7rumP2CwPWzYGzliR2H7FfaYkKP 7TD0y8FpxyscIWt9v7fBsnxn+maDlIBnSijFJYKzgnQW4xludCnAt8VyED3pMFlk6cBk lfYV7QGgiKx6XdS4obMWI/wx9Er618w9NsMeIK8NHrL7UmfwOqNSmFNqv9zCd4nfIDYC B14A== X-Received: by 10.182.165.73 with SMTP id yw9mr22570589obb.39.1401513735091; Fri, 30 May 2014 22:22:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.123.178 with HTTP; Fri, 30 May 2014 22:21:45 -0700 (PDT) In-Reply-To: <20140531044152.GK43976@funkthat.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531044152.GK43976@funkthat.com> From: Jia-Shiun Li Date: Sat, 31 May 2014 13:21:45 +0800 Message-ID: Subject: Re: TRIM on SD cards To: Warner Losh , Ian Lepore , "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 05:22:16 -0000 On Sat, May 31, 2014 at 12:41 PM, John-Mark Gurney wrote: > Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: >> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent blocks are, by definition, all zeros. The only time there?s a problem is when the TRIM doesn?t really TRIM? You don?t need it to be sparse at all. Zeros are zeros. > > Are you sure? TRIM'd space may or may not have a defined value to > return upon read, and what happens if one of those blocks of zeros > belongs to a file that needs those zeros to be zero? > > There are bits that declare if the drive returns zeros or not, so this > would only be safe on those drives.. > For the original question, the need is to keep info about written blocks with the image it self, rather than directly issuing delete on media. I think it is easier to - erase all sdcard blocks before writing image, - teach md to write sparse file, and - teach dd to only write blocks according to info got from sparse image file. In current status block usage info got lost during image creation. Zeroes do not guarantee their existence can be safely ignored. On the other hand read from deleted block does not guarantee zeroes either. I know little about sdcard, but ATA defines a TRIMmed block as being one of the following behaviors on read, according to device: - non-deterministic read, each read *may* get different value - deterministic read value, reads can be *any* fixed value - deterministic read zero, reads are always zero. in practice at least both case 1 & 3 exist. -Jia-Shiun From owner-freebsd-arm@FreeBSD.ORG Sat May 31 05:37:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87C3D1BC for ; Sat, 31 May 2014 05:37:50 +0000 (UTC) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A7BE26B4 for ; Sat, 31 May 2014 05:37:50 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id wm4so2685340obc.4 for ; Fri, 30 May 2014 22:37:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=kWSjCBioCCjD06kdQ+ENpz0m9cKVkMr72W0XBvc5FeI=; b=R6NMzPfwxiWcHWC77sMe1Wo19xPp+NpwKCAPZyGzvo4u+pQQ5z9qWGiiExOG0BgJAd VCLmHZ1tWSa7wi9m3aMtPxWTq/ChqkyIqHud4jsgTFr6aAembwmIY50jCTuGTYT0jYjo HNhvDYlCPbv1p88sr9+JUrlfq7QWLrwFz1O4ZJhvjV1e6du8KVRlv+VFX1jrM85Eps5r JABatJm3BDuA7NmqdfHIeJHsdHbLfKVtijCUWXEqGzgX/l0PivlE3rttYnQ3xFreqwVE wrAX/KwOwSmRLnStHeHi6kT9dCuLsxe2QW87ox+dWhLTE0QtaCbEpXr2TZrUylBHGfH7 Xh+g== X-Gm-Message-State: ALoCoQkLQeGjouC65U0ezLt/4thOOzlgWAxGpOP2Wv1U4uMkU8COKOkfHkPuGw16rQN1uv+8tyLT X-Received: by 10.182.97.1 with SMTP id dw1mr22672083obb.23.1401514668906; Fri, 30 May 2014 22:37:48 -0700 (PDT) Received: from [172.21.0.96] (65-111-100-227.static.grandenetworks.net. [65.111.100.227]) by mx.google.com with ESMTPSA id ny5sm11273358obb.21.2014.05.30.22.37.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 22:37:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: TRIM on SD cards From: Jim Thompson X-Mailer: iPad Mail (11D201) In-Reply-To: <20140531044152.GK43976@funkthat.com> Date: Sat, 31 May 2014 00:37:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <54DF962E-4A84-4309-ABCE-DB2DA12DAE0A@netgate.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531044152.GK43976@funkthat.com> To: John-Mark Gurney Cc: Ian Lepore , "freebsd-arm@freebsd.org" , Bernd Walter , "ticso@cicely.de" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 05:37:50 -0000 > On May 30, 2014, at 11:41 PM, John-Mark Gurney wrote: >=20 > Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: >>> On May 30, 2014, at 9:00 PM, Ian Lepore wrote: >>>=20 >>>> On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: >>>> It seems SD cards support a delete command, which FreeBSD supports >>>> with the mmcsd driver. >>>> newfs and tunefs support TRIM in that new filesystems are trim'ed >>>> and the filesystems automatically trim free'ed blocks. >>>> So far so good. >>>> On the practical side with SD based ARM you don't write filesystems >>>> directly via mmcsd. >>>> We either create an image, which id dd'ed onto SD or in some cases >>>> we use an USB SD drive. >>>> With dd the unused blocks are written as well, which effectively >>>> hurts by writing data. >>>> Is there some kind of dd, which actually don't write zero blocks, >>>> or even better does a trim call for them? >>>=20 >>> I don't think dd can safely do that. If it finds a block of zeroes on >>> the input side, how does it know it's okay to do a DELETE for those >>> (which sets the block to all-bits-on on most flash media). Maybe it's >>> important for that data to really be zero; dd doesn't know. >>>=20 >>> That's one of the reasons why I recently mentioned a desire for >>> a /dev/ones to go with /dev/zero as a way of pre-init'ing an image to be= >>> more friendly to flash media. The idea was not well-received by other >>> freebsd folks. >>>=20 >>> Maybe if the image was sparse, dd could tell the difference between an >>> missing segment and a segment populated with zeroes and do a DELETE for >>> missing data. I never do the image creation thing, I mostly tend to use= >>> nfsroot and at $work we use tar to copy files to sdcards with a usb >>> burner rather than preformatting images into files. >>=20 >> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent block= s are, by definition, all zeros. The only time there?s a problem is when the= TRIM doesn?t really TRIM? You don?t need it to be sparse at all. Zeros are z= eros. >=20 > Are you sure? TRIM'd space may or may not have a defined value to > return upon read, and what happens if one of those blocks of zeros > belongs to a file that needs those zeros to be zero? >=20 > There are bits that declare if the drive returns zeros or not, so this > would only be safe on those drives.. Since time immortal (23:59:59 31 Dec 1969), or at least 1978 or so, the file= system has supported the idea of sparse files. =20 =46rom the iPad, so no error checking or indentation... #include #include main() { int fd; struct stat st =3D {0}; fd =3D open("foo", 2); lseek(fd, 1024*1024, SEEK_SET); write(fd, '\0', 1); fstat(fd,&st); if (st.st_blocksize * st.st_blocks < st.st_size) printf("file is sparse\n); close(fd); exit(0); } Unix doesn't zero the blocks on the free list. This is the same. TRIM just t= ells the drive that the block is free. The file system already knows.=20 The above will fail if foo exists and is at least 1MB in size. Sorry.=20 Jim From owner-freebsd-arm@FreeBSD.ORG Sat May 31 08:39:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3862D5B; Sat, 31 May 2014 08:39:12 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 989C32442; Sat, 31 May 2014 08:39:11 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s4V8ctGC015260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 31 May 2014 10:38:55 +0200 (CEST) (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 s4V8coRp059257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 10:38:50 +0200 (CEST) (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 s4V8com8050421; Sat, 31 May 2014 10:38:50 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s4V8cnTW050420; Sat, 31 May 2014 10:38:49 +0200 (CEST) (envelope-from ticso) Date: Sat, 31 May 2014 10:38:49 +0200 From: Bernd Walter To: Jia-Shiun Li Subject: Re: TRIM on SD cards Message-ID: <20140531083849.GJ26883@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531044152.GK43976@funkthat.com> 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" , Bernd Walter , Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 08:39:13 -0000 On Sat, May 31, 2014 at 01:21:45PM +0800, Jia-Shiun Li wrote: > On Sat, May 31, 2014 at 12:41 PM, John-Mark Gurney wrote: > > Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: > >> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent blocks are, by definition, all zeros. The only time there?s a problem is when the TRIM doesn?t really TRIM? You don?t need it to be sparse at all. Zeros are zeros. > > > > Are you sure? TRIM'd space may or may not have a defined value to > > return upon read, and what happens if one of those blocks of zeros > > belongs to a file that needs those zeros to be zero? > > > > There are bits that declare if the drive returns zeros or not, so this > > would only be safe on those drives.. > > > > For the original question, the need is to keep info about written > blocks with the image it self, rather than directly issuing delete on > media. I think it is easier to > - erase all sdcard blocks before writing image, > - teach md to write sparse file, and > - teach dd to only write blocks according to info got from sparse image file. > > In current status block usage info got lost during image creation. > Zeroes do not guarantee their existence can be safely ignored. On the > other hand read from deleted block does not guarantee zeroes either. I > know little about sdcard, but ATA defines a TRIMmed block as being one > of the following behaviors on read, according to device: > > - non-deterministic read, each read *may* get different value > - deterministic read value, reads can be *any* fixed value > - deterministic read zero, reads are always zero. > > in practice at least both case 1 & 3 exist. Well Ok. I thought TRIM'ed blocks return zero and it would be possible to autodetect zero blocks in images. Anyway, this is only one part of my first mail. Sorry - my first mail wasn't very clear about this, but there are two other parts. Is there any option to TRIM a filesystem at a later point? Newfs can TRIM unused space of new filesystems and tunefs ensure TRIM for freshly emptied blocks. But what can I do when upgrading old systems? With the above I need to copy the data and newfs. I don't have to use images at all, but I do have to handle USB cardreader, unless I go another step further and setup a special environment with raw MMC/SD controller to write cards. How can I be sure that a given USB SD-reader really handles the TRIM? In my case I didn't get an error, but does it mean the blocks are really TRIM'ed? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat May 31 09:09:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50EE83C9; Sat, 31 May 2014 09:09:05 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BBAF2645; Sat, 31 May 2014 09:09:04 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4V98mjc078064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 02:08:48 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4V98mVS078063; Sat, 31 May 2014 02:08:48 -0700 (PDT) (envelope-from jmg) Date: Sat, 31 May 2014 02:08:48 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: TRIM on SD cards Message-ID: <20140531090847.GL43976@funkthat.com> Mail-Followup-To: Warner Losh , Ian Lepore , freebsd-arm , Bernd Walter , ticso@cicely.de References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531044152.GK43976@funkthat.com> <54E44307-F5AF-4ED5-9566-18C5A3AF86DD@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E44307-F5AF-4ED5-9566-18C5A3AF86DD@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 31 May 2014 02:08:48 -0700 (PDT) Cc: freebsd-arm , Bernd Walter , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 09:09:05 -0000 Warner Losh wrote this message on Fri, May 30, 2014 at 23:06 -0600: > On May 30, 2014, at 10:41 PM, John-Mark Gurney wrote: > > > Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: > >> On May 30, 2014, at 9:00 PM, Ian Lepore wrote: > >> > >>> On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: > >>>> It seems SD cards support a delete command, which FreeBSD supports > >>>> with the mmcsd driver. > >>>> newfs and tunefs support TRIM in that new filesystems are trim'ed > >>>> and the filesystems automatically trim free'ed blocks. > >>>> So far so good. > >>>> On the practical side with SD based ARM you don't write filesystems > >>>> directly via mmcsd. > >>>> We either create an image, which id dd'ed onto SD or in some cases > >>>> we use an USB SD drive. > >>>> With dd the unused blocks are written as well, which effectively > >>>> hurts by writing data. > >>>> Is there some kind of dd, which actually don't write zero blocks, > >>>> or even better does a trim call for them? > >>> > >>> I don't think dd can safely do that. If it finds a block of zeroes on > >>> the input side, how does it know it's okay to do a DELETE for those > >>> (which sets the block to all-bits-on on most flash media). Maybe it's > >>> important for that data to really be zero; dd doesn't know. > >>> > >>> That's one of the reasons why I recently mentioned a desire for > >>> a /dev/ones to go with /dev/zero as a way of pre-init'ing an image to be > >>> more friendly to flash media. The idea was not well-received by other > >>> freebsd folks. > >>> > >>> Maybe if the image was sparse, dd could tell the difference between an > >>> missing segment and a segment populated with zeroes and do a DELETE for > >>> missing data. I never do the image creation thing, I mostly tend to use > >>> nfsroot and at $work we use tar to copy files to sdcards with a usb > >>> burner rather than preformatting images into files. > >> > >> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent blocks are, by definition, all zeros. The only time there?s a problem is when the TRIM doesn?t really TRIM? You don?t need it to be sparse at all. Zeros are zeros. > > > > Are you sure? TRIM'd space may or may not have a defined value to > > return upon read, and what happens if one of those blocks of zeros > > belongs to a file that needs those zeros to be zero? > > TRIM unmaps the block. Unmapped blocks are required by the standard to return 0?s. But the problem is there whether the images are written out sparse or not: blocks of zeros are the same as blocks of missing data (which return zeros). We only check that the drive supports _DSM_TRIM... We would also need to check that ATA_SUPPORT_RZAT and ATA_SUPPORT_DRAT are set in support3, but I don't see us doing that... This is per 7.9.3.2 of the ACS-3 ATA spec... if ((cgd.ident_data.support_dsm & ATA_SUPPORT_DSM_TRIM) && (cgd.inq_flags & SID_DMA)) softc->flags |= ADA_FLAG_CAN_TRIM; else softc->flags &= ~ADA_FLAG_CAN_TRIM; > > There are bits that declare if the drive returns zeros or not, so this > > would only be safe on those drives.. > > On the drives where they don?t, we don?t do TRIM, if I?m reading the code correctly? But it would be worth a check. Let me check the SD card standard? I haven't checked the SD card standard, I was only looking at the ATA standard... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat May 31 10:23:33 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7605DC95; Sat, 31 May 2014 10:23:33 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DB8882BC3; Sat, 31 May 2014 10:23:32 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s4VANED2015992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 31 May 2014 12:23:14 +0200 (CEST) (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 s4VAN5Fk060017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 12:23:06 +0200 (CEST) (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 s4VAN5b9050869; Sat, 31 May 2014 12:23:05 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s4VAN5h8050868; Sat, 31 May 2014 12:23:05 +0200 (CEST) (envelope-from ticso) Date: Sat, 31 May 2014 12:23:05 +0200 From: Bernd Walter To: Ian Lepore Subject: Re: TRIM on SD cards Message-ID: <20140531102305.GK26883@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1401505209.20883.34.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@FreeBSD.org, Bernd Walter , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 10:23:33 -0000 On Fri, May 30, 2014 at 09:00:09PM -0600, Ian Lepore wrote: > On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: > > It seems SD cards support a delete command, which FreeBSD supports > > with the mmcsd driver. > > newfs and tunefs support TRIM in that new filesystems are trim'ed > > and the filesystems automatically trim free'ed blocks. > > So far so good. > > On the practical side with SD based ARM you don't write filesystems > > directly via mmcsd. > > We either create an image, which id dd'ed onto SD or in some cases > > we use an USB SD drive. > > With dd the unused blocks are written as well, which effectively > > hurts by writing data. > > Is there some kind of dd, which actually don't write zero blocks, > > or even better does a trim call for them? > > I don't think dd can safely do that. If it finds a block of zeroes on > the input side, how does it know it's okay to do a DELETE for those > (which sets the block to all-bits-on on most flash media). Maybe it's > important for that data to really be zero; dd doesn't know. That 1 bit thing is true for raw flash media. A amanged NAND flash device simply unmaps a logical block from physical storage. This is similar to having holes in an ufs file, which per definition returns zero when reading a hole range. However from reading the thread it is not save to assume managed flash devices return zero blocks when reading TRIM'ed space. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat May 31 13:20:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D388303; Sat, 31 May 2014 13:20:28 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2245C287E; Sat, 31 May 2014 13:20:27 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s4VDK7CZ017322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 31 May 2014 15:20:08 +0200 (CEST) (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 s4VDK3fL061192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 15:20:03 +0200 (CEST) (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 s4VDK3qZ051807; Sat, 31 May 2014 15:20:03 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s4VDK2P7051806; Sat, 31 May 2014 15:20:02 +0200 (CEST) (envelope-from ticso) Date: Sat, 31 May 2014 15:20:02 +0200 From: Bernd Walter To: Jia-Shiun Li Subject: Re: TRIM on SD cards Message-ID: <20140531132002.GL26883@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531044152.GK43976@funkthat.com> <20140531083849.GJ26883@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140531083849.GJ26883@cicely7.cicely.de> 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" , Bernd Walter , Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 13:20:28 -0000 On Sat, May 31, 2014 at 10:38:49AM +0200, Bernd Walter wrote: > On Sat, May 31, 2014 at 01:21:45PM +0800, Jia-Shiun Li wrote: > > On Sat, May 31, 2014 at 12:41 PM, John-Mark Gurney wrote: > > > Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: > > >> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent blocks are, by definition, all zeros. The only time there?s a problem is when the TRIM doesn?t really TRIM? You don?t need it to be sparse at all. Zeros are zeros. > > > > > > Are you sure? TRIM'd space may or may not have a defined value to > > > return upon read, and what happens if one of those blocks of zeros > > > belongs to a file that needs those zeros to be zero? > > > > > > There are bits that declare if the drive returns zeros or not, so this > > > would only be safe on those drives.. > > > > > > > For the original question, the need is to keep info about written > > blocks with the image it self, rather than directly issuing delete on > > media. I think it is easier to > > - erase all sdcard blocks before writing image, > > - teach md to write sparse file, and > > - teach dd to only write blocks according to info got from sparse image file. > > > > In current status block usage info got lost during image creation. > > Zeroes do not guarantee their existence can be safely ignored. On the > > other hand read from deleted block does not guarantee zeroes either. I > > know little about sdcard, but ATA defines a TRIMmed block as being one > > of the following behaviors on read, according to device: > > > > - non-deterministic read, each read *may* get different value > > - deterministic read value, reads can be *any* fixed value > > - deterministic read zero, reads are always zero. > > > > in practice at least both case 1 & 3 exist. > > Well Ok. > I thought TRIM'ed blocks return zero and it would be possible to > autodetect zero blocks in images. > Anyway, this is only one part of my first mail. > Sorry - my first mail wasn't very clear about this, but there are two > other parts. > > Is there any option to TRIM a filesystem at a later point? > Newfs can TRIM unused space of new filesystems and tunefs ensure > TRIM for freshly emptied blocks. > But what can I do when upgrading old systems? > With the above I need to copy the data and newfs. > > I don't have to use images at all, but I do have to handle USB > cardreader, unless I go another step further and setup a special > environment with raw MMC/SD controller to write cards. > How can I be sure that a given USB SD-reader really handles the TRIM? > In my case I didn't get an error, but does it mean the blocks are > really TRIM'ed? Ok - so much about "I got no error". In fact there was one, but this was a kernel message I didn't saw on my shell: WARNING: /mnt: TRIM flag on fs but disk does not support TRIM Interestingly newfs -E worked without errors. I've tried some USB sticks and readers, but all issued this error message. So it seems that either my USB reader or the card don't support TRIM. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat May 31 16:45:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE4491B1 for ; Sat, 31 May 2014 16:45:36 +0000 (UTC) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BED6275C for ; Sat, 31 May 2014 16:45:36 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fb1so2758695pad.37 for ; Sat, 31 May 2014 09:45:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Xj7DPmmaoZep0mUON6hHIh4TSafOcOZS3egcah0qh3g=; b=iY5t/wS43CUJrEXVBA+T+wS4RGfbqADmDiBCUWvQvPcKNGUhNart3QtgwtytgJ4svi UNgpxLJER5cQZ6n2OsNHfPgAUUclxUdIlOhxyyO+YpFYOwQdS3R8CJLeiwQ/3TVoUnrp qb/AKr9XgkPMwFBWf65B9iuncDwZLPfvoV4hQv5mhJPu8IXb4Da6iKXauCdfNGf88Tb0 PzGQbj2XMnzazD4P3cZyAt4aVpcY3Q+do1jCnpThPGm9YYsl60oNK9pcy4Nj4b3NmSyo GRZtrrxuAtdI8Tl25Fg6dVT6egBOH4d/YAQPzPxwP/Sx9NlNfr7hbmKKHKcH0HonYzhK ctgg== X-Gm-Message-State: ALoCoQlX0saX6bIBKujjKD5JNoYZdzhZu38qgugLXEFKqfwqT+51QmU9CkQAWhfJDx8EXL9Sh0OP X-Received: by 10.68.237.33 with SMTP id uz1mr27875566pbc.76.1401554730460; Sat, 31 May 2014 09:45:30 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id xk3sm12061442pbb.65.2014.05.31.09.45.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 09:45:29 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_85874F1D-B829-4757-9B82-F7A7D14631F0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: <20140531102305.GK26883@cicely7.cicely.de> Date: Sat, 31 May 2014 10:45:30 -0600 Message-Id: <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@FreeBSD.org, Bernd Walter , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 16:45:36 -0000 --Apple-Mail=_85874F1D-B829-4757-9B82-F7A7D14631F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 4:23 AM, Bernd Walter = wrote: > On Fri, May 30, 2014 at 09:00:09PM -0600, Ian Lepore wrote: >> On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: >>> It seems SD cards support a delete command, which FreeBSD supports >>> with the mmcsd driver. >>> newfs and tunefs support TRIM in that new filesystems are trim'ed >>> and the filesystems automatically trim free'ed blocks. >>> So far so good. >>> On the practical side with SD based ARM you don't write filesystems >>> directly via mmcsd. >>> We either create an image, which id dd'ed onto SD or in some cases >>> we use an USB SD drive. >>> With dd the unused blocks are written as well, which effectively >>> hurts by writing data. >>> Is there some kind of dd, which actually don't write zero blocks, >>> or even better does a trim call for them? >>=20 >> I don't think dd can safely do that. If it finds a block of zeroes = on >> the input side, how does it know it's okay to do a DELETE for those >> (which sets the block to all-bits-on on most flash media). Maybe = it's >> important for that data to really be zero; dd doesn't know. >=20 > That 1 bit thing is true for raw flash media. > A amanged NAND flash device simply unmaps a logical block from = physical > storage. > This is similar to having holes in an ufs file, which per definition > returns zero when reading a hole range. > However from reading the thread it is not save to assume managed flash > devices return zero blocks when reading TRIM'ed space. One of the things that I did for images years ago was compressed tar = files. There was so much variation between CF makers and at the time CF = geometry was important to the BIOS, so we made our images as tar balls. = We then had a makefile target that would create a partition on the card = that was actually there, put boot blocks on it then extract the tarball=85= I never have liked DD for creating images, even when LBAs ruled the = day because you=92d always have to grow/shrink the FS afterwards. The = only advantage it had was it was easy=85 Perhaps it is time to go back = to that model? The alternative that wouldn=92t suck too bad would be to = create variable sized images based on how much data was actually present = and ensure there are no holes (or minimal holes) in the filesystem. Hmmm, if we know WHAT filesystem we=92re dealing with, then we could = perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it = knows are free, which would be a useful, data-driven approach that could = ensure we start out with a nicely trimmed FS. Given the vagaries of the = different kinds of TRIMs and the various translation layers we have, = that might be the most robust. Warner --Apple-Mail=_85874F1D-B829-4757-9B82-F7A7D14631F0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTigcqAAoJEGwc0Sh9sBEArVQQAI+QilFKU6INLQEbz+ikn82H zOm2aVPf3VrYXjokf9nbUuk2/5G2330MmdQDzJ/enhCon4l2UF/5L7yTeR1OLGCI O9+/cFq9umlHgKwch+CFUhL1EAwrtou21/Z9CAzxEaoLuMs7m1mR0jntCGcuUHrh Un5dzQclcPYDp3v32vjNnNvEGzNvK1fsmNdY07zUwZCj8gm3aZJkulD8Txy3lJ7W KyAA1Xh+IXQ+U7LSYkVIt8NrKYEMozU0oZ6PCBuakpDif9PiPeB/pY+TpYP/A9vM cpC4FdTkIjUxnzIWSC1u6mNuUvnLKJuOhtwDREO4r4R1Nu6EDMIKi+DriU3mvWfe v0AqYWEx6QvJQJq+79Pdk/7LCPwZB7Fl9mx7xcEidortFfCPlulORLjieaH1rUlf 1ipaPOUAybXV6W2oezneo1xm0uIj7BKEt+chM6Gij/zcxTZg5b3unNnRBohrdHlm /sbMGdl/kVr8ll+HrESdbwqJ/ttSAN7QYk5YKveC+PR1pO3i2Ndy6/HIacSrW6P/ gt499zrgDUtMTExMx3SmgIqvq3CtAhUCmtk0RFyGy84JmGq3DWoaMkOCG91i1D06 QJ9Cph+duV0ykudw5G06oayOzuasNDjVf1JOLN8gx5zvD4ATJ6+MGo8AkOnRY0FK Ie6ZTlM+S8i7QXLhaYXF =ybKK -----END PGP SIGNATURE----- --Apple-Mail=_85874F1D-B829-4757-9B82-F7A7D14631F0-- From owner-freebsd-arm@FreeBSD.ORG Sat May 31 17:05:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C69ED3F4 for ; Sat, 31 May 2014 17:05:59 +0000 (UTC) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90BC128B9 for ; Sat, 31 May 2014 17:05:59 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id kx10so2769650pab.14 for ; Sat, 31 May 2014 10:05:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FYHQM3UAOJoinXdr71MAcyCxsBIoL8nOx6yIZNUGcb4=; b=N2t2AsdHLNdvxOQzGZSRXYDAQfgLrKoTikpl+g5LrF5ihPPJB1CWbV1m93pyy4z311 2WbFnXYUwMl2oo44NUNGTGngA+SjOoGrxrgZadfonM1b/1tZE7L2r0qA9ta4kgGHAwhm vTwrk7+0ZXVpDWohF53kI3r1blL2Kff8w6nx4GbMVsekMyfoEjC8gw1Unat0AIxjcKV1 U2M0eUYPBb+CrU5LQeg8fTgLjVxjfirhtVbO2FbuvWxMwi4GoLbKvUrdDNzlJykMI7Co NxRVxopXxSYAcZA5TpG9PYVSe6USYvrzH33YxTL0/yJkjFNF3LvjQ1i9XuMjpg2HpVhH iTBQ== X-Gm-Message-State: ALoCoQlkEnS7iWIgxQ0jhEv4Y0nFvlVrXj2PJDUM72EwcrCUGBFdIxe97bBpQY8ajP/ftCeQTnDU X-Received: by 10.68.172.193 with SMTP id be1mr27936490pbc.31.1401554093933; Sat, 31 May 2014 09:34:53 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id fk4sm36137347pab.23.2014.05.31.09.34.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 09:34:53 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_FEDB7C16-ECD3-453F-AEEE-53CC88EEDA19"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: <20140531132002.GL26883@cicely7.cicely.de> Date: Sat, 31 May 2014 10:34:54 -0600 Message-Id: <127A95E9-82D7-413E-ABDB-81C5C3A027B4@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531044152.GK43976@funkthat.com> <20140531083849.GJ26883@cicely7.cicely.de> <20140531132002.GL26883@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" , Bernd Walter , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 17:05:59 -0000 --Apple-Mail=_FEDB7C16-ECD3-453F-AEEE-53CC88EEDA19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 7:20 AM, Bernd Walter = wrote: > On Sat, May 31, 2014 at 10:38:49AM +0200, Bernd Walter wrote: >> On Sat, May 31, 2014 at 01:21:45PM +0800, Jia-Shiun Li wrote: >>> On Sat, May 31, 2014 at 12:41 PM, John-Mark Gurney = wrote: >>>> Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: >>>>> Blocks of zeros can safely be BIO_DELETEd. Why, because = nonexistent blocks are, by definition, all zeros. The only time there?s = a problem is when the TRIM doesn?t really TRIM? You don?t need it to be = sparse at all. Zeros are zeros. >>>>=20 >>>> Are you sure? TRIM'd space may or may not have a defined value to >>>> return upon read, and what happens if one of those blocks of zeros >>>> belongs to a file that needs those zeros to be zero? >>>>=20 >>>> There are bits that declare if the drive returns zeros or not, so = this >>>> would only be safe on those drives.. >>>>=20 >>>=20 >>> For the original question, the need is to keep info about written >>> blocks with the image it self, rather than directly issuing delete = on >>> media. I think it is easier to >>> - erase all sdcard blocks before writing image, >>> - teach md to write sparse file, and >>> - teach dd to only write blocks according to info got from sparse = image file. >>>=20 >>> In current status block usage info got lost during image creation. >>> Zeroes do not guarantee their existence can be safely ignored. On = the >>> other hand read from deleted block does not guarantee zeroes either. = I >>> know little about sdcard, but ATA defines a TRIMmed block as being = one >>> of the following behaviors on read, according to device: >>>=20 >>> - non-deterministic read, each read *may* get different value >>> - deterministic read value, reads can be *any* fixed value >>> - deterministic read zero, reads are always zero. >>>=20 >>> in practice at least both case 1 & 3 exist. >>=20 >> Well Ok. >> I thought TRIM'ed blocks return zero and it would be possible to >> autodetect zero blocks in images. >> Anyway, this is only one part of my first mail. >> Sorry - my first mail wasn't very clear about this, but there are two >> other parts. >>=20 >> Is there any option to TRIM a filesystem at a later point? >> Newfs can TRIM unused space of new filesystems and tunefs ensure >> TRIM for freshly emptied blocks. >> But what can I do when upgrading old systems? >> With the above I need to copy the data and newfs. >>=20 >> I don't have to use images at all, but I do have to handle USB >> cardreader, unless I go another step further and setup a special >> environment with raw MMC/SD controller to write cards. >> How can I be sure that a given USB SD-reader really handles the TRIM? >> In my case I didn't get an error, but does it mean the blocks are >> really TRIM'ed? >=20 > Ok - so much about "I got no error". > In fact there was one, but this was a kernel message I didn't saw > on my shell: > WARNING: /mnt: TRIM flag on fs but disk does not support TRIM > Interestingly newfs -E worked without errors. > I've tried some USB sticks and readers, but all issued this error > message. > So it seems that either my USB reader or the card don't support TRIM. That=92s why I think we=92ll need to trim on the actual target. It could = also be that umass doesn=92t support BIO_DELETE properly by not = translating that info to indicate TRIM or UNMAP or WS is supported. It = would take some quality time with the da driver to find out for sure, = plus looking at the USB specs. CMD38 is listed as mandatory, except for = ROM cards. First, the SD card standard guarantees a value, which is good. The bad = news is that the value guaranteed varies from card to card. CMD38 is = used to erase the data. The standard says: The data at the card after an erase operation is either '0' or '1', = depends on the card vendor.=20 The SCR register bit DATA_STAT_AFTER_ERASE (bit 55) defines whether it = is '0' or '1'.=20 =20 which is less useful than I=92d hoped. This implies either that we hope = for it to be 0, then write a trivial program to read blocks and trim the = zero=92d ones, or we have to know the extents that are valid or invalid, = which is much harder=85. This suggests looking at umass and/or the SD adapter card would be = fruitful=85 Warner --Apple-Mail=_FEDB7C16-ECD3-453F-AEEE-53CC88EEDA19 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTigSuAAoJEGwc0Sh9sBEAt+oP/j1vrTHtdmpoX9OAwsHkQX/8 VxuZZv0rUQ6Sf/7/CtauWtKgo2lOWslMpalf3OIVk0H/8ePsL8jYKLNi30h0DjM5 7dpyVZLnOy7B0b6xyfTz5g2OGbq2bNJ2l7VdjEqN5uXEqE8uwWDbh9YPdn6gfIqV J+S0BpNiIqtTgReLks54k23+oML/1D/ndMCVleSAsJSYCEVKIUPxA8+KGUaK8tBW 1kTwiLV1SaKNO4ltgljXhwPJm1cJUidXSambP8l1OXouu7JpcrlA4K+35vNnbtCl 2EYWNjUWjzRAXHoVFRielE63Zr1TbJwA/Pnhbx2ITRfYdoe1bHfHHrJtGMg83DJM v34TczYN4h2zegbwdJQiaBEpPwaTS9YjRmqYy5ll2tDXsyUFjomPN5mcVzKVLvb9 ItP1TmeS1Oz9HSzWHwF3mPHB5ebc2ytPcBt+zUt3CTUXqRsN8K7BPFRwmCjFM47o gR0VMF5sT72J1NNeG3OebtCiaJVoV9eIV38ISJlZner8u/eZFQxPHMtOoxhMbgLs rYOjmpUgL0EUEX7Cl1c+2YMOew1TetXdIj2L3kakM5lpCKkb8lBzH5EnvhT1wMRz HvZVx53sxgLaflAvBkP30iwmBD0i/TOctGQOJGI2CmcG91TUl2GaR3X3JusWj3eW jWcIAWtbTEPjl34JZ+Ov =xWa+ -----END PGP SIGNATURE----- --Apple-Mail=_FEDB7C16-ECD3-453F-AEEE-53CC88EEDA19-- From owner-freebsd-arm@FreeBSD.ORG Sat May 31 17:31:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1CB36CA; Sat, 31 May 2014 17:31:54 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 60F702A93; Sat, 31 May 2014 17:31:54 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id a108so8342164qge.39 for ; Sat, 31 May 2014 10:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=exuqowdlGr465K1O/krT3AxU57s+u8xk3buEKC/Hyjo=; b=tgVnq/MitWTLCi4yK/E/JvooLwp+Mz1Py391SVgFsb48ZTNowrouU7eEfvil1qFnLM Zn3WAo2ufcZvqvHKscHdMh+oZSqfI4/lIxUpXgfRnu1WAz2oE07UxqED67ezWdDalR+/ Bi0xoJy7c8BjD5SwkS/b3W8DUAlvILpmDds3d3nM6CJJtjzUAnudLg2H+nOneyV/x/sQ nkQBilk6LjByI46ZQm9Xwmr6GGMPDDo7UN+PkZAoVGsyMG9TKn/qaPRdfNDu+zFKi75O UBX8yy1VFp40NnDH3+9JiVYPsD5Hq33SRTSnAht/L0vvlDIek2U6fz6FzYSHi23p3vpc g07A== MIME-Version: 1.0 X-Received: by 10.140.96.51 with SMTP id j48mr31425501qge.24.1401557513482; Sat, 31 May 2014 10:31:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 31 May 2014 10:31:53 -0700 (PDT) In-Reply-To: <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> Date: Sat, 31 May 2014 10:31:53 -0700 X-Google-Sender-Auth: 1pKb3avuM_yXL3BvDybGC2Ydrss Message-ID: Subject: Re: TRIM on SD cards From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 17:31:54 -0000 On 31 May 2014 09:45, Warner Losh wrote: > One of the things that I did for images years ago was compressed tar file= s. There was so much variation between CF makers and at the time CF geometr= y was important to the BIOS, so we made our images as tar balls. We then ha= d a makefile target that would create a partition on the card that was actu= ally there, put boot blocks on it then extract the tarball=E2=80=A6 I neve= r have liked DD for creating images, even when LBAs ruled the day because y= ou=E2=80=99d always have to grow/shrink the FS afterwards. The only advanta= ge it had was it was easy=E2=80=A6 Perhaps it is time to go back to that mo= del? The alternative that wouldn=E2=80=99t suck too bad would be to create = variable sized images based on how much data was actually present and ensur= e there are no holes (or minimal holes) in the filesystem. > > Hmmm, if we know WHAT filesystem we=E2=80=99re dealing with, then we coul= d perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it k= nows are free, which would be a useful, data-driven approach that could ens= ure we start out with a nicely trimmed FS. Given the vagaries of the differ= ent kinds of TRIMs and the various translation layers we have, that might b= e the most robust. Having makefs spit this out would be rather useful. -a From owner-freebsd-arm@FreeBSD.ORG Sat May 31 17:43:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5CB077A for ; Sat, 31 May 2014 17:43:51 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81B3E2C34 for ; Sat, 31 May 2014 17:43:51 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s4VHPB9i047562; Sat, 31 May 2014 17:25:11 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id pckx8zpfeygpixfn88zhgdh37w; Sat, 31 May 2014 17:25:11 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Tim Kientzle In-Reply-To: <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> Date: Sat, 31 May 2014 10:25:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <931C85D3-3D43-461E-9A78-BFB4451E9342@kientzle.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 17:43:51 -0000 On May 31, 2014, at 9:45 AM, Warner Losh wrote: > I never have liked DD for creating images, even when LBAs ruled the = day because you=92d always have to grow/shrink the FS afterwards. A few of us have been experimenting with having growfs run automatically on first boot. Seems to work okay, it just requires a couple of iterations to figure out the "proper" minimal FS size to start with. If the FS is minimally sized, then there aren't many empty blocks to worry about. The big advantage of DD images is that there are plentiful tools for Windows, Mac, etc, that can splat them onto a USB stick or SD card. Tim From owner-freebsd-arm@FreeBSD.ORG Sat May 31 17:48:24 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D3DF83F for ; Sat, 31 May 2014 17:48:24 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EB142D1F for ; Sat, 31 May 2014 17:48:24 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WqnOI-000FHG-Gm; Sat, 31 May 2014 17:48:22 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4VHmJ7q001346; Sat, 31 May 2014 11:48:19 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Cks9CFBxbbyJNsqv/POtK Subject: Re: TRIM on SD cards From: Ian Lepore To: Warner Losh In-Reply-To: <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> Content-Type: text/plain; charset="windows-1251" Date: Sat, 31 May 2014 11:48:19 -0600 Message-ID: <1401558499.20883.44.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s4VHmJ7q001346 Cc: freebsd-arm@FreeBSD.org, Bernd Walter , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 17:48:24 -0000 On Sat, 2014-05-31 at 10:45 -0600, Warner Losh wrote: > On May 31, 2014, at 4:23 AM, Bernd Walter wro= te: >=20 > > On Fri, May 30, 2014 at 09:00:09PM -0600, Ian Lepore wrote: > >> On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: > >>> It seems SD cards support a delete command, which FreeBSD supports > >>> with the mmcsd driver. > >>> newfs and tunefs support TRIM in that new filesystems are trim'ed > >>> and the filesystems automatically trim free'ed blocks. > >>> So far so good. > >>> On the practical side with SD based ARM you don't write filesystems > >>> directly via mmcsd. > >>> We either create an image, which id dd'ed onto SD or in some cases > >>> we use an USB SD drive. > >>> With dd the unused blocks are written as well, which effectively > >>> hurts by writing data. > >>> Is there some kind of dd, which actually don't write zero blocks, > >>> or even better does a trim call for them? > >>=20 > >> I don't think dd can safely do that. If it finds a block of zeroes = on > >> the input side, how does it know it's okay to do a DELETE for those > >> (which sets the block to all-bits-on on most flash media). Maybe it= 's > >> important for that data to really be zero; dd doesn't know. > >=20 > > That 1 bit thing is true for raw flash media. > > A amanged NAND flash device simply unmaps a logical block from physic= al > > storage. > > This is similar to having holes in an ufs file, which per definition > > returns zero when reading a hole range. > > However from reading the thread it is not save to assume managed flas= h > > devices return zero blocks when reading TRIM'ed space. >=20 > One of the things that I did for images years ago was compressed tar fi= les. There was so much variation between CF makers and at the time CF geo= metry was important to the BIOS, so we made our images as tar balls. We t= hen had a makefile target that would create a partition on the card that = was actually there, put boot blocks on it then extract the tarball=85 I = never have liked DD for creating images, even when LBAs ruled the day bec= ause you=92d always have to grow/shrink the FS afterwards. The only advan= tage it had was it was easy=85 Perhaps it is time to go back to that mode= l? The alternative that wouldn=92t suck too bad would be to create variab= le sized images based on how much data was actually present and ensure th= ere are no holes (or minimal holes) in the filesystem. >=20 > Hmmm, if we know WHAT filesystem we=92re dealing with, then we could pe= rhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it kno= ws are free, which would be a useful, data-driven approach that could ens= ure we start out with a nicely trimmed FS. Given the vagaries of the diff= erent kinds of TRIMs and the various translation layers we have, that mig= ht be the most robust. >=20 > Warner >=20 I wouldn't at all mind an fsck or growfs option or a standalone tool that would issue deletes for unused blocks on an existing filesystem. I have several big SSDs on this system and I had no TRIM support for a long time, so there are lots of blocks on the drives that bogusly look used to the onboard block management code. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat May 31 17:49:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96F82881 for ; Sat, 31 May 2014 17:49:15 +0000 (UTC) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62B042D25 for ; Sat, 31 May 2014 17:49:15 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id rq2so2835216pbb.3 for ; Sat, 31 May 2014 10:49:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=L6wFcLL/8HXkDHvJ2hlGozAafEtUf77CSBhElxFVwZo=; b=feordcPxeUUJziZ8Mii8JPIxvJw4nvw+NxGk28Riqxyh+B17WgZyIeAQodq3KhW+8l 2D9kM9d+ORhwTQVgchlfH5EVb+Fn+A1oIKWEFuceeKu7RXw4SNNEiPyahIk107wB8YQL f/UykoKtDlq6JyRew8KPc/V4I2xqCA/NksyfDYmo1PgnNj+KkQ3CPlpozePCt1aAE0MO XUfTksqgTOdj4EtHK0iCabcukNf/9+GzkxLOWHplRNX7NmXtI0yyMr9LU9njoJoZu/7l q3n/zf8z3oI5UzafmSltx4+tyyjCxzwaB5r6hD/hxHX1XVUnMvpFOu2m81bdQeAvkdlx xYaw== X-Gm-Message-State: ALoCoQnxf6aK0cdigczDs4YTFokXHtwPrUg35ozpdSNp4lBaQsZ1/g81cvb1ks2x9AmkL6NL18fo X-Received: by 10.68.242.135 with SMTP id wq7mr28000783pbc.147.1401558549590; Sat, 31 May 2014 10:49:09 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id wq10sm36905306pac.24.2014.05.31.10.49.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 10:49:08 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_5EF80B3B-98D6-41B7-9A6B-788C0F2F3B6E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: Date: Sat, 31 May 2014 11:49:10 -0600 Message-Id: References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 17:49:15 -0000 --Apple-Mail=_5EF80B3B-98D6-41B7-9A6B-788C0F2F3B6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 11:31 AM, Adrian Chadd wrote: > On 31 May 2014 09:45, Warner Losh wrote: >=20 >> One of the things that I did for images years ago was compressed tar = files. There was so much variation between CF makers and at the time CF = geometry was important to the BIOS, so we made our images as tar balls. = We then had a makefile target that would create a partition on the card = that was actually there, put boot blocks on it then extract the tarball=85= I never have liked DD for creating images, even when LBAs ruled the = day because you=92d always have to grow/shrink the FS afterwards. The = only advantage it had was it was easy=85 Perhaps it is time to go back = to that model? The alternative that wouldn=92t suck too bad would be to = create variable sized images based on how much data was actually present = and ensure there are no holes (or minimal holes) in the filesystem. >>=20 >> Hmmm, if we know WHAT filesystem we=92re dealing with, then we could = perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it = knows are free, which would be a useful, data-driven approach that could = ensure we start out with a nicely trimmed FS. Given the vagaries of the = different kinds of TRIMs and the various translation layers we have, = that might be the most robust. >=20 > Having makefs spit this out would be rather useful. I=92m not sure it would be. Any writes to the FS after you create it = would invalidate the list=85 Far easier to have fsck do it for you any = time you need it... Warner --Apple-Mail=_5EF80B3B-98D6-41B7-9A6B-788C0F2F3B6E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTihYWAAoJEGwc0Sh9sBEAsNEP/iiQ2M4RJVnHVZFWrJtqSbWo 6n+NWhW35joaG3MVOgwCdburr/OwIfn/X3KPsapMTnzfzAjhlp93BXM/4/FrtVDs /Et5ksG93BbreFcru5HRlqP2OF4h4m3lHCjTq8d1mTNIMdNeRotsfGyVmGuxK6Ap 5gDquaRi9/Y5djh8f+6z3Ca/QLSB4qXprML/jWFdh0skgcT9eIQftKmjYprgol5n 6f9HQHbj1mAUOcthw4JNbb4h5Bl8kknV2kf5Flb49RekuSce3WRPdPbNqWRwq6Nr wLQiBeKk+u7lN7dRZMVlPNXaJAd6r+UBmCHOhbxx4KNIW2TUowGg14eJ6toknmGX ein0/7snDWx/Ee1d9OGGMwRRLq0dlO1fcONywx+P9Q5TODH2/FtVlewI8yeEXfZQ VwxeOoh7vS49sZOxukqpmEdsDe5eWKmPT5Ot+T88EGgVhKXpMNLSLlPTsqbZBEQN P3Axw1UPnlI1DyQHz2Nkg8omGEnEAc2GRmc+9u9PbMkVq+PUFCuohMxtGh302KWd Ajkz8x3s2IZAcs5njyAJjVrSJrsL5B3GREitwHGPgHNRdsZfV0LOTg08Y/XhToGq cRrSbgE+2lZ7qiYXIaAcWas2qFfxTOUWdmHEixrZAetZ+Gn5TAtRCKhmSHY6Raqs tz8B3jy3QRKWlyLB13rT =jDja -----END PGP SIGNATURE----- --Apple-Mail=_5EF80B3B-98D6-41B7-9A6B-788C0F2F3B6E-- From owner-freebsd-arm@FreeBSD.ORG Sat May 31 17:59:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B800B02 for ; Sat, 31 May 2014 17:59:29 +0000 (UTC) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC5322DDB for ; Sat, 31 May 2014 17:59:28 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id g10so2043292pdj.1 for ; Sat, 31 May 2014 10:59:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zdMEBP1Cb4HkYCWM0bSDVWOPfdPIkGYjeoJ+L8uPNKQ=; b=XpZ2NWaRDCRLutnkXjHoH3DQdGgU30WagQ0BYGf7eppanwmji8a4xwxkRFP6VTX5WS Gql+jj+lXWk1fKwoB6epgqzghuhbKiTefs1zy4lJJB4ZEHXm3mViHM04wjlSV2AFts2V RliZ//FKHcO504SNmL0DGAUHOffhxey3Z7Br/0klSjbNYtr0m3hmm5n8oy1kOLk28tCq ctoXSlJSwX5WxLC+1ImjgwsVbAXBnYfshkdlhmRNbvlVCxwXbFfzXBg8Wr4rrLQUP77c IWKpEM8idTJHlb+Lw79g40A5AbUiGSxStgG8/Ra1XaaRWIc/cTWuoWEyRGhg9VyCY6fO bSmw== X-Gm-Message-State: ALoCoQn+2dpU2hVCoaXz7PsFFDy9GQlUL1/im/fYG1S3UnxFxe0y85g3BqpFP1vomc6l4MG207fD X-Received: by 10.68.194.134 with SMTP id hw6mr28304640pbc.49.1401559161882; Sat, 31 May 2014 10:59:21 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ox3sm12262610pbb.88.2014.05.31.10.59.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 10:59:21 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_3D186CE6-EEDF-4711-ABBB-18836371C086"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: <1401558499.20883.44.camel@revolution.hippie.lan> Date: Sat, 31 May 2014 11:59:22 -0600 Message-Id: <5B622E08-6BAE-4A39-B04B-B80F40D1C692@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <1401558499.20883.44.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@FreeBSD.org, Bernd Walter , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 17:59:29 -0000 --Apple-Mail=_3D186CE6-EEDF-4711-ABBB-18836371C086 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1251 On May 31, 2014, at 11:48 AM, Ian Lepore wrote: > On Sat, 2014-05-31 at 10:45 -0600, Warner Losh wrote: >> On May 31, 2014, at 4:23 AM, Bernd Walter = wrote: >>=20 >>> On Fri, May 30, 2014 at 09:00:09PM -0600, Ian Lepore wrote: >>>> On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: >>>>> It seems SD cards support a delete command, which FreeBSD supports >>>>> with the mmcsd driver. >>>>> newfs and tunefs support TRIM in that new filesystems are trim'ed >>>>> and the filesystems automatically trim free'ed blocks. >>>>> So far so good. >>>>> On the practical side with SD based ARM you don't write = filesystems >>>>> directly via mmcsd. >>>>> We either create an image, which id dd'ed onto SD or in some cases >>>>> we use an USB SD drive. >>>>> With dd the unused blocks are written as well, which effectively >>>>> hurts by writing data. >>>>> Is there some kind of dd, which actually don't write zero blocks, >>>>> or even better does a trim call for them? >>>>=20 >>>> I don't think dd can safely do that. If it finds a block of zeroes = on >>>> the input side, how does it know it's okay to do a DELETE for those >>>> (which sets the block to all-bits-on on most flash media). Maybe = it's >>>> important for that data to really be zero; dd doesn't know. >>>=20 >>> That 1 bit thing is true for raw flash media. >>> A amanged NAND flash device simply unmaps a logical block from = physical >>> storage. >>> This is similar to having holes in an ufs file, which per definition >>> returns zero when reading a hole range. >>> However from reading the thread it is not save to assume managed = flash >>> devices return zero blocks when reading TRIM'ed space. >>=20 >> One of the things that I did for images years ago was compressed tar = files. There was so much variation between CF makers and at the time CF = geometry was important to the BIOS, so we made our images as tar balls. = We then had a makefile target that would create a partition on the card = that was actually there, put boot blocks on it then extract the tarball=85= I never have liked DD for creating images, even when LBAs ruled the = day because you=92d always have to grow/shrink the FS afterwards. The = only advantage it had was it was easy=85 Perhaps it is time to go back = to that model? The alternative that wouldn=92t suck too bad would be to = create variable sized images based on how much data was actually present = and ensure there are no holes (or minimal holes) in the filesystem. >>=20 >> Hmmm, if we know WHAT filesystem we=92re dealing with, then we could = perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it = knows are free, which would be a useful, data-driven approach that could = ensure we start out with a nicely trimmed FS. Given the vagaries of the = different kinds of TRIMs and the various translation layers we have, = that might be the most robust. >>=20 > I wouldn't at all mind an fsck or growfs option or a standalone tool > that would issue deletes for unused blocks on an existing filesystem. = I > have several big SSDs on this system and I had no TRIM support for a > long time, so there are lots of blocks on the drives that bogusly look > used to the onboard block management code. This is precisely why I=92d like this=85 There are also times one might = want to turn TRIM off if you are going to do a huge delete, followed by = adding lots of data. It might be faster to just trim what you didn=92t = refill=85 Or you might want to have a best-effort time strategy if you = know your FS can cope. Then if you get too many, you can discard them = and cleanup after the fact on the next boot. The number of use cases = here is actually rather large in addition to the one that tisco wants :) Warner --Apple-Mail=_3D186CE6-EEDF-4711-ABBB-18836371C086 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTihh6AAoJEGwc0Sh9sBEAiEMQALurYPzFHXuVPt1ATik0kzoi TO3gm9za9a8cqAGKk4rQVF0oo37wOcH5zuh5JmJaK0oHO/RyF7S97rrNANiFZp49 xjKWOW3HqzlQpGkLD2e2AYdeCIXHXyxRJuSluXT55BJyU5CEeq+Sh6B/wo5TnNTo 5YYtPZKnb31TUms5zAoDYjBZniYgBvWv17hb0EZ653U3sB8m5gjUuqMg3/s67B6J TEetOMMB1UaAnGPzKU5KTFVikh2ioPI39iwXlPw+2wertyZXoDy+UNAMK+YwBdLy VLB3UHbXeIyfUqfh2WYaADRd2RQs2wlgBI3rq/wFb8miVEa5Y+6W1LH8EWI33oKj +Eonleo7iNj5WKSVUshNw1QJivTJVFRkjdUpqDjjThZi/AwEABdDWqwqDQNef3MO Q+7Zf/qEbpZ1Zk5oZeqrToqJYQsHv2KSXiRwVQTkSaLkDIy1fx/AqhRgwIgZUdPt j9VRDNkbdriZHEbetroOmchd3nEITNNzkcS2TbmOOEJZbSa1x2IhKyKDkASFCscr vB91a7+kRGgcvPM/APs321J7Lo6FR4yiaVFaQ3ZLX5/zuE7c15WX1AKH9XWn5CZO S4mtpIcVKAr+x+xfYPpbCTU4PSpoJJd43Rv7ItCVA5S5wdiwkKDoJ0CxpRwITyOu chQFScl4lAkcrtlHvX8a =88FI -----END PGP SIGNATURE----- --Apple-Mail=_3D186CE6-EEDF-4711-ABBB-18836371C086-- From owner-freebsd-arm@FreeBSD.ORG Sat May 31 18:06:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC0E2C85; Sat, 31 May 2014 18:06:32 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 795672E80; Sat, 31 May 2014 18:06:32 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j7so588657qaq.17 for ; Sat, 31 May 2014 11:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Zuv5Wof+U8nZrBivm9SAmV2UklYKAqNblqT1kqj1dy0=; b=guhNvLb363pjQZPP6tfFmWNaOQREs7eHNEjn9Y8S6+i8/5iymuMyx21liO7vRbX45Q X0n7Q8awY4hct2uJzugArA2RviN8++YpMCIQmGc89QaBoLFIGCTc5ymYNWhwLs6qhK+G QgUGyk3YMgunMEXLGqCm7dGgQR7+ToTAmEJjXT0wXYbhpTIShwQtZVHnf1EwkzBgDdGp oRi9lvl3nhr/0kz65k+ebjSAdUPA//VO4ktwi/hIRCw2XYWDCV4IZhV6bjmn01vl27XW wqpA4t5lFUxDE5H23IYAiYRXWxUjWFLbX/Ts6BOztRNjqtayZ1HD+3hzFLKfKKPQU+b4 RBmQ== MIME-Version: 1.0 X-Received: by 10.140.104.195 with SMTP id a61mr30842888qgf.102.1401559591691; Sat, 31 May 2014 11:06:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 31 May 2014 11:06:31 -0700 (PDT) In-Reply-To: References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> Date: Sat, 31 May 2014 11:06:31 -0700 X-Google-Sender-Auth: 7cupQ3Seyo86cRM5XTFyg5lpOFA Message-ID: Subject: Re: TRIM on SD cards From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 18:06:33 -0000 On 31 May 2014 10:49, Warner Losh wrote: > > On May 31, 2014, at 11:31 AM, Adrian Chadd wrote: > >> On 31 May 2014 09:45, Warner Losh wrote: >> >>> One of the things that I did for images years ago was compressed tar fi= les. There was so much variation between CF makers and at the time CF geome= try was important to the BIOS, so we made our images as tar balls. We then = had a makefile target that would create a partition on the card that was ac= tually there, put boot blocks on it then extract the tarball=E2=80=A6 I ne= ver have liked DD for creating images, even when LBAs ruled the day because= you=E2=80=99d always have to grow/shrink the FS afterwards. The only advan= tage it had was it was easy=E2=80=A6 Perhaps it is time to go back to that = model? The alternative that wouldn=E2=80=99t suck too bad would be to creat= e variable sized images based on how much data was actually present and ens= ure there are no holes (or minimal holes) in the filesystem. >>> >>> Hmmm, if we know WHAT filesystem we=E2=80=99re dealing with, then we co= uld perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it= knows are free, which would be a useful, data-driven approach that could e= nsure we start out with a nicely trimmed FS. Given the vagaries of the diff= erent kinds of TRIMs and the various translation layers we have, that might= be the most robust. >> >> Having makefs spit this out would be rather useful. > > I=E2=80=99m not sure it would be. Any writes to the FS after you create i= t would invalidate the list=E2=80=A6 Far easier to have fsck do it for you = any time you need it... Sure, but it'd be part of a larger scale image creation and writing tool. That way you could ship images that had the sparseness bits in them and the tool + growfs can TRIM as appropriate on the installing media. -a From owner-freebsd-arm@FreeBSD.ORG Sat May 31 18:44:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A820A56 for ; Sat, 31 May 2014 18:44:35 +0000 (UTC) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45044229D for ; Sat, 31 May 2014 18:44:35 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id up15so2837547pbc.2 for ; Sat, 31 May 2014 11:44:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=42UQzNBquDw5/fbN0pqc/KphYT7eN7PLB5fISmTlfaM=; b=eiJRXnOnfyio+vOdDWr9KVKpjXf/EHFclFmWZhghQYpAfC0Ik+7Ac+03yhWW39rkdM 07LSKiMwG3GYlpYRpYryOKLe9ZGvbEJse4spThuazV/Fa7Vu2TNjCSr6ktvqURx3jVHf gw1NIMNMoQCDbFRzXUm9uW7JIPrpNeygWPlT7S5MsIIrigZXBBcGQd2wc6tlkylfWyGq pwSk/IxBPzEQXgzQyiprrr2W0Tf+KFFCI2bqQPz7b5qMLUrdUndzR9wP/dBgEE/VqPq8 ykEv7dQJU8LTFLUmlI5VYg+xicvZ1TtGTQRfPHd0Vvw25+9fPPZkc3Ex2i4HS+enHeKu qayA== X-Gm-Message-State: ALoCoQnkhRvA0H1wgUs9VxShQtCExyIUo+xQG6wOVtbA45Am6DmXvKSVB1lvtPTMUsixLrgXBdzL X-Received: by 10.69.25.105 with SMTP id ip9mr28432202pbd.145.1401561874734; Sat, 31 May 2014 11:44:34 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id mt1sm12437464pbb.31.2014.05.31.11.44.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 11:44:34 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: Date: Sat, 31 May 2014 12:44:35 -0600 Message-Id: <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 18:44:35 -0000 --Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 12:06 PM, Adrian Chadd wrote: > On 31 May 2014 10:49, Warner Losh wrote: >>=20 >> On May 31, 2014, at 11:31 AM, Adrian Chadd = wrote: >>=20 >>> On 31 May 2014 09:45, Warner Losh wrote: >>>=20 >>>> One of the things that I did for images years ago was compressed = tar files. There was so much variation between CF makers and at the time = CF geometry was important to the BIOS, so we made our images as tar = balls. We then had a makefile target that would create a partition on = the card that was actually there, put boot blocks on it then extract the = tarball=85 I never have liked DD for creating images, even when LBAs = ruled the day because you=92d always have to grow/shrink the FS = afterwards. The only advantage it had was it was easy=85 Perhaps it is = time to go back to that model? The alternative that wouldn=92t suck too = bad would be to create variable sized images based on how much data was = actually present and ensure there are no holes (or minimal holes) in the = filesystem. >>>>=20 >>>> Hmmm, if we know WHAT filesystem we=92re dealing with, then we = could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks = that it knows are free, which would be a useful, data-driven approach = that could ensure we start out with a nicely trimmed FS. Given the = vagaries of the different kinds of TRIMs and the various translation = layers we have, that might be the most robust. >>>=20 >>> Having makefs spit this out would be rather useful. >>=20 >> I=92m not sure it would be. Any writes to the FS after you create it = would invalidate the list=85 Far easier to have fsck do it for you any = time you need it... >=20 > Sure, but it'd be part of a larger scale image creation and writing > tool. That way you could ship images that had the sparseness bits in > them and the tool + growfs can TRIM as appropriate on the installing > media. Except why have an extra step when all that metadata is encoded in the = filesystem itself? Warner --Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTiiMTAAoJEGwc0Sh9sBEA8AQP/RiQ71lHsceYFND/HoV9uBRf vfYHXVMZHrO6JYG0DCam81jhPpTaRwRHPw9NdWRwOLrjHiwPB/amTmIxfMifpu1R zTbS2MMJqZUn6/lL0nQy4eUeOD6Uo7F1t09G5dMJONFAFD0sr9QgSVeHmz+TgkFf 9sjzQVP6NPya3tCrXnhNIXn2sAIcycPXPc1j+7c9WSi1042KdckDxDcBkR4OB2Vv Kf5P5ODf4/5uMzB6PnC8So5oDszKVwIFrLzfg2LUWPZnQ/eiPR/Nc8+IpcTaOEd6 TlzkOA4chLEYxo5W1+Yj6wUsMKDneUFJtv5po3eCTNtn76bgeIo5vOMffsyN96VQ SeVLH/XYT/7oRhycrUB3Fbisj7m+iOUsxhjn9N95R+0JLaJ2ZbgWSBH2gqZuquCf 6Is6oGIGVgUzZ8a+GSH62tYjARLPgltpth0YMW+UbWjwnY6w1JZgAvJtPjSu2Dc0 SzyXZWZyv2syYX/d0f71Ah+Ngi93UWaws8bhEQ5ya/WUY0o/jYYxA8jOldejldbX vE+qQg/mEeoP7Mk5XS/jD+5C0z6fAuq6EZ//Q0HqtXc85l79+AxIEp5hfL/bmKve KV6fdus6aDwFUeLCCmshSTzQ1TnnGQvOeJfIL6dNkyjxg01+0vL6cpcbT1/jWTcv TDh0Z/+ntnF5j96xs1qj =+wkZ -----END PGP SIGNATURE----- --Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8-- From owner-freebsd-arm@FreeBSD.ORG Sat May 31 18:58:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C04DCD07 for ; Sat, 31 May 2014 18:58:18 +0000 (UTC) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A71323E0 for ; Sat, 31 May 2014 18:58:18 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id md12so2865284pbc.1 for ; Sat, 31 May 2014 11:58:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zBtqUxsjfhUkEJTZXp2tGGWaTQ6f0pZMcIraSw4gm98=; b=LkrCP/J22Xggv61xnAgL+BjB1qRVqiaocZlN0Cehsj/w+7gymvaaUfA9OetW9bL64e pDvTRzX0P0v+K9wtZ0242ARS+Ppddmbx3THGlfLphmLJRdEq7fILhCKh0+/l6eH8mezH wirHGBV35Xb3MnGqRGI9aLZKa+psgPz+amWdblb6xc3qltcnx3bAUqwxzpbWMZQXQhHe dkdshtmblzJ0iejl3xB321rkfNSDLCq5gKriAIY5/k0B5Z0j5NqhDlZn78Syv0pkqOUD W7C1CcA1RM0xzdkWExsAOk5T4tprK/u2aV2ZW0xMu7NuVcgsIj/g6ULyf5gvXDNYRKpH qG/A== X-Gm-Message-State: ALoCoQnJz+SSM7evFfjLnZ5tZAZfZvf/n8sHYREXdisuOYzGa923TYQWIWKwh04j9aPoiSfB2AQE X-Received: by 10.66.66.135 with SMTP id f7mr28835349pat.22.1401562302517; Sat, 31 May 2014 11:51:42 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id og3sm12438629pbc.48.2014.05.31.11.51.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 11:51:41 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_283F729B-7F4B-4D0E-B4A0-C5CAB0496CBD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> Date: Sat, 31 May 2014 12:51:42 -0600 Message-Id: References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 18:58:18 -0000 --Apple-Mail=_283F729B-7F4B-4D0E-B4A0-C5CAB0496CBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 12:44 PM, Warner Losh wrote: >=20 > On May 31, 2014, at 12:06 PM, Adrian Chadd wrote: >=20 >> On 31 May 2014 10:49, Warner Losh wrote: >>>=20 >>> On May 31, 2014, at 11:31 AM, Adrian Chadd = wrote: >>>=20 >>>> On 31 May 2014 09:45, Warner Losh wrote: >>>>=20 >>>>> One of the things that I did for images years ago was compressed = tar files. There was so much variation between CF makers and at the time = CF geometry was important to the BIOS, so we made our images as tar = balls. We then had a makefile target that would create a partition on = the card that was actually there, put boot blocks on it then extract the = tarball=85 I never have liked DD for creating images, even when LBAs = ruled the day because you=92d always have to grow/shrink the FS = afterwards. The only advantage it had was it was easy=85 Perhaps it is = time to go back to that model? The alternative that wouldn=92t suck too = bad would be to create variable sized images based on how much data was = actually present and ensure there are no holes (or minimal holes) in the = filesystem. >>>>>=20 >>>>> Hmmm, if we know WHAT filesystem we=92re dealing with, then we = could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks = that it knows are free, which would be a useful, data-driven approach = that could ensure we start out with a nicely trimmed FS. Given the = vagaries of the different kinds of TRIMs and the various translation = layers we have, that might be the most robust. >>>>=20 >>>> Having makefs spit this out would be rather useful. >>>=20 >>> I=92m not sure it would be. Any writes to the FS after you create it = would invalidate the list=85 Far easier to have fsck do it for you any = time you need it... >>=20 >> Sure, but it'd be part of a larger scale image creation and writing >> tool. That way you could ship images that had the sparseness bits in >> them and the tool + growfs can TRIM as appropriate on the installing >> media. >=20 > Except why have an extra step when all that metadata is encoded in the = filesystem itself? looks like fsck already has a -E flag: -E Clear unallocated blocks, notifying the underlying device = that they are not used and that their contents may be discarded. = This is useful for filesystems which have been mounted on = systems without TRIM support, or with TRIM support disabled, as = well as filesystems which have been copied from one device to = another. So maybe the answer =91it is already there=92 might be a better reason = :) Bernd, can you try this on your arm box to see what it does for your = system? Warner --Apple-Mail=_283F729B-7F4B-4D0E-B4A0-C5CAB0496CBD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTiiS/AAoJEGwc0Sh9sBEAA20P/j9RBKiDQ5ifi5rU7LtUkxxa MZ5WW9QMUfOriy8JHvkCFnTMahO8/ukWmGE38SGw1+SHpleXZ5wA0gLW80ykoBaP GiE/329e5oz6PQWeUXHXK7pj3ye3IM1weSxgsnM6qnCCgvrLpKcQcdVz6TjjyLG1 XmrlILCTUegDFkL0GhsXAW3o22AJlDkRKVoIjeqhVwgTQs+e+pXm4R6A6e/uBxTI poV0UyoTcoj9FolzdyPQbfU74uOE/qyojFelbHfLdNGrNLkfmm1mQMELrVP0Uq5R kHnhH6ZWqu5gCa1/N5To/JlXftPCPrh933wsB3KvWGmv7exbbR8PSkzYR53oBFd9 GodZjvXdNxeJXnXUCgkhVxPpB4ixQctT1lHwyrJX5rjKkcktJQQhmKCOkMicjxyS z4fVaUDmSKTlKvZAwGllda8gu7ipnyqk6pyWnlOcVJ+uLXgSnqjyNuf+bptkkY/J xyxz3Aa00zzb6TFhhecsB1wfGN7LY6ogh5E03zpT9WO6UquLTNQC7G4cXZpOzrfo eXRx+KMNC2Jn+cOO6VhK1wIttG2G294pBsLgmwcPLUMqmBXJBqxrIYudPHWbevBa BepJgo5rJlYKYWx2nhzEF9zLFs/lrIO8c2HqEpCagkQLUyfSxncnISwqkxjzOLvo Zl/pphVYXS3cELNrMhhc =UNSX -----END PGP SIGNATURE----- --Apple-Mail=_283F729B-7F4B-4D0E-B4A0-C5CAB0496CBD-- From owner-freebsd-arm@FreeBSD.ORG Sat May 31 19:23:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94ACF2D2; Sat, 31 May 2014 19:23:43 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CC8925BB; Sat, 31 May 2014 19:23:43 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4VJNW8Z087344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 12:23:32 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4VJNWq4087343; Sat, 31 May 2014 12:23:32 -0700 (PDT) (envelope-from jmg) Date: Sat, 31 May 2014 12:23:32 -0700 From: John-Mark Gurney To: Jim Thompson Subject: Re: TRIM on SD cards Message-ID: <20140531192332.GM43976@funkthat.com> Mail-Followup-To: Jim Thompson , Warner Losh , "freebsd-arm@freebsd.org" , Bernd Walter , "ticso@cicely.de" , Ian Lepore References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531044152.GK43976@funkthat.com> <54DF962E-4A84-4309-ABCE-DB2DA12DAE0A@netgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DF962E-4A84-4309-ABCE-DB2DA12DAE0A@netgate.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 31 May 2014 12:23:33 -0700 (PDT) Cc: Ian Lepore , "freebsd-arm@freebsd.org" , Bernd Walter , "ticso@cicely.de" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 19:23:43 -0000 Jim Thompson wrote this message on Sat, May 31, 2014 at 00:37 -0500: > > On May 30, 2014, at 11:41 PM, John-Mark Gurney wrote: > > > > Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: > >>> On May 30, 2014, at 9:00 PM, Ian Lepore wrote: > >>> > >>>> On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: > >>>> It seems SD cards support a delete command, which FreeBSD supports > >>>> with the mmcsd driver. > >>>> newfs and tunefs support TRIM in that new filesystems are trim'ed > >>>> and the filesystems automatically trim free'ed blocks. > >>>> So far so good. > >>>> On the practical side with SD based ARM you don't write filesystems > >>>> directly via mmcsd. > >>>> We either create an image, which id dd'ed onto SD or in some cases > >>>> we use an USB SD drive. > >>>> With dd the unused blocks are written as well, which effectively > >>>> hurts by writing data. > >>>> Is there some kind of dd, which actually don't write zero blocks, > >>>> or even better does a trim call for them? > >>> > >>> I don't think dd can safely do that. If it finds a block of zeroes on > >>> the input side, how does it know it's okay to do a DELETE for those > >>> (which sets the block to all-bits-on on most flash media). Maybe it's > >>> important for that data to really be zero; dd doesn't know. > >>> > >>> That's one of the reasons why I recently mentioned a desire for > >>> a /dev/ones to go with /dev/zero as a way of pre-init'ing an image to be > >>> more friendly to flash media. The idea was not well-received by other > >>> freebsd folks. > >>> > >>> Maybe if the image was sparse, dd could tell the difference between an > >>> missing segment and a segment populated with zeroes and do a DELETE for > >>> missing data. I never do the image creation thing, I mostly tend to use > >>> nfsroot and at $work we use tar to copy files to sdcards with a usb > >>> burner rather than preformatting images into files. > >> > >> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent blocks are, by definition, all zeros. The only time there?s a problem is when the TRIM doesn?t really TRIM? You don?t need it to be sparse at all. Zeros are zeros. > > > > Are you sure? TRIM'd space may or may not have a defined value to > > return upon read, and what happens if one of those blocks of zeros > > belongs to a file that needs those zeros to be zero? > > > > There are bits that declare if the drive returns zeros or not, so this > > would only be safe on those drives.. > > Since time immortal (23:59:59 31 Dec 1969), or at least 1978 or so, the file system has supported the idea of sparse files. Yep, easier: $ truncate -s 2048t /tmp/largefile $ ls -sl /tmp/largefile 128 -rw-r--r-- 1 jmg wheel 2251799813685248 May 31 12:19 /tmp/largefile [...] > Unix doesn't zero the blocks on the free list. This is the same. TRIM just tells the drive that the block is free. The file system already knows. > > The above will fail if foo exists and is at least 1MB in size. Sorry. We are talking about two different thing... I'm talking about what the drive does, and you, what the FS does.. There are no guarantees that zero blocks in an FS will not be pointed to by a file... I just realized that parts of the FS metadata such as the block usage bitmap could be zero, and there for trimmed by autodetecting zeros... But doesn't most flash adaption layers auto detect blocks of zeros, and not write them anyways? and instead write a market note that this is all zeros? If that is true, than detecting blocks of zero and trimming o that just makes the software more complicated... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat May 31 19:45:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBA9A706 for ; Sat, 31 May 2014 19:45:23 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 923CF26F6 for ; Sat, 31 May 2014 19:45:23 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4VJjLck087685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 12:45:21 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4VJjKkY087684; Sat, 31 May 2014 12:45:20 -0700 (PDT) (envelope-from jmg) Date: Sat, 31 May 2014 12:45:20 -0700 From: John-Mark Gurney To: Tim Kientzle Subject: Re: TRIM on SD cards Message-ID: <20140531194520.GO43976@funkthat.com> Mail-Followup-To: Tim Kientzle , Warner Losh , freebsd-arm References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <931C85D3-3D43-461E-9A78-BFB4451E9342@kientzle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <931C85D3-3D43-461E-9A78-BFB4451E9342@kientzle.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 31 May 2014 12:45:21 -0700 (PDT) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 19:45:23 -0000 Tim Kientzle wrote this message on Sat, May 31, 2014 at 10:25 -0700: > On May 31, 2014, at 9:45 AM, Warner Losh wrote: > > > I never have liked DD for creating images, even when LBAs ruled the day because you?d always have to grow/shrink the FS afterwards. > > A few of us have been experimenting with having > growfs run automatically on first boot. Seems to work okay, > it just requires a couple of iterations to figure out the "proper" > minimal FS size to start with. > > If the FS is minimally sized, then there aren't many empty > blocks to worry about. > > The big advantage of DD images is that there are plentiful > tools for Windows, Mac, etc, that can splat them onto a > USB stick or SD card. I'm close to committing my modified growfs that will run once on boot when enabled... I even wrote a manpage for it... Just when I posted it for review on -rc, I didn't get any... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat May 31 19:49:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E78A7EC; Sat, 31 May 2014 19:49:29 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B3E52716; Sat, 31 May 2014 19:49:29 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id j15so682942qaq.13 for ; Sat, 31 May 2014 12:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3gAa6xGOKAuBeN5rv/HOaSl/EWWX5CGRHKAH+Eq9dNg=; b=MQuE6Px24NyUtGEXB5ZMpEfajohU1NuDo2eMk5L/6ReFwFXdvN/WE/vbtfRjedL+Lm 1aKj3n5J5U/wi4MbQjj2CMw4IlLiNq32pbl3ws9Pge9kyBEoJV53P4qvsN95DtNcdi5h VY1qjdDzKk9Ga7I3d1u4odhZYNZzHLkZPnAnSF/StEQNV2EWZJB2DqS1obA3hGV9Iv7j VcgRTYSldRa1e9TBQglAMB1tyZ+6dM7C0tsUepDFnuyItM7/nMZtg6Ca6OrjGV3OObOO NSF1p1hIkDUo1fMgoIrCoZnAERZ/91NAulp+/Yuw/YGVMjP53a1dxz6QvPPiFt7ghVl5 HrNQ== MIME-Version: 1.0 X-Received: by 10.140.22.209 with SMTP id 75mr32077587qgn.4.1401565768265; Sat, 31 May 2014 12:49:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 31 May 2014 12:49:28 -0700 (PDT) In-Reply-To: <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> Date: Sat, 31 May 2014 12:49:28 -0700 X-Google-Sender-Auth: lCKdPJd0qScLRcz-YrHyeg_oaJ0 Message-ID: Subject: Re: TRIM on SD cards From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 19:49:29 -0000 On 31 May 2014 11:44, Warner Losh wrote: > > On May 31, 2014, at 12:06 PM, Adrian Chadd wrote: > >> On 31 May 2014 10:49, Warner Losh wrote: >>> >>> On May 31, 2014, at 11:31 AM, Adrian Chadd wrote: >>> >>>> On 31 May 2014 09:45, Warner Losh wrote: >>>> >>>>> One of the things that I did for images years ago was compressed tar = files. There was so much variation between CF makers and at the time CF geo= metry was important to the BIOS, so we made our images as tar balls. We the= n had a makefile target that would create a partition on the card that was = actually there, put boot blocks on it then extract the tarball=E2=80=A6 I = never have liked DD for creating images, even when LBAs ruled the day becau= se you=E2=80=99d always have to grow/shrink the FS afterwards. The only adv= antage it had was it was easy=E2=80=A6 Perhaps it is time to go back to tha= t model? The alternative that wouldn=E2=80=99t suck too bad would be to cre= ate variable sized images based on how much data was actually present and e= nsure there are no holes (or minimal holes) in the filesystem. >>>>> >>>>> Hmmm, if we know WHAT filesystem we=E2=80=99re dealing with, then we = could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that = it knows are free, which would be a useful, data-driven approach that could= ensure we start out with a nicely trimmed FS. Given the vagaries of the di= fferent kinds of TRIMs and the various translation layers we have, that mig= ht be the most robust. >>>> >>>> Having makefs spit this out would be rather useful. >>> >>> I=E2=80=99m not sure it would be. Any writes to the FS after you create= it would invalidate the list=E2=80=A6 Far easier to have fsck do it for yo= u any time you need it... >> >> Sure, but it'd be part of a larger scale image creation and writing >> tool. That way you could ship images that had the sparseness bits in >> them and the tool + growfs can TRIM as appropriate on the installing >> media. > > Except why have an extra step when all that metadata is encoded in the fi= lesystem itself? Cool, so how do we do this? Teach a dd like tool about FFS? :P -a From owner-freebsd-arm@FreeBSD.ORG Sat May 31 19:57:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D03AA0D; Sat, 31 May 2014 19:57:09 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3264A27E6; Sat, 31 May 2014 19:57:08 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4VJuxGc087889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 12:56:59 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4VJux24087888; Sat, 31 May 2014 12:56:59 -0700 (PDT) (envelope-from jmg) Date: Sat, 31 May 2014 12:56:59 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: TRIM on SD cards Message-ID: <20140531195659.GP43976@funkthat.com> Mail-Followup-To: Warner Losh , Adrian Chadd , "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de, Ian Lepore References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 31 May 2014 12:56:59 -0700 (PDT) Cc: Bernd Walter , "freebsd-arm@freebsd.org" , Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 19:57:09 -0000 Warner Losh wrote this message on Sat, May 31, 2014 at 12:51 -0600: > > On May 31, 2014, at 12:44 PM, Warner Losh wrote: > > > > > On May 31, 2014, at 12:06 PM, Adrian Chadd wrote: > > > >> On 31 May 2014 10:49, Warner Losh wrote: > >>> > >>> On May 31, 2014, at 11:31 AM, Adrian Chadd wrote: > >>> > >>>> On 31 May 2014 09:45, Warner Losh wrote: > >>>> > >>>>> One of the things that I did for images years ago was compressed tar files. There was so much variation between CF makers and at the time CF geometry was important to the BIOS, so we made our images as tar balls. We then had a makefile target that would create a partition on the card that was actually there, put boot blocks on it then extract the tarball? I never have liked DD for creating images, even when LBAs ruled the day because you?d always have to grow/shrink the FS afterwards. The only advantage it had was it was easy? Perhaps it is time to go back to that model? The alternative that wouldn?t suck too bad would be to create variable sized images based on how much data was actually present and ensure there are no holes (or minimal holes) in the filesystem. > >>>>> > >>>>> Hmmm, if we know WHAT filesystem we?re dealing with, then we could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it knows are free, which would be a useful, data-driven approach that could ensure we start out with a nicely trimmed FS. Given the vagaries of the different kinds of TRIMs and the various translation layers we have, that might be the most robust. > >>>> > >>>> Having makefs spit this out would be rather useful. > >>> > >>> I?m not sure it would be. Any writes to the FS after you create it would invalidate the list? Far easier to have fsck do it for you any time you need it... > >> > >> Sure, but it'd be part of a larger scale image creation and writing > >> tool. That way you could ship images that had the sparseness bits in > >> them and the tool + growfs can TRIM as appropriate on the installing > >> media. > > > > Except why have an extra step when all that metadata is encoded in the filesystem itself? > > looks like fsck already has a -E flag: > > -E Clear unallocated blocks, notifying the underlying device that > they are not used and that their contents may be discarded. This > is useful for filesystems which have been mounted on systems > without TRIM support, or with TRIM support disabled, as well as > filesystems which have been copied from one device to another. > > So maybe the answer ?it is already there? might be a better reason :) > > Bernd, can you try this on your arm box to see what it does for your system? Hmm... sounds like another useful command to run on first boot, though right now it's disabled by default... makefs doesn't support setting the flag... I'll fix makefs, as I have some other minor changes sitting in my tree... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat May 31 21:16:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5529BB46 for ; Sat, 31 May 2014 21:16:05 +0000 (UTC) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D6552E40 for ; Sat, 31 May 2014 21:16:04 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id v10so2109844pde.23 for ; Sat, 31 May 2014 14:16:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=I1xlZouQZGVGOA0Aetjj04N4eXb+kINB/heP7RKpxH8=; b=NUovmRPNJra5efRvxmaBMlVuyKEAkn1hq/HXBmyYb92dqJ5OyltzFx+VtLnR6GOrFe XjtQiGpY4k7tous2fYA0cFD/2xbY7E9E9SE+jIi0gZIaYjvde61NaZoQeVjGbm/OEE/N Nv1mEtM4G63UHg5NiWxaLKlzMrMxogRLrAynhRO8SowSXn0XWVIO0aWUntS6HoF1sGve lvKhrUs4mKHx8ufJGri2bhOToVScgWHNVqIqY41M1TSphwNNolkzTVHw8JSOusqCv5bQ 6X1E6CtTlJ/YmDif8wSsHPLMDiTeQ9TScuEvc1eKo3BZDfpUJ9cdpSDmaCK7lWbx/Y/K Rsmg== X-Gm-Message-State: ALoCoQnX8rCu9R/cNqkXIFH7MAs5L3lhuKjEXAZeJZrH2mzI6F6oVqmfdFHnXeap1qYKcXnG48TB X-Received: by 10.68.240.5 with SMTP id vw5mr28537522pbc.113.1401570550879; Sat, 31 May 2014 14:09:10 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id wq10sm38842514pac.24.2014.05.31.14.09.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 14:09:10 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: <20140531195659.GP43976@funkthat.com> Date: Sat, 31 May 2014 15:09:11 -0600 Message-Id: <72D59B65-09FF-4272-A795-99DC94970F7D@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> <20140531195659.GP43976@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.2) Cc: Bernd Walter , "freebsd-arm@freebsd.org" , Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 21:16:05 -0000 --Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 1:56 PM, John-Mark Gurney wrote: > Warner Losh wrote this message on Sat, May 31, 2014 at 12:51 -0600: >>=20 >> On May 31, 2014, at 12:44 PM, Warner Losh wrote: >>=20 >>>=20 >>> On May 31, 2014, at 12:06 PM, Adrian Chadd = wrote: >>>=20 >>>> On 31 May 2014 10:49, Warner Losh wrote: >>>>>=20 >>>>> On May 31, 2014, at 11:31 AM, Adrian Chadd = wrote: >>>>>=20 >>>>>> On 31 May 2014 09:45, Warner Losh wrote: >>>>>>=20 >>>>>>> One of the things that I did for images years ago was compressed = tar files. There was so much variation between CF makers and at the time = CF geometry was important to the BIOS, so we made our images as tar = balls. We then had a makefile target that would create a partition on = the card that was actually there, put boot blocks on it then extract the = tarball? I never have liked DD for creating images, even when LBAs = ruled the day because you?d always have to grow/shrink the FS = afterwards. The only advantage it had was it was easy? Perhaps it is = time to go back to that model? The alternative that wouldn?t suck too = bad would be to create variable sized images based on how much data was = actually present and ensure there are no holes (or minimal holes) in the = filesystem. >>>>>>>=20 >>>>>>> Hmmm, if we know WHAT filesystem we?re dealing with, then we = could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks = that it knows are free, which would be a useful, data-driven approach = that could ensure we start out with a nicely trimmed FS. Given the = vagaries of the different kinds of TRIMs and the various translation = layers we have, that might be the most robust. >>>>>>=20 >>>>>> Having makefs spit this out would be rather useful. >>>>>=20 >>>>> I?m not sure it would be. Any writes to the FS after you create it = would invalidate the list? Far easier to have fsck do it for you any = time you need it... >>>>=20 >>>> Sure, but it'd be part of a larger scale image creation and writing >>>> tool. That way you could ship images that had the sparseness bits = in >>>> them and the tool + growfs can TRIM as appropriate on the = installing >>>> media. >>>=20 >>> Except why have an extra step when all that metadata is encoded in = the filesystem itself? >>=20 >> looks like fsck already has a -E flag: >>=20 >> -E Clear unallocated blocks, notifying the underlying device = that >> they are not used and that their contents may be = discarded. This >> is useful for filesystems which have been mounted on = systems >> without TRIM support, or with TRIM support disabled, as = well as >> filesystems which have been copied from one device to = another. >>=20 >> So maybe the answer ?it is already there? might be a better reason :) >>=20 >> Bernd, can you try this on your arm box to see what it does for your = system? >=20 > Hmm... sounds like another useful command to run on first boot, though > right now it's disabled by default... >=20 > makefs doesn't support setting the flag... I'll fix makefs, as I have > some other minor changes sitting in my tree... Putting it in makefs is approximately useless=85 Warner --Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTikT4AAoJEGwc0Sh9sBEArjEP/j8Q+NoPJ+33zx5HBSCcwueN Wqpetzp96DXyO29wdYuuH7xlwO3x78KM68phWXkjulHVx1NuDFT4CWmF5f/QNK7J Z+Cx5OC7tsiVFVB5ctkK3R0BbY/KwAKHcYSswlw6RTqLCCc23gUJs24IiScYCvkT 4ZoaaOWq3x/lTvOT0/JPOa3BpjP6tg1t3TwDAT+zSH0CzTaDgN3R8GY5kVDsYcQU 9pJTBHnYKxRQKBJWsrqmhUkTzucGZL4Y4POZVtxvPEv0okbKhT6GMMwk/njrfNSb Z0U1HnuEzz44iXzIo1app/81x2bDYmH0rUwO435YgSnD6rizKAwe0lg9sgvrIdSj YLYYUmlaSgpAncV+fsFSt3ezeUF9aYnnVW8749qhUgAS1a23aHtE7fRV2mQdBB1w JeAM/lbCfvgFP+HQWJaiHfl7TzK8NzRfWpOd0CbBNU0VF2Te+GX+mZw4/mYk1sMs t759oTznlzz1T2RjqU2KpSfkmYvusiu1qXf/4ZKtHXp2kBijbfoZQNlAhNJVPCLy Zr1hRQDQdHBlZzGcLSY8jc28A9OycvwlabcmWqmcNEdHSXD6cShRbX8SPfQ3OIUh YUI0blAuSeE3pMTAk/0MQ/kR66/+ak7QhXQscgu44m8+8PBIJHwPiABL6GJ4Zsq5 nwkQSlUAMK20VtFps8RC =CbPY -----END PGP SIGNATURE----- --Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79-- From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 00:26:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88FAD8D5; Sun, 1 Jun 2014 00:26:15 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C3B72B55; Sun, 1 Jun 2014 00:26:14 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s510Q4AV091250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 17:26:04 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s510Q3rW091249; Sat, 31 May 2014 17:26:03 -0700 (PDT) (envelope-from jmg) Date: Sat, 31 May 2014 17:26:03 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: TRIM on SD cards Message-ID: <20140601002603.GQ43976@funkthat.com> Mail-Followup-To: Warner Losh , Adrian Chadd , "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de, Ian Lepore References: <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> <20140531195659.GP43976@funkthat.com> <72D59B65-09FF-4272-A795-99DC94970F7D@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72D59B65-09FF-4272-A795-99DC94970F7D@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 31 May 2014 17:26:04 -0700 (PDT) Cc: Bernd Walter , "freebsd-arm@freebsd.org" , Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 00:26:15 -0000 Warner Losh wrote this message on Sat, May 31, 2014 at 15:09 -0600: > > On May 31, 2014, at 1:56 PM, John-Mark Gurney wrote: > > > Warner Losh wrote this message on Sat, May 31, 2014 at 12:51 -0600: > >> > >> On May 31, 2014, at 12:44 PM, Warner Losh wrote: > >> > >>> > >>> On May 31, 2014, at 12:06 PM, Adrian Chadd wrote: > >>> > >>>> On 31 May 2014 10:49, Warner Losh wrote: > >>>>> > >>>>> On May 31, 2014, at 11:31 AM, Adrian Chadd wrote: > >>>>> > >>>>>> On 31 May 2014 09:45, Warner Losh wrote: > >>>>>> > >>>>>>> One of the things that I did for images years ago was compressed tar files. There was so much variation between CF makers and at the time CF geometry was important to the BIOS, so we made our images as tar balls. We then had a makefile target that would create a partition on the card that was actually there, put boot blocks on it then extract the tarball? I never have liked DD for creating images, even when LBAs ruled the day because you?d always have to grow/shrink the FS afterwards. The only advantage it had was it was easy? Perhaps it is time to go back to that model? The alternative that wouldn?t suck too bad would be to create variable sized images based on how much data was actually present and ensure there are no holes (or minimal holes) in the filesystem. > >>>>>>> > >>>>>>> Hmmm, if we know WHAT filesystem we?re dealing with, then we could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it knows are free, which would be a useful, data-driven approach that could ensure we start out with a nicely trimmed FS. Given the vagaries of the different kinds of TRIMs and the various translation layers we have, that might be the most robust. > >>>>>> > >>>>>> Having makefs spit this out would be rather useful. > >>>>> > >>>>> I?m not sure it would be. Any writes to the FS after you create it would invalidate the list? Far easier to have fsck do it for you any time you need it... > >>>> > >>>> Sure, but it'd be part of a larger scale image creation and writing > >>>> tool. That way you could ship images that had the sparseness bits in > >>>> them and the tool + growfs can TRIM as appropriate on the installing > >>>> media. > >>> > >>> Except why have an extra step when all that metadata is encoded in the filesystem itself? > >> > >> looks like fsck already has a -E flag: > >> > >> -E Clear unallocated blocks, notifying the underlying device that > >> they are not used and that their contents may be discarded. This > >> is useful for filesystems which have been mounted on systems > >> without TRIM support, or with TRIM support disabled, as well as > >> filesystems which have been copied from one device to another. > >> > >> So maybe the answer ?it is already there? might be a better reason :) > >> > >> Bernd, can you try this on your arm box to see what it does for your system? > > > > Hmm... sounds like another useful command to run on first boot, though > > right now it's disabled by default... > > > > makefs doesn't support setting the flag... I'll fix makefs, as I have > > some other minor changes sitting in my tree... > > Putting it in makefs is approximately useless? How else can you use makefs to generate a FS that will use trim if makefs doesn't set the _TRIM flag? Or do you mean you can set it on a live system w/ tunefs? If so, then why don't we remove the label option, since that too can be set by tunefs... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 00:43:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D861CB41; Sun, 1 Jun 2014 00:43:44 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C0662C7D; Sun, 1 Jun 2014 00:43:44 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s510hRhb022226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 1 Jun 2014 02:43:27 +0200 (CEST) (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 s510hBf4069802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jun 2014 02:43:11 +0200 (CEST) (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 s510hBIl054804; Sun, 1 Jun 2014 02:43:11 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s510hBwX054803; Sun, 1 Jun 2014 02:43:11 +0200 (CEST) (envelope-from ticso) Date: Sun, 1 Jun 2014 02:43:11 +0200 From: Bernd Walter To: Warner Losh Subject: Re: TRIM on SD cards Message-ID: <20140601004311.GB54731@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> 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=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Bernd Walter , "freebsd-arm@freebsd.org" , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 00:43:44 -0000 On Sat, May 31, 2014 at 12:51:42PM -0600, Warner Losh wrote: > > On May 31, 2014, at 12:44 PM, Warner Losh wrote: > > > > > On May 31, 2014, at 12:06 PM, Adrian Chadd wrote: > > > >> On 31 May 2014 10:49, Warner Losh wrote: > >>> > >>> On May 31, 2014, at 11:31 AM, Adrian Chadd wrote: > >>> > >>>> On 31 May 2014 09:45, Warner Losh wrote: > >>>> > >>>>> One of the things that I did for images years ago was compressed tar files. There was so much variation between CF makers and at the time CF geometry was important to the BIOS, so we made our images as tar balls. We then had a makefile target that would create a partition on the card that was actually there, put boot blocks on it then extract the tarball? I never have liked DD for creating images, even when LBAs ruled the day because you?d always have to grow/shrink the FS afterwards. The only advantage it had was it was easy? Perhaps it is time to go back to that model? The alternative that wouldn?t suck too bad would be to create variable sized images based on how much data was actually present and ensure there are no holes (or minimal holes) in the filesystem. > >>>>> > >>>>> Hmmm, if we know WHAT filesystem we?re dealing with, then we could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it knows are free, which would be a useful, data-driven approach that could ensure we start out with a nicely trimmed FS. Given the vagaries of the different kinds of TRIMs and the various translation layers we have, that might be the most robust. > >>>> > >>>> Having makefs spit this out would be rather useful. > >>> > >>> I?m not sure it would be. Any writes to the FS after you create it would invalidate the list? Far easier to have fsck do it for you any time you need it... > >> > >> Sure, but it'd be part of a larger scale image creation and writing > >> tool. That way you could ship images that had the sparseness bits in > >> them and the tool + growfs can TRIM as appropriate on the installing > >> media. > > > > Except why have an extra step when all that metadata is encoded in the filesystem itself? > > looks like fsck already has a -E flag: > > -E Clear unallocated blocks, notifying the underlying device that > they are not used and that their contents may be discarded. This > is useful for filesystems which have been mounted on systems > without TRIM support, or with TRIM support disabled, as well as > filesystems which have been copied from one device to another. > > So maybe the answer ?it is already there? might be a better reason :) > > Bernd, can you try this on your arm box to see what it does for your system? Oh damn - I should have looked into the fsck manpage. This is great. I've put it on my TODO list for next week. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 02:23:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA54DBCE; Sun, 1 Jun 2014 02:23:36 +0000 (UTC) Received: from remote.thehowies.com (50-197-91-217-static.hfc.comcastbusiness.net [50.197.91.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "remote.thehowies.com", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7656D233C; Sun, 1 Jun 2014 02:23:35 +0000 (UTC) Received: from PRIMARY.thehowies.local ([fe80::967:7eb6:ee49:3820]) by PRIMARY.thehowies.local ([fe80::967:7eb6:ee49:3820%11]) with mapi id 14.01.0438.000; Sat, 31 May 2014 19:22:27 -0700 From: John Howie To: "freebsd-arm@freebsd.org" , "freebsd-net@freebsd.org" , "freebsd-questions@freebsd.org" Subject: Patches for BOOTP/DHCP code to support Windows Server DHCP Thread-Topic: Patches for BOOTP/DHCP code to support Windows Server DHCP Thread-Index: AQHPfUBUW2MQdiTIGUuysOzuLv/2xg== Date: Sun, 1 Jun 2014 02:22:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [203.147.52.194] Content-Type: multipart/mixed; boundary="_003_CFB0A140426CBjohnthehowiescom_" MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 02:23:36 -0000 --_003_CFB0A140426CBjohnthehowiescom_ Content-Type: text/plain; charset="Windows-1252" Content-ID: <07D53905702BB74B9802B9E3C82B70C7@thehowies.local> Content-Transfer-Encoding: quoted-printable Hi all, I apologize for the cross posting of this email, but I believe it will be of interest to people across all three groups. Please feel free to forward to additional groups if you feel they would benefit. I have seen a few posts on and off over the years about Windows Server DHCP not working with FreeBSD. Specifically, the Windows Server DHCP would not return the boot host name/IP address and the root path. The typical response to =B3why won=B9t it work" has typically been that there is a flaw= in Windows Server DHCP code. I did a little digging and found that the problem actually lies in code in FreeBSD. Section 3.5 of RFC 2131 (the DHCP RFC) states that =B3...Second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the server with a list of specific parameters the client is interested in=8A=B2 and =B3...The client can inform the server which configuration parameters the client is interested in by including the 'parameter request list' option. The data portion of this option explicitly lists the options requested by tag number=8A=B2. A DHCP Server is not required to return any parameter that a client does not ask for. It appears that the ISC-DHCP server, which is recommended by most, will return configured options regardless of whether or not the client asks for them. There are two places in the FreeBSD codebase that DHCP is used to boot the system over a network. The first is in the boot loader, which uses code in lib/libstand. The second is in the NFS code, in sys/nfs. The code is sys/nfs is not always used if the boot loader sets up the environment for the NFS code, either by passing parameters to the kernel (as PXEBOOT appears to do), or information is configured in the boot loader configuration files, e.g. /boot/loader.rc. I have attached two unified diff files which I ask people to test, before I submit them for inclusion into the codebase as fixes. The first, bootp.c.diff fixes the code in lib/libstand/bootp.c to request the boot host (option 12, aka TAG_HOSTNAME) and the NFS root path (option 17, aka TAG_ROOTPATH). This fix has been tested with PXEBOOT on an amd64 box and ubldr on an ARM/RaspberryPI system. The second, bootp_subr.c.diff, fixes code in sys/nfs/bootp_subr.c to request the same options and also to fix bugs that erroneously reported the IP address of the BOOTP/DHCP server. The code assumed that the BOOTP/DHCP server was also the boot host. Please send me all feedback directly. The diff files work with 10.0-RELEASE through 10.0-RELEASE-p3, but will likely work with 9.0 and also CURRENT and STABLE, including 11.0, as the code is old code that does not appear to have changed in a while. If you want to try it on those systems please, please make sure you have backup copies just in case. If you do not have experience configuring Windows Server DHCP just drop me an email, and I will send you a cheat sheet to get you up and running. I am going to grab the latest ubldr code to see if I can get it to work more like PXEBOOT, that appears to pass parameters to the kernel to avoid the need for the NFS BOOTP/DHCP process. If you test on an ARM system with ubldr in RELEASE you will see a lot of unnecessary network activity going on, that we should be able to fix. Regards, John john@thehowies.com (personal) | jhowie@email.arizona.edu (academic) | j.howie@napier.ac.uk (academic) | jhowie@cloudsecurityalliance.org (work) --_003_CFB0A140426CBjohnthehowiescom_ Content-Type: application/octet-stream; name="bootp_subr.c.diff" Content-Description: bootp_subr.c.diff Content-Disposition: attachment; filename="bootp_subr.c.diff"; size=2626; creation-date="Sun, 01 Jun 2014 02:22:26 GMT"; modification-date="Sun, 01 Jun 2014 02:22:26 GMT" Content-ID: <48E8CD1FA2F5FF40B7454A0D1B2A8C6F@thehowies.local> Content-Transfer-Encoding: base64 LS0tIHN5cy9uZnMvYm9vdHBfc3Vici5jCTIwMTQtMDEtMjYgMTU6NTU6NDIuMDAwMDAwMDAwIC0w ODAwCisrKyAvaG9tZS9qb2huL3RtcC9ib290cF9zdWJyLmMJMjAxNC0wNS0yNCAxOTowMzo1OS4w MDAwMDAwMDAgLTA3MDAKQEAgLTE5OCw2ICsxOTgsNyBAQAogCiAvKiBESENQIHNwZWNpZmljIHRh Z3MgKi8KICNkZWZpbmUgVEFHX09WRVJMT0FECSA1MiAgLyogT3B0aW9uIE92ZXJsb2FkICovCisj ZGVmaW5lIFRBR19QQVJBTV9SRVEgICAgNTUgIC8qIFRhZyBkZW5vdGluZyBvcHRpb25hbCB0YWdz IGluIERIQ1AgY2xpZW50IG1lc3NhZ2UsIHJlcXVlc3RpbmcgZGF0YSBmcm9tIERIQ1Agc2VydmVy ICovCiAjZGVmaW5lIFRBR19NQVhNU0dTSVpFICAgNTcgIC8qIE1heGltdW0gREhDUCBNZXNzYWdl IFNpemUgKi8KIAogI2RlZmluZSBUQUdfRU5ECQkyNTUgIC8qIEVuZCBPcHRpb24gKGkuZS4gbm8g bW9yZSBvcHRpb25zKSAqLwpAQCAtNTczLDcgKzU3NCw3IEBACiBzdGF0aWMgaW50CiBib290cGNf Y2FsbChzdHJ1Y3QgYm9vdHBjX2dsb2JhbGNvbnRleHQgKmdjdHgsIHN0cnVjdCB0aHJlYWQgKnRk KQogewotCXN0cnVjdCBzb2NrYWRkcl9pbiAqc2luLCBkc3Q7CisJc3RydWN0IHNvY2thZGRyX2lu ICpzaW4sIGRzdCwgKmZyb207CiAJc3RydWN0IHVpbyBhdWlvOwogCXN0cnVjdCBzb2Nrb3B0IHNv cHQ7CiAJc3RydWN0IGlvdmVjIGFpbzsKQEAgLTU4Nyw2ICs1ODgsNyBAQAogCWludCByZXRyeTsK IAljb25zdCBjaGFyICpzOwogCisgICAgZnJvbSA9IChzdHJ1Y3Qgc29ja2FkZHJfaW4gKikgMDsK IAl0di50dl9zZWMgPSAxOwogCXR2LnR2X3VzZWMgPSAwOwogCWJ6ZXJvKCZzb3B0LCBzaXplb2Yo c29wdCkpOwpAQCAtNzYwLDkgKzc2MiwxNCBAQAogCQlpZiAodGltbyA8IE1BWF9SRVNFTkRfREVM QVkpCiAJCQl0aW1vKys7CiAJCWVsc2UgewotCQkJcHJpbnRmKCJESENQL0JPT1RQIHRpbWVvdXQg Zm9yIHNlcnZlciAiKTsKLQkJCXByaW50X3Npbl9hZGRyKCZkc3QpOwotCQkJcHJpbnRmKCJcbiIp OworICAgICAgICAgICAgaWYgKGZyb20gIT0gKHN0cnVjdCBzb2NrYWRkcl9pbiAqKSAwKSB7Cisg ICAgICAgICAgICAgICAgcHJpbnRmKCJESENQL0JPT1RQIHRpbWVvdXQgZm9yIHNlcnZlciAiKTsK KyAgICAgICAgICAgICAgICBwcmludF9zaW5fYWRkcihmcm9tKTsKKyAgICAgICAgICAgICAgICBw cmludGYoIlxuIik7CisgICAgICAgICAgICB9CisgICAgICAgICAgICBlbHNlIHsKKyAgICAgICAg ICAgICAgICBwcmludGYgKCJESENQL0JPT1RQIHRpbWVvdXRcbiIpOworICAgICAgICAgICAgfQog CQl9CiAKIAkJLyoKQEAgLTc4Myw3ICs3OTAsMTEgQEAKIAkJCWF1aW8udWlvX3RkID0gdGQ7CiAK IAkJCXJjdmZsZyA9IDA7Ci0JCQllcnJvciA9IHNvcmVjZWl2ZShib290cF9zbywgTlVMTCwgJmF1 aW8sCisgICAgICAgICAgICBpZiAoZnJvbSAhPSAoc3RydWN0IHNvY2thZGRyX2luICopIDApIHsK KyAgICAgICAgICAgICAgICBmcmVlIChmcm9tLCBNX1NPTkFNRSk7CisgICAgICAgICAgICAgICAg ZnJvbSA9IChzdHJ1Y3Qgc29ja2FkZHJfaW4gKikgMDsKKyAgICAgICAgICAgIH0KKwkJCWVycm9y ID0gc29yZWNlaXZlKGJvb3RwX3NvLCAoc3RydWN0IHNvY2thZGRyICoqKSAmZnJvbSwgJmF1aW8s CiAJCQkJCSAgTlVMTCwgTlVMTCwgJnJjdmZsZyk7CiAJCQlnY3R4LT5zZWNzID0gdGltZV9zZWNv bmQgLSBnY3R4LT5zdGFydHRpbWU7CiAJCQlTVEFJTFFfRk9SRUFDSChpZmN0eCwgJmdjdHgtPmlu dGVyZmFjZXMsIG5leHQpIHsKQEAgLTg1MCw3ICs4NjEsNyBAQAogCQkJCSAgICAgICAiIG9uICVz IGZyb20gIiwKIAkJCQkgICAgICAgcywKIAkJCQkgICAgICAgaWZjdHgtPmlyZXEuaWZyX25hbWUp OwotCQkJCXByaW50X2luX2FkZHIoZ2N0eC0+cmVwbHkuc2lhZGRyKTsKKwkJCQlwcmludF9zaW5f YWRkcihmcm9tKTsKIAkJCQlpZiAoZ2N0eC0+cmVwbHkuZ2lhZGRyLnNfYWRkciAhPQogCQkJCSAg ICBodG9ubChJTkFERFJfQU5ZKSkgewogCQkJCQlwcmludGYoIiB2aWEgIik7CkBAIC05MzMsNiAr OTQ0LDEwIEBACiAJZXJyb3IgPSBFVElNRURPVVQ7CiAKIG91dDoKKyAgICBpZiAoZnJvbSAhPSAo c3RydWN0IHNvY2thZGRyX2luICopIDApIHsKKyAgICAgICAgZnJlZSAoZnJvbSwgTV9TT05BTUUp OworICAgICAgICBmcm9tID0gKHN0cnVjdCBzb2NrYWRkcl9pbiAqKSAwOworICAgIH0KIAlyZXR1 cm4gKGVycm9yKTsKIH0KIApAQCAtMTI3Nyw2ICsxMjkyLDE1IEBACiAJCWxlYXNldGltZSA9IGh0 b25sKDMwMCk7CiAJCW1lbWNweSh2ZW5kcCwgJmxlYXNldGltZSwgNCk7CiAJCXZlbmRwICs9IDQ7 CisgICAgICAgICAgICAKKyAgICAgICAgLyoKKyAgICAgICAgICogUmVxdWVzdCBob3N0IGFuZCBw YXRoIG9mIHJvb3QgZGlzayAocmVxdWlyZWQgZm9yIFdpbmRvd3MgU2VydmVyIERIQ1ApCisgICAg ICAgICAqLworICAgICAgICAgICAgCisgICAgICAgICp2ZW5kcCsrID0gVEFHX1BBUkFNX1JFUTsK KyAgICAgICAgKnZlbmRwKysgPSAyOworICAgICAgICAqdmVuZHArKyA9IFRBR19IT1NUTkFNRTsK KyAgICAgICAgKnZlbmRwKysgPSBUQUdfUk9PVDsKIAkJYnJlYWs7CiAJZGVmYXVsdDoKIAkJYnJl YWs7Cg== --_003_CFB0A140426CBjohnthehowiescom_ Content-Type: application/octet-stream; name="bootp.c.diff" Content-Description: bootp.c.diff Content-Disposition: attachment; filename="bootp.c.diff"; size=907; creation-date="Sun, 01 Jun 2014 02:22:26 GMT"; modification-date="Sun, 01 Jun 2014 02:22:26 GMT" Content-ID: <257902279A9442499AC0B670B2BC93E1@thehowies.local> Content-Transfer-Encoding: base64 LS0tIGxpYi9saWJzdGFuZC9ib290cC5jCTIwMTQtMDQtMDQgMTI6MTg6NDAuMDAwMDAwMDAwIC0w NzAwCisrKyAvaG9tZS9qb2huL3RtcC9ib290cC5jCTIwMTQtMDUtMTEgMjA6MDA6NDQuMDAwMDAw MDAwIC0wNzAwCkBAIC0xODYsMTMgKzE4NiwyMiBAQAogCQlicC0+YnBfdmVuZFsyMF0gPSA0Owog CQlsZWFzZXRpbWUgPSBodG9ubCgzMDApOwogCQliY29weSgmbGVhc2V0aW1lLCAmYnAtPmJwX3Zl bmRbMjFdLCA0KTsKKyAgICAgICAgCisgICAgICAgIC8qCisgICAgICAgICAqIFJlcXVlc3QgaG9z dCBhbmQgcGF0aCBvZiByb290IGRpc2sgKHJlcXVpcmVkIGZvciBXaW5kb3dzIFNlcnZlciBESENQ KQorICAgICAgICAgKi8KKyAgICAgICAgCisJCWJwLT5icF92ZW5kWzI1XSA9IFRBR19QQVJBTV9S RVE7CisJCWJwLT5icF92ZW5kWzI2XSA9IDI7CisJCWJwLT5icF92ZW5kWzI3XSA9IFRBR19IT1NU TkFNRTsKKwkJYnAtPmJwX3ZlbmRbMjhdID0gVEFHX1JPT1RQQVRIOwogCQlpZiAoZmxhZyAmIEJP T1RQX1BYRSkgewotCQkJYnAtPmJwX3ZlbmRbMjVdID0gVEFHX0NMQVNTSUQ7Ci0JCQlicC0+YnBf dmVuZFsyNl0gPSA5OwotCQkJYmNvcHkoIlBYRUNsaWVudCIsICZicC0+YnBfdmVuZFsyN10sIDkp OwotCQkJYnAtPmJwX3ZlbmRbMzZdID0gVEFHX0VORDsKKwkJCWJwLT5icF92ZW5kWzI5XSA9IFRB R19DTEFTU0lEOworCQkJYnAtPmJwX3ZlbmRbMzBdID0gOTsKKwkJCWJjb3B5KCJQWEVDbGllbnQi LCAmYnAtPmJwX3ZlbmRbMzFdLCA5KTsKKwkJCWJwLT5icF92ZW5kWzQwXSA9IFRBR19FTkQ7CiAJ CX0gZWxzZQotCQkJYnAtPmJwX3ZlbmRbMjVdID0gVEFHX0VORDsKKwkJCWJwLT5icF92ZW5kWzI5 XSA9IFRBR19FTkQ7CiAKIAkJZXhwZWN0ZWRfZGhjcG1zZ3R5cGUgPSBESENQQUNLOwogCg== --_003_CFB0A140426CBjohnthehowiescom_-- From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 02:33:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29E50E92; Sun, 1 Jun 2014 02:33:41 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8B6323FF; Sun, 1 Jun 2014 02:33:40 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s512XVQ5023259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 1 Jun 2014 04:33:31 +0200 (CEST) (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 s512XOVb072012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jun 2014 04:33:24 +0200 (CEST) (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 s512XOrF055942; Sun, 1 Jun 2014 04:33:24 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s512XOtl055941; Sun, 1 Jun 2014 04:33:24 +0200 (CEST) (envelope-from ticso) Date: Sun, 1 Jun 2014 04:33:24 +0200 From: Bernd Walter To: Warner Losh Subject: Re: TRIM on SD cards Message-ID: <20140601023324.GD54731@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> <20140601004311.GB54731@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140601004311.GB54731@cicely7.cicely.de> 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: Bernd Walter , "freebsd-arm@freebsd.org" , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 02:33:41 -0000 On Sun, Jun 01, 2014 at 02:43:11AM +0200, Bernd Walter wrote: > On Sat, May 31, 2014 at 12:51:42PM -0600, Warner Losh wrote: > > > > On May 31, 2014, at 12:44 PM, Warner Losh wrote: > > > > > > > > On May 31, 2014, at 12:06 PM, Adrian Chadd wrote: > > > > > >> On 31 May 2014 10:49, Warner Losh wrote: > > >>> > > >>> On May 31, 2014, at 11:31 AM, Adrian Chadd wrote: > > >>> > > >>>> On 31 May 2014 09:45, Warner Losh wrote: > > >>>> > > >>>>> One of the things that I did for images years ago was compressed tar files. There was so much variation between CF makers and at the time CF geometry was important to the BIOS, so we made our images as tar balls. We then had a makefile target that would create a partition on the card that was actually there, put boot blocks on it then extract the tarball? I never have liked DD for creating images, even when LBAs ruled the day because you?d always have to grow/shrink the FS afterwards. The only advantage it had was it was easy? Perhaps it is time to go back to that model? The alternative that wouldn?t suck too bad would be to create variable sized images based on how much data was actually present and ensure there are no holes (or minimal holes) in the filesystem. > > >>>>> > > >>>>> Hmmm, if we know WHAT filesystem we?re dealing with, then we could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it knows are free, which would be a useful, data-driven approach that could ensure we start out with a nicely trimmed FS. Given the vagaries of the different kinds of TRIMs and the various translation layers we have, that might be the most robust. > > >>>> > > >>>> Having makefs spit this out would be rather useful. > > >>> > > >>> I?m not sure it would be. Any writes to the FS after you create it would invalidate the list? Far easier to have fsck do it for you any time you need it... > > >> > > >> Sure, but it'd be part of a larger scale image creation and writing > > >> tool. That way you could ship images that had the sparseness bits in > > >> them and the tool + growfs can TRIM as appropriate on the installing > > >> media. > > > > > > Except why have an extra step when all that metadata is encoded in the filesystem itself? > > > > looks like fsck already has a -E flag: > > > > -E Clear unallocated blocks, notifying the underlying device that > > they are not used and that their contents may be discarded. This > > is useful for filesystems which have been mounted on systems > > without TRIM support, or with TRIM support disabled, as well as > > filesystems which have been copied from one device to another. > > > > So maybe the answer ?it is already there? might be a better reason :) > > > > Bernd, can you try this on your arm box to see what it does for your system? > > Oh damn - I should have looked into the fsck manpage. > This is great. > I've put it on my TODO list for next week. Seems to be a rather new feature. At least my 1 month old stable system don't have this feature. At least this explains why I didn't spot it - I thought to have looked into fsck manpage, but wasn't sure. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 02:37:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F02FF1A for ; Sun, 1 Jun 2014 02:37:24 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55A3C2415 for ; Sun, 1 Jun 2014 02:37:23 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id rd3so3044440pab.29 for ; Sat, 31 May 2014 19:37:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=wJmsgiRE1vGFf4LquzLAKcL/cd+rPJu8EPh7H8J/EWk=; b=Sr6sg28Z77yljOc6MtYuFpTIjRq+LHn56crXqygqfq7M6WnH16dd/pB8YRjILjeYjH FAMECVyeffRmy4qdBIjqao/W2WCDQiSQCfWMnMWR4ARvIMHIDFi2Gps2khFbuA086cbw BElcw0S97lFvsxZRNCLfYRaOYXFrlMCibG1IVx7rv04V90vcDjQwBiJNWnxvT/+Q6FDH +goGwGttVrLrJImymdC+1hRZgJJwgbo8FAXB82sRMt0QxrK/zbjqDC3JKYRlLx40AeTm uoVE81X168EPl4VrR6dOSXh7Vpq9qj0I/MtZdZ2LVED36xqkZmDyEJ771XRhmcSPDm1+ NijQ== X-Gm-Message-State: ALoCoQkJXGVhrFYDky6ldFsWLe35ctkbrYqBY9Z9KZt5lEGIfTLYcDtG+MDLETG3+Pg8Z3ZrRfDm X-Received: by 10.66.248.65 with SMTP id yk1mr30662375pac.38.1401590237205; Sat, 31 May 2014 19:37:17 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id yx3sm13472569pbb.6.2014.05.31.19.37.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 19:37:16 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_B6266CF5-BA0D-4F15-99A9-3D9AF060C655"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: <20140601002603.GQ43976@funkthat.com> Date: Sat, 31 May 2014 20:37:18 -0600 Message-Id: References: <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> <20140531195659.GP43976@funkthat.com> <72D59B65-09FF-4272-A795-99DC94970F7D@bsdimp.com> <20140601002603.GQ43976@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.2) Cc: Bernd Walter , "freebsd-arm@freebsd.org" , Ian Lepore , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 02:37:24 -0000 --Apple-Mail=_B6266CF5-BA0D-4F15-99A9-3D9AF060C655 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 31, 2014, at 6:26 PM, John-Mark Gurney wrote: > Warner Losh wrote this message on Sat, May 31, 2014 at 15:09 -0600: >>=20 >> On May 31, 2014, at 1:56 PM, John-Mark Gurney = wrote: >>=20 >>> Warner Losh wrote this message on Sat, May 31, 2014 at 12:51 -0600: >>>>=20 >>>> On May 31, 2014, at 12:44 PM, Warner Losh wrote: >>>>=20 >>>>>=20 >>>>> On May 31, 2014, at 12:06 PM, Adrian Chadd = wrote: >>>>>=20 >>>>>> On 31 May 2014 10:49, Warner Losh wrote: >>>>>>>=20 >>>>>>> On May 31, 2014, at 11:31 AM, Adrian Chadd = wrote: >>>>>>>=20 >>>>>>>> On 31 May 2014 09:45, Warner Losh wrote: >>>>>>>>=20 >>>>>>>>> One of the things that I did for images years ago was = compressed tar files. There was so much variation between CF makers and = at the time CF geometry was important to the BIOS, so we made our images = as tar balls. We then had a makefile target that would create a = partition on the card that was actually there, put boot blocks on it = then extract the tarball? I never have liked DD for creating images, = even when LBAs ruled the day because you?d always have to grow/shrink = the FS afterwards. The only advantage it had was it was easy? Perhaps it = is time to go back to that model? The alternative that wouldn?t suck too = bad would be to create variable sized images based on how much data was = actually present and ensure there are no holes (or minimal holes) in the = filesystem. >>>>>>>>>=20 >>>>>>>>> Hmmm, if we know WHAT filesystem we?re dealing with, then we = could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks = that it knows are free, which would be a useful, data-driven approach = that could ensure we start out with a nicely trimmed FS. Given the = vagaries of the different kinds of TRIMs and the various translation = layers we have, that might be the most robust. >>>>>>>>=20 >>>>>>>> Having makefs spit this out would be rather useful. >>>>>>>=20 >>>>>>> I?m not sure it would be. Any writes to the FS after you create = it would invalidate the list? Far easier to have fsck do it for you any = time you need it... >>>>>>=20 >>>>>> Sure, but it'd be part of a larger scale image creation and = writing >>>>>> tool. That way you could ship images that had the sparseness bits = in >>>>>> them and the tool + growfs can TRIM as appropriate on the = installing >>>>>> media. >>>>>=20 >>>>> Except why have an extra step when all that metadata is encoded in = the filesystem itself? >>>>=20 >>>> looks like fsck already has a -E flag: >>>>=20 >>>> -E Clear unallocated blocks, notifying the underlying device = that >>>> they are not used and that their contents may be = discarded. This >>>> is useful for filesystems which have been mounted on = systems >>>> without TRIM support, or with TRIM support disabled, as = well as >>>> filesystems which have been copied from one device to = another. >>>>=20 >>>> So maybe the answer ?it is already there? might be a better reason = :) >>>>=20 >>>> Bernd, can you try this on your arm box to see what it does for = your system? >>>=20 >>> Hmm... sounds like another useful command to run on first boot, = though >>> right now it's disabled by default... >>>=20 >>> makefs doesn't support setting the flag... I'll fix makefs, as I = have >>> some other minor changes sitting in my tree... >>=20 >> Putting it in makefs is approximately useless? >=20 > How else can you use makefs to generate a FS that will use trim if > makefs doesn't set the _TRIM flag? Or do you mean you can set it on > a live system w/ tunefs? If so, then why don't we remove the label > option, since that too can be set by tunefs... Doh! I thought you meant the -E option, not the -t option :) Warner --Apple-Mail=_B6266CF5-BA0D-4F15-99A9-3D9AF060C655 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTipHeAAoJEGwc0Sh9sBEARBYQANRNIdr/+ivnRJAKTBE3PgEl vaYjavx4ZweyB7syQuFzObSaooX+8INMoodJKZHE8YXR5yeO2qasNTXlN/OrGHL5 TTqAs+D6uiKe6AoG9/2s38nwRx5C6jh30xd3iC23I3ZyjaSdLq2M4/zeoC5ej2qp SPU4oiS+/twi1CCe7jlg/PqlGh6eP6Y5uBXU51BWWRwwZzNhZg7Gm7YGyzcrO72f XFJy/ncEylCKn+23N0oPTKYnMesa0+DWQSDOr69VYDnb+x/CGWgNX9VSEEmX0eO2 vC9/azNoR3U3qmw3A+By2klHwhoRFXzx5WOnqKGaUgYkqO0Zvc+hbQKmq4UqD+28 xkx+KwH4Z4U0phECSbTtuwG5gLR/yQEWWkDIJfK5ii8LZ6q6DLssTNjvQ72jBFEG 3bd10e3MOfypFTCqapHG+F8una67QxhXiBTaifcs/mrna09/cY6zxfFh55oowNmw fgILJacFWeWBkONnmGzZJtv9tG89ikwEJaNGAuHoBnzkNscpfAgGjZuwkEIZ743z atKskRSXrO8fB44jn1hV+v+KQR9dMfAC2wit80y5uZWVI5ZL98eiSOvkNalF7VwB rY66sBihO68sH7fhjZeSvzkzREahIWB1ZcpH/WLypxRi43BABcHlQXMR8Dnu4IbZ exdA4znStFDtmSoxQcPS =qjOr -----END PGP SIGNATURE----- --Apple-Mail=_B6266CF5-BA0D-4F15-99A9-3D9AF060C655-- From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 02:44:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B36C1FCD for ; Sun, 1 Jun 2014 02:44:57 +0000 (UTC) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A9C924A5 for ; Sun, 1 Jun 2014 02:44:57 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id rr13so3047472pbb.21 for ; Sat, 31 May 2014 19:44:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=vM1nkXEV3HWWOt5VYFWHAtCC4iMRiLoI7qeladcOCaA=; b=dP4jLgagKvOseIr0ejkX71AECVC41NMg1hWR0hnj+7ZnF+EamFWJ0lD7MWbtrfTJaA XNWOHzn0Q2mhpNazh5eu3psQVzgRprQDWZiThdDg9vOwq49KmbQKNINFb5783HFCrczC +MTs2a5b3KJ3ds4mw0VgHdKdX530yhXvTzpZlnLoQk6yTx8JZjXWxQpN0vOPRfdj4C26 epFDr3zUN5t5oaIR5aZ22avwwoq5p80N19mRVLzCu3Lida2S9KgKIXFXdHCmlqTtKKqx YIV+Qlw0W7+1ihQTvkwPwdvVqdv8WG7x0cnbC1x5qKvWEdHcF423JrMqaNIkbiPMgrOw /Qiw== X-Gm-Message-State: ALoCoQn7fSF+GO85+Rm6cYuq88ntG06Ebt+A1I6DQTo7M8TsM5wgnKzof/TDEa6Mx5KHI8MfEowL X-Received: by 10.66.180.168 with SMTP id dp8mr31191850pac.100.1401590306682; Sat, 31 May 2014 19:38:26 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ky8sm13425470pbc.64.2014.05.31.19.38.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 19:38:25 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_5CF164A9-25A1-48A0-9A6E-30BA1272342D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: <20140601023324.GD54731@cicely7.cicely.de> Date: Sat, 31 May 2014 20:38:28 -0600 Message-Id: References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> <20140601004311.GB54731@cicely7.cicely.de> <20140601023324.GD54731@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.1878.2) Cc: Bernd Walter , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 02:44:57 -0000 --Apple-Mail=_5CF164A9-25A1-48A0-9A6E-30BA1272342D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 8:33 PM, Bernd Walter = wrote: > On Sun, Jun 01, 2014 at 02:43:11AM +0200, Bernd Walter wrote: >> On Sat, May 31, 2014 at 12:51:42PM -0600, Warner Losh wrote: >>>=20 >>> On May 31, 2014, at 12:44 PM, Warner Losh wrote: >>>=20 >>>>=20 >>>> On May 31, 2014, at 12:06 PM, Adrian Chadd = wrote: >>>>=20 >>>>> On 31 May 2014 10:49, Warner Losh wrote: >>>>>>=20 >>>>>> On May 31, 2014, at 11:31 AM, Adrian Chadd = wrote: >>>>>>=20 >>>>>>> On 31 May 2014 09:45, Warner Losh wrote: >>>>>>>=20 >>>>>>>> One of the things that I did for images years ago was = compressed tar files. There was so much variation between CF makers and = at the time CF geometry was important to the BIOS, so we made our images = as tar balls. We then had a makefile target that would create a = partition on the card that was actually there, put boot blocks on it = then extract the tarball? I never have liked DD for creating images, = even when LBAs ruled the day because you?d always have to grow/shrink = the FS afterwards. The only advantage it had was it was easy? Perhaps it = is time to go back to that model? The alternative that wouldn?t suck too = bad would be to create variable sized images based on how much data was = actually present and ensure there are no holes (or minimal holes) in the = filesystem. >>>>>>>>=20 >>>>>>>> Hmmm, if we know WHAT filesystem we?re dealing with, then we = could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks = that it knows are free, which would be a useful, data-driven approach = that could ensure we start out with a nicely trimmed FS. Given the = vagaries of the different kinds of TRIMs and the various translation = layers we have, that might be the most robust. >>>>>>>=20 >>>>>>> Having makefs spit this out would be rather useful. >>>>>>=20 >>>>>> I?m not sure it would be. Any writes to the FS after you create = it would invalidate the list? Far easier to have fsck do it for you any = time you need it... >>>>>=20 >>>>> Sure, but it'd be part of a larger scale image creation and = writing >>>>> tool. That way you could ship images that had the sparseness bits = in >>>>> them and the tool + growfs can TRIM as appropriate on the = installing >>>>> media. >>>>=20 >>>> Except why have an extra step when all that metadata is encoded in = the filesystem itself? >>>=20 >>> looks like fsck already has a -E flag: >>>=20 >>> -E Clear unallocated blocks, notifying the underlying device = that >>> they are not used and that their contents may be = discarded. This >>> is useful for filesystems which have been mounted on = systems >>> without TRIM support, or with TRIM support disabled, as = well as >>> filesystems which have been copied from one device to = another. >>>=20 >>> So maybe the answer ?it is already there? might be a better reason = :) >>>=20 >>> Bernd, can you try this on your arm box to see what it does for your = system? >>=20 >> Oh damn - I should have looked into the fsck manpage. >> This is great. >> I've put it on my TODO list for next week. >=20 > Seems to be a rather new feature. > At least my 1 month old stable system don't have this feature. > At least this explains why I didn't spot it - I thought to have looked > into fsck manpage, but wasn't sure. That=92s because it is in the fsck_ffs man page, not the fsck man page. Warner --Apple-Mail=_5CF164A9-25A1-48A0-9A6E-30BA1272342D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTipIkAAoJEGwc0Sh9sBEAYz4P/A7EZ32DUV95zxwrU9Xuu0XS 2UqEOTFDdobGfjgh7m1Ij2WtWYgVnpeLTOUE5qjexg1DKEf+GIbjRAkr0zBBRqdZ e4lSrx9QFczwyOMOJmRAx7tcMVvYu/mQUaAco1QgtccHCadvcy5/B7jh/29/tM8r n0vpxEejlty9NKBYZvGBgmDcey6FkW+4xu7mNpajohcvmSXhMShEr9iLvkDh62JF CgMDe9/nLzPe7AteVrvBsvGn2KAiYerulq4IYaN7HN9HmTY/UJKJG5s93fLjEejQ pKs3JhKIipz5r67M0+6BDQjAORuBoupCmdDjCy2nhetioqTbCozVfkPUwlmH2I4r Rf3fPIXzXWTBdIZ4k0LoekKAKJJjRyE3DYLqReu/zwgIrdUOTLWFTzEE1uMCejBs KNs6bN2V3s9UfsylLx42QFHC7WJU0/DZIrpT2yXX/9ME1PF2IB9K8JqZlESyJbt+ rit/IUC9q8jZnV39hg4xU0nKnZZySHs9WA5Sy8V+Is8VMgo8mI/IhsQjSgXsizqu mxrOnQbapSGuwEUCH/3NLBUhQJEIk587yJZJqdg2uH6R2Tx0ik3GniAChuonBlEe D/fV0RtV3yYqGBifF9R2rr4kVoCTk79LCYSsmU2zTOvLl3JNwUMM0NCaxvInCWt6 eDAaMz2TEg5ozk+XcmeN =QMsK -----END PGP SIGNATURE----- --Apple-Mail=_5CF164A9-25A1-48A0-9A6E-30BA1272342D-- From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 02:56:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6B90298; Sun, 1 Jun 2014 02:56:19 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 60897254E; Sun, 1 Jun 2014 02:56:19 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s512uGIr023404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 1 Jun 2014 04:56:16 +0200 (CEST) (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 s512u3st072224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jun 2014 04:56:03 +0200 (CEST) (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 s512u2gd056041; Sun, 1 Jun 2014 04:56:02 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s512u2R7056040; Sun, 1 Jun 2014 04:56:02 +0200 (CEST) (envelope-from ticso) Date: Sun, 1 Jun 2014 04:56:02 +0200 From: Bernd Walter To: Warner Losh Subject: Re: TRIM on SD cards Message-ID: <20140601025602.GF54731@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> <20140601004311.GB54731@cicely7.cicely.de> <20140601023324.GD54731@cicely7.cicely.de> 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=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Bernd Walter , "freebsd-arm@freebsd.org" , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 02:56:19 -0000 On Sat, May 31, 2014 at 08:38:28PM -0600, Warner Losh wrote: > > On May 31, 2014, at 8:33 PM, Bernd Walter wrote: > > > On Sun, Jun 01, 2014 at 02:43:11AM +0200, Bernd Walter wrote: > >> On Sat, May 31, 2014 at 12:51:42PM -0600, Warner Losh wrote: > >>> > >>> On May 31, 2014, at 12:44 PM, Warner Losh wrote: > >>> > >>>> > >>>> On May 31, 2014, at 12:06 PM, Adrian Chadd wrote: > >>>> > >>>>> On 31 May 2014 10:49, Warner Losh wrote: > >>>>>> > >>>>>> On May 31, 2014, at 11:31 AM, Adrian Chadd wrote: > >>>>>> > >>>>>>> On 31 May 2014 09:45, Warner Losh wrote: > >>>>>>> > >>>>>>>> One of the things that I did for images years ago was compressed tar files. There was so much variation between CF makers and at the time CF geometry was important to the BIOS, so we made our images as tar balls. We then had a makefile target that would create a partition on the card that was actually there, put boot blocks on it then extract the tarball? I never have liked DD for creating images, even when LBAs ruled the day because you?d always have to grow/shrink the FS afterwards. The only advantage it had was it was easy? Perhaps it is time to go back to that model? The alternative that wouldn?t suck too bad would be to create variable sized images based on how much data was actually present and ensure there are no holes (or minimal holes) in the filesystem. > >>>>>>>> > >>>>>>>> Hmmm, if we know WHAT filesystem we?re dealing with, then we could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it knows are free, which would be a useful, data-driven approach that could ensure we start out with a nicely trimmed FS. Given the vagaries of the different kinds of TRIMs and the various translation layers we have, that might be the most robust. > >>>>>>> > >>>>>>> Having makefs spit this out would be rather useful. > >>>>>> > >>>>>> I?m not sure it would be. Any writes to the FS after you create it would invalidate the list? Far easier to have fsck do it for you any time you need it... > >>>>> > >>>>> Sure, but it'd be part of a larger scale image creation and writing > >>>>> tool. That way you could ship images that had the sparseness bits in > >>>>> them and the tool + growfs can TRIM as appropriate on the installing > >>>>> media. > >>>> > >>>> Except why have an extra step when all that metadata is encoded in the filesystem itself? > >>> > >>> looks like fsck already has a -E flag: > >>> > >>> -E Clear unallocated blocks, notifying the underlying device that > >>> they are not used and that their contents may be discarded. This > >>> is useful for filesystems which have been mounted on systems > >>> without TRIM support, or with TRIM support disabled, as well as > >>> filesystems which have been copied from one device to another. > >>> > >>> So maybe the answer ?it is already there? might be a better reason :) > >>> > >>> Bernd, can you try this on your arm box to see what it does for your system? > >> > >> Oh damn - I should have looked into the fsck manpage. > >> This is great. > >> I've put it on my TODO list for next week. > > > > Seems to be a rather new feature. > > At least my 1 month old stable system don't have this feature. > > At least this explains why I didn't spot it - I thought to have looked > > into fsck manpage, but wasn't sure. > > That?s because it is in the fsck_ffs man page, not the fsck man page. Makes sense... -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 06:31:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51B506F0 for ; Sun, 1 Jun 2014 06:31:32 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 8CD5F2B98 for ; Sun, 1 Jun 2014 06:31:31 +0000 (UTC) Received: (qmail 43464 invoked from network); 1 Jun 2014 06:24:48 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 1 Jun 2014 06:24:48 -0000 Date: Sun, 01 Jun 2014 08:24:48 +0200 (CEST) Message-Id: <20140601.082448.74710838.sthaug@nethelp.no> To: john@thehowies.com Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 06:31:32 -0000 > Section 3.5 of RFC 2131 (the DHCP RFC) states that "...Second, in its > initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the > server with a list of specific parameters the client is interested in" > and "...The client can inform the server which configuration parameters > the client is interested in by including the 'parameter request list' > option." The data portion of this option explicitly lists the options > requested by tag number. A DHCP Server is not required to return any > parameter that a client does not ask for. It appears that the ISC-DHCP > server, which is recommended by most, will return configured options > regardless of whether or not the client asks for them. As far as I know this is wrong. ISC DHCP does *not* behave this way. Do you have packet sniffer traces to indicate oterwise? In any case - yes, the client should absolutely request all the parameters it wants. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 08:11:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 652AFAC0; Sun, 1 Jun 2014 08:11:56 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B60D2309; Sun, 1 Jun 2014 08:11:55 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s518BrYn097184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jun 2014 01:11:54 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s518BrCD097183; Sun, 1 Jun 2014 01:11:53 -0700 (PDT) (envelope-from jmg) Date: Sun, 1 Jun 2014 01:11:53 -0700 From: John-Mark Gurney To: Alan Cox Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140601081153.GU43976@funkthat.com> Mail-Followup-To: Alan Cox , Olivier Houchard , Adrian Chadd , "freebsd-arm@freebsd.org" , alc@freebsd.org, kib@freebsd.org References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5388ABF1.3030200@rice.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 01 Jun 2014 01:11:54 -0700 (PDT) Cc: alc@freebsd.org, kib@freebsd.org, "freebsd-arm@freebsd.org" , Olivier Houchard X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 08:11:56 -0000 Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: > On 05/30/2014 01:32, John-Mark Gurney wrote: > > Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: > >> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: > >>> On 29 May 2014 10:16, Olivier Houchard wrote: > >>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > >>>>> Have you tested this on xscale hardware? > >>>> > >>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot > >>>> again. > >>> Woo! What can I provide to help you do this? :-) > >>> > >>> (Drinks? Food? Donations?) > >>> > >>> > >> Drinks and food are always appreciated ;) > >> It almost boots for me now, except a few userland programs gets SIGSEGV or > >> SIGILL along the way, trying to figure out why. > > Thanks for fixing ddb... I'm getting panic messages again... bad > > news is that my panic is still around: > > panic: vm_page_alloc: page 0xc07e73b0 is wired > > > > Though, interestingly, it looks like sparc64 has a similar panic: > > https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 > > > > kib, Alan, any clue to why this is happening? Any suggestions as to > > help track it down? > > I'm afraid not. The dump below shows a perfectly normal, in-use page. > If this page had actually been free prior to the vm_page_alloc() call, > then other fields, like dirty, would have been different. In other > words, this isn't just a problem with the wire count. > > What object is vm_page_alloc() being performed on? Is this enough? Or do you need more? panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 KDB: enter: panic [ thread pid 781 tid 100051 ] Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! db> show object/f 0xc1500b40 Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 sref=0, backing_object(0)=(0)+0x0 memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) If you need more, let me know what/how to get it, and I will... > > Lastest dump of the vm_page from a tree from today is: > > {'act_count': '\x00', > > 'aflags': '\x00', > > 'busy_lock': 1, > > 'dirty': '\xff', > > 'flags': 0, > > 'hold_count': 0, > > 'listq': {'tqe_next': 0xc07e7400, 'tqe_prev': 0xc06e63a0}, > > 'md': {'pv_kva': 3235893248, > > 'pv_list': {'tqh_first': 0x0, 'tqh_last': 0xc07e73e0}, > > 'pv_memattr': '\x00', > > 'pvh_attrs': 0}, > > 'object': 0xc06e6378, > > 'oflags': '\x04', > > 'order': '\t', > > 'phys_addr': 9424896, > > 'pindex': 3581, > > 'plinks': {'memguard': {'p': 0, 'v': 3228461644}, > > 'q': {'tqe_next': 0x0, 'tqe_prev': 0xc06e6a4c}, > > 's': {'pv': 0xc06e6a4c, 'ss': {'sle_next': 0x0}}}, > > 'pool': '\x00', > > 'queue': '\xff', > > 'segind': '\x02', > > 'valid': '\xff', > > 'wire_count': 1} > > > > This appears to be on the kmem_object list as: > > c06e62d8 B kernel_object_store > > c06e6378 B kmem_object_store > > c06e6418 b old_msync > > > > and you can see the tqh_last would be part of kmem_object_store... > > > > Could this be something bad happening w/ when memory is low? The > > board I'm testing on has only 64MB (54MB avail), so it hits that > > pretty quickly... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 10:22:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A210663E; Sun, 1 Jun 2014 10:22:18 +0000 (UTC) Received: from remote.thehowies.com (50-197-91-217-static.hfc.comcastbusiness.net [50.197.91.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "remote.thehowies.com", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C0122D08; Sun, 1 Jun 2014 10:22:17 +0000 (UTC) Received: from PRIMARY.thehowies.local ([fe80::967:7eb6:ee49:3820]) by PRIMARY.thehowies.local ([fe80::967:7eb6:ee49:3820%11]) with mapi id 14.01.0438.000; Sun, 1 Jun 2014 03:22:15 -0700 From: John Howie To: "sthaug@nethelp.no" Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP Thread-Topic: Patches for BOOTP/DHCP code to support Windows Server DHCP Thread-Index: AQHPfUBUW2MQdiTIGUuysOzuLv/2xptcPzcAgAC3qoA= Date: Sun, 1 Jun 2014 10:22:15 +0000 Message-ID: References: <20140601.082448.74710838.sthaug@nethelp.no> In-Reply-To: <20140601.082448.74710838.sthaug@nethelp.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [203.147.52.194] Content-Type: text/plain; charset="us-ascii" Content-ID: <4894C64CE3DA02458F33AE8BB40F8A9F@thehowies.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "freebsd-arm@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 10:22:18 -0000 Hi Steinar, In short, no, I have no packet traces. Given that the DHCP code in the FreeBSD boot loader and NFS subsystem does not request those options, but that ISC-DHCP does provide them, I will go out on a limb and say that it must be serving them without being asked if they are configured. Regards, John On 6/1/14, 1:24 PM, "sthaug@nethelp.no" wrote: >> Section 3.5 of RFC 2131 (the DHCP RFC) states that "...Second, in its >> initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the >> server with a list of specific parameters the client is interested in" >> and "...The client can inform the server which configuration parameters >> the client is interested in by including the 'parameter request list' >> option." The data portion of this option explicitly lists the options >> requested by tag number. A DHCP Server is not required to return any >> parameter that a client does not ask for. It appears that the ISC-DHCP >> server, which is recommended by most, will return configured options >> regardless of whether or not the client asks for them. > >As far as I know this is wrong. ISC DHCP does *not* behave this way. >Do you have packet sniffer traces to indicate oterwise? > >In any case - yes, the client should absolutely request all the >parameters it wants. > >Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 12:01:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4F9BDB7; Sun, 1 Jun 2014 12:01:45 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 52BD92650; Sun, 1 Jun 2014 12:01:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkEAHUEi1ODaFve/2dsb2JhbABYgyYzWIJsuCyGaFEBgR50giUBAQEDAQEBASArIAsFFhgRGQIpAQkYAQ0GCAcEARwCAogZCA2xLaQxF41nCRACARs0B4I0DzISgTkElxyEIpFvg1QhNIE+ X-IronPort-AV: E=Sophos;i="4.98,951,1392181200"; d="scan'208";a="125510873" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 01 Jun 2014 08:01:42 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E12BEB41A3; Sun, 1 Jun 2014 08:01:42 -0400 (EDT) Date: Sun, 1 Jun 2014 08:01:42 -0400 (EDT) From: Rick Macklem To: John Howie Message-ID: <1468927196.9638531.1401624102908.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP MIME-Version: 1.0 X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 12:01:45 -0000 John Howie wrote: > Hi all, >=20 > I apologize for the cross posting of this email, but I believe it > will be > of interest to people across all three groups. Please feel free to > forward > to additional groups if you feel they would benefit. >=20 > I have seen a few posts on and off over the years about Windows > Server > DHCP not working with FreeBSD. Specifically, the Windows Server DHCP > would > not return the boot host name/IP address and the root path. The > typical > response to =C2=B3why won=C2=B9t it work" has typically been that there i= s a > flaw in > Windows Server DHCP code. I did a little digging and found that the > problem actually lies in code in FreeBSD. >=20 > Section 3.5 of RFC 2131 (the DHCP RFC) states that =C2=B3...Second, in it= s > initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the > server with a list of specific parameters the client is interested > in=C5=A0=C2=B2 > and =C2=B3...The client can inform the server which configuration > parameters > the client is interested in by including the 'parameter request list' > option. The data portion of this option explicitly lists the options > requested by tag number=C5=A0=C2=B2. A DHCP Server is not required to ret= urn > any > parameter that a client does not ask for. It appears that the > ISC-DHCP > server, which is recommended by most, will return configured options > regardless of whether or not the client asks for them. >=20 > There are two places in the FreeBSD codebase that DHCP is used to > boot the > system over a network. The first is in the boot loader, which uses > code in > lib/libstand. The second is in the NFS code, in sys/nfs. The code is > sys/nfs is not always used if the boot loader sets up the environment > for > the NFS code, either by passing parameters to the kernel (as PXEBOOT > appears to do), or information is configured in the boot loader > configuration files, e.g. /boot/loader.rc. >=20 > I have attached two unified diff files which I ask people to test, > before > I submit them for inclusion into the codebase as fixes. The first, > bootp.c.diff fixes the code in lib/libstand/bootp.c to request the > boot > host (option 12, aka TAG_HOSTNAME) and the NFS root path (option 17, > aka > TAG_ROOTPATH). This fix has been tested with PXEBOOT on an amd64 box > and > ubldr on an ARM/RaspberryPI system. The second, bootp_subr.c.diff, > fixes > code in sys/nfs/bootp_subr.c to request the same options and also to > fix > bugs that erroneously reported the IP address of the BOOTP/DHCP > server. > The code assumed that the BOOTP/DHCP server was also the boot host. > Please > send me all feedback directly. >=20 > The diff files work with 10.0-RELEASE through 10.0-RELEASE-p3, but > will > likely work with 9.0 and also CURRENT and STABLE, including 11.0, as > the > code is old code that does not appear to have changed in a while. If > you > want to try it on those systems please, please make sure you have > backup > copies just in case. >=20 > If you do not have experience configuring Windows Server DHCP just > drop me > an email, and I will send you a cheat sheet to get you up and > running. >=20 > I am going to grab the latest ubldr code to see if I can get it to > work > more like PXEBOOT, that appears to pass parameters to the kernel to > avoid > the need for the NFS BOOTP/DHCP process. If you test on an ARM system > with > ubldr in RELEASE you will see a lot of unnecessary network activity > going > on, that we should be able to fix. >=20 Actually, I tend to think that using the code in sys/nfs/bootp_subr.c is preferable to using the NFS stuff in stand that pxeboot does. The only reason I know for pxeboot doing the NFS stuff and filling in the nfsv3_diskless structure is historical. (Or that's what most people use for x86, so it would be a POLA violation if it breaks, if you prefer.) (Basically, the code in sys/nfs/bootp_subr.c is easier to maintain than the stand alone NFS client pxeboot uses.) As such, I don't think this work is necessary, rick > Regards, >=20 > John >=20 > john@thehowies.com (personal) | jhowie@email.arizona.edu (academic) | > j.howie@napier.ac.uk (academic) | jhowie@cloudsecurityalliance.org > (work) >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 12:30:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37A4C5F2 for ; Sun, 1 Jun 2014 12:30:37 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 3FF492862 for ; Sun, 1 Jun 2014 12:30:35 +0000 (UTC) Received: (qmail 47967 invoked from network); 1 Jun 2014 12:30:33 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 1 Jun 2014 12:30:33 -0000 Date: Sun, 01 Jun 2014 14:30:33 +0200 (CEST) Message-Id: <20140601.143033.41674928.sthaug@nethelp.no> To: john@thehowies.com Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP From: sthaug@nethelp.no In-Reply-To: References: <20140601.082448.74710838.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 12:30:37 -0000 > In short, no, I have no packet traces. Given that the DHCP code in the > FreeBSD boot loader and NFS subsystem does not request those options, but > that ISC-DHCP does provide them, I will go out on a limb and say that it > must be serving them without being asked if they are configured. In that case I'm afraid I must stand by my claim that you're wrong and ISC DHCP does *not* provide configured options unless the client asks for them. (And I have copious amounts of packet sniffer traces to prove this.) Not that this is particularly relevant to FreeBSD any more... Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 13:01:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8FD42CA; Sun, 1 Jun 2014 13:01:51 +0000 (UTC) Received: from remote.thehowies.com (50-197-91-217-static.hfc.comcastbusiness.net [50.197.91.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "remote.thehowies.com", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82A4C2B0E; Sun, 1 Jun 2014 13:01:50 +0000 (UTC) Received: from PRIMARY.thehowies.local ([fe80::967:7eb6:ee49:3820]) by PRIMARY.thehowies.local ([fe80::967:7eb6:ee49:3820%11]) with mapi id 14.01.0438.000; Sun, 1 Jun 2014 06:01:48 -0700 From: John Howie To: "sthaug@nethelp.no" Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP Thread-Topic: Patches for BOOTP/DHCP code to support Windows Server DHCP Thread-Index: AQHPfUBUW2MQdiTIGUuysOzuLv/2xptcPzcAgAC3qoD//66HgP//k2Lc Date: Sun, 1 Jun 2014 13:01:48 +0000 Message-ID: <0FF4F173-8D6A-4664-AA31-FB1BF28A7E74@thehowies.com> References: <20140601.082448.74710838.sthaug@nethelp.no> , <20140601.143033.41674928.sthaug@nethelp.no> In-Reply-To: <20140601.143033.41674928.sthaug@nethelp.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "freebsd-arm@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 13:01:51 -0000 Hi Steinar, I could ask you to 'prove it', too, but I can easily check when I get back = from my current travels :-) It important to note that even if it does (as I think it does) it is NOT in= violation of the RFC. The RFC simply says that if a client wants something= it should ask for it, and not that a server cannot send the options unsoli= cited. Best regards, John Sent from my iPhone On Jun 1, 2014, at 19:30, "sthaug@nethelp.no" wrote: >> In short, no, I have no packet traces. Given that the DHCP code in the >> FreeBSD boot loader and NFS subsystem does not request those options, bu= t >> that ISC-DHCP does provide them, I will go out on a limb and say that it >> must be serving them without being asked if they are configured. >=20 > In that case I'm afraid I must stand by my claim that you're wrong > and ISC DHCP does *not* provide configured options unless the client > asks for them. >=20 > (And I have copious amounts of packet sniffer traces to prove this.) >=20 > Not that this is particularly relevant to FreeBSD any more... >=20 > Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 13:15:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB744905; Sun, 1 Jun 2014 13:15:57 +0000 (UTC) Received: from remote.thehowies.com (50-197-91-217-static.hfc.comcastbusiness.net [50.197.91.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "remote.thehowies.com", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C1552BED; Sun, 1 Jun 2014 13:15:56 +0000 (UTC) Received: from PRIMARY.thehowies.local ([fe80::967:7eb6:ee49:3820]) by PRIMARY.thehowies.local ([fe80::967:7eb6:ee49:3820%11]) with mapi id 14.01.0438.000; Sun, 1 Jun 2014 06:15:56 -0700 From: John Howie To: Rick Macklem Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP Thread-Topic: Patches for BOOTP/DHCP code to support Windows Server DHCP Thread-Index: AQHPfUBUW2MQdiTIGUuysOzuLv/2xptcnVgA//+fZCc= Date: Sun, 1 Jun 2014 13:15:55 +0000 Message-ID: References: , <1468927196.9638531.1401624102908.JavaMail.root@uoguelph.ca> In-Reply-To: <1468927196.9638531.1401624102908.JavaMail.root@uoguelph.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "freebsd-arm@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 13:15:58 -0000 Hi Rick, That is an excellent point and a good debate to have. I have not looked in detail at how PXEBOOT does it, but I think a clean up = of the code to somehow pass arguments to the kernel is preferable to having= a diskless client send a slew of needless requests to the DHCP server to r= equest information already requested and obtained in previous stages of the= boot process. The number of DHCP requests made by a client when using U-Bo= ot and ubldr is dizzying. The NFS code will look to see if the boot loader = configuration file has specified the root filesystem through use of vfs.roo= t.mountfrom, so something should be possible. Another area for possible attention is handling the scenario when there are= a number of DHCP servers able to reply to requests. This can happen when y= ou have multiple NICs on segments with DHCP Servers or where you have multi= ple servers on the same segment. The current code just grabs the first serv= er to reply at each stage (going through each NIC in turn) and has affinity= to it for the remainder of that stage but not through the entire boot proc= ess. Regards, John Sent from my iPhone > On Jun 1, 2014, at 19:01, "Rick Macklem" wrote: >=20 > John Howie wrote: >> Hi all, >>=20 >> I apologize for the cross posting of this email, but I believe it >> will be >> of interest to people across all three groups. Please feel free to >> forward >> to additional groups if you feel they would benefit. >>=20 >> I have seen a few posts on and off over the years about Windows >> Server >> DHCP not working with FreeBSD. Specifically, the Windows Server DHCP >> would >> not return the boot host name/IP address and the root path. The >> typical >> response to =B3why won=B9t it work" has typically been that there is a >> flaw in >> Windows Server DHCP code. I did a little digging and found that the >> problem actually lies in code in FreeBSD. >>=20 >> Section 3.5 of RFC 2131 (the DHCP RFC) states that =B3...Second, in its >> initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the >> server with a list of specific parameters the client is interested >> in=8A=B2 >> and =B3...The client can inform the server which configuration >> parameters >> the client is interested in by including the 'parameter request list' >> option. The data portion of this option explicitly lists the options >> requested by tag number=8A=B2. A DHCP Server is not required to return >> any >> parameter that a client does not ask for. It appears that the >> ISC-DHCP >> server, which is recommended by most, will return configured options >> regardless of whether or not the client asks for them. >>=20 >> There are two places in the FreeBSD codebase that DHCP is used to >> boot the >> system over a network. The first is in the boot loader, which uses >> code in >> lib/libstand. The second is in the NFS code, in sys/nfs. The code is >> sys/nfs is not always used if the boot loader sets up the environment >> for >> the NFS code, either by passing parameters to the kernel (as PXEBOOT >> appears to do), or information is configured in the boot loader >> configuration files, e.g. /boot/loader.rc. >>=20 >> I have attached two unified diff files which I ask people to test, >> before >> I submit them for inclusion into the codebase as fixes. The first, >> bootp.c.diff fixes the code in lib/libstand/bootp.c to request the >> boot >> host (option 12, aka TAG_HOSTNAME) and the NFS root path (option 17, >> aka >> TAG_ROOTPATH). This fix has been tested with PXEBOOT on an amd64 box >> and >> ubldr on an ARM/RaspberryPI system. The second, bootp_subr.c.diff, >> fixes >> code in sys/nfs/bootp_subr.c to request the same options and also to >> fix >> bugs that erroneously reported the IP address of the BOOTP/DHCP >> server. >> The code assumed that the BOOTP/DHCP server was also the boot host. >> Please >> send me all feedback directly. >>=20 >> The diff files work with 10.0-RELEASE through 10.0-RELEASE-p3, but >> will >> likely work with 9.0 and also CURRENT and STABLE, including 11.0, as >> the >> code is old code that does not appear to have changed in a while. If >> you >> want to try it on those systems please, please make sure you have >> backup >> copies just in case. >>=20 >> If you do not have experience configuring Windows Server DHCP just >> drop me >> an email, and I will send you a cheat sheet to get you up and >> running. >>=20 >> I am going to grab the latest ubldr code to see if I can get it to >> work >> more like PXEBOOT, that appears to pass parameters to the kernel to >> avoid >> the need for the NFS BOOTP/DHCP process. If you test on an ARM system >> with >> ubldr in RELEASE you will see a lot of unnecessary network activity >> going >> on, that we should be able to fix. > Actually, I tend to think that using the code in sys/nfs/bootp_subr.c > is preferable to using the NFS stuff in stand that pxeboot does. >=20 > The only reason I know for pxeboot doing the NFS stuff and filling in > the nfsv3_diskless structure is historical. (Or that's what most people > use for x86, so it would be a POLA violation if it breaks, if you prefer.= ) > (Basically, the code in sys/nfs/bootp_subr.c is easier to maintain than t= he > stand alone NFS client pxeboot uses.) >=20 > As such, I don't think this work is necessary, rick >=20 >> Regards, >>=20 >> John >>=20 >> john@thehowies.com (personal) | jhowie@email.arizona.edu (academic) | >> j.howie@napier.ac.uk (academic) | jhowie@cloudsecurityalliance.org >> (work) >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 13:30:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1D35E02; Sun, 1 Jun 2014 13:30:18 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7416E2CCB; Sun, 1 Jun 2014 13:30:17 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s51DU6tW078105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 1 Jun 2014 06:30:08 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <538B2AD8.5050608@freebsd.org> Date: Sun, 01 Jun 2014 21:30:00 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Rick Macklem , John Howie Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP References: <1468927196.9638531.1401624102908.JavaMail.root@uoguelph.ca> In-Reply-To: <1468927196.9638531.1401624102908.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 13:30:18 -0000 On 6/1/14, 8:01 PM, Rick Macklem wrote: > John Howie wrote: >> [...] > Actually, I tend to think that using the code in sys/nfs/bootp_subr.c > is preferable to using the NFS stuff in stand that pxeboot does. > > The only reason I know for pxeboot doing the NFS stuff and filling in > the nfsv3_diskless structure is historical. (Or that's what most people > use for x86, so it would be a POLA violation if it breaks, if you prefer.) > (Basically, the code in sys/nfs/bootp_subr.c is easier to maintain than the > stand alone NFS client pxeboot uses.) > > As such, I don't think this work is necessary, rick it's probably worth having both options John. great work BTW. > >> Regards, >> >> John >> >> john@thehowies.com (personal) | jhowie@email.arizona.edu (academic) | >> j.howie@napier.ac.uk (academic) | jhowie@cloudsecurityalliance.org >> (work) >> >> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 18:38:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B7681A9; Sun, 1 Jun 2014 18:38:31 +0000 (UTC) Received: from orange.myspectrum.nl (orange.myspectrum.nl [149.210.134.247]) by mx1.freebsd.org (Postfix) with ESMTP id CF0302502; Sun, 1 Jun 2014 18:38:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by orange.myspectrum.nl (Postfix) with ESMTP id 6D1BD8ABDD; Sun, 1 Jun 2014 20:32:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at myspectrum.nl Received: from orange.myspectrum.nl ([127.0.0.1]) by localhost (orange.myspectrum.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4TymCKFYdIN; Sun, 1 Jun 2014 20:32:04 +0200 (CEST) Received: from [192.168.0.13] (ip136-5-208-87.adsl2.static.versatel.nl [87.208.5.136]) (Authenticated sender: freebsd_arm@myspectrum.nl) by orange.myspectrum.nl (Postfix) with ESMTPSA id 2F8D781B6A; Sun, 1 Jun 2014 20:32:04 +0200 (CEST) Message-ID: <1401647513.2295.37.camel@yellow> Subject: Re: Today's Crochet fixes From: Jeroen Hofstee To: Tim Kientzle Date: Sun, 01 Jun 2014 20:31:53 +0200 In-Reply-To: <24AD766C-FA11-45AD-94B3-7C99EBF53FD0@freebsd.org> References: <24AD766C-FA11-45AD-94B3-7C99EBF53FD0@freebsd.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 18:38:31 -0000 Hello Tim, On zo, 2014-04-20 at 10:27 -0700, Tim Kientzle wrote: > > Things I'm interested in help with: > > * Updating U-Boot for BeagleBone to a newer snapshot > (Including migrating Patrick Kelsey's patches to support eMMC booting) > > * Building U-Boot with clang (Winston Smith claims it "just works" > if you have new enough U-Boot sources; I've not yet tried to reproduce this. > If it works as well as I hope, it will take a while to update U-Boot sources > for each Crochet-supported board.) > A bit late, but above it more then doubtful. This branch [1] can at least build some ARM targets. Didn't check FreeBSD yet, waiting for an old laptop to finish updating, since it needs at least llvm 3.4. Regards, Jeroen [1] https://github.com/jhofstee/u-boot/commits/v2014.07-rc2-clang. From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 19:10:27 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBBB54C3; Sun, 1 Jun 2014 19:10:27 +0000 (UTC) Received: from orange.myspectrum.nl (orange.myspectrum.nl [149.210.134.247]) by mx1.freebsd.org (Postfix) with ESMTP id 77A792816; Sun, 1 Jun 2014 19:10:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by orange.myspectrum.nl (Postfix) with ESMTP id A2CBE8ABDD; Sun, 1 Jun 2014 21:10:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at myspectrum.nl Received: from orange.myspectrum.nl ([127.0.0.1]) by localhost (orange.myspectrum.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjBtIhlRHr8d; Sun, 1 Jun 2014 21:10:25 +0200 (CEST) Received: from [192.168.0.13] (ip136-5-208-87.adsl2.static.versatel.nl [87.208.5.136]) (Authenticated sender: freebsd_arm@myspectrum.nl) by orange.myspectrum.nl (Postfix) with ESMTPSA id CB4088A9A9; Sun, 1 Jun 2014 21:10:24 +0200 (CEST) Message-ID: <1401649825.2295.45.camel@yellow> Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Jeroen Hofstee To: Mark R V Murray Date: Sun, 01 Jun 2014 21:10:25 +0200 In-Reply-To: References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: Tim Kientzle , freebsd-arm , ticso@cicely.de, Ian Lepore , albert.u.boot@aribaud.net X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 19:10:27 -0000 On do, 2014-04-17 at 19:01 +0100, Mark R V Murray wrote: > On 17 Apr 2014, at 13:49, Ian Lepore wrote: > > > U-boot requires that a global register be set aside by the compiler and > > it's used to access all global vars. As I vaguely understand it, u-boot > > used to want r8 for this, and clang didn't used to support the concept > > at all. Now clang supports it, but only for r9, and apparently more > > recent u-boot expects r9 rather than r8. So the fix is probably to use > > more recent u-boot sources (I've been using 2014.01 for imx6 stuff), and > > probably to add the new -ffixed-r9 flag for a clang build. > > Correct. > > The pig in trying to build u-boot 2004.04 with Clang/XDEV is the use of > > #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r9”) > > which means “gd is an alias for the r9 register and is a pointer to type …” > > … I think. :-) > > Clang doesn’t like this one bit. First objection is to “global register variables”, so if I experimentally knock out the “register”, I simply get the second objection - to "multiple instances of the r9 global variable”. > > Googling a bit suggests that Clang just plain can’t do this. :-( > Well with a bit of creativity this will work [1]. Hopefully this ends up in mainline u-boot. For the record, it is the U-Boot Arm maintainer (Albert) who actually dug up the fixed-r9 in llvm (but was a hidden option for ios). Regards, Jeroen [1] https://github.com/jhofstee/u-boot/commit/4ab717325cb7e7b02efaec2b3f95bf9874492ba2 From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 21:19:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EE7E9C7; Sun, 1 Jun 2014 21:19:06 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 40CF62164; Sun, 1 Jun 2014 21:19:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAGKYi1ODaFve/2dsb2JhbABZg1lYgmy4LYZoUQGBIHSCJQEBAQMBAQEBICsgBgUFFhgCAg0ZAikBCRgBDQYIBwQBHAICiBkIDbExpC0XgSqMPQkQAgEbATMHgnWBSwSXHIQikW+DVCE0gT4 X-IronPort-AV: E=Sophos;i="4.98,952,1392181200"; d="scan'208";a="125575012" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 01 Jun 2014 17:18:30 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0F161B4045; Sun, 1 Jun 2014 17:18:30 -0400 (EDT) Date: Sun, 1 Jun 2014 17:18:30 -0400 (EDT) From: Rick Macklem To: John Howie Message-ID: <867385953.9728745.1401657510047.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 21:19:06 -0000 John Howie wrote: > Hi Rick, >=20 > That is an excellent point and a good debate to have. >=20 > I have not looked in detail at how PXEBOOT does it, but I think a > clean up of the code to somehow pass arguments to the kernel is > preferable to having a diskless client send a slew of needless > requests to the DHCP server to request information already requested > and obtained in previous stages of the boot process. The number of > DHCP requests made by a client when using U-Boot and ubldr is > dizzying. The NFS code will look to see if the boot loader > configuration file has specified the root filesystem through use of > vfs.root.mountfrom, so something should be possible. >=20 Well, pxeboot uses a standalone nfs client to do all the things that sys/nfs/bootp_subr.c does. I bothered to add NFSv3 to this stand alone nfs client, but there is no way I will be doing NFSv4 for it. (Although I don't see much use for an NFSv4 root fs, a couple of people have already asked about it. To do it, modifying the NFSv4 kernel client code to use the stuff in bootp_subr.c is definitely the way to go.) I have no intention of removing the pxeboot stuff, but I do suspect many would be surprised to see they are still using NFSv2 (with a performance penalty) for the diskless root fs over pxeboot. (If you have a pxeboot built from sources post-r212125 Sep. 2010, it can use NFSv3, but I think you have to specify the "nfsv3" option in the line for "/" in the /etc/fsta= b in the rootfs being exported to the client.) Btw, if you are running a fairly recent system with a diskless NFS root fs, you might want to type "nfsstat -m" to see what it is actually using for th= e root fs. It is mainly the difficulties w.r.t. maintaining lib/libstand/nfs.c which m= akes sys/nfs/bootp_subr.c preferable from my point of view. Anyhow, have fun with it, rick > Another area for possible attention is handling the scenario when > there are a number of DHCP servers able to reply to requests. This > can happen when you have multiple NICs on segments with DHCP Servers > or where you have multiple servers on the same segment. The current > code just grabs the first server to reply at each stage (going > through each NIC in turn) and has affinity to it for the remainder > of that stage but not through the entire boot process. >=20 > Regards, >=20 > John >=20 > Sent from my iPhone >=20 > > On Jun 1, 2014, at 19:01, "Rick Macklem" > > wrote: > >=20 > > John Howie wrote: > >> Hi all, > >>=20 > >> I apologize for the cross posting of this email, but I believe it > >> will be > >> of interest to people across all three groups. Please feel free to > >> forward > >> to additional groups if you feel they would benefit. > >>=20 > >> I have seen a few posts on and off over the years about Windows > >> Server > >> DHCP not working with FreeBSD. Specifically, the Windows Server > >> DHCP > >> would > >> not return the boot host name/IP address and the root path. The > >> typical > >> response to =C2=B3why won=C2=B9t it work" has typically been that ther= e is a > >> flaw in > >> Windows Server DHCP code. I did a little digging and found that > >> the > >> problem actually lies in code in FreeBSD. > >>=20 > >> Section 3.5 of RFC 2131 (the DHCP RFC) states that =C2=B3...Second, in > >> its > >> initial DHCPDISCOVER or DHCPREQUEST message, a client may provide > >> the > >> server with a list of specific parameters the client is interested > >> in=C5=A0=C2=B2 > >> and =C2=B3...The client can inform the server which configuration > >> parameters > >> the client is interested in by including the 'parameter request > >> list' > >> option. The data portion of this option explicitly lists the > >> options > >> requested by tag number=C5=A0=C2=B2. A DHCP Server is not required to = return > >> any > >> parameter that a client does not ask for. It appears that the > >> ISC-DHCP > >> server, which is recommended by most, will return configured > >> options > >> regardless of whether or not the client asks for them. > >>=20 > >> There are two places in the FreeBSD codebase that DHCP is used to > >> boot the > >> system over a network. The first is in the boot loader, which uses > >> code in > >> lib/libstand. The second is in the NFS code, in sys/nfs. The code > >> is > >> sys/nfs is not always used if the boot loader sets up the > >> environment > >> for > >> the NFS code, either by passing parameters to the kernel (as > >> PXEBOOT > >> appears to do), or information is configured in the boot loader > >> configuration files, e.g. /boot/loader.rc. > >>=20 > >> I have attached two unified diff files which I ask people to test, > >> before > >> I submit them for inclusion into the codebase as fixes. The first, > >> bootp.c.diff fixes the code in lib/libstand/bootp.c to request the > >> boot > >> host (option 12, aka TAG_HOSTNAME) and the NFS root path (option > >> 17, > >> aka > >> TAG_ROOTPATH). This fix has been tested with PXEBOOT on an amd64 > >> box > >> and > >> ubldr on an ARM/RaspberryPI system. The second, bootp_subr.c.diff, > >> fixes > >> code in sys/nfs/bootp_subr.c to request the same options and also > >> to > >> fix > >> bugs that erroneously reported the IP address of the BOOTP/DHCP > >> server. > >> The code assumed that the BOOTP/DHCP server was also the boot > >> host. > >> Please > >> send me all feedback directly. > >>=20 > >> The diff files work with 10.0-RELEASE through 10.0-RELEASE-p3, but > >> will > >> likely work with 9.0 and also CURRENT and STABLE, including 11.0, > >> as > >> the > >> code is old code that does not appear to have changed in a while. > >> If > >> you > >> want to try it on those systems please, please make sure you have > >> backup > >> copies just in case. > >>=20 > >> If you do not have experience configuring Windows Server DHCP just > >> drop me > >> an email, and I will send you a cheat sheet to get you up and > >> running. > >>=20 > >> I am going to grab the latest ubldr code to see if I can get it to > >> work > >> more like PXEBOOT, that appears to pass parameters to the kernel > >> to > >> avoid > >> the need for the NFS BOOTP/DHCP process. If you test on an ARM > >> system > >> with > >> ubldr in RELEASE you will see a lot of unnecessary network > >> activity > >> going > >> on, that we should be able to fix. > > Actually, I tend to think that using the code in > > sys/nfs/bootp_subr.c > > is preferable to using the NFS stuff in stand that pxeboot does. > >=20 > > The only reason I know for pxeboot doing the NFS stuff and filling > > in > > the nfsv3_diskless structure is historical. (Or that's what most > > people > > use for x86, so it would be a POLA violation if it breaks, if you > > prefer.) > > (Basically, the code in sys/nfs/bootp_subr.c is easier to maintain > > than the > > stand alone NFS client pxeboot uses.) > >=20 > > As such, I don't think this work is necessary, rick > >=20 > >> Regards, > >>=20 > >> John > >>=20 > >> john@thehowies.com (personal) | jhowie@email.arizona.edu > >> (academic) | > >> j.howie@napier.ac.uk (academic) | jhowie@cloudsecurityalliance.org > >> (work) > >>=20 > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to > >> "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@FreeBSD.ORG Mon Jun 2 06:21:17 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCF05446; Mon, 2 Jun 2014 06:21:17 +0000 (UTC) Received: from aribaud.fr (aribaud.fr [IPv6:2001:470:c8ce::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 500A22E09; Mon, 2 Jun 2014 06:21:16 +0000 (UTC) Received: from lilith ([192.168.128.3]) by janus with esmtps (SSL3.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WrLcJ-0001fP-5z; Mon, 02 Jun 2014 08:21:07 +0200 Date: Mon, 2 Jun 2014 08:21:06 +0200 From: Albert ARIBAUD To: Jeroen Hofstee Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. In-Reply-To: <1401649825.2295.45.camel@yellow> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> <1397738961.1124.157.camel@revolution.hippie.lan> <1401649825.2295.45.camel@yellow> X-Mailer: Claws Mail 3.10.0 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-Id: Cc: Tim Kientzle , freebsd-arm , Ian Lepore , Mark R V Murray , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 06:21:17 -0000 Hi Jeroen et al., On Sun, 01 Jun 2014 21:10:25 +0200, Jeroen Hofstee wrote: > On do, 2014-04-17 at 19:01 +0100, Mark R V Murray wrote: > > On 17 Apr 2014, at 13:49, Ian Lepore wrote: > >=20 > > > U-boot requires that a global register be set aside by the compiler a= nd > > > it's used to access all global vars. As I vaguely understand it, u-b= oot > > > used to want r8 for this, and clang didn't used to support the concept > > > at all. Now clang supports it, but only for r9, and apparently more > > > recent u-boot expects r9 rather than r8. So the fix is probably to u= se > > > more recent u-boot sources (I've been using 2014.01 for imx6 stuff), = and > > > probably to add the new -ffixed-r9 flag for a clang build. > >=20 > > Correct. > >=20 > > The pig in trying to build u-boot 2004.04 with Clang/XDEV is the use of > >=20 > > #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *= gd asm ("r9=E2=80=9D) > >=20 > > which means =E2=80=9Cgd is an alias for the r9 register and is a pointe= r to type =E2=80=A6=E2=80=9D > >=20 > > =E2=80=A6 I think. :-) > >=20 > > Clang doesn=E2=80=99t like this one bit. First objection is to =E2=80= =9Cglobal register variables=E2=80=9D, so if I experimentally knock out the= =E2=80=9Cregister=E2=80=9D, I simply get the second objection - to "multip= le instances of the r9 global variable=E2=80=9D. > >=20 > > Googling a bit suggests that Clang just plain can=E2=80=99t do this. :-( > >=20 >=20 > Well with a bit of creativity this will work [1]. Hopefully this ends up > in mainline u-boot. For the record, it is the U-Boot Arm maintainer > (Albert) who actually dug up the fixed-r9 in llvm (but was a hidden > option for ios).=20 Although my name was not uttered thrice :) allow me to chime in still, and say that while I did dig up the r9 option, it was a mere consequence of Jeroen's effort to make U-boot build with LLVM, and that even though the EABI states that r9 is the register to use if you need one to store a global constant, U-Boot itself used r8 rather than r9 and thus was non-compliant until Jeroen fixed it in mainline, see commit fe1378a961e508b31b1f29a2bb08ba1dac063155), and it is Jeroen's effort too that will make U-Boot eventualy buildable with LLVM/clang. BTW, Jeroen, I'll have a look at your patch series today. > Regards, > Jeroen >=20 > [1] > https://github.com/jhofstee/u-boot/commit/4ab717325cb7e7b02efaec2b3f95bf9= 874492ba2 Amicalement, --=20 Albert. From owner-freebsd-arm@FreeBSD.ORG Tue Jun 3 13:42:28 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 545C95C6; Tue, 3 Jun 2014 13:42:28 +0000 (UTC) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 8E39F2C0D; Tue, 3 Jun 2014 13:42:27 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id A8A70C493A; Tue, 3 Jun 2014 16:42:26 +0300 (EEST) Date: Tue, 3 Jun 2014 16:43:38 +0300 From: Aleksandr Rybalko To: Michael Tuexen Subject: Re: svn commit: r265927 - head/sys/dev/vt Message-Id: <20140603164338.bbcf323f6e1d1edd83db56fc@freebsd.org> In-Reply-To: <17B3391B-BCE3-4B0D-93AE-D2B377FD9038@freebsd.org> References: <201405121929.s4CJTcBx010967@svn.freebsd.org> <2899E6ED-712E-46BC-960B-9847FD99431C@freebsd.org> <20140514142252.8fe1742f90a28e534532b1d5@freebsd.org> <17B3391B-BCE3-4B0D-93AE-D2B377FD9038@freebsd.org> X-Mailer: Sylpheed 3.3.1 (GTK+ 2.24.22; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , src-committers@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:42:28 -0000 On Wed, 14 May 2014 18:37:15 +0200 Michael Tuexen wrote: > On 14 May 2014, at 13:22, Aleksandr Rybalko wrote: > > > On Tue, 13 May 2014 18:20:32 +0200 > > Michael Tuexen wrote: > > > >> Hi Aleksandr, > > > > Hi Michael, > > > >> > >> could it be that this commit results in the following panic when booting > >> a Raspberry Pi: > >> > >> fb0: 656x416(0x0@0,0) 16bpp > >> fb0: pitch 1312, base 0x5e006000, screen_size 545792 > >> fbd0 on fb0 > >> VT: initialize with new VT driver "fb". > >> panic: mtx_lock() of spin mutex (null) @ /usr/home/tuexen/head/sys/dev/vt/vt_core.c:2035 > >> KDB: enter: panic > > > > > > Hmm, looks like here is some memory corruption. It is possible happen > > due some issue of vt(4), but panic and bt show problem with lock which > > was used right before that place: > > vt_upgrade() call VT_LOCK(vd), VT_UNLOCK(vd), then vt_resize(vd) > > vt_resize(vd) try to VT_LOCK(vd) and fail. > OK, I tested this. > > the first time vt_upgrade() is called, it calls vt_resize() from line 2024, > and this is not a problem. The second time vt_upgrade is called, it calls > vt_resize from line 1987. This results in the panic. > > Does this help? Michael, many thanks for your investigation. I think it is fixed with r267007. > > Best regards > Michael > > > > Can you please try to do clean rebuild (in case you use incremental > > build)? > > > >> [ thread pid 0 tid 100000 ] > >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! > >> db> where > >> Tracing pid 0 tid 100000 td 0xc06648a0 > >> db_trace_self() at db_trace_self > >> pc = 0xc0495760 lr = 0xc0130fdc (db_stack_trace+0xf4) > >> sp = 0xc075ea68 fp = 0xc075ea80 > >> r10 = 0xc0663930 > >> db_stack_trace() at db_stack_trace+0xf4 > >> pc = 0xc0130fdc lr = 0xc013094c (db_command+0x270) > >> sp = 0xc075ea88 fp = 0xc075eb28 > >> r4 = 0x00000000 r5 = 0x00000000 > >> r6 = 0x00000072 > >> db_command() at db_command+0x270 > >> pc = 0xc013094c lr = 0xc01306b0 (db_command_loop+0x60) > >> sp = 0xc075eb30 fp = 0xc075eb40 > >> r4 = 0xc04d5176 r5 = 0xc04ef7ba > >> r6 = 0xc066391c r7 = 0xc0590b40 > >> r8 = 0xc065a294 r9 = 0xc065a290 > >> r10 = 0xc075ed10 > >> db_command_loop() at db_command_loop+0x60 > >> pc = 0xc01306b0 lr = 0xc0133078 (db_trap+0xd8) > >> sp = 0xc075eb48 fp = 0xc075ec68 > >> r4 = 0x00000000 r5 = 0xc0663928 > >> r6 = 0xc065a2c0 > >> db_trap() at db_trap+0xd8 > >> pc = 0xc0133078 lr = 0xc028de10 (kdb_trap+0xbc) > >> sp = 0xc075ec70 fp = 0xc075ec90 > >> r4 = 0x00000000 r5 = 0x00000001 > >> r6 = 0xc065a2c0 r7 = 0xc0590b40 > >> kdb_trap() at kdb_trap+0xbc > >> pc = 0xc028de10 lr = 0xc04a90e0 (undefinedinstruction+0x298) > >> sp = 0xc075ec98 fp = 0xc075ed08 > >> r4 = 0x00000000 r5 = 0x00000000 > >> r6 = 0xc04a8d98 r7 = 0xe7ffffff > >> r8 = 0xc06648a0 r9 = 0xc028d6e0 > >> r10 = 0xc075ed10 > >> undefinedinstruction() at undefinedinstruction+0x298 > >> pc = 0xc04a90e0 lr = 0xc04972dc (exception_exit) > >> sp = 0xc075ed10 fp = 0xc075ed68 > >> r4 = 0xc04ef814 r5 = 0xc075edbc > >> r6 = 0xc04ed1f1 r7 = 0xc064c7d0 > >> r8 = 0xc06648a0 r9 = 0xc066537c > >> r10 = 0xc064c630 > >> exception_exit() at exception_exit > >> pc = 0xc04972dc lr = 0xc028d6d4 (kdb_enter+0x40) > >> sp = 0xc075ed60 fp = 0xc075ed68 > >> r0 = 0xc065a2a4 r1 = 0x00000000 > >> r2 = 0xc04f328a r3 = 0x000000ab > >> r4 = 0xc04ef814 r5 = 0xc075edbc > >> r6 = 0xc04ed1f1 r7 = 0xc064c7d0 > >> r8 = 0xc06648a0 r9 = 0xc066537c > >> r10 = 0xc064c630 r12 = 0x00000000 > >> $a() at $a > >> pc = 0xc028d6e4 lr = 0xc0256eb8 (vpanic+0xb4) > >> sp = 0xc075ed70 fp = 0xc075ed90 > >> r4 = 0x00000100 > >> vpanic() at vpanic+0xb4 > >> pc = 0xc0256eb8 lr = 0xc0256df4 ($d) > >> sp = 0xc075ed98 fp = 0xc075edb0 > >> r4 = 0xc064c6d0 r5 = 0xc04ed1f1 > >> r6 = 0xc075edbc r7 = 0xc064c630 > >> r8 = 0x00000000 r9 = 0x000007f3 > >> r10 = 0x000007f7 > >> $d() at $d > >> pc = 0xc0256df4 lr = 0xc0243240 (__mtx_lock_flags+0x134) > >> sp = 0xc075edc8 fp = 0xc075edf0 > >> r4 = 0xc04df462 r5 = 0xc05a0f00 > >> r6 = 0x000007f3 r7 = 0xc05a0f00 > >> __mtx_lock_flags() at __mtx_lock_flags+0x134 > >> pc = 0xc0243240 lr = 0xc0192008 (vt_resize+0x44) > >> sp = 0xc075edf8 fp = 0xc075ee18 > >> r4 = 0xc05a0e90 r5 = 0xc05a0f00 > >> r6 = 0xc04df462 r7 = 0xc05a0f50 > >> r8 = 0x00000000 > >> vt_resize() at vt_resize+0x44 > >> pc = 0xc0192008 lr = 0xc0191f7c (vt_upgrade+0x38c) > >> sp = 0xc075ee20 fp = 0xc075ee88 > >> r4 = 0x00000001 r5 = 0xc0664898 > >> r6 = 0xc05a0e90 r7 = 0xc0523148 > >> r8 = 0xc06650a4 r9 = 0xc06650a0 > >> r10 = 0x00001bd6 > >> vt_upgrade() at vt_upgrade+0x38c > >> pc = 0xc0191f7c lr = 0xc0205e14 (mi_startup+0x11c) > >> sp = 0xc075ee90 fp = 0xc075eea8 > >> r4 = 0x00000001 r5 = 0xc0664898 > >> r6 = 0x00000000 r7 = 0xc0523148 > >> r8 = 0xc06650a4 r9 = 0xc06650a0 > >> r10 = 0x00001bd6 > >> mi_startup() at mi_startup+0x11c > >> pc = 0xc0205e14 lr = 0xc0100238 (virt_done+0x44) > >> sp = 0xc075eeb0 fp = 0x00000000 > >> r4 = 0xc0100268 r5 = 0xc066c000 > >> r6 = 0x02048740 r7 = 0x0010014c > >> r8 = 0x00000000 r9 = 0xc074d000 > >> virt_done() at virt_done+0x44 > >> pc = 0xc0100238 lr = 0xc0100238 (virt_done+0x44) > >> sp = 0xc075eeb0 fp = 0x00000000 > >> Unable to unwind further > >> db> > >> On 12 May 2014, at 21:29, Aleksandr Rybalko wrote: > >> > >>> Author: ray > >>> Date: Mon May 12 19:29:38 2014 > >>> New Revision: 265927 > >>> URL: http://svnweb.freebsd.org/changeset/base/265927 > >>> > >>> Log: > >>> Update terminal sizes in any case when new vt(4) driver arrive. > >>> (Plus remove one unused newline) > >>> > >>> Sponsored by: The FreeBSD Foundation > >>> > >>> Modified: > >>> head/sys/dev/vt/vt_core.c > >>> > >>> Modified: head/sys/dev/vt/vt_core.c > >>> ============================================================================== > >>> --- head/sys/dev/vt/vt_core.c Mon May 12 19:11:39 2014 (r265926) > >>> +++ head/sys/dev/vt/vt_core.c Mon May 12 19:29:38 2014 (r265927) > >>> @@ -1981,8 +1981,11 @@ vt_upgrade(struct vt_device *vd) > >>> unsigned int i; > >>> > >>> /* Device didn't pass vd_init() or already upgraded. */ > >>> - if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) > >>> + if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) { > >>> + /* Refill settings with new sizes anyway. */ > >>> + vt_resize(vd); > >>> return; > >>> + } > >>> vd->vd_flags |= VDF_ASYNC; > >>> > >>> for (i = 0; i < VT_MAXWINDOWS; i++) { > >>> @@ -2019,7 +2022,6 @@ vt_upgrade(struct vt_device *vd) > >>> > >>> /* Refill settings with new sizes. */ > >>> vt_resize(vd); > >>> - > >>> } > >>> > >>> static void > >>> > >>> > >> > > > > Thanks! > > > > WBW > > -- > > Aleksandr Rybalko > > > Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Tue Jun 3 18:25:06 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E472E3D4; Tue, 3 Jun 2014 18:25:06 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A31B4281C; Tue, 3 Jun 2014 18:25:06 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id DF5851FE028; Tue, 3 Jun 2014 20:25:05 +0200 (CEST) Message-ID: <538E1325.3070703@selasky.org> Date: Tue, 03 Jun 2014 20:25:41 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Aleksandr Rybalko , Michael Tuexen Subject: Re: svn commit: r265927 - head/sys/dev/vt References: <201405121929.s4CJTcBx010967@svn.freebsd.org> <2899E6ED-712E-46BC-960B-9847FD99431C@freebsd.org> <20140514142252.8fe1742f90a28e534532b1d5@freebsd.org> <17B3391B-BCE3-4B0D-93AE-D2B377FD9038@freebsd.org> <20140603164338.bbcf323f6e1d1edd83db56fc@freebsd.org> In-Reply-To: <20140603164338.bbcf323f6e1d1edd83db56fc@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , src-committers@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 18:25:07 -0000 Thanks! --HPS From owner-freebsd-arm@FreeBSD.ORG Wed Jun 4 01:17:38 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D741A349; Wed, 4 Jun 2014 01:17:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5E252EC8; Wed, 4 Jun 2014 01:17:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s541HTNo043923; Tue, 3 Jun 2014 21:17:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s541HTkp043919; Wed, 4 Jun 2014 01:17:29 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 4 Jun 2014 01:17:29 GMT Message-Id: <201406040117.s541HTkp043919@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 01:17:38 -0000 TB --- 2014-06-03 22:30:35 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-06-03 22:30:35 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-06-03 22:30:35 - starting HEAD tinderbox run for arm/arm TB --- 2014-06-03 22:30:35 - cleaning the object tree TB --- 2014-06-03 22:30:35 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-06-03 22:30:40 - At svn revision 267032 TB --- 2014-06-03 22:30:41 - building world TB --- 2014-06-03 22:30:41 - CROSS_BUILD_TESTING=YES TB --- 2014-06-03 22:30:41 - MAKEOBJDIRPREFIX=/obj TB --- 2014-06-03 22:30:41 - MAKESYSPATH=/src/share/mk TB --- 2014-06-03 22:30:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-06-03 22:30:41 - SRCCONF=/dev/null TB --- 2014-06-03 22:30:41 - TARGET=arm TB --- 2014-06-03 22:30:41 - TARGET_ARCH=arm TB --- 2014-06-03 22:30:41 - TZ=UTC TB --- 2014-06-03 22:30:41 - __MAKE_CONF=/dev/null TB --- 2014-06-03 22:30:41 - cd /src TB --- 2014-06-03 22:30:41 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Tue Jun 3 22:30:48 UTC 2014 >>> 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 [...] /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/sgsmsg.c:603:32: warning: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] "\n/* %4ld */ 0x%.2x,", ndx, ~~~~ ^~~ %4u /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/sgsmsg.c:1007:26: warning: format string is not a string literal (potentially insecure) [-Wformat-security] if (fprintf(fdmsgs, str) < 0) { ^~~ /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/sgsmsg.c:1081:26: warning: format string is not a string literal (potentially insecure) [-Wformat-security] (void) fprintf(stderr, Errmsg_use); ^~~~~~~~~~ 10 warnings generated. cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/string_table.c cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/findprime.c cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/common/zfs/ -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-ta! utological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/common/zfs/ -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-ta! utological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/common/zfs/ -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-ta! utological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/arm.arm/src/tmp/usr/lib/libzpool.so: undefined reference to `cpu_ticks' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[4]: stopped in /src/cddl/usr.bin/zinject *** Error code 1 Stop. bmake[3]: stopped in /src/cddl/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/cddl *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-06-04 01:17:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-06-04 01:17:29 - ERROR: failed to build world TB --- 2014-06-04 01:17:29 - 8428.98 user 1221.75 system 10013.71 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Jun 4 05:15:57 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB66E28A for ; Wed, 4 Jun 2014 05:15:57 +0000 (UTC) Received: from up-smx-s1.dmz.det.nsw.edu.au (up-smx-s1.det.nsw.edu.au [153.107.41.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 998BB231B for ; Wed, 4 Jun 2014 05:15:56 +0000 (UTC) Received: from itfsmtp5.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-smx-s1.dmz.det.nsw.edu.au (8.14.4/8.14.4) with ESMTP id s545FlUn030780 for ; Wed, 4 Jun 2014 15:15:47 +1000 Received: from SLPEXHT02.central.det.win (Not Verified[153.107.14.67]) by itfsmtp5.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Wed, 04 Jun 2014 15:15:46 +1000 Received: from SLPEXHUB01.central.det.win (153.107.14.8) by SLPEXHT02.central.det.win (153.107.14.67) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 4 Jun 2014 15:15:47 +1000 Received: from WPEXCHMBSL1021.central.det.win ([169.254.1.14]) by slpexhub01.central.det.win ([153.107.14.8]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 15:15:45 +1000 From: "Scott, Brian" To: "'arm@freebsd.org'" Subject: Changes to dwc_otg USB controller code (stable/10) Thread-Topic: Changes to dwc_otg USB controller code (stable/10) Thread-Index: Ac9/spahyxvDvUntT4SsSJgnL9lJHw== Date: Wed, 4 Jun 2014 05:15:45 +0000 Message-ID: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.107.9.240] x-route: TAFECORP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 05:15:57 -0000 Hi all, A recent (yesterday) build for raspberry-pi has non-functioning USB*. A p= revious build (23 May) is fine. A quick look shows a bunch of changes wer= e MFC'd in 11 days ago and other than that, nothing has changed in the US= B area for a while. I'm not an expert at tracking these things down thoug= h so I could have missed something. Is it just me that can't make it work? [I've overwritten the SD card with the new OS on it when trying the older= =20version and didn't save any messages. I should be able to repeat the t= est and get some messages if it will help anyone.] Brian Scott * USB keyboards (various types) and mouse fail to attach. Inserting USB m= emory stick prompts immediate reboot. Ethernet is functional (internal et= hernet is USB based) so not all USB is broken. ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-arm@FreeBSD.ORG Wed Jun 4 06:18:48 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F225791 for ; Wed, 4 Jun 2014 06:18:48 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5AF727C6 for ; Wed, 4 Jun 2014 06:18:47 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3F7FE1FE028; Wed, 4 Jun 2014 08:18:46 +0200 (CEST) Message-ID: <538EBA69.2070603@selasky.org> Date: Wed, 04 Jun 2014 08:19:21 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Scott, Brian" , "'arm@freebsd.org'" Subject: Re: Changes to dwc_otg USB controller code (stable/10) References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> In-Reply-To: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 06:18:48 -0000 On 06/04/14 07:15, Scott, Brian wrote: > Hi all, > > A recent (yesterday) build for raspberry-pi has non-functioning USB*. A previous build (23 May) is fine. A quick look shows a bunch of changes were MFC'd in 11 days ago and other than that, nothing has changed in the USB area for a while. I'm not an expert at tracking these things down though so I could have missed something. > > Is it just me that can't make it work? > > [I've overwritten the SD card with the new OS on it when trying the older version and didn't save any messages. I should be able to repeat the test and get some messages if it will help anyone.] > > Brian Scott > > * USB keyboards (various types) and mouse fail to attach. Inserting USB memory stick prompts immediate reboot. > Ethernet is functional (internal ethernet is USB based) so not all USB is broken. Hi, If you don't see a panic prompt, then you need to use an external USB HUB with own power supply to avoid that. I've just MFC'ed the last DWC OTG related patch from -head: http://svnweb.freebsd.org/changeset/base/267039 Can you build a new kernel including that patch. BTW: You only need to build a new kernel, you don't need to install a new userland. Can you show dmesg for the attach failures? --HPS From owner-freebsd-arm@FreeBSD.ORG Wed Jun 4 10:12:52 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79F0262D for ; Wed, 4 Jun 2014 10:12:52 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D78A2E64 for ; Wed, 4 Jun 2014 10:12:52 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8E58E1FE02A; Wed, 4 Jun 2014 12:12:49 +0200 (CEST) Message-ID: <538EF145.5020608@selasky.org> Date: Wed, 04 Jun 2014 12:13:25 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Scott, Brian" , "'arm@freebsd.org'" Subject: Re: Changes to dwc_otg USB controller code (stable/10) References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> In-Reply-To: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:12:52 -0000 Hi, I'm able to reproduce this only if I connect the device directly to the RPI-B. If I use an external HUB, no issue is seen. --HPS From owner-freebsd-arm@FreeBSD.ORG Wed Jun 4 10:29:52 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6635A9FB for ; Wed, 4 Jun 2014 10:29:52 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24D482F9C for ; Wed, 4 Jun 2014 10:29:51 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0596D1FE02A; Wed, 4 Jun 2014 12:29:49 +0200 (CEST) Message-ID: <538EF541.9050502@selasky.org> Date: Wed, 04 Jun 2014 12:30:25 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Scott, Brian" , "'arm@freebsd.org'" Subject: Re: Changes to dwc_otg USB controller code (stable/10) References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> In-Reply-To: <538EF145.5020608@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:29:52 -0000 On 06/04/14 12:13, Hans Petter Selasky wrote: > Hi, > > I'm able to reproduce this only if I connect the device directly to the > RPI-B. If I use an external HUB, no issue is seen. > --HPS I think the following patch will fix your issue: http://svnweb.freebsd.org/changeset/base/267044 Please try and report back. --HPS From owner-freebsd-arm@FreeBSD.ORG Wed Jun 4 11:50:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5910C34 for ; Wed, 4 Jun 2014 11:50:45 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CEC22829 for ; Wed, 4 Jun 2014 11:50:45 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id w62so8444026wes.30 for ; Wed, 04 Jun 2014 04:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=REJEoHUBUt4XLxUpkYdAuvnUodZ9joNqYMiVC13sGd0=; b=vfTVj96gaayEpfNeWuzuiVCqAZDrHxZ5jT8OPj5LP6290ZSbjMb3ptgpDmRI9D8ROM XIRXWJB2SRu8MCEns2btHBPoY93XKGeOWFNrcCKyxzyJXd8PKOYHZyIbvduZcOL2qtro w65tv5C+cUS1kln5P+RaXvQwolJxaO5nT/aV0hjcpvv7uk2aQkJAIkIzmt2ob5JQwu4B waf7Oy8++4gJZjR1dOtjhnhdEaj/hsInvYBcaRBpNKjg0n93ypga88kvW+8ozw6U5kUJ yLQySaSFKbr36ef2kQ4ehMf84W7C2Ztlub800gqnfjpr81KgYl2+cdQFx4y/AaVDL7Ud KxlA== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr4052184wjb.73.1401882642679; Wed, 04 Jun 2014 04:50:42 -0700 (PDT) Received: by 10.194.39.230 with HTTP; Wed, 4 Jun 2014 04:50:42 -0700 (PDT) In-Reply-To: <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> References: <53850478.3080302@wp.pl> <53854768.1020904@hot.ee> <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> Date: Wed, 4 Jun 2014 13:50:42 +0200 Message-ID: Subject: Re: RPi + FreeBSD + Xorg + XBMC player ? From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= To: "Scott, Brian" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 11:50:45 -0000 2014-05-29 3:03 GMT+02:00 Scott, Brian : > Has anyone actually got X running recently? I've just been trying to buil= d a few packages on the Pi and it looks like things have moved on since the= various tutorials on the web were written. The scfb video driver is includ= ed in ports now but other broken-ness in xorg-server (dri) stops it being = built. > > Haven't even started trying to get applications like XBMC going. Hi, I have submitted some patches to get X running (see PR/181318). XMBC is only for i386 and amd64 From owner-freebsd-arm@FreeBSD.ORG Wed Jun 4 13:03:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96025984 for ; Wed, 4 Jun 2014 13:03:51 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 598F72FF2 for ; Wed, 4 Jun 2014 13:03:51 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j7so6972929qaq.3 for ; Wed, 04 Jun 2014 06:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kmpERFC7WYL9bQzTRrtS1Z48ephIwF7qOuGLqnwg4tE=; b=gQIghNSo/TiAqERcdt6WMm01ZZPFXXPC1XfDek9nuu8YgtiMVg5cig+DR5Rc6iHRph QJ4fuF740hnjcNxHsuJntfMPMcF3mFl99TDyqNH/xfN0KqThqkGBc3qaUn+fpdVNtcLb PPIxD2h822KIuq5VrP9GhE/luOWUakDlwxqXlSm0WbkfztZdsoPpF5xHqvAOeOIEuWMz hPYXnvhuMyXQds2zx1zg2VXdlqUtz51YHKy1LEAhba2qdzBiSQ5+jupmppQjE0QpdVIA d6Mv5V0JdEZTrvXDerGlnCtbloUpubjOwRbvA4TqmEoZT8BYuM5+ESbJ5+6Iop0q9jVF +wMQ== MIME-Version: 1.0 X-Received: by 10.224.55.83 with SMTP id t19mr6219690qag.42.1401887029957; Wed, 04 Jun 2014 06:03:49 -0700 (PDT) Received: by 10.224.217.66 with HTTP; Wed, 4 Jun 2014 06:03:49 -0700 (PDT) Date: Wed, 4 Jun 2014 22:03:49 +0900 Message-ID: Subject: only issue on FreeBSD/arm(beaglebone black) with multi channel USB audio device. From: Yoshiro MIHIRA To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 13:03:51 -0000 I have multi-channel USB audio device. *1 Kyo-On DIGI(sorry,this page was writtin in Japanese) http://www.area-powers.jp/product/usb_product/product/kyo-on/u1soundt4.html I can use this device without issue on **FreeBSD/i386-current**[OK]. (only I set below setting in /boot/loader.conf hw.usb.uaudio.default_ channels=16 [FYI] we discussed below thread. http://comments.gmane.org/gmane.os.freebsd.devel.usb/6213 I tried to use this USB audio on **FreeBSD/arm BeagleBone Black** same source tree(r267049). However I have noise sound **playback** sound[NG](mpg123 and wavplay). If I **record** this device on BeagleBone Black, there is no issues. If I use 2ch USB audio device, there is no issues on BeagleBone Black. Does someone have any idea to use this device on BeagleBone Black? Cheers. From owner-freebsd-arm@FreeBSD.ORG Wed Jun 4 13:09:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FF383E6 for ; Wed, 4 Jun 2014 13:09:29 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1ADD207A for ; Wed, 4 Jun 2014 13:09:28 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5C2DB1FE02A; Wed, 4 Jun 2014 15:09:27 +0200 (CEST) Message-ID: <538F1AAA.5000403@selasky.org> Date: Wed, 04 Jun 2014 15:10:02 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Yoshiro MIHIRA , freebsd-arm@freebsd.org Subject: Re: only issue on FreeBSD/arm(beaglebone black) with multi channel USB audio device. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 13:09:29 -0000 On 06/04/14 15:03, Yoshiro MIHIRA wrote: > I have multi-channel USB audio device. > > *1 Kyo-On DIGI(sorry,this page was writtin in Japanese) > http://www.area-powers.jp/product/usb_product/product/kyo-on/u1soundt4.html > > I can use this device without issue on **FreeBSD/i386-current**[OK]. > (only I set below setting in /boot/loader.conf > hw.usb.uaudio.default_ > channels=16 > > [FYI] we discussed below thread. > http://comments.gmane.org/gmane.os.freebsd.devel.usb/6213 > > I tried to use this USB audio on **FreeBSD/arm BeagleBone Black** same > source tree(r267049). > However I have noise sound **playback** sound[NG](mpg123 and wavplay). > If I **record** this device on BeagleBone Black, there is no issues. > > If I use 2ch USB audio device, there is no issues on BeagleBone Black. > > Does someone have any idea to use this device on BeagleBone Black? > Hi, Can you give some more information about your USB audio device: High Speed or Full Speed? What USB controllers are used? There are some limitations currently, that high-payload isochonous transfers are not fully supported by the non ehci/ohci/uhci/xhci controllers. That probably explains why only 2-channels are working. --HPS From owner-freebsd-arm@FreeBSD.ORG Wed Jun 4 13:39:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 257DD647 for ; Wed, 4 Jun 2014 13:39:09 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3DAD23A9 for ; Wed, 4 Jun 2014 13:39:08 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id DD9E61FE02A; Wed, 4 Jun 2014 15:39:07 +0200 (CEST) Message-ID: <538F219F.4090708@selasky.org> Date: Wed, 04 Jun 2014 15:39:43 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Yoshiro MIHIRA , freebsd-arm@freebsd.org Subject: Re: only issue on FreeBSD/arm(beaglebone black) with multi channel USB audio device. References: <538F1AAA.5000403@selasky.org> In-Reply-To: <538F1AAA.5000403@selasky.org> Content-Type: multipart/mixed; boundary="------------040301030404030009050306" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 13:39:09 -0000 This is a multi-part message in MIME format. --------------040301030404030009050306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/04/14 15:10, Hans Petter Selasky wrote: > On 06/04/14 15:03, Yoshiro MIHIRA wrote: >> I have multi-channel USB audio device. >> >> *1 Kyo-On DIGI(sorry,this page was writtin in Japanese) >> http://www.area-powers.jp/product/usb_product/product/kyo-on/u1soundt4.html >> >> >> I can use this device without issue on **FreeBSD/i386-current**[OK]. >> (only I set below setting in /boot/loader.conf >> hw.usb.uaudio.default_ >> channels=16 >> >> [FYI] we discussed below thread. >> http://comments.gmane.org/gmane.os.freebsd.devel.usb/6213 >> >> I tried to use this USB audio on **FreeBSD/arm BeagleBone Black** same >> source tree(r267049). >> However I have noise sound **playback** sound[NG](mpg123 and wavplay). >> If I **record** this device on BeagleBone Black, there is no issues. >> >> If I use 2ch USB audio device, there is no issues on BeagleBone Black. >> >> Does someone have any idea to use this device on BeagleBone Black? >> > > Hi, > > Can you give some more information about your USB audio device: > > High Speed or Full Speed? > > What USB controllers are used? > > There are some limitations currently, that high-payload isochonous > transfers are not fully supported by the non ehci/ohci/uhci/xhci > controllers. That probably explains why only 2-channels are working. > > --HPS Hi, If the musb controller is used, can you try the attached patch? --HPS --------------040301030404030009050306 Content-Type: text/x-diff; name="musb_otg.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="musb_otg.diff" === musb_otg.c ================================================================== --- musb_otg.c (revision 266950) +++ musb_otg.c (local) @@ -131,7 +131,7 @@ static void musbotg_standard_done(struct usb_xfer *); static void musbotg_interrupt_poll(struct musbotg_softc *); static void musbotg_root_intr(struct musbotg_softc *); -static int musbotg_channel_alloc(struct musbotg_softc *, struct musbotg_td *td); +static int musbotg_channel_alloc(struct musbotg_softc *, struct musbotg_td *td, uint8_t); static void musbotg_channel_free(struct musbotg_softc *, struct musbotg_td *td); static void musbotg_ep_int_set(struct musbotg_softc *sc, int channel, int on); @@ -149,7 +149,7 @@ }; static int -musbotg_channel_alloc(struct musbotg_softc *sc, struct musbotg_td *td) +musbotg_channel_alloc(struct musbotg_softc *sc, struct musbotg_td *td, uint8_t is_tx) { int ch; int ep; @@ -173,12 +173,23 @@ return (0); } - for (ch = 1; ch < MUSB2_EP_MAX; ch++) { - if (!(sc->sc_channel_mask & (1 << ch))) { - sc->sc_channel_mask |= (1 << ch); - musbotg_ep_int_set(sc, ch, 1); - return (ch); + for (ch = sc->sc_ep_max; ch != 0; ch--) { + if (sc->sc_channel_mask & (1 << ch)) + continue; + + /* verify FIFO size */ + if (is_tx) { + if (td->max_frame_size > + sc->sc_hw_ep_profile[ch].max_in_frame_size) + continue; + } else { + if (td->max_frame_size > + sc->sc_hw_ep_profile[ch].max_out_frame_size) + continue; } + sc->sc_channel_mask |= (1 << ch); + musbotg_ep_int_set(sc, ch, 1); + return (ch); } DPRINTFN(-1, "No available channels. Mask: %04x\n", sc->sc_channel_mask); @@ -377,7 +388,7 @@ sc = MUSBOTG_PC2SC(td->pc); if (td->channel == -1) - td->channel = musbotg_channel_alloc(sc, td); + td->channel = musbotg_channel_alloc(sc, td, 0); /* EP0 is busy, wait */ if (td->channel == -1) @@ -498,7 +509,7 @@ sc = MUSBOTG_PC2SC(td->pc); if (td->channel == -1) - td->channel = musbotg_channel_alloc(sc, td); + td->channel = musbotg_channel_alloc(sc, td, 1); /* EP0 is busy, wait */ if (td->channel == -1) @@ -870,7 +881,7 @@ sc = MUSBOTG_PC2SC(td->pc); if (td->channel == -1) - td->channel = musbotg_channel_alloc(sc, td); + td->channel = musbotg_channel_alloc(sc, td, 0); /* EP0 is busy, wait */ if (td->channel == -1) @@ -1049,7 +1060,7 @@ sc = MUSBOTG_PC2SC(td->pc); if (td->channel == -1) - td->channel = musbotg_channel_alloc(sc, td); + td->channel = musbotg_channel_alloc(sc, td, 1); /* No free EPs */ if (td->channel == -1) @@ -1259,7 +1270,7 @@ sc = MUSBOTG_PC2SC(td->pc); if (td->channel == -1) - td->channel = musbotg_channel_alloc(sc, td); + td->channel = musbotg_channel_alloc(sc, td, 0); /* EP0 is busy, wait */ if (td->channel == -1) @@ -1346,7 +1357,7 @@ sc = MUSBOTG_PC2SC(td->pc); if (td->channel == -1) - td->channel = musbotg_channel_alloc(sc, td); + td->channel = musbotg_channel_alloc(sc, td, 1); /* EP0 is busy, wait */ if (td->channel == -1) @@ -1419,7 +1430,7 @@ sc = MUSBOTG_PC2SC(td->pc); if (td->channel == -1) - td->channel = musbotg_channel_alloc(sc, td); + td->channel = musbotg_channel_alloc(sc, td, 0); /* EP0 is busy, wait */ if (td->channel == -1) @@ -1567,7 +1578,7 @@ sc = MUSBOTG_PC2SC(td->pc); if (td->channel == -1) - td->channel = musbotg_channel_alloc(sc, td); + td->channel = musbotg_channel_alloc(sc, td, 1); /* EP0 is busy, wait */ if (td->channel == -1) @@ -1695,7 +1706,7 @@ sc = MUSBOTG_PC2SC(td->pc); if (td->channel == -1) - td->channel = musbotg_channel_alloc(sc, td); + td->channel = musbotg_channel_alloc(sc, td, 0); /* No free EPs */ if (td->channel == -1) @@ -1917,7 +1928,7 @@ sc = MUSBOTG_PC2SC(td->pc); if (td->channel == -1) - td->channel = musbotg_channel_alloc(sc, td); + td->channel = musbotg_channel_alloc(sc, td, 1); /* No free EPs */ if (td->channel == -1) @@ -3226,6 +3237,7 @@ pf->support_out = 1; } else if (frx && (temp <= nrx)) { pf->max_out_frame_size = 1 << frx; + pf->max_in_frame_size = 0; pf->is_simplex = 1; /* simplex */ pf->support_multi_buffer = 1; pf->support_bulk = 1; @@ -3234,6 +3246,7 @@ pf->support_out = 1; } else if (ftx && (temp <= ntx)) { pf->max_in_frame_size = 1 << ftx; + pf->max_out_frame_size = 0; pf->is_simplex = 1; /* simplex */ pf->support_multi_buffer = 1; pf->support_bulk = 1; @@ -3287,18 +3300,6 @@ } static void -musbotg_suspend(struct musbotg_softc *sc) -{ - /* TODO */ -} - -static void -musbotg_resume(struct musbotg_softc *sc) -{ - /* TODO */ -} - -static void musbotg_do_poll(struct usb_bus *bus) { struct musbotg_softc *sc = MUSBOTG_BUS2SC(bus); @@ -4214,13 +4215,13 @@ switch (state) { case USB_HW_POWER_SUSPEND: - musbotg_suspend(sc); + musbotg_uninit(sc); break; case USB_HW_POWER_SHUTDOWN: musbotg_uninit(sc); break; case USB_HW_POWER_RESUME: - musbotg_resume(sc); + musbotg_init(sc); break; default: break; --------------040301030404030009050306-- From owner-freebsd-arm@FreeBSD.ORG Wed Jun 4 22:08:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 589EF56F for ; Wed, 4 Jun 2014 22:08:05 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 189B829F6 for ; Wed, 4 Jun 2014 22:08:05 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id s7so205623qap.20 for ; Wed, 04 Jun 2014 15:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OiP1ErvLdvf+RM+PSKNWUeium+LRQutwCjiWqjDNc7g=; b=jOyVjVtZYtuiLrtrST4MEefvrh7xr2RDpAwuncGRVJ9wB47DkfIufGLy6UAsq7a6GO LAeC9xn730K3QZFyNRR2+A+pm3GS1n4ezTfeWd2ccYbTRRjk0qwRaKWlNQYJOeGKhzB/ fI2axgSMUpaE0vORi3KHZ3sN0r6OleviEdAJyeURmHXznjyjrcyCJHIMYWTDDuxZCyR3 bvgezo3PckJYln+6FqgfWY0IlamPkqdeVc234S+6vdgz6+2WjfiFowCJAEt7e+h8BQXq aR/UFrAEqQ12jFMWtRAiWadP+Gz4HqtFytmCJdYi5VmXTm0Gfkn+mcRSbRerB1Tt/huk eudw== MIME-Version: 1.0 X-Received: by 10.140.23.166 with SMTP id 35mr71507772qgp.89.1401919684223; Wed, 04 Jun 2014 15:08:04 -0700 (PDT) Received: by 10.224.217.66 with HTTP; Wed, 4 Jun 2014 15:08:04 -0700 (PDT) In-Reply-To: <538F219F.4090708@selasky.org> References: <538F1AAA.5000403@selasky.org> <538F219F.4090708@selasky.org> Date: Thu, 5 Jun 2014 07:08:04 +0900 Message-ID: Subject: Re: only issue on FreeBSD/arm(beaglebone black) with multi channel USB audio device. From: Yoshiro MIHIRA To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:08:05 -0000 >If the musb controller is used, can you try the attached patch? Yes, BeagleBone Black has musb. But I could not apply your patch. patch < musb_otg.diff how to apply your patch on FreeBSD? 2014-06-04 22:39 GMT+09:00 Hans Petter Selasky : > On 06/04/14 15:10, Hans Petter Selasky wrote: > >> On 06/04/14 15:03, Yoshiro MIHIRA wrote: >> >>> I have multi-channel USB audio device. >>> >>> *1 Kyo-On DIGI(sorry,this page was writtin in Japanese) >>> http://www.area-powers.jp/product/usb_product/product/ >>> kyo-on/u1soundt4.html >>> >>> >>> I can use this device without issue on **FreeBSD/i386-current**[OK]. >>> (only I set below setting in /boot/loader.conf >>> hw.usb.uaudio.default_ >>> channels=16 >>> >>> [FYI] we discussed below thread. >>> http://comments.gmane.org/gmane.os.freebsd.devel.usb/6213 >>> >>> I tried to use this USB audio on **FreeBSD/arm BeagleBone Black** same >>> source tree(r267049). >>> However I have noise sound **playback** sound[NG](mpg123 and wavplay). >>> If I **record** this device on BeagleBone Black, there is no issues. >>> >>> If I use 2ch USB audio device, there is no issues on BeagleBone Black. >>> >>> Does someone have any idea to use this device on BeagleBone Black? >>> >>> >> Hi, >> >> Can you give some more information about your USB audio device: >> >> High Speed or Full Speed? >> >> What USB controllers are used? >> >> There are some limitations currently, that high-payload isochonous >> transfers are not fully supported by the non ehci/ohci/uhci/xhci >> controllers. That probably explains why only 2-channels are working. >> >> --HPS >> > > Hi, > > If the musb controller is used, can you try the attached patch? > > --HPS > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 05:34:55 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC703B24 for ; Thu, 5 Jun 2014 05:34:55 +0000 (UTC) Received: from up-mx4.det.nsw.edu.au (up-mx4.det.nsw.edu.au [153.107.105.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53A3B2F3B for ; Thu, 5 Jun 2014 05:34:54 +0000 (UTC) Received: from itfsmtp5.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-mx4.det.nsw.edu.au (8.13.8/8.13.8) with ESMTP id s554fTJ8014070; Thu, 5 Jun 2014 14:41:29 +1000 Received: from SLPEXHT02.central.det.win (Not Verified[153.107.14.67]) by itfsmtp5.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Thu, 05 Jun 2014 14:41:25 +1000 Received: from UGPEXHUB01.central.det.win (153.107.78.92) by SLPEXHT02.central.det.win (153.107.14.67) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 5 Jun 2014 14:41:26 +1000 Received: from WPEXCHMBSL1021.central.det.win ([169.254.1.14]) by ugpexhub01.central.det.win ([153.107.78.92]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 14:41:25 +1000 From: "Scott, Brian" To: "'Hans Petter Selasky'" , "'arm@freebsd.org'" Subject: RE: Changes to dwc_otg USB controller code (stable/10) Thread-Topic: Changes to dwc_otg USB controller code (stable/10) Thread-Index: AQHPf92fyxvDvUntT4SsSJgnL9lJH5tgGJ+AgAHXSuA= Date: Thu, 5 Jun 2014 04:41:24 +0000 Message-ID: <7DB382CFB050654DBFF7A39B1F8056EB3321C1AB@WPEXCHMBSL1021.central.det.win> References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> In-Reply-To: <538EF541.9050502@selasky.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.107.9.240] x-route: TAFECORP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 05:34:55 -0000 Hi, A few little problems with the compiler... /usr/src/sys/modules/usb/dwc_otg/../../../dev/usb/controller/dwc_otg.c:36= 92:21: error: assigning to 'struct usb_bus_methods *' from 'const struct = usb_bus_methods *' discards qualifiers [-Werror,-Wincompatible-pointer-ty= pes-discards-qualifiers] =20 sc->sc_bus.methods =3D &dwc_otg_bus_methods; =20 ^ ~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/modules/usb/dwc_otg/../../../dev/usb/controller/dwc_otg.c:47= 27:16: error: assigning to 'struct usb_pipe_methods *' from 'const struct= =20usb_pipe_methods *' discards qualifiers [-Werror,-Wincompatible-pointe= r-types-discards-qualifiers] =20 ep->methods =3D &dwc_otg_device_isoc_methods; =20 ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/modules/usb/dwc_otg/../../../dev/usb/controller/dwc_otg.c:47= 29:16: error: assigning to 'struct usb_pipe_methods *' from 'const struct= =20usb_pipe_methods *' discards qualifiers [-Werror,-Wincompatible-pointe= r-types-discards-qualifiers] =20 ep->methods =3D &dwc_otg_device_non_isoc_method= s; =20 ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3 errors generated. [I guessing I did this right: the changeset just listed the one file chan= ged so I copied the file over to my stable/10 source tree and compiled. I= f there are other related things I need to track down then let me know] Brian -----Original Message----- From: Hans Petter Selasky [mailto:hps@selasky.org]=20 Sent: Wednesday, 4 June 2014 8:30 PM To: Scott, Brian; 'arm@freebsd.org' Subject: Re: Changes to dwc_otg USB controller code (stable/10) On 06/04/14 12:13, Hans Petter Selasky wrote: > Hi, > > I'm able to reproduce this only if I connect the device directly to the= > RPI-B. If I use an external HUB, no issue is seen. > --HPS I think the following patch will fix your issue: http://svnweb.freebsd.org/changeset/base/267044 Please try and report back. --HPS ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 05:51:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F144E39 for ; Thu, 5 Jun 2014 05:51:27 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3083520B8 for ; Thu, 5 Jun 2014 05:51:26 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0BADE1FE02A; Thu, 5 Jun 2014 07:51:25 +0200 (CEST) Message-ID: <53900580.4080901@selasky.org> Date: Thu, 05 Jun 2014 07:52:00 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Yoshiro MIHIRA Subject: Re: only issue on FreeBSD/arm(beaglebone black) with multi channel USB audio device. References: <538F1AAA.5000403@selasky.org> <538F219F.4090708@selasky.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 05:51:27 -0000 On 06/05/14 00:08, Yoshiro MIHIRA wrote: > >If the musb controller is used, can you try the attached patch? > > Yes, BeagleBone Black has musb. > But I could not apply your patch. > > patch < musb_otg.diff > > how to apply your patch on FreeBSD? cd /usr/src/sys/dev/usb/controller cat musb_otg.diff | patch --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 05:54:29 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1063FC5 for ; Thu, 5 Jun 2014 05:54:29 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6259920E1 for ; Thu, 5 Jun 2014 05:54:29 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id BE4C71FE02A; Thu, 5 Jun 2014 07:54:28 +0200 (CEST) Message-ID: <53900636.30700@selasky.org> Date: Thu, 05 Jun 2014 07:55:02 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Scott, Brian" , "'arm@freebsd.org'" Subject: Re: Changes to dwc_otg USB controller code (stable/10) References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321C1AB@WPEXCHMBSL1021.central.det.win> In-Reply-To: <7DB382CFB050654DBFF7A39B1F8056EB3321C1AB@WPEXCHMBSL1021.central.det.win> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 05:54:29 -0000 On 06/05/14 06:41, Scott, Brian wrote: > Hi, > > A few little problems with the compiler... > > /usr/src/sys/modules/usb/dwc_otg/../../../dev/usb/controller/dwc_otg.c:3692:21: error: assigning to 'struct usb_bus_methods *' from 'const struct usb_bus_methods *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] > sc->sc_bus.methods = &dwc_otg_bus_methods; > ^ ~~~~~~~~~~~~~~~~~~~~ > /usr/src/sys/modules/usb/dwc_otg/../../../dev/usb/controller/dwc_otg.c:4727:16: error: assigning to 'struct usb_pipe_methods *' from 'const struct usb_pipe_methods *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] > ep->methods = &dwc_otg_device_isoc_methods; > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/sys/modules/usb/dwc_otg/../../../dev/usb/controller/dwc_otg.c:4729:16: error: assigning to 'struct usb_pipe_methods *' from 'const struct usb_pipe_methods *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] > ep->methods = &dwc_otg_device_non_isoc_methods; > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 3 errors generated. > > [I guessing I did this right: the changeset just listed the one file changed so I copied the file over to my stable/10 source tree and compiled. If there are other related things I need to track down then let me know] > > Brian Hi, That won't work. You need to patch the 10-stable sources: fetch -o dwc_otg.diff "http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/dwc_otg.c?r1=266833&r2=267044&view=patch" cd /usr/src/sys cat dwc_otg.diff | patch -p2 --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 05:56:16 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4C45104 for ; Thu, 5 Jun 2014 05:56:16 +0000 (UTC) Received: from up-smx-s1.dmz.det.nsw.edu.au (up-smx-s1.det.nsw.edu.au [153.107.41.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4075220F6 for ; Thu, 5 Jun 2014 05:56:15 +0000 (UTC) Received: from slppmxmm01.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-smx-s1.dmz.det.nsw.edu.au (8.14.4/8.14.4) with ESMTP id s555u5SL003481; Thu, 5 Jun 2014 15:56:06 +1000 Received: from SLPEXHT01.central.det.win (Not Verified[153.107.14.60]) by slppmxmm01.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Thu, 05 Jun 2014 15:56:05 +1000 Received: from SLPEXHUB01.central.det.win (153.107.14.8) by SLPEXHT01.central.det.win (153.107.14.60) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 5 Jun 2014 15:56:06 +1000 Received: from WPEXCHMBSL1021.central.det.win ([169.254.1.14]) by slpexhub01.central.det.win ([153.107.14.8]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 15:56:02 +1000 From: "Scott, Brian" To: Hans Petter Selasky , "'arm@freebsd.org'" Subject: RE: Changes to dwc_otg USB controller code (stable/10) Thread-Topic: Changes to dwc_otg USB controller code (stable/10) Thread-Index: AQHPf92fyxvDvUntT4SsSJgnL9lJH5tgGJ+AgAHq/BA= Date: Thu, 5 Jun 2014 05:56:00 +0000 Message-ID: <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> In-Reply-To: <538EF541.9050502@selasky.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.107.9.240] x-route: TAFECORP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 05:56:16 -0000 Hans Petter, Good news and bad news. If I add some casts to the code to make it compil= e (don't know if its valid or not, casting from a constant to a non-const= ant could be ugly and I haven't looked beyond the error messages), I can = now boot the system and the various USB devices are recognised properly. The bad news is that the keyboard is very intermittent now. Many characte= rs are simply being dropped when I type. Sometimes I get a character repe= ating as though the keyboard has gone into repeat mode, suggesting that a= =20character up event has been lost. Moving the mouse around has it freez= e every few seconds then resume. I have had a similar behaviour on another raspberry pi at home that I've = just been blaming on poor hardware. This means that I may be seeing an ol= der problem here. Don't know. Thanks, Brian -----Original Message----- From: Hans Petter Selasky [mailto:hps@selasky.org]=20 Sent: Wednesday, 4 June 2014 8:30 PM To: Scott, Brian; 'arm@freebsd.org' Subject: Re: Changes to dwc_otg USB controller code (stable/10) On 06/04/14 12:13, Hans Petter Selasky wrote: > Hi, > > I'm able to reproduce this only if I connect the device directly to the= > RPI-B. If I use an external HUB, no issue is seen. > --HPS I think the following patch will fix your issue: http://svnweb.freebsd.org/changeset/base/267044 Please try and report back. --HPS ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 06:09:31 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 220F664C for ; Thu, 5 Jun 2014 06:09:31 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8CB221F4 for ; Thu, 5 Jun 2014 06:09:30 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 40C771FE02A; Thu, 5 Jun 2014 08:09:29 +0200 (CEST) Message-ID: <539009BB.5030906@selasky.org> Date: Thu, 05 Jun 2014 08:10:03 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Scott, Brian" , "'arm@freebsd.org'" Subject: Re: Changes to dwc_otg USB controller code (stable/10) References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> In-Reply-To: <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 06:09:31 -0000 On 06/05/14 07:56, Scott, Brian wrote: > Hans Petter, > > Good news and bad news. If I add some casts to the code to make it compile (don't know if its valid or not, casting from a constant to a non-constant could be ugly and I haven't looked beyond the error messages), I can now boot the system and the various USB devices are recognised properly. > > The bad news is that the keyboard is very intermittent now. Many characters are simply being dropped when I type. Sometimes I get a character repeating as though the keyboard has gone into repeat mode, suggesting that a character up event has been lost. Moving the mouse around has it freeze every few seconds then resume. > > I have had a similar behaviour on another raspberry pi at home that I've just been blaming on poor hardware. This means that I may be seeing an older problem here. Don't know. Hi, I'll see if I can reproduce. --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 06:13:57 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B69256C2 for ; Thu, 5 Jun 2014 06:13:57 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78BB82285 for ; Thu, 5 Jun 2014 06:13:57 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D6CFF1FE02A; Thu, 5 Jun 2014 08:13:56 +0200 (CEST) Message-ID: <53900AC7.5070402@selasky.org> Date: Thu, 05 Jun 2014 08:14:31 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Scott, Brian" , "'arm@freebsd.org'" Subject: Re: Changes to dwc_otg USB controller code (stable/10) References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> <539009BB.5030906@selasky.org> In-Reply-To: <539009BB.5030906@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 06:13:57 -0000 On 06/05/14 08:10, Hans Petter Selasky wrote: > On 06/05/14 07:56, Scott, Brian wrote: >> Hans Petter, >> >> Good news and bad news. If I add some casts to the code to make it >> compile (don't know if its valid or not, casting from a constant to a >> non-constant could be ugly and I haven't looked beyond the error >> messages), I can now boot the system and the various USB devices are >> recognised properly. >> >> The bad news is that the keyboard is very intermittent now. Many >> characters are simply being dropped when I type. Sometimes I get a >> character repeating as though the keyboard has gone into repeat mode, >> suggesting that a character up event has been lost. Moving the mouse >> around has it freeze every few seconds then resume. >> >> I have had a similar behaviour on another raspberry pi at home that >> I've just been blaming on poor hardware. This means that I may be >> seeing an older problem here. Don't know. > > Hi, > > I'll see if I can reproduce. > Reminds me, you probably should grab this patch aswell: http://svnweb.freebsd.org/changeset/base/265913 I'll see if I can get it MFC'ed. --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 06:18:09 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 533D99B5 for ; Thu, 5 Jun 2014 06:18:09 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 149F922BF for ; Thu, 5 Jun 2014 06:18:09 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 75C071FE02A; Thu, 5 Jun 2014 08:18:08 +0200 (CEST) Message-ID: <53900BC2.3090701@selasky.org> Date: Thu, 05 Jun 2014 08:18:42 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Scott, Brian" , "'arm@freebsd.org'" Subject: Re: Changes to dwc_otg USB controller code (stable/10) References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> <539009BB.5030906@selasky.org> <53900AC7.5070402@selasky.org> In-Reply-To: <53900AC7.5070402@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 06:18:09 -0000 On 06/05/14 08:14, Hans Petter Selasky wrote: > On 06/05/14 08:10, Hans Petter Selasky wrote: >> On 06/05/14 07:56, Scott, Brian wrote: >>> Hans Petter, >>> >>> Good news and bad news. If I add some casts to the code to make it >>> compile (don't know if its valid or not, casting from a constant to a >>> non-constant could be ugly and I haven't looked beyond the error >>> messages), I can now boot the system and the various USB devices are >>> recognised properly. >>> >>> The bad news is that the keyboard is very intermittent now. Many >>> characters are simply being dropped when I type. Sometimes I get a >>> character repeating as though the keyboard has gone into repeat mode, >>> suggesting that a character up event has been lost. Moving the mouse >>> around has it freeze every few seconds then resume. >>> >>> I have had a similar behaviour on another raspberry pi at home that >>> I've just been blaming on poor hardware. This means that I may be >>> seeing an older problem here. Don't know. >> >> Hi, >> >> I'll see if I can reproduce. >> > > Reminds me, you probably should grab this patch aswell: > > http://svnweb.freebsd.org/changeset/base/265913 > > I'll see if I can get it MFC'ed. Seems to already be MFC'ed. --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 06:31:08 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1D94FE8 for ; Thu, 5 Jun 2014 06:31:08 +0000 (UTC) Received: from up-smx-s3.dmz.det.nsw.edu.au (up-smx-s3.det.nsw.edu.au [153.107.41.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 465CB2419 for ; Thu, 5 Jun 2014 06:31:06 +0000 (UTC) Received: from itfsmtp5.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-smx-s3.dmz.det.nsw.edu.au (8.14.4/8.14.4) with ESMTP id s556V3Un008226; Thu, 5 Jun 2014 16:31:03 +1000 Received: from SLPEXHT01.central.det.win (Not Verified[153.107.14.60]) by itfsmtp5.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Thu, 05 Jun 2014 16:31:02 +1000 Received: from WPEXCHHTSL1041.central.det.win (153.107.14.175) by SLPEXHT01.central.det.win (153.107.14.60) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 5 Jun 2014 16:31:03 +1000 Received: from WPEXCHMBSL1021.central.det.win ([169.254.1.14]) by WPEXCHHTSL1041.central.det.win ([153.107.14.175]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 16:31:02 +1000 From: "Scott, Brian" To: Hans Petter Selasky , "'arm@freebsd.org'" Subject: RE: Changes to dwc_otg USB controller code (stable/10) Thread-Topic: Changes to dwc_otg USB controller code (stable/10) Thread-Index: AQHPf92fyxvDvUntT4SsSJgnL9lJH5tgGJ+AgAHxGsD//1m7gIAAASwAgACpDAA= Date: Thu, 5 Jun 2014 06:31:01 +0000 Message-ID: <7DB382CFB050654DBFF7A39B1F8056EB3321D251@WPEXCHMBSL1021.central.det.win> References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> <539009BB.5030906@selasky.org> <53900AC7.5070402@selasky.org> <53900BC2.3090701@selasky.org> In-Reply-To: <53900BC2.3090701@selasky.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.107.9.240] x-route: TAFECORP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 06:31:08 -0000 Hi, Just rebuilt using the 'patched' version of the file rather than replacin= g the whole file. Compiles without problems. The other symptoms remain (erratic mouse movement, dropped keyboard chara= cters) on the new version. Thanks, Brian -----Original Message----- From: Hans Petter Selasky [mailto:hps@selasky.org]=20 Sent: Thursday, 5 June 2014 4:19 PM To: Scott, Brian; 'arm@freebsd.org' Subject: Re: Changes to dwc_otg USB controller code (stable/10) On 06/05/14 08:14, Hans Petter Selasky wrote: > On 06/05/14 08:10, Hans Petter Selasky wrote: >> On 06/05/14 07:56, Scott, Brian wrote: >>> Hans Petter, >>> >>> Good news and bad news. If I add some casts to the code to make it >>> compile (don't know if its valid or not, casting from a constant to a= >>> non-constant could be ugly and I haven't looked beyond the error >>> messages), I can now boot the system and the various USB devices are >>> recognised properly. >>> >>> The bad news is that the keyboard is very intermittent now. Many >>> characters are simply being dropped when I type. Sometimes I get a >>> character repeating as though the keyboard has gone into repeat mode,= >>> suggesting that a character up event has been lost. Moving the mouse >>> around has it freeze every few seconds then resume. >>> >>> I have had a similar behaviour on another raspberry pi at home that >>> I've just been blaming on poor hardware. This means that I may be >>> seeing an older problem here. Don't know. >> >> Hi, >> >> I'll see if I can reproduce. >> > > Reminds me, you probably should grab this patch aswell: > > http://svnweb.freebsd.org/changeset/base/265913 > > I'll see if I can get it MFC'ed. Seems to already be MFC'ed. --HPS ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 06:31:43 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FD55B0 for ; Thu, 5 Jun 2014 06:31:43 +0000 (UTC) Received: from up-smx-s3.dmz.det.nsw.edu.au (up-smx-s3.det.nsw.edu.au [153.107.41.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25BDA2421 for ; Thu, 5 Jun 2014 06:31:42 +0000 (UTC) Received: from slppmxmm02.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-smx-s3.dmz.det.nsw.edu.au (8.14.4/8.14.4) with ESMTP id s555wp0j003836; Thu, 5 Jun 2014 15:58:51 +1000 Received: from UGPEXHT01.central.det.win (Not Verified[153.107.78.56]) by slppmxmm02.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Thu, 05 Jun 2014 15:58:50 +1000 Received: from UGPEXHUB01.central.det.win (153.107.78.92) by UGPEXHT01.central.det.win (153.107.78.56) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 5 Jun 2014 15:58:50 +1000 Received: from WPEXCHMBSL1021.central.det.win ([169.254.1.14]) by ugpexhub01.central.det.win ([153.107.78.92]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 15:58:50 +1000 From: "Scott, Brian" To: "'Hans Petter Selasky'" , "'arm@freebsd.org'" Subject: RE: Changes to dwc_otg USB controller code (stable/10) Thread-Topic: Changes to dwc_otg USB controller code (stable/10) Thread-Index: AQHPf92fyxvDvUntT4SsSJgnL9lJH5tgGJ+AgAHs56aAAAEbsA== Date: Thu, 5 Jun 2014 05:58:49 +0000 Message-ID: <7DB382CFB050654DBFF7A39B1F8056EB3321D20F@WPEXCHMBSL1021.central.det.win> References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321C1AB@WPEXCHMBSL1021.central.det.win> <53900636.30700@selasky.org> In-Reply-To: <53900636.30700@selasky.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.107.9.240] x-route: TAFECORP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 06:31:43 -0000 OK, I'll try that. Thanks. -----Original Message----- From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freebsd.org= ] On Behalf Of Hans Petter Selasky Sent: Thursday, 5 June 2014 3:55 PM To: Scott, Brian; 'arm@freebsd.org' Subject: Re: Changes to dwc_otg USB controller code (stable/10) On 06/05/14 06:41, Scott, Brian wrote: > Hi, > > A few little problems with the compiler... > > /usr/src/sys/modules/usb/dwc_otg/../../../dev/usb/controller/dwc_otg.c:= 3692:21: error: assigning to 'struct usb_bus_methods *' from 'const struc= t usb_bus_methods *' discards qualifiers [-Werror,-Wincompatible-pointer-= types-discards-qualifiers] > sc->sc_bus.methods =3D &dwc_otg_bus_methods; > ^ ~~~~~~~~~~~~~~~~~~~~ > /usr/src/sys/modules/usb/dwc_otg/../../../dev/usb/controller/dwc_otg.c:= 4727:16: error: assigning to 'struct usb_pipe_methods *' from 'const stru= ct usb_pipe_methods *' discards qualifiers [-Werror,-Wincompatible-pointe= r-types-discards-qualifiers] > ep->methods =3D &dwc_otg_device_isoc_methods; > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/sys/modules/usb/dwc_otg/../../../dev/usb/controller/dwc_otg.c:= 4729:16: error: assigning to 'struct usb_pipe_methods *' from 'const stru= ct usb_pipe_methods *' discards qualifiers [-Werror,-Wincompatible-pointe= r-types-discards-qualifiers] > ep->methods =3D &dwc_otg_device_non_isoc_metho= ds; > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= > 3 errors generated. > > [I guessing I did this right: the changeset just listed the one file ch= anged so I copied the file over to my stable/10 source tree and compiled.= =20If there are other related things I need to track down then let me kno= w] > > Brian Hi, That won't work. You need to patch the 10-stable sources: fetch -o dwc_otg.diff=20 "http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/dwc_otg.c?r1=3D= 266833&r2=3D267044&view=3Dpatch" cd /usr/src/sys cat dwc_otg.diff | patch -p2 --HPS _______________________________________________ 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" ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 13:43:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEA4FC40 for ; Thu, 5 Jun 2014 13:43:59 +0000 (UTC) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DA382F49 for ; Thu, 5 Jun 2014 13:43:59 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id q108so1556278qgd.33 for ; Thu, 05 Jun 2014 06:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NUx1bVrIIYCZF/WyhVOPWvwem/a50OmdGZvK5Fh8rGU=; b=O55XK79ra6ldyatKcS9/Z2cQNtGMQK20bBRjngfnxUZC8auGjVvAGtcY+t+5ttK01P 2z93yZvnW3NckL8fHgO/dOtXu98DlsZkFZFSgK3K5W1vuKx1qbNxtZStvODmimER3IU9 +lmLg+1LeCW8dNAgX7/1+CDa2I1weiW+c8cYuyl7yQLKaSUIxz6lhvj3EEPbOYshM53n xJu/nvMPm1ssuw4RQdDVkAByq9vwWiAiN759cDxsPzJGIYKgjFnemtUO7UofEHQnXE3y r3mjqIICInCEEDlMsU6H0W2aCq5wpA2x02ECBdQYyQTp3QlRfwjjeIoq0MYF4w8Fb20n oo1Q== MIME-Version: 1.0 X-Received: by 10.229.27.198 with SMTP id j6mr82107024qcc.12.1401975838737; Thu, 05 Jun 2014 06:43:58 -0700 (PDT) Received: by 10.224.217.66 with HTTP; Thu, 5 Jun 2014 06:43:58 -0700 (PDT) In-Reply-To: <53900580.4080901@selasky.org> References: <538F1AAA.5000403@selasky.org> <538F219F.4090708@selasky.org> <53900580.4080901@selasky.org> Date: Thu, 5 Jun 2014 22:43:58 +0900 Message-ID: Subject: Re: only issue on FreeBSD/arm(beaglebone black) with multi channel USB audio device. From: Yoshiro MIHIRA To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:44:00 -0000 Finally I applied Hans-san's patch to musb_otg.c. However the problem was not solved. Do you have any suggetion, Hans-san? Yoshiro MIHIRA 2014-06-05 14:52 GMT+09:00 Hans Petter Selasky : > On 06/05/14 00:08, Yoshiro MIHIRA wrote: > >> >If the musb controller is used, can you try the attached patch? >> >> Yes, BeagleBone Black has musb. >> But I could not apply your patch. >> >> patch < musb_otg.diff >> >> how to apply your patch on FreeBSD? >> > > > cd /usr/src/sys/dev/usb/controller > cat musb_otg.diff | patch > > --HPS > From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 18:26:53 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07CD1896 for ; Thu, 5 Jun 2014 18:26:53 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A291B2BC3 for ; Thu, 5 Jun 2014 18:26:52 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 488A61FE02A; Thu, 5 Jun 2014 20:26:49 +0200 (CEST) Message-ID: <5390B68B.5070802@selasky.org> Date: Thu, 05 Jun 2014 20:27:23 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Scott, Brian" , "'arm@freebsd.org'" Subject: Re: Changes to dwc_otg USB controller code (stable/10) References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> <539009BB.5030906@selasky.org> <53900AC7.5070402@selasky.org> <53900BC2.3090701@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D251@WPEXCHMBSL1021.central.det.win> In-Reply-To: <7DB382CFB050654DBFF7A39B1F8056EB3321D251@WPEXCHMBSL1021.central.det.win> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 18:26:53 -0000 On 06/05/14 08:31, Scott, Brian wrote: > Hi, > > Just rebuilt using the 'patched' version of the file rather than replacing the whole file. Compiles without problems. > > The other symptoms remain (erratic mouse movement, dropped keyboard characters) on the new version. > > Thanks, > > Brian Hi, Can you re-fetch the latest DWC OTG files *.[ch] after this commit: http://svnweb.freebsd.org/base?view=revision&revision=267120 Apply your (void *)(long) cast for the bus methods and try again. Any change? Sorry that I broke stuff in my commits. The matter is that the microtiming in the USB TT is quite hard. Thank you! --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Jun 5 23:58:14 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDF75E9B for ; Thu, 5 Jun 2014 23:58:14 +0000 (UTC) Received: from up-mx2.det.nsw.edu.au (up-mx2.det.nsw.edu.au [153.107.105.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53179299B for ; Thu, 5 Jun 2014 23:58:13 +0000 (UTC) Received: from itfsmtp6.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-mx2.det.nsw.edu.au (8.13.8/8.13.8) with ESMTP id s55NrEXb019269; Fri, 6 Jun 2014 09:53:14 +1000 Received: from SLPEXHT01.central.det.win (Not Verified[153.107.14.60]) by itfsmtp6.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Fri, 06 Jun 2014 09:53:08 +1000 Received: from WPEXCHHTUG1052.central.det.win (153.107.78.169) by SLPEXHT01.central.det.win (153.107.14.60) with Microsoft SMTP Server (TLS) id 8.3.342.0; Fri, 6 Jun 2014 09:52:17 +1000 Received: from WPEXCHMBSL1021.central.det.win ([169.254.1.14]) by WPEXCHHTUG1052.central.det.win ([153.107.78.169]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 09:52:16 +1000 From: "Scott, Brian" To: "'Hans Petter Selasky'" , "'arm@freebsd.org'" Subject: RE: Changes to dwc_otg USB controller code (stable/10) Thread-Topic: Changes to dwc_otg USB controller code (stable/10) Thread-Index: AQHPf92fyxvDvUntT4SsSJgnL9lJH5tgGJ+AgAHxGsD//1m7gIAAASwAgAFzG7CAAFnLMA== Date: Thu, 5 Jun 2014 23:52:16 +0000 Message-ID: <7DB382CFB050654DBFF7A39B1F8056EB3321E3BE@WPEXCHMBSL1021.central.det.win> References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> <539009BB.5030906@selasky.org> <53900AC7.5070402@selasky.org> <53900BC2.3090701@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D251@WPEXCHMBSL1021.central.det.win> <5390B68B.5070802@selasky.org> In-Reply-To: <5390B68B.5070802@selasky.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.107.9.240] x-route: TAFECORP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 23:58:14 -0000 Hello, Smooth mouse movement (OK, only tested in console but as smooth as that e= ver is). Occasional dropped keyboard characters (and key up events) but nowhere ne= ar as bad as earlier. A very positive step forward. Thanks. Brian -----Original Message----- From: Hans Petter Selasky [mailto:hps@selasky.org]=20 Sent: Friday, 6 June 2014 4:27 AM To: Scott, Brian; 'arm@freebsd.org' Subject: Re: Changes to dwc_otg USB controller code (stable/10) On 06/05/14 08:31, Scott, Brian wrote: > Hi, > > Just rebuilt using the 'patched' version of the file rather than replac= ing the whole file. Compiles without problems. > > The other symptoms remain (erratic mouse movement, dropped keyboard cha= racters) on the new version. > > Thanks, > > Brian Hi, Can you re-fetch the latest DWC OTG files *.[ch] after this commit: http://svnweb.freebsd.org/base?view=3Drevision&revision=3D267120 Apply your (void *)(long) cast for the bus methods and try again. Any=20 change? Sorry that I broke stuff in my commits. The matter is that the=20 microtiming in the USB TT is quite hard. Thank you! --HPS ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-arm@FreeBSD.ORG Fri Jun 6 05:03:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1979EA7 for ; Fri, 6 Jun 2014 05:03:39 +0000 (UTC) Received: from up-mx4.det.nsw.edu.au (up-mx4.det.nsw.edu.au [153.107.105.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4939E23DC for ; Fri, 6 Jun 2014 05:03:38 +0000 (UTC) Received: from slppmxmm02.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-mx4.det.nsw.edu.au (8.13.8/8.13.8) with ESMTP id s5653SAx021072; Fri, 6 Jun 2014 15:03:28 +1000 Received: from SLPEXHT01.central.det.win (Not Verified[153.107.14.60]) by slppmxmm02.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Fri, 06 Jun 2014 15:03:28 +1000 Received: from WPEXCHHTUG1051.central.det.win (153.107.78.168) by SLPEXHT01.central.det.win (153.107.14.60) with Microsoft SMTP Server (TLS) id 8.3.342.0; Fri, 6 Jun 2014 15:03:29 +1000 Received: from WPEXCHMBSL1021.central.det.win ([169.254.1.14]) by WPEXCHHTUG1051.central.det.win ([153.107.78.168]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 15:03:27 +1000 From: "Scott, Brian" To: =?utf-8?B?J01pa2HDq2wgVXJhbmthcic=?= Subject: RE: RPi + FreeBSD + Xorg + XBMC player ? Thread-Topic: RPi + FreeBSD + Xorg + XBMC player ? Thread-Index: AQHPf+s5yiOoqqxvx0yxOPbIzxE9cJtjiVSg Date: Fri, 6 Jun 2014 05:03:27 +0000 Message-ID: <7DB382CFB050654DBFF7A39B1F8056EB3321E46F@WPEXCHMBSL1021.central.det.win> References: <53850478.3080302@wp.pl> <53854768.1020904@hot.ee> <7DB382CFB050654DBFF7A39B1F8056EB3320BEB4@WPEXCHMBUG1062.central.det.win> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.107.9.240] x-route: TAFECORP Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 05:03:39 -0000 WCBzZWVtcyB0byBydW4gbmljZWx5IHdpdGggdGhlc2UgcGF0Y2hlcy4gVGhhbmtzLg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWlrYcOrbCBVcmFua2FyIFttYWlsdG86bWlr YWVsLnVyYW5rYXJAZ21haWwuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgNCBKdW5lIDIwMTQgOTo1 MSBQTQ0KVG86IFNjb3R0LCBCcmlhbg0KQ2M6IFN1bGV2LU1hZGlzIFNpbGJlciAoa2V0YXMpOyBN YXJlayBTYWx3ZXJvd2ljejsgZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmcNClN1YmplY3Q6IFJlOiBS UGkgKyBGcmVlQlNEICsgWG9yZyArIFhCTUMgcGxheWVyID8NCg0KMjAxNC0wNS0yOSAzOjAzIEdN VCswMjowMCBTY290dCwgQnJpYW4gPGJyaWFuLnNjb3R0NEBkZXQubnN3LmVkdS5hdT46DQo+IEhh cyBhbnlvbmUgYWN0dWFsbHkgZ290IFggcnVubmluZyByZWNlbnRseT8gSSd2ZSBqdXN0IGJlZW4g dHJ5aW5nIHRvIGJ1aWxkIGEgZmV3IHBhY2thZ2VzIG9uIHRoZSBQaSBhbmQgaXQgbG9va3MgbGlr ZSB0aGluZ3MgaGF2ZSBtb3ZlZCBvbiBzaW5jZSB0aGUgdmFyaW91cyB0dXRvcmlhbHMgb24gdGhl IHdlYiB3ZXJlIHdyaXR0ZW4uIFRoZSBzY2ZiIHZpZGVvIGRyaXZlciBpcyBpbmNsdWRlZCBpbiBw b3J0cyBub3cgYnV0ICBvdGhlciBicm9rZW4tbmVzcyBpbiB4b3JnLXNlcnZlciAoZHJpKSBzdG9w cyBpdCBiZWluZyBidWlsdC4NCj4NCj4gSGF2ZW4ndCBldmVuIHN0YXJ0ZWQgdHJ5aW5nIHRvIGdl dCBhcHBsaWNhdGlvbnMgbGlrZSBYQk1DIGdvaW5nLg0KDQpIaSwNCg0KSSBoYXZlIHN1Ym1pdHRl ZCBzb21lIHBhdGNoZXMgdG8gZ2V0IFggcnVubmluZyAoc2VlIFBSLzE4MTMxOCkuDQpYTUJDIGlz IG9ubHkgZm9yIGkzODYgYW5kIGFtZDY0DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgbWVzc2FnZSBp cyBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZSBuYW1lZCBhbmQgbWF5IGNvbnRhaW4NCnByaXZp bGVnZWQgaW5mb3JtYXRpb24gb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG9yIGJvdGguIElm IHlvdQ0KYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgYW5k IG5vdGlmeSB0aGUgc2VuZGVyLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K From owner-freebsd-arm@FreeBSD.ORG Fri Jun 6 07:41:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B293FB1 for ; Fri, 6 Jun 2014 07:41:00 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 614202FFB for ; Fri, 6 Jun 2014 07:41:00 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3626F1FE02A for ; Fri, 6 Jun 2014 09:40:59 +0200 (CEST) Message-ID: <539170AA.2000109@selasky.org> Date: Fri, 06 Jun 2014 09:41:30 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-arm Subject: RPI-B VM panic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 07:41:00 -0000 Hi, I'm seeing this with RPI-B: panic: vm_page_insert_after: msucc doesn't succeed pindex KDB: enter: panic [ thread pid 18 tid 100052 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> Any ideas? --HPS From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 07:29:22 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88494EE9 for ; Sat, 7 Jun 2014 07:29:22 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08C0724FD for ; Sat, 7 Jun 2014 07:29:21 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B1A6D1FE02A; Sat, 7 Jun 2014 09:29:13 +0200 (CEST) Message-ID: <5392BF67.9070306@selasky.org> Date: Sat, 07 Jun 2014 09:29:43 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Scott, Brian" , "'arm@freebsd.org'" Subject: Re: Changes to dwc_otg USB controller code (stable/10) References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> <539009BB.5030906@selasky.org> <53900AC7.5070402@selasky.org> <53900BC2.3090701@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D251@WPEXCHMBSL1021.central.det.win> <5390B68B.5070802@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321E3BE@WPEXCHMBSL1021.central.det.win> In-Reply-To: <7DB382CFB050654DBFF7A39B1F8056EB3321E3BE@WPEXCHMBSL1021.central.det.win> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 07:29:22 -0000 Hi, Can you re-test once more using DWC OTG code newer than: http://svnweb.freebsd.org/changeset/base/267210 I will get those patches MFC'ed shortly to 10-stable. --HPS From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 12:12:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65D21DC9 for ; Sat, 7 Jun 2014 12:12:49 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C432628DF for ; Sat, 7 Jun 2014 12:12:48 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id p9so2114676lbv.39 for ; Sat, 07 Jun 2014 05:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=ZAQuHGTAeX8sDgj0Axr60MCPQRlywPIH6OWXlNdmwpA=; b=xQ2zL7QYVlD9OxpHGp/AnOsgNWUbdVoHM9hWd6x+N+8RpzgqhzuTTlVNAkhtGTxeRY yuO1/dK6Pb2hoZWk18t/CK6dCHg08OaJ6GXwc3W6viyzrMC3hXMZVGnb2Xoq2yRKkiNL zsperNT0sWtChH3BFwevokx7jnwTUsuDnrzoyBlQXy3nYrIkUmOrk0E4R3dvLzB9ZO+K ecm15pQQFL3pkwxvmbd3Tyx9OYJPJGYg4QuqHLclO+J/1X1hUXh9H6XxKXJ0kXHWJh4f HB9YS09jc9B9h89Bv47LPvzv62uSF0naAWunFAPyPr6cfkiNfiK49AE+QF9noenHlhrx l7Lw== X-Received: by 10.112.97.146 with SMTP id ea18mr1161010lbb.67.1402143166657; Sat, 07 Jun 2014 05:12:46 -0700 (PDT) Received: from [192.168.1.106] (c-3535e155.556-1-64736c11.cust.bredbandsbolaget.se. [85.225.53.53]) by mx.google.com with ESMTPSA id aa1sm11833936lbd.12.2014.06.07.05.12.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 05:12:45 -0700 (PDT) From: Olavi Kumpulainen Subject: C++ exceptions in freebsd-arm doesn't seem to work Message-Id: Date: Sat, 7 Jun 2014 14:12:43 +0200 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 12:12:49 -0000 Hi there, If this question has been discussed before, sorry. I couldn=92t find = anything when scanning through the archives though. So, I=92m running FreeBSD-10/stable on a RPI version B as you can see = here; Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-STABLE #0 r266807: Thu May 29 07:07:08 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 I have this little program; $ cat t.cc #include #include void func()=20 { throw std::exception(); } int main() { std::cout << "Starting throw-test" << std::endl; try { func(); } catch(std::exception){ std::cout << =93In my exception handler" << std::endl; } catch(...) { std::cout << "In catch-all handler" << std::endl; } return 0; } With this Makefile; $ cat Makefile all : t t : t.cc c++ -o t -fexceptions t.cc Running the above produces the following result; $ ./t Starting throw-test Fatal error during phase 1 unwinding Abort (core dumped) Which indeed is not what I expected. I=92ve tried debugging this for a couple of days and have concluded that = my throw clause ends up in contrib/gcc/config/arm/unwind-arm.c. The = associated code in unwind-arm.c is; static _Unwind_Reason_Code get_eit_entry (_Unwind_Control_Block *ucbp, _uw return_address) { const __EIT_entry * eitp; int nrec; =20 /* The return address is the address of the instruction following the call instruction (plus one in thumb mode). If this was the last instruction in the function the address will lie in the following function. Subtract 2 from the address so that it points within the = call instruction itself. */ return_address -=3D 2; if (__gnu_Unwind_Find_exidx) { eitp =3D (const __EIT_entry *) __gnu_Unwind_Find_exidx = (return_address, &nrec); if (!eitp) { UCB_PR_ADDR (ucbp) =3D 0; return _URC_FAILURE; } } else { eitp =3D &__exidx_start; nrec =3D &__exidx_end - &__exidx_start; } Since __gnu_Unwind_Find_exidx =3D=3D NULL, the EIT is located in an = array located between __exidx_start and __exidx_end. However, __exidx_end =3D=3D __exidx_start! So the EIT has a length of = zero, nrec will be 0. libgcc will fail the lookup and return = _URC_FAILURE to libcxxrt.cc, which in turn will produce the = fprintf(stderr, "Fatal error during phase 1 unwinding\n"); # readelf -s t | grep exidx 36: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start 47: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end 115: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end 150: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start So exception throwing in clang++ doesn=92t seem to work. Can any of you guys shed some light on this? Cheers, /Olavi From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 14:04:43 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A2A6FE9 for ; Sat, 7 Jun 2014 14:04:43 +0000 (UTC) Received: from up-smx-s1.dmz.det.nsw.edu.au (up-smx-s1.det.nsw.edu.au [153.107.41.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 321CE2091 for ; Sat, 7 Jun 2014 14:04:41 +0000 (UTC) Received: from slppmxmm01.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-smx-s1.dmz.det.nsw.edu.au (8.14.4/8.14.4) with ESMTP id s57E4V9L024067; Sun, 8 Jun 2014 00:04:32 +1000 Received: from UGPEXHT01.central.det.win (Not Verified[153.107.78.56]) by slppmxmm01.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Sun, 08 Jun 2014 00:04:30 +1000 Received: from WPEXCHHTSL1042.central.det.win (153.107.14.178) by UGPEXHT01.central.det.win (153.107.78.56) with Microsoft SMTP Server (TLS) id 8.3.342.0; Sun, 8 Jun 2014 00:04:30 +1000 Received: from WPEXCHMBSL1021.central.det.win ([169.254.1.14]) by WPEXCHHTSL1042.central.det.win ([153.107.14.178]) with mapi id 14.03.0174.001; Sun, 8 Jun 2014 00:04:30 +1000 From: "Scott, Brian" To: Hans Petter Selasky Subject: Re: Changes to dwc_otg USB controller code (stable/10) Thread-Topic: Changes to dwc_otg USB controller code (stable/10) Thread-Index: AQHPf92fyxvDvUntT4SsSJgnL9lJH5tgGJ+AgAHxGsD//1m7gIAAASwAgAFzG7CAAmzt8IAAbmm3 Date: Sat, 7 Jun 2014 14:04:29 +0000 Message-ID: <3FBCFE32-009B-4CFA-9403-33AF1C3344DB@det.nsw.edu.au> References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> <539009BB.5030906@selasky.org> <53900AC7.5070402@selasky.org> <53900BC2.3090701@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D251@WPEXCHMBSL1021.central.det.win> <5390B68B.5070802@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321E3BE@WPEXCHMBSL1021.central.det.win>, <5392BF67.9070306@selasky.org> In-Reply-To: <5392BF67.9070306@selasky.org> Accept-Language: en-AU, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-route: TAFECORP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 14:04:43 -0000 It will be Tuesday before I can test again but will be happy to then. I'l= l let you know. Brian On 07/06/2014, at 5:29 PM, "Hans Petter Selasky" wrote:= > Hi, >=20 > Can you re-test once more using DWC OTG code newer than: >=20 > http://svnweb.freebsd.org/changeset/base/267210 >=20 > I will get those patches MFC'ed shortly to 10-stable. >=20 > --HPS ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 15:55:27 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0EB643D for ; Sat, 7 Jun 2014 15:55:27 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 829B92966 for ; Sat, 7 Jun 2014 15:55:27 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WtIxk-000Nvn-HU; Sat, 07 Jun 2014 15:55:20 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s57FtHtI002557; Sat, 7 Jun 2014 09:55:17 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19w0N9CM9aCshlvO9rYlZh6 Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Ian Lepore To: Olavi Kumpulainen In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-13" Date: Sat, 07 Jun 2014 09:55:16 -0600 Message-ID: <1402156516.20883.154.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s57FtHtI002557 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 15:55:27 -0000 On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: > Hi there, >=20 > If this question has been discussed before, sorry. I couldn=FFt find an= ything when scanning through the archives though. >=20 > So, I=FFm running FreeBSD-10/stable on a RPI version B as you can see h= ere; >=20 >=20 > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 > The Regents of the University of California. All rights reserve= d. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-STABLE #0 r266807: Thu May 29 07:07:08 UTC 2014 > root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 2014051= 2 >=20 >=20 > I have this little program; >=20 > $ cat t.cc >=20 > #include > #include >=20 > void func()=20 > { > throw std::exception(); > } >=20 >=20 > int main() > { > std::cout << "Starting throw-test" << std::endl; >=20 > try > { > func(); > } > catch(std::exception){ > std::cout << =B4In my exception handler" << std::endl; > } > catch(...) { > std::cout << "In catch-all handler" << std::endl; > } >=20 > return 0; > } >=20 > With this Makefile; >=20 > $ cat Makefile >=20 > all : t >=20 > t : t.cc > c++ -o t -fexceptions t.cc >=20 >=20 > Running the above produces the following result; >=20 > $ ./t > Starting throw-test > Fatal error during phase 1 unwinding > Abort (core dumped) >=20 > Which indeed is not what I expected. >=20 > I=FFve tried debugging this for a couple of days and have concluded tha= t my throw clause ends up in contrib/gcc/config/arm/unwind-arm.c. The ass= ociated code in unwind-arm.c is; >=20 > static _Unwind_Reason_Code > get_eit_entry (_Unwind_Control_Block *ucbp, _uw return_address) > { > const __EIT_entry * eitp; > int nrec; > =20 > /* The return address is the address of the instruction following the > call instruction (plus one in thumb mode). If this was the last > instruction in the function the address will lie in the following > function. Subtract 2 from the address so that it points within th= e call > instruction itself. */ > return_address -=3D 2; >=20 > if (__gnu_Unwind_Find_exidx) > { > eitp =3D (const __EIT_entry *) __gnu_Unwind_Find_exidx (return_ad= dress, > &nrec); > if (!eitp) > { > UCB_PR_ADDR (ucbp) =3D 0; > return _URC_FAILURE; > } > } > else > { > eitp =3D &__exidx_start; > nrec =3D &__exidx_end - &__exidx_start; > } >=20 >=20 > Since __gnu_Unwind_Find_exidx =3D=3D NULL, the EIT is located in an arr= ay located between __exidx_start and __exidx_end. >=20 > However, __exidx_end =3D=3D __exidx_start! So the EIT has a length of z= ero, nrec will be 0. libgcc will fail the lookup and return _URC_FAILURE = to libcxxrt.cc, which in turn will produce the fprintf(stderr, "Fatal err= or during phase 1 unwinding\n"); >=20 > # readelf -s t | grep exidx > 36: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start > 47: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end > 115: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end > 150: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start >=20 > So exception throwing in clang++ doesn=FFt seem to work. >=20 > Can any of you guys shed some light on this? >=20 > Cheers, >=20 > /Olavi Sadly, all I can do is confirm what you say: C++ exceptions don't work on ARM EABI, not with clang and not with gcc. The only combo that works is gcc and OABI, but with that combo you lose hardware floating point. There are rumours that this may be fixed in clang 3.5, but we apparently can't import 3.5 because it can't be bootstrapped using gcc 4.2. I haven't had time yet to learn how to build clang 3.5 out-of-tree to confirm that exceptions work there. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 16:07:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F0A79A1; Sat, 7 Jun 2014 16:07:43 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E4BD2A43; Sat, 7 Jun 2014 16:07:43 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id i50so6929345qgf.3 for ; Sat, 07 Jun 2014 09:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=P7tQMNpFpNx1hLHrWjRk1bxrgZQKUaFSkSFPZyu/cEY=; b=yyxyr4qNPPYkn77Fkp2pjBpW+8lqGDobWVG5Orj3E1/UdjSLHg41e7a52hp9I9uuuF uSl+lCn6bUUY1N4Q1zsmlfIi+XcGGUFhrBq9akvux1nPBapmclpDElfYemgqdwKJDQ/2 KI1zQf46KQCgib2ys24tTdzu46q931Lg2c0PTZSwCDlDlDHGEaXXyFhDRNzymnRQIhpI eH+divZjLh9Lhzc+bvVFWgASkaD7UP5/Z9pcmTnWMfJ6IVUKypykwuWAA2N9skwn8IDU i/mMkK8yma+nNlOkGnb1AcynYzQDAmIHS6CbLqCxIKOOX6dj8T7FxACrr/Z0pW7XUiq+ hlMg== MIME-Version: 1.0 X-Received: by 10.140.35.212 with SMTP id n78mr18037623qgn.87.1402157262372; Sat, 07 Jun 2014 09:07:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sat, 7 Jun 2014 09:07:42 -0700 (PDT) In-Reply-To: <1402156516.20883.154.camel@revolution.hippie.lan> References: <1402156516.20883.154.camel@revolution.hippie.lan> Date: Sat, 7 Jun 2014 12:07:42 -0400 X-Google-Sender-Auth: az7UU1_cbowNGL3WPLntwtWBe6g Message-ID: Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , Olavi Kumpulainen X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:07:43 -0000 > Sadly, all I can do is confirm what you say: C++ exceptions don't work > on ARM EABI, not with clang and not with gcc. The only combo that works > is gcc and OABI, but with that combo you lose hardware floating point. > > There are rumours that this may be fixed in clang 3.5, but we apparently > can't import 3.5 because it can't be bootstrapped using gcc 4.2. I > haven't had time yet to learn how to build clang 3.5 out-of-tree to > confirm that exceptions work there. > If only we had a way to tell our build system to build the in-src-tree compiler suite using an external compiler toolchain. That'd make those problems go away. -a From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 16:14:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B86C5C03 for ; Sat, 7 Jun 2014 16:14:29 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83F802B04 for ; Sat, 7 Jun 2014 16:14:29 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id z10so3629741pdj.6 for ; Sat, 07 Jun 2014 09:14:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=U/05ghbUqw8DNddmjNUXxl51oYnMZeES+SJtmQzHHng=; b=BI3rZ83s9lMlmvEHF3WMtEjFR6alpYJU2RQ3+aEqLj0gqLbkXA4CjXazB5xYNSTU3F oBb2vaJkw44Vr0LYR8rkufRJbTIM9mRtJfEK88/+mWEkUap6lVoUjo0MesK3D6hmVc+d 5mgFtqfsUJykusp60uSYLTaX/ZZBwvE4Yz0y0BwPAt06fnHXRt7HgZbUXiVrE3FqOS6h 2gr29g5kA+IMA2Z4IegvjN4Kt69K1dR/y9AQpdx3qYjfZZ47BZb976qmB+qV+h1uYiZu VKAA60LOb+BUZ8fO43IH9E0NfqJ7TX6G7ddZ12p07EK4+rkztCNsl3C9KgVNAf+agPUI FObA== X-Gm-Message-State: ALoCoQk4jNGZWF9WHEg6BFbASf7moHR785TBVGHrvZvr4u7DhgeveQHon9iCQ8yWRf77E7bXGHZ+ X-Received: by 10.68.226.197 with SMTP id ru5mr13236023pbc.77.1402157663438; Sat, 07 Jun 2014 09:14:23 -0700 (PDT) Received: from lgmac-cvenus.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id av2sm50223512pbc.16.2014.06.07.09.14.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 09:14:22 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_A8C64F4F-6649-40EC-8046-066E4041FAA2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Warner Losh In-Reply-To: Date: Sat, 7 Jun 2014 10:14:15 -0600 Message-Id: References: <1402156516.20883.154.camel@revolution.hippie.lan> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" , Ian Lepore , Olavi Kumpulainen X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:14:29 -0000 --Apple-Mail=_A8C64F4F-6649-40EC-8046-066E4041FAA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 7, 2014, at 10:07 AM, Adrian Chadd wrote: >> Sadly, all I can do is confirm what you say: C++ exceptions don't = work >> on ARM EABI, not with clang and not with gcc. The only combo that = works >> is gcc and OABI, but with that combo you lose hardware floating = point. >>=20 >> There are rumours that this may be fixed in clang 3.5, but we = apparently >> can't import 3.5 because it can't be bootstrapped using gcc 4.2. I >> haven't had time yet to learn how to build clang 3.5 out-of-tree to >> confirm that exceptions work there. >>=20 >=20 > If only we had a way to tell our build system to build the in-src-tree > compiler suite using an external compiler toolchain. That'd make those > problems go away. We do. It isn=92t perfect, and you=92d have to bootstrap either a new = gcc or a 3.4 clang first to do it though. The automation of the = bootstrapping isn=92t present, and is what I=92m working on=85 Of course, it doesn=92t solve all the problems, just means we have more = tools to deploy. 3.5 is also quite experimental as well. But there=92s been no real talk about the right path forward: just FUD = and hand wringing on the lists. We do need to have a real discussion = about this. Not the lame pot-shots that have happened to date: what = versions do we support upgrading from, what configurations, etc. If we = had that discussion, then we wouldn=92t even need what Adrian suggests. = We=92d just say you have to have FreeBSD 9.2 or newer with clang 3.3 (or = is it clang 3.4) to bootstrap, and if you want to use other tools, you = are on your own. This would break updating from 8.x, but that=92s likely = OK. Be we need to have this discussion. Warner --Apple-Mail=_A8C64F4F-6649-40EC-8046-066E4041FAA2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTkzpXAAoJEGwc0Sh9sBEA7XoQALVPY/5QURxbiAmycyO7eegS oS2+szDbEwfnBifMdJcso7tVrv0O6du9qwehWW24RD+2cI4hiUfW3ji5xEYcNr02 mojjjXrCiicwYI0nnGYv1OkL8onlPLJI5N4m4rcMbflv8WqYhVxJGSFfZmpVYvwT JdSAfcyDvv4fvnRyrsNOMp/p3v/SMmUu0xNgxT76eHb3IhJcrKIVqENNqJ1kA7rN c06kzwiXNtoTdCeQs3kix5R3QDy9plTmrAf0Y+TLRRQtVWV+CooxZsfOz9joywV8 ZLOnrC0Lpu7Dd3f+6BO76h881arBDuauFIG1sRmtzb8C8U8hInLVLyVEOT6HgR0d tShzW2tYyY4F9cQEqXdbemqUyqKboEaT8eY2BNx4AW4tSW8qfJnm2QOOJsPkds9U oxBxWtldaq/CfJi3h6j31OahC0a1Nqa5eeUs0tN+9ELaB96jEwQtwrhWGtYucM9i YKTIH4m0vAgJ+so5nVLnPHBP9t6NbzKj6WoMons0BM7BwK+tiUMgAl5E9zWLgpjd GwMOjUd8JMcsC8t9t/HvuTucoGPqnYb+jLeiBYqgij+r1KwOHOksQwM9XBmBlJAO I7GNSFWvry512MpOtGwrvqNi1Zx52GUhIlLWW4MJofTzb2IGYhQaG5aU1x0V83g2 Kpr6ZdNhqlZltSMbdM4G =sSDP -----END PGP SIGNATURE----- --Apple-Mail=_A8C64F4F-6649-40EC-8046-066E4041FAA2-- From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 16:24:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F7E3EE2; Sat, 7 Jun 2014 16:24:02 +0000 (UTC) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D2A12BB6; Sat, 7 Jun 2014 16:24:02 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id j107so6813011qga.6 for ; Sat, 07 Jun 2014 09:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=12LWxF67jodNmSZ/rrVJhH6K/Q3GkrvGjvzXfJf42cA=; b=YuS0ZUBggfOYn4Zp1ILdUNOFOvVLdCfJj4R5F6J8DPxIx2DwE2SfuYZaiCfC1TABfS hd3yihPG4+XmNk1NRFyYY2cAf+oemVb91TDI3S2NZqGF1GythOVGODBSgM0Wb2ozZZmB 48o0od6tKk1LXFGQrJXPeBqlhP14wOCA9SfBBBnhlujbxqbCbAsxAoiRlmYXXLLqSvOP +A6w1V3FeyTyM2ETDLdD9gpTBJNC9a54LtUuQ8neCVA6elJRiCQrTW/DZHCynbnd6HnY ulfO4mZpU4JTTqHo8UxpqHXsNbm61Xp3LDe+o9X+CL5OcE4kLm3eFHjxlUwdZl20zPL2 t0xA== MIME-Version: 1.0 X-Received: by 10.224.43.148 with SMTP id w20mr19672213qae.26.1402158241320; Sat, 07 Jun 2014 09:24:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sat, 7 Jun 2014 09:24:01 -0700 (PDT) In-Reply-To: References: <1402156516.20883.154.camel@revolution.hippie.lan> Date: Sat, 7 Jun 2014 12:24:01 -0400 X-Google-Sender-Auth: tp0KXN9yM1PqPgQ0SfLPWxOtZJI Message-ID: Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" , Ian Lepore , Olavi Kumpulainen X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:24:02 -0000 On 7 June 2014 12:14, Warner Losh wrote: > > On Jun 7, 2014, at 10:07 AM, Adrian Chadd wrote: > >>> Sadly, all I can do is confirm what you say: C++ exceptions don't work >>> on ARM EABI, not with clang and not with gcc. The only combo that work= s >>> is gcc and OABI, but with that combo you lose hardware floating point. >>> >>> There are rumours that this may be fixed in clang 3.5, but we apparentl= y >>> can't import 3.5 because it can't be bootstrapped using gcc 4.2. I >>> haven't had time yet to learn how to build clang 3.5 out-of-tree to >>> confirm that exceptions work there. >>> >> >> If only we had a way to tell our build system to build the in-src-tree >> compiler suite using an external compiler toolchain. That'd make those >> problems go away. > > We do. It isn=E2=80=99t perfect, and you=E2=80=99d have to bootstrap eith= er a new gcc or a 3.4 clang first to do it though. The automation of the bo= otstrapping isn=E2=80=99t present, and is what I=E2=80=99m working on=E2=80= =A6 Cool! The last time I wrangled this, I could only get it to build the whole system with the compiler I fed in. It wouldn't build the in-source-tree compiler with the external compiler I gave it - using the external compiler seemed to totally just negate building the toolchain. I'm glad this isn't the case. > Of course, it doesn=E2=80=99t solve all the problems, just means we have = more tools to deploy. > > 3.5 is also quite experimental as well. > > But there=E2=80=99s been no real talk about the right path forward: just = FUD and hand wringing on the lists. We do need to have a real discussion ab= out this. Not the lame pot-shots that have happened to date: what versions = do we support upgrading from, what configurations, etc. If we had that disc= ussion, then we wouldn=E2=80=99t even need what Adrian suggests. We=E2=80= =99d just say you have to have FreeBSD 9.2 or newer with clang 3.3 (or is i= t clang 3.4) to bootstrap, and if you want to use other tools, you are on = your own. This would break updating from 8.x, but that=E2=80=99s likely OK.= Be we need to have this discussion. I'd personally like to rehash the "build from under Linux" discussion. I keep bumping into cases like this where a lot of the work being done to make this stuff happen is in line with what we need to be able to build FreeBSD under a non-FreeBSD operating system. I'd really like _that_ to happen - it'll help migrations _to_ freebsd from other projects. -a From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 16:29:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C46831AB for ; Sat, 7 Jun 2014 16:29:50 +0000 (UTC) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E4FD2BFC for ; Sat, 7 Jun 2014 16:29:50 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id md12so3736258pbc.29 for ; Sat, 07 Jun 2014 09:29:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=/CoCyRWlL8wmQtwXXz4+ZhD2vFFJH+inVQYR8jEsgxA=; b=AoxRwqbzOJnMXDx6v90ZJdQSFnwLKzQ7sCqgbJLizteDxiqezzLWZnAyN8vCnotfiq lRsT43CONp1Xucsh0eOvHcuIn9DldDAgxgPNxcxI14EASVepQHTyq7Sv8qH1rhL+CCq0 DApNa4JfuL0TFQ673GYw1OuZB+O8aFw6xtYbQm1b398tIZuZshhX0mNC4gMag4OEopKk cS5YDKv3Qe1Mg8HbwZ4Esw6Mv2xYHqrE0glQykxmcu06wVHy/PFK08TNGe29SE0erLO4 Jz+6EZ11QpTBEeqSc9AAZQHMlXHHZz2Ez9tNAGc6Mn9dKKEPwcfehz3o++OS2GlV/BNn jvOA== X-Gm-Message-State: ALoCoQlze/tcAtpNq0ndGJ1rVLJ5G7PIHdQPchdQxMGJLtB8ZN3PoJ7W3qKMF6eJGnNxqmI4lXSe X-Received: by 10.68.247.65 with SMTP id yc1mr13073379pbc.68.1402158589758; Sat, 07 Jun 2014 09:29:49 -0700 (PDT) Received: from lgmac-cvenus.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id vk5sm9861026pbc.44.2014.06.07.09.29.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 09:29:48 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_0365EEA9-610B-4F98-B3C1-F821F7D41339"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Warner Losh In-Reply-To: Date: Sat, 7 Jun 2014 10:29:46 -0600 Message-Id: <0567DA73-DE37-48F0-BD18-F6498D6083A6@bsdimp.com> References: <1402156516.20883.154.camel@revolution.hippie.lan> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" , Ian Lepore , Olavi Kumpulainen X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:29:50 -0000 --Apple-Mail=_0365EEA9-610B-4F98-B3C1-F821F7D41339 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 7, 2014, at 10:24 AM, Adrian Chadd wrote: > On 7 June 2014 12:14, Warner Losh wrote: >>=20 >> On Jun 7, 2014, at 10:07 AM, Adrian Chadd wrote: >>=20 >>>> Sadly, all I can do is confirm what you say: C++ exceptions don't = work >>>> on ARM EABI, not with clang and not with gcc. The only combo that = works >>>> is gcc and OABI, but with that combo you lose hardware floating = point. >>>>=20 >>>> There are rumours that this may be fixed in clang 3.5, but we = apparently >>>> can't import 3.5 because it can't be bootstrapped using gcc 4.2. I >>>> haven't had time yet to learn how to build clang 3.5 out-of-tree to >>>> confirm that exceptions work there. >>>>=20 >>>=20 >>> If only we had a way to tell our build system to build the = in-src-tree >>> compiler suite using an external compiler toolchain. That'd make = those >>> problems go away. >>=20 >> We do. It isn=92t perfect, and you=92d have to bootstrap either a new = gcc or a 3.4 clang first to do it though. The automation of the = bootstrapping isn=92t present, and is what I=92m working on=85 >=20 > Cool! The last time I wrangled this, I could only get it to build the > whole system with the compiler I fed in. It wouldn't build the > in-source-tree compiler with the external compiler I gave it - using > the external compiler seemed to totally just negate building the > toolchain. I'm glad this isn't the case. It does take many hand-stands to doit... >> Of course, it doesn=92t solve all the problems, just means we have = more tools to deploy. >>=20 >> 3.5 is also quite experimental as well. >>=20 >> But there=92s been no real talk about the right path forward: just = FUD and hand wringing on the lists. We do need to have a real discussion = about this. Not the lame pot-shots that have happened to date: what = versions do we support upgrading from, what configurations, etc. If we = had that discussion, then we wouldn=92t even need what Adrian suggests. = We=92d just say you have to have FreeBSD 9.2 or newer with clang 3.3 (or = is it clang 3.4) to bootstrap, and if you want to use other tools, you = are on your own. This would break updating from 8.x, but that=92s likely = OK. Be we need to have this discussion. >=20 > I'd personally like to rehash the "build from under Linux" discussion. > I keep bumping into cases like this where a lot of the work being done > to make this stuff happen is in line with what we need to be able to > build FreeBSD under a non-FreeBSD operating system. I'd really like > _that_ to happen - it'll help migrations _to_ freebsd from other > projects. No. Have that as a separate discussion. That=92s a big bike shed of = wonder and requires functionality not present in the tree (e.g. actual = work). My discussion is =93we currently allow X to work, I want to = change that to X+Y so we can import Z.=94 which is much smaller. So go = ahead and have your linux discussion, but don=92t hijack mine. Warner --Apple-Mail=_0365EEA9-610B-4F98-B3C1-F821F7D41339 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTkz36AAoJEGwc0Sh9sBEAeKUP/17Ypc1S2peyeL8AGMx4fNXo Xci1RFxhKu2I6pqfgO3hrhOblYc0/B9cNfoeKfJD9YqvPXS7+8Mal+8XsKpcukru CatIz7olwRuQCnYkvugpMUh1+8FltwpJWUjvcTACclGPuHGlHLvqsI6zppj1Dne1 fzY4ss5FiCpmfUptaHztxYLiTj3WSVEo7hVigvJuNyeLxJZiA3nLzh8HcPBvgEd+ I9jQulaI0i8mb/COdzmIUJWfuYJS5aQJAb5OHNjMp6ZyZjFgoxzlOxTPkQAuwmgM qNbiQp3ALe2N1Uu/5h3FRH/OE7f4Sbwqlb+tzJH31znPl3VArt6aY/rhBTbtGJg7 Py5o0IVUZdZ1oeS72iec+9lWW165HZeSSI40Sf8KLnPyc+H8IcmZsiiP+XddWN+W LBt8QGNbZ1lNOfLB5sZLBVZmyMeKzH4ejjE3HapHwSY5SAvjYkMDsxlETRfXOMJ6 5H2KJ0FNVxzsIrTgHSSle28/znTLO6uj3j90Hg3tHTbv8EICrcXiM2MmJIQ+G02O +Bmum0KgxcW/bGPkPBWyy5rG7H97D0g+JH4FA6Z26DUwD2ENCVEyqBU4YYruIvPB fXWY/DPM8asE41U2QiRmHJWORfCUieJxPNoZgE4RX3uH33yG0Rm4E22b5fnI7/ta YR8f5r9JSLj0DL44LX83 =ZvSG -----END PGP SIGNATURE----- --Apple-Mail=_0365EEA9-610B-4F98-B3C1-F821F7D41339-- From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 16:33:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F098398; Sat, 7 Jun 2014 16:33:31 +0000 (UTC) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27DC22C85; Sat, 7 Jun 2014 16:33:31 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id ij19so959057vcb.9 for ; Sat, 07 Jun 2014 09:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=pUbDT/0wm9V1rNbyebbLLi9W07nS83NlWPczyaua00M=; b=IMCVJEztN9A13iaVlm8SPL1vORygUQO2dvbhSmfLHOVQFhaa6zhSlnRaqx0iGMiR75 P0DaVJ8KPW8AR7UH48ohy9PC5XflvPtOrFCs8eHBmgfuvYThrnZuWHYbGQnN/ud/waO2 hmyrkeEJ1VEIOh1woYTw6XK1jLRS/F6fr169I3XSgXyFN2jFo6jalO3Iird+Bx4XD7x3 OfetF5RSw2n5LeVry1vmTLcsc9c2obqvkODuj7KKiHVqvqpzdQfJlpACaO9wQhHQ7f9R qFGNONbxb3JiKz57kdMLy++orNrUnvpmv9TnQmkr/xRBgktP1xLg8gfZjGzGiM35apSI MI3g== MIME-Version: 1.0 X-Received: by 10.220.92.193 with SMTP id s1mr14214378vcm.34.1402158810082; Sat, 07 Jun 2014 09:33:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.220.186.193 with HTTP; Sat, 7 Jun 2014 09:33:29 -0700 (PDT) In-Reply-To: <0567DA73-DE37-48F0-BD18-F6498D6083A6@bsdimp.com> References: <1402156516.20883.154.camel@revolution.hippie.lan> <0567DA73-DE37-48F0-BD18-F6498D6083A6@bsdimp.com> Date: Sat, 7 Jun 2014 12:33:29 -0400 X-Google-Sender-Auth: 5XFWA96B54ELWwesvIeq6GAR3EM Message-ID: Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" , Ian Lepore , Olavi Kumpulainen X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:33:31 -0000 On 7 June 2014 12:29, Warner Losh wrote: > > On Jun 7, 2014, at 10:24 AM, Adrian Chadd wrote: > >> On 7 June 2014 12:14, Warner Losh wrote: >>> >>> On Jun 7, 2014, at 10:07 AM, Adrian Chadd wrote: >>> >>>>> Sadly, all I can do is confirm what you say: C++ exceptions don't wo= rk >>>>> on ARM EABI, not with clang and not with gcc. The only combo that wo= rks >>>>> is gcc and OABI, but with that combo you lose hardware floating point= . >>>>> >>>>> There are rumours that this may be fixed in clang 3.5, but we apparen= tly >>>>> can't import 3.5 because it can't be bootstrapped using gcc 4.2. I >>>>> haven't had time yet to learn how to build clang 3.5 out-of-tree to >>>>> confirm that exceptions work there. >>>>> >>>> >>>> If only we had a way to tell our build system to build the in-src-tree >>>> compiler suite using an external compiler toolchain. That'd make those >>>> problems go away. >>> >>> We do. It isn=E2=80=99t perfect, and you=E2=80=99d have to bootstrap ei= ther a new gcc or a 3.4 clang first to do it though. The automation of the = bootstrapping isn=E2=80=99t present, and is what I=E2=80=99m working on=E2= =80=A6 >> >> Cool! The last time I wrangled this, I could only get it to build the >> whole system with the compiler I fed in. It wouldn't build the >> in-source-tree compiler with the external compiler I gave it - using >> the external compiler seemed to totally just negate building the >> toolchain. I'm glad this isn't the case. > > It does take many hand-stands to doit... I may give it another go then. >> I'd personally like to rehash the "build from under Linux" discussion. >> I keep bumping into cases like this where a lot of the work being done >> to make this stuff happen is in line with what we need to be able to >> build FreeBSD under a non-FreeBSD operating system. I'd really like >> _that_ to happen - it'll help migrations _to_ freebsd from other >> projects. > > No. Have that as a separate discussion. That=E2=80=99s a big bike shed o= f wonder and requires functionality not present in the tree (e.g. actual wo= rk). My discussion is =E2=80=9Cwe currently allow X to work, I want to chan= ge that to X+Y so we can import Z.=E2=80=9D which is much smaller. So go ah= ead and have your linux discussion, but don=E2=80=99t hijack mine. Absolutely. -a From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 17:13:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21D9482F; Sat, 7 Jun 2014 17:13:47 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E18A2FDC; Sat, 7 Jun 2014 17:13:46 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id w7so2235501lbi.15 for ; Sat, 07 Jun 2014 10:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DkJ75+5gQmZjh5cnfCkVK7FAkOKvF57ijf4TTVRWDLU=; b=bGTv2seW4IFaE9datQDaRR4glmxvdYOyV34B77zAeizqJyXNwkkxtjvfcip2KIW2Uh nNsorapAfFiSZqnx953uf7sZndh8dzsZC7F9X/6GLQOdFZDCcZVVYE1jz10Ve3DIaQ2E hzzQ7u2N0j6bu8Nfjhun68hon/xgrmOvg8nInn7LZB3B/WKJ5awKCxD4gA3JWO+JyFgI eYLMYdiGy2Tpx/5j3u1DX2VIUBXWRQwErMFDCabK4ZxogsODkzMi7sNdu1tJ1yNr/e2g LITl1LHf2dKFCt5SFoUEyDZ4kWt5i5e87PMh/RdxBSQIStYq72TzpO0IrEWAmnoeMjlT sNAA== X-Received: by 10.152.4.227 with SMTP id n3mr9503923lan.16.1402161224116; Sat, 07 Jun 2014 10:13:44 -0700 (PDT) Received: from [192.168.1.106] (c-3535e155.556-1-64736c11.cust.bredbandsbolaget.se. [85.225.53.53]) by mx.google.com with ESMTPSA id oc3sm12471920lbb.18.2014.06.07.10.13.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 10:13:43 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Olavi Kumpulainen In-Reply-To: <0567DA73-DE37-48F0-BD18-F6498D6083A6@bsdimp.com> Date: Sat, 7 Jun 2014 19:13:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1402156516.20883.154.camel@revolution.hippie.lan> <0567DA73-DE37-48F0-BD18-F6498D6083A6@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 17:13:47 -0000 On 07 Jun 2014, at 18:29 , Warner Losh wrote: >=20 > On Jun 7, 2014, at 10:24 AM, Adrian Chadd wrote: >=20 >> On 7 June 2014 12:14, Warner Losh wrote: >>>=20 >>> On Jun 7, 2014, at 10:07 AM, Adrian Chadd = wrote: >>>=20 >>>>> Sadly, all I can do is confirm what you say: C++ exceptions don't = work >>>>> on ARM EABI, not with clang and not with gcc. The only combo that = works >>>>> is gcc and OABI, but with that combo you lose hardware floating = point. >>>>>=20 >>>>> There are rumours that this may be fixed in clang 3.5, but we = apparently >>>>> can't import 3.5 because it can't be bootstrapped using gcc 4.2. = I >>>>> haven't had time yet to learn how to build clang 3.5 out-of-tree = to >>>>> confirm that exceptions work there. >>>>>=20 >>>>=20 >>>> If only we had a way to tell our build system to build the = in-src-tree >>>> compiler suite using an external compiler toolchain. That'd make = those >>>> problems go away. >>>=20 >>> We do. It isn=92t perfect, and you=92d have to bootstrap either a = new gcc or a 3.4 clang first to do it though. The automation of the = bootstrapping isn=92t present, and is what I=92m working on=85 >>=20 >> Cool! The last time I wrangled this, I could only get it to build the >> whole system with the compiler I fed in. It wouldn't build the >> in-source-tree compiler with the external compiler I gave it - using >> the external compiler seemed to totally just negate building the >> toolchain. I'm glad this isn't the case. >=20 > It does take many hand-stands to doit... >=20 >>> Of course, it doesn=92t solve all the problems, just means we have = more tools to deploy. >>>=20 >>> 3.5 is also quite experimental as well. >>>=20 >>> But there=92s been no real talk about the right path forward: just = FUD and hand wringing on the lists. We do need to have a real discussion = about this. Not the lame pot-shots that have happened to date: what = versions do we support upgrading from, what configurations, etc. If we = had that discussion, then we wouldn=92t even need what Adrian suggests. = We=92d just say you have to have FreeBSD 9.2 or newer with clang 3.3 (or = is it clang 3.4) to bootstrap, and if you want to use other tools, you = are on your own. This would break updating from 8.x, but that=92s likely = OK. Be we need to have this discussion. >>=20 >> I'd personally like to rehash the "build from under Linux" = discussion. >> I keep bumping into cases like this where a lot of the work being = done >> to make this stuff happen is in line with what we need to be able to >> build FreeBSD under a non-FreeBSD operating system. I'd really like >> _that_ to happen - it'll help migrations _to_ freebsd from other >> projects. >=20 > No. Have that as a separate discussion. That=92s a big bike shed of = wonder and requires functionality not present in the tree (e.g. actual = work). My discussion is =93we currently allow X to work, I want to = change that to X+Y so we can import Z.=94 which is much smaller. So go = ahead and have your linux discussion, but don=92t hijack mine. >=20 > Warner Thanks guys, A =93no=94 is also an answer and it seems I have to work-around my = throw-catch=92es with setjmp/longjmp for the time being.=20 As for "This would break updating from 8.x, but that=92s likely OK.=94 - = I totally agree with that it=92s OK. I think function has precedence = over legacy support.=20 Understand me correctly now. Legacy support _is_ important. It=92s just = that current function is _more_ important.=20 At the moment we have a system that doesn=92t support c++ exceptions, = this is a serious limitation. It means that we=92re not standard = compliant. This will likely make tentative developers disappointed. Most (all?) = RPI/beaglebone developers would not care whether their systems was = upgradeable from FreeBSD-8 or not.=20 /Olavi From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 18:18:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01DA488C; Sat, 7 Jun 2014 18:18:09 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B08CF2492; Sat, 7 Jun 2014 18:18:07 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s57IH49Y019447; Sat, 7 Jun 2014 13:18:00 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp1.rice.edu with ESMTP id 1m6965uvx9-1; Sat, 07 Jun 2014 13:18:00 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 1BB2A500169; Sat, 7 Jun 2014 13:18:00 -0500 (CDT) Message-ID: <53935755.70908@rice.edu> Date: Sat, 07 Jun 2014 13:17:57 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Olivier Houchard , Adrian Chadd , "freebsd-arm@freebsd.org" , alc@freebsd.org, kib@freebsd.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> <20140601081153.GU43976@funkthat.com> In-Reply-To: <20140601081153.GU43976@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------070407040005080007020500" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=10 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406070252 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 18:18:09 -0000 This is a multi-part message in MIME format. --------------070407040005080007020500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/01/2014 03:11, John-Mark Gurney wrote: > Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: >> On 05/30/2014 01:32, John-Mark Gurney wrote: >>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: >>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: >>>>> On 29 May 2014 10:16, Olivier Houchard wrote: >>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: >>>>>>> Have you tested this on xscale hardware? >>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot >>>>>> again. >>>>> Woo! What can I provide to help you do this? :-) >>>>> >>>>> (Drinks? Food? Donations?) >>>>> >>>>> >>>> Drinks and food are always appreciated ;) >>>> It almost boots for me now, except a few userland programs gets SIGSEGV or >>>> SIGILL along the way, trying to figure out why. >>> Thanks for fixing ddb... I'm getting panic messages again... bad >>> news is that my panic is still around: >>> panic: vm_page_alloc: page 0xc07e73b0 is wired >>> >>> Though, interestingly, it looks like sparc64 has a similar panic: >>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 >>> >>> kib, Alan, any clue to why this is happening? Any suggestions as to >>> help track it down? >> I'm afraid not. The dump below shows a perfectly normal, in-use page. >> If this page had actually been free prior to the vm_page_alloc() call, >> then other fields, like dirty, would have been different. In other >> words, this isn't just a problem with the wire count. >> >> What object is vm_page_alloc() being performed on? > Is this enough? Or do you need more? > > panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 > KDB: enter: panic > [ thread pid 781 tid 100051 ] > Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > db> show object/f 0xc1500b40 > Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 > sref=0, backing_object(0)=(0)+0x0 > memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) > ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) > > If you need more, let me know what/how to get it, and I will... > Anyone who has seen the "wired page" panic, please try the attached patch. It introduces some new KASSERT()s that may help me to narrow down the problem. I haven't been able to trigger these KASSERT()s on amd64, but the symptoms that you guys are reporting are consistent with a bug that would trigger these KASSERT()s. >>> Lastest dump of the vm_page from a tree from today is: >>> {'act_count': '\x00', >>> 'aflags': '\x00', >>> 'busy_lock': 1, >>> 'dirty': '\xff', >>> 'flags': 0, >>> 'hold_count': 0, >>> 'listq': {'tqe_next': 0xc07e7400, 'tqe_prev': 0xc06e63a0}, >>> 'md': {'pv_kva': 3235893248, >>> 'pv_list': {'tqh_first': 0x0, 'tqh_last': 0xc07e73e0}, >>> 'pv_memattr': '\x00', >>> 'pvh_attrs': 0}, >>> 'object': 0xc06e6378, >>> 'oflags': '\x04', >>> 'order': '\t', >>> 'phys_addr': 9424896, >>> 'pindex': 3581, >>> 'plinks': {'memguard': {'p': 0, 'v': 3228461644}, >>> 'q': {'tqe_next': 0x0, 'tqe_prev': 0xc06e6a4c}, >>> 's': {'pv': 0xc06e6a4c, 'ss': {'sle_next': 0x0}}}, >>> 'pool': '\x00', >>> 'queue': '\xff', >>> 'segind': '\x02', >>> 'valid': '\xff', >>> 'wire_count': 1} >>> >>> This appears to be on the kmem_object list as: >>> c06e62d8 B kernel_object_store >>> c06e6378 B kmem_object_store >>> c06e6418 b old_msync >>> >>> and you can see the tqh_last would be part of kmem_object_store... >>> >>> Could this be something bad happening w/ when memory is low? The >>> board I'm testing on has only 64MB (54MB avail), so it hits that >>> pretty quickly... --------------070407040005080007020500 Content-Type: text/plain; charset=ISO-8859-15; name="arm_debug.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_debug.patch" Index: vm/vm_phys.c =================================================================== --- vm/vm_phys.c (revision 267209) +++ vm/vm_phys.c (working copy) @@ -693,6 +693,7 @@ vm_phys_free_pages(vm_page_t m, int order) void vm_phys_free_contig(vm_page_t m, u_long npages) { + vm_page_t m_tmp; u_int n; int order; @@ -714,6 +715,10 @@ vm_phys_free_contig(vm_page_t m, u_long npages) n = 1 << order; if (npages < n) break; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: xxx")); vm_phys_free_pages(m, order); m += n; } @@ -721,6 +726,10 @@ vm_phys_free_contig(vm_page_t m, u_long npages) for (; npages > 0; npages -= n) { order = flsl(npages) - 1; n = 1 << order; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: yyy")); vm_phys_free_pages(m, order); m += n; } --------------070407040005080007020500-- From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 18:42:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0443F117 for ; Sat, 7 Jun 2014 18:42:27 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B35D7266E for ; Sat, 7 Jun 2014 18:42:26 +0000 (UTC) Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [37.140.190.27]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 82E3E1A40ECE for ; Sat, 7 Jun 2014 22:42:14 +0400 (MSK) Received: from smtp2o.mail.yandex.net (localhost [127.0.0.1]) by smtp2o.mail.yandex.net (Yandex) with ESMTP id 398A736A1BA2 for ; Sat, 7 Jun 2014 22:42:14 +0400 (MSK) Received: from adsl-71-135-103-89.dsl.pltn13.pacbell.net (adsl-71-135-103-89.dsl.pltn13.pacbell.net [71.135.103.89]) by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id VzkjizBQld-gCO4oIhH; Sat, 7 Jun 2014 22:42:13 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 4fb1e3dc-7f7d-465c-9477-f46c62e785d6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402166533; bh=+zAHx1HQN5OJjG6vqPF92PJQkPLPgsAuBj8ukWKhyhs=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=otW/Z9R5yOISrNP7i+RFtMw+qBoCZYO+Zu2ddnpNkjuhMtdkiGddRfQbfpEswuYRa sk7o7dGHuv7Wn9A+BRZlYuV+26nBndfo4kQ0YJqHZr3vQtGF/nHjpU8NGimYA4Z0Am uMjcPsAcwrjdye0JV0otnSubxJaqQiwpeHBBFj5g= Authentication-Results: smtp2o.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <53935D02.2030604@narod.ru> Date: Sun, 08 Jun 2014 00:42:10 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Compilation for ARM Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 18:42:27 -0000 Hi all! I'm trying to cross-compile FreeBSD kernel with clang for ARM, but currently I have some troubles with it. Main is: Clang uses external assembler and invokes GCC with some really specific flags, that aren't supported by GCC (like -fformat-extensions). As base I used this guide: http://people.freebsd.org/~cognet/arm.html So the question is, had somebody tried to cross-compile FreeBSD kernel with clang for ARM? I would glad if somebody ready to share such experience ;-) Thanks! -Stepan From owner-freebsd-arm@FreeBSD.ORG Sat Jun 7 19:01:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC4995E7 for ; Sat, 7 Jun 2014 19:01:22 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B917A27C1 for ; Sat, 7 Jun 2014 19:01:22 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s57J1ETS089093; Sat, 7 Jun 2014 19:01:14 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id exsrzdgv8suyitysfdywxsjxzs; Sat, 07 Jun 2014 19:01:14 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: Compilation for ARM From: Tim Kientzle In-Reply-To: <53935D02.2030604@narod.ru> Date: Sat, 7 Jun 2014 12:01:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> References: <53935D02.2030604@narod.ru> To: Stepan Dyatkovskiy X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 19:01:22 -0000 On Jun 7, 2014, at 11:42 AM, Stepan Dyatkovskiy wrote: > I'm trying to cross-compile FreeBSD kernel with clang for ARM,... For what board? There are a few high-level tools now for building ready-to-run system images for particular boards. > As base I used this guide: > http://people.freebsd.org/~cognet/arm.html That looks pretty old; there are much simpler approaches available now. The basic process for cross-building is: $ make TARGET_ARCH=armv6 buildworld $ make TARGET_ARCH=armv6 KERNCONF=XYZ buildkernel In particular, buildworld builds all of the cross-compile tools for you. Also, clang is the default for FreeBSD on ARM now, so the above commands all use clang. If you want to do kernel development (which involves repeatedly making changes and rebuilding), you'll want to experiment with $ make TARGET_ARCH=armv6 buildenv This starts a shell with all the necessary environment variables already correctly set for cross-buildling. (It assumes you have already done a cross-buildworld to build the tools.) Note: For some targets, you need to also specify TARGET_CPUTYPE. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Sun Jun 8 00:39:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C2B8E2; Sun, 8 Jun 2014 00:39:46 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 133AF2184; Sun, 8 Jun 2014 00:39:45 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s580dijn028515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jun 2014 17:39:45 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s580diAM028514; Sat, 7 Jun 2014 17:39:44 -0700 (PDT) (envelope-from jmg) Date: Sat, 7 Jun 2014 17:39:44 -0700 From: John-Mark Gurney To: Alan Cox Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140608003944.GK31367@funkthat.com> Mail-Followup-To: Alan Cox , "freebsd-arm@freebsd.org" , alc@freebsd.org References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53935755.70908@rice.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 07 Jun 2014 17:39:45 -0700 (PDT) Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 00:39:46 -0000 Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 -0500: > On 06/01/2014 03:11, John-Mark Gurney wrote: > > Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: > >> On 05/30/2014 01:32, John-Mark Gurney wrote: > >>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: > >>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: > >>>>> On 29 May 2014 10:16, Olivier Houchard wrote: > >>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > >>>>>>> Have you tested this on xscale hardware? > >>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot > >>>>>> again. > >>>>> Woo! What can I provide to help you do this? :-) > >>>>> > >>>>> (Drinks? Food? Donations?) > >>>>> > >>>>> > >>>> Drinks and food are always appreciated ;) > >>>> It almost boots for me now, except a few userland programs gets SIGSEGV or > >>>> SIGILL along the way, trying to figure out why. > >>> Thanks for fixing ddb... I'm getting panic messages again... bad > >>> news is that my panic is still around: > >>> panic: vm_page_alloc: page 0xc07e73b0 is wired > >>> > >>> Though, interestingly, it looks like sparc64 has a similar panic: > >>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 > >>> > >>> kib, Alan, any clue to why this is happening? Any suggestions as to > >>> help track it down? > >> I'm afraid not. The dump below shows a perfectly normal, in-use page. > >> If this page had actually been free prior to the vm_page_alloc() call, > >> then other fields, like dirty, would have been different. In other > >> words, this isn't just a problem with the wire count. > >> > >> What object is vm_page_alloc() being performed on? > > Is this enough? Or do you need more? > > > > panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 > > KDB: enter: panic > > [ thread pid 781 tid 100051 ] > > Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > > db> show object/f 0xc1500b40 > > Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 > > sref=0, backing_object(0)=(0)+0x0 > > memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) > > ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) > > > > If you need more, let me know what/how to get it, and I will... > > > > > Anyone who has seen the "wired page" panic, please try the attached > patch. It introduces some new KASSERT()s that may help me to narrow > down the problem. I haven't been able to trigger these KASSERT()s on > amd64, but the symptoms that you guys are reporting are consistent with > a bug that would trigger these KASSERT()s. Ok, it triggered the xxx one: Starting sendmail_msp_queue. panic: vm_phys_free_contig: xxx KDB: enter: panic [ thread pid 782 tid 100051 ] Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 782 tid 100051 td 0xc1470000 db_trace_self() at db_trace_self pc = 0xc0566ec8 lr = 0xc0566f54 (db_trace_thread+0x50) sp = 0xcd830850 fp = 0xc03db694 db_trace_thread() at db_trace_thread+0x50 pc = 0xc0566f54 lr = 0xc022cd14 (db_command_init+0x620) sp = 0xcd8308b0 fp = 0xc03db694 db_command_init() at db_command_init+0x620 pc = 0xc022cd14 lr = 0xc022c3ec (db_skip_to_eol+0x480) sp = 0xcd8308c8 fp = 0xc03db694 r4 = 0xc0683c30 r5 = 0x00000000 db_skip_to_eol() at db_skip_to_eol+0x480 pc = 0xc022c3ec lr = 0xc022c554 (db_command_loop+0x5c) sp = 0xcd830968 fp = 0xc03db694 r4 = 0xcd83097c r5 = 0xc0683efc r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000001 r10 = 0x600000d3 db_command_loop() at db_command_loop+0x5c pc = 0xc022c554 lr = 0xc022e99c (X_db_sym_numargs+0xec) sp = 0xcd830970 fp = 0xc03db694 X_db_sym_numargs() at X_db_sym_numargs+0xec pc = 0xc022e99c lr = 0xc03db8c4 (kdb_trap+0x94) sp = 0xcd830a88 fp = 0xc03db694 r4 = 0x00000000 kdb_trap() at kdb_trap+0x94 pc = 0xc03db8c4 lr = 0xc0578eb0 (undefinedinstruction+0x2c8) sp = 0xcd830aa8 fp = 0xc03db694 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r7 = 0xcd830b20 r8 = 0xe7ffffff r10 = 0xe7ffffff undefinedinstruction() at undefinedinstruction+0x2c8 pc = 0xc0578eb0 lr = 0xc0568a0c (exception_exit) sp = 0xcd830b20 fp = 0xc0613e70 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0xc06d0ebc r7 = 0xcd830ba4 r8 = 0xc1470000 r9 = 0x00000013 r10 = 0x00000010 exception_exit() at exception_exit pc = 0xc0568a0c lr = 0xc03db68c (kdb_enter+0x38) sp = 0xcd830b70 fp = 0xc0613e70 r0 = 0x00000012 r1 = 0x60000013 r2 = 0xc06df2ac r3 = 0xc06d0ee8 r4 = 0xc05e5258 r5 = 0xc06155e8 r6 = 0xc06d0ebc r7 = 0xcd830ba4 r8 = 0xc1470000 r9 = 0x00000013 r10 = 0x00000010 r12 = 0xc05e2518 kdb_enter() at kdb_enter+0x44 pc = 0xc03db698 lr = 0xc03aa094 (kern_reboot+0x948) sp = 0xcd830b78 fp = 0xc0613e70 r4 = 0x00000100 kern_reboot() at kern_reboot+0x948 pc = 0xc03aa094 lr = 0xc03aa164 (kassert_panic+0x68) sp = 0xcd830b90 fp = 0xc0613e70 r4 = 0xc06155e8 r5 = 0xc07e74a0 r6 = 0xc07e6fa0 r7 = 0x00000004 r8 = 0x00000010 kassert_panic() at kassert_panic+0x68 pc = 0xc03aa164 lr = 0xc055a0a8 (vm_phys_free_contig+0x8c) sp = 0xcd830bb0 fp = 0xc0613e70 r0 = 0xc06155e8 r1 = 0xc07e6d20 r2 = 0xc06e6a70 r3 = 0x00000000 r4 = 0xc07e73b0 vm_phys_free_contig() at vm_phys_free_contig+0x8c pc = 0xc055a0a8 lr = 0xc055ca70 (vm_reserv_startup+0x4bc) sp = 0xcd830bd0 fp = 0xc0613e70 r4 = 0xc08fb2cc r5 = 0x00000008 r6 = 0x000000e8 r7 = 0xc08fb280 r8 = 0x00000005 r10 = 0x00000001 vm_reserv_startup() at vm_reserv_startup+0x4bc pc = 0xc055ca70 lr = 0xc055cb40 (vm_reserv_startup+0x58c) sp = 0xcd830be8 fp = 0xc0613e70 r4 = 0xc08fb280 r5 = 0x00000000 r6 = 0xc14b7280 r7 = 0x00000040 r8 = 0x00000000 vm_reserv_startup() at vm_reserv_startup+0x58c pc = 0xc055cb40 lr = 0xc055ce08 (vm_reserv_reclaim_inactive+0x34) sp = 0xcd830bf0 fp = 0xc0613e70 r4 = 0xc06e6550 vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 pc = 0xc055ce08 lr = 0xc0554cb8 (vm_page_alloc+0x280) sp = 0xcd830bf8 fp = 0xc0613e70 vm_page_alloc() at vm_page_alloc+0x280 pc = 0xc0554cb8 lr = 0xc0540eb0 (vm_fault_hold+0x60c) sp = 0xcd830c30 fp = 0xcd830dac r4 = 0xc14b7280 r5 = 0xc0618d00 r6 = 0xcd830eb0 r7 = 0xc1470000 r8 = 0xcd830e60 r9 = 0x00000000 r10 = 0x00000000 vm_fault_hold() at vm_fault_hold+0x60c pc = 0xc0540eb0 lr = 0xc05426b8 (vm_fault+0x44) sp = 0xcd830db0 fp = 0x00000002 r4 = 0xc14c8a0c r5 = 0xc0618d00 r6 = 0xcd830eb0 r7 = 0xc1470000 r8 = 0xcd830e60 r9 = 0x00000001 r10 = 0x00000000 vm_fault() at vm_fault+0x44 pc = 0xc05426b8 lr = 0xc05782d0 (data_abort_handler+0x35c) sp = 0xcd830dc0 fp = 0x00000002 data_abort_handler() at data_abort_handler+0x35c pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) sp = 0xcd830dc0 fp = 0x00000002 data_abort_handler() at data_abort_handler+0x35c pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) sp = 0xcd830e60 fp = 0x20c43000 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0x00000000 r7 = 0x20443740 r8 = 0x0009b8e4 r9 = 0x00000001 r10 = 0x00000004 exception_exit() at exception_exit pc = 0xc0568a0c lr = 0x204140d0 (0x204140d0) sp = 0xcd830eb0 fp = 0x20c43000 r0 = 0x00000000 r1 = 0x20c4302c r2 = 0x00000004 r3 = 0x00000000 r4 = 0x20446190 r5 = 0x20c4302c r6 = 0x00000000 r7 = 0x20443740 r8 = 0x0009b8e4 r9 = 0x00000001 r10 = 0x00000004 r12 = 0x00000001 Unable to unwind into user mode Hope this helps, let me know if you need anything else... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Jun 8 02:03:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 578B3C31; Sun, 8 Jun 2014 02:03:48 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C44A273F; Sun, 8 Jun 2014 02:03:47 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5823jd7029579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jun 2014 19:03:46 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5823jFF029578; Sat, 7 Jun 2014 19:03:45 -0700 (PDT) (envelope-from jmg) Date: Sat, 7 Jun 2014 19:03:45 -0700 From: John-Mark Gurney To: Alan Cox , "freebsd-arm@freebsd.org" , alc@freebsd.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140608020345.GM31367@funkthat.com> Mail-Followup-To: Alan Cox , "freebsd-arm@freebsd.org" , alc@freebsd.org References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140608003944.GK31367@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 07 Jun 2014 19:03:46 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 02:03:48 -0000 John-Mark Gurney wrote this message on Sat, Jun 07, 2014 at 17:39 -0700: > Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 -0500: > > On 06/01/2014 03:11, John-Mark Gurney wrote: > > > Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: > > >> On 05/30/2014 01:32, John-Mark Gurney wrote: > > >>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: > > >>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: > > >>>>> On 29 May 2014 10:16, Olivier Houchard wrote: > > >>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > > >>>>>>> Have you tested this on xscale hardware? > > >>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot > > >>>>>> again. > > >>>>> Woo! What can I provide to help you do this? :-) > > >>>>> > > >>>>> (Drinks? Food? Donations?) > > >>>>> > > >>>>> > > >>>> Drinks and food are always appreciated ;) > > >>>> It almost boots for me now, except a few userland programs gets SIGSEGV or > > >>>> SIGILL along the way, trying to figure out why. > > >>> Thanks for fixing ddb... I'm getting panic messages again... bad > > >>> news is that my panic is still around: > > >>> panic: vm_page_alloc: page 0xc07e73b0 is wired > > >>> > > >>> Though, interestingly, it looks like sparc64 has a similar panic: > > >>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 > > >>> > > >>> kib, Alan, any clue to why this is happening? Any suggestions as to > > >>> help track it down? > > >> I'm afraid not. The dump below shows a perfectly normal, in-use page. > > >> If this page had actually been free prior to the vm_page_alloc() call, > > >> then other fields, like dirty, would have been different. In other > > >> words, this isn't just a problem with the wire count. > > >> > > >> What object is vm_page_alloc() being performed on? > > > Is this enough? Or do you need more? > > > > > > panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 > > > KDB: enter: panic > > > [ thread pid 781 tid 100051 ] > > > Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > > > db> show object/f 0xc1500b40 > > > Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 > > > sref=0, backing_object(0)=(0)+0x0 > > > memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) > > > ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) > > > > > > If you need more, let me know what/how to get it, and I will... > > > > > > > > > Anyone who has seen the "wired page" panic, please try the attached > > patch. It introduces some new KASSERT()s that may help me to narrow > > down the problem. I haven't been able to trigger these KASSERT()s on > > amd64, but the symptoms that you guys are reporting are consistent with > > a bug that would trigger these KASSERT()s. > > Ok, it triggered the xxx one: > Starting sendmail_msp_queue. > panic: vm_phys_free_contig: xxx > KDB: enter: panic > [ thread pid 782 tid 100051 ] > Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 782 tid 100051 td 0xc1470000 > db_trace_self() at db_trace_self > pc = 0xc0566ec8 lr = 0xc0566f54 (db_trace_thread+0x50) > sp = 0xcd830850 fp = 0xc03db694 > db_trace_thread() at db_trace_thread+0x50 > pc = 0xc0566f54 lr = 0xc022cd14 (db_command_init+0x620) > sp = 0xcd8308b0 fp = 0xc03db694 > db_command_init() at db_command_init+0x620 > pc = 0xc022cd14 lr = 0xc022c3ec (db_skip_to_eol+0x480) > sp = 0xcd8308c8 fp = 0xc03db694 > r4 = 0xc0683c30 r5 = 0x00000000 > db_skip_to_eol() at db_skip_to_eol+0x480 > pc = 0xc022c3ec lr = 0xc022c554 (db_command_loop+0x5c) > sp = 0xcd830968 fp = 0xc03db694 > r4 = 0xcd83097c r5 = 0xc0683efc > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0x00000001 r10 = 0x600000d3 > db_command_loop() at db_command_loop+0x5c > pc = 0xc022c554 lr = 0xc022e99c (X_db_sym_numargs+0xec) > sp = 0xcd830970 fp = 0xc03db694 > X_db_sym_numargs() at X_db_sym_numargs+0xec > pc = 0xc022e99c lr = 0xc03db8c4 (kdb_trap+0x94) > sp = 0xcd830a88 fp = 0xc03db694 > r4 = 0x00000000 > kdb_trap() at kdb_trap+0x94 > pc = 0xc03db8c4 lr = 0xc0578eb0 (undefinedinstruction+0x2c8) > sp = 0xcd830aa8 fp = 0xc03db694 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000000 r7 = 0xcd830b20 > r8 = 0xe7ffffff r10 = 0xe7ffffff > undefinedinstruction() at undefinedinstruction+0x2c8 > pc = 0xc0578eb0 lr = 0xc0568a0c (exception_exit) > sp = 0xcd830b20 fp = 0xc0613e70 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0xc06d0ebc r7 = 0xcd830ba4 > r8 = 0xc1470000 r9 = 0x00000013 > r10 = 0x00000010 > exception_exit() at exception_exit > pc = 0xc0568a0c lr = 0xc03db68c (kdb_enter+0x38) > sp = 0xcd830b70 fp = 0xc0613e70 > r0 = 0x00000012 r1 = 0x60000013 > r2 = 0xc06df2ac r3 = 0xc06d0ee8 > r4 = 0xc05e5258 r5 = 0xc06155e8 > r6 = 0xc06d0ebc r7 = 0xcd830ba4 > r8 = 0xc1470000 r9 = 0x00000013 > r10 = 0x00000010 r12 = 0xc05e2518 > kdb_enter() at kdb_enter+0x44 > pc = 0xc03db698 lr = 0xc03aa094 (kern_reboot+0x948) > sp = 0xcd830b78 fp = 0xc0613e70 > r4 = 0x00000100 > kern_reboot() at kern_reboot+0x948 > pc = 0xc03aa094 lr = 0xc03aa164 (kassert_panic+0x68) > sp = 0xcd830b90 fp = 0xc0613e70 > r4 = 0xc06155e8 r5 = 0xc07e74a0 > r6 = 0xc07e6fa0 r7 = 0x00000004 > r8 = 0x00000010 > kassert_panic() at kassert_panic+0x68 > pc = 0xc03aa164 lr = 0xc055a0a8 (vm_phys_free_contig+0x8c) > sp = 0xcd830bb0 fp = 0xc0613e70 > r0 = 0xc06155e8 r1 = 0xc07e6d20 > r2 = 0xc06e6a70 r3 = 0x00000000 > r4 = 0xc07e73b0 > vm_phys_free_contig() at vm_phys_free_contig+0x8c > pc = 0xc055a0a8 lr = 0xc055ca70 (vm_reserv_startup+0x4bc) > sp = 0xcd830bd0 fp = 0xc0613e70 > r4 = 0xc08fb2cc r5 = 0x00000008 > r6 = 0x000000e8 r7 = 0xc08fb280 > r8 = 0x00000005 r10 = 0x00000001 > vm_reserv_startup() at vm_reserv_startup+0x4bc > pc = 0xc055ca70 lr = 0xc055cb40 (vm_reserv_startup+0x58c) > sp = 0xcd830be8 fp = 0xc0613e70 > r4 = 0xc08fb280 r5 = 0x00000000 > r6 = 0xc14b7280 r7 = 0x00000040 > r8 = 0x00000000 > vm_reserv_startup() at vm_reserv_startup+0x58c > pc = 0xc055cb40 lr = 0xc055ce08 (vm_reserv_reclaim_inactive+0x34) > sp = 0xcd830bf0 fp = 0xc0613e70 > r4 = 0xc06e6550 > vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 > pc = 0xc055ce08 lr = 0xc0554cb8 (vm_page_alloc+0x280) > sp = 0xcd830bf8 fp = 0xc0613e70 > vm_page_alloc() at vm_page_alloc+0x280 > pc = 0xc0554cb8 lr = 0xc0540eb0 (vm_fault_hold+0x60c) > sp = 0xcd830c30 fp = 0xcd830dac > r4 = 0xc14b7280 r5 = 0xc0618d00 > r6 = 0xcd830eb0 r7 = 0xc1470000 > r8 = 0xcd830e60 r9 = 0x00000000 > r10 = 0x00000000 > vm_fault_hold() at vm_fault_hold+0x60c > pc = 0xc0540eb0 lr = 0xc05426b8 (vm_fault+0x44) > sp = 0xcd830db0 fp = 0x00000002 > r4 = 0xc14c8a0c r5 = 0xc0618d00 > r6 = 0xcd830eb0 r7 = 0xc1470000 > r8 = 0xcd830e60 r9 = 0x00000001 > r10 = 0x00000000 > vm_fault() at vm_fault+0x44 > pc = 0xc05426b8 lr = 0xc05782d0 (data_abort_handler+0x35c) > sp = 0xcd830dc0 fp = 0x00000002 > data_abort_handler() at data_abort_handler+0x35c > pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > sp = 0xcd830dc0 fp = 0x00000002 > data_abort_handler() at data_abort_handler+0x35c > pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > sp = 0xcd830e60 fp = 0x20c43000 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0x00000000 r7 = 0x20443740 > r8 = 0x0009b8e4 r9 = 0x00000001 > r10 = 0x00000004 > exception_exit() at exception_exit > pc = 0xc0568a0c lr = 0x204140d0 (0x204140d0) > sp = 0xcd830eb0 fp = 0x20c43000 > r0 = 0x00000000 r1 = 0x20c4302c > r2 = 0x00000004 r3 = 0x00000000 > r4 = 0x20446190 r5 = 0x20c4302c > r6 = 0x00000000 r7 = 0x20443740 > r8 = 0x0009b8e4 r9 = 0x00000001 > r10 = 0x00000004 r12 = 0x00000001 > Unable to unwind into user mode > > Hope this helps, let me know if you need anything else... I realized you might want some info from the object... Code for xxx became: KASSERT(m_tmp->object == NULL || (m_tmp->flags & PG_CACHED) != 0, ("vm_phys_free_contig: %p, %p, %x", m_tmp, m_tmp->object, m_tmp->flags)); This information is from a different run than the stack trace above... from the console: Starting sendmail_msp_queue. panic: vm_phys_free_contig: 0xc07e73b0, 0xc06e6378, 0 KDB: enter: panic db> show object/f 0xc06e6378 Object 0xc06e6378: type=4, size=0x20000, res=1803, ref=1, flags=0x1002 ruid -1 charge 0 sref=0, backing_object(0)=(0)+0x0 [...lots of data deleted..] db> show freepages DOMAIN: 0 FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 -- -- -- -- -- -- 08 (001024K) | 000000 | 000000 07 (000512K) | 000001 | 000000 06 (000256K) | 000001 | 000000 05 (000128K) | 000001 | 000000 04 (000064K) | 000000 | 000000 03 (000032K) | 000001 | 000000 02 (000016K) | 000001 | 000000 01 (000008K) | 000000 | 000000 00 (000004K) | 000001 | 000000 db> show pageq pq_free 8247 pq_cache 0 dom 0 page_cnt 14555 free 8247 pq_act 2108 pq_inact 1096 pass 0 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Jun 8 06:15:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0136A52 for ; Sun, 8 Jun 2014 06:15:41 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87B572757 for ; Sun, 8 Jun 2014 06:15:40 +0000 (UTC) Received: from smtp6.mail.yandex.net (smtp6.mail.yandex.net [77.88.61.56]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 248D2BC10E5; Sun, 8 Jun 2014 10:15:30 +0400 (MSK) Received: from smtp6.mail.yandex.net (localhost [127.0.0.1]) by smtp6.mail.yandex.net (Yandex) with ESMTP id BFC331640785; Sun, 8 Jun 2014 10:15:29 +0400 (MSK) Received: from adsl-71-135-103-89.dsl.pltn13.pacbell.net (adsl-71-135-103-89.dsl.pltn13.pacbell.net [71.135.103.89]) by smtp6.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id VL11TKhSsb-FRkueYjS; Sun, 8 Jun 2014 10:15:28 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 2d869b8b-442f-4a71-835a-f7491712734c DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402208129; bh=FrXxAlbCY3RzGCNU043AvPD6vn0+x0ZvZojDdzL1C4Q=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=g/9UtqDLjnUawdjH/rAV0iBmdhaPBb6SkUbDL8J67s6ZBxQAziBeExUdYFVaBLsUK XyyLXSWZsCDNdp9eP5xwfoc/tPZJDl3D8WZhlSxKMMU3DEsBvcgQwsL4qKyoyemIfJ MP2ebuNimLgwVd3u6pD+j0L7+IfYGQFn/eIHzYRk= Authentication-Results: smtp6.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <5393FF7B.4020407@narod.ru> Date: Sun, 08 Jun 2014 12:15:23 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: Compilation for ARM References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> In-Reply-To: <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 06:15:41 -0000 Hi Tim, Thank you for quick response! I will try your advices straight after weekends. We are using pandaboard. Are here any other cortex-a9/a15 boards that has, perhaps, better support in FreeBSD OS? If so, we ready to test it too, because the only thing we need in pandaboard for now is its CPU. Thanks! -Stepan I Tim Kientzle wrote: > On Jun 7, 2014, at 11:42 AM, Stepan Dyatkovskiy wrote: > >> I'm trying to cross-compile FreeBSD kernel with clang for ARM,... > > For what board? There are a few high-level tools now for > building ready-to-run system images for particular boards. > >> As base I used this guide: >> http://people.freebsd.org/~cognet/arm.html > > That looks pretty old; there are much simpler approaches available now. > > The basic process for cross-building is: > > $ make TARGET_ARCH=armv6 buildworld > $ make TARGET_ARCH=armv6 KERNCONF=XYZ buildkernel > > In particular, buildworld builds all of the cross-compile tools for you. > Also, clang is the default for FreeBSD on ARM now, so the above > commands all use clang. > > If you want to do kernel development (which involves repeatedly > making changes and rebuilding), you'll want to experiment with > > $ make TARGET_ARCH=armv6 buildenv > > This starts a shell with all the necessary environment variables > already correctly set for cross-buildling. (It assumes you have > already done a cross-buildworld to build the tools.) > > Note: For some targets, you need to also specify TARGET_CPUTYPE. > > Cheers, > > Tim > From owner-freebsd-arm@FreeBSD.ORG Sun Jun 8 17:30:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADF40620; Sun, 8 Jun 2014 17:30:08 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 69480283E; Sun, 8 Jun 2014 17:30:06 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s58HStmj027511; Sun, 8 Jun 2014 12:30:00 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1mbn6tgcn7-1; Sun, 08 Jun 2014 12:29:59 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 035E94601E2; Sun, 8 Jun 2014 12:29:58 -0500 (CDT) Message-ID: <53949D96.3060409@rice.edu> Date: Sun, 08 Jun 2014 12:29:58 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" , alc@freebsd.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> In-Reply-To: <20140608003944.GK31367@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------010506080105090907030104" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.713890987064109 urlsuspect_oldscore=0.713890987064109 suspectscore=10 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.713890987064109 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406080251 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 17:30:08 -0000 This is a multi-part message in MIME format. --------------010506080105090907030104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/07/2014 19:39, John-Mark Gurney wrote: > Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 -0500: >> On 06/01/2014 03:11, John-Mark Gurney wrote: >>> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: >>>> On 05/30/2014 01:32, John-Mark Gurney wrote: >>>>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: >>>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: >>>>>>> On 29 May 2014 10:16, Olivier Houchard wrote: >>>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: >>>>>>>>> Have you tested this on xscale hardware? >>>>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot >>>>>>>> again. >>>>>>> Woo! What can I provide to help you do this? :-) >>>>>>> >>>>>>> (Drinks? Food? Donations?) >>>>>>> >>>>>>> >>>>>> Drinks and food are always appreciated ;) >>>>>> It almost boots for me now, except a few userland programs gets SIGSEGV or >>>>>> SIGILL along the way, trying to figure out why. >>>>> Thanks for fixing ddb... I'm getting panic messages again... bad >>>>> news is that my panic is still around: >>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired >>>>> >>>>> Though, interestingly, it looks like sparc64 has a similar panic: >>>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 >>>>> >>>>> kib, Alan, any clue to why this is happening? Any suggestions as to >>>>> help track it down? >>>> I'm afraid not. The dump below shows a perfectly normal, in-use page. >>>> If this page had actually been free prior to the vm_page_alloc() call, >>>> then other fields, like dirty, would have been different. In other >>>> words, this isn't just a problem with the wire count. >>>> >>>> What object is vm_page_alloc() being performed on? >>> Is this enough? Or do you need more? >>> >>> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 >>> KDB: enter: panic >>> [ thread pid 781 tid 100051 ] >>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! >>> db> show object/f 0xc1500b40 >>> Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 >>> sref=0, backing_object(0)=(0)+0x0 >>> memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) >>> ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) >>> >>> If you need more, let me know what/how to get it, and I will... >>> >> >> Anyone who has seen the "wired page" panic, please try the attached >> patch. It introduces some new KASSERT()s that may help me to narrow >> down the problem. I haven't been able to trigger these KASSERT()s on >> amd64, but the symptoms that you guys are reporting are consistent with >> a bug that would trigger these KASSERT()s. > Ok, it triggered the xxx one: > Starting sendmail_msp_queue. > panic: vm_phys_free_contig: xxx > KDB: enter: panic > [ thread pid 782 tid 100051 ] > Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 782 tid 100051 td 0xc1470000 > db_trace_self() at db_trace_self > pc = 0xc0566ec8 lr = 0xc0566f54 (db_trace_thread+0x50) > sp = 0xcd830850 fp = 0xc03db694 > db_trace_thread() at db_trace_thread+0x50 > pc = 0xc0566f54 lr = 0xc022cd14 (db_command_init+0x620) > sp = 0xcd8308b0 fp = 0xc03db694 > db_command_init() at db_command_init+0x620 > pc = 0xc022cd14 lr = 0xc022c3ec (db_skip_to_eol+0x480) > sp = 0xcd8308c8 fp = 0xc03db694 > r4 = 0xc0683c30 r5 = 0x00000000 > db_skip_to_eol() at db_skip_to_eol+0x480 > pc = 0xc022c3ec lr = 0xc022c554 (db_command_loop+0x5c) > sp = 0xcd830968 fp = 0xc03db694 > r4 = 0xcd83097c r5 = 0xc0683efc > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0x00000001 r10 = 0x600000d3 > db_command_loop() at db_command_loop+0x5c > pc = 0xc022c554 lr = 0xc022e99c (X_db_sym_numargs+0xec) > sp = 0xcd830970 fp = 0xc03db694 > X_db_sym_numargs() at X_db_sym_numargs+0xec > pc = 0xc022e99c lr = 0xc03db8c4 (kdb_trap+0x94) > sp = 0xcd830a88 fp = 0xc03db694 > r4 = 0x00000000 > kdb_trap() at kdb_trap+0x94 > pc = 0xc03db8c4 lr = 0xc0578eb0 (undefinedinstruction+0x2c8) > sp = 0xcd830aa8 fp = 0xc03db694 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000000 r7 = 0xcd830b20 > r8 = 0xe7ffffff r10 = 0xe7ffffff > undefinedinstruction() at undefinedinstruction+0x2c8 > pc = 0xc0578eb0 lr = 0xc0568a0c (exception_exit) > sp = 0xcd830b20 fp = 0xc0613e70 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0xc06d0ebc r7 = 0xcd830ba4 > r8 = 0xc1470000 r9 = 0x00000013 > r10 = 0x00000010 > exception_exit() at exception_exit > pc = 0xc0568a0c lr = 0xc03db68c (kdb_enter+0x38) > sp = 0xcd830b70 fp = 0xc0613e70 > r0 = 0x00000012 r1 = 0x60000013 > r2 = 0xc06df2ac r3 = 0xc06d0ee8 > r4 = 0xc05e5258 r5 = 0xc06155e8 > r6 = 0xc06d0ebc r7 = 0xcd830ba4 > r8 = 0xc1470000 r9 = 0x00000013 > r10 = 0x00000010 r12 = 0xc05e2518 > kdb_enter() at kdb_enter+0x44 > pc = 0xc03db698 lr = 0xc03aa094 (kern_reboot+0x948) > sp = 0xcd830b78 fp = 0xc0613e70 > r4 = 0x00000100 > kern_reboot() at kern_reboot+0x948 > pc = 0xc03aa094 lr = 0xc03aa164 (kassert_panic+0x68) > sp = 0xcd830b90 fp = 0xc0613e70 > r4 = 0xc06155e8 r5 = 0xc07e74a0 > r6 = 0xc07e6fa0 r7 = 0x00000004 > r8 = 0x00000010 > kassert_panic() at kassert_panic+0x68 > pc = 0xc03aa164 lr = 0xc055a0a8 (vm_phys_free_contig+0x8c) > sp = 0xcd830bb0 fp = 0xc0613e70 > r0 = 0xc06155e8 r1 = 0xc07e6d20 > r2 = 0xc06e6a70 r3 = 0x00000000 > r4 = 0xc07e73b0 > vm_phys_free_contig() at vm_phys_free_contig+0x8c > pc = 0xc055a0a8 lr = 0xc055ca70 (vm_reserv_startup+0x4bc) > sp = 0xcd830bd0 fp = 0xc0613e70 > r4 = 0xc08fb2cc r5 = 0x00000008 > r6 = 0x000000e8 r7 = 0xc08fb280 > r8 = 0x00000005 r10 = 0x00000001 > vm_reserv_startup() at vm_reserv_startup+0x4bc > pc = 0xc055ca70 lr = 0xc055cb40 (vm_reserv_startup+0x58c) > sp = 0xcd830be8 fp = 0xc0613e70 > r4 = 0xc08fb280 r5 = 0x00000000 > r6 = 0xc14b7280 r7 = 0x00000040 > r8 = 0x00000000 > vm_reserv_startup() at vm_reserv_startup+0x58c > pc = 0xc055cb40 lr = 0xc055ce08 (vm_reserv_reclaim_inactive+0x34) > sp = 0xcd830bf0 fp = 0xc0613e70 > r4 = 0xc06e6550 > vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 > pc = 0xc055ce08 lr = 0xc0554cb8 (vm_page_alloc+0x280) > sp = 0xcd830bf8 fp = 0xc0613e70 > vm_page_alloc() at vm_page_alloc+0x280 > pc = 0xc0554cb8 lr = 0xc0540eb0 (vm_fault_hold+0x60c) > sp = 0xcd830c30 fp = 0xcd830dac > r4 = 0xc14b7280 r5 = 0xc0618d00 > r6 = 0xcd830eb0 r7 = 0xc1470000 > r8 = 0xcd830e60 r9 = 0x00000000 > r10 = 0x00000000 > vm_fault_hold() at vm_fault_hold+0x60c > pc = 0xc0540eb0 lr = 0xc05426b8 (vm_fault+0x44) > sp = 0xcd830db0 fp = 0x00000002 > r4 = 0xc14c8a0c r5 = 0xc0618d00 > r6 = 0xcd830eb0 r7 = 0xc1470000 > r8 = 0xcd830e60 r9 = 0x00000001 > r10 = 0x00000000 > vm_fault() at vm_fault+0x44 > pc = 0xc05426b8 lr = 0xc05782d0 (data_abort_handler+0x35c) > sp = 0xcd830dc0 fp = 0x00000002 > data_abort_handler() at data_abort_handler+0x35c > pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > sp = 0xcd830dc0 fp = 0x00000002 > data_abort_handler() at data_abort_handler+0x35c > pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > sp = 0xcd830e60 fp = 0x20c43000 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0x00000000 r7 = 0x20443740 > r8 = 0x0009b8e4 r9 = 0x00000001 > r10 = 0x00000004 > exception_exit() at exception_exit > pc = 0xc0568a0c lr = 0x204140d0 (0x204140d0) > sp = 0xcd830eb0 fp = 0x20c43000 > r0 = 0x00000000 r1 = 0x20c4302c > r2 = 0x00000004 r3 = 0x00000000 > r4 = 0x20446190 r5 = 0x20c4302c > r6 = 0x00000000 r7 = 0x20443740 > r8 = 0x0009b8e4 r9 = 0x00000001 > r10 = 0x00000004 r12 = 0x00000001 > Unable to unwind into user mode > > Hope this helps, let me know if you need anything else... > Please try the attached patch. It adds another KASSERT() loop. Depending on which KASSERT() fires, that will tell us whether to look deeper at this function or its caller for the source of the problem. Alan --------------010506080105090907030104 Content-Type: text/plain; charset=ISO-8859-15; name="arm_debug2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_debug2.patch" Index: vm/vm_phys.c =================================================================== --- vm/vm_phys.c (revision 267209) +++ vm/vm_phys.c (working copy) @@ -693,9 +693,16 @@ vm_phys_free_pages(vm_page_t m, int order) void vm_phys_free_contig(vm_page_t m, u_long npages) { + vm_page_t m_tmp; u_int n; int order; + for (m_tmp = m; m_tmp < &m[npages]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: start %p %td %u", + m, m_tmp - m, npages)); + /* * Avoid unnecessary coalescing by freeing the pages in the largest * possible power-of-two-sized subsets. @@ -714,6 +721,11 @@ vm_phys_free_contig(vm_page_t m, u_long npages) n = 1 << order; if (npages < n) break; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: xxx %p %td %u", + m, m_tmp - m, n)); vm_phys_free_pages(m, order); m += n; } @@ -721,6 +733,11 @@ vm_phys_free_contig(vm_page_t m, u_long npages) for (; npages > 0; npages -= n) { order = flsl(npages) - 1; n = 1 << order; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: yyy %p %td %u", + m, m_tmp - m, n)); vm_phys_free_pages(m, order); m += n; } --------------010506080105090907030104-- From owner-freebsd-arm@FreeBSD.ORG Sun Jun 8 21:18:21 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74145C1C for ; Sun, 8 Jun 2014 21:18:21 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31C0C29B6 for ; Sun, 8 Jun 2014 21:18:21 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 61F291FE026; Sun, 8 Jun 2014 23:18:19 +0200 (CEST) Message-ID: <5394D339.8090700@selasky.org> Date: Sun, 08 Jun 2014 23:18:49 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Scott, Brian" Subject: Re: Changes to dwc_otg USB controller code (stable/10) References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> <539009BB.5030906@selasky.org> <53900AC7.5070402@selasky.org> <53900BC2.3090701@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D251@WPEXCHMBSL1021.central.det.win> <5390B68B.5070802@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321E3BE@WPEXCHMBSL1021.central.det.win>, <5392BF67.9070306@selasky.org> <3FBCFE32-009B-4CFA-9403-33AF1C3344DB@det.nsw.edu.au> In-Reply-To: <3FBCFE32-009B-4CFA-9403-33AF1C3344DB@det.nsw.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 21:18:21 -0000 FYI: http://svnweb.freebsd.org/changeset/base/267242 Please test and report any issues. Thank you! --HPS From owner-freebsd-arm@FreeBSD.ORG Sun Jun 8 23:56:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84B73C69; Sun, 8 Jun 2014 23:56:13 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FE48250F; Sun, 8 Jun 2014 23:56:12 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s58NuBFe046714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jun 2014 16:56:12 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s58NuBUP046713; Sun, 8 Jun 2014 16:56:11 -0700 (PDT) (envelope-from jmg) Date: Sun, 8 Jun 2014 16:56:11 -0700 From: John-Mark Gurney To: Alan Cox Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140608235611.GP31367@funkthat.com> Mail-Followup-To: Alan Cox , "freebsd-arm@freebsd.org" , alc@freebsd.org References: <20140529171641.GA5246@ci0.org> <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> <53949D96.3060409@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53949D96.3060409@rice.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 08 Jun 2014 16:56:12 -0700 (PDT) Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 23:56:13 -0000 Alan Cox wrote this message on Sun, Jun 08, 2014 at 12:29 -0500: > On 06/07/2014 19:39, John-Mark Gurney wrote: > > Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 -0500: > >> On 06/01/2014 03:11, John-Mark Gurney wrote: > >>> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: > >>>> On 05/30/2014 01:32, John-Mark Gurney wrote: > >>>>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: > >>>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: > >>>>>>> On 29 May 2014 10:16, Olivier Houchard wrote: > >>>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > >>>>>>>>> Have you tested this on xscale hardware? > >>>>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot > >>>>>>>> again. > >>>>>>> Woo! What can I provide to help you do this? :-) > >>>>>>> > >>>>>>> (Drinks? Food? Donations?) > >>>>>>> > >>>>>>> > >>>>>> Drinks and food are always appreciated ;) > >>>>>> It almost boots for me now, except a few userland programs gets SIGSEGV or > >>>>>> SIGILL along the way, trying to figure out why. > >>>>> Thanks for fixing ddb... I'm getting panic messages again... bad > >>>>> news is that my panic is still around: > >>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired > >>>>> > >>>>> Though, interestingly, it looks like sparc64 has a similar panic: > >>>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 > >>>>> > >>>>> kib, Alan, any clue to why this is happening? Any suggestions as to > >>>>> help track it down? > >>>> I'm afraid not. The dump below shows a perfectly normal, in-use page. > >>>> If this page had actually been free prior to the vm_page_alloc() call, > >>>> then other fields, like dirty, would have been different. In other > >>>> words, this isn't just a problem with the wire count. > >>>> > >>>> What object is vm_page_alloc() being performed on? > >>> Is this enough? Or do you need more? > >>> > >>> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 > >>> KDB: enter: panic > >>> [ thread pid 781 tid 100051 ] > >>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > >>> db> show object/f 0xc1500b40 > >>> Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 > >>> sref=0, backing_object(0)=(0)+0x0 > >>> memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) > >>> ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) > >>> > >>> If you need more, let me know what/how to get it, and I will... > >>> > >> > >> Anyone who has seen the "wired page" panic, please try the attached > >> patch. It introduces some new KASSERT()s that may help me to narrow > >> down the problem. I haven't been able to trigger these KASSERT()s on > >> amd64, but the symptoms that you guys are reporting are consistent with > >> a bug that would trigger these KASSERT()s. > > Ok, it triggered the xxx one: > > Starting sendmail_msp_queue. > > panic: vm_phys_free_contig: xxx > > KDB: enter: panic > > [ thread pid 782 tid 100051 ] > > Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > > db> bt > > Tracing pid 782 tid 100051 td 0xc1470000 > > db_trace_self() at db_trace_self > > pc = 0xc0566ec8 lr = 0xc0566f54 (db_trace_thread+0x50) > > sp = 0xcd830850 fp = 0xc03db694 > > db_trace_thread() at db_trace_thread+0x50 > > pc = 0xc0566f54 lr = 0xc022cd14 (db_command_init+0x620) > > sp = 0xcd8308b0 fp = 0xc03db694 > > db_command_init() at db_command_init+0x620 > > pc = 0xc022cd14 lr = 0xc022c3ec (db_skip_to_eol+0x480) > > sp = 0xcd8308c8 fp = 0xc03db694 > > r4 = 0xc0683c30 r5 = 0x00000000 > > db_skip_to_eol() at db_skip_to_eol+0x480 > > pc = 0xc022c3ec lr = 0xc022c554 (db_command_loop+0x5c) > > sp = 0xcd830968 fp = 0xc03db694 > > r4 = 0xcd83097c r5 = 0xc0683efc > > r6 = 0x00000000 r7 = 0x00000000 > > r8 = 0x00000001 r10 = 0x600000d3 > > db_command_loop() at db_command_loop+0x5c > > pc = 0xc022c554 lr = 0xc022e99c (X_db_sym_numargs+0xec) > > sp = 0xcd830970 fp = 0xc03db694 > > X_db_sym_numargs() at X_db_sym_numargs+0xec > > pc = 0xc022e99c lr = 0xc03db8c4 (kdb_trap+0x94) > > sp = 0xcd830a88 fp = 0xc03db694 > > r4 = 0x00000000 > > kdb_trap() at kdb_trap+0x94 > > pc = 0xc03db8c4 lr = 0xc0578eb0 (undefinedinstruction+0x2c8) > > sp = 0xcd830aa8 fp = 0xc03db694 > > r4 = 0x00000000 r5 = 0x00000000 > > r6 = 0x00000000 r7 = 0xcd830b20 > > r8 = 0xe7ffffff r10 = 0xe7ffffff > > undefinedinstruction() at undefinedinstruction+0x2c8 > > pc = 0xc0578eb0 lr = 0xc0568a0c (exception_exit) > > sp = 0xcd830b20 fp = 0xc0613e70 > > r4 = 0xffffffff r5 = 0xffff1004 > > r6 = 0xc06d0ebc r7 = 0xcd830ba4 > > r8 = 0xc1470000 r9 = 0x00000013 > > r10 = 0x00000010 > > exception_exit() at exception_exit > > pc = 0xc0568a0c lr = 0xc03db68c (kdb_enter+0x38) > > sp = 0xcd830b70 fp = 0xc0613e70 > > r0 = 0x00000012 r1 = 0x60000013 > > r2 = 0xc06df2ac r3 = 0xc06d0ee8 > > r4 = 0xc05e5258 r5 = 0xc06155e8 > > r6 = 0xc06d0ebc r7 = 0xcd830ba4 > > r8 = 0xc1470000 r9 = 0x00000013 > > r10 = 0x00000010 r12 = 0xc05e2518 > > kdb_enter() at kdb_enter+0x44 > > pc = 0xc03db698 lr = 0xc03aa094 (kern_reboot+0x948) > > sp = 0xcd830b78 fp = 0xc0613e70 > > r4 = 0x00000100 > > kern_reboot() at kern_reboot+0x948 > > pc = 0xc03aa094 lr = 0xc03aa164 (kassert_panic+0x68) > > sp = 0xcd830b90 fp = 0xc0613e70 > > r4 = 0xc06155e8 r5 = 0xc07e74a0 > > r6 = 0xc07e6fa0 r7 = 0x00000004 > > r8 = 0x00000010 > > kassert_panic() at kassert_panic+0x68 > > pc = 0xc03aa164 lr = 0xc055a0a8 (vm_phys_free_contig+0x8c) > > sp = 0xcd830bb0 fp = 0xc0613e70 > > r0 = 0xc06155e8 r1 = 0xc07e6d20 > > r2 = 0xc06e6a70 r3 = 0x00000000 > > r4 = 0xc07e73b0 > > vm_phys_free_contig() at vm_phys_free_contig+0x8c > > pc = 0xc055a0a8 lr = 0xc055ca70 (vm_reserv_startup+0x4bc) > > sp = 0xcd830bd0 fp = 0xc0613e70 > > r4 = 0xc08fb2cc r5 = 0x00000008 > > r6 = 0x000000e8 r7 = 0xc08fb280 > > r8 = 0x00000005 r10 = 0x00000001 > > vm_reserv_startup() at vm_reserv_startup+0x4bc > > pc = 0xc055ca70 lr = 0xc055cb40 (vm_reserv_startup+0x58c) > > sp = 0xcd830be8 fp = 0xc0613e70 > > r4 = 0xc08fb280 r5 = 0x00000000 > > r6 = 0xc14b7280 r7 = 0x00000040 > > r8 = 0x00000000 > > vm_reserv_startup() at vm_reserv_startup+0x58c > > pc = 0xc055cb40 lr = 0xc055ce08 (vm_reserv_reclaim_inactive+0x34) > > sp = 0xcd830bf0 fp = 0xc0613e70 > > r4 = 0xc06e6550 > > vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 > > pc = 0xc055ce08 lr = 0xc0554cb8 (vm_page_alloc+0x280) > > sp = 0xcd830bf8 fp = 0xc0613e70 > > vm_page_alloc() at vm_page_alloc+0x280 > > pc = 0xc0554cb8 lr = 0xc0540eb0 (vm_fault_hold+0x60c) > > sp = 0xcd830c30 fp = 0xcd830dac > > r4 = 0xc14b7280 r5 = 0xc0618d00 > > r6 = 0xcd830eb0 r7 = 0xc1470000 > > r8 = 0xcd830e60 r9 = 0x00000000 > > r10 = 0x00000000 > > vm_fault_hold() at vm_fault_hold+0x60c > > pc = 0xc0540eb0 lr = 0xc05426b8 (vm_fault+0x44) > > sp = 0xcd830db0 fp = 0x00000002 > > r4 = 0xc14c8a0c r5 = 0xc0618d00 > > r6 = 0xcd830eb0 r7 = 0xc1470000 > > r8 = 0xcd830e60 r9 = 0x00000001 > > r10 = 0x00000000 > > vm_fault() at vm_fault+0x44 > > pc = 0xc05426b8 lr = 0xc05782d0 (data_abort_handler+0x35c) > > sp = 0xcd830dc0 fp = 0x00000002 > > data_abort_handler() at data_abort_handler+0x35c > > pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > > sp = 0xcd830dc0 fp = 0x00000002 > > data_abort_handler() at data_abort_handler+0x35c > > pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > > sp = 0xcd830e60 fp = 0x20c43000 > > r4 = 0xffffffff r5 = 0xffff1004 > > r6 = 0x00000000 r7 = 0x20443740 > > r8 = 0x0009b8e4 r9 = 0x00000001 > > r10 = 0x00000004 > > exception_exit() at exception_exit > > pc = 0xc0568a0c lr = 0x204140d0 (0x204140d0) > > sp = 0xcd830eb0 fp = 0x20c43000 > > r0 = 0x00000000 r1 = 0x20c4302c > > r2 = 0x00000004 r3 = 0x00000000 > > r4 = 0x20446190 r5 = 0x20c4302c > > r6 = 0x00000000 r7 = 0x20443740 > > r8 = 0x0009b8e4 r9 = 0x00000001 > > r10 = 0x00000004 r12 = 0x00000001 > > Unable to unwind into user mode > > > > Hope this helps, let me know if you need anything else... > > > > Please try the attached patch. It adds another KASSERT() loop. > > Depending on which KASSERT() fires, that will tell us whether to look > deeper at this function or its caller for the source of the problem. Ok, that panic is: panic: vm_phys_free_contig: start 0xc07e6d20 21 24 Let me know if you need any more info... oh, btw, the last %u needed to be %lu since it was a u_long, not an unsigned... Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Jun 9 01:19:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3579A96; Mon, 9 Jun 2014 01:19:57 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FF762A7C; Mon, 9 Jun 2014 01:19:56 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s591Ha8W031938; Sun, 8 Jun 2014 20:19:55 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp1.rice.edu with ESMTP id 1m6965v4rk-1; Sun, 08 Jun 2014 20:19:54 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 5FB38500135; Sun, 8 Jun 2014 20:19:54 -0500 (CDT) Message-ID: <53950BB9.3090808@rice.edu> Date: Sun, 08 Jun 2014 20:19:53 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" , alc@freebsd.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa References: <20140529171641.GA5246@ci0.org> <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> <53949D96.3060409@rice.edu> <20140608235611.GP31367@funkthat.com> In-Reply-To: <20140608235611.GP31367@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------080107080500080701010507" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.713890987064109 urlsuspect_oldscore=0.713890987064109 suspectscore=10 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.713890987064109 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406090018 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 01:19:57 -0000 This is a multi-part message in MIME format. --------------080107080500080701010507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/08/2014 18:56, John-Mark Gurney wrote: > Alan Cox wrote this message on Sun, Jun 08, 2014 at 12:29 -0500: >> On 06/07/2014 19:39, John-Mark Gurney wrote: >>> Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 -0500: >>>> On 06/01/2014 03:11, John-Mark Gurney wrote: >>>>> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: >>>>>> On 05/30/2014 01:32, John-Mark Gurney wrote: >>>>>>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: >>>>>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: >>>>>>>>> On 29 May 2014 10:16, Olivier Houchard wrote: >>>>>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: >>>>>>>>>>> Have you tested this on xscale hardware? >>>>>>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot >>>>>>>>>> again. >>>>>>>>> Woo! What can I provide to help you do this? :-) >>>>>>>>> >>>>>>>>> (Drinks? Food? Donations?) >>>>>>>>> >>>>>>>>> >>>>>>>> Drinks and food are always appreciated ;) >>>>>>>> It almost boots for me now, except a few userland programs gets SIGSEGV or >>>>>>>> SIGILL along the way, trying to figure out why. >>>>>>> Thanks for fixing ddb... I'm getting panic messages again... bad >>>>>>> news is that my panic is still around: >>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired >>>>>>> >>>>>>> Though, interestingly, it looks like sparc64 has a similar panic: >>>>>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 >>>>>>> >>>>>>> kib, Alan, any clue to why this is happening? Any suggestions as to >>>>>>> help track it down? >>>>>> I'm afraid not. The dump below shows a perfectly normal, in-use page. >>>>>> If this page had actually been free prior to the vm_page_alloc() call, >>>>>> then other fields, like dirty, would have been different. In other >>>>>> words, this isn't just a problem with the wire count. >>>>>> >>>>>> What object is vm_page_alloc() being performed on? >>>>> Is this enough? Or do you need more? >>>>> >>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 >>>>> KDB: enter: panic >>>>> [ thread pid 781 tid 100051 ] >>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! >>>>> db> show object/f 0xc1500b40 >>>>> Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 >>>>> sref=0, backing_object(0)=(0)+0x0 >>>>> memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) >>>>> ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) >>>>> >>>>> If you need more, let me know what/how to get it, and I will... >>>>> >>>> Anyone who has seen the "wired page" panic, please try the attached >>>> patch. It introduces some new KASSERT()s that may help me to narrow >>>> down the problem. I haven't been able to trigger these KASSERT()s on >>>> amd64, but the symptoms that you guys are reporting are consistent with >>>> a bug that would trigger these KASSERT()s. >>> Ok, it triggered the xxx one: >>> Starting sendmail_msp_queue. >>> panic: vm_phys_free_contig: xxx >>> KDB: enter: panic >>> [ thread pid 782 tid 100051 ] >>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! >>> db> bt >>> Tracing pid 782 tid 100051 td 0xc1470000 >>> db_trace_self() at db_trace_self >>> pc = 0xc0566ec8 lr = 0xc0566f54 (db_trace_thread+0x50) >>> sp = 0xcd830850 fp = 0xc03db694 >>> db_trace_thread() at db_trace_thread+0x50 >>> pc = 0xc0566f54 lr = 0xc022cd14 (db_command_init+0x620) >>> sp = 0xcd8308b0 fp = 0xc03db694 >>> db_command_init() at db_command_init+0x620 >>> pc = 0xc022cd14 lr = 0xc022c3ec (db_skip_to_eol+0x480) >>> sp = 0xcd8308c8 fp = 0xc03db694 >>> r4 = 0xc0683c30 r5 = 0x00000000 >>> db_skip_to_eol() at db_skip_to_eol+0x480 >>> pc = 0xc022c3ec lr = 0xc022c554 (db_command_loop+0x5c) >>> sp = 0xcd830968 fp = 0xc03db694 >>> r4 = 0xcd83097c r5 = 0xc0683efc >>> r6 = 0x00000000 r7 = 0x00000000 >>> r8 = 0x00000001 r10 = 0x600000d3 >>> db_command_loop() at db_command_loop+0x5c >>> pc = 0xc022c554 lr = 0xc022e99c (X_db_sym_numargs+0xec) >>> sp = 0xcd830970 fp = 0xc03db694 >>> X_db_sym_numargs() at X_db_sym_numargs+0xec >>> pc = 0xc022e99c lr = 0xc03db8c4 (kdb_trap+0x94) >>> sp = 0xcd830a88 fp = 0xc03db694 >>> r4 = 0x00000000 >>> kdb_trap() at kdb_trap+0x94 >>> pc = 0xc03db8c4 lr = 0xc0578eb0 (undefinedinstruction+0x2c8) >>> sp = 0xcd830aa8 fp = 0xc03db694 >>> r4 = 0x00000000 r5 = 0x00000000 >>> r6 = 0x00000000 r7 = 0xcd830b20 >>> r8 = 0xe7ffffff r10 = 0xe7ffffff >>> undefinedinstruction() at undefinedinstruction+0x2c8 >>> pc = 0xc0578eb0 lr = 0xc0568a0c (exception_exit) >>> sp = 0xcd830b20 fp = 0xc0613e70 >>> r4 = 0xffffffff r5 = 0xffff1004 >>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 >>> r8 = 0xc1470000 r9 = 0x00000013 >>> r10 = 0x00000010 >>> exception_exit() at exception_exit >>> pc = 0xc0568a0c lr = 0xc03db68c (kdb_enter+0x38) >>> sp = 0xcd830b70 fp = 0xc0613e70 >>> r0 = 0x00000012 r1 = 0x60000013 >>> r2 = 0xc06df2ac r3 = 0xc06d0ee8 >>> r4 = 0xc05e5258 r5 = 0xc06155e8 >>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 >>> r8 = 0xc1470000 r9 = 0x00000013 >>> r10 = 0x00000010 r12 = 0xc05e2518 >>> kdb_enter() at kdb_enter+0x44 >>> pc = 0xc03db698 lr = 0xc03aa094 (kern_reboot+0x948) >>> sp = 0xcd830b78 fp = 0xc0613e70 >>> r4 = 0x00000100 >>> kern_reboot() at kern_reboot+0x948 >>> pc = 0xc03aa094 lr = 0xc03aa164 (kassert_panic+0x68) >>> sp = 0xcd830b90 fp = 0xc0613e70 >>> r4 = 0xc06155e8 r5 = 0xc07e74a0 >>> r6 = 0xc07e6fa0 r7 = 0x00000004 >>> r8 = 0x00000010 >>> kassert_panic() at kassert_panic+0x68 >>> pc = 0xc03aa164 lr = 0xc055a0a8 (vm_phys_free_contig+0x8c) >>> sp = 0xcd830bb0 fp = 0xc0613e70 >>> r0 = 0xc06155e8 r1 = 0xc07e6d20 >>> r2 = 0xc06e6a70 r3 = 0x00000000 >>> r4 = 0xc07e73b0 >>> vm_phys_free_contig() at vm_phys_free_contig+0x8c >>> pc = 0xc055a0a8 lr = 0xc055ca70 (vm_reserv_startup+0x4bc) >>> sp = 0xcd830bd0 fp = 0xc0613e70 >>> r4 = 0xc08fb2cc r5 = 0x00000008 >>> r6 = 0x000000e8 r7 = 0xc08fb280 >>> r8 = 0x00000005 r10 = 0x00000001 >>> vm_reserv_startup() at vm_reserv_startup+0x4bc >>> pc = 0xc055ca70 lr = 0xc055cb40 (vm_reserv_startup+0x58c) >>> sp = 0xcd830be8 fp = 0xc0613e70 >>> r4 = 0xc08fb280 r5 = 0x00000000 >>> r6 = 0xc14b7280 r7 = 0x00000040 >>> r8 = 0x00000000 >>> vm_reserv_startup() at vm_reserv_startup+0x58c >>> pc = 0xc055cb40 lr = 0xc055ce08 (vm_reserv_reclaim_inactive+0x34) >>> sp = 0xcd830bf0 fp = 0xc0613e70 >>> r4 = 0xc06e6550 >>> vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 >>> pc = 0xc055ce08 lr = 0xc0554cb8 (vm_page_alloc+0x280) >>> sp = 0xcd830bf8 fp = 0xc0613e70 >>> vm_page_alloc() at vm_page_alloc+0x280 >>> pc = 0xc0554cb8 lr = 0xc0540eb0 (vm_fault_hold+0x60c) >>> sp = 0xcd830c30 fp = 0xcd830dac >>> r4 = 0xc14b7280 r5 = 0xc0618d00 >>> r6 = 0xcd830eb0 r7 = 0xc1470000 >>> r8 = 0xcd830e60 r9 = 0x00000000 >>> r10 = 0x00000000 >>> vm_fault_hold() at vm_fault_hold+0x60c >>> pc = 0xc0540eb0 lr = 0xc05426b8 (vm_fault+0x44) >>> sp = 0xcd830db0 fp = 0x00000002 >>> r4 = 0xc14c8a0c r5 = 0xc0618d00 >>> r6 = 0xcd830eb0 r7 = 0xc1470000 >>> r8 = 0xcd830e60 r9 = 0x00000001 >>> r10 = 0x00000000 >>> vm_fault() at vm_fault+0x44 >>> pc = 0xc05426b8 lr = 0xc05782d0 (data_abort_handler+0x35c) >>> sp = 0xcd830dc0 fp = 0x00000002 >>> data_abort_handler() at data_abort_handler+0x35c >>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) >>> sp = 0xcd830dc0 fp = 0x00000002 >>> data_abort_handler() at data_abort_handler+0x35c >>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) >>> sp = 0xcd830e60 fp = 0x20c43000 >>> r4 = 0xffffffff r5 = 0xffff1004 >>> r6 = 0x00000000 r7 = 0x20443740 >>> r8 = 0x0009b8e4 r9 = 0x00000001 >>> r10 = 0x00000004 >>> exception_exit() at exception_exit >>> pc = 0xc0568a0c lr = 0x204140d0 (0x204140d0) >>> sp = 0xcd830eb0 fp = 0x20c43000 >>> r0 = 0x00000000 r1 = 0x20c4302c >>> r2 = 0x00000004 r3 = 0x00000000 >>> r4 = 0x20446190 r5 = 0x20c4302c >>> r6 = 0x00000000 r7 = 0x20443740 >>> r8 = 0x0009b8e4 r9 = 0x00000001 >>> r10 = 0x00000004 r12 = 0x00000001 >>> Unable to unwind into user mode >>> >>> Hope this helps, let me know if you need anything else... >>> >> Please try the attached patch. It adds another KASSERT() loop. >> >> Depending on which KASSERT() fires, that will tell us whether to look >> deeper at this function or its caller for the source of the problem. > Ok, that panic is: > panic: vm_phys_free_contig: start 0xc07e6d20 21 24 > > Let me know if you need any more info... oh, btw, the last %u needed > to be %lu since it was a u_long, not an unsigned... > Ok. Here is the next debug patch. --------------080107080500080701010507 Content-Type: text/plain; charset=ISO-8859-15; name="arm_debug3.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_debug3.patch" Index: vm/vm_phys.c =================================================================== --- vm/vm_phys.c (revision 267209) +++ vm/vm_phys.c (working copy) @@ -693,9 +693,16 @@ vm_phys_free_pages(vm_page_t m, int order) void vm_phys_free_contig(vm_page_t m, u_long npages) { + vm_page_t m_tmp; u_int n; int order; + for (m_tmp = m; m_tmp < &m[npages]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: start %p %td %lu", + m, m_tmp - m, npages)); + /* * Avoid unnecessary coalescing by freeing the pages in the largest * possible power-of-two-sized subsets. @@ -714,6 +721,11 @@ vm_phys_free_contig(vm_page_t m, u_long npages) n = 1 << order; if (npages < n) break; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: xxx %p %td %u", + m, m_tmp - m, n)); vm_phys_free_pages(m, order); m += n; } @@ -721,6 +733,11 @@ vm_phys_free_contig(vm_page_t m, u_long npages) for (; npages > 0; npages -= n) { order = flsl(npages) - 1; n = 1 << order; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: yyy %p %td %u", + m, m_tmp - m, n)); vm_phys_free_pages(m, order); m += n; } Index: vm/vm_reserv.c =================================================================== --- vm/vm_reserv.c (revision 267213) +++ vm/vm_reserv.c (working copy) @@ -646,7 +646,7 @@ found: static void vm_reserv_break(vm_reserv_t rv, vm_page_t m) { - int begin_zeroes, hi, i, lo; + int begin_zeroes, hi, i, lo, x; mtx_assert(&vm_page_queue_free_mtx, MA_OWNED); KASSERT(rv->object != NULL, @@ -703,6 +703,11 @@ vm_reserv_break(vm_reserv_t rv, vm_page_t m) if (i != NPOPMAP) /* Convert from ffsl() to ordinary bit numbering. */ hi--; + for (x = begin_zeroes; x < NBPOPMAP * i + hi - begin_zeroes; + x++) { + KASSERT(isclr(rv->popmap, x), + ("vm_reserv_break: reserv %p popmap[%d]", rv, x)); + } vm_phys_free_contig(&rv->pages[begin_zeroes], NBPOPMAP * i + hi - begin_zeroes); } while (i < NPOPMAP); --------------080107080500080701010507-- From owner-freebsd-arm@FreeBSD.ORG Mon Jun 9 04:22:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 734C3E14; Mon, 9 Jun 2014 04:22:09 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D5C02874; Mon, 9 Jun 2014 04:22:08 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s594M7FB050126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jun 2014 21:22:07 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s594M77U050125; Sun, 8 Jun 2014 21:22:07 -0700 (PDT) (envelope-from jmg) Date: Sun, 8 Jun 2014 21:22:07 -0700 From: John-Mark Gurney To: Alan Cox Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140609042206.GQ31367@funkthat.com> Mail-Followup-To: Alan Cox , "freebsd-arm@freebsd.org" , alc@freebsd.org References: <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> <53949D96.3060409@rice.edu> <20140608235611.GP31367@funkthat.com> <53950BB9.3090808@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53950BB9.3090808@rice.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 08 Jun 2014 21:22:07 -0700 (PDT) Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 04:22:09 -0000 Alan Cox wrote this message on Sun, Jun 08, 2014 at 20:19 -0500: > On 06/08/2014 18:56, John-Mark Gurney wrote: > > Alan Cox wrote this message on Sun, Jun 08, 2014 at 12:29 -0500: > >> On 06/07/2014 19:39, John-Mark Gurney wrote: > >>> Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 -0500: > >>>> On 06/01/2014 03:11, John-Mark Gurney wrote: > >>>>> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: > >>>>>> On 05/30/2014 01:32, John-Mark Gurney wrote: > >>>>>>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: > >>>>>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: > >>>>>>>>> On 29 May 2014 10:16, Olivier Houchard wrote: > >>>>>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > >>>>>>>>>>> Have you tested this on xscale hardware? > >>>>>>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot > >>>>>>>>>> again. > >>>>>>>>> Woo! What can I provide to help you do this? :-) > >>>>>>>>> > >>>>>>>>> (Drinks? Food? Donations?) > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Drinks and food are always appreciated ;) > >>>>>>>> It almost boots for me now, except a few userland programs gets SIGSEGV or > >>>>>>>> SIGILL along the way, trying to figure out why. > >>>>>>> Thanks for fixing ddb... I'm getting panic messages again... bad > >>>>>>> news is that my panic is still around: > >>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired > >>>>>>> > >>>>>>> Though, interestingly, it looks like sparc64 has a similar panic: > >>>>>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 > >>>>>>> > >>>>>>> kib, Alan, any clue to why this is happening? Any suggestions as to > >>>>>>> help track it down? > >>>>>> I'm afraid not. The dump below shows a perfectly normal, in-use page. > >>>>>> If this page had actually been free prior to the vm_page_alloc() call, > >>>>>> then other fields, like dirty, would have been different. In other > >>>>>> words, this isn't just a problem with the wire count. > >>>>>> > >>>>>> What object is vm_page_alloc() being performed on? > >>>>> Is this enough? Or do you need more? > >>>>> > >>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 > >>>>> KDB: enter: panic > >>>>> [ thread pid 781 tid 100051 ] > >>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > >>>>> db> show object/f 0xc1500b40 > >>>>> Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 > >>>>> sref=0, backing_object(0)=(0)+0x0 > >>>>> memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) > >>>>> ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) > >>>>> > >>>>> If you need more, let me know what/how to get it, and I will... > >>>>> > >>>> Anyone who has seen the "wired page" panic, please try the attached > >>>> patch. It introduces some new KASSERT()s that may help me to narrow > >>>> down the problem. I haven't been able to trigger these KASSERT()s on > >>>> amd64, but the symptoms that you guys are reporting are consistent with > >>>> a bug that would trigger these KASSERT()s. > >>> Ok, it triggered the xxx one: > >>> Starting sendmail_msp_queue. > >>> panic: vm_phys_free_contig: xxx > >>> KDB: enter: panic > >>> [ thread pid 782 tid 100051 ] > >>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > >>> db> bt > >>> Tracing pid 782 tid 100051 td 0xc1470000 > >>> db_trace_self() at db_trace_self > >>> pc = 0xc0566ec8 lr = 0xc0566f54 (db_trace_thread+0x50) > >>> sp = 0xcd830850 fp = 0xc03db694 > >>> db_trace_thread() at db_trace_thread+0x50 > >>> pc = 0xc0566f54 lr = 0xc022cd14 (db_command_init+0x620) > >>> sp = 0xcd8308b0 fp = 0xc03db694 > >>> db_command_init() at db_command_init+0x620 > >>> pc = 0xc022cd14 lr = 0xc022c3ec (db_skip_to_eol+0x480) > >>> sp = 0xcd8308c8 fp = 0xc03db694 > >>> r4 = 0xc0683c30 r5 = 0x00000000 > >>> db_skip_to_eol() at db_skip_to_eol+0x480 > >>> pc = 0xc022c3ec lr = 0xc022c554 (db_command_loop+0x5c) > >>> sp = 0xcd830968 fp = 0xc03db694 > >>> r4 = 0xcd83097c r5 = 0xc0683efc > >>> r6 = 0x00000000 r7 = 0x00000000 > >>> r8 = 0x00000001 r10 = 0x600000d3 > >>> db_command_loop() at db_command_loop+0x5c > >>> pc = 0xc022c554 lr = 0xc022e99c (X_db_sym_numargs+0xec) > >>> sp = 0xcd830970 fp = 0xc03db694 > >>> X_db_sym_numargs() at X_db_sym_numargs+0xec > >>> pc = 0xc022e99c lr = 0xc03db8c4 (kdb_trap+0x94) > >>> sp = 0xcd830a88 fp = 0xc03db694 > >>> r4 = 0x00000000 > >>> kdb_trap() at kdb_trap+0x94 > >>> pc = 0xc03db8c4 lr = 0xc0578eb0 (undefinedinstruction+0x2c8) > >>> sp = 0xcd830aa8 fp = 0xc03db694 > >>> r4 = 0x00000000 r5 = 0x00000000 > >>> r6 = 0x00000000 r7 = 0xcd830b20 > >>> r8 = 0xe7ffffff r10 = 0xe7ffffff > >>> undefinedinstruction() at undefinedinstruction+0x2c8 > >>> pc = 0xc0578eb0 lr = 0xc0568a0c (exception_exit) > >>> sp = 0xcd830b20 fp = 0xc0613e70 > >>> r4 = 0xffffffff r5 = 0xffff1004 > >>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 > >>> r8 = 0xc1470000 r9 = 0x00000013 > >>> r10 = 0x00000010 > >>> exception_exit() at exception_exit > >>> pc = 0xc0568a0c lr = 0xc03db68c (kdb_enter+0x38) > >>> sp = 0xcd830b70 fp = 0xc0613e70 > >>> r0 = 0x00000012 r1 = 0x60000013 > >>> r2 = 0xc06df2ac r3 = 0xc06d0ee8 > >>> r4 = 0xc05e5258 r5 = 0xc06155e8 > >>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 > >>> r8 = 0xc1470000 r9 = 0x00000013 > >>> r10 = 0x00000010 r12 = 0xc05e2518 > >>> kdb_enter() at kdb_enter+0x44 > >>> pc = 0xc03db698 lr = 0xc03aa094 (kern_reboot+0x948) > >>> sp = 0xcd830b78 fp = 0xc0613e70 > >>> r4 = 0x00000100 > >>> kern_reboot() at kern_reboot+0x948 > >>> pc = 0xc03aa094 lr = 0xc03aa164 (kassert_panic+0x68) > >>> sp = 0xcd830b90 fp = 0xc0613e70 > >>> r4 = 0xc06155e8 r5 = 0xc07e74a0 > >>> r6 = 0xc07e6fa0 r7 = 0x00000004 > >>> r8 = 0x00000010 > >>> kassert_panic() at kassert_panic+0x68 > >>> pc = 0xc03aa164 lr = 0xc055a0a8 (vm_phys_free_contig+0x8c) > >>> sp = 0xcd830bb0 fp = 0xc0613e70 > >>> r0 = 0xc06155e8 r1 = 0xc07e6d20 > >>> r2 = 0xc06e6a70 r3 = 0x00000000 > >>> r4 = 0xc07e73b0 > >>> vm_phys_free_contig() at vm_phys_free_contig+0x8c > >>> pc = 0xc055a0a8 lr = 0xc055ca70 (vm_reserv_startup+0x4bc) > >>> sp = 0xcd830bd0 fp = 0xc0613e70 > >>> r4 = 0xc08fb2cc r5 = 0x00000008 > >>> r6 = 0x000000e8 r7 = 0xc08fb280 > >>> r8 = 0x00000005 r10 = 0x00000001 > >>> vm_reserv_startup() at vm_reserv_startup+0x4bc > >>> pc = 0xc055ca70 lr = 0xc055cb40 (vm_reserv_startup+0x58c) > >>> sp = 0xcd830be8 fp = 0xc0613e70 > >>> r4 = 0xc08fb280 r5 = 0x00000000 > >>> r6 = 0xc14b7280 r7 = 0x00000040 > >>> r8 = 0x00000000 > >>> vm_reserv_startup() at vm_reserv_startup+0x58c > >>> pc = 0xc055cb40 lr = 0xc055ce08 (vm_reserv_reclaim_inactive+0x34) > >>> sp = 0xcd830bf0 fp = 0xc0613e70 > >>> r4 = 0xc06e6550 > >>> vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 > >>> pc = 0xc055ce08 lr = 0xc0554cb8 (vm_page_alloc+0x280) > >>> sp = 0xcd830bf8 fp = 0xc0613e70 > >>> vm_page_alloc() at vm_page_alloc+0x280 > >>> pc = 0xc0554cb8 lr = 0xc0540eb0 (vm_fault_hold+0x60c) > >>> sp = 0xcd830c30 fp = 0xcd830dac > >>> r4 = 0xc14b7280 r5 = 0xc0618d00 > >>> r6 = 0xcd830eb0 r7 = 0xc1470000 > >>> r8 = 0xcd830e60 r9 = 0x00000000 > >>> r10 = 0x00000000 > >>> vm_fault_hold() at vm_fault_hold+0x60c > >>> pc = 0xc0540eb0 lr = 0xc05426b8 (vm_fault+0x44) > >>> sp = 0xcd830db0 fp = 0x00000002 > >>> r4 = 0xc14c8a0c r5 = 0xc0618d00 > >>> r6 = 0xcd830eb0 r7 = 0xc1470000 > >>> r8 = 0xcd830e60 r9 = 0x00000001 > >>> r10 = 0x00000000 > >>> vm_fault() at vm_fault+0x44 > >>> pc = 0xc05426b8 lr = 0xc05782d0 (data_abort_handler+0x35c) > >>> sp = 0xcd830dc0 fp = 0x00000002 > >>> data_abort_handler() at data_abort_handler+0x35c > >>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > >>> sp = 0xcd830dc0 fp = 0x00000002 > >>> data_abort_handler() at data_abort_handler+0x35c > >>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > >>> sp = 0xcd830e60 fp = 0x20c43000 > >>> r4 = 0xffffffff r5 = 0xffff1004 > >>> r6 = 0x00000000 r7 = 0x20443740 > >>> r8 = 0x0009b8e4 r9 = 0x00000001 > >>> r10 = 0x00000004 > >>> exception_exit() at exception_exit > >>> pc = 0xc0568a0c lr = 0x204140d0 (0x204140d0) > >>> sp = 0xcd830eb0 fp = 0x20c43000 > >>> r0 = 0x00000000 r1 = 0x20c4302c > >>> r2 = 0x00000004 r3 = 0x00000000 > >>> r4 = 0x20446190 r5 = 0x20c4302c > >>> r6 = 0x00000000 r7 = 0x20443740 > >>> r8 = 0x0009b8e4 r9 = 0x00000001 > >>> r10 = 0x00000004 r12 = 0x00000001 > >>> Unable to unwind into user mode > >>> > >>> Hope this helps, let me know if you need anything else... > >>> > >> Please try the attached patch. It adds another KASSERT() loop. > >> > >> Depending on which KASSERT() fires, that will tell us whether to look > >> deeper at this function or its caller for the source of the problem. > > Ok, that panic is: > > panic: vm_phys_free_contig: start 0xc07e6d20 21 24 > > > > Let me know if you need any more info... oh, btw, the last %u needed > > to be %lu since it was a u_long, not an unsigned... > > > > Ok. Here is the next debug patch. so, it's crashing in the same place: panic: vm_phys_free_contig: start 0xc07e6d20 21 24 so, I commented out this KASSERT, and now it panics with: panic: vm_phys_free_contig: xxx 0xc07e6fa0 13 16 so I commented out this KASSERT too, and it panics back w/ the original panic.. So it didn't hit the new KASSERT in vm_reserv_break... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Jun 9 15:30:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5620D6F; Mon, 9 Jun 2014 15:30:30 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0CBB2319; Mon, 9 Jun 2014 15:30:29 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s59FRWLR007788; Mon, 9 Jun 2014 10:30:28 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp1.rice.edu with ESMTP id 1m6965vaxk-1; Mon, 09 Jun 2014 10:30:27 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 47D4E460148; Mon, 9 Jun 2014 10:30:27 -0500 (CDT) Message-ID: <5395D312.5000302@rice.edu> Date: Mon, 09 Jun 2014 10:30:26 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" , alc@freebsd.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa References: <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> <53949D96.3060409@rice.edu> <20140608235611.GP31367@funkthat.com> <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> In-Reply-To: <20140609042206.GQ31367@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------030200060505090800030104" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=8.36997138264906e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.714301145562988 urlsuspect_oldscore=0.714301145562988 suspectscore=10 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.714301145562988 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406090201 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:30:31 -0000 This is a multi-part message in MIME format. --------------030200060505090800030104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/08/2014 23:22, John-Mark Gurney wrote: > Alan Cox wrote this message on Sun, Jun 08, 2014 at 20:19 -0500: >> On 06/08/2014 18:56, John-Mark Gurney wrote: >>> Alan Cox wrote this message on Sun, Jun 08, 2014 at 12:29 -0500: >>>> On 06/07/2014 19:39, John-Mark Gurney wrote: >>>>> Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 -0500: >>>>>> On 06/01/2014 03:11, John-Mark Gurney wrote: >>>>>>> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: >>>>>>>> On 05/30/2014 01:32, John-Mark Gurney wrote: >>>>>>>>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: >>>>>>>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: >>>>>>>>>>> On 29 May 2014 10:16, Olivier Houchard wrote: >>>>>>>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: >>>>>>>>>>>>> Have you tested this on xscale hardware? >>>>>>>>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot >>>>>>>>>>>> again. >>>>>>>>>>> Woo! What can I provide to help you do this? :-) >>>>>>>>>>> >>>>>>>>>>> (Drinks? Food? Donations?) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Drinks and food are always appreciated ;) >>>>>>>>>> It almost boots for me now, except a few userland programs gets SIGSEGV or >>>>>>>>>> SIGILL along the way, trying to figure out why. >>>>>>>>> Thanks for fixing ddb... I'm getting panic messages again... bad >>>>>>>>> news is that my panic is still around: >>>>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired >>>>>>>>> >>>>>>>>> Though, interestingly, it looks like sparc64 has a similar panic: >>>>>>>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 >>>>>>>>> >>>>>>>>> kib, Alan, any clue to why this is happening? Any suggestions as to >>>>>>>>> help track it down? >>>>>>>> I'm afraid not. The dump below shows a perfectly normal, in-use page. >>>>>>>> If this page had actually been free prior to the vm_page_alloc() call, >>>>>>>> then other fields, like dirty, would have been different. In other >>>>>>>> words, this isn't just a problem with the wire count. >>>>>>>> >>>>>>>> What object is vm_page_alloc() being performed on? >>>>>>> Is this enough? Or do you need more? >>>>>>> >>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 >>>>>>> KDB: enter: panic >>>>>>> [ thread pid 781 tid 100051 ] >>>>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! >>>>>>> db> show object/f 0xc1500b40 >>>>>>> Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 >>>>>>> sref=0, backing_object(0)=(0)+0x0 >>>>>>> memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) >>>>>>> ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) >>>>>>> >>>>>>> If you need more, let me know what/how to get it, and I will... >>>>>>> >>>>>> Anyone who has seen the "wired page" panic, please try the attached >>>>>> patch. It introduces some new KASSERT()s that may help me to narrow >>>>>> down the problem. I haven't been able to trigger these KASSERT()s on >>>>>> amd64, but the symptoms that you guys are reporting are consistent with >>>>>> a bug that would trigger these KASSERT()s. >>>>> Ok, it triggered the xxx one: >>>>> Starting sendmail_msp_queue. >>>>> panic: vm_phys_free_contig: xxx >>>>> KDB: enter: panic >>>>> [ thread pid 782 tid 100051 ] >>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! >>>>> db> bt >>>>> Tracing pid 782 tid 100051 td 0xc1470000 >>>>> db_trace_self() at db_trace_self >>>>> pc = 0xc0566ec8 lr = 0xc0566f54 (db_trace_thread+0x50) >>>>> sp = 0xcd830850 fp = 0xc03db694 >>>>> db_trace_thread() at db_trace_thread+0x50 >>>>> pc = 0xc0566f54 lr = 0xc022cd14 (db_command_init+0x620) >>>>> sp = 0xcd8308b0 fp = 0xc03db694 >>>>> db_command_init() at db_command_init+0x620 >>>>> pc = 0xc022cd14 lr = 0xc022c3ec (db_skip_to_eol+0x480) >>>>> sp = 0xcd8308c8 fp = 0xc03db694 >>>>> r4 = 0xc0683c30 r5 = 0x00000000 >>>>> db_skip_to_eol() at db_skip_to_eol+0x480 >>>>> pc = 0xc022c3ec lr = 0xc022c554 (db_command_loop+0x5c) >>>>> sp = 0xcd830968 fp = 0xc03db694 >>>>> r4 = 0xcd83097c r5 = 0xc0683efc >>>>> r6 = 0x00000000 r7 = 0x00000000 >>>>> r8 = 0x00000001 r10 = 0x600000d3 >>>>> db_command_loop() at db_command_loop+0x5c >>>>> pc = 0xc022c554 lr = 0xc022e99c (X_db_sym_numargs+0xec) >>>>> sp = 0xcd830970 fp = 0xc03db694 >>>>> X_db_sym_numargs() at X_db_sym_numargs+0xec >>>>> pc = 0xc022e99c lr = 0xc03db8c4 (kdb_trap+0x94) >>>>> sp = 0xcd830a88 fp = 0xc03db694 >>>>> r4 = 0x00000000 >>>>> kdb_trap() at kdb_trap+0x94 >>>>> pc = 0xc03db8c4 lr = 0xc0578eb0 (undefinedinstruction+0x2c8) >>>>> sp = 0xcd830aa8 fp = 0xc03db694 >>>>> r4 = 0x00000000 r5 = 0x00000000 >>>>> r6 = 0x00000000 r7 = 0xcd830b20 >>>>> r8 = 0xe7ffffff r10 = 0xe7ffffff >>>>> undefinedinstruction() at undefinedinstruction+0x2c8 >>>>> pc = 0xc0578eb0 lr = 0xc0568a0c (exception_exit) >>>>> sp = 0xcd830b20 fp = 0xc0613e70 >>>>> r4 = 0xffffffff r5 = 0xffff1004 >>>>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 >>>>> r8 = 0xc1470000 r9 = 0x00000013 >>>>> r10 = 0x00000010 >>>>> exception_exit() at exception_exit >>>>> pc = 0xc0568a0c lr = 0xc03db68c (kdb_enter+0x38) >>>>> sp = 0xcd830b70 fp = 0xc0613e70 >>>>> r0 = 0x00000012 r1 = 0x60000013 >>>>> r2 = 0xc06df2ac r3 = 0xc06d0ee8 >>>>> r4 = 0xc05e5258 r5 = 0xc06155e8 >>>>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 >>>>> r8 = 0xc1470000 r9 = 0x00000013 >>>>> r10 = 0x00000010 r12 = 0xc05e2518 >>>>> kdb_enter() at kdb_enter+0x44 >>>>> pc = 0xc03db698 lr = 0xc03aa094 (kern_reboot+0x948) >>>>> sp = 0xcd830b78 fp = 0xc0613e70 >>>>> r4 = 0x00000100 >>>>> kern_reboot() at kern_reboot+0x948 >>>>> pc = 0xc03aa094 lr = 0xc03aa164 (kassert_panic+0x68) >>>>> sp = 0xcd830b90 fp = 0xc0613e70 >>>>> r4 = 0xc06155e8 r5 = 0xc07e74a0 >>>>> r6 = 0xc07e6fa0 r7 = 0x00000004 >>>>> r8 = 0x00000010 >>>>> kassert_panic() at kassert_panic+0x68 >>>>> pc = 0xc03aa164 lr = 0xc055a0a8 (vm_phys_free_contig+0x8c) >>>>> sp = 0xcd830bb0 fp = 0xc0613e70 >>>>> r0 = 0xc06155e8 r1 = 0xc07e6d20 >>>>> r2 = 0xc06e6a70 r3 = 0x00000000 >>>>> r4 = 0xc07e73b0 >>>>> vm_phys_free_contig() at vm_phys_free_contig+0x8c >>>>> pc = 0xc055a0a8 lr = 0xc055ca70 (vm_reserv_startup+0x4bc) >>>>> sp = 0xcd830bd0 fp = 0xc0613e70 >>>>> r4 = 0xc08fb2cc r5 = 0x00000008 >>>>> r6 = 0x000000e8 r7 = 0xc08fb280 >>>>> r8 = 0x00000005 r10 = 0x00000001 >>>>> vm_reserv_startup() at vm_reserv_startup+0x4bc >>>>> pc = 0xc055ca70 lr = 0xc055cb40 (vm_reserv_startup+0x58c) >>>>> sp = 0xcd830be8 fp = 0xc0613e70 >>>>> r4 = 0xc08fb280 r5 = 0x00000000 >>>>> r6 = 0xc14b7280 r7 = 0x00000040 >>>>> r8 = 0x00000000 >>>>> vm_reserv_startup() at vm_reserv_startup+0x58c >>>>> pc = 0xc055cb40 lr = 0xc055ce08 (vm_reserv_reclaim_inactive+0x34) >>>>> sp = 0xcd830bf0 fp = 0xc0613e70 >>>>> r4 = 0xc06e6550 >>>>> vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 >>>>> pc = 0xc055ce08 lr = 0xc0554cb8 (vm_page_alloc+0x280) >>>>> sp = 0xcd830bf8 fp = 0xc0613e70 >>>>> vm_page_alloc() at vm_page_alloc+0x280 >>>>> pc = 0xc0554cb8 lr = 0xc0540eb0 (vm_fault_hold+0x60c) >>>>> sp = 0xcd830c30 fp = 0xcd830dac >>>>> r4 = 0xc14b7280 r5 = 0xc0618d00 >>>>> r6 = 0xcd830eb0 r7 = 0xc1470000 >>>>> r8 = 0xcd830e60 r9 = 0x00000000 >>>>> r10 = 0x00000000 >>>>> vm_fault_hold() at vm_fault_hold+0x60c >>>>> pc = 0xc0540eb0 lr = 0xc05426b8 (vm_fault+0x44) >>>>> sp = 0xcd830db0 fp = 0x00000002 >>>>> r4 = 0xc14c8a0c r5 = 0xc0618d00 >>>>> r6 = 0xcd830eb0 r7 = 0xc1470000 >>>>> r8 = 0xcd830e60 r9 = 0x00000001 >>>>> r10 = 0x00000000 >>>>> vm_fault() at vm_fault+0x44 >>>>> pc = 0xc05426b8 lr = 0xc05782d0 (data_abort_handler+0x35c) >>>>> sp = 0xcd830dc0 fp = 0x00000002 >>>>> data_abort_handler() at data_abort_handler+0x35c >>>>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) >>>>> sp = 0xcd830dc0 fp = 0x00000002 >>>>> data_abort_handler() at data_abort_handler+0x35c >>>>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) >>>>> sp = 0xcd830e60 fp = 0x20c43000 >>>>> r4 = 0xffffffff r5 = 0xffff1004 >>>>> r6 = 0x00000000 r7 = 0x20443740 >>>>> r8 = 0x0009b8e4 r9 = 0x00000001 >>>>> r10 = 0x00000004 >>>>> exception_exit() at exception_exit >>>>> pc = 0xc0568a0c lr = 0x204140d0 (0x204140d0) >>>>> sp = 0xcd830eb0 fp = 0x20c43000 >>>>> r0 = 0x00000000 r1 = 0x20c4302c >>>>> r2 = 0x00000004 r3 = 0x00000000 >>>>> r4 = 0x20446190 r5 = 0x20c4302c >>>>> r6 = 0x00000000 r7 = 0x20443740 >>>>> r8 = 0x0009b8e4 r9 = 0x00000001 >>>>> r10 = 0x00000004 r12 = 0x00000001 >>>>> Unable to unwind into user mode >>>>> >>>>> Hope this helps, let me know if you need anything else... >>>>> >>>> Please try the attached patch. It adds another KASSERT() loop. >>>> >>>> Depending on which KASSERT() fires, that will tell us whether to look >>>> deeper at this function or its caller for the source of the problem. >>> Ok, that panic is: >>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 >>> >>> Let me know if you need any more info... oh, btw, the last %u needed >>> to be %lu since it was a u_long, not an unsigned... >>> >> Ok. Here is the next debug patch. > so, it's crashing in the same place: > panic: vm_phys_free_contig: start 0xc07e6d20 21 24 > > so, I commented out this KASSERT, and now it panics with: > panic: vm_phys_free_contig: xxx 0xc07e6fa0 13 16 > > so I commented out this KASSERT too, and it panics back w/ the original > panic.. So it didn't hit the new KASSERT in vm_reserv_break... > Next patch...It should panic in vm_reserv_break this time and tell me if the reservation being broken belongs to the same object as the inuse page that is being inappropriately freed. --------------030200060505090800030104 Content-Type: text/plain; charset=ISO-8859-15; name="arm_debug4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_debug4.patch" Index: vm/vm_phys.c =================================================================== --- vm/vm_phys.c (revision 267209) +++ vm/vm_phys.c (working copy) @@ -693,9 +693,16 @@ vm_phys_free_pages(vm_page_t m, int order) void vm_phys_free_contig(vm_page_t m, u_long npages) { + vm_page_t m_tmp; u_int n; int order; + for (m_tmp = m; m_tmp < &m[npages]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: start %p %td %lu", + m, m_tmp - m, npages)); + /* * Avoid unnecessary coalescing by freeing the pages in the largest * possible power-of-two-sized subsets. @@ -714,6 +721,11 @@ vm_phys_free_contig(vm_page_t m, u_long npages) n = 1 << order; if (npages < n) break; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: xxx %p %td %u", + m, m_tmp - m, n)); vm_phys_free_pages(m, order); m += n; } @@ -721,6 +733,11 @@ vm_phys_free_contig(vm_page_t m, u_long npages) for (; npages > 0; npages -= n) { order = flsl(npages) - 1; n = 1 << order; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: yyy %p %td %u", + m, m_tmp - m, n)); vm_phys_free_pages(m, order); m += n; } Index: vm/vm_reserv.c =================================================================== --- vm/vm_reserv.c (revision 267213) +++ vm/vm_reserv.c (working copy) @@ -646,7 +646,8 @@ found: static void vm_reserv_break(vm_reserv_t rv, vm_page_t m) { - int begin_zeroes, hi, i, lo; + int begin_zeroes, hi, i, lo, x; + vm_object_t saved_object; mtx_assert(&vm_page_queue_free_mtx, MA_OWNED); KASSERT(rv->object != NULL, @@ -653,6 +654,7 @@ vm_reserv_break(vm_reserv_t rv, vm_page_t m) ("vm_reserv_break: reserv %p is free", rv)); KASSERT(!rv->inpartpopq, ("vm_reserv_break: reserv %p's inpartpopq is TRUE", rv)); + saved_object = rv->object; LIST_REMOVE(rv, objq); rv->object = NULL; if (m != NULL) { @@ -703,6 +705,19 @@ vm_reserv_break(vm_reserv_t rv, vm_page_t m) if (i != NPOPMAP) /* Convert from ffsl() to ordinary bit numbering. */ hi--; + for (x = begin_zeroes; x < NBPOPMAP * i + hi - begin_zeroes; + x++) { + KASSERT(isclr(rv->popmap, x), + ("vm_reserv_break: reserv %p popmap[%d]", rv, x)); + } + for (x = begin_zeroes; x < NBPOPMAP * i + hi - begin_zeroes; + x++) { + vm_page_t m_tmp = &rv->pages[x]; + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_reservs_break: saved_object=%p x=%d m_tmp->object=%p (%d)", + saved_object, x, m_tmp->object, m_tmp->object == kmem_object)); + } vm_phys_free_contig(&rv->pages[begin_zeroes], NBPOPMAP * i + hi - begin_zeroes); } while (i < NPOPMAP); --------------030200060505090800030104-- From owner-freebsd-arm@FreeBSD.ORG Mon Jun 9 16:33:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E887692B; Mon, 9 Jun 2014 16:33:04 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 99BB328C5; Mon, 9 Jun 2014 16:33:04 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s59GX3xI059613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 09:33:03 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s59GX2uT059612; Mon, 9 Jun 2014 09:33:02 -0700 (PDT) (envelope-from jmg) Date: Mon, 9 Jun 2014 09:33:02 -0700 From: John-Mark Gurney To: Alan Cox Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140609163302.GS31367@funkthat.com> Mail-Followup-To: Alan Cox , "freebsd-arm@freebsd.org" , alc@freebsd.org References: <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> <53949D96.3060409@rice.edu> <20140608235611.GP31367@funkthat.com> <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> <5395D312.5000302@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5395D312.5000302@rice.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 09 Jun 2014 09:33:03 -0700 (PDT) Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:33:05 -0000 Alan Cox wrote this message on Mon, Jun 09, 2014 at 10:30 -0500: > On 06/08/2014 23:22, John-Mark Gurney wrote: > > Alan Cox wrote this message on Sun, Jun 08, 2014 at 20:19 -0500: > >> On 06/08/2014 18:56, John-Mark Gurney wrote: > >>> Alan Cox wrote this message on Sun, Jun 08, 2014 at 12:29 -0500: > >>>> On 06/07/2014 19:39, John-Mark Gurney wrote: > >>>>> Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 -0500: > >>>>>> On 06/01/2014 03:11, John-Mark Gurney wrote: > >>>>>>> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: > >>>>>>>> On 05/30/2014 01:32, John-Mark Gurney wrote: > >>>>>>>>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: > >>>>>>>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: > >>>>>>>>>>> On 29 May 2014 10:16, Olivier Houchard wrote: > >>>>>>>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > >>>>>>>>>>>>> Have you tested this on xscale hardware? > >>>>>>>>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot > >>>>>>>>>>>> again. > >>>>>>>>>>> Woo! What can I provide to help you do this? :-) > >>>>>>>>>>> > >>>>>>>>>>> (Drinks? Food? Donations?) > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> Drinks and food are always appreciated ;) > >>>>>>>>>> It almost boots for me now, except a few userland programs gets SIGSEGV or > >>>>>>>>>> SIGILL along the way, trying to figure out why. > >>>>>>>>> Thanks for fixing ddb... I'm getting panic messages again... bad > >>>>>>>>> news is that my panic is still around: > >>>>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired > >>>>>>>>> > >>>>>>>>> Though, interestingly, it looks like sparc64 has a similar panic: > >>>>>>>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 > >>>>>>>>> > >>>>>>>>> kib, Alan, any clue to why this is happening? Any suggestions as to > >>>>>>>>> help track it down? > >>>>>>>> I'm afraid not. The dump below shows a perfectly normal, in-use page. > >>>>>>>> If this page had actually been free prior to the vm_page_alloc() call, > >>>>>>>> then other fields, like dirty, would have been different. In other > >>>>>>>> words, this isn't just a problem with the wire count. > >>>>>>>> > >>>>>>>> What object is vm_page_alloc() being performed on? > >>>>>>> Is this enough? Or do you need more? > >>>>>>> > >>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 > >>>>>>> KDB: enter: panic > >>>>>>> [ thread pid 781 tid 100051 ] > >>>>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > >>>>>>> db> show object/f 0xc1500b40 > >>>>>>> Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 > >>>>>>> sref=0, backing_object(0)=(0)+0x0 > >>>>>>> memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) > >>>>>>> ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) > >>>>>>> > >>>>>>> If you need more, let me know what/how to get it, and I will... > >>>>>>> > >>>>>> Anyone who has seen the "wired page" panic, please try the attached > >>>>>> patch. It introduces some new KASSERT()s that may help me to narrow > >>>>>> down the problem. I haven't been able to trigger these KASSERT()s on > >>>>>> amd64, but the symptoms that you guys are reporting are consistent with > >>>>>> a bug that would trigger these KASSERT()s. > >>>>> Ok, it triggered the xxx one: > >>>>> Starting sendmail_msp_queue. > >>>>> panic: vm_phys_free_contig: xxx > >>>>> KDB: enter: panic > >>>>> [ thread pid 782 tid 100051 ] > >>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > >>>>> db> bt > >>>>> Tracing pid 782 tid 100051 td 0xc1470000 > >>>>> db_trace_self() at db_trace_self > >>>>> pc = 0xc0566ec8 lr = 0xc0566f54 (db_trace_thread+0x50) > >>>>> sp = 0xcd830850 fp = 0xc03db694 > >>>>> db_trace_thread() at db_trace_thread+0x50 > >>>>> pc = 0xc0566f54 lr = 0xc022cd14 (db_command_init+0x620) > >>>>> sp = 0xcd8308b0 fp = 0xc03db694 > >>>>> db_command_init() at db_command_init+0x620 > >>>>> pc = 0xc022cd14 lr = 0xc022c3ec (db_skip_to_eol+0x480) > >>>>> sp = 0xcd8308c8 fp = 0xc03db694 > >>>>> r4 = 0xc0683c30 r5 = 0x00000000 > >>>>> db_skip_to_eol() at db_skip_to_eol+0x480 > >>>>> pc = 0xc022c3ec lr = 0xc022c554 (db_command_loop+0x5c) > >>>>> sp = 0xcd830968 fp = 0xc03db694 > >>>>> r4 = 0xcd83097c r5 = 0xc0683efc > >>>>> r6 = 0x00000000 r7 = 0x00000000 > >>>>> r8 = 0x00000001 r10 = 0x600000d3 > >>>>> db_command_loop() at db_command_loop+0x5c > >>>>> pc = 0xc022c554 lr = 0xc022e99c (X_db_sym_numargs+0xec) > >>>>> sp = 0xcd830970 fp = 0xc03db694 > >>>>> X_db_sym_numargs() at X_db_sym_numargs+0xec > >>>>> pc = 0xc022e99c lr = 0xc03db8c4 (kdb_trap+0x94) > >>>>> sp = 0xcd830a88 fp = 0xc03db694 > >>>>> r4 = 0x00000000 > >>>>> kdb_trap() at kdb_trap+0x94 > >>>>> pc = 0xc03db8c4 lr = 0xc0578eb0 (undefinedinstruction+0x2c8) > >>>>> sp = 0xcd830aa8 fp = 0xc03db694 > >>>>> r4 = 0x00000000 r5 = 0x00000000 > >>>>> r6 = 0x00000000 r7 = 0xcd830b20 > >>>>> r8 = 0xe7ffffff r10 = 0xe7ffffff > >>>>> undefinedinstruction() at undefinedinstruction+0x2c8 > >>>>> pc = 0xc0578eb0 lr = 0xc0568a0c (exception_exit) > >>>>> sp = 0xcd830b20 fp = 0xc0613e70 > >>>>> r4 = 0xffffffff r5 = 0xffff1004 > >>>>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 > >>>>> r8 = 0xc1470000 r9 = 0x00000013 > >>>>> r10 = 0x00000010 > >>>>> exception_exit() at exception_exit > >>>>> pc = 0xc0568a0c lr = 0xc03db68c (kdb_enter+0x38) > >>>>> sp = 0xcd830b70 fp = 0xc0613e70 > >>>>> r0 = 0x00000012 r1 = 0x60000013 > >>>>> r2 = 0xc06df2ac r3 = 0xc06d0ee8 > >>>>> r4 = 0xc05e5258 r5 = 0xc06155e8 > >>>>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 > >>>>> r8 = 0xc1470000 r9 = 0x00000013 > >>>>> r10 = 0x00000010 r12 = 0xc05e2518 > >>>>> kdb_enter() at kdb_enter+0x44 > >>>>> pc = 0xc03db698 lr = 0xc03aa094 (kern_reboot+0x948) > >>>>> sp = 0xcd830b78 fp = 0xc0613e70 > >>>>> r4 = 0x00000100 > >>>>> kern_reboot() at kern_reboot+0x948 > >>>>> pc = 0xc03aa094 lr = 0xc03aa164 (kassert_panic+0x68) > >>>>> sp = 0xcd830b90 fp = 0xc0613e70 > >>>>> r4 = 0xc06155e8 r5 = 0xc07e74a0 > >>>>> r6 = 0xc07e6fa0 r7 = 0x00000004 > >>>>> r8 = 0x00000010 > >>>>> kassert_panic() at kassert_panic+0x68 > >>>>> pc = 0xc03aa164 lr = 0xc055a0a8 (vm_phys_free_contig+0x8c) > >>>>> sp = 0xcd830bb0 fp = 0xc0613e70 > >>>>> r0 = 0xc06155e8 r1 = 0xc07e6d20 > >>>>> r2 = 0xc06e6a70 r3 = 0x00000000 > >>>>> r4 = 0xc07e73b0 > >>>>> vm_phys_free_contig() at vm_phys_free_contig+0x8c > >>>>> pc = 0xc055a0a8 lr = 0xc055ca70 (vm_reserv_startup+0x4bc) > >>>>> sp = 0xcd830bd0 fp = 0xc0613e70 > >>>>> r4 = 0xc08fb2cc r5 = 0x00000008 > >>>>> r6 = 0x000000e8 r7 = 0xc08fb280 > >>>>> r8 = 0x00000005 r10 = 0x00000001 > >>>>> vm_reserv_startup() at vm_reserv_startup+0x4bc > >>>>> pc = 0xc055ca70 lr = 0xc055cb40 (vm_reserv_startup+0x58c) > >>>>> sp = 0xcd830be8 fp = 0xc0613e70 > >>>>> r4 = 0xc08fb280 r5 = 0x00000000 > >>>>> r6 = 0xc14b7280 r7 = 0x00000040 > >>>>> r8 = 0x00000000 > >>>>> vm_reserv_startup() at vm_reserv_startup+0x58c > >>>>> pc = 0xc055cb40 lr = 0xc055ce08 (vm_reserv_reclaim_inactive+0x34) > >>>>> sp = 0xcd830bf0 fp = 0xc0613e70 > >>>>> r4 = 0xc06e6550 > >>>>> vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 > >>>>> pc = 0xc055ce08 lr = 0xc0554cb8 (vm_page_alloc+0x280) > >>>>> sp = 0xcd830bf8 fp = 0xc0613e70 > >>>>> vm_page_alloc() at vm_page_alloc+0x280 > >>>>> pc = 0xc0554cb8 lr = 0xc0540eb0 (vm_fault_hold+0x60c) > >>>>> sp = 0xcd830c30 fp = 0xcd830dac > >>>>> r4 = 0xc14b7280 r5 = 0xc0618d00 > >>>>> r6 = 0xcd830eb0 r7 = 0xc1470000 > >>>>> r8 = 0xcd830e60 r9 = 0x00000000 > >>>>> r10 = 0x00000000 > >>>>> vm_fault_hold() at vm_fault_hold+0x60c > >>>>> pc = 0xc0540eb0 lr = 0xc05426b8 (vm_fault+0x44) > >>>>> sp = 0xcd830db0 fp = 0x00000002 > >>>>> r4 = 0xc14c8a0c r5 = 0xc0618d00 > >>>>> r6 = 0xcd830eb0 r7 = 0xc1470000 > >>>>> r8 = 0xcd830e60 r9 = 0x00000001 > >>>>> r10 = 0x00000000 > >>>>> vm_fault() at vm_fault+0x44 > >>>>> pc = 0xc05426b8 lr = 0xc05782d0 (data_abort_handler+0x35c) > >>>>> sp = 0xcd830dc0 fp = 0x00000002 > >>>>> data_abort_handler() at data_abort_handler+0x35c > >>>>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > >>>>> sp = 0xcd830dc0 fp = 0x00000002 > >>>>> data_abort_handler() at data_abort_handler+0x35c > >>>>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > >>>>> sp = 0xcd830e60 fp = 0x20c43000 > >>>>> r4 = 0xffffffff r5 = 0xffff1004 > >>>>> r6 = 0x00000000 r7 = 0x20443740 > >>>>> r8 = 0x0009b8e4 r9 = 0x00000001 > >>>>> r10 = 0x00000004 > >>>>> exception_exit() at exception_exit > >>>>> pc = 0xc0568a0c lr = 0x204140d0 (0x204140d0) > >>>>> sp = 0xcd830eb0 fp = 0x20c43000 > >>>>> r0 = 0x00000000 r1 = 0x20c4302c > >>>>> r2 = 0x00000004 r3 = 0x00000000 > >>>>> r4 = 0x20446190 r5 = 0x20c4302c > >>>>> r6 = 0x00000000 r7 = 0x20443740 > >>>>> r8 = 0x0009b8e4 r9 = 0x00000001 > >>>>> r10 = 0x00000004 r12 = 0x00000001 > >>>>> Unable to unwind into user mode > >>>>> > >>>>> Hope this helps, let me know if you need anything else... > >>>>> > >>>> Please try the attached patch. It adds another KASSERT() loop. > >>>> > >>>> Depending on which KASSERT() fires, that will tell us whether to look > >>>> deeper at this function or its caller for the source of the problem. > >>> Ok, that panic is: > >>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 > >>> > >>> Let me know if you need any more info... oh, btw, the last %u needed > >>> to be %lu since it was a u_long, not an unsigned... > >>> > >> Ok. Here is the next debug patch. > > so, it's crashing in the same place: > > panic: vm_phys_free_contig: start 0xc07e6d20 21 24 > > > > so, I commented out this KASSERT, and now it panics with: > > panic: vm_phys_free_contig: xxx 0xc07e6fa0 13 16 > > > > so I commented out this KASSERT too, and it panics back w/ the original > > panic.. So it didn't hit the new KASSERT in vm_reserv_break... > > Next patch...It should panic in vm_reserv_break this time and tell me if > the reservation being broken belongs to the same object as the inuse > page that is being inappropriately freed. So, bad news... still panics with: panic: vm_phys_free_contig: start 0xc07e6d20 21 24 This panic seems to be consistent now, in that the start address is always the same... Is there a way you could add various debugging for this specific vm page to catch a stack trace (stack(9)) where it's going wrong? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Jun 9 16:56:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AB1BEFE; Mon, 9 Jun 2014 16:56:09 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 166C62AAC; Mon, 9 Jun 2014 16:56:08 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s59Gq5kT025589; Mon, 9 Jun 2014 11:56:07 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp1.rice.edu with ESMTP id 1mdfu4r1qc-1; Mon, 09 Jun 2014 11:56:06 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 46A59500108; Mon, 9 Jun 2014 11:56:06 -0500 (CDT) Message-ID: <5395E725.7020807@rice.edu> Date: Mon, 09 Jun 2014 11:56:05 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" , alc@freebsd.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa References: <20140530063228.GD43976@funkthat.com> <5388ABF1.3030200@rice.edu> <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> <53949D96.3060409@rice.edu> <20140608235611.GP31367@funkthat.com> <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> In-Reply-To: <20140609163302.GS31367@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------010505000208050803050800" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=1.67643676718399e-14 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.714301145562988 urlsuspect_oldscore=0.714301145562988 suspectscore=10 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.714301145562988 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406090219 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:56:09 -0000 This is a multi-part message in MIME format. --------------010505000208050803050800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/09/2014 11:33, John-Mark Gurney wrote: > Alan Cox wrote this message on Mon, Jun 09, 2014 at 10:30 -0500: >> On 06/08/2014 23:22, John-Mark Gurney wrote: >>> Alan Cox wrote this message on Sun, Jun 08, 2014 at 20:19 -0500: >>>> On 06/08/2014 18:56, John-Mark Gurney wrote: >>>>> Alan Cox wrote this message on Sun, Jun 08, 2014 at 12:29 -0500: >>>>>> On 06/07/2014 19:39, John-Mark Gurney wrote: >>>>>>> Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 -0500: >>>>>>>> On 06/01/2014 03:11, John-Mark Gurney wrote: >>>>>>>>> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: >>>>>>>>>> On 05/30/2014 01:32, John-Mark Gurney wrote: >>>>>>>>>>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: >>>>>>>>>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: >>>>>>>>>>>>> On 29 May 2014 10:16, Olivier Houchard wrote: >>>>>>>>>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: >>>>>>>>>>>>>>> Have you tested this on xscale hardware? >>>>>>>>>>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot >>>>>>>>>>>>>> again. >>>>>>>>>>>>> Woo! What can I provide to help you do this? :-) >>>>>>>>>>>>> >>>>>>>>>>>>> (Drinks? Food? Donations?) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Drinks and food are always appreciated ;) >>>>>>>>>>>> It almost boots for me now, except a few userland programs gets SIGSEGV or >>>>>>>>>>>> SIGILL along the way, trying to figure out why. >>>>>>>>>>> Thanks for fixing ddb... I'm getting panic messages again... bad >>>>>>>>>>> news is that my panic is still around: >>>>>>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired >>>>>>>>>>> >>>>>>>>>>> Though, interestingly, it looks like sparc64 has a similar panic: >>>>>>>>>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 >>>>>>>>>>> >>>>>>>>>>> kib, Alan, any clue to why this is happening? Any suggestions as to >>>>>>>>>>> help track it down? >>>>>>>>>> I'm afraid not. The dump below shows a perfectly normal, in-use page. >>>>>>>>>> If this page had actually been free prior to the vm_page_alloc() call, >>>>>>>>>> then other fields, like dirty, would have been different. In other >>>>>>>>>> words, this isn't just a problem with the wire count. >>>>>>>>>> >>>>>>>>>> What object is vm_page_alloc() being performed on? >>>>>>>>> Is this enough? Or do you need more? >>>>>>>>> >>>>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 >>>>>>>>> KDB: enter: panic >>>>>>>>> [ thread pid 781 tid 100051 ] >>>>>>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! >>>>>>>>> db> show object/f 0xc1500b40 >>>>>>>>> Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 >>>>>>>>> sref=0, backing_object(0)=(0)+0x0 >>>>>>>>> memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) >>>>>>>>> ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) >>>>>>>>> >>>>>>>>> If you need more, let me know what/how to get it, and I will... >>>>>>>>> >>>>>>>> Anyone who has seen the "wired page" panic, please try the attached >>>>>>>> patch. It introduces some new KASSERT()s that may help me to narrow >>>>>>>> down the problem. I haven't been able to trigger these KASSERT()s on >>>>>>>> amd64, but the symptoms that you guys are reporting are consistent with >>>>>>>> a bug that would trigger these KASSERT()s. >>>>>>> Ok, it triggered the xxx one: >>>>>>> Starting sendmail_msp_queue. >>>>>>> panic: vm_phys_free_contig: xxx >>>>>>> KDB: enter: panic >>>>>>> [ thread pid 782 tid 100051 ] >>>>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! >>>>>>> db> bt >>>>>>> Tracing pid 782 tid 100051 td 0xc1470000 >>>>>>> db_trace_self() at db_trace_self >>>>>>> pc = 0xc0566ec8 lr = 0xc0566f54 (db_trace_thread+0x50) >>>>>>> sp = 0xcd830850 fp = 0xc03db694 >>>>>>> db_trace_thread() at db_trace_thread+0x50 >>>>>>> pc = 0xc0566f54 lr = 0xc022cd14 (db_command_init+0x620) >>>>>>> sp = 0xcd8308b0 fp = 0xc03db694 >>>>>>> db_command_init() at db_command_init+0x620 >>>>>>> pc = 0xc022cd14 lr = 0xc022c3ec (db_skip_to_eol+0x480) >>>>>>> sp = 0xcd8308c8 fp = 0xc03db694 >>>>>>> r4 = 0xc0683c30 r5 = 0x00000000 >>>>>>> db_skip_to_eol() at db_skip_to_eol+0x480 >>>>>>> pc = 0xc022c3ec lr = 0xc022c554 (db_command_loop+0x5c) >>>>>>> sp = 0xcd830968 fp = 0xc03db694 >>>>>>> r4 = 0xcd83097c r5 = 0xc0683efc >>>>>>> r6 = 0x00000000 r7 = 0x00000000 >>>>>>> r8 = 0x00000001 r10 = 0x600000d3 >>>>>>> db_command_loop() at db_command_loop+0x5c >>>>>>> pc = 0xc022c554 lr = 0xc022e99c (X_db_sym_numargs+0xec) >>>>>>> sp = 0xcd830970 fp = 0xc03db694 >>>>>>> X_db_sym_numargs() at X_db_sym_numargs+0xec >>>>>>> pc = 0xc022e99c lr = 0xc03db8c4 (kdb_trap+0x94) >>>>>>> sp = 0xcd830a88 fp = 0xc03db694 >>>>>>> r4 = 0x00000000 >>>>>>> kdb_trap() at kdb_trap+0x94 >>>>>>> pc = 0xc03db8c4 lr = 0xc0578eb0 (undefinedinstruction+0x2c8) >>>>>>> sp = 0xcd830aa8 fp = 0xc03db694 >>>>>>> r4 = 0x00000000 r5 = 0x00000000 >>>>>>> r6 = 0x00000000 r7 = 0xcd830b20 >>>>>>> r8 = 0xe7ffffff r10 = 0xe7ffffff >>>>>>> undefinedinstruction() at undefinedinstruction+0x2c8 >>>>>>> pc = 0xc0578eb0 lr = 0xc0568a0c (exception_exit) >>>>>>> sp = 0xcd830b20 fp = 0xc0613e70 >>>>>>> r4 = 0xffffffff r5 = 0xffff1004 >>>>>>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 >>>>>>> r8 = 0xc1470000 r9 = 0x00000013 >>>>>>> r10 = 0x00000010 >>>>>>> exception_exit() at exception_exit >>>>>>> pc = 0xc0568a0c lr = 0xc03db68c (kdb_enter+0x38) >>>>>>> sp = 0xcd830b70 fp = 0xc0613e70 >>>>>>> r0 = 0x00000012 r1 = 0x60000013 >>>>>>> r2 = 0xc06df2ac r3 = 0xc06d0ee8 >>>>>>> r4 = 0xc05e5258 r5 = 0xc06155e8 >>>>>>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 >>>>>>> r8 = 0xc1470000 r9 = 0x00000013 >>>>>>> r10 = 0x00000010 r12 = 0xc05e2518 >>>>>>> kdb_enter() at kdb_enter+0x44 >>>>>>> pc = 0xc03db698 lr = 0xc03aa094 (kern_reboot+0x948) >>>>>>> sp = 0xcd830b78 fp = 0xc0613e70 >>>>>>> r4 = 0x00000100 >>>>>>> kern_reboot() at kern_reboot+0x948 >>>>>>> pc = 0xc03aa094 lr = 0xc03aa164 (kassert_panic+0x68) >>>>>>> sp = 0xcd830b90 fp = 0xc0613e70 >>>>>>> r4 = 0xc06155e8 r5 = 0xc07e74a0 >>>>>>> r6 = 0xc07e6fa0 r7 = 0x00000004 >>>>>>> r8 = 0x00000010 >>>>>>> kassert_panic() at kassert_panic+0x68 >>>>>>> pc = 0xc03aa164 lr = 0xc055a0a8 (vm_phys_free_contig+0x8c) >>>>>>> sp = 0xcd830bb0 fp = 0xc0613e70 >>>>>>> r0 = 0xc06155e8 r1 = 0xc07e6d20 >>>>>>> r2 = 0xc06e6a70 r3 = 0x00000000 >>>>>>> r4 = 0xc07e73b0 >>>>>>> vm_phys_free_contig() at vm_phys_free_contig+0x8c >>>>>>> pc = 0xc055a0a8 lr = 0xc055ca70 (vm_reserv_startup+0x4bc) >>>>>>> sp = 0xcd830bd0 fp = 0xc0613e70 >>>>>>> r4 = 0xc08fb2cc r5 = 0x00000008 >>>>>>> r6 = 0x000000e8 r7 = 0xc08fb280 >>>>>>> r8 = 0x00000005 r10 = 0x00000001 >>>>>>> vm_reserv_startup() at vm_reserv_startup+0x4bc >>>>>>> pc = 0xc055ca70 lr = 0xc055cb40 (vm_reserv_startup+0x58c) >>>>>>> sp = 0xcd830be8 fp = 0xc0613e70 >>>>>>> r4 = 0xc08fb280 r5 = 0x00000000 >>>>>>> r6 = 0xc14b7280 r7 = 0x00000040 >>>>>>> r8 = 0x00000000 >>>>>>> vm_reserv_startup() at vm_reserv_startup+0x58c >>>>>>> pc = 0xc055cb40 lr = 0xc055ce08 (vm_reserv_reclaim_inactive+0x34) >>>>>>> sp = 0xcd830bf0 fp = 0xc0613e70 >>>>>>> r4 = 0xc06e6550 >>>>>>> vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 >>>>>>> pc = 0xc055ce08 lr = 0xc0554cb8 (vm_page_alloc+0x280) >>>>>>> sp = 0xcd830bf8 fp = 0xc0613e70 >>>>>>> vm_page_alloc() at vm_page_alloc+0x280 >>>>>>> pc = 0xc0554cb8 lr = 0xc0540eb0 (vm_fault_hold+0x60c) >>>>>>> sp = 0xcd830c30 fp = 0xcd830dac >>>>>>> r4 = 0xc14b7280 r5 = 0xc0618d00 >>>>>>> r6 = 0xcd830eb0 r7 = 0xc1470000 >>>>>>> r8 = 0xcd830e60 r9 = 0x00000000 >>>>>>> r10 = 0x00000000 >>>>>>> vm_fault_hold() at vm_fault_hold+0x60c >>>>>>> pc = 0xc0540eb0 lr = 0xc05426b8 (vm_fault+0x44) >>>>>>> sp = 0xcd830db0 fp = 0x00000002 >>>>>>> r4 = 0xc14c8a0c r5 = 0xc0618d00 >>>>>>> r6 = 0xcd830eb0 r7 = 0xc1470000 >>>>>>> r8 = 0xcd830e60 r9 = 0x00000001 >>>>>>> r10 = 0x00000000 >>>>>>> vm_fault() at vm_fault+0x44 >>>>>>> pc = 0xc05426b8 lr = 0xc05782d0 (data_abort_handler+0x35c) >>>>>>> sp = 0xcd830dc0 fp = 0x00000002 >>>>>>> data_abort_handler() at data_abort_handler+0x35c >>>>>>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) >>>>>>> sp = 0xcd830dc0 fp = 0x00000002 >>>>>>> data_abort_handler() at data_abort_handler+0x35c >>>>>>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) >>>>>>> sp = 0xcd830e60 fp = 0x20c43000 >>>>>>> r4 = 0xffffffff r5 = 0xffff1004 >>>>>>> r6 = 0x00000000 r7 = 0x20443740 >>>>>>> r8 = 0x0009b8e4 r9 = 0x00000001 >>>>>>> r10 = 0x00000004 >>>>>>> exception_exit() at exception_exit >>>>>>> pc = 0xc0568a0c lr = 0x204140d0 (0x204140d0) >>>>>>> sp = 0xcd830eb0 fp = 0x20c43000 >>>>>>> r0 = 0x00000000 r1 = 0x20c4302c >>>>>>> r2 = 0x00000004 r3 = 0x00000000 >>>>>>> r4 = 0x20446190 r5 = 0x20c4302c >>>>>>> r6 = 0x00000000 r7 = 0x20443740 >>>>>>> r8 = 0x0009b8e4 r9 = 0x00000001 >>>>>>> r10 = 0x00000004 r12 = 0x00000001 >>>>>>> Unable to unwind into user mode >>>>>>> >>>>>>> Hope this helps, let me know if you need anything else... >>>>>>> >>>>>> Please try the attached patch. It adds another KASSERT() loop. >>>>>> >>>>>> Depending on which KASSERT() fires, that will tell us whether to look >>>>>> deeper at this function or its caller for the source of the problem. >>>>> Ok, that panic is: >>>>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 >>>>> >>>>> Let me know if you need any more info... oh, btw, the last %u needed >>>>> to be %lu since it was a u_long, not an unsigned... >>>>> >>>> Ok. Here is the next debug patch. >>> so, it's crashing in the same place: >>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 >>> >>> so, I commented out this KASSERT, and now it panics with: >>> panic: vm_phys_free_contig: xxx 0xc07e6fa0 13 16 >>> >>> so I commented out this KASSERT too, and it panics back w/ the original >>> panic.. So it didn't hit the new KASSERT in vm_reserv_break... >> Next patch...It should panic in vm_reserv_break this time and tell me if >> the reservation being broken belongs to the same object as the inuse >> page that is being inappropriately freed. > So, bad news... still panics with: > panic: vm_phys_free_contig: start 0xc07e6d20 21 24 > > This panic seems to be consistent now, in that the start address is > always the same... Is there a way you could add various debugging > for this specific vm page to catch a stack trace (stack(9)) where it's > going wrong? > I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this. --------------010505000208050803050800 Content-Type: text/plain; charset=ISO-8859-15; name="arm_debug7.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_debug7.patch" Index: vm/vm_phys.c =================================================================== --- vm/vm_phys.c (revision 267282) +++ vm/vm_phys.c (working copy) @@ -693,9 +693,16 @@ vm_phys_free_pages(vm_page_t m, int order) void vm_phys_free_contig(vm_page_t m, u_long npages) { + vm_page_t m_tmp; u_int n; int order; + for (m_tmp = m; m_tmp < &m[npages]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: start %p %td %lu", + m, m_tmp - m, npages)); + /* * Avoid unnecessary coalescing by freeing the pages in the largest * possible power-of-two-sized subsets. @@ -714,6 +721,11 @@ vm_phys_free_contig(vm_page_t m, u_long npages) n = 1 << order; if (npages < n) break; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: xxx %p %td %u", + m, m_tmp - m, n)); vm_phys_free_pages(m, order); m += n; } @@ -721,6 +733,11 @@ vm_phys_free_contig(vm_page_t m, u_long npages) for (; npages > 0; npages -= n) { order = flsl(npages) - 1; n = 1 << order; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: yyy %p %td %u", + m, m_tmp - m, n)); vm_phys_free_pages(m, order); m += n; } Index: vm/vm_reserv.c =================================================================== --- vm/vm_reserv.c (revision 267282) +++ vm/vm_reserv.c (working copy) @@ -646,7 +646,8 @@ found: static void vm_reserv_break(vm_reserv_t rv, vm_page_t m) { - int begin_zeroes, hi, i, lo; + int begin_zeroes, hi, i, lo, x; + vm_object_t saved_object; mtx_assert(&vm_page_queue_free_mtx, MA_OWNED); KASSERT(rv->object != NULL, @@ -653,6 +654,7 @@ vm_reserv_break(vm_reserv_t rv, vm_page_t m) ("vm_reserv_break: reserv %p is free", rv)); KASSERT(!rv->inpartpopq, ("vm_reserv_break: reserv %p's inpartpopq is TRUE", rv)); + saved_object = rv->object; LIST_REMOVE(rv, objq); rv->object = NULL; if (m != NULL) { @@ -703,6 +705,19 @@ vm_reserv_break(vm_reserv_t rv, vm_page_t m) if (i != NPOPMAP) /* Convert from ffsl() to ordinary bit numbering. */ hi--; + for (x = begin_zeroes; x < NBPOPMAP * i + hi; x++) { + vm_page_t m_tmp = &rv->pages[x]; + KASSERT(isclr(rv->popmap, x), + ("vm_reserv_break: 1 saved_object=%p x=%d m_tmp->object=%p (%d)", + saved_object, x, m_tmp->object, m_tmp->object == kmem_object)); + } + for (x = begin_zeroes; x < NBPOPMAP * i + hi; x++) { + vm_page_t m_tmp = &rv->pages[x]; + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_reserv_break: 2 saved_object=%p x=%d m_tmp->object=%p (%d)", + saved_object, x, m_tmp->object, m_tmp->object == kmem_object)); + } vm_phys_free_contig(&rv->pages[begin_zeroes], NBPOPMAP * i + hi - begin_zeroes); } while (i < NPOPMAP); --------------010505000208050803050800-- From owner-freebsd-arm@FreeBSD.ORG Mon Jun 9 17:44:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D78FF62; Mon, 9 Jun 2014 17:44:34 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D7A502F1E; Mon, 9 Jun 2014 17:44:33 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s59HiWV7060550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 10:44:32 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s59HiVFw060549; Mon, 9 Jun 2014 10:44:31 -0700 (PDT) (envelope-from jmg) Date: Mon, 9 Jun 2014 10:44:31 -0700 From: John-Mark Gurney To: Alan Cox Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140609174431.GT31367@funkthat.com> Mail-Followup-To: Alan Cox , "freebsd-arm@freebsd.org" , alc@freebsd.org References: <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> <53949D96.3060409@rice.edu> <20140608235611.GP31367@funkthat.com> <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5395E725.7020807@rice.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 09 Jun 2014 10:44:32 -0700 (PDT) Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:44:34 -0000 Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: > On 06/09/2014 11:33, John-Mark Gurney wrote: > > Alan Cox wrote this message on Mon, Jun 09, 2014 at 10:30 -0500: > >> On 06/08/2014 23:22, John-Mark Gurney wrote: > >>> Alan Cox wrote this message on Sun, Jun 08, 2014 at 20:19 -0500: > >>>> On 06/08/2014 18:56, John-Mark Gurney wrote: > >>>>> Alan Cox wrote this message on Sun, Jun 08, 2014 at 12:29 -0500: > >>>>>> On 06/07/2014 19:39, John-Mark Gurney wrote: > >>>>>>> Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 -0500: > >>>>>>>> On 06/01/2014 03:11, John-Mark Gurney wrote: > >>>>>>>>> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500: > >>>>>>>>>> On 05/30/2014 01:32, John-Mark Gurney wrote: > >>>>>>>>>>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200: > >>>>>>>>>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote: > >>>>>>>>>>>>> On 29 May 2014 10:16, Olivier Houchard wrote: > >>>>>>>>>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote: > >>>>>>>>>>>>>>> Have you tested this on xscale hardware? > >>>>>>>>>>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot > >>>>>>>>>>>>>> again. > >>>>>>>>>>>>> Woo! What can I provide to help you do this? :-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> (Drinks? Food? Donations?) > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> Drinks and food are always appreciated ;) > >>>>>>>>>>>> It almost boots for me now, except a few userland programs gets SIGSEGV or > >>>>>>>>>>>> SIGILL along the way, trying to figure out why. > >>>>>>>>>>> Thanks for fixing ddb... I'm getting panic messages again... bad > >>>>>>>>>>> news is that my panic is still around: > >>>>>>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired > >>>>>>>>>>> > >>>>>>>>>>> Though, interestingly, it looks like sparc64 has a similar panic: > >>>>>>>>>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080 > >>>>>>>>>>> > >>>>>>>>>>> kib, Alan, any clue to why this is happening? Any suggestions as to > >>>>>>>>>>> help track it down? > >>>>>>>>>> I'm afraid not. The dump below shows a perfectly normal, in-use page. > >>>>>>>>>> If this page had actually been free prior to the vm_page_alloc() call, > >>>>>>>>>> then other fields, like dirty, would have been different. In other > >>>>>>>>>> words, this isn't just a problem with the wire count. > >>>>>>>>>> > >>>>>>>>>> What object is vm_page_alloc() being performed on? > >>>>>>>>> Is this enough? Or do you need more? > >>>>>>>>> > >>>>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40 > >>>>>>>>> KDB: enter: panic > >>>>>>>>> [ thread pid 781 tid 100051 ] > >>>>>>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > >>>>>>>>> db> show object/f 0xc1500b40 > >>>>>>>>> Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0 > >>>>>>>>> sref=0, backing_object(0)=(0)+0x0 > >>>>>>>>> memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000) > >>>>>>>>> ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000) > >>>>>>>>> > >>>>>>>>> If you need more, let me know what/how to get it, and I will... > >>>>>>>>> > >>>>>>>> Anyone who has seen the "wired page" panic, please try the attached > >>>>>>>> patch. It introduces some new KASSERT()s that may help me to narrow > >>>>>>>> down the problem. I haven't been able to trigger these KASSERT()s on > >>>>>>>> amd64, but the symptoms that you guys are reporting are consistent with > >>>>>>>> a bug that would trigger these KASSERT()s. > >>>>>>> Ok, it triggered the xxx one: > >>>>>>> Starting sendmail_msp_queue. > >>>>>>> panic: vm_phys_free_contig: xxx > >>>>>>> KDB: enter: panic > >>>>>>> [ thread pid 782 tid 100051 ] > >>>>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror r15]! > >>>>>>> db> bt > >>>>>>> Tracing pid 782 tid 100051 td 0xc1470000 > >>>>>>> db_trace_self() at db_trace_self > >>>>>>> pc = 0xc0566ec8 lr = 0xc0566f54 (db_trace_thread+0x50) > >>>>>>> sp = 0xcd830850 fp = 0xc03db694 > >>>>>>> db_trace_thread() at db_trace_thread+0x50 > >>>>>>> pc = 0xc0566f54 lr = 0xc022cd14 (db_command_init+0x620) > >>>>>>> sp = 0xcd8308b0 fp = 0xc03db694 > >>>>>>> db_command_init() at db_command_init+0x620 > >>>>>>> pc = 0xc022cd14 lr = 0xc022c3ec (db_skip_to_eol+0x480) > >>>>>>> sp = 0xcd8308c8 fp = 0xc03db694 > >>>>>>> r4 = 0xc0683c30 r5 = 0x00000000 > >>>>>>> db_skip_to_eol() at db_skip_to_eol+0x480 > >>>>>>> pc = 0xc022c3ec lr = 0xc022c554 (db_command_loop+0x5c) > >>>>>>> sp = 0xcd830968 fp = 0xc03db694 > >>>>>>> r4 = 0xcd83097c r5 = 0xc0683efc > >>>>>>> r6 = 0x00000000 r7 = 0x00000000 > >>>>>>> r8 = 0x00000001 r10 = 0x600000d3 > >>>>>>> db_command_loop() at db_command_loop+0x5c > >>>>>>> pc = 0xc022c554 lr = 0xc022e99c (X_db_sym_numargs+0xec) > >>>>>>> sp = 0xcd830970 fp = 0xc03db694 > >>>>>>> X_db_sym_numargs() at X_db_sym_numargs+0xec > >>>>>>> pc = 0xc022e99c lr = 0xc03db8c4 (kdb_trap+0x94) > >>>>>>> sp = 0xcd830a88 fp = 0xc03db694 > >>>>>>> r4 = 0x00000000 > >>>>>>> kdb_trap() at kdb_trap+0x94 > >>>>>>> pc = 0xc03db8c4 lr = 0xc0578eb0 (undefinedinstruction+0x2c8) > >>>>>>> sp = 0xcd830aa8 fp = 0xc03db694 > >>>>>>> r4 = 0x00000000 r5 = 0x00000000 > >>>>>>> r6 = 0x00000000 r7 = 0xcd830b20 > >>>>>>> r8 = 0xe7ffffff r10 = 0xe7ffffff > >>>>>>> undefinedinstruction() at undefinedinstruction+0x2c8 > >>>>>>> pc = 0xc0578eb0 lr = 0xc0568a0c (exception_exit) > >>>>>>> sp = 0xcd830b20 fp = 0xc0613e70 > >>>>>>> r4 = 0xffffffff r5 = 0xffff1004 > >>>>>>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 > >>>>>>> r8 = 0xc1470000 r9 = 0x00000013 > >>>>>>> r10 = 0x00000010 > >>>>>>> exception_exit() at exception_exit > >>>>>>> pc = 0xc0568a0c lr = 0xc03db68c (kdb_enter+0x38) > >>>>>>> sp = 0xcd830b70 fp = 0xc0613e70 > >>>>>>> r0 = 0x00000012 r1 = 0x60000013 > >>>>>>> r2 = 0xc06df2ac r3 = 0xc06d0ee8 > >>>>>>> r4 = 0xc05e5258 r5 = 0xc06155e8 > >>>>>>> r6 = 0xc06d0ebc r7 = 0xcd830ba4 > >>>>>>> r8 = 0xc1470000 r9 = 0x00000013 > >>>>>>> r10 = 0x00000010 r12 = 0xc05e2518 > >>>>>>> kdb_enter() at kdb_enter+0x44 > >>>>>>> pc = 0xc03db698 lr = 0xc03aa094 (kern_reboot+0x948) > >>>>>>> sp = 0xcd830b78 fp = 0xc0613e70 > >>>>>>> r4 = 0x00000100 > >>>>>>> kern_reboot() at kern_reboot+0x948 > >>>>>>> pc = 0xc03aa094 lr = 0xc03aa164 (kassert_panic+0x68) > >>>>>>> sp = 0xcd830b90 fp = 0xc0613e70 > >>>>>>> r4 = 0xc06155e8 r5 = 0xc07e74a0 > >>>>>>> r6 = 0xc07e6fa0 r7 = 0x00000004 > >>>>>>> r8 = 0x00000010 > >>>>>>> kassert_panic() at kassert_panic+0x68 > >>>>>>> pc = 0xc03aa164 lr = 0xc055a0a8 (vm_phys_free_contig+0x8c) > >>>>>>> sp = 0xcd830bb0 fp = 0xc0613e70 > >>>>>>> r0 = 0xc06155e8 r1 = 0xc07e6d20 > >>>>>>> r2 = 0xc06e6a70 r3 = 0x00000000 > >>>>>>> r4 = 0xc07e73b0 > >>>>>>> vm_phys_free_contig() at vm_phys_free_contig+0x8c > >>>>>>> pc = 0xc055a0a8 lr = 0xc055ca70 (vm_reserv_startup+0x4bc) > >>>>>>> sp = 0xcd830bd0 fp = 0xc0613e70 > >>>>>>> r4 = 0xc08fb2cc r5 = 0x00000008 > >>>>>>> r6 = 0x000000e8 r7 = 0xc08fb280 > >>>>>>> r8 = 0x00000005 r10 = 0x00000001 > >>>>>>> vm_reserv_startup() at vm_reserv_startup+0x4bc > >>>>>>> pc = 0xc055ca70 lr = 0xc055cb40 (vm_reserv_startup+0x58c) > >>>>>>> sp = 0xcd830be8 fp = 0xc0613e70 > >>>>>>> r4 = 0xc08fb280 r5 = 0x00000000 > >>>>>>> r6 = 0xc14b7280 r7 = 0x00000040 > >>>>>>> r8 = 0x00000000 > >>>>>>> vm_reserv_startup() at vm_reserv_startup+0x58c > >>>>>>> pc = 0xc055cb40 lr = 0xc055ce08 (vm_reserv_reclaim_inactive+0x34) > >>>>>>> sp = 0xcd830bf0 fp = 0xc0613e70 > >>>>>>> r4 = 0xc06e6550 > >>>>>>> vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 > >>>>>>> pc = 0xc055ce08 lr = 0xc0554cb8 (vm_page_alloc+0x280) > >>>>>>> sp = 0xcd830bf8 fp = 0xc0613e70 > >>>>>>> vm_page_alloc() at vm_page_alloc+0x280 > >>>>>>> pc = 0xc0554cb8 lr = 0xc0540eb0 (vm_fault_hold+0x60c) > >>>>>>> sp = 0xcd830c30 fp = 0xcd830dac > >>>>>>> r4 = 0xc14b7280 r5 = 0xc0618d00 > >>>>>>> r6 = 0xcd830eb0 r7 = 0xc1470000 > >>>>>>> r8 = 0xcd830e60 r9 = 0x00000000 > >>>>>>> r10 = 0x00000000 > >>>>>>> vm_fault_hold() at vm_fault_hold+0x60c > >>>>>>> pc = 0xc0540eb0 lr = 0xc05426b8 (vm_fault+0x44) > >>>>>>> sp = 0xcd830db0 fp = 0x00000002 > >>>>>>> r4 = 0xc14c8a0c r5 = 0xc0618d00 > >>>>>>> r6 = 0xcd830eb0 r7 = 0xc1470000 > >>>>>>> r8 = 0xcd830e60 r9 = 0x00000001 > >>>>>>> r10 = 0x00000000 > >>>>>>> vm_fault() at vm_fault+0x44 > >>>>>>> pc = 0xc05426b8 lr = 0xc05782d0 (data_abort_handler+0x35c) > >>>>>>> sp = 0xcd830dc0 fp = 0x00000002 > >>>>>>> data_abort_handler() at data_abort_handler+0x35c > >>>>>>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > >>>>>>> sp = 0xcd830dc0 fp = 0x00000002 > >>>>>>> data_abort_handler() at data_abort_handler+0x35c > >>>>>>> pc = 0xc05782d0 lr = 0xc0568a0c (exception_exit) > >>>>>>> sp = 0xcd830e60 fp = 0x20c43000 > >>>>>>> r4 = 0xffffffff r5 = 0xffff1004 > >>>>>>> r6 = 0x00000000 r7 = 0x20443740 > >>>>>>> r8 = 0x0009b8e4 r9 = 0x00000001 > >>>>>>> r10 = 0x00000004 > >>>>>>> exception_exit() at exception_exit > >>>>>>> pc = 0xc0568a0c lr = 0x204140d0 (0x204140d0) > >>>>>>> sp = 0xcd830eb0 fp = 0x20c43000 > >>>>>>> r0 = 0x00000000 r1 = 0x20c4302c > >>>>>>> r2 = 0x00000004 r3 = 0x00000000 > >>>>>>> r4 = 0x20446190 r5 = 0x20c4302c > >>>>>>> r6 = 0x00000000 r7 = 0x20443740 > >>>>>>> r8 = 0x0009b8e4 r9 = 0x00000001 > >>>>>>> r10 = 0x00000004 r12 = 0x00000001 > >>>>>>> Unable to unwind into user mode > >>>>>>> > >>>>>>> Hope this helps, let me know if you need anything else... > >>>>>>> > >>>>>> Please try the attached patch. It adds another KASSERT() loop. > >>>>>> > >>>>>> Depending on which KASSERT() fires, that will tell us whether to look > >>>>>> deeper at this function or its caller for the source of the problem. > >>>>> Ok, that panic is: > >>>>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 > >>>>> > >>>>> Let me know if you need any more info... oh, btw, the last %u needed > >>>>> to be %lu since it was a u_long, not an unsigned... > >>>>> > >>>> Ok. Here is the next debug patch. > >>> so, it's crashing in the same place: > >>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 > >>> > >>> so, I commented out this KASSERT, and now it panics with: > >>> panic: vm_phys_free_contig: xxx 0xc07e6fa0 13 16 > >>> > >>> so I commented out this KASSERT too, and it panics back w/ the original > >>> panic.. So it didn't hit the new KASSERT in vm_reserv_break... > >> Next patch...It should panic in vm_reserv_break this time and tell me if > >> the reservation being broken belongs to the same object as the inuse > >> page that is being inappropriately freed. > > So, bad news... still panics with: > > panic: vm_phys_free_contig: start 0xc07e6d20 21 24 > > > > This panic seems to be consistent now, in that the start address is > > always the same... Is there a way you could add various debugging > > for this specific vm page to catch a stack trace (stack(9)) where it's > > going wrong? > > > > I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this. No worried, the new patch panics: panic: vm_reserv_break: 2 saved_object=0xc06e6378 x=253 m_tmp->object=0xc06e6378 (1) w/ a bt of: [...] vm_reserv_startup() at vm_reserv_startup+0x570 pc = 0xc055cd94 lr = 0xc055cec8 (vm_reserv_startup+0x6a4) sp = 0xcd833be8 fp = 0xc06142d0 r4 = 0xc08fb280 r5 = 0x00000000 r6 = 0xc14b76e0 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000033 r10 = 0x00000001 vm_reserv_startup() at vm_reserv_startup+0x6a4 pc = 0xc055cec8 lr = 0xc055d190 (vm_reserv_reclaim_inactive+0x34) sp = 0xcd833bf0 fp = 0xc06142d0 r4 = 0xc06e6550 vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 pc = 0xc055d190 lr = 0xc0554eb0 (vm_page_alloc+0x280) sp = 0xcd833bf8 fp = 0xc06142d0 vm_page_alloc() at vm_page_alloc+0x280 pc = 0xc0554eb0 lr = 0xc0540ebc (vm_fault_hold+0x60c) sp = 0xcd833c30 fp = 0xcd833dac r4 = 0xc14b76e0 r5 = 0xc0619288 r6 = 0xcd833eb0 r7 = 0xc0f7ec80 r8 = 0xcd833e60 r9 = 0x00000000 r10 = 0x00000000 vm_fault_hold() at vm_fault_hold+0x60c pc = 0xc0540ebc lr = 0xc05426c4 (vm_fault+0x44) sp = 0xcd833db0 fp = 0x00000002 r4 = 0xc14c66ec r5 = 0xc0619288 r6 = 0xcd833eb0 r7 = 0xc0f7ec80 r8 = 0xcd833e60 r9 = 0x00000001 r10 = 0x00000000 vm_fault() at vm_fault+0x44 pc = 0xc05426c4 lr = 0xc05786d0 (data_abort_handler+0x35c) sp = 0xcd833dc0 fp = 0x00000002 data_abort_handler() at data_abort_handler+0x35c pc = 0xc05786d0 lr = 0xc0568dc8 (exception_exit) sp = 0xcd833e60 fp = 0x00000000 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0x001b7740 r7 = 0x00052ec4 r8 = 0x00000000 r9 = 0x000cc4b0 r10 = 0x00000000 exception_exit() at exception_exit pc = 0xc0568dc8 lr = 0x203f1208 (0x203f1208) sp = 0xcd833eb0 fp = 0x00000000 r0 = 0x20c53e60 r1 = 0x00000000 r2 = 0x000eeb40 r3 = 0x00000001 r4 = 0x00000000 r5 = 0x000e9654 r6 = 0x001b7740 r7 = 0x00052ec4 r8 = 0x00000000 r9 = 0x000cc4b0 r10 = 0x00000000 r12 = 0x200d26a4 Let me know if you need any more information.. Thanks for tracking this down. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Jun 9 19:23:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C28D84CD; Mon, 9 Jun 2014 19:23:38 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81F4028BA; Mon, 9 Jun 2014 19:23:38 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s59JLrvo032289; Mon, 9 Jun 2014 14:23:30 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp1.rice.edu with ESMTP id 1mdfu4r54s-1; Mon, 09 Jun 2014 14:23:30 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from [10.82.76.83] (unknown [10.82.76.83]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id E8F5750003F; Mon, 9 Jun 2014 14:23:29 -0500 (CDT) Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alan Cox In-Reply-To: <20140609174431.GT31367@funkthat.com> Date: Mon, 9 Jun 2014 14:23:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> References: <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> <53949D96.3060409@rice.edu> <20140608235611.GP31367@funkthat.com> <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=1 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406090246 Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 19:23:38 -0000 On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote: > Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: >> On 06/09/2014 11:33, John-Mark Gurney wrote: >>> Alan Cox wrote this message on Mon, Jun 09, 2014 at 10:30 -0500: >>>> On 06/08/2014 23:22, John-Mark Gurney wrote: >>>>> Alan Cox wrote this message on Sun, Jun 08, 2014 at 20:19 -0500: >>>>>> On 06/08/2014 18:56, John-Mark Gurney wrote: >>>>>>> Alan Cox wrote this message on Sun, Jun 08, 2014 at 12:29 -0500: >>>>>>>> On 06/07/2014 19:39, John-Mark Gurney wrote: >>>>>>>>> Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 = -0500: >>>>>>>>>> On 06/01/2014 03:11, John-Mark Gurney wrote: >>>>>>>>>>> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 = -0500: >>>>>>>>>>>> On 05/30/2014 01:32, John-Mark Gurney wrote: >>>>>>>>>>>>> Olivier Houchard wrote this message on Thu, May 29, 2014 = at 19:38 +0200: >>>>>>>>>>>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd = wrote: >>>>>>>>>>>>>>> On 29 May 2014 10:16, Olivier Houchard = wrote: >>>>>>>>>>>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd = wrote: >>>>>>>>>>>>>>>>> Have you tested this on xscale hardware? >>>>>>>>>>>>>>>> Yeah, my two last commits were an attempt to get the = AVILA kernel to boot >>>>>>>>>>>>>>>> again. >>>>>>>>>>>>>>> Woo! What can I provide to help you do this? :-) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> (Drinks? Food? Donations?) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Drinks and food are always appreciated ;) >>>>>>>>>>>>>> It almost boots for me now, except a few userland = programs gets SIGSEGV or >>>>>>>>>>>>>> SIGILL along the way, trying to figure out why. >>>>>>>>>>>>> Thanks for fixing ddb... I'm getting panic messages = again... bad >>>>>>>>>>>>> news is that my panic is still around: >>>>>>>>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Though, interestingly, it looks like sparc64 has a similar = panic: >>>>>>>>>>>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=3D187080 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> kib, Alan, any clue to why this is happening? Any = suggestions as to >>>>>>>>>>>>> help track it down? >>>>>>>>>>>> I'm afraid not. The dump below shows a perfectly normal, = in-use page.=20 >>>>>>>>>>>> If this page had actually been free prior to the = vm_page_alloc() call, >>>>>>>>>>>> then other fields, like dirty, would have been different. = In other >>>>>>>>>>>> words, this isn't just a problem with the wire count. >>>>>>>>>>>>=20 >>>>>>>>>>>> What object is vm_page_alloc() being performed on? >>>>>>>>>>> Is this enough? Or do you need more? >>>>>>>>>>>=20 >>>>>>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: = 0xc1500b40 >>>>>>>>>>> KDB: enter: panic >>>>>>>>>>> [ thread pid 781 tid 100051 ] >>>>>>>>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror = r15]! >>>>>>>>>>> db> show object/f 0xc1500b40 >>>>>>>>>>> Object 0xc1500b40: type=3D2, size=3D0xa, res=3D9, ref=3D0, = flags=3D0x0 ruid -1 charge 0 >>>>>>>>>>> sref=3D0, backing_object(0)=3D(0)+0x0 >>>>>>>>>>> = memory:=3D(off=3D0x0,page=3D0x8f0000),(off=3D0x1,page=3D0x8f1000),(off=3D0= x2,page=3D0x8ee000),(off=3D0x3,page=3D0x8ef000),(off=3D0x4,page=3D0x8f3000= ),(off=3D0x5,page=3D0x8f4000) >>>>>>>>>>> = ...(off=3D0x6,page=3D0x8fa000),(off=3D0x7,page=3D0x8fb000),(off=3D0x8,page= =3D0x8fc000) >>>>>>>>>>>=20 >>>>>>>>>>> If you need more, let me know what/how to get it, and I = will... >>>>>>>>>>>=20 >>>>>>>>>> Anyone who has seen the "wired page" panic, please try the = attached >>>>>>>>>> patch. It introduces some new KASSERT()s that may help me to = narrow >>>>>>>>>> down the problem. I haven't been able to trigger these = KASSERT()s on >>>>>>>>>> amd64, but the symptoms that you guys are reporting are = consistent with >>>>>>>>>> a bug that would trigger these KASSERT()s. >>>>>>>>> Ok, it triggered the xxx one: >>>>>>>>> Starting sendmail_msp_queue. >>>>>>>>> panic: vm_phys_free_contig: xxx >>>>>>>>> KDB: enter: panic >>>>>>>>> [ thread pid 782 tid 100051 ] >>>>>>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror = r15]! >>>>>>>>> db> bt >>>>>>>>> Tracing pid 782 tid 100051 td 0xc1470000 >>>>>>>>> db_trace_self() at db_trace_self >>>>>>>>> pc =3D 0xc0566ec8 lr =3D 0xc0566f54 = (db_trace_thread+0x50) >>>>>>>>> sp =3D 0xcd830850 fp =3D 0xc03db694 >>>>>>>>> db_trace_thread() at db_trace_thread+0x50 >>>>>>>>> pc =3D 0xc0566f54 lr =3D 0xc022cd14 = (db_command_init+0x620) >>>>>>>>> sp =3D 0xcd8308b0 fp =3D 0xc03db694 >>>>>>>>> db_command_init() at db_command_init+0x620 >>>>>>>>> pc =3D 0xc022cd14 lr =3D 0xc022c3ec = (db_skip_to_eol+0x480) >>>>>>>>> sp =3D 0xcd8308c8 fp =3D 0xc03db694 >>>>>>>>> r4 =3D 0xc0683c30 r5 =3D 0x00000000 >>>>>>>>> db_skip_to_eol() at db_skip_to_eol+0x480 >>>>>>>>> pc =3D 0xc022c3ec lr =3D 0xc022c554 = (db_command_loop+0x5c) >>>>>>>>> sp =3D 0xcd830968 fp =3D 0xc03db694 >>>>>>>>> r4 =3D 0xcd83097c r5 =3D 0xc0683efc >>>>>>>>> r6 =3D 0x00000000 r7 =3D 0x00000000 >>>>>>>>> r8 =3D 0x00000001 r10 =3D 0x600000d3 >>>>>>>>> db_command_loop() at db_command_loop+0x5c >>>>>>>>> pc =3D 0xc022c554 lr =3D 0xc022e99c = (X_db_sym_numargs+0xec) >>>>>>>>> sp =3D 0xcd830970 fp =3D 0xc03db694 >>>>>>>>> X_db_sym_numargs() at X_db_sym_numargs+0xec >>>>>>>>> pc =3D 0xc022e99c lr =3D 0xc03db8c4 (kdb_trap+0x94) >>>>>>>>> sp =3D 0xcd830a88 fp =3D 0xc03db694 >>>>>>>>> r4 =3D 0x00000000 >>>>>>>>> kdb_trap() at kdb_trap+0x94 >>>>>>>>> pc =3D 0xc03db8c4 lr =3D 0xc0578eb0 = (undefinedinstruction+0x2c8) >>>>>>>>> sp =3D 0xcd830aa8 fp =3D 0xc03db694 >>>>>>>>> r4 =3D 0x00000000 r5 =3D 0x00000000 >>>>>>>>> r6 =3D 0x00000000 r7 =3D 0xcd830b20 >>>>>>>>> r8 =3D 0xe7ffffff r10 =3D 0xe7ffffff >>>>>>>>> undefinedinstruction() at undefinedinstruction+0x2c8 >>>>>>>>> pc =3D 0xc0578eb0 lr =3D 0xc0568a0c (exception_exit) >>>>>>>>> sp =3D 0xcd830b20 fp =3D 0xc0613e70 >>>>>>>>> r4 =3D 0xffffffff r5 =3D 0xffff1004 >>>>>>>>> r6 =3D 0xc06d0ebc r7 =3D 0xcd830ba4 >>>>>>>>> r8 =3D 0xc1470000 r9 =3D 0x00000013 >>>>>>>>> r10 =3D 0x00000010 >>>>>>>>> exception_exit() at exception_exit >>>>>>>>> pc =3D 0xc0568a0c lr =3D 0xc03db68c (kdb_enter+0x38) >>>>>>>>> sp =3D 0xcd830b70 fp =3D 0xc0613e70 >>>>>>>>> r0 =3D 0x00000012 r1 =3D 0x60000013 >>>>>>>>> r2 =3D 0xc06df2ac r3 =3D 0xc06d0ee8 >>>>>>>>> r4 =3D 0xc05e5258 r5 =3D 0xc06155e8 >>>>>>>>> r6 =3D 0xc06d0ebc r7 =3D 0xcd830ba4 >>>>>>>>> r8 =3D 0xc1470000 r9 =3D 0x00000013 >>>>>>>>> r10 =3D 0x00000010 r12 =3D 0xc05e2518 >>>>>>>>> kdb_enter() at kdb_enter+0x44 >>>>>>>>> pc =3D 0xc03db698 lr =3D 0xc03aa094 = (kern_reboot+0x948) >>>>>>>>> sp =3D 0xcd830b78 fp =3D 0xc0613e70 >>>>>>>>> r4 =3D 0x00000100 >>>>>>>>> kern_reboot() at kern_reboot+0x948 >>>>>>>>> pc =3D 0xc03aa094 lr =3D 0xc03aa164 = (kassert_panic+0x68) >>>>>>>>> sp =3D 0xcd830b90 fp =3D 0xc0613e70 >>>>>>>>> r4 =3D 0xc06155e8 r5 =3D 0xc07e74a0 >>>>>>>>> r6 =3D 0xc07e6fa0 r7 =3D 0x00000004 >>>>>>>>> r8 =3D 0x00000010 >>>>>>>>> kassert_panic() at kassert_panic+0x68 >>>>>>>>> pc =3D 0xc03aa164 lr =3D 0xc055a0a8 = (vm_phys_free_contig+0x8c) >>>>>>>>> sp =3D 0xcd830bb0 fp =3D 0xc0613e70 >>>>>>>>> r0 =3D 0xc06155e8 r1 =3D 0xc07e6d20 >>>>>>>>> r2 =3D 0xc06e6a70 r3 =3D 0x00000000 >>>>>>>>> r4 =3D 0xc07e73b0 >>>>>>>>> vm_phys_free_contig() at vm_phys_free_contig+0x8c >>>>>>>>> pc =3D 0xc055a0a8 lr =3D 0xc055ca70 = (vm_reserv_startup+0x4bc) >>>>>>>>> sp =3D 0xcd830bd0 fp =3D 0xc0613e70 >>>>>>>>> r4 =3D 0xc08fb2cc r5 =3D 0x00000008 >>>>>>>>> r6 =3D 0x000000e8 r7 =3D 0xc08fb280 >>>>>>>>> r8 =3D 0x00000005 r10 =3D 0x00000001 >>>>>>>>> vm_reserv_startup() at vm_reserv_startup+0x4bc >>>>>>>>> pc =3D 0xc055ca70 lr =3D 0xc055cb40 = (vm_reserv_startup+0x58c) >>>>>>>>> sp =3D 0xcd830be8 fp =3D 0xc0613e70 >>>>>>>>> r4 =3D 0xc08fb280 r5 =3D 0x00000000 >>>>>>>>> r6 =3D 0xc14b7280 r7 =3D 0x00000040 >>>>>>>>> r8 =3D 0x00000000 >>>>>>>>> vm_reserv_startup() at vm_reserv_startup+0x58c >>>>>>>>> pc =3D 0xc055cb40 lr =3D 0xc055ce08 = (vm_reserv_reclaim_inactive+0x34) >>>>>>>>> sp =3D 0xcd830bf0 fp =3D 0xc0613e70 >>>>>>>>> r4 =3D 0xc06e6550 >>>>>>>>> vm_reserv_reclaim_inactive() at = vm_reserv_reclaim_inactive+0x34 >>>>>>>>> pc =3D 0xc055ce08 lr =3D 0xc0554cb8 = (vm_page_alloc+0x280) >>>>>>>>> sp =3D 0xcd830bf8 fp =3D 0xc0613e70 >>>>>>>>> vm_page_alloc() at vm_page_alloc+0x280 >>>>>>>>> pc =3D 0xc0554cb8 lr =3D 0xc0540eb0 = (vm_fault_hold+0x60c) >>>>>>>>> sp =3D 0xcd830c30 fp =3D 0xcd830dac >>>>>>>>> r4 =3D 0xc14b7280 r5 =3D 0xc0618d00 >>>>>>>>> r6 =3D 0xcd830eb0 r7 =3D 0xc1470000 >>>>>>>>> r8 =3D 0xcd830e60 r9 =3D 0x00000000 >>>>>>>>> r10 =3D 0x00000000 >>>>>>>>> vm_fault_hold() at vm_fault_hold+0x60c >>>>>>>>> pc =3D 0xc0540eb0 lr =3D 0xc05426b8 (vm_fault+0x44) >>>>>>>>> sp =3D 0xcd830db0 fp =3D 0x00000002 >>>>>>>>> r4 =3D 0xc14c8a0c r5 =3D 0xc0618d00 >>>>>>>>> r6 =3D 0xcd830eb0 r7 =3D 0xc1470000 >>>>>>>>> r8 =3D 0xcd830e60 r9 =3D 0x00000001 >>>>>>>>> r10 =3D 0x00000000 >>>>>>>>> vm_fault() at vm_fault+0x44 >>>>>>>>> pc =3D 0xc05426b8 lr =3D 0xc05782d0 = (data_abort_handler+0x35c) >>>>>>>>> sp =3D 0xcd830dc0 fp =3D 0x00000002 >>>>>>>>> data_abort_handler() at data_abort_handler+0x35c >>>>>>>>> pc =3D 0xc05782d0 lr =3D 0xc0568a0c (exception_exit) >>>>>>>>> sp =3D 0xcd830dc0 fp =3D 0x00000002 >>>>>>>>> data_abort_handler() at data_abort_handler+0x35c >>>>>>>>> pc =3D 0xc05782d0 lr =3D 0xc0568a0c (exception_exit) >>>>>>>>> sp =3D 0xcd830e60 fp =3D 0x20c43000 >>>>>>>>> r4 =3D 0xffffffff r5 =3D 0xffff1004 >>>>>>>>> r6 =3D 0x00000000 r7 =3D 0x20443740 >>>>>>>>> r8 =3D 0x0009b8e4 r9 =3D 0x00000001 >>>>>>>>> r10 =3D 0x00000004 >>>>>>>>> exception_exit() at exception_exit >>>>>>>>> pc =3D 0xc0568a0c lr =3D 0x204140d0 (0x204140d0) >>>>>>>>> sp =3D 0xcd830eb0 fp =3D 0x20c43000 >>>>>>>>> r0 =3D 0x00000000 r1 =3D 0x20c4302c >>>>>>>>> r2 =3D 0x00000004 r3 =3D 0x00000000 >>>>>>>>> r4 =3D 0x20446190 r5 =3D 0x20c4302c >>>>>>>>> r6 =3D 0x00000000 r7 =3D 0x20443740 >>>>>>>>> r8 =3D 0x0009b8e4 r9 =3D 0x00000001 >>>>>>>>> r10 =3D 0x00000004 r12 =3D 0x00000001 >>>>>>>>> Unable to unwind into user mode >>>>>>>>>=20 >>>>>>>>> Hope this helps, let me know if you need anything else... >>>>>>>>>=20 >>>>>>>> Please try the attached patch. It adds another KASSERT() loop. >>>>>>>>=20 >>>>>>>> Depending on which KASSERT() fires, that will tell us whether = to look >>>>>>>> deeper at this function or its caller for the source of the = problem. >>>>>>> Ok, that panic is: >>>>>>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 >>>>>>>=20 >>>>>>> Let me know if you need any more info... oh, btw, the last %u = needed >>>>>>> to be %lu since it was a u_long, not an unsigned... >>>>>>>=20 >>>>>> Ok. Here is the next debug patch. >>>>> so, it's crashing in the same place: >>>>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 >>>>>=20 >>>>> so, I commented out this KASSERT, and now it panics with: >>>>> panic: vm_phys_free_contig: xxx 0xc07e6fa0 13 16 >>>>>=20 >>>>> so I commented out this KASSERT too, and it panics back w/ the = original >>>>> panic.. So it didn't hit the new KASSERT in vm_reserv_break... >>>> Next patch...It should panic in vm_reserv_break this time and tell = me if >>>> the reservation being broken belongs to the same object as the = inuse >>>> page that is being inappropriately freed. >>> So, bad news... still panics with: >>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 >>>=20 >>> This panic seems to be consistent now, in that the start address is >>> always the same... Is there a way you could add various debugging >>> for this specific vm page to catch a stack trace (stack(9)) where = it's >>> going wrong? =20 >>>=20 >>=20 >> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try = this. >=20 > No worried, the new patch panics: > panic: vm_reserv_break: 2 saved_object=3D0xc06e6378 x=3D253 = m_tmp->object=3D0xc06e6378 (1) >=20 Is your arm processor running in big-endian or little-endian mode? > w/ a bt of: > [...] > vm_reserv_startup() at vm_reserv_startup+0x570 > pc =3D 0xc055cd94 lr =3D 0xc055cec8 (vm_reserv_startup+0x6a4) > sp =3D 0xcd833be8 fp =3D 0xc06142d0 > r4 =3D 0xc08fb280 r5 =3D 0x00000000 > r6 =3D 0xc14b76e0 r7 =3D 0x00000000 > r8 =3D 0x00000000 r9 =3D 0x00000033 > r10 =3D 0x00000001 > vm_reserv_startup() at vm_reserv_startup+0x6a4 > pc =3D 0xc055cec8 lr =3D 0xc055d190 = (vm_reserv_reclaim_inactive+0x34) > sp =3D 0xcd833bf0 fp =3D 0xc06142d0 > r4 =3D 0xc06e6550 > vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 > pc =3D 0xc055d190 lr =3D 0xc0554eb0 (vm_page_alloc+0x280) > sp =3D 0xcd833bf8 fp =3D 0xc06142d0 > vm_page_alloc() at vm_page_alloc+0x280 > pc =3D 0xc0554eb0 lr =3D 0xc0540ebc (vm_fault_hold+0x60c) > sp =3D 0xcd833c30 fp =3D 0xcd833dac > r4 =3D 0xc14b76e0 r5 =3D 0xc0619288 > r6 =3D 0xcd833eb0 r7 =3D 0xc0f7ec80 > r8 =3D 0xcd833e60 r9 =3D 0x00000000 > r10 =3D 0x00000000 > vm_fault_hold() at vm_fault_hold+0x60c > pc =3D 0xc0540ebc lr =3D 0xc05426c4 (vm_fault+0x44) > sp =3D 0xcd833db0 fp =3D 0x00000002 > r4 =3D 0xc14c66ec r5 =3D 0xc0619288 > r6 =3D 0xcd833eb0 r7 =3D 0xc0f7ec80 > r8 =3D 0xcd833e60 r9 =3D 0x00000001 > r10 =3D 0x00000000 > vm_fault() at vm_fault+0x44 > pc =3D 0xc05426c4 lr =3D 0xc05786d0 = (data_abort_handler+0x35c) > sp =3D 0xcd833dc0 fp =3D 0x00000002 > data_abort_handler() at data_abort_handler+0x35c > pc =3D 0xc05786d0 lr =3D 0xc0568dc8 (exception_exit) > sp =3D 0xcd833e60 fp =3D 0x00000000 > r4 =3D 0xffffffff r5 =3D 0xffff1004 > r6 =3D 0x001b7740 r7 =3D 0x00052ec4 > r8 =3D 0x00000000 r9 =3D 0x000cc4b0 > r10 =3D 0x00000000 > exception_exit() at exception_exit > pc =3D 0xc0568dc8 lr =3D 0x203f1208 (0x203f1208) > sp =3D 0xcd833eb0 fp =3D 0x00000000 > r0 =3D 0x20c53e60 r1 =3D 0x00000000 > r2 =3D 0x000eeb40 r3 =3D 0x00000001 > r4 =3D 0x00000000 r5 =3D 0x000e9654 > r6 =3D 0x001b7740 r7 =3D 0x00052ec4 > r8 =3D 0x00000000 r9 =3D 0x000cc4b0 > r10 =3D 0x00000000 r12 =3D 0x200d26a4 >=20 > Let me know if you need any more information.. >=20 > Thanks for tracking this down. >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." >=20 From owner-freebsd-arm@FreeBSD.ORG Mon Jun 9 20:08:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35764EF2 for ; Mon, 9 Jun 2014 20:08:30 +0000 (UTC) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1B622D53 for ; Mon, 9 Jun 2014 20:08:29 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id ma3so5324472pbc.23 for ; Mon, 09 Jun 2014 13:08:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Fz8RW6awg74WTnsGNK2JH5AswgveNMcrJ4RBoiuVKD0=; b=iGsb5Glyy7JGQH1mztIODsRhpN5ROGuPlQPFspkuHvaP8Th2idx1sbNmvCZj7BIwh/ cR/qKFnB9CtNi/M1HEdS5ELfR9m5QWZNAgaFiWgNH9UOF225L2bJQAm1AvgyM+mgKN70 Ob7JXepX5qOCsa6Po/VBHeUuX/SUMgAxithkC/WdzfGh13JvUb7tOAOvCusB1iHke5kk WvWFZnEUDnj3Ks1a/vV0PU0Kty7xWOPhEnoCcw0qg1Vf9jNfy9lZyxMD8in2P6i6J3Fv b1FhQu/rZJjVYUHnEzy//ebn+0JXRKAKvCrRSOcbtQupIj1doK00BAdI8XoOmy2i/dMj FkxA== X-Gm-Message-State: ALoCoQkJnANeQ68EHtoO2zPB7omlsq29NtwA2yTSlQObrL6W2hSFA5dlxTIoKkhyazHVBCVQQDaG X-Received: by 10.66.240.130 with SMTP id wa2mr478519pac.73.1402344503000; Mon, 09 Jun 2014 13:08:23 -0700 (PDT) Received: from lgmac-cvenus.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id xs2sm1440020pab.0.2014.06.09.13.08.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 13:08:22 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_46E1BBD9-7591-4E7F-8C35-B281C680DAD2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa From: Warner Losh In-Reply-To: <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> Date: Mon, 9 Jun 2014 14:08:20 -0600 Message-Id: <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> References: <20140601081153.GU43976@funkthat.com> <53935755.70908@rice.edu> <20140608003944.GK31367@funkthat.com> <53949D96.3060409@rice.edu> <20140608235611.GP31367@funkthat.com> <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> To: Alan Cox X-Mailer: Apple Mail (2.1878.2) Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 20:08:30 -0000 --Apple-Mail=_46E1BBD9-7591-4E7F-8C35-B281C680DAD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 9, 2014, at 1:23 PM, Alan Cox wrote: >=20 > On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote: >=20 >> Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: >>> On 06/09/2014 11:33, John-Mark Gurney wrote: >>>> Alan Cox wrote this message on Mon, Jun 09, 2014 at 10:30 -0500: >>>>> On 06/08/2014 23:22, John-Mark Gurney wrote: >>>>>> Alan Cox wrote this message on Sun, Jun 08, 2014 at 20:19 -0500: >>>>>>> On 06/08/2014 18:56, John-Mark Gurney wrote: >>>>>>>> Alan Cox wrote this message on Sun, Jun 08, 2014 at 12:29 = -0500: >>>>>>>>> On 06/07/2014 19:39, John-Mark Gurney wrote: >>>>>>>>>> Alan Cox wrote this message on Sat, Jun 07, 2014 at 13:17 = -0500: >>>>>>>>>>> On 06/01/2014 03:11, John-Mark Gurney wrote: >>>>>>>>>>>> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 = -0500: >>>>>>>>>>>>> On 05/30/2014 01:32, John-Mark Gurney wrote: >>>>>>>>>>>>>> Olivier Houchard wrote this message on Thu, May 29, 2014 = at 19:38 +0200: >>>>>>>>>>>>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd = wrote: >>>>>>>>>>>>>>>> On 29 May 2014 10:16, Olivier Houchard = wrote: >>>>>>>>>>>>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd = wrote: >>>>>>>>>>>>>>>>>> Have you tested this on xscale hardware? >>>>>>>>>>>>>>>>> Yeah, my two last commits were an attempt to get the = AVILA kernel to boot >>>>>>>>>>>>>>>>> again. >>>>>>>>>>>>>>>> Woo! What can I provide to help you do this? :-) >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> (Drinks? Food? Donations?) >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Drinks and food are always appreciated ;) >>>>>>>>>>>>>>> It almost boots for me now, except a few userland = programs gets SIGSEGV or >>>>>>>>>>>>>>> SIGILL along the way, trying to figure out why. >>>>>>>>>>>>>> Thanks for fixing ddb... I'm getting panic messages = again... bad >>>>>>>>>>>>>> news is that my panic is still around: >>>>>>>>>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Though, interestingly, it looks like sparc64 has a = similar panic: >>>>>>>>>>>>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=3D187080 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> kib, Alan, any clue to why this is happening? Any = suggestions as to >>>>>>>>>>>>>> help track it down? >>>>>>>>>>>>> I'm afraid not. The dump below shows a perfectly normal, = in-use page.=20 >>>>>>>>>>>>> If this page had actually been free prior to the = vm_page_alloc() call, >>>>>>>>>>>>> then other fields, like dirty, would have been different. = In other >>>>>>>>>>>>> words, this isn't just a problem with the wire count. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> What object is vm_page_alloc() being performed on? >>>>>>>>>>>> Is this enough? Or do you need more? >>>>>>>>>>>>=20 >>>>>>>>>>>> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: = 0xc1500b40 >>>>>>>>>>>> KDB: enter: panic >>>>>>>>>>>> [ thread pid 781 tid 100051 ] >>>>>>>>>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror = r15]! >>>>>>>>>>>> db> show object/f 0xc1500b40 >>>>>>>>>>>> Object 0xc1500b40: type=3D2, size=3D0xa, res=3D9, ref=3D0, = flags=3D0x0 ruid -1 charge 0 >>>>>>>>>>>> sref=3D0, backing_object(0)=3D(0)+0x0 >>>>>>>>>>>> = memory:=3D(off=3D0x0,page=3D0x8f0000),(off=3D0x1,page=3D0x8f1000),(off=3D0= x2,page=3D0x8ee000),(off=3D0x3,page=3D0x8ef000),(off=3D0x4,page=3D0x8f3000= ),(off=3D0x5,page=3D0x8f4000) >>>>>>>>>>>> = ...(off=3D0x6,page=3D0x8fa000),(off=3D0x7,page=3D0x8fb000),(off=3D0x8,page= =3D0x8fc000) >>>>>>>>>>>>=20 >>>>>>>>>>>> If you need more, let me know what/how to get it, and I = will... >>>>>>>>>>>>=20 >>>>>>>>>>> Anyone who has seen the "wired page" panic, please try the = attached >>>>>>>>>>> patch. It introduces some new KASSERT()s that may help me = to narrow >>>>>>>>>>> down the problem. I haven't been able to trigger these = KASSERT()s on >>>>>>>>>>> amd64, but the symptoms that you guys are reporting are = consistent with >>>>>>>>>>> a bug that would trigger these KASSERT()s. >>>>>>>>>> Ok, it triggered the xxx one: >>>>>>>>>> Starting sendmail_msp_queue. >>>>>>>>>> panic: vm_phys_free_contig: xxx >>>>>>>>>> KDB: enter: panic >>>>>>>>>> [ thread pid 782 tid 100051 ] >>>>>>>>>> Stopped at kdb_enter+0x40: ldrb r15, [r15, r15, ror = r15]! >>>>>>>>>> db> bt >>>>>>>>>> Tracing pid 782 tid 100051 td 0xc1470000 >>>>>>>>>> db_trace_self() at db_trace_self >>>>>>>>>> pc =3D 0xc0566ec8 lr =3D 0xc0566f54 = (db_trace_thread+0x50) >>>>>>>>>> sp =3D 0xcd830850 fp =3D 0xc03db694 >>>>>>>>>> db_trace_thread() at db_trace_thread+0x50 >>>>>>>>>> pc =3D 0xc0566f54 lr =3D 0xc022cd14 = (db_command_init+0x620) >>>>>>>>>> sp =3D 0xcd8308b0 fp =3D 0xc03db694 >>>>>>>>>> db_command_init() at db_command_init+0x620 >>>>>>>>>> pc =3D 0xc022cd14 lr =3D 0xc022c3ec = (db_skip_to_eol+0x480) >>>>>>>>>> sp =3D 0xcd8308c8 fp =3D 0xc03db694 >>>>>>>>>> r4 =3D 0xc0683c30 r5 =3D 0x00000000 >>>>>>>>>> db_skip_to_eol() at db_skip_to_eol+0x480 >>>>>>>>>> pc =3D 0xc022c3ec lr =3D 0xc022c554 = (db_command_loop+0x5c) >>>>>>>>>> sp =3D 0xcd830968 fp =3D 0xc03db694 >>>>>>>>>> r4 =3D 0xcd83097c r5 =3D 0xc0683efc >>>>>>>>>> r6 =3D 0x00000000 r7 =3D 0x00000000 >>>>>>>>>> r8 =3D 0x00000001 r10 =3D 0x600000d3 >>>>>>>>>> db_command_loop() at db_command_loop+0x5c >>>>>>>>>> pc =3D 0xc022c554 lr =3D 0xc022e99c = (X_db_sym_numargs+0xec) >>>>>>>>>> sp =3D 0xcd830970 fp =3D 0xc03db694 >>>>>>>>>> X_db_sym_numargs() at X_db_sym_numargs+0xec >>>>>>>>>> pc =3D 0xc022e99c lr =3D 0xc03db8c4 (kdb_trap+0x94) >>>>>>>>>> sp =3D 0xcd830a88 fp =3D 0xc03db694 >>>>>>>>>> r4 =3D 0x00000000 >>>>>>>>>> kdb_trap() at kdb_trap+0x94 >>>>>>>>>> pc =3D 0xc03db8c4 lr =3D 0xc0578eb0 = (undefinedinstruction+0x2c8) >>>>>>>>>> sp =3D 0xcd830aa8 fp =3D 0xc03db694 >>>>>>>>>> r4 =3D 0x00000000 r5 =3D 0x00000000 >>>>>>>>>> r6 =3D 0x00000000 r7 =3D 0xcd830b20 >>>>>>>>>> r8 =3D 0xe7ffffff r10 =3D 0xe7ffffff >>>>>>>>>> undefinedinstruction() at undefinedinstruction+0x2c8 >>>>>>>>>> pc =3D 0xc0578eb0 lr =3D 0xc0568a0c (exception_exit) >>>>>>>>>> sp =3D 0xcd830b20 fp =3D 0xc0613e70 >>>>>>>>>> r4 =3D 0xffffffff r5 =3D 0xffff1004 >>>>>>>>>> r6 =3D 0xc06d0ebc r7 =3D 0xcd830ba4 >>>>>>>>>> r8 =3D 0xc1470000 r9 =3D 0x00000013 >>>>>>>>>> r10 =3D 0x00000010 >>>>>>>>>> exception_exit() at exception_exit >>>>>>>>>> pc =3D 0xc0568a0c lr =3D 0xc03db68c (kdb_enter+0x38) >>>>>>>>>> sp =3D 0xcd830b70 fp =3D 0xc0613e70 >>>>>>>>>> r0 =3D 0x00000012 r1 =3D 0x60000013 >>>>>>>>>> r2 =3D 0xc06df2ac r3 =3D 0xc06d0ee8 >>>>>>>>>> r4 =3D 0xc05e5258 r5 =3D 0xc06155e8 >>>>>>>>>> r6 =3D 0xc06d0ebc r7 =3D 0xcd830ba4 >>>>>>>>>> r8 =3D 0xc1470000 r9 =3D 0x00000013 >>>>>>>>>> r10 =3D 0x00000010 r12 =3D 0xc05e2518 >>>>>>>>>> kdb_enter() at kdb_enter+0x44 >>>>>>>>>> pc =3D 0xc03db698 lr =3D 0xc03aa094 = (kern_reboot+0x948) >>>>>>>>>> sp =3D 0xcd830b78 fp =3D 0xc0613e70 >>>>>>>>>> r4 =3D 0x00000100 >>>>>>>>>> kern_reboot() at kern_reboot+0x948 >>>>>>>>>> pc =3D 0xc03aa094 lr =3D 0xc03aa164 = (kassert_panic+0x68) >>>>>>>>>> sp =3D 0xcd830b90 fp =3D 0xc0613e70 >>>>>>>>>> r4 =3D 0xc06155e8 r5 =3D 0xc07e74a0 >>>>>>>>>> r6 =3D 0xc07e6fa0 r7 =3D 0x00000004 >>>>>>>>>> r8 =3D 0x00000010 >>>>>>>>>> kassert_panic() at kassert_panic+0x68 >>>>>>>>>> pc =3D 0xc03aa164 lr =3D 0xc055a0a8 = (vm_phys_free_contig+0x8c) >>>>>>>>>> sp =3D 0xcd830bb0 fp =3D 0xc0613e70 >>>>>>>>>> r0 =3D 0xc06155e8 r1 =3D 0xc07e6d20 >>>>>>>>>> r2 =3D 0xc06e6a70 r3 =3D 0x00000000 >>>>>>>>>> r4 =3D 0xc07e73b0 >>>>>>>>>> vm_phys_free_contig() at vm_phys_free_contig+0x8c >>>>>>>>>> pc =3D 0xc055a0a8 lr =3D 0xc055ca70 = (vm_reserv_startup+0x4bc) >>>>>>>>>> sp =3D 0xcd830bd0 fp =3D 0xc0613e70 >>>>>>>>>> r4 =3D 0xc08fb2cc r5 =3D 0x00000008 >>>>>>>>>> r6 =3D 0x000000e8 r7 =3D 0xc08fb280 >>>>>>>>>> r8 =3D 0x00000005 r10 =3D 0x00000001 >>>>>>>>>> vm_reserv_startup() at vm_reserv_startup+0x4bc >>>>>>>>>> pc =3D 0xc055ca70 lr =3D 0xc055cb40 = (vm_reserv_startup+0x58c) >>>>>>>>>> sp =3D 0xcd830be8 fp =3D 0xc0613e70 >>>>>>>>>> r4 =3D 0xc08fb280 r5 =3D 0x00000000 >>>>>>>>>> r6 =3D 0xc14b7280 r7 =3D 0x00000040 >>>>>>>>>> r8 =3D 0x00000000 >>>>>>>>>> vm_reserv_startup() at vm_reserv_startup+0x58c >>>>>>>>>> pc =3D 0xc055cb40 lr =3D 0xc055ce08 = (vm_reserv_reclaim_inactive+0x34) >>>>>>>>>> sp =3D 0xcd830bf0 fp =3D 0xc0613e70 >>>>>>>>>> r4 =3D 0xc06e6550 >>>>>>>>>> vm_reserv_reclaim_inactive() at = vm_reserv_reclaim_inactive+0x34 >>>>>>>>>> pc =3D 0xc055ce08 lr =3D 0xc0554cb8 = (vm_page_alloc+0x280) >>>>>>>>>> sp =3D 0xcd830bf8 fp =3D 0xc0613e70 >>>>>>>>>> vm_page_alloc() at vm_page_alloc+0x280 >>>>>>>>>> pc =3D 0xc0554cb8 lr =3D 0xc0540eb0 = (vm_fault_hold+0x60c) >>>>>>>>>> sp =3D 0xcd830c30 fp =3D 0xcd830dac >>>>>>>>>> r4 =3D 0xc14b7280 r5 =3D 0xc0618d00 >>>>>>>>>> r6 =3D 0xcd830eb0 r7 =3D 0xc1470000 >>>>>>>>>> r8 =3D 0xcd830e60 r9 =3D 0x00000000 >>>>>>>>>> r10 =3D 0x00000000 >>>>>>>>>> vm_fault_hold() at vm_fault_hold+0x60c >>>>>>>>>> pc =3D 0xc0540eb0 lr =3D 0xc05426b8 (vm_fault+0x44) >>>>>>>>>> sp =3D 0xcd830db0 fp =3D 0x00000002 >>>>>>>>>> r4 =3D 0xc14c8a0c r5 =3D 0xc0618d00 >>>>>>>>>> r6 =3D 0xcd830eb0 r7 =3D 0xc1470000 >>>>>>>>>> r8 =3D 0xcd830e60 r9 =3D 0x00000001 >>>>>>>>>> r10 =3D 0x00000000 >>>>>>>>>> vm_fault() at vm_fault+0x44 >>>>>>>>>> pc =3D 0xc05426b8 lr =3D 0xc05782d0 = (data_abort_handler+0x35c) >>>>>>>>>> sp =3D 0xcd830dc0 fp =3D 0x00000002 >>>>>>>>>> data_abort_handler() at data_abort_handler+0x35c >>>>>>>>>> pc =3D 0xc05782d0 lr =3D 0xc0568a0c (exception_exit) >>>>>>>>>> sp =3D 0xcd830dc0 fp =3D 0x00000002 >>>>>>>>>> data_abort_handler() at data_abort_handler+0x35c >>>>>>>>>> pc =3D 0xc05782d0 lr =3D 0xc0568a0c (exception_exit) >>>>>>>>>> sp =3D 0xcd830e60 fp =3D 0x20c43000 >>>>>>>>>> r4 =3D 0xffffffff r5 =3D 0xffff1004 >>>>>>>>>> r6 =3D 0x00000000 r7 =3D 0x20443740 >>>>>>>>>> r8 =3D 0x0009b8e4 r9 =3D 0x00000001 >>>>>>>>>> r10 =3D 0x00000004 >>>>>>>>>> exception_exit() at exception_exit >>>>>>>>>> pc =3D 0xc0568a0c lr =3D 0x204140d0 (0x204140d0) >>>>>>>>>> sp =3D 0xcd830eb0 fp =3D 0x20c43000 >>>>>>>>>> r0 =3D 0x00000000 r1 =3D 0x20c4302c >>>>>>>>>> r2 =3D 0x00000004 r3 =3D 0x00000000 >>>>>>>>>> r4 =3D 0x20446190 r5 =3D 0x20c4302c >>>>>>>>>> r6 =3D 0x00000000 r7 =3D 0x20443740 >>>>>>>>>> r8 =3D 0x0009b8e4 r9 =3D 0x00000001 >>>>>>>>>> r10 =3D 0x00000004 r12 =3D 0x00000001 >>>>>>>>>> Unable to unwind into user mode >>>>>>>>>>=20 >>>>>>>>>> Hope this helps, let me know if you need anything else... >>>>>>>>>>=20 >>>>>>>>> Please try the attached patch. It adds another KASSERT() = loop. >>>>>>>>>=20 >>>>>>>>> Depending on which KASSERT() fires, that will tell us whether = to look >>>>>>>>> deeper at this function or its caller for the source of the = problem. >>>>>>>> Ok, that panic is: >>>>>>>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 >>>>>>>>=20 >>>>>>>> Let me know if you need any more info... oh, btw, the last %u = needed >>>>>>>> to be %lu since it was a u_long, not an unsigned... >>>>>>>>=20 >>>>>>> Ok. Here is the next debug patch. >>>>>> so, it's crashing in the same place: >>>>>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 >>>>>>=20 >>>>>> so, I commented out this KASSERT, and now it panics with: >>>>>> panic: vm_phys_free_contig: xxx 0xc07e6fa0 13 16 >>>>>>=20 >>>>>> so I commented out this KASSERT too, and it panics back w/ the = original >>>>>> panic.. So it didn't hit the new KASSERT in vm_reserv_break... >>>>> Next patch...It should panic in vm_reserv_break this time and tell = me if >>>>> the reservation being broken belongs to the same object as the = inuse >>>>> page that is being inappropriately freed. >>>> So, bad news... still panics with: >>>> panic: vm_phys_free_contig: start 0xc07e6d20 21 24 >>>>=20 >>>> This panic seems to be consistent now, in that the start address is >>>> always the same... Is there a way you could add various debugging >>>> for this specific vm page to catch a stack trace (stack(9)) where = it's >>>> going wrong? =20 >>>>=20 >>>=20 >>> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try = this. >>=20 >> No worried, the new patch panics: >> panic: vm_reserv_break: 2 saved_object=3D0xc06e6378 x=3D253 = m_tmp->object=3D0xc06e6378 (1) >>=20 >=20 >=20 > Is your arm processor running in big-endian or little-endian mode? Big Endian. Warner >=20 >=20 >> w/ a bt of: >> [...] >> vm_reserv_startup() at vm_reserv_startup+0x570 >> pc =3D 0xc055cd94 lr =3D 0xc055cec8 (vm_reserv_startup+0x6a4) >> sp =3D 0xcd833be8 fp =3D 0xc06142d0 >> r4 =3D 0xc08fb280 r5 =3D 0x00000000 >> r6 =3D 0xc14b76e0 r7 =3D 0x00000000 >> r8 =3D 0x00000000 r9 =3D 0x00000033 >> r10 =3D 0x00000001 >> vm_reserv_startup() at vm_reserv_startup+0x6a4 >> pc =3D 0xc055cec8 lr =3D 0xc055d190 = (vm_reserv_reclaim_inactive+0x34) >> sp =3D 0xcd833bf0 fp =3D 0xc06142d0 >> r4 =3D 0xc06e6550 >> vm_reserv_reclaim_inactive() at vm_reserv_reclaim_inactive+0x34 >> pc =3D 0xc055d190 lr =3D 0xc0554eb0 (vm_page_alloc+0x280) >> sp =3D 0xcd833bf8 fp =3D 0xc06142d0 >> vm_page_alloc() at vm_page_alloc+0x280 >> pc =3D 0xc0554eb0 lr =3D 0xc0540ebc (vm_fault_hold+0x60c) >> sp =3D 0xcd833c30 fp =3D 0xcd833dac >> r4 =3D 0xc14b76e0 r5 =3D 0xc0619288 >> r6 =3D 0xcd833eb0 r7 =3D 0xc0f7ec80 >> r8 =3D 0xcd833e60 r9 =3D 0x00000000 >> r10 =3D 0x00000000 >> vm_fault_hold() at vm_fault_hold+0x60c >> pc =3D 0xc0540ebc lr =3D 0xc05426c4 (vm_fault+0x44) >> sp =3D 0xcd833db0 fp =3D 0x00000002 >> r4 =3D 0xc14c66ec r5 =3D 0xc0619288 >> r6 =3D 0xcd833eb0 r7 =3D 0xc0f7ec80 >> r8 =3D 0xcd833e60 r9 =3D 0x00000001 >> r10 =3D 0x00000000 >> vm_fault() at vm_fault+0x44 >> pc =3D 0xc05426c4 lr =3D 0xc05786d0 = (data_abort_handler+0x35c) >> sp =3D 0xcd833dc0 fp =3D 0x00000002 >> data_abort_handler() at data_abort_handler+0x35c >> pc =3D 0xc05786d0 lr =3D 0xc0568dc8 (exception_exit) >> sp =3D 0xcd833e60 fp =3D 0x00000000 >> r4 =3D 0xffffffff r5 =3D 0xffff1004 >> r6 =3D 0x001b7740 r7 =3D 0x00052ec4 >> r8 =3D 0x00000000 r9 =3D 0x000cc4b0 >> r10 =3D 0x00000000 >> exception_exit() at exception_exit >> pc =3D 0xc0568dc8 lr =3D 0x203f1208 (0x203f1208) >> sp =3D 0xcd833eb0 fp =3D 0x00000000 >> r0 =3D 0x20c53e60 r1 =3D 0x00000000 >> r2 =3D 0x000eeb40 r3 =3D 0x00000001 >> r4 =3D 0x00000000 r5 =3D 0x000e9654 >> r6 =3D 0x001b7740 r7 =3D 0x00052ec4 >> r8 =3D 0x00000000 r9 =3D 0x000cc4b0 >> r10 =3D 0x00000000 r12 =3D 0x200d26a4 >>=20 >> Let me know if you need any more information.. >>=20 >> Thanks for tracking this down. >>=20 >> --=20 >> John-Mark Gurney Voice: +1 415 225 5579 >>=20 >> "All that I will do, has been done, All that I have, has not." >>=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --Apple-Mail=_46E1BBD9-7591-4E7F-8C35-B281C680DAD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTlhQ1AAoJEGwc0Sh9sBEAUtEP/i+J+crpb9rzRBJjV4zbAEN9 HLlhKA48zf7SLSq987hCHrNLqd8yHq7Gi+pkX/0kdooo/QrXFU9nX7+aMgfY/07z 971h/k6YG9VXBkvkBedHbH6tvow1BOKSd4L7szxbsg0bwHvYAtqGKgqrDebXzXtr mfVNqQZ9l4Cf7RoXhJ8roSrQvqbfCSwdYJH8LmgdCpUnDCbugnCRddZ5hBlf79no WwygIisLzUqz+SQw0PvM/xQQBR6DqXOOaHCBaWM7omYWwCVbyBp3WZ8dmAXkJxB5 VUcD3X4bTbmde5a3WaCDDY/GtfhsXio6v9G1aP6pLpVwOUJAYfZroGQ70QOSKXOl szqYCvgec69sPSOI3DYArgMVF7fM+y441hvBeyKfb0eYgC0eX0e1h8C7kQzHy0VZ u3qwnpP5b6LQtBXcKxKniBV82q1mWCqyJJSbAbBLb+DJzUmoqnqGOHR5TonVl1lN 9r4TDFjbnRvQBaK+DJiwZH/AvisNBbAFb23mXyolAyT5w7hYBuobJuDEJSXamk2d jNTIO5h4dSMDShSwKPw8lbL4WF7nk7P+ScB9TKPxxnhKgwuJCtxC1e35eJU4B4uP hYaMUY1qUNg5ahmq9K8FF3cMyM6UUFPSrTp0fUrzvhaoke3Hs2GcCsH8NC5olBlx lzdLY5g10diMIdXAMSue =+NVF -----END PGP SIGNATURE----- --Apple-Mail=_46E1BBD9-7591-4E7F-8C35-B281C680DAD2-- From owner-freebsd-arm@FreeBSD.ORG Mon Jun 9 22:17:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AE90F55; Mon, 9 Jun 2014 22:17:46 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 19575283C; Mon, 9 Jun 2014 22:17:45 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s59MHgpN064770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 15:17:43 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s59MHgiY064769; Mon, 9 Jun 2014 15:17:42 -0700 (PDT) (envelope-from jmg) Date: Mon, 9 Jun 2014 15:17:42 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140609221742.GV31367@funkthat.com> Mail-Followup-To: Warner Losh , Alan Cox , alc@freebsd.org, "freebsd-arm@freebsd.org" References: <53949D96.3060409@rice.edu> <20140608235611.GP31367@funkthat.com> <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 09 Jun 2014 15:17:43 -0700 (PDT) Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" , Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 22:17:46 -0000 Warner Losh wrote this message on Mon, Jun 09, 2014 at 14:08 -0600: > > On Jun 9, 2014, at 1:23 PM, Alan Cox wrote: > > > > > On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote: > > > >> Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: > >>> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this. > >> > >> No worried, the new patch panics: > >> panic: vm_reserv_break: 2 saved_object=0xc06e6378 x=253 m_tmp->object=0xc06e6378 (1) > >> > > > > > > Is your arm processor running in big-endian or little-endian mode? > > Big Endian. Specificly, TARGET_ARCH=armeb... So, ARMv4 in big-endian mode... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Tue Jun 10 06:40:42 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7342F99D for ; Tue, 10 Jun 2014 06:40:42 +0000 (UTC) Received: from up-smx-s1.dmz.det.nsw.edu.au (up-smx-s1.det.nsw.edu.au [153.107.41.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD0D62F84 for ; Tue, 10 Jun 2014 06:40:40 +0000 (UTC) Received: from itfsmtp5.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-smx-s1.dmz.det.nsw.edu.au (8.14.4/8.14.4) with ESMTP id s5A6eTMT023373; Tue, 10 Jun 2014 16:40:29 +1000 Received: from SLPEXHT01.central.det.win (Not Verified[153.107.14.60]) by itfsmtp5.central.det.win with MailMarshal (v6, 9, 9, 4075) id ; Tue, 10 Jun 2014 16:40:28 +1000 Received: from SLPEXHUB01.central.det.win (153.107.14.8) by SLPEXHT01.central.det.win (153.107.14.60) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 10 Jun 2014 16:40:28 +1000 Received: from WPEXCHMBSL1021.central.det.win ([169.254.1.14]) by slpexhub01.central.det.win ([153.107.14.8]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 16:40:28 +1000 From: "Scott, Brian" To: "'Hans Petter Selasky'" Subject: RE: Changes to dwc_otg USB controller code (stable/10) Thread-Topic: Changes to dwc_otg USB controller code (stable/10) Thread-Index: AQHPf92fyxvDvUntT4SsSJgnL9lJH5tgGJ+AgAHxGsD//1m7gIAAASwAgAFzG7CAAmzt8IAAbmm3gAFkCoCAAtaKwA== Date: Tue, 10 Jun 2014 06:40:27 +0000 Message-ID: <7DB382CFB050654DBFF7A39B1F8056EB3321FD1B@WPEXCHMBSL1021.central.det.win> References: <7DB382CFB050654DBFF7A39B1F8056EB3321BE3F@WPEXCHMBSL1021.central.det.win> <538EF145.5020608@selasky.org> <538EF541.9050502@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D1F3@WPEXCHMBSL1021.central.det.win> <539009BB.5030906@selasky.org> <53900AC7.5070402@selasky.org> <53900BC2.3090701@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321D251@WPEXCHMBSL1021.central.det.win> <5390B68B.5070802@selasky.org> <7DB382CFB050654DBFF7A39B1F8056EB3321E3BE@WPEXCHMBSL1021.central.det.win>, <5392BF67.9070306@selasky.org> <3FBCFE32-009B-4CFA-9403-33AF1C3344DB@det.nsw.edu.au> <5394D339.8090700@selasky.org> In-Reply-To: <5394D339.8090700@selasky.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.107.9.240] x-route: TAFECORP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 06:40:42 -0000 Works beautifully. Mouse is smooth, no lost key strokes. Thanks again for the prompt action. Brian -----Original Message----- From: Hans Petter Selasky [mailto:hps@selasky.org]=20 Sent: Monday, 9 June 2014 7:19 AM To: Scott, Brian Cc: arm@freebsd.org Subject: Re: Changes to dwc_otg USB controller code (stable/10) FYI: http://svnweb.freebsd.org/changeset/base/267242 Please test and report any issues. Thank you! --HPS ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-arm@FreeBSD.ORG Tue Jun 10 16:22:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AC1D5B4; Tue, 10 Jun 2014 16:22:22 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE82527E2; Tue, 10 Jun 2014 16:22:21 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s5AGGXxt028072; Tue, 10 Jun 2014 11:22:10 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1mdnrm8a96-1; Tue, 10 Jun 2014 11:22:10 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 3B9D7460110; Tue, 10 Jun 2014 11:22:10 -0500 (CDT) Message-ID: <539730B1.2040900@rice.edu> Date: Tue, 10 Jun 2014 11:22:09 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Warner Losh , alc@freebsd.org, "freebsd-arm@freebsd.org" Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa References: <53949D96.3060409@rice.edu> <20140608235611.GP31367@funkthat.com> <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> <20140609221742.GV31367@funkthat.com> In-Reply-To: <20140609221742.GV31367@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------000600030207070805040206" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=11 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406100196 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:22:22 -0000 This is a multi-part message in MIME format. --------------000600030207070805040206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/09/2014 17:17, John-Mark Gurney wrote: > Warner Losh wrote this message on Mon, Jun 09, 2014 at 14:08 -0600: >> On Jun 9, 2014, at 1:23 PM, Alan Cox wrote: >> >>> On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote: >>> >>>> Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: >>>>> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this. >>>> No worried, the new patch panics: >>>> panic: vm_reserv_break: 2 saved_object=0xc06e6378 x=253 m_tmp->object=0xc06e6378 (1) >>>> >>> >>> Is your arm processor running in big-endian or little-endian mode? >> Big Endian. > Specificly, TARGET_ARCH=armeb... So, ARMv4 in big-endian mode... > Please try the attached patch. --------------000600030207070805040206 Content-Type: text/plain; charset=ISO-8859-15; name="arm_debug9.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_debug9.patch" Index: vm/vm_phys.c =================================================================== --- vm/vm_phys.c (revision 267282) +++ vm/vm_phys.c (working copy) @@ -693,9 +693,16 @@ vm_phys_free_pages(vm_page_t m, int order) void vm_phys_free_contig(vm_page_t m, u_long npages) { + vm_page_t m_tmp; u_int n; int order; + for (m_tmp = m; m_tmp < &m[npages]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: start %p %td %lu", + m, m_tmp - m, npages)); + /* * Avoid unnecessary coalescing by freeing the pages in the largest * possible power-of-two-sized subsets. @@ -714,6 +721,11 @@ vm_phys_free_contig(vm_page_t m, u_long npages) n = 1 << order; if (npages < n) break; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: xxx %p %td %u", + m, m_tmp - m, n)); vm_phys_free_pages(m, order); m += n; } @@ -721,6 +733,11 @@ vm_phys_free_contig(vm_page_t m, u_long npages) for (; npages > 0; npages -= n) { order = flsl(npages) - 1; n = 1 << order; + for (m_tmp = m; m_tmp < &m[n]; m_tmp++) + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_phys_free_contig: yyy %p %td %u", + m, m_tmp - m, n)); vm_phys_free_pages(m, order); m += n; } Index: vm/vm_reserv.c =================================================================== --- vm/vm_reserv.c (revision 267282) +++ vm/vm_reserv.c (working copy) @@ -108,6 +108,18 @@ typedef u_long popmap_t; #define NPOPMAP howmany(VM_LEVEL_0_NPAGES, NBPOPMAP) /* + * XXX + */ +#undef setbit +#define setbit(a,i) ((a)[(i) / NBPOPMAP] |= 1UL << ((i) % NBPOPMAP)) +#undef clrbit +#define clrbit(a,i) ((a)[(i) / NBPOPMAP] &= ~(1UL << ((i) % NBPOPMAP))) +#undef isset +#define isset(a,i) ((a)[(i) / NBPOPMAP] & (1UL << ((i) % NBPOPMAP))) +#undef isclr +#define isclr(a,i) (((a)[(i) / NBPOPMAP] & (1UL << ((i) % NBPOPMAP))) == 0) + +/* * The reservation structure * * A reservation structure is constructed whenever a large physical page is @@ -646,7 +658,8 @@ found: static void vm_reserv_break(vm_reserv_t rv, vm_page_t m) { - int begin_zeroes, hi, i, lo; + int begin_zeroes, hi, i, lo, x; + vm_object_t saved_object; mtx_assert(&vm_page_queue_free_mtx, MA_OWNED); KASSERT(rv->object != NULL, @@ -653,6 +666,7 @@ vm_reserv_break(vm_reserv_t rv, vm_page_t m) ("vm_reserv_break: reserv %p is free", rv)); KASSERT(!rv->inpartpopq, ("vm_reserv_break: reserv %p's inpartpopq is TRUE", rv)); + saved_object = rv->object; LIST_REMOVE(rv, objq); rv->object = NULL; if (m != NULL) { @@ -703,6 +717,19 @@ vm_reserv_break(vm_reserv_t rv, vm_page_t m) if (i != NPOPMAP) /* Convert from ffsl() to ordinary bit numbering. */ hi--; + for (x = begin_zeroes; x < NBPOPMAP * i + hi; x++) { + vm_page_t m_tmp = &rv->pages[x]; + KASSERT(isclr(rv->popmap, x), + ("vm_reserv_break: 1 saved_object=%p x=%d m_tmp->object=%p (%d)", + saved_object, x, m_tmp->object, m_tmp->object == kmem_object)); + } + for (x = begin_zeroes; x < NBPOPMAP * i + hi; x++) { + vm_page_t m_tmp = &rv->pages[x]; + KASSERT(m_tmp->object == NULL || + (m_tmp->flags & PG_CACHED) != 0, + ("vm_reserv_break: 2 saved_object=%p x=%d m_tmp->object=%p (%d)", + saved_object, x, m_tmp->object, m_tmp->object == kmem_object)); + } vm_phys_free_contig(&rv->pages[begin_zeroes], NBPOPMAP * i + hi - begin_zeroes); } while (i < NPOPMAP); --------------000600030207070805040206-- From owner-freebsd-arm@FreeBSD.ORG Tue Jun 10 17:00:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0F22138; Tue, 10 Jun 2014 17:00:55 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EA9E2B6E; Tue, 10 Jun 2014 17:00:55 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5AH0qCn079880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 10:00:53 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5AH0qBM079879; Tue, 10 Jun 2014 10:00:52 -0700 (PDT) (envelope-from jmg) Date: Tue, 10 Jun 2014 10:00:52 -0700 From: John-Mark Gurney To: Alan Cox Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140610170052.GF31367@funkthat.com> Mail-Followup-To: Alan Cox , Warner Losh , alc@freebsd.org, "freebsd-arm@freebsd.org" References: <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> <20140609221742.GV31367@funkthat.com> <539730B1.2040900@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539730B1.2040900@rice.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 10 Jun 2014 10:00:53 -0700 (PDT) Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:00:55 -0000 Alan Cox wrote this message on Tue, Jun 10, 2014 at 11:22 -0500: > On 06/09/2014 17:17, John-Mark Gurney wrote: > > Warner Losh wrote this message on Mon, Jun 09, 2014 at 14:08 -0600: > >> On Jun 9, 2014, at 1:23 PM, Alan Cox wrote: > >> > >>> On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote: > >>> > >>>> Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: > >>>>> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this. > >>>> No worried, the new patch panics: > >>>> panic: vm_reserv_break: 2 saved_object=0xc06e6378 x=253 m_tmp->object=0xc06e6378 (1) > >>>> > >>> > >>> Is your arm processor running in big-endian or little-endian mode? > >> Big Endian. > > Specificly, TARGET_ARCH=armeb... So, ARMv4 in big-endian mode... > > > > Please try the attached patch. This patch now boots to multiuser mode and I can log in! I can now more easily debug newsyslog segfaulting and stuff... I'll let you know if I have any more issues... Thanks again for tracking this down! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Tue Jun 10 17:19:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B512D72; Tue, 10 Jun 2014 17:19:12 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE3D12CE1; Tue, 10 Jun 2014 17:19:11 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s5AHHDqU001259; Tue, 10 Jun 2014 12:19:06 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp1.rice.edu with ESMTP id 1mdfu4rm1w-1; Tue, 10 Jun 2014 12:19:05 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 74C4D460196; Tue, 10 Jun 2014 12:19:05 -0500 (CDT) Message-ID: <53973E09.2040702@rice.edu> Date: Tue, 10 Jun 2014 12:19:05 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Warner Losh , alc@freebsd.org, "freebsd-arm@freebsd.org" Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa References: <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> <20140609221742.GV31367@funkthat.com> <539730B1.2040900@rice.edu> <20140610170052.GF31367@funkthat.com> In-Reply-To: <20140610170052.GF31367@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406100208 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:19:12 -0000 On 06/10/2014 12:00, John-Mark Gurney wrote: > Alan Cox wrote this message on Tue, Jun 10, 2014 at 11:22 -0500: >> On 06/09/2014 17:17, John-Mark Gurney wrote: >>> Warner Losh wrote this message on Mon, Jun 09, 2014 at 14:08 -0600: >>>> On Jun 9, 2014, at 1:23 PM, Alan Cox wrote: >>>> >>>>> On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote: >>>>> >>>>>> Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: >>>>>>> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this. >>>>>> No worried, the new patch panics: >>>>>> panic: vm_reserv_break: 2 saved_object=0xc06e6378 x=253 m_tmp->object=0xc06e6378 (1) >>>>>> >>>>> Is your arm processor running in big-endian or little-endian mode? >>>> Big Endian. >>> Specificly, TARGET_ARCH=armeb... So, ARMv4 in big-endian mode... >>> >> Please try the attached patch. > This patch now boots to multiuser mode and I can log in! > > I can now more easily debug newsyslog segfaulting and stuff... I'll > let you know if I have any more issues... > > Thanks again for tracking this down! > You made it very, very easy for me to finally figure out what was going on. You also said some things, like "low memory", that got me looking in the right place. I'll prepare a commit-able patch as soon as time permits and send it to you for pre-commit testing. From owner-freebsd-arm@FreeBSD.ORG Tue Jun 10 19:34:27 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BE28A7D for ; Tue, 10 Jun 2014 19:34:27 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30A392AD0 for ; Tue, 10 Jun 2014 19:34:26 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WuRoK-000H7X-B4; Tue, 10 Jun 2014 19:34:20 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5AJYHoB001529; Tue, 10 Jun 2014 13:34:17 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+d/L45kXvxkX+ki0gObU3j Subject: Re: Compilation for ARM From: Ian Lepore To: Stepan Dyatkovskiy In-Reply-To: <5393FF7B.4020407@narod.ru> References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Jun 2014 13:34:17 -0600 Message-ID: <1402428857.20883.177.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:34:27 -0000 On Sun, 2014-06-08 at 12:15 +0600, Stepan Dyatkovskiy wrote: > Hi Tim, > Thank you for quick response! > I will try your advices straight after weekends. > We are using pandaboard. Are here any other cortex-a9/a15 boards that > has, perhaps, better support in FreeBSD OS? If so, we ready to test it > too, because the only thing we need in pandaboard for now is its CPU. > > Thanks! > -Stepan I think the TI OMAP/AM335x chip probably has the best cortex a9 freebsd support right now. Second would probably be the freescale imx6 family, mainly because we use it where I work so I get paid to support it. But the TI support has been around for a lot longer than imx6 and is more mature right now. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Jun 10 23:38:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B06F82CA for ; Tue, 10 Jun 2014 23:38:04 +0000 (UTC) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 832912F60 for ; Tue, 10 Jun 2014 23:38:04 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id jt11so6719188pbb.22 for ; Tue, 10 Jun 2014 16:37:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=AiGnE/zTLPWDwdy2I+uNM0WGgvasPtn5gwG6OGV/+gI=; b=dAmVb+s0Ol2WRij6dxwFoffhuL8fzsvKuifIC6cxS3Z4twDNXJoBrYleWp3Otod1jT 0b/ELK1uZmcrw4x4r7R9CcrJsb4Rqg7uIfeX8BUYjh7XeOcbhxPQWkS+l9AiSxkGjv6q sD232IOYanIrAJ2zo6s9ZvZPn8m0C+NiM6GQqlEJBLVx9MY3SoyEPQ8auX9Qna23+Aok CTNWzYp4kSfGdtpwyM03K84xGdl28p01ShvzJmp5LG/VgPGI1QqG0DZHSDJJdfst3vYM 8yf+GAFRBtJyFuIW++Sn2fTPppALWtbN9OlCVWosLw8+dFLUcbt6qjdPw91qYt5v64as P+4A== X-Gm-Message-State: ALoCoQnZ45wEMAr8m7v4PnpYJKJj8IN7+Oq9Is4+/d7i2voMAdSVjy3LfAPHcTQoeHRJQicvePNG X-Received: by 10.66.142.135 with SMTP id rw7mr8873709pab.71.1402443164400; Tue, 10 Jun 2014 16:32:44 -0700 (PDT) Received: from [192.168.1.2] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id kl10sm259679pbd.20.2014.06.10.16.32.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 16:32:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: Compilation for ARM From: Tim Kientzle In-Reply-To: <1402428857.20883.177.camel@revolution.hippie.lan> Date: Tue, 10 Jun 2014 16:31:57 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0292EAB5-F536-464D-9BF7-C4CA9B72639D@kientzle.com> References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 23:38:04 -0000 On Jun 10, 2014, at 12:34 PM, Ian Lepore wrote: > On Sun, 2014-06-08 at 12:15 +0600, Stepan Dyatkovskiy wrote: >> Hi Tim, >> Thank you for quick response! >> I will try your advices straight after weekends. >> We are using pandaboard. Are here any other cortex-a9/a15 boards that >> has, perhaps, better support in FreeBSD OS? If so, we ready to test it >> too, because the only thing we need in pandaboard for now is its CPU. >> >> Thanks! >> -Stepan > > I think the TI OMAP/AM335x chip probably has the best cortex a9 freebsd > support right now. The AM335x is Cortex-A8. If that suffices, I would recommend looking at the BeagleBone Black as one of the best-supported boards for FreeBSD right now. > Second would probably be the freescale imx6 family, > mainly because we use it where I work so I get paid to support it. But > the TI support has been around for a lot longer than imx6 and is more > mature right now. > > -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jun 11 06:00:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68503807; Wed, 11 Jun 2014 06:00:46 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23E982BF9; Wed, 11 Jun 2014 06:00:45 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s5B60G4F030701; Wed, 11 Jun 2014 01:00:43 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1megh0806r-1; Wed, 11 Jun 2014 01:00:42 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 39DED460110; Wed, 11 Jun 2014 01:00:42 -0500 (CDT) Message-ID: <5397F089.90403@rice.edu> Date: Wed, 11 Jun 2014 01:00:41 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Warner Losh , alc@freebsd.org, "freebsd-arm@freebsd.org" Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa References: <53950BB9.3090808@rice.edu> <20140609042206.GQ31367@funkthat.com> <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> <20140609221742.GV31367@funkthat.com> <539730B1.2040900@rice.edu> <20140610170052.GF31367@funkthat.com> In-Reply-To: <20140610170052.GF31367@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------040803000403060807040002" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=8.27792390190041e-10 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=11 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406110081 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 06:00:46 -0000 This is a multi-part message in MIME format. --------------040803000403060807040002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/10/2014 12:00, John-Mark Gurney wrote: > Alan Cox wrote this message on Tue, Jun 10, 2014 at 11:22 -0500: >> On 06/09/2014 17:17, John-Mark Gurney wrote: >>> Warner Losh wrote this message on Mon, Jun 09, 2014 at 14:08 -0600: >>>> On Jun 9, 2014, at 1:23 PM, Alan Cox wrote: >>>> >>>>> On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote: >>>>> >>>>>> Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: >>>>>>> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this. >>>>>> No worried, the new patch panics: >>>>>> panic: vm_reserv_break: 2 saved_object=0xc06e6378 x=253 m_tmp->object=0xc06e6378 (1) >>>>>> >>>>> Is your arm processor running in big-endian or little-endian mode? >>>> Big Endian. >>> Specificly, TARGET_ARCH=armeb... So, ARMv4 in big-endian mode... >>> >> Please try the attached patch. > This patch now boots to multiuser mode and I can log in! > > I can now more easily debug newsyslog segfaulting and stuff... I'll > let you know if I have any more issues... > > Thanks again for tracking this down! > Here is a commit-able patch. Please tell me if it works. Alan --------------040803000403060807040002 Content-Type: text/plain; charset=ISO-8859-15; name="arm_final2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_final2.patch" Index: vm/vm_reserv.c =================================================================== --- vm/vm_reserv.c (revision 267282) +++ vm/vm_reserv.c (working copy) @@ -108,6 +108,46 @@ typedef u_long popmap_t; #define NPOPMAP howmany(VM_LEVEL_0_NPAGES, NBPOPMAP) /* + * Clear a bit in the population map. + */ +static __inline void +popmap_clear(popmap_t popmap[], int i) +{ + + popmap[i / NBPOPMAP] &= ~(1UL << (i % NBPOPMAP)); +} + +/* + * Set a bit in the population map. + */ +static __inline void +popmap_set(popmap_t popmap[], int i) +{ + + popmap[i / NBPOPMAP] |= 1UL << (i % NBPOPMAP); +} + +/* + * Is a bit in the population map clear? + */ +static __inline boolean_t +popmap_is_clear(popmap_t popmap[], int i) +{ + + return ((popmap[i / NBPOPMAP] & (1UL << (i % NBPOPMAP))) == 0); +} + +/* + * Is a bit in the population map set? + */ +static __inline boolean_t +popmap_is_set(popmap_t popmap[], int i) +{ + + return ((popmap[i / NBPOPMAP] & (1UL << (i % NBPOPMAP))) != 0); +} + +/* * The reservation structure * * A reservation structure is constructed whenever a large physical page is @@ -241,7 +281,7 @@ vm_reserv_depopulate(vm_reserv_t rv, int index) mtx_assert(&vm_page_queue_free_mtx, MA_OWNED); KASSERT(rv->object != NULL, ("vm_reserv_depopulate: reserv %p is free", rv)); - KASSERT(isset(rv->popmap, index), + KASSERT(popmap_is_set(rv->popmap, index), ("vm_reserv_depopulate: reserv %p's popmap[%d] is clear", rv, index)); KASSERT(rv->popcnt > 0, @@ -255,7 +295,7 @@ vm_reserv_depopulate(vm_reserv_t rv, int index) rv)); rv->pages->psind = 0; } - clrbit(rv->popmap, index); + popmap_clear(rv->popmap, index); rv->popcnt--; if (rv->popcnt == 0) { LIST_REMOVE(rv, objq); @@ -302,7 +342,7 @@ vm_reserv_populate(vm_reserv_t rv, int index) mtx_assert(&vm_page_queue_free_mtx, MA_OWNED); KASSERT(rv->object != NULL, ("vm_reserv_populate: reserv %p is free", rv)); - KASSERT(isclr(rv->popmap, index), + KASSERT(popmap_is_clear(rv->popmap, index), ("vm_reserv_populate: reserv %p's popmap[%d] is set", rv, index)); KASSERT(rv->popcnt < VM_LEVEL_0_NPAGES, @@ -313,7 +353,7 @@ vm_reserv_populate(vm_reserv_t rv, int index) TAILQ_REMOVE(&vm_rvq_partpop, rv, partpopq); rv->inpartpopq = FALSE; } - setbit(rv->popmap, index); + popmap_set(rv->popmap, index); rv->popcnt++; if (rv->popcnt < VM_LEVEL_0_NPAGES) { rv->inpartpopq = TRUE; @@ -503,7 +543,7 @@ found: return (NULL); /* Handle vm_page_rename(m, new_object, ...). */ for (i = 0; i < npages; i++) - if (isset(rv->popmap, index + i)) + if (popmap_is_set(rv->popmap, index + i)) return (NULL); for (i = 0; i < npages; i++) vm_reserv_populate(rv, index + i); @@ -628,7 +668,7 @@ found: index = VM_RESERV_INDEX(object, pindex); m = &rv->pages[index]; /* Handle vm_page_rename(m, new_object, ...). */ - if (isset(rv->popmap, index)) + if (popmap_is_set(rv->popmap, index)) return (NULL); vm_reserv_populate(rv, index); return (m); @@ -662,9 +702,9 @@ vm_reserv_break(vm_reserv_t rv, vm_page_t m) * to the physical memory allocator. */ i = m - rv->pages; - KASSERT(isclr(rv->popmap, i), + KASSERT(popmap_is_clear(rv->popmap, i), ("vm_reserv_break: reserv %p's popmap is corrupted", rv)); - setbit(rv->popmap, i); + popmap_set(rv->popmap, i); rv->popcnt++; } i = hi = 0; --------------040803000403060807040002-- From owner-freebsd-arm@FreeBSD.ORG Wed Jun 11 07:42:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFCFB37F; Wed, 11 Jun 2014 07:42:06 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C5B382483; Wed, 11 Jun 2014 07:42:06 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5B7fxEN091743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 00:41:59 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5B7fxj4091742; Wed, 11 Jun 2014 00:41:59 -0700 (PDT) (envelope-from jmg) Date: Wed, 11 Jun 2014 00:41:59 -0700 From: John-Mark Gurney To: Alan Cox Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140611074159.GL31367@funkthat.com> Mail-Followup-To: Alan Cox , alc@freebsd.org, "freebsd-arm@freebsd.org" , ian@FreeBSD.org References: <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> <20140609221742.GV31367@funkthat.com> <539730B1.2040900@rice.edu> <20140610170052.GF31367@funkthat.com> <5397F089.90403@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5397F089.90403@rice.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 11 Jun 2014 00:42:00 -0700 (PDT) Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" , ian@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 07:42:07 -0000 Alan Cox wrote this message on Wed, Jun 11, 2014 at 01:00 -0500: > On 06/10/2014 12:00, John-Mark Gurney wrote: > > Alan Cox wrote this message on Tue, Jun 10, 2014 at 11:22 -0500: > >> On 06/09/2014 17:17, John-Mark Gurney wrote: > >>> Warner Losh wrote this message on Mon, Jun 09, 2014 at 14:08 -0600: > >>>> On Jun 9, 2014, at 1:23 PM, Alan Cox wrote: > >>>> > >>>>> On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote: > >>>>> > >>>>>> Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: > >>>>>>> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this. > >>>>>> No worried, the new patch panics: > >>>>>> panic: vm_reserv_break: 2 saved_object=0xc06e6378 x=253 m_tmp->object=0xc06e6378 (1) > >>>>>> > >>>>> Is your arm processor running in big-endian or little-endian mode? > >>>> Big Endian. > >>> Specificly, TARGET_ARCH=armeb... So, ARMv4 in big-endian mode... > >>> > >> Please try the attached patch. > > This patch now boots to multiuser mode and I can log in! > > > > I can now more easily debug newsyslog segfaulting and stuff... I'll > > let you know if I have any more issues... > > > > Thanks again for tracking this down! > > > > Here is a commit-able patch. Please tell me if it works. So, it worked for a while, but it looks like there are still lingering bugs... Not sure if this is the same, or different... While doing portsnap extract, I got the following panic: panic: Lock vm object not exclusively locked @ /usr/src.avila/sys/arm/arm/pmap.c:4474 w/ the bt: [lots of boiler plate panic backtrace deleted] kassert_panic() at kassert_panic pc = 0xc03ac2d4 lr = 0xc03a9980 (__rw_assert+0x168) sp = 0xcd157d78 fp = 0x00000000 r0 = 0xc05e41f8 r1 = 0xc0617ab0 r2 = 0xc061c818 r3 = 0x0000117a r4 = 0x00000000 __rw_assert() at __rw_assert+0x168 pc = 0xc03a9980 lr = 0xc05736a4 (pmap_remove_write+0x3c) sp = 0xcd157d88 fp = 0x00000000 r4 = 0xc0845a50 pmap_remove_write() at pmap_remove_write+0x3c pc = 0xc05736a4 lr = 0xc0574890 (pmap_remove_all+0x4c) sp = 0xcd157d90 fp = 0x00000000 r4 = 0xc0845a50 pmap_remove_all() at pmap_remove_all+0x4c pc = 0xc0574890 lr = 0xc055abf8 (vm_pageout_grow_cache+0x8b0) sp = 0xcd157dc0 fp = 0x00000000 r4 = 0xc0845a50 r5 = 0xc184dd20 r6 = 0xc14b8a9c r7 = 0x00000000 r8 = 0xc06ea5d0 r9 = 0xc14b89e0 r10 = 0xc184dd20 vm_pageout_grow_cache() at vm_pageout_grow_cache+0x8b0 pc = 0xc055abf8 lr = 0xc055af9c (vm_pageout_grow_cache+0xc54) sp = 0xcd157df0 fp = 0x00000000 r4 = 0xc14b89e0 r5 = 0xc1853320 r6 = 0xc0618cd8 r7 = 0xc184dd20 r8 = 0xc14ea320 r9 = 0xc14b89e0 r10 = 0xc14b89e0 vm_pageout_grow_cache() at vm_pageout_grow_cache+0xc54 pc = 0xc055af9c lr = 0xc037fa30 (fork_exit+0x94) sp = 0xcd157e48 fp = 0x00000000 r4 = 0xc0f83960 r5 = 0xc0e58000 r6 = 0xc055ac9c r7 = 0x00000000 r8 = 0xcd157e60 r9 = 0x19999990 r10 = 0x00000000 fork_exit() at fork_exit+0x94 pc = 0xc037fa30 lr = 0xc056c4e4 (swi_exit) sp = 0xcd157e60 fp = 0x00000000 r4 = 0xc055ac9c r5 = 0x00000000 r6 = 0x1284378c r7 = 0x00000104 r8 = 0x00000104 swi_exit() at swi_exit pc = 0xc056c4e4 lr = 0xc056c4e4 (swi_exit) sp = 0xcd157e60 fp = 0x00000000 Unable to unwind further Let me know if there is any thing else you need to collect... I've rebooted the machine, and I'll be doing the same command to see if it's reproducable... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Jun 11 16:45:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B58B646; Wed, 11 Jun 2014 16:45:59 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA67A2B6B; Wed, 11 Jun 2014 16:45:58 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s5BGfYRb007954; Wed, 11 Jun 2014 11:45:50 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp1.rice.edu with ESMTP id 1megfvr7ke-1; Wed, 11 Jun 2014 11:45:49 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 6704E500158; Wed, 11 Jun 2014 11:45:49 -0500 (CDT) Message-ID: <539887BD.2090408@rice.edu> Date: Wed, 11 Jun 2014 11:45:49 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: alc@freebsd.org, "freebsd-arm@freebsd.org" , ian@FreeBSD.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa References: <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> <20140609221742.GV31367@funkthat.com> <539730B1.2040900@rice.edu> <20140610170052.GF31367@funkthat.com> <5397F089.90403@rice.edu> <20140611074159.GL31367@funkthat.com> In-Reply-To: <20140611074159.GL31367@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------090707050109010501090800" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.713890987064109 urlsuspect_oldscore=0.713890987064109 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.713890987064109 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406110209 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:45:59 -0000 This is a multi-part message in MIME format. --------------090707050109010501090800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/11/2014 02:41, John-Mark Gurney wrote: > Alan Cox wrote this message on Wed, Jun 11, 2014 at 01:00 -0500: >> On 06/10/2014 12:00, John-Mark Gurney wrote: >>> Alan Cox wrote this message on Tue, Jun 10, 2014 at 11:22 -0500: >>>> On 06/09/2014 17:17, John-Mark Gurney wrote: >>>>> Warner Losh wrote this message on Mon, Jun 09, 2014 at 14:08 -0600: >>>>>> On Jun 9, 2014, at 1:23 PM, Alan Cox wrote: >>>>>> >>>>>>> On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote: >>>>>>> >>>>>>>> Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: >>>>>>>>> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this. >>>>>>>> No worried, the new patch panics: >>>>>>>> panic: vm_reserv_break: 2 saved_object=0xc06e6378 x=253 m_tmp->object=0xc06e6378 (1) >>>>>>>> >>>>>>> Is your arm processor running in big-endian or little-endian mode? >>>>>> Big Endian. >>>>> Specificly, TARGET_ARCH=armeb... So, ARMv4 in big-endian mode... >>>>> >>>> Please try the attached patch. >>> This patch now boots to multiuser mode and I can log in! >>> >>> I can now more easily debug newsyslog segfaulting and stuff... I'll >>> let you know if I have any more issues... >>> >>> Thanks again for tracking this down! >>> >> Here is a commit-able patch. Please tell me if it works. > So, it worked for a while, but it looks like there are still lingering > bugs... Not sure if this is the same, or different... This is an entirely different problem. It's also a much simpler problem. A simple workaround patch is attached. Go ahead and commit this patch yourself if it helps. > While doing portsnap extract, I got the following panic: > panic: Lock vm object not exclusively locked @ /usr/src.avila/sys/arm/arm/pmap.c:4474 > > w/ the bt: > [lots of boiler plate panic backtrace deleted] > kassert_panic() at kassert_panic > pc = 0xc03ac2d4 lr = 0xc03a9980 (__rw_assert+0x168) > sp = 0xcd157d78 fp = 0x00000000 > r0 = 0xc05e41f8 r1 = 0xc0617ab0 > r2 = 0xc061c818 r3 = 0x0000117a > r4 = 0x00000000 > __rw_assert() at __rw_assert+0x168 > pc = 0xc03a9980 lr = 0xc05736a4 (pmap_remove_write+0x3c) > sp = 0xcd157d88 fp = 0x00000000 > r4 = 0xc0845a50 > pmap_remove_write() at pmap_remove_write+0x3c > pc = 0xc05736a4 lr = 0xc0574890 (pmap_remove_all+0x4c) > sp = 0xcd157d90 fp = 0x00000000 > r4 = 0xc0845a50 > pmap_remove_all() at pmap_remove_all+0x4c > pc = 0xc0574890 lr = 0xc055abf8 (vm_pageout_grow_cache+0x8b0) > sp = 0xcd157dc0 fp = 0x00000000 > r4 = 0xc0845a50 r5 = 0xc184dd20 > r6 = 0xc14b8a9c r7 = 0x00000000 > r8 = 0xc06ea5d0 r9 = 0xc14b89e0 > r10 = 0xc184dd20 > vm_pageout_grow_cache() at vm_pageout_grow_cache+0x8b0 > pc = 0xc055abf8 lr = 0xc055af9c (vm_pageout_grow_cache+0xc54) > sp = 0xcd157df0 fp = 0x00000000 > r4 = 0xc14b89e0 r5 = 0xc1853320 > r6 = 0xc0618cd8 r7 = 0xc184dd20 > r8 = 0xc14ea320 r9 = 0xc14b89e0 > r10 = 0xc14b89e0 > vm_pageout_grow_cache() at vm_pageout_grow_cache+0xc54 > pc = 0xc055af9c lr = 0xc037fa30 (fork_exit+0x94) > sp = 0xcd157e48 fp = 0x00000000 > r4 = 0xc0f83960 r5 = 0xc0e58000 > r6 = 0xc055ac9c r7 = 0x00000000 > r8 = 0xcd157e60 r9 = 0x19999990 > r10 = 0x00000000 > fork_exit() at fork_exit+0x94 > pc = 0xc037fa30 lr = 0xc056c4e4 (swi_exit) > sp = 0xcd157e60 fp = 0x00000000 > r4 = 0xc055ac9c r5 = 0x00000000 > r6 = 0x1284378c r7 = 0x00000104 > r8 = 0x00000104 > swi_exit() at swi_exit > pc = 0xc056c4e4 lr = 0xc056c4e4 (swi_exit) > sp = 0xcd157e60 fp = 0x00000000 > Unable to unwind further > > Let me know if there is any thing else you need to collect... I've > rebooted the machine, and I'll be doing the same command to see if > it's reproducable... > --------------090707050109010501090800 Content-Type: text/plain; charset=ISO-8859-15; name="arm_pmap_remove_all.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_pmap_remove_all.patch" Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 267282) +++ arm/arm/pmap.c (working copy) @@ -3034,7 +3034,14 @@ pmap_remove_all(vm_page_t m) if (TAILQ_EMPTY(&m->md.pv_list)) return; rw_wlock(&pvh_global_lock); - pmap_remove_write(m); + + /* + * XXX This call shouldn't exist. Iterating over the PV list twice, + * once in pmap_clearbit() and again below, is both unnecessary and + * inefficient. The below code should itself write back the cache + * entry before it destroys the mapping. + */ + pmap_clearbit(m, PVF_WRITE); curpm = vmspace_pmap(curproc->p_vmspace); while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) { if (flush == FALSE && (pv->pv_pmap == curpm || @@ -3043,7 +3050,7 @@ pmap_remove_all(vm_page_t m) PMAP_LOCK(pv->pv_pmap); /* - * Cached contents were written-back in pmap_remove_write(), + * Cached contents were written-back in pmap_clearbit(), * but we still have to invalidate the cache entry to make * sure stale data are not retrieved when another page will be * mapped under this virtual address. --------------090707050109010501090800-- From owner-freebsd-arm@FreeBSD.ORG Wed Jun 11 19:44:45 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14BF3C97; Wed, 11 Jun 2014 19:44:45 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [IPv6:2a02:6b8:0:1819::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C001F2DB9; Wed, 11 Jun 2014 19:44:44 +0000 (UTC) Received: from smtp1o.mail.yandex.net (smtp1o.mail.yandex.net [37.140.190.26]) by forward4l.mail.yandex.net (Yandex) with ESMTP id DB0121440E5B; Wed, 11 Jun 2014 23:44:40 +0400 (MSK) Received: from smtp1o.mail.yandex.net (localhost [127.0.0.1]) by smtp1o.mail.yandex.net (Yandex) with ESMTP id 6126EDE1CF8; Wed, 11 Jun 2014 23:44:40 +0400 (MSK) Received: from unknown (unknown [12.202.173.169]) by smtp1o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id vnEEGmcxKB-icqKdOxM; Wed, 11 Jun 2014 23:44:39 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: f5421713-3833-448b-841b-4ae8bf626432 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402515879; bh=O3Lq8Kr0daBvJDaaJC1Qdl7msof0eq6VdIod+fyGskI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=eQhMRgYzPu92gVvwWYae8QZeLzW2mryWHuH1n3OpiP4F6A38U+NZY8u5h2gWUj/yO p1htLyugjHi/HvGhv1XSglsx1OtYBRMGhB8BEnVmMN6GpdHMnGLkQHsEaPB3d6qb3w wMptOlo5Ry94+psti8FqV4DiOZX9Zsekg6ySZqzs= Authentication-Results: smtp1o.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <5398B1A2.3010007@narod.ru> Date: Thu, 12 Jun 2014 01:44:34 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Compilation for ARM References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> In-Reply-To: <1402428857.20883.177.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:44:45 -0000 Hi guys, Thank you! I have built it successfully. It was really simple. Currently I'm trying to launch with u-boot. Are here any instructions/manual how to run kernel with u-boot? Thanks! -Stepan Ian Lepore wrote: > On Sun, 2014-06-08 at 12:15 +0600, Stepan Dyatkovskiy wrote: >> Hi Tim, >> Thank you for quick response! >> I will try your advices straight after weekends. >> We are using pandaboard. Are here any other cortex-a9/a15 boards that >> has, perhaps, better support in FreeBSD OS? If so, we ready to test it >> too, because the only thing we need in pandaboard for now is its CPU. >> >> Thanks! >> -Stepan > > I think the TI OMAP/AM335x chip probably has the best cortex a9 freebsd > support right now. Second would probably be the freescale imx6 family, > mainly because we use it where I work so I get paid to support it. But > the TI support has been around for a lot longer than imx6 and is more > mature right now. > > -- Ian > From owner-freebsd-arm@FreeBSD.ORG Wed Jun 11 19:58:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98705134 for ; Wed, 11 Jun 2014 19:58:40 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CA912EF1 for ; Wed, 11 Jun 2014 19:58:40 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F39171FE026 for ; Wed, 11 Jun 2014 21:58:38 +0200 (CEST) Message-ID: <5398B50A.1070301@selasky.org> Date: Wed, 11 Jun 2014 21:59:06 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-arm Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> In-Reply-To: <539170AA.2000109@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:58:40 -0000 On 06/06/14 09:41, Hans Petter Selasky wrote: > Hi, > > I'm seeing this with RPI-B: > > panic: vm_page_insert_after: msucc doesn't succeed pindex > KDB: enter: panic > [ thread pid 18 tid 100052 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> > > > Any ideas? > > --HPS More information: vm_page_insert_after() at vm_page_insert_after+0x150 pc = 0xc047a2fc lr = 0xc047b7dc (vm_page_alloc+0x568) sp = 0xd3ac7be0 fp = 0xd3ac7c10 r4 = 0xc1a2a140 r5 = 0x00000000 r6 = 0xc0a40920 r7 = 0xc0664310 r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000040 vm_page_alloc() at vm_page_alloc+0x568 pc = 0xc047b7dc lr = 0xc0465d88 (vm_fault_hold+0x3a8) sp = 0xd3ac7c18 fp = 0xd3ac7d88 r4 = 0xc0511362 r5 = 0x00000000 r6 = 0xc0511362 r7 = 0xd3ac7d18 r8 = 0x00000000 r9 = 0xc0664190 r10 = 0x20055000 vm_fault_hold() at vm_fault_hold+0x3a8 pc = 0xc0465d88 lr = 0xc0465998 (vm_fault+0x84) sp = 0xd3ac7d90 fp = 0xd3ac7db0 r4 = 0xc09164f0 r5 = 0x00000002 r6 = 0xc1720c80 r7 = 0x20055000 r8 = 0x00000000 r9 = 0x00000003 r10 = 0xc0663f30 vm_fault() at vm_fault+0x84 pc = 0xc0465998 lr = 0xc04a3c08 (data_abort_handler+0x324) sp = 0xd3ac7db8 fp = 0xd3ac7e58 r4 = 0xc09164f0 r5 = 0xc1720c80 r6 = 0xc0663f30 r7 = 0x00000001 r8 = 0x00000000 r9 = 0x00000010 r10 = 0x00000000 data_abort_handler() at data_abort_handler+0x324 pc = 0xc04a3c08 lr = 0xc049328c (exception_exit) sp = 0xd3ac7e60 fp = 0xbffffa58 r4 = 0x2080f040 r5 = 0x00000030 r6 = 0x00030f50 r7 = 0x2080f044 r8 = 0x00031188 r9 = 0x0003117c r10 = 0x00000000 exception_exit() at exception_exit pc = 0xc049328c lr = 0x20180ff0 (0x20180ff0) sp = 0xd3ac7eb0 fp = 0xbffffa58 r0 = 0x20055348 r1 = 0x00000001 r2 = 0x00027250 r3 = 0x00000000 r4 = 0x2080f040 r5 = 0x00000030 r6 = 0x00030f50 r7 = 0x2080f044 r8 = 0x00031188 r9 = 0x0003117c r10 = 0x00000000 r12 = 0x00000002 > 0xc0a40ce0 idx = 20 < 21 > 0xc0a40ce0 idx = 11 < 20 > 0xc0a40c90 idx = 2 < 4 > 0xc09b8c50 idx = 1 < 36 > 0xc0a40e20 idx = 2 < 36 > 0xc0a3f070 idx = 3 < 36 > 0xc0a3f0c0 idx = 4 < 36 > 0xc0a40ce0 idx = 6 < 11 > growfs: re0xc0a40dd0 idx = 3 < 4 > 0 idx = 4 < 0 > panic: vm_page_insert_after: msucc doesn't succeed pindex > KDB: enter: panic > [ thread pid 18 tid 100052 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> From owner-freebsd-arm@FreeBSD.ORG Wed Jun 11 20:51:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1047EE5F for ; Wed, 11 Jun 2014 20:51:09 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90A2824DE for ; Wed, 11 Jun 2014 20:51:08 +0000 (UTC) Received: from [192.168.1.181] (p508F360C.dip0.t-ipconnect.de [80.143.54.12]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A1B291C1049B8; Wed, 11 Jun 2014 22:51:04 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: RPI-B VM panic From: Michael Tuexen In-Reply-To: <5398B50A.1070301@selasky.org> Date: Wed, 11 Jun 2014 22:51:03 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <539170AA.2000109@selasky.org> <5398B50A.1070301@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 20:51:09 -0000 On 11 Jun 2014, at 21:59, Hans Petter Selasky wrote: > On 06/06/14 09:41, Hans Petter Selasky wrote: >> Hi, >> >> I'm seeing this with RPI-B: >> >> panic: vm_page_insert_after: msucc doesn't succeed pindex >> KDB: enter: panic >> [ thread pid 18 tid 100052 ] >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >> db> >> >> >> Any ideas? Which revision are you using? What is triggering the panic? I could try to reproduce the problem. I've used r267055 with reverted r266083 for a couple of days and it was running stable. It compiled a lot of ports including wireshark. Best regards Michael >> >> --HPS > > More information: > > vm_page_insert_after() at vm_page_insert_after+0x150 > pc = 0xc047a2fc lr = 0xc047b7dc (vm_page_alloc+0x568) > sp = 0xd3ac7be0 fp = 0xd3ac7c10 > r4 = 0xc1a2a140 r5 = 0x00000000 > r6 = 0xc0a40920 r7 = 0xc0664310 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0x00000040 > vm_page_alloc() at vm_page_alloc+0x568 > pc = 0xc047b7dc lr = 0xc0465d88 (vm_fault_hold+0x3a8) > sp = 0xd3ac7c18 fp = 0xd3ac7d88 > r4 = 0xc0511362 r5 = 0x00000000 > r6 = 0xc0511362 r7 = 0xd3ac7d18 > r8 = 0x00000000 r9 = 0xc0664190 > r10 = 0x20055000 > vm_fault_hold() at vm_fault_hold+0x3a8 > pc = 0xc0465d88 lr = 0xc0465998 (vm_fault+0x84) > sp = 0xd3ac7d90 fp = 0xd3ac7db0 > r4 = 0xc09164f0 r5 = 0x00000002 > r6 = 0xc1720c80 r7 = 0x20055000 > r8 = 0x00000000 r9 = 0x00000003 > r10 = 0xc0663f30 > vm_fault() at vm_fault+0x84 > pc = 0xc0465998 lr = 0xc04a3c08 (data_abort_handler+0x324) > sp = 0xd3ac7db8 fp = 0xd3ac7e58 > r4 = 0xc09164f0 r5 = 0xc1720c80 > r6 = 0xc0663f30 r7 = 0x00000001 > r8 = 0x00000000 r9 = 0x00000010 > r10 = 0x00000000 > data_abort_handler() at data_abort_handler+0x324 > pc = 0xc04a3c08 lr = 0xc049328c (exception_exit) > sp = 0xd3ac7e60 fp = 0xbffffa58 > r4 = 0x2080f040 r5 = 0x00000030 > r6 = 0x00030f50 r7 = 0x2080f044 > r8 = 0x00031188 r9 = 0x0003117c > r10 = 0x00000000 > exception_exit() at exception_exit > pc = 0xc049328c lr = 0x20180ff0 (0x20180ff0) > sp = 0xd3ac7eb0 fp = 0xbffffa58 > r0 = 0x20055348 r1 = 0x00000001 > r2 = 0x00027250 r3 = 0x00000000 > r4 = 0x2080f040 r5 = 0x00000030 > r6 = 0x00030f50 r7 = 0x2080f044 > r8 = 0x00031188 r9 = 0x0003117c > r10 = 0x00000000 r12 = 0x00000002 > > > > 0xc0a40ce0 idx = 20 < 21 > > 0xc0a40ce0 idx = 11 < 20 > > 0xc0a40c90 idx = 2 < 4 > > 0xc09b8c50 idx = 1 < 36 > > 0xc0a40e20 idx = 2 < 36 > > 0xc0a3f070 idx = 3 < 36 > > 0xc0a3f0c0 idx = 4 < 36 > > 0xc0a40ce0 idx = 6 < 11 > > growfs: re0xc0a40dd0 idx = 3 < 4 > > 0 idx = 4 < 0 > > panic: vm_page_insert_after: msucc doesn't succeed pindex > > KDB: enter: panic > > [ thread pid 18 tid 100052 ] > > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > db> > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 06:05:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61D39EEA; Thu, 12 Jun 2014 06:05:43 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2577F23E9; Thu, 12 Jun 2014 06:05:42 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 992721FE026; Thu, 12 Jun 2014 08:05:41 +0200 (CEST) Message-ID: <5399434D.2070008@selasky.org> Date: Thu, 12 Jun 2014 08:06:05 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5398B50A.1070301@selasky.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 06:05:43 -0000 On 06/11/14 22:51, Michael Tuexen wrote: > On 11 Jun 2014, at 21:59, Hans Petter Selasky wrote: > >> On 06/06/14 09:41, Hans Petter Selasky wrote: >>> Hi, >>> >>> I'm seeing this with RPI-B: >>> >>> panic: vm_page_insert_after: msucc doesn't succeed pindex >>> KDB: enter: panic >>> [ thread pid 18 tid 100052 ] >>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>> db> >>> >>> >>> Any ideas? > Which revision are you using? What is triggering the panic? I could > try to reproduce the problem. > > I've used r267055 with reverted r266083 for a couple of days and > it was running stable. It compiled a lot of ports including wireshark. > Hi, I'm running -current with a patch reverted for the CPU counter. It happens around growfs. The error is not constant. If I change the boot timing by plugging more USB devices, then I sometimes can pass the point of error. I think the problem is related to the following commit: > commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 > Author: alc > Date: Sun May 12 16:50:18 2013 +0000 > > Refactor vm_page_alloc()'s interactions with vm_reserv_alloc_page() and > vm_page_insert() so that (1) vm_radix_lookup_le() is never called while the > free page queues lock is held and (2) vm_radix_lookup_le() is called at most > once. This change reduces the average time that the free page queues lock > is held by vm_page_alloc() as well as vm_page_alloc()'s average overall > running time. > > Sponsored by: EMC / Isilon Storage Division > Looks like we are trying to grow the stack and then the pages are not in the expected order. --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 16:36:56 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52C6789D for ; Thu, 12 Jun 2014 16:36:56 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 260482F17 for ; Thu, 12 Jun 2014 16:36:55 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wv7zc-000BQC-M5; Thu, 12 Jun 2014 16:36:48 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5CGaj73001309; Thu, 12 Jun 2014 10:36:45 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Oa1BgeLJ7RBf4sY1T+tWj Subject: Re: Compilation for ARM From: Ian Lepore To: Stepan Dyatkovskiy In-Reply-To: <5398B1A2.3010007@narod.ru> References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jun 2014 10:36:45 -0600 Message-ID: <1402591005.20883.213.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:36:56 -0000 On Thu, 2014-06-12 at 01:44 +0600, Stepan Dyatkovskiy wrote: > Hi guys, > Thank you! I have built it successfully. It was really simple. Currently > I'm trying to launch with u-boot. Are here any instructions/manual how > to run kernel with u-boot? > Thanks! > -Stepan If you compile the dtb into the kernel, you can launch the kernel directly from u-boot. If you don't, then you need u-boot to launch ubldr (loader(8) that uses the u-boot API, which requires a u-boot with the API option enabled). The kernel can be loaded at any 1MB-boundary address, and can be launched by jumping to the load address + 0x100, such as: fatload 11000000; go 11000100 If you are using a modern u-boot that enables data caches, you need to turn them off manually, like: fatload 11000000 dcache off; dcache flush go 11000100 This is just a u-boot quirk, it disables caches on bootm and bootelf commands, but not on a "go" command. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 16:54:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBB5F57D; Thu, 12 Jun 2014 16:54:25 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A4E8F2100; Thu, 12 Jun 2014 16:54:25 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5CGsNnj019087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 09:54:24 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5CGsN7x019086; Thu, 12 Jun 2014 09:54:23 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Jun 2014 09:54:23 -0700 From: John-Mark Gurney To: Alan Cox Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140612165423.GS31367@funkthat.com> Mail-Followup-To: Alan Cox , alc@freebsd.org, "freebsd-arm@freebsd.org" , ian@freebsd.org References: <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> <20140609221742.GV31367@funkthat.com> <539730B1.2040900@rice.edu> <20140610170052.GF31367@funkthat.com> <5397F089.90403@rice.edu> <20140611074159.GL31367@funkthat.com> <539887BD.2090408@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539887BD.2090408@rice.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 12 Jun 2014 09:54:24 -0700 (PDT) Cc: alc@freebsd.org, "freebsd-arm@freebsd.org" , ian@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:54:26 -0000 Alan Cox wrote this message on Wed, Jun 11, 2014 at 11:45 -0500: > On 06/11/2014 02:41, John-Mark Gurney wrote: > > Alan Cox wrote this message on Wed, Jun 11, 2014 at 01:00 -0500: > >> On 06/10/2014 12:00, John-Mark Gurney wrote: > >>> Alan Cox wrote this message on Tue, Jun 10, 2014 at 11:22 -0500: > >>>> On 06/09/2014 17:17, John-Mark Gurney wrote: > >>>>> Warner Losh wrote this message on Mon, Jun 09, 2014 at 14:08 -0600: > >>>>>> On Jun 9, 2014, at 1:23 PM, Alan Cox wrote: > >>>>>> > >>>>>>> On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote: > >>>>>>> > >>>>>>>> Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500: > >>>>>>>>> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this. > >>>>>>>> No worried, the new patch panics: > >>>>>>>> panic: vm_reserv_break: 2 saved_object=0xc06e6378 x=253 m_tmp->object=0xc06e6378 (1) > >>>>>>>> > >>>>>>> Is your arm processor running in big-endian or little-endian mode? > >>>>>> Big Endian. > >>>>> Specificly, TARGET_ARCH=armeb... So, ARMv4 in big-endian mode... > >>>>> > >>>> Please try the attached patch. > >>> This patch now boots to multiuser mode and I can log in! > >>> > >>> I can now more easily debug newsyslog segfaulting and stuff... I'll > >>> let you know if I have any more issues... > >>> > >>> Thanks again for tracking this down! > >>> > >> Here is a commit-able patch. Please tell me if it works. > > So, it worked for a while, but it looks like there are still lingering > > bugs... Not sure if this is the same, or different... > > This is an entirely different problem. It's also a much simpler problem. > > A simple workaround patch is attached. Go ahead and commit this patch > yourself if it helps. Thanks committed... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 16:59:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B281D78F for ; Thu, 12 Jun 2014 16:59:52 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CF812154 for ; Thu, 12 Jun 2014 16:59:51 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5CGxnXM019172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 09:59:49 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5CGxk6F019171; Thu, 12 Jun 2014 09:59:46 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Jun 2014 09:59:46 -0700 From: John-Mark Gurney To: John Hay Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140612165946.GT31367@funkthat.com> Mail-Followup-To: John Hay , Warner Losh , freebsd-arm References: <20140521192807.GA48338@zibbi.meraka.csir.co.za> <95AD97BA-AA48-4BBF-845C-D0CB585ACAA3@bsdimp.com> <20140522090504.GA22488@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140522090504.GA22488@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 12 Jun 2014 09:59:49 -0700 (PDT) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:59:52 -0000 John Hay wrote this message on Thu, May 22, 2014 at 11:05 +0200: > On Wed, May 21, 2014 at 02:01:42PM -0600, Warner Losh wrote: > > > > On May 21, 2014, at 1:28 PM, John Hay wrote: > > > > > On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: > > >> isn't eabi on the xscale still broken? > > > > > > It might still be broken. But there are more brokenness than that. :-( > > > By defining WITHOUT_ARM_EABI=yes in src.conf, I can get an AVILA kernel > > > built that boots with src from head at around mid December. Latest 10 > > > and head just give no output, with or without WITHOUT_ARM_EABI defined. > > > > Does the same thing happen with make.conf instead of src.conf? > > Yes, I have tried both 10 and head with WITHOUT_ARM_EABI=yes and no > output after go in redboot. My compile lines look like this: > > make TARGET_ARCH=armeb TARGET_CPUTYPE=xscale toolchain > make TARGET=arm TARGET_ARCH=armeb buildkernel KERNCONF=AVILA DESTDIR=/arm/ > > And then in redboot "load -b 0x200000 kernel" to load it with tftp. And > then "go". > > The "no output" happened somewhere between mid December and beginning > of Feb. I determined that before getting side tracked. I'll see in the > next day or two if I can narrow that down. That sounds like the gcc bug that was fixed... > If someone have patches so that WITHOUT_ARM_EABI=yes is not needed > anymore, I'll test that too. We are getting close to having EABI working on AVILA... alc has tracked down a couple issues that was causing kernel panics.. Look for an email shortly on a remaining issue, which I believe is w/ rtld... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 17:12:35 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 677B5E1B for ; Thu, 12 Jun 2014 17:12:35 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2871A233E for ; Thu, 12 Jun 2014 17:12:34 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s5CHBouc031138; Thu, 12 Jun 2014 12:12:33 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp1.rice.edu with ESMTP id 1megfvrr5s-1; Thu, 12 Jun 2014 12:12:33 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 938AF460197; Thu, 12 Jun 2014 12:12:32 -0500 (CDT) Message-ID: <5399DF7F.4010501@rice.edu> Date: Thu, 12 Jun 2014 12:12:31 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Hans Petter Selasky , "arm@freebsd.org" Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> In-Reply-To: <539942C0.5010706@selasky.org> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------040103050600070308080401" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=11 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406120201 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:12:35 -0000 This is a multi-part message in MIME format. --------------040103050600070308080401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/12/2014 01:03, Hans Petter Selasky wrote: > On 06/11/14 22:47, Alan Cox wrote: >> >> On Jun 11, 2014, at 3:45 PM, Hans Petter Selasky wrote: >> >>> On 06/11/14 22:20, Alan Cox wrote: >>>> >>>> On Jun 11, 2014, at 3:07 PM, Hans Petter Selasky wrote: >>>> >>>>> kernel: file format elf32-littlearm >>>>> >>>> >>>> Then this problem is unrelated to the one that I just fixed. It's >>>> also not a problem that I've seen before. >>> >>> It is happening after your recent patches to -current, optimising >>> the "page ordering". Happens every now and then during boot when >>> stack is growing looks like. >> >> More precisely, which commit is that? >> > >> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 >> Author: alc >> Date: Sun May 12 16:50:18 2013 +0000 >> >> Refactor vm_page_alloc()'s interactions with >> vm_reserv_alloc_page() and >> vm_page_insert() so that (1) vm_radix_lookup_le() is never called >> while the >> free page queues lock is held and (2) vm_radix_lookup_le() is >> called at most >> once. This change reduces the average time that the free page >> queues lock >> is held by vm_page_alloc() as well as vm_page_alloc()'s average >> overall >> running time. >> >> Sponsored by: EMC / Isilon Storage Division >> > > That's not exactly a recent commit. It was 13 months ago. And, this code is exercised by all page allocations except for page table pages and uma_small_alloc(). What this assertion is telling us is that somewhere else we have screwed up the vm object to which we are now trying to allocate a page. Try the attached patch. It will provide additional information the next time that the assertion fails. Has anyone else seen this assertion fail? --------------040103050600070308080401 Content-Type: text/plain; charset=ISO-8859-15; name="hps_page_insert_after1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="hps_page_insert_after1.patch" Index: vm/vm_page.c =================================================================== --- vm/vm_page.c (revision 267411) +++ vm/vm_page.c (working copy) @@ -975,7 +975,9 @@ vm_page_insert_after(vm_page_t m, vm_object_t obje msucc = TAILQ_FIRST(&object->memq); if (msucc != NULL) KASSERT(msucc->pindex > pindex, - ("vm_page_insert_after: msucc doesn't succeed pindex")); + ("vm_page_insert_after: msucc %p (%ju) doesn't succeed pindex %ju\n" +"object %p type %d", +msucc, (uintmax_t)msucc->pindex, (uintmax_t)pindex, object, object->type)); /* * Record the object/offset pair in this page --------------040103050600070308080401-- From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 17:28:22 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD5ECBA2 for ; Thu, 12 Jun 2014 17:28:22 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97E982452 for ; Thu, 12 Jun 2014 17:28:22 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B97ED1FE026; Thu, 12 Jun 2014 19:28:19 +0200 (CEST) Message-ID: <5399E349.5050600@selasky.org> Date: Thu, 12 Jun 2014 19:28:41 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Alan Cox , "arm@freebsd.org" Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> In-Reply-To: <5399DF7F.4010501@rice.edu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:28:22 -0000 On 06/12/14 19:12, Alan Cox wrote: > On 06/12/2014 01:03, Hans Petter Selasky wrote: >> On 06/11/14 22:47, Alan Cox wrote: >>> >>> On Jun 11, 2014, at 3:45 PM, Hans Petter Selasky wrote: >>> >>>> On 06/11/14 22:20, Alan Cox wrote: >>>>> >>>>> On Jun 11, 2014, at 3:07 PM, Hans Petter Selasky wrote: >>>>> >>>>>> kernel: file format elf32-littlearm >>>>>> >>>>> >>>>> Then this problem is unrelated to the one that I just fixed. It's >>>>> also not a problem that I've seen before. >>>> >>>> It is happening after your recent patches to -current, optimising >>>> the "page ordering". Happens every now and then during boot when >>>> stack is growing looks like. >>> >>> More precisely, which commit is that? >>> >> >>> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 >>> Author: alc >>> Date: Sun May 12 16:50:18 2013 +0000 >>> >>> Refactor vm_page_alloc()'s interactions with >>> vm_reserv_alloc_page() and >>> vm_page_insert() so that (1) vm_radix_lookup_le() is never called >>> while the >>> free page queues lock is held and (2) vm_radix_lookup_le() is >>> called at most >>> once. This change reduces the average time that the free page >>> queues lock >>> is held by vm_page_alloc() as well as vm_page_alloc()'s average >>> overall >>> running time. >>> >>> Sponsored by: EMC / Isilon Storage Division >>> >> >> > > That's not exactly a recent commit. It was 13 months ago. And, this > code is exercised by all page allocations except for page table pages > and uma_small_alloc(). > > What this assertion is telling us is that somewhere else we have screwed > up the vm object to which we are now trying to allocate a page. > > Try the attached patch. It will provide additional information the next > time that the assertion fails. > Here you go: > panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed pindex 4 > object 0xc1a2b140 type 0 > KDB: enter: panic > [ thread pid 18 tid 100052 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 17:32:22 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16427D0C for ; Thu, 12 Jun 2014 17:32:22 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAD1B24E3 for ; Thu, 12 Jun 2014 17:32:18 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wv8rC-0007K4-P5; Thu, 12 Jun 2014 17:32:11 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5CHW7Gx001384; Thu, 12 Jun 2014 11:32:07 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX181t6X1C3aki7dvvk3hC/qW Subject: Re: RPI-B VM panic From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <5399E349.5050600@selasky.org> References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jun 2014 11:32:07 -0600 Message-ID: <1402594327.20883.216.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" , Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:32:22 -0000 On Thu, 2014-06-12 at 19:28 +0200, Hans Petter Selasky wrote: > On 06/12/14 19:12, Alan Cox wrote: > > On 06/12/2014 01:03, Hans Petter Selasky wrote: > >> On 06/11/14 22:47, Alan Cox wrote: > >>> > >>> On Jun 11, 2014, at 3:45 PM, Hans Petter Selasky wrote: > >>> > >>>> On 06/11/14 22:20, Alan Cox wrote: > >>>>> > >>>>> On Jun 11, 2014, at 3:07 PM, Hans Petter Selasky wrote: > >>>>> > >>>>>> kernel: file format elf32-littlearm > >>>>>> > >>>>> > >>>>> Then this problem is unrelated to the one that I just fixed. It's > >>>>> also not a problem that I've seen before. > >>>> > >>>> It is happening after your recent patches to -current, optimising > >>>> the "page ordering". Happens every now and then during boot when > >>>> stack is growing looks like. > >>> > >>> More precisely, which commit is that? > >>> > >> > >>> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 > >>> Author: alc > >>> Date: Sun May 12 16:50:18 2013 +0000 > >>> > >>> Refactor vm_page_alloc()'s interactions with > >>> vm_reserv_alloc_page() and > >>> vm_page_insert() so that (1) vm_radix_lookup_le() is never called > >>> while the > >>> free page queues lock is held and (2) vm_radix_lookup_le() is > >>> called at most > >>> once. This change reduces the average time that the free page > >>> queues lock > >>> is held by vm_page_alloc() as well as vm_page_alloc()'s average > >>> overall > >>> running time. > >>> > >>> Sponsored by: EMC / Isilon Storage Division > >>> > >> > >> > > > > That's not exactly a recent commit. It was 13 months ago. And, this > > code is exercised by all page allocations except for page table pages > > and uma_small_alloc(). > > > > What this assertion is telling us is that somewhere else we have screwed > > up the vm object to which we are now trying to allocate a page. > > > > Try the attached patch. It will provide additional information the next > > time that the assertion fails. > > > > Here you go: > > > panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed pindex 4 > > object 0xc1a2b140 type 0 > > KDB: enter: panic > > [ thread pid 18 tid 100052 ] > > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > db> Could this be related to changing superpages to enabled by default recently? Easy to test by setting vm.pmap.sp_enabled=0 in ubldr -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 17:41:34 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4B8C97; Thu, 12 Jun 2014 17:41:33 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E70A25DE; Thu, 12 Jun 2014 17:41:33 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D63311FE026; Thu, 12 Jun 2014 19:41:30 +0200 (CEST) Message-ID: <5399E660.5050207@selasky.org> Date: Thu, 12 Jun 2014 19:41:52 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> In-Reply-To: <1402594327.20883.216.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" , Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:41:34 -0000 On 06/12/14 19:32, Ian Lepore wrote: > On Thu, 2014-06-12 at 19:28 +0200, Hans Petter Selasky wrote: >> On 06/12/14 19:12, Alan Cox wrote: >>> On 06/12/2014 01:03, Hans Petter Selasky wrote: >>>> On 06/11/14 22:47, Alan Cox wrote: >>>>> >>>>> On Jun 11, 2014, at 3:45 PM, Hans Petter Selasky wrote: >>>>> >>>>>> On 06/11/14 22:20, Alan Cox wrote: >>>>>>> >>>>>>> On Jun 11, 2014, at 3:07 PM, Hans Petter Selasky wrote: >>>>>>> >>>>>>>> kernel: file format elf32-littlearm >>>>>>>> >>>>>>> >>>>>>> Then this problem is unrelated to the one that I just fixed. It's >>>>>>> also not a problem that I've seen before. >>>>>> >>>>>> It is happening after your recent patches to -current, optimising >>>>>> the "page ordering". Happens every now and then during boot when >>>>>> stack is growing looks like. >>>>> >>>>> More precisely, which commit is that? >>>>> >>>> >>>>> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 >>>>> Author: alc >>>>> Date: Sun May 12 16:50:18 2013 +0000 >>>>> >>>>> Refactor vm_page_alloc()'s interactions with >>>>> vm_reserv_alloc_page() and >>>>> vm_page_insert() so that (1) vm_radix_lookup_le() is never called >>>>> while the >>>>> free page queues lock is held and (2) vm_radix_lookup_le() is >>>>> called at most >>>>> once. This change reduces the average time that the free page >>>>> queues lock >>>>> is held by vm_page_alloc() as well as vm_page_alloc()'s average >>>>> overall >>>>> running time. >>>>> >>>>> Sponsored by: EMC / Isilon Storage Division >>>>> >>>> >>>> >>> >>> That's not exactly a recent commit. It was 13 months ago. And, this >>> code is exercised by all page allocations except for page table pages >>> and uma_small_alloc(). >>> >>> What this assertion is telling us is that somewhere else we have screwed >>> up the vm object to which we are now trying to allocate a page. >>> >>> Try the attached patch. It will provide additional information the next >>> time that the assertion fails. >>> >> >> Here you go: >> >>> panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed pindex 4 >>> object 0xc1a2b140 type 0 >>> KDB: enter: panic >>> [ thread pid 18 tid 100052 ] >>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>> db> > > Could this be related to changing superpages to enabled by default > recently? Easy to test by setting vm.pmap.sp_enabled=0 in ubldr > Setting the sp_enabled to 0 does not fix the problem. --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 17:52:45 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E731338; Thu, 12 Jun 2014 17:52:45 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A814D26DD; Thu, 12 Jun 2014 17:52:44 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 70FF11FE026; Thu, 12 Jun 2014 19:52:43 +0200 (CEST) Message-ID: <5399E901.1080805@selasky.org> Date: Thu, 12 Jun 2014 19:53:05 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> In-Reply-To: <5399E660.5050207@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" , Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:52:45 -0000 On 06/12/14 19:41, Hans Petter Selasky wrote: > On 06/12/14 19:32, Ian Lepore wrote: >> On Thu, 2014-06-12 at 19:28 +0200, Hans Petter Selasky wrote: >>> On 06/12/14 19:12, Alan Cox wrote: >>>> On 06/12/2014 01:03, Hans Petter Selasky wrote: >>>>> On 06/11/14 22:47, Alan Cox wrote: >>>>>> >>>>>> On Jun 11, 2014, at 3:45 PM, Hans Petter Selasky wrote: >>>>>> >>>>>>> On 06/11/14 22:20, Alan Cox wrote: >>>>>>>> >>>>>>>> On Jun 11, 2014, at 3:07 PM, Hans Petter Selasky wrote: >>>>>>>> >>>>>>>>> kernel: file format elf32-littlearm >>>>>>>>> >>>>>>>> >>>>>>>> Then this problem is unrelated to the one that I just fixed. It's >>>>>>>> also not a problem that I've seen before. >>>>>>> >>>>>>> It is happening after your recent patches to -current, optimising >>>>>>> the "page ordering". Happens every now and then during boot when >>>>>>> stack is growing looks like. >>>>>> >>>>>> More precisely, which commit is that? >>>>>> >>>>> >>>>>> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 >>>>>> Author: alc >>>>>> Date: Sun May 12 16:50:18 2013 +0000 >>>>>> >>>>>> Refactor vm_page_alloc()'s interactions with >>>>>> vm_reserv_alloc_page() and >>>>>> vm_page_insert() so that (1) vm_radix_lookup_le() is never >>>>>> called >>>>>> while the >>>>>> free page queues lock is held and (2) vm_radix_lookup_le() is >>>>>> called at most >>>>>> once. This change reduces the average time that the free page >>>>>> queues lock >>>>>> is held by vm_page_alloc() as well as vm_page_alloc()'s average >>>>>> overall >>>>>> running time. >>>>>> >>>>>> Sponsored by: EMC / Isilon Storage Division >>>>>> >>>>> >>>>> >>>> >>>> That's not exactly a recent commit. It was 13 months ago. And, this >>>> code is exercised by all page allocations except for page table pages >>>> and uma_small_alloc(). >>>> >>>> What this assertion is telling us is that somewhere else we have >>>> screwed >>>> up the vm object to which we are now trying to allocate a page. >>>> >>>> Try the attached patch. It will provide additional information the >>>> next >>>> time that the assertion fails. >>>> >>> >>> Here you go: >>> >>>> panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed >>>> pindex 4 >>>> object 0xc1a2b140 type 0 >>>> KDB: enter: panic >>>> [ thread pid 18 tid 100052 ] >>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>>> db> >> >> Could this be related to changing superpages to enabled by default >> recently? Easy to test by setting vm.pmap.sp_enabled=0 in ubldr >> > > Setting the sp_enabled to 0 does not fix the problem. > > --HPS Output from the debugger regarding the object: > panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed pindex 4 > object 0xc1a2b1e0 type 0 > KDB: enter: panic > db> show vmochk > vmochk: internal obj is not in a map: ref: 1, size: 2: 0x2, backing_object: 0 > vmochk: internal obj is not in a map: ref: 1, size: 2: 0x2, backing_object: 0 .... > db> show vmopag .... > new object: 0xc1a2b1e0 > index(0)run(1)pa(0x1766000) > index(1)run(1)pa(0x1e17000) > index(2)run(2)pa(0x1772000) > index(4)run(1)pa(0x1e6a000) > index(5)run(2)pa(0x1775000) > index(7)run(1)pa(0x1778000) > index(8)run(1)pa(0x1788000) > index(9)run(1)pa(0x17e9000) --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 18:44:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 276BD104 for ; Thu, 12 Jun 2014 18:44:09 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBD112BA6 for ; Thu, 12 Jun 2014 18:44:08 +0000 (UTC) Received: from [192.168.1.200] (p508F17FA.dip0.t-ipconnect.de [80.143.23.250]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id F17371C104649; Thu, 12 Jun 2014 20:44:04 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: RPI-B VM panic From: Michael Tuexen In-Reply-To: <5399434D.2070008@selasky.org> Date: Thu, 12 Jun 2014 20:44:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <539170AA.2000109@selasky.org> <5398B50A.1070301@selasky.org> <5399434D.2070008@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:44:09 -0000 On 12 Jun 2014, at 08:06, Hans Petter Selasky wrote: > On 06/11/14 22:51, Michael Tuexen wrote: >> On 11 Jun 2014, at 21:59, Hans Petter Selasky = wrote: >>=20 >>> On 06/06/14 09:41, Hans Petter Selasky wrote: >>>> Hi, >>>>=20 >>>> I'm seeing this with RPI-B: >>>>=20 >>>> panic: vm_page_insert_after: msucc doesn't succeed pindex >>>> KDB: enter: panic >>>> [ thread pid 18 tid 100052 ] >>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>>> db> >>>>=20 >>>>=20 >>>> Any ideas? >> Which revision are you using? What is triggering the panic? I could >> try to reproduce the problem. >>=20 >> I've used r267055 with reverted r266083 for a couple of days and >> it was running stable. It compiled a lot of ports including = wireshark. >>=20 >=20 > Hi, >=20 > I'm running -current with a patch reverted for the CPU counter. It = happens around growfs. The error is not constant. If I change the boot = timing by plugging more USB devices, then I sometimes can pass I haven't it experienced. I normally grow the filesystem from 1 GB to 16 = GB after installation and I have not connected any USP device. I'm normally = booting it using a serial cable, no monitor, no keyboard, no mouse attached. Best regards Michael > the point of error. I think the problem is related to the following = commit: >=20 >> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 >> Author: alc >> Date: Sun May 12 16:50:18 2013 +0000 >>=20 >> Refactor vm_page_alloc()'s interactions with = vm_reserv_alloc_page() and >> vm_page_insert() so that (1) vm_radix_lookup_le() is never called = while the >> free page queues lock is held and (2) vm_radix_lookup_le() is = called at most >> once. This change reduces the average time that the free page = queues lock >> is held by vm_page_alloc() as well as vm_page_alloc()'s average = overall >> running time. >>=20 >> Sponsored by: EMC / Isilon Storage Division >>=20 >=20 > Looks like we are trying to grow the stack and then the pages are not = in the expected order. >=20 > --HPS >=20 From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 19:11:29 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F28AEDDD; Thu, 12 Jun 2014 19:11:28 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B38FD2F20; Thu, 12 Jun 2014 19:11:27 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s5CJ7aS5016938; Thu, 12 Jun 2014 14:11:20 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1mfh28g1tf-1; Thu, 12 Jun 2014 14:11:20 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 0BF0C460203; Thu, 12 Jun 2014 14:11:20 -0500 (CDT) Message-ID: <5399FB57.8090102@rice.edu> Date: Thu, 12 Jun 2014 14:11:19 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Hans Petter Selasky , Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> In-Reply-To: <5399E901.1080805@selasky.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=11 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406120223 Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 19:11:29 -0000 On 06/12/2014 12:53, Hans Petter Selasky wrote: > On 06/12/14 19:41, Hans Petter Selasky wrote: >> On 06/12/14 19:32, Ian Lepore wrote: >>> On Thu, 2014-06-12 at 19:28 +0200, Hans Petter Selasky wrote: >>>> On 06/12/14 19:12, Alan Cox wrote: >>>>> On 06/12/2014 01:03, Hans Petter Selasky wrote: >>>>>> On 06/11/14 22:47, Alan Cox wrote: >>>>>>> >>>>>>> On Jun 11, 2014, at 3:45 PM, Hans Petter Selasky wrote: >>>>>>> >>>>>>>> On 06/11/14 22:20, Alan Cox wrote: >>>>>>>>> >>>>>>>>> On Jun 11, 2014, at 3:07 PM, Hans Petter Selasky wrote: >>>>>>>>> >>>>>>>>>> kernel: file format elf32-littlearm >>>>>>>>>> >>>>>>>>> >>>>>>>>> Then this problem is unrelated to the one that I just fixed. >>>>>>>>> It's >>>>>>>>> also not a problem that I've seen before. >>>>>>>> >>>>>>>> It is happening after your recent patches to -current, optimising >>>>>>>> the "page ordering". Happens every now and then during boot when >>>>>>>> stack is growing looks like. >>>>>>> >>>>>>> More precisely, which commit is that? >>>>>>> >>>>>> >>>>>>> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 >>>>>>> Author: alc >>>>>>> Date: Sun May 12 16:50:18 2013 +0000 >>>>>>> >>>>>>> Refactor vm_page_alloc()'s interactions with >>>>>>> vm_reserv_alloc_page() and >>>>>>> vm_page_insert() so that (1) vm_radix_lookup_le() is never >>>>>>> called >>>>>>> while the >>>>>>> free page queues lock is held and (2) vm_radix_lookup_le() is >>>>>>> called at most >>>>>>> once. This change reduces the average time that the free >>>>>>> page >>>>>>> queues lock >>>>>>> is held by vm_page_alloc() as well as vm_page_alloc()'s >>>>>>> average >>>>>>> overall >>>>>>> running time. >>>>>>> >>>>>>> Sponsored by: EMC / Isilon Storage Division >>>>>>> >>>>>> >>>>>> >>>>> >>>>> That's not exactly a recent commit. It was 13 months ago. And, this >>>>> code is exercised by all page allocations except for page table pages >>>>> and uma_small_alloc(). >>>>> >>>>> What this assertion is telling us is that somewhere else we have >>>>> screwed >>>>> up the vm object to which we are now trying to allocate a page. >>>>> >>>>> Try the attached patch. It will provide additional information the >>>>> next >>>>> time that the assertion fails. >>>>> >>>> >>>> Here you go: >>>> >>>>> panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed >>>>> pindex 4 >>>>> object 0xc1a2b140 type 0 >>>>> KDB: enter: panic >>>>> [ thread pid 18 tid 100052 ] >>>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>>>> db> >>> >>> Could this be related to changing superpages to enabled by default >>> recently? Easy to test by setting vm.pmap.sp_enabled=0 in ubldr >>> >> >> Setting the sp_enabled to 0 does not fix the problem. >> >> --HPS > > Output from the debugger regarding the object: > >> panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed >> pindex 4 >> object 0xc1a2b1e0 type 0 >> KDB: enter: panic > >> db> show vmochk >> vmochk: internal obj is not in a map: ref: 1, size: 2: 0x2, >> backing_object: 0 >> vmochk: internal obj is not in a map: ref: 1, size: 2: 0x2, >> backing_object: 0 > Use the ddb command "object", not "vmochk". > .... > >> db> show vmopag > > .... > >> new object: 0xc1a2b1e0 >> index(0)run(1)pa(0x1766000) >> index(1)run(1)pa(0x1e17000) >> index(2)run(2)pa(0x1772000) >> index(4)run(1)pa(0x1e6a000) >> index(5)run(2)pa(0x1775000) >> index(7)run(1)pa(0x1778000) >> index(8)run(1)pa(0x1788000) >> index(9)run(1)pa(0x17e9000) > > --HPS > > > From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 20:56:28 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ACB457E; Thu, 12 Jun 2014 20:56:28 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE66627E9; Thu, 12 Jun 2014 20:56:27 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 66A831FE026; Thu, 12 Jun 2014 22:56:25 +0200 (CEST) Message-ID: <539A140F.6020107@selasky.org> Date: Thu, 12 Jun 2014 22:56:47 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Alan Cox , Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> <5399FB57.8090102@rice.edu> In-Reply-To: <5399FB57.8090102@rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 20:56:28 -0000 On 06/12/14 21:11, Alan Cox wrote: > On 06/12/2014 12:53, Hans Petter Selasky wrote: >> On 06/12/14 19:41, Hans Petter Selasky wrote: >>> On 06/12/14 19:32, Ian Lepore wrote: >>>> On Thu, 2014-06-12 at 19:28 +0200, Hans Petter Selasky wrote: >>>>> On 06/12/14 19:12, Alan Cox wrote: >>>>>> On 06/12/2014 01:03, Hans Petter Selasky wrote: >>>>>>> On 06/11/14 22:47, Alan Cox wrote: >>>>>>>> >>>>>>>> On Jun 11, 2014, at 3:45 PM, Hans Petter Selasky wrote: >>>>>>>> >>>>>>>>> On 06/11/14 22:20, Alan Cox wrote: >>>>>>>>>> >>>>>>>>>> On Jun 11, 2014, at 3:07 PM, Hans Petter Selasky wrote: >>>>>>>>>> >>>>>>>>>>> kernel: file format elf32-littlearm >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Then this problem is unrelated to the one that I just fixed. >>>>>>>>>> It's >>>>>>>>>> also not a problem that I've seen before. >>>>>>>>> >>>>>>>>> It is happening after your recent patches to -current, optimising >>>>>>>>> the "page ordering". Happens every now and then during boot when >>>>>>>>> stack is growing looks like. >>>>>>>> >>>>>>>> More precisely, which commit is that? >>>>>>>> >>>>>>> >>>>>>>> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 >>>>>>>> Author: alc >>>>>>>> Date: Sun May 12 16:50:18 2013 +0000 >>>>>>>> >>>>>>>> Refactor vm_page_alloc()'s interactions with >>>>>>>> vm_reserv_alloc_page() and >>>>>>>> vm_page_insert() so that (1) vm_radix_lookup_le() is never >>>>>>>> called >>>>>>>> while the >>>>>>>> free page queues lock is held and (2) vm_radix_lookup_le() is >>>>>>>> called at most >>>>>>>> once. This change reduces the average time that the free >>>>>>>> page >>>>>>>> queues lock >>>>>>>> is held by vm_page_alloc() as well as vm_page_alloc()'s >>>>>>>> average >>>>>>>> overall >>>>>>>> running time. >>>>>>>> >>>>>>>> Sponsored by: EMC / Isilon Storage Division >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> That's not exactly a recent commit. It was 13 months ago. And, this >>>>>> code is exercised by all page allocations except for page table pages >>>>>> and uma_small_alloc(). >>>>>> >>>>>> What this assertion is telling us is that somewhere else we have >>>>>> screwed >>>>>> up the vm object to which we are now trying to allocate a page. >>>>>> >>>>>> Try the attached patch. It will provide additional information the >>>>>> next >>>>>> time that the assertion fails. >>>>>> >>>>> >>>>> Here you go: >>>>> >>>>>> panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed >>>>>> pindex 4 >>>>>> object 0xc1a2b140 type 0 >>>>>> KDB: enter: panic >>>>>> [ thread pid 18 tid 100052 ] >>>>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>>>>> db> >>>> >>>> Could this be related to changing superpages to enabled by default >>>> recently? Easy to test by setting vm.pmap.sp_enabled=0 in ubldr >>>> >>> >>> Setting the sp_enabled to 0 does not fix the problem. >>> >>> --HPS >> >> Output from the debugger regarding the object: >> >>> panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed >>> pindex 4 >>> object 0xc1a2b1e0 type 0 >>> KDB: enter: panic >> >>> db> show vmochk >>> vmochk: internal obj is not in a map: ref: 1, size: 2: 0x2, >>> backing_object: 0 >>> vmochk: internal obj is not in a map: ref: 1, size: 2: 0x2, >>> backing_object: 0 >> > > Use the ddb command "object", not "vmochk". > >> .... >> >>> db> show vmopag >> >> .... >> >>> new object: 0xc1a2b1e0 >>> index(0)run(1)pa(0x1766000) >>> index(1)run(1)pa(0x1e17000) >>> index(2)run(2)pa(0x1772000) >>> index(4)run(1)pa(0x1e6a000) >>> index(5)run(2)pa(0x1775000) >>> index(7)run(1)pa(0x1778000) >>> index(8)run(1)pa(0x1788000) >>> index(9)run(1)pa(0x17e9000) >> >> --HPS >> >> >> > > show object 0xc1a2b1e0 Object 0xc1a2b1e0: type=0, size=0xa, res=10, ref=2, flags=0x3000 ruid 0 charge a000 sref=0, backing_object(0)=(0)+0x0 memory:=(off=0x0,page=0x1766000),(off=0x1,page=0x1e17000),(off=0x2,page=0x1772000),(off=0x3,page=0x1773000),(off=0x4,page=0x1e6a000),(off=0x5,page=0x177500) ...(off=0x6,page=0x1776000),(off=0x7,page=0x1778000),(off=0x8,page=0x1788000),(off=0x9,page=0x17e9000) From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 21:58:03 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FC4FA3B; Thu, 12 Jun 2014 21:58:03 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36F262D67; Thu, 12 Jun 2014 21:58:02 +0000 (UTC) Received: from smtp7.mail.yandex.net (smtp7.mail.yandex.net [77.88.61.55]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 6AEAC1A41434; Fri, 13 Jun 2014 01:57:59 +0400 (MSK) Received: from smtp7.mail.yandex.net (localhost [127.0.0.1]) by smtp7.mail.yandex.net (Yandex) with ESMTP id F2FA71580901; Fri, 13 Jun 2014 01:57:58 +0400 (MSK) Received: from unknown (unknown [12.202.173.169]) by smtp7.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id QYinZgty1k-vuJSfRA7; Fri, 13 Jun 2014 01:57:58 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 3a7cf8c0-ad74-4283-86f6-da53a10ccc83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402610278; bh=L0PXDYCPALWS1AziJ7CyzeE8imlyY3nSa+UVUeEtKYQ=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hnh6nne5Ab2A5Uhkm/+tEs6IdfqTL9eDW2/jJY5wqQDRyhnLDuAgKRMuT+62+5U4j VYF8N15ypHe9UCf8Hck/cCzhCF7wniq4iRYITbJ0tRbfJuUwj0YsL8nO0GVo3eeFp4 lxL6WySVPmW7Du9CVfxb9SzjyBSWjWI6AwZWbWuo= Authentication-Results: smtp7.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <539A2261.4070705@narod.ru> Date: Fri, 13 Jun 2014 03:57:53 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Compilation for ARM References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> In-Reply-To: <1402591005.20883.213.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 21:58:03 -0000 Hi all, Thanks for advices! That's interesting. I have managed to launch kernel, using these u-boot binaries: http://people.freebsd.org/~gonzo/pandaboard/ Looks like specific MLO. But I'm not sure. With regular linaro u-boot, I load kernel.bin, then try start it with "go", and nothing happens. With binaries of this Gonzo guy, I did the same, and everything works fine :-/ Do you know who is it (I mean Gonzo)? I would like to ask him, what he did in his binaries. Another question: I would like to build FreeBSD, using latest clang. Currently I have tried to build it latest svn version of FreeBSD: svn://svn.freebsd.org/base/head/ With command: make TARGET_ARCH=armv6 buildworld TARGET_CPUTYPE=cortex-a9 But got next error (repeated several times):/tmp/jemalloc_atomic-22cc38.s:21: Error: garbage following instruction -- `dmb ish' So perhaps, its better to use stable version (10.0.0), but with new clang. Currently, I'm going to copy clang sources from HEAD into 10.0.0 sources tree. But perhaps there is better way to do it? Thanks! -Stepan Ian Lepore wrote: > On Thu, 2014-06-12 at 01:44 +0600, Stepan Dyatkovskiy wrote: >> Hi guys, >> Thank you! I have built it successfully. It was really simple. Currently >> I'm trying to launch with u-boot. Are here any instructions/manual how >> to run kernel with u-boot? >> Thanks! >> -Stepan > > If you compile the dtb into the kernel, you can launch the kernel > directly from u-boot. If you don't, then you need u-boot to launch > ubldr (loader(8) that uses the u-boot API, which requires a u-boot with > the API option enabled). > > The kernel can be loaded at any 1MB-boundary address, and can be > launched by jumping to the load address + 0x100, such as: > > fatload 11000000; go 11000100 > > If you are using a modern u-boot that enables data caches, you need to > turn them off manually, like: > > fatload 11000000 > dcache off; dcache flush > go 11000100 > > This is just a u-boot quirk, it disables caches on bootm and bootelf > commands, but not on a "go" command. > > -- Ian > From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 23:41:00 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D990E681; Thu, 12 Jun 2014 23:41:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E07C2665; Thu, 12 Jun 2014 23:41:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s5CNeqru025559; Thu, 12 Jun 2014 19:40:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s5CNeqPp025555; Thu, 12 Jun 2014 23:40:52 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Jun 2014 23:40:52 GMT Message-Id: <201406122340.s5CNeqPp025555@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 23:41:00 -0000 TB --- 2014-06-12 23:40:36 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-06-12 23:40:36 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-06-12 23:40:36 - starting HEAD tinderbox run for arm/arm TB --- 2014-06-12 23:40:36 - cleaning the object tree TB --- 2014-06-12 23:40:36 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-06-12 23:40:41 - At svn revision 267431 TB --- 2014-06-12 23:40:42 - building world TB --- 2014-06-12 23:40:42 - CROSS_BUILD_TESTING=YES TB --- 2014-06-12 23:40:42 - MAKEOBJDIRPREFIX=/obj TB --- 2014-06-12 23:40:42 - MAKESYSPATH=/src/share/mk TB --- 2014-06-12 23:40:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-06-12 23:40:42 - SRCCONF=/dev/null TB --- 2014-06-12 23:40:42 - TARGET=arm TB --- 2014-06-12 23:40:42 - TARGET_ARCH=arm TB --- 2014-06-12 23:40:42 - TZ=UTC TB --- 2014-06-12 23:40:42 - __MAKE_CONF=/dev/null TB --- 2014-06-12 23:40:42 - cd /src TB --- 2014-06-12 23:40:42 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) [...] cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstIsEmpty.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstLast.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstMember.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstNext.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstOpen.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstPrev.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstRemove.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstReplace.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstSucc.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/stresep.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -static -o make arch.o buf.o compat.o cond.o dir.o for.o hash.o job.o main.o make.o make_malloc.o meta.o parse.o str.o strlist.o suff.o targ.o trace.o util.o var.o lstAppend.o lstAtEnd.o lstAtFront.o lstClose.o lstConcat.o lstDatum.o lstDeQueue.o lstDestroy.o lstDupl.o lstEnQueue.o lstFind.o lstFindFrom.o lstFirst.o lstForEach.o lstForEachFrom.o lstInit.o lstInsert.o lstIsAtEnd.o lstIsEmpty.o lstLast.o lstMember.o lstNext.o lstOpen.o lstPrev.o lstRemove.o lstReplace.o lstSucc.o stresep.o ===> tests (all) ===> tests/archives (all) ===> tests/archives/fmt_44bsd (all) cat /src/usr.bin/bmake/tests/archives/fmt_44bsd/legacy_test.sh | sed >legacy_test.tmp chmod +x legacy_test.tmp mv legacy_test.tmp legacy_test Unknown modifier 't' Syntax error: Unterminated quoted string *** [Kyuafile.auto] Error code 2 Stop in /src/usr.bin/bmake/tests/archives/fmt_44bsd. *** [_sub.all] Error code 1 Stop in /src/usr.bin/bmake/tests/archives. *** [_sub.all] Error code 1 Stop in /src/usr.bin/bmake/tests. *** [_sub.all] Error code 1 Stop in /src/usr.bin/bmake. *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-06-12 23:40:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-06-12 23:40:52 - ERROR: failed to build world TB --- 2014-06-12 23:40:52 - 8.33 user 4.89 system 15.45 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 23:50:47 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D055630; Thu, 12 Jun 2014 23:50:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF1A42780; Thu, 12 Jun 2014 23:50:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s5CNojQT038284; Thu, 12 Jun 2014 19:50:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s5CNojDW038275; Thu, 12 Jun 2014 23:50:45 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Jun 2014 23:50:45 GMT Message-Id: <201406122350.s5CNojDW038275@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 23:50:47 -0000 TB --- 2014-06-12 23:50:27 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-06-12 23:50:27 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-06-12 23:50:27 - starting HEAD tinderbox run for arm/arm TB --- 2014-06-12 23:50:27 - cleaning the object tree TB --- 2014-06-12 23:50:28 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-06-12 23:50:35 - At svn revision 267431 TB --- 2014-06-12 23:50:36 - building world TB --- 2014-06-12 23:50:36 - CROSS_BUILD_TESTING=YES TB --- 2014-06-12 23:50:36 - MAKEOBJDIRPREFIX=/obj TB --- 2014-06-12 23:50:36 - MAKESYSPATH=/src/share/mk TB --- 2014-06-12 23:50:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-06-12 23:50:36 - SRCCONF=/dev/null TB --- 2014-06-12 23:50:36 - TARGET=arm TB --- 2014-06-12 23:50:36 - TARGET_ARCH=arm TB --- 2014-06-12 23:50:36 - TZ=UTC TB --- 2014-06-12 23:50:36 - __MAKE_CONF=/dev/null TB --- 2014-06-12 23:50:36 - cd /src TB --- 2014-06-12 23:50:36 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) [...] cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstIsEmpty.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstLast.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstMember.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstNext.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstOpen.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstPrev.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstRemove.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstReplace.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstSucc.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/stresep.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -static -o make arch.o buf.o compat.o cond.o dir.o for.o hash.o job.o main.o make.o make_malloc.o meta.o parse.o str.o strlist.o suff.o targ.o trace.o util.o var.o lstAppend.o lstAtEnd.o lstAtFront.o lstClose.o lstConcat.o lstDatum.o lstDeQueue.o lstDestroy.o lstDupl.o lstEnQueue.o lstFind.o lstFindFrom.o lstFirst.o lstForEach.o lstForEachFrom.o lstInit.o lstInsert.o lstIsAtEnd.o lstIsEmpty.o lstLast.o lstMember.o lstNext.o lstOpen.o lstPrev.o lstRemove.o lstReplace.o lstSucc.o stresep.o ===> tests (all) ===> tests/archives (all) ===> tests/archives/fmt_44bsd (all) cat /src/usr.bin/bmake/tests/archives/fmt_44bsd/legacy_test.sh | sed >legacy_test.tmp chmod +x legacy_test.tmp mv legacy_test.tmp legacy_test Unknown modifier 't' Syntax error: Unterminated quoted string *** [Kyuafile.auto] Error code 2 Stop in /src/usr.bin/bmake/tests/archives/fmt_44bsd. *** [_sub.all] Error code 1 Stop in /src/usr.bin/bmake/tests/archives. *** [_sub.all] Error code 1 Stop in /src/usr.bin/bmake/tests. *** [_sub.all] Error code 1 Stop in /src/usr.bin/bmake. *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-06-12 23:50:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-06-12 23:50:45 - ERROR: failed to build world TB --- 2014-06-12 23:50:45 - 8.27 user 4.83 system 17.87 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 00:00:46 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C80B74FE; Fri, 13 Jun 2014 00:00:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8480B2820; Fri, 13 Jun 2014 00:00:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s5D00jce051028; Thu, 12 Jun 2014 20:00:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s5D00jZL051022; Fri, 13 Jun 2014 00:00:45 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Jun 2014 00:00:45 GMT Message-Id: <201406130000.s5D00jZL051022@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 00:00:46 -0000 TB --- 2014-06-13 00:00:27 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-06-13 00:00:27 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-06-13 00:00:27 - starting HEAD tinderbox run for arm/arm TB --- 2014-06-13 00:00:27 - cleaning the object tree TB --- 2014-06-13 00:00:28 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-06-13 00:00:35 - At svn revision 267431 TB --- 2014-06-13 00:00:36 - building world TB --- 2014-06-13 00:00:36 - CROSS_BUILD_TESTING=YES TB --- 2014-06-13 00:00:36 - MAKEOBJDIRPREFIX=/obj TB --- 2014-06-13 00:00:36 - MAKESYSPATH=/src/share/mk TB --- 2014-06-13 00:00:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-06-13 00:00:36 - SRCCONF=/dev/null TB --- 2014-06-13 00:00:36 - TARGET=arm TB --- 2014-06-13 00:00:36 - TARGET_ARCH=arm TB --- 2014-06-13 00:00:36 - TZ=UTC TB --- 2014-06-13 00:00:36 - __MAKE_CONF=/dev/null TB --- 2014-06-13 00:00:36 - cd /src TB --- 2014-06-13 00:00:36 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) [...] cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstIsEmpty.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstLast.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstMember.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstNext.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstOpen.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstPrev.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstRemove.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstReplace.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/lst.lib/lstSucc.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/contrib/bmake/stresep.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -static -o make arch.o buf.o compat.o cond.o dir.o for.o hash.o job.o main.o make.o make_malloc.o meta.o parse.o str.o strlist.o suff.o targ.o trace.o util.o var.o lstAppend.o lstAtEnd.o lstAtFront.o lstClose.o lstConcat.o lstDatum.o lstDeQueue.o lstDestroy.o lstDupl.o lstEnQueue.o lstFind.o lstFindFrom.o lstFirst.o lstForEach.o lstForEachFrom.o lstInit.o lstInsert.o lstIsAtEnd.o lstIsEmpty.o lstLast.o lstMember.o lstNext.o lstOpen.o lstPrev.o lstRemove.o lstReplace.o lstSucc.o stresep.o ===> tests (all) ===> tests/archives (all) ===> tests/archives/fmt_44bsd (all) cat /src/usr.bin/bmake/tests/archives/fmt_44bsd/legacy_test.sh | sed >legacy_test.tmp chmod +x legacy_test.tmp mv legacy_test.tmp legacy_test Unknown modifier 't' Syntax error: Unterminated quoted string *** [Kyuafile.auto] Error code 2 Stop in /src/usr.bin/bmake/tests/archives/fmt_44bsd. *** [_sub.all] Error code 1 Stop in /src/usr.bin/bmake/tests/archives. *** [_sub.all] Error code 1 Stop in /src/usr.bin/bmake/tests. *** [_sub.all] Error code 1 Stop in /src/usr.bin/bmake. *** [bmake] Error code 1 Stop in /src. *** [upgrade_checks] Error code 1 Stop in /src. TB --- 2014-06-13 00:00:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-06-13 00:00:45 - ERROR: failed to build world TB --- 2014-06-13 00:00:45 - 8.20 user 4.88 system 17.67 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 02:33:22 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B0E9AF5; Fri, 13 Jun 2014 02:33:22 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [IPv6:2a02:6b8:0:1819::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25CE32370; Fri, 13 Jun 2014 02:33:21 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward4l.mail.yandex.net (Yandex) with ESMTP id CA11B144135F; Fri, 13 Jun 2014 06:33:09 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 58E1FE400B4; Fri, 13 Jun 2014 06:33:09 +0400 (MSK) Received: from unknown (unknown [12.202.173.169]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id GiWYsb5w4I-X7ZCcVqS; Fri, 13 Jun 2014 06:33:08 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 0b2754c0-4540-4173-b73b-b82c5a7be0fd DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402626788; bh=5wpYiuCvPDHm57T2+bwrR9/bTtvt8c23aWq6GSVntIE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=vkpgHl3jAdmQRM5MufjdWyXTDCyjI0+WvU0FULU9PG1Oz7o0M1XuACPBBXrYFO16R HvKALVihFEOMnrbP27ouxToRvXY6sEKZhl//FDjNpckCki7+jZ5i0aHIq3qNxBKF2b HmQxI9+vH/2n/cYytlK/wUJiCXSzn9W7a6S59zsA= Authentication-Results: smtp13.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <539A62E2.20003@narod.ru> Date: Fri, 13 Jun 2014 08:33:06 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Compilation for ARM References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> In-Reply-To: <539A2261.4070705@narod.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 02:33:22 -0000 Hi all, Currently I'm trying to compile kernel, with activated cortex-a9 or a15 options (TARGET_CPUTYPE=cortex-a9). Currently "as" from buildworld gives me tons of "unknown instruction" errors. That happens, I suppose, due to its release date (2007). So I have tried newer versions of binutils: 1. devel/cross-binutils from ports. I have built it with TGTARCH=armv6 and TGTABI=none-eabi. 2. Binutils from http://ftp.gnu.org/gnu/binutils/ I did it in several steps: 1. I have built them. 2. I have entered buildenv: "make TARGET_CPUTYPE=armv6 buildenv" 3. # which as 4. # cp /usr/obj/arm.armv6/usr/src/tmp/usr/bin/as /usr/obj/arm.armv6/usr/src/tmp/usr/bin/as.bak Below I tried several ways to replace as/ld/and-friends: 5. cp /usr/local/bin/armv6-none-eabi-as /usr/obj/arm.armv6/usr/src/tmp/usr/bin/as 6. I have also tried "ln -s" 7. # make KERNCONF=PANDABOARD TARGET_CPUTYPE=cortex-a9 buildkernel Whatever I did, it always ended up with /usr/src/sys/arm/arm/locore.S: Assembler messages: /usr/src/sys/arm/arm/locore.S:79: Error: duplicate .fnstart directive /usr/src/sys/arm/arm/locore.S:255: Error: .fnend directive without .fnstart So, may be, you guys know how to deal with that? Currently I have no idea :-(.. May be sleep a bit :-) Thanks! -Stepan Stepan Dyatkovskiy wrote: > Hi all, > > Thanks for advices! > > That's interesting. I have managed to launch kernel, using these u-boot > binaries: > http://people.freebsd.org/~gonzo/pandaboard/ > > Looks like specific MLO. But I'm not sure. > > With regular linaro u-boot, I load kernel.bin, then try start it with > "go", and nothing happens. With binaries of this Gonzo guy, I did the > same, and everything works fine :-/ Do you know who is it (I mean > Gonzo)? I would like to ask him, what he did in his binaries. > > Another question: > I would like to build FreeBSD, using latest clang. Currently I have > tried to build it latest svn version of FreeBSD: > svn://svn.freebsd.org/base/head/ > With command: > make TARGET_ARCH=armv6 buildworld TARGET_CPUTYPE=cortex-a9 > > But got next error (repeated several > times):/tmp/jemalloc_atomic-22cc38.s:21: Error: garbage following > instruction -- `dmb ish' > > So perhaps, its better to use stable version (10.0.0), but with new > clang. Currently, I'm going to copy clang sources from HEAD into 10.0.0 > sources tree. But perhaps there is better way to do it? > > Thanks! > > -Stepan > > Ian Lepore wrote: >> On Thu, 2014-06-12 at 01:44 +0600, Stepan Dyatkovskiy wrote: >>> Hi guys, >>> Thank you! I have built it successfully. It was really simple. Currently >>> I'm trying to launch with u-boot. Are here any instructions/manual how >>> to run kernel with u-boot? >>> Thanks! >>> -Stepan >> >> If you compile the dtb into the kernel, you can launch the kernel >> directly from u-boot. If you don't, then you need u-boot to launch >> ubldr (loader(8) that uses the u-boot API, which requires a u-boot with >> the API option enabled). >> >> The kernel can be loaded at any 1MB-boundary address, and can be >> launched by jumping to the load address + 0x100, such as: >> >> fatload 11000000; go 11000100 >> >> If you are using a modern u-boot that enables data caches, you need to >> turn them off manually, like: >> >> fatload 11000000 >> dcache off; dcache flush >> go 11000100 >> >> This is just a u-boot quirk, it disables caches on bootm and bootelf >> commands, but not on a "go" command. >> >> -- Ian >> > From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 11:14:00 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD02B51A; Fri, 13 Jun 2014 11:14:00 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 647FF2E58; Fri, 13 Jun 2014 11:13:59 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 338611FE045; Fri, 13 Jun 2014 13:13:51 +0200 (CEST) Message-ID: <539ADD04.4000202@selasky.org> Date: Fri, 13 Jun 2014 13:14:12 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Alan Cox , Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> <5399FB57.8090102@rice.edu> <539A140F.6020107@selasky.org> In-Reply-To: <539A140F.6020107@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 11:14:00 -0000 Hi, Some debugging reveals that the previous element has pindex == 0 aswell. So it turns out there can be multiple pages having same pindex, and then the "mpred" logic falls apart :-( --HPS From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 12:23:03 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5951CA1D; Fri, 13 Jun 2014 12:23:03 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EEA2268B; Fri, 13 Jun 2014 12:23:01 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id CBA2D1FE045; Fri, 13 Jun 2014 14:22:59 +0200 (CEST) Message-ID: <539AED38.2000307@selasky.org> Date: Fri, 13 Jun 2014 14:23:20 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Alan Cox , Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> <5399FB57.8090102@rice.edu> <539A140F.6020107@selasky.org> <539ADD04.4000202@selasky.org> In-Reply-To: <539ADD04.4000202@selasky.org> Content-Type: multipart/mixed; boundary="------------070804040301090402060701" Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 12:23:03 -0000 This is a multi-part message in MIME format. --------------070804040301090402060701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/13/14 13:14, Hans Petter Selasky wrote: > Hi, > > Some debugging reveals that the previous element has pindex == 0 aswell. > So it turns out there can be multiple pages having same pindex, and then > the "mpred" logic falls apart :-( > > --HPS > Hi, Added some random printfs to vm_xxx.c: One observation is that allocated pages are busy, and we are not waiting for then to become non-busy ? I cannot debug this further until coming Monday ... Patch suggestions are welcome! It happens approximately 1 of 2 times during boot. --HPS --------------070804040301090402060701 Content-Type: text/x-patch; name="vm_debug.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_debug.diff" diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c index 35aea6b..931855a 100644 --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -106,6 +106,8 @@ __FBSDID("$FreeBSD$"); #define PFFOR 4 static int vm_fault_additional_pages(vm_page_t, int, int, vm_page_t *, int *); +static int enable_debug; + #define VM_FAULT_READ_BEHIND 8 #define VM_FAULT_READ_MAX (1 + VM_FAULT_READ_AHEAD_MAX) @@ -214,8 +216,17 @@ vm_fault(vm_map_t map, vm_offset_t vaddr, vm_prot_t fault_type, if (map != kernel_map && KTRPOINT(td, KTR_FAULT)) ktrfault(vaddr, fault_type); #endif + if (td->td_proc->p_pid == 18) + enable_debug = 1; + if (enable_debug) + printf("+Fault %p 0x%x\n", (void *)vaddr, (int)fault_type); result = vm_fault_hold(map, trunc_page(vaddr), fault_type, fault_flags, NULL); + if (enable_debug) + printf("-Fault %p 0x%x\n", (void *)vaddr, (int)fault_type); + + if (td->td_proc->p_pid == 18) + enable_debug = 0; #ifdef KTRACE if (map != kernel_map && KTRPOINT(td, KTR_FAULTEND)) ktrfaultend(result); @@ -254,6 +265,10 @@ RetryFault:; fs.map = map; result = vm_map_lookup(&fs.map, vaddr, fault_type, &fs.entry, &fs.first_object, &fs.first_pindex, &prot, &wired); + + if (enable_debug) + printf("Result = %d object = %p index = %d\n", result, fs.first_object, (int)fs.first_pindex); + if (result != KERN_SUCCESS) { if (growstack && result == KERN_INVALID_ADDRESS && map != kernel_map) { @@ -279,6 +294,10 @@ RetryFault:; if (fs.entry->eflags & MAP_ENTRY_IN_TRANSITION && fs.entry->wiring_thread != curthread) { + + if (enable_debug) + printf("Wiring thread\n"); + vm_map_unlock_read(fs.map); vm_map_lock(fs.map); if (vm_map_lookup_entry(fs.map, vaddr, &fs.entry) && @@ -328,7 +347,12 @@ RetryFault:; /* * See if page is resident */ + fs.m = vm_page_lookup(fs.object, fs.pindex); + + if (enable_debug) + printf("Page lookup %p %d = %p\n", fs.object, (int)fs.pindex, fs.m); + if (fs.m != NULL) { /* * Wait/Retry if the page is busy. We have to do this @@ -426,15 +450,26 @@ RetryFault:; if (fs.object->type != OBJT_VNODE && fs.object->backing_object == NULL) alloc_req |= VM_ALLOC_ZERO; + fs.m = vm_page_alloc(fs.object, fs.pindex, alloc_req); + printf("Severe alloc = %p\n", fs.m); + + if (enable_debug && fs.m != NULL && vm_page_busied(fs.m)) + printf("Page is BUSY\n"); } if (fs.m == NULL) { unlock_and_deallocate(&fs); VM_WAITPFAULT; goto RetryFault; - } else if (fs.m->valid == VM_PAGE_BITS_ALL) + } else if (fs.m->valid == VM_PAGE_BITS_ALL) { + if (enable_debug) + printf("All bits\n"); break; + } else { + if (enable_debug) + printf("fs.m->valid = 0x%08x\n", (int)fs.m->valid); + } } readrest: @@ -448,6 +483,9 @@ readrest: * at the same time. */ if (TRYPAGER) { + + printf("Try pager\n"); + int rv; u_char behavior = vm_map_entry_behavior(fs.entry); --------------070804040301090402060701 Content-Type: text/plain; charset=us-ascii; name="vm_debug.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_debug.txt" +Fault 0x31000 0x3 Result = 0 object = 0xc1a2b280 index = 2 Page lookup 0xc1a2b280 2 = 0 Severe alloc = 0xc09b6ef0 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2b960 2 = 0xc09b5e60 -Fault 0x31000 0x3 +Fault 0xbffff000 0x3 Result = 0 object = 0xc1a2bdc0 index = 31 Page lookup 0xc1a2bdc0 31 = 0 Severe alloc = 0xc09b6f40 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2b460 31 = 0xc09b5f00 -Fault 0xbffff000 0x3 +Fault 0x20055000 0x3 Result = 0 object = 0xc1a2b140 index = 4 Page lookup 0xc1a2b140 4 = 0 Severe alloc = 0xc09b6f90 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2b640 4 = 0xc09b5780 -Fault+Fault 0x20156000 0x5 Result = 0 object = 0xc1a2bf00 index = 129 Page lookup 0xc1a2bf00 129 = 0xc09ad4e0 -Fault 0 0x20055000 0x3 +Fault 0x2082d000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1069 Page lookup 0xc1a2b8c0 1069 = 0 Severe alloc = 0xc0a19c80 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2c960 1069 = 0xc09bac80 -Fault 0x2082d000 0x3 +Fault 0x2082c000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1068 Page lookup 0xc1a2b8c0 1068 = 0 Severe alloc = 0xc0a19c30 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2c960 1068 = 0xc09bac30 -Fault 0x2082c000 0x3 +Fault 0x20400000 0x3 Result = 0 object = 0xc1a2b8c0 index = 0 Page lookup 0xc1a2b8c0 0 = 0 Severe alloc = 0xc0a1de70 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2c960 0 = 0xc09afe70 -Fault 0x20400000 0x3 +Fault 0x20843000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1091 Page lookup 0xc1a2b8c0 1091 = 0 Severe alloc = 0xc0a1a360 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2c960 1091 = 0xc09bb360 -Fault 0x20843000 0x3 x20156000 0x5 Severe alloc = 0xc09b7030 Severe alloc = 0xc09b7080 Severe alloc = 0xc09b70d0 Severe alloc = 0xc09b7120 Severe alloc = 0xc0a22f60 Severe alloc = 0xc0a27e70 Severe alloc = 0xc0a2ce70 Severe alloc = 0xc09b7670 Severe alloc = 0xc0a23370 Severe alloc = 0xc0a23370 Severe alloc = 0xc0a23320 Severe alloc = 0xc0a23280 Severe alloc = 0xc0a23c30 Severe alloc = 0xc0a23c80 Severe alloc = 0xc0a24360 Severe alloc = 0xc0a31e70 Severe alloc = 0xc09b6fe0 Severe alloc = 0xc09b5f00 Severe alloc = 0xc09b5780 Severe alloc = 0xc09b7850 Severe alloc = 0xc09b78a0 Severe alloc = 0xc09b5e10 Severe alloc = 0xc09b5e60 Severe alloc = 0xc09b7670 Severe alloc = 0xc09b76c0 Severe alloc = 0xc09b7030 Severe alloc = 0xc09b7080 Severe alloc = 0xc09b70d0 Severe alloc = 0xc09b7120 Severe alloc = 0xc09b82f0 Severe alloc = 0xc09b8340 Try pager Severe alloc = 0xc09b8390 Severe alloc = 0xc09b83e0 Try pager Severe alloc = 0xc09b8430 Try pager Severe alloc = 0xc09b8750 Severe alloc = 0xc09b87a0 Severe alloc = 0xc09b87f0 Severe alloc = 0xc09b8840 Severe alloc = 0xc09b8890 Severe alloc = 0xc09b88e0 Severe alloc = 0xc09b8930 Severe alloc = 0xc09b8980 Severe alloc = 0xc09b89d0 Severe alloc = 0xc09b8a20 Severe alloc = 0xc09b8a70 Severe alloc = 0xc09b8ac0 Severe alloc = 0xc09b8b10 Severe alloc = 0xc09b8b60 Severe alloc = 0xc09b8bb0 Severe alloc = 0xc09b8c00 Severe alloc = 0xc09b8c50 Severe alloc = 0xc09b8ca0 Severe alloc = 0xc09b8cf0 Severe alloc = 0xc09b8d40 Severe alloc = 0xc09b8d90 Severe alloc = 0xc09b8de0 Severe alloc = 0xc09b8e30 Severe alloc = 0xc09b8e80 Severe alloc = 0xc0a36e70 Severe alloc = 0xc0a36ec0 Severe alloc = 0xc0a36f10 Severe alloc = 0xc0a36f60 Severe alloc = 0xc0a36fb0 Severe alloc = 0xc0a37000 Severe alloc = 0xc0a37050 Severe alloc = 0xc0a370a0 Severe alloc = 0xc0a370f0 Severe alloc = 0xc09b8ed0 Severe alloc = 0xc0a3be70 Severe alloc = 0xc0a3bec0 Severe alloc = 0xc0a3bf10 Severe alloc = 0xc0a3bf60 Severe alloc = 0xc0a3bfb0 Severe alloc = 0xc0a3c000 Severe alloc = 0xc0a3c050 Severe alloc = 0xc0a3c0a0 Severe alloc = 0xc0a3c0f0 Severe alloc = 0xc0a3c140 Severe alloc = 0xc0a3c190 Severe alloc = 0xc0a3c1e0 Severe alloc = 0xc0a3c230 Severe alloc = 0xc0a3c280 Severe alloc = 0xc0a3c2d0 Severe alloc = 0xc0a3c320 Severe alloc = 0xc0a3c370 Severe alloc = 0xc0a3c3c0 Severe alloc = 0xc0a3c410 Severe alloc = 0xc0a3c460 Severe alloc = 0xc0a3c4b0 Severe alloc = 0xc09b8f20 Try pager Severe alloc = 0xc0a3c500 Severe alloc = 0xc0a3c550 Severe alloc = 0xc0a3c5a0 Severe alloc = 0xc0a3c5f0 Severe alloc = 0xc0a3c640 Severe alloc = 0xc0a3c690 Severe alloc = 0xc0a3c6e0 Severe alloc = 0xc0a3c730 Severe alloc = 0xc0a3c780 Severe alloc = 0xc0a3c7d0 Severe alloc = 0xc0a3c820 Severe alloc = 0xc0a3c870 Severe alloc = 0xc0a3c8c0 Severe alloc = 0xc0a3c910 Severe alloc = 0xc0a3c960 Severe alloc = 0xc0a3c9b0 Severe alloc = 0xc0a3ca00 Severe alloc = 0xc0a43bc0 Severe alloc = 0xc0a43c10 +Fault 0x20052000 0x3 Result = 0 object = 0xc1a2b140 index = 1 Page lookup 0xc1a2b140 1 = 0xc09b5730 -Fault 0x20052000 0x3 +Fault 0x2f000 0x3 Result = 0 object = 0xc1a2b280 index = 0 Page lookup 0xc1a2b280 0 = 0xc09b57d0 -Fault 0x2f000 0x3 +Fault 0x208ed000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1261 Page lookup 0xc1a2b8c0 1261 = 0xc09be880 -Fault 0x208ed000 0x3 +Fault 0x208ee000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1262 Page lookup 0xc1a2b8c0 1262 = 0xc09be8d0 -Fault 0x208ee000 0x3 +Fault 0x20800000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1024 Page lookup 0xc1a2b8c0 1024 = 0xc09b9e70 -Fault 0x20800000 0x3 +Fault 0x20802000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1026 Page lookup 0xc1a2b8c0 1026 = 0xc09b9f10 -Fault 0x20802000 0x3 +Fault 0x208fe000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1278 Page lookup 0xc1a2b8c0 1278 = 0 Severe alloc = 0xc09bedd0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x208fe000 0x1 +Fault 0x208ff000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1279 Page lookup 0xc1a2b8c0 1279 = 0 Severe alloc = 0xc09bee20 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x208ff000 0x1 +Fault 0x20900000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1280 Page lookup 0xc1a2b8c0 1280 = 0 Severe alloc = 0xc0a45e70 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20900000 0x1 +Fault 0x20901000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1281 Page lookup 0xc1a2b8c0 1281 = 0 Severe alloc = 0xc0a45ec0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20901000 0x1 +Fault 0x20902000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1282 Page lookup 0xc1a2b8c0 1282 = 0 Severe alloc = 0xc0a45f10 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20902000 0x1 +Fault 0x20903000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1283 Page lookup 0xc1a2b8c0 1283 = 0 Severe alloc = 0xc0a45f60 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20903000 0x1 +Fault 0x20904000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1284 Page lookup 0xc1a2b8c0 1284 = 0 Severe alloc = 0xc0a45fb0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20904000 0x1 +Fault 0x20905000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1285 Page lookup 0xc1a2b8c0 1285 = 0 Severe alloc = 0xc0a46000 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20905000 0x1 +Fault 0x20906000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1286 Page lookup 0xc1a2b8c0 1286 = 0 Severe alloc = 0xc0a46050 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20906000 0x1 +Fault 0x20907000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1287 Page lookup 0xc1a2b8c0 1287 = 0 Severe alloc = 0xc0a460a0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20907000 0x1 +Fault 0x20908000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1288 Page lookup 0xc1a2b8c0 1288 = 0 Severe alloc = 0xc0a460f0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20908000 0x1 +Fault 0x20909000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1289 Page lookup 0xc1a2b8c0 1289 = 0 Severe alloc = 0xc0a46140 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20909000 0x1 +Fault 0x2090a000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1290 Page lookup 0xc1a2b8c0 1290 = 0 Severe alloc = 0xc0a46190 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2090a000 0x1 +Fault 0x2090b000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1291 Page lookup 0xc1a2b8c0 1291 = 0 Severe alloc = 0xc0a461e0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2090b000 0x1 +Fault 0x2090c000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1292 Page lookup 0xc1a2b8c0 1292 = 0 Severe alloc = 0xc0a46230 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2090c000 0x1 +Fault 0x2090d000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1293 Page lookup 0xc1a2b8c0 1293 = 0 Severe alloc = 0xc0a46280 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2090d000 0x1 +Fault 0x2090e000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1294 Page lookup 0xc1a2b8c0 1294 = 0 Severe alloc = 0xc0a462d0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2090e000 0x1 +Fault 0x2090f000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1295 Page lookup 0xc1a2b8c0 1295 = 0 Severe alloc = 0xc0a46320 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2090f000 0x1 +Fault 0x20910000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1296 Page lookup 0xc1a2b8c0 1296 = 0 Severe alloc = 0xc0a46370 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20910000 0x1 +Fault 0x20911000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1297 Page lookup 0xc1a2b8c0 1297 = 0 Severe alloc = 0xc0a463c0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20911000 0x1 +Fault 0x20912000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1298 Page lookup 0xc1a2b8c0 1298 = 0 Severe alloc = 0xc0a46410 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20912000 0x1 +Fault 0x20913000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1299 Page lookup 0xc1a2b8c0 1299 = 0 Severe alloc = 0xc0a46460 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20913000 0x1 +Fault 0x20914000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1300 Page lookup 0xc1a2b8c0 1300 = 0 Severe alloc = 0xc0a464b0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20914000 0x1 +Fault 0x20915000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1301 Page lookup 0xc1a2b8c0 1301 = 0 Severe alloc = 0xc0a46500 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20915000 0x1 +Fault 0x20916000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1302 Page lookup 0xc1a2b8c0 1302 = 0 Severe alloc = 0xc0a46550 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20916000 0x1 +Fault 0x20917000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1303 Page lookup 0xc1a2b8c0 1303 = 0 Severe alloc = 0xc0a465a0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20917000 0x1 +Fault 0x20918000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1304 Page lookup 0xc1a2b8c0 1304 = 0 Severe alloc = 0xc0a465f0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20918000 0x1 +Fault 0x20919000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1305 Page lookup 0xc1a2b8c0 1305 = 0 Severe alloc = 0xc0a46640 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x20919000 0x1 +Fault 0x2091a000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1306 Page lookup 0xc1a2b8c0 1306 = 0 Severe alloc = 0xc0a46690 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2091a000 0x1 +Fault 0x2091b000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1307 Page lookup 0xc1a2b8c0 1307 = 0 Severe alloc = 0xc0a466e0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2091b000 0x1 +Fault 0x2091c000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1308 Page lookup 0xc1a2b8c0 1308 = 0 Severe alloc = 0xc0a46730 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2091c000 0x1 +Fault 0x2091d000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1309 Page lookup 0xc1a2b8c0 1309 = 0 Severe alloc = 0xc0a46780 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2091d000 0x1 +Fault 0x2091e000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1310 Page lookup 0xc1a2b8c0 1310 = 0 Severe alloc = 0xc0a467d0 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2091e000 0x1 +Fault 0x20809000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1033 Page lookup 0xc1a2b8c0 1033 = 0xc09ba140 -Fault 0x20809000 0x3 +Fault 0x2080f000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1039 Page lookup 0xc1a2b8c0 1039 = 0xc09ba320 -Fault 0x2080f000 0x3 +Fault 0x2086a000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1130 Page lookup 0xc1a2b8c0 1130 = 0xc09bbf90 -Fault 0x2086a000 0x3 +Fault 0x2086c000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1132 Page lookup 0xc1a2b8c0 1132 = 0xc09bc030 -Fault 0x2086c000 0x3 +Fault 0x20807000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1031 Page lookup 0xc1a2b8c0 1031 = 0xc09ba0a0 -Fault 0x20807000 0x3 +Fault 0x20812000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1042 Page lookup 0xc1a2b8c0 1042 = 0xc09ba410 -Fault 0x20812000 0x3 +Fault 0x2091f000 0x1 Result = 0 object = 0xc1a2b8c0 index = 1311 Page lookup 0xc1a2b8c0 1311 = 0 Severe alloc = 0xc0a46820 Page is BUSY fs.m->valid = 0x00000000 -Fault 0x2091f000 0x1 +Fault 0x20810000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1040 Page lookup 0xc1a2b8c0 1040 = 0xc09ba370 -Fault 0x20810000 0x3 +Fault 0x208a3000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1187 Page lookup 0xc1a2b8c0 1187 = 0xc09bd160 -Fault 0x208a3000 0x3 +Fault 0x20811000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1041 Page lookup 0xc1a2b8c0 1041 = 0xc09ba3c0 -Fault 0x20811000 0x3 +Fault 0x20813000 0x3 Result = 0 object = 0xc1a2b8c0 index = 1043 Page lookup 0xc1a2b8c0 1043 = 0xc09ba460 -Fault 0x20813000 0x3 +Fault 0x2080d000 0x3 Result = 0 object = 0xc1a700a0 index = 1037 Page lookup 0xc1a700a0 1037 = 0 Severe alloc = 0xc0a4b280 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2b8c0 1037 = 0xc0a19280 -Fault 0x2080d000 0x3 +Fault 0x30000 0x3 Result = 0 object = 0xc1a2b960 index = 1 Page lookup 0xc1a2b960 1 = 0 Severe alloc = 0xc09b8700 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2b280 1 = 0xc09b6c20 -Fault 0x30000 0x3 +Fault 0x31000 0x3 Result = 0 object = 0xc1a2b960 index = 2 Page lookup 0xc1a2b960 2 = 0 Severe alloc = 0xc09b7800 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2b280 2 = 0xc09b6ef0 -Fault 0x31000 0x3 +Fault 0xbffff000 0x3 Result = 0 object = 0xc1a2b0a0 index = 31 Page l+Fault 0x20156000 0x5 Result = 0 object = 0xc1a2bf00 index = 129 Page lookup 0xc1a2bf00 129 = 0xc09ad4e0 -Fault 0x20156000 0x5 +Fault 0x17000 0x5 Result = 0 object = 0xc1a2c6e0 index = 15 Page lookup 0xc1a2c6e0 15 = 0xc0993a40 -Fault 0x17000 0x5 +Fault 0x31000 0x1 Result = 0 object = 0xc1a2b280 index = 2 Page lookup 0xc1a2b280 2 = 0xc09b6ef0 -Fault 0x31000 0x1 +Fault 0x31000 0x3 Result = 0 object = 0xc1a2bd20 index = 2 Page lookup 0xc1a2bd20 2 = 0 Severe alloc = 0xc09b8ed0 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2b280 2 = 0xc09b6ef0 -Fault 0x31000 0x3 +Fault 0xbffff000 0x3 Result = 0 object = 0xc1a2c960 index = 31 Page lookup 0xc1a2c960 31 = 0 Severe alloc = 0xc09b5780 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2bdc0 31 = 0xc09b6f40 -Fault 0xbffff000 0x3 +Fault 0xa000 0x5 Result = 0 object = 0xc1a2c6e0 index = 2 Page lookup 0xc1a2c6e0 2 = 0xc0993630 -Fault 0xa000 0x5 +Fault 0x20217000 0x5 Result = 0 object = 0xc1a2bf00 index = 322 Page lookup 0xc1a2bf00 322 = 0xc09aba50 -Fault 0x20217000 0x5 ookup 0xc1a2b0a0 31 = 0 Severe alloc = 0xc09b8390 Page is BUSY fs.m->valid = 0x00000000 Page lookup 0xc1a2bdc0 31 = 0xc09b6f40 -Fault 0xbffff000 0x3 Severe alloc = 0xc09b5f00 Severe alloc = 0xc09b82f0 Severe alloc = 0xc0a4ff60 Severe alloc = 0xc0a54e70 Severe alloc = 0xc0a59e70 Severe alloc = 0xc09b6fe0 Severe alloc = 0xc0a50370 Severe alloc = 0xc0a50370 Severe alloc = 0xc0a50320 Severe alloc = 0xc0a50280 Severe alloc = 0xc0a53160 Severe alloc = 0xc0a54dd0 Severe alloc = 0xc0a50c30 Severe alloc = 0xc0a50c30 Severe alloc = 0xc0a500f0 Severe alloc = 0xc0a500f0 Severe alloc = 0xc0a50460 Severe alloc = 0xc0a500a0 Severe alloc = 0xc0a50410 Severe alloc = 0xc0a504b0 Severe alloc = 0xc0a50500 Severe alloc = 0xc09b8e80 Severe alloc = 0xc0a4ffb0 Severe alloc = 0xc0a50c80 Severe alloc = 0xc0a50cd0 Severe alloc = 0xc0a50d20 Severe alloc = 0xc0a50d70 Severe alloc = 0xc0a50dc0 Severe alloc = 0xc0a50e10 Severe alloc = 0xc0a50e60 Severe alloc = 0xc0a4fe70 Severe alloc = 0xc0a509b0 Severe alloc = 0xc0a50a00 Severe alloc = 0xc0a50a50 Severe alloc = 0xc0a50aa0 Severe alloc = 0xc0a50af0 Severe alloc = 0xc0a50b40 Severe alloc = 0xc0a50b90 Severe alloc = 0xc0a50be0 Severe alloc = 0xc0a4ff10 Severe alloc = 0xc0a5ee70 Severe alloc = 0xc0a64000 Severe alloc = 0xc0a68e70 Severe alloc = 0xc0a68ec0 Severe alloc = 0xc0a503c0 Severe alloc = 0xc0a68f10 Severe alloc = 0xc0a68f60 Severe alloc = 0xc0a68fb0 Severe alloc = 0xc0a69000 Severe alloc = 0xc0a69050 Severe alloc = 0xc0a50eb0 Severe alloc = 0xc0a51fe0 Severe alloc = 0xc0a51fe0 Severe alloc = 0xc09b7850 Severe alloc = 0xc0a53020 Severe alloc = 0xc0a50140 Severe alloc = 0xc0a51360 Severe alloc = 0xc0a51360 Severe alloc = 0xc0a51b30 Severe alloc = 0xc0a51b30 Severe alloc = 0xc0a51770 Severe alloc = 0xc0a51770 Severe alloc = 0xc0a510e0 Severe alloc = 0xc0a510e0 Severe alloc = 0xc0a54880 Severe alloc = 0xc0a54880 Severe alloc = 0xc0a548d0 Severe alloc = 0xc09b78a0 Enlarging root partition Severe alloc = 0xc0a6de70 Severe alloc = 0xc0a43da0 Severe alloc = 0xc09b7030 Severe alloc = 0xc09b7080 Severe alloc = 0xc09b7670 Severe alloc = 0xc09b70d0 Severe alloc = 0xc09b7120 Severe alloc = 0xc09b8cf0 Severe alloc = 0xc09b8d40 Severe alloc = 0xc09b8d90 Severe alloc = 0xc09b8de0 Severe alloc = 0xc0a43df0 Severe alloc = 0xc0a43e40 Severe alloc = 0xc0a43e90 Severe alloc = 0xc0a43ee0 Try pager Severe alloc = 0xc0a43f30 Severe alloc = 0xc0a43f80 Try pager Severe alloc = 0xc0a44020 Try pager Severe alloc = 0xc09b8840 Try pager Severe alloc = 0xc09b8890 Try pager Severe alloc = 0xc09b88e0 Try pager Severe alloc = 0xc09b8930 Try pager Severe alloc = 0xc09b89d0 Try pager Severe alloc = 0xc09b8c50 Severe alloc = 0xc0a44070 Severe alloc = 0xc0a440c0 Severe alloc = 0xc0a73500 Severe alloc = 0xc0a73550 Severe alloc = 0xc0a44110 Severe alloc = 0xc0a44160 Severe alloc = 0xc0a441b0 Severe alloc = 0xc0a44200 Severe alloc = 0xc0a735a0 Severe alloc = 0xc0a73640 Severe alloc = 0xc0a73690 Severe alloc = 0xc0a736e0 Severe alloc = 0xc0a73730 Severe alloc = 0xc0a73780 Severe alloc = 0xc0a737d0 Severe alloc = 0xc0a73820 Severe alloc = 0xc0a73870 Severe alloc = 0xc0a44250 Severe alloc = 0xc0a442a0 Severe alloc = 0xc0a442f0 Severe alloc = 0xc0a44340 Severe alloc = 0xc0a44390 Severe alloc = 0xc0a443e0 Severe alloc = 0xc0a44430 Severe alloc = 0xc0a73460 Severe alloc = 0xc0a734b0 Severe alloc = 0xc0a44480 Severe alloc = 0xc0a72f10 Severe alloc = 0xc0a73410 Severe alloc = 0xc0a77e70 Severe alloc = 0xc0a77ec0 Severe alloc = 0xc0a77f10 Severe alloc = 0xc0a77f60 Severe alloc = 0xc0a77fb0 Severe alloc = 0xc0a78000 Severe alloc = 0xc0a78050 Severe alloc = 0xc0a780a0 Severe alloc = 0xc0a780f0 Severe alloc = 0xc0a73140 Severe alloc = 0xc0a444d0 Severe alloc = 0xc0a72ec0 Severe alloc = 0xc0a7ce70 Severe alloc = 0xc0a7cec0 Severe alloc = 0xc0a7cf10 Severe alloc = 0xc0a7cf60 Severe alloc = 0xc0a7cfb0 Severe alloc = 0xc0a7d000 Severe alloc = 0xc0a7d050 Severe alloc = 0xc0a7d0a0 Severe alloc = 0xc0a7d0f0 Severe alloc = 0xc0a7d140 Severe alloc = 0xc0a7d190 Severe alloc = 0xc0a7d1e0 Severe alloc = 0xc0a7d230 Severe alloc = 0xc0a7d280 Severe alloc = 0xc0a7d2d0 Severe alloc = 0xc0a7d320 Severe alloc = 0xc0a7d370 Severe alloc = 0xc0a7d3c0 Severe alloc = 0xc0a7d410 Severe alloc = 0xc0a7d460 Severe alloc = 0xc0a447f0 Severe alloc = 0xc0a44840 Try pager Severe alloc = 0xc0a44890 Severe alloc = 0xc0a448e0 Try pager Severe alloc = 0xc0a44930 Severe alloc = 0xc0a44980 Try pager Severe alloc = 0xc0a44930 Try pager Severe alloc = 0xc0a44b60 Severe alloc = 0xc0a7d4b0 Severe alloc = 0xc0a7d500 Severe alloc = 0xc0a7d550 Severe alloc = 0xc0a7d5a0 Severe alloc = 0xc0a7d5f0 Severe alloc = 0xc0a7d640 Severe alloc = 0xc0a7d690 Severe alloc = 0xc0a7d6e0 Severe alloc = 0xc0a7d730 Severe alloc = 0xc0a7d780 Severe alloc = 0xc0a7d7d0 Severe alloc = 0xc0a7d820 Severe alloc = 0xc0a7d870 Severe alloc = 0xc0a7d8c0 Severe alloc = 0xc0a7d910 Severe alloc = 0xc0a7d960 Severe alloc = 0xc0a7d9b0 Severe alloc = 0xc0a7da00 Severe alloc = 0xc0a7da50 Severe alloc = 0xc0a7daa0 Severe alloc = 0xc0a7daf0 Severe alloc = 0xc0a7db40 Severe alloc = 0xc0a7db90 Severe alloc = 0xc0a7dbe0 Severe alloc = 0xc0a7dc30 Severe alloc = 0xc0a7dc80 Severe alloc = 0xc0a7dcd0 Severe alloc = 0xc0a7dd20 Severe alloc = 0xc0a44bb0 Try pager Severe alloc = 0xc0a44f70 Try pager Severe alloc = 0xc0a7dd70 Severe alloc = 0xc0a7ddc0 Severe alloc = 0xc0a7de10 Severe alloc = 0xc0a7de60 Severe alloc = 0xc0a7deb0 Severe alloc = 0xc0a7df00 Severe alloc = 0xc0a7df50 Severe alloc = 0xc0a7dfa0 Severe alloc = 0xc0a7dff0 Severe alloc = 0xc0a7e040 Severe alloc = 0xc0a7e090 Severe alloc = 0xc0a7e0e0 Severe alloc = 0xc0a7e130 Severe alloc = 0xc0a7e180 Severe alloc = 0xc0a7e1d0 Severe alloc = 0xc0a7e220 Severe alloc = 0xc0a7e270 Severe alloc = 0xc0a7e2c0 Severe alloc = 0xc0a7e310 Severe alloc = 0xc0a7e360 Severe alloc = 0xc0a45330 mmcsd0s2 resized Severe alloc = 0xc0a81e70 Severe alloc = 0xc0a444d0 Severe alloc = 0xc0a44b60 Severe alloc = 0xc0a44890 Severe alloc = 0xc0a43f30 Severe alloc = 0xc09b7670 Severe alloc = 0xc0a43e90 Severe alloc = 0xc0a452e0 Severe alloc = 0xc09b8c50 Severe alloc = 0xc09b8ca0 Severe alloc = 0xc0a43df0 Severe alloc = 0xc0a43e40 Severe alloc = 0xc0a43d50 Severe alloc = 0xc0a43da0 Severe alloc = 0xc0a44430 Severe alloc = 0xc0a44480 Severe alloc = 0xc0a45380 Severe alloc = 0xc0a453d0 Severe alloc = 0xc0a87500 Severe alloc = 0xc0a87550 Severe alloc = 0xc0a45420 Severe alloc = 0xc0a442f0 Severe alloc = 0xc0a44340 Severe alloc = 0xc0a44390 Severe alloc = 0xc0a875a0 Severe alloc = 0xc0a87640 Severe alloc = 0xc0a87690 Severe alloc = 0xc0a876e0 Severe alloc = 0xc0a87730 Severe alloc = 0xc0a87780 Severe alloc = 0xc0a877d0 Severe alloc = 0xc0a87820 Severe alloc = 0xc0a87870 Severe alloc = 0xc0a443e0 Severe alloc = 0xc09b7030 Severe alloc = 0xc09b7080 Severe alloc = 0xc09b70d0 Severe alloc = 0xc09b7120 Severe alloc = 0xc09b8cf0 Severe alloc = 0xc09b8d40 Severe alloc = 0xc0a87460 Severe alloc = 0xc0a874b0 Severe alloc = 0xc09b8d90 Severe alloc = 0xc0a86f10 Severe alloc = 0xc0a87410 Severe alloc = 0xc0a8be70 Severe alloc = 0xc0a8bec0 Severe alloc = 0xc0a8bf10 Severe alloc = 0xc0a8bf60 Severe alloc = 0xc0a8bfb0 Severe alloc = 0xc0a8c000 Severe alloc = 0xc0a8c050 Severe alloc = 0xc0a8c0a0 Severe alloc = 0xc0a8c0f0 Severe alloc = 0xc0a87140 Severe alloc = 0xc09b8de0 Severe alloc = 0xc0a86ec0 Severe alloc = 0xc0a90e70 Severe alloc = 0xc0a90ec0 Severe alloc = 0xc0a90f10 Severe alloc = 0xc0a90f60 Severe alloc = 0xc0a90fb0 Severe alloc = 0xc0a91000 Severe alloc = 0xc0a91050 Severe alloc = 0xc0a910a0 Severe alloc = 0xc0a910f0 Severe alloc = 0xc0a91140 Severe alloc = 0xc0a91190 Severe alloc = 0xc0a911e0 Severe alloc = 0xc0a91230 Severe alloc = 0xc0a91280 Severe alloc = 0xc0a912d0 Severe alloc = 0xc0a91320 Severe alloc = 0xc0a91370 Severe alloc = 0xc0a913c0 Severe alloc = 0xc0a91410 Severe alloc = 0xc0a91460 Severe alloc = 0xc0a44070 Severe alloc = 0xc0a440c0 Severe alloc = 0xc0a44110 Severe alloc = 0xc0a914b0 Severe alloc = 0xc0a91500 Severe alloc = 0xc0a91550 Severe alloc = 0xc0a915a0 Severe alloc = 0xc0a915f0 Severe alloc = 0xc0a91640 Severe alloc = 0xc0a91690 Severe alloc = 0xc0a916e0 Severe alloc = 0xc0a91730 Severe alloc = 0xc0a91780 Severe alloc = 0xc0a917d0 Severe alloc = 0xc0a91820 Severe alloc = 0xc0a91870 Severe alloc = 0xc0a918c0 Severe alloc = 0xc0a91910 Severe alloc = 0xc0a91960 Severe alloc = 0xc0a919b0 Severe alloc = 0xc0a91a00 Severe alloc = 0xc0a91a50 Severe alloc = 0xc0a91aa0 Severe alloc = 0xc0a91af0 Severe alloc = 0xc0a91b40 Severe alloc = 0xc0a91b90 Severe alloc = 0xc0a91be0 Severe alloc = 0xc0a91c30 Severe alloc = 0xc0a91c80 Severe alloc = 0xc0a91cd0 Severe alloc = 0xc0a91d20 Severe alloc = 0xc0a91d70 Severe alloc = 0xc0a91dc0 Severe alloc = 0xc0a91e10 Severe alloc = 0xc0a91e60 Severe alloc = 0xc0a91eb0 Severe alloc = 0xc0a91f00 Severe alloc = 0xc0a91f50 Severe alloc = 0xc0a91fa0 Severe alloc = 0xc0a91ff0 Severe alloc = 0xc0a92040 Severe alloc = 0xc0a92090 Severe alloc = 0xc0a920e0 Severe alloc = 0xc0a92130 Severe alloc = 0xc0a92180 Severe alloc = 0xc0a921d0 Severe alloc = 0xc0a92220 Severe alloc = 0xc0a92270 Severe alloc = 0xc0a922c0 Severe alloc = 0xc0a92310 Severe alloc = 0xc0a92360 Severe alloc = 0xc0a86fb0 Severe alloc = 0xc0a441b0 gpart: autofill: No space left on device Severe alloc = 0xc0a95e70 Severe alloc = 0xc0a44430 Severe alloc = 0xc0a44480 Severe alloc = 0xc09b8c50 Severe alloc = 0xc09b8ca0 Severe alloc = 0xc0a447f0 Severe alloc = 0xc0a43df0 Severe alloc = 0xc0a43e40 Severe alloc = 0xc0a43d50 Severe alloc = 0xc0a43da0 Severe alloc = 0xc0a44070 Severe alloc = 0xc0a440c0 Severe alloc = 0xc0a44110 Severe alloc = 0xc0a44160 Severe alloc = 0xc09b7030 Severe alloc = 0xc09b70d0 Severe alloc = 0xc09b7120 Severe alloc = 0xc0a442f0 Severe alloc = 0xc0a44340 Severe alloc = 0xc0a44390 Severe alloc = 0xc0a443e0 Severe alloc = 0xc0a45330 Severe alloc = 0xc0a45380 Severe alloc = 0xc0a453d0 Severe alloc = 0xc0a45420 Severe alloc = 0xc09b8cf0 Severe alloc = 0xc09b8d40 Severe alloc = 0xc09b8d90 Severe alloc = 0xc09b8de0 Severe alloc = 0xc0a45470 Severe alloc = 0xc0a454c0 Severe alloc = 0xc0a45510 Severe alloc = 0xc0a45560 Severe alloc = 0xc0a455b0 Severe alloc = 0xc0a45600 Severe alloc = 0xc0a45650 Severe alloc = 0xc0a456a0 Severe alloc = 0xc0a456f0 Severe alloc = 0xc0a45740 Severe alloc = 0xc0a45790 Severe alloc = 0xc0a9ae70 Severe alloc = 0xc0a9aec0 Severe alloc = 0xc0a9af10 Severe alloc = 0xc0a9af60 Severe alloc = 0xc0a9afb0 Severe alloc = 0xc0a9b000 Severe alloc = 0xc0a9b050 Severe alloc = 0xc0a9b0a0 Severe alloc = 0xc0a9b0f0 Severe alloc = 0xc0a457e0 Severe alloc = 0xc0a45830 Severe alloc = 0xc0a9fe70 Severe alloc = 0xc0a9fec0 Severe alloc = 0xc0a9ff10 Severe alloc = 0xc0a9ff60 Severe alloc = 0xc0a9ffb0 Severe alloc = 0xc0aa0000 Severe alloc = 0xc0aa0050 Severe alloc = 0xc0aa00a0 Severe alloc = 0xc0aa00f0 Severe alloc = 0xc0aa0140 Severe alloc = 0xc0aa0190 Severe alloc = 0xc0aa01e0 Severe alloc = 0xc0aa0230 Severe alloc = 0xc0aa0280 Severe alloc = 0xc0aa02d0 Severe alloc = 0xc0aa0320 Severe alloc = 0xc0aa0370 Severe alloc = 0xc0aa03c0 Severe alloc = 0xc0aa0410 Severe alloc = 0xc0a45880 Severe alloc = 0xc0a458d0 Severe alloc = 0xc0a45920 Severe alloc = 0xc0a45970 Severe alloc = 0xc0a459c0 growfs: Severe alloc = 0xc0a45a10 requested size 3.6GB is not larger than the current filesystem size 3.6GB +Fault 0x208a3000 0x3 Result = 0 object = 0xc1a700a0 index = 1187 Page lookup 0xc1a700a0 1187 = 0xc09bd160 -Fault 0x208a3000 0x3 +Fault 0x20055000 0x3 Result = 0 object = 0xc1a2b140 index = 4 Page lookup 0xc1a2b140 4 = 0 panic: vm_page_insert_after: msucc doesn't succeed pindex KDB: enter: panic [ thread pid 18 tid 100052 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> --------------070804040301090402060701-- From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 16:15:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B023E25 for ; Fri, 13 Jun 2014 16:15:29 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3AEA02BD1 for ; Fri, 13 Jun 2014 16:15:28 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WvU8V-000PUy-8U; Fri, 13 Jun 2014 16:15:27 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5DGFLrr002771; Fri, 13 Jun 2014 10:15:21 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19nWNuytGyrzAn/W3QuU+UJ Subject: Re: Compilation for ARM From: Ian Lepore To: Stepan Dyatkovskiy In-Reply-To: <539A62E2.20003@narod.ru> References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Jun 2014 10:15:21 -0600 Message-ID: <1402676121.20883.231.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:15:29 -0000 On Fri, 2014-06-13 at 08:33 +0600, Stepan Dyatkovskiy wrote: > Hi all, > > Currently I'm trying to compile kernel, with activated cortex-a9 or a15 > options (TARGET_CPUTYPE=cortex-a9). > Currently "as" from buildworld gives me tons of "unknown instruction" > errors. That happens, I suppose, due to its release date (2007). > It makes no sense that you are getting such problems. I've never used TARGET_CPUTYPE at all, and there's no problem compiling the kernel with the tools in base. All you need to build the kernel is make buildkernel TARGET_ARCH=armv6 KERNCONF=PANDABOARD -- Ian > So I have tried newer versions of binutils: > 1. devel/cross-binutils from ports. I have built it with TGTARCH=armv6 > and TGTABI=none-eabi. > 2. Binutils from http://ftp.gnu.org/gnu/binutils/ > > I did it in several steps: > 1. I have built them. > 2. I have entered buildenv: "make TARGET_CPUTYPE=armv6 buildenv" > 3. # which as > 4. # cp /usr/obj/arm.armv6/usr/src/tmp/usr/bin/as > /usr/obj/arm.armv6/usr/src/tmp/usr/bin/as.bak > > Below I tried several ways to replace as/ld/and-friends: > 5. cp /usr/local/bin/armv6-none-eabi-as > /usr/obj/arm.armv6/usr/src/tmp/usr/bin/as > 6. I have also tried "ln -s" > > 7. # make KERNCONF=PANDABOARD TARGET_CPUTYPE=cortex-a9 buildkernel > > Whatever I did, it always ended up with > > /usr/src/sys/arm/arm/locore.S: Assembler messages: > /usr/src/sys/arm/arm/locore.S:79: Error: duplicate .fnstart directive > /usr/src/sys/arm/arm/locore.S:255: Error: .fnend directive without .fnstart > > So, may be, you guys know how to deal with that? > > Currently I have no idea :-(.. May be sleep a bit :-) > > Thanks! > > -Stepan > > Stepan Dyatkovskiy wrote: > > Hi all, > > > > Thanks for advices! > > > > That's interesting. I have managed to launch kernel, using these u-boot > > binaries: > > http://people.freebsd.org/~gonzo/pandaboard/ > > > > Looks like specific MLO. But I'm not sure. > > > > With regular linaro u-boot, I load kernel.bin, then try start it with > > "go", and nothing happens. With binaries of this Gonzo guy, I did the > > same, and everything works fine :-/ Do you know who is it (I mean > > Gonzo)? I would like to ask him, what he did in his binaries. > > > > Another question: > > I would like to build FreeBSD, using latest clang. Currently I have > > tried to build it latest svn version of FreeBSD: > > svn://svn.freebsd.org/base/head/ > > With command: > > make TARGET_ARCH=armv6 buildworld TARGET_CPUTYPE=cortex-a9 > > > > But got next error (repeated several > > times):/tmp/jemalloc_atomic-22cc38.s:21: Error: garbage following > > instruction -- `dmb ish' > > > > So perhaps, its better to use stable version (10.0.0), but with new > > clang. Currently, I'm going to copy clang sources from HEAD into 10.0.0 > > sources tree. But perhaps there is better way to do it? > > > > Thanks! > > > > -Stepan > > > > Ian Lepore wrote: > >> On Thu, 2014-06-12 at 01:44 +0600, Stepan Dyatkovskiy wrote: > >>> Hi guys, > >>> Thank you! I have built it successfully. It was really simple. Currently > >>> I'm trying to launch with u-boot. Are here any instructions/manual how > >>> to run kernel with u-boot? > >>> Thanks! > >>> -Stepan > >> > >> If you compile the dtb into the kernel, you can launch the kernel > >> directly from u-boot. If you don't, then you need u-boot to launch > >> ubldr (loader(8) that uses the u-boot API, which requires a u-boot with > >> the API option enabled). > >> > >> The kernel can be loaded at any 1MB-boundary address, and can be > >> launched by jumping to the load address + 0x100, such as: > >> > >> fatload 11000000; go 11000100 > >> > >> If you are using a modern u-boot that enables data caches, you need to > >> turn them off manually, like: > >> > >> fatload 11000000 > >> dcache off; dcache flush > >> go 11000100 > >> > >> This is just a u-boot quirk, it disables caches on bootm and bootelf > >> commands, but not on a "go" command. > >> > >> -- Ian > >> > > > From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 16:20:59 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05D0916D; Fri, 13 Jun 2014 16:20:59 +0000 (UTC) Received: from forward1l.mail.yandex.net (forward1l.mail.yandex.net [84.201.143.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2ADB2C99; Fri, 13 Jun 2014 16:20:57 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward1l.mail.yandex.net (Yandex) with ESMTP id 2F0A51521111; Fri, 13 Jun 2014 20:20:48 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 95D5213403DA; Fri, 13 Jun 2014 20:20:47 +0400 (MSK) Received: from adsl-71-135-103-89.dsl.pltn13.pacbell.net (adsl-71-135-103-89.dsl.pltn13.pacbell.net [71.135.103.89]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Gi9Ef7mHkz-KjF4cFL2; Fri, 13 Jun 2014 20:20:46 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 5de91ab7-6d76-43e8-935b-3ddaae562d3d DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402676446; bh=ttrBGzZojuz2HmXhx1PuLVzUxIs72GWq2M9Hmxxs3Z0=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IOGJlMB8g6ag7uegY9hSZkbymjSG3Tf4hPNLntCbsId5svqaakOZ+IUKFNW7IbdPF KMnM1ZzdzQdXqfAZrouk0XMKexQjqcXAxZ8sSO4Y6iktWGiNLCtmcoBjus4iVxR3Yh SB/yF8dJYcoJZYALwmuGfABNj19gBo63XDIX/tBw= Authentication-Results: smtp1h.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <539B24DB.4090005@narod.ru> Date: Fri, 13 Jun 2014 22:20:43 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Compilation for ARM References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> In-Reply-To: <1402676121.20883.231.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:20:59 -0000 Hi Ian, Yup. I have done it with default options. That works fine. Thanks! But, currently we need to compare launch times for kernel that was compiled with cortex-a9 options and for kernel that was compiled with cortex-a15 options. The reason of doing that is some improvements in clang backend that promises faster execution for (-mcpu=cortex-a15). So we would like to check it on FreeBSD kernel, since we going to use this OS as base for our applications. -Stepan Ian Lepore wrote: > On Fri, 2014-06-13 at 08:33 +0600, Stepan Dyatkovskiy wrote: >> Hi all, >> >> Currently I'm trying to compile kernel, with activated cortex-a9 or a15 >> options (TARGET_CPUTYPE=cortex-a9). >> Currently "as" from buildworld gives me tons of "unknown instruction" >> errors. That happens, I suppose, due to its release date (2007). >> > > It makes no sense that you are getting such problems. I've never used > TARGET_CPUTYPE at all, and there's no problem compiling the kernel with > the tools in base. All you need to build the kernel is > > make buildkernel TARGET_ARCH=armv6 KERNCONF=PANDABOARD > > -- Ian > > >> So I have tried newer versions of binutils: >> 1. devel/cross-binutils from ports. I have built it with TGTARCH=armv6 >> and TGTABI=none-eabi. >> 2. Binutils from http://ftp.gnu.org/gnu/binutils/ >> >> I did it in several steps: >> 1. I have built them. >> 2. I have entered buildenv: "make TARGET_CPUTYPE=armv6 buildenv" >> 3. # which as >> 4. # cp /usr/obj/arm.armv6/usr/src/tmp/usr/bin/as >> /usr/obj/arm.armv6/usr/src/tmp/usr/bin/as.bak >> >> Below I tried several ways to replace as/ld/and-friends: >> 5. cp /usr/local/bin/armv6-none-eabi-as >> /usr/obj/arm.armv6/usr/src/tmp/usr/bin/as >> 6. I have also tried "ln -s" >> >> 7. # make KERNCONF=PANDABOARD TARGET_CPUTYPE=cortex-a9 buildkernel >> >> Whatever I did, it always ended up with >> >> /usr/src/sys/arm/arm/locore.S: Assembler messages: >> /usr/src/sys/arm/arm/locore.S:79: Error: duplicate .fnstart directive >> /usr/src/sys/arm/arm/locore.S:255: Error: .fnend directive without .fnstart >> >> So, may be, you guys know how to deal with that? >> >> Currently I have no idea :-(.. May be sleep a bit :-) >> >> Thanks! >> >> -Stepan >> >> Stepan Dyatkovskiy wrote: >>> Hi all, >>> >>> Thanks for advices! >>> >>> That's interesting. I have managed to launch kernel, using these u-boot >>> binaries: >>> http://people.freebsd.org/~gonzo/pandaboard/ >>> >>> Looks like specific MLO. But I'm not sure. >>> >>> With regular linaro u-boot, I load kernel.bin, then try start it with >>> "go", and nothing happens. With binaries of this Gonzo guy, I did the >>> same, and everything works fine :-/ Do you know who is it (I mean >>> Gonzo)? I would like to ask him, what he did in his binaries. >>> >>> Another question: >>> I would like to build FreeBSD, using latest clang. Currently I have >>> tried to build it latest svn version of FreeBSD: >>> svn://svn.freebsd.org/base/head/ >>> With command: >>> make TARGET_ARCH=armv6 buildworld TARGET_CPUTYPE=cortex-a9 >>> >>> But got next error (repeated several >>> times):/tmp/jemalloc_atomic-22cc38.s:21: Error: garbage following >>> instruction -- `dmb ish' >>> >>> So perhaps, its better to use stable version (10.0.0), but with new >>> clang. Currently, I'm going to copy clang sources from HEAD into 10.0.0 >>> sources tree. But perhaps there is better way to do it? >>> >>> Thanks! >>> >>> -Stepan >>> >>> Ian Lepore wrote: >>>> On Thu, 2014-06-12 at 01:44 +0600, Stepan Dyatkovskiy wrote: >>>>> Hi guys, >>>>> Thank you! I have built it successfully. It was really simple. Currently >>>>> I'm trying to launch with u-boot. Are here any instructions/manual how >>>>> to run kernel with u-boot? >>>>> Thanks! >>>>> -Stepan >>>> >>>> If you compile the dtb into the kernel, you can launch the kernel >>>> directly from u-boot. If you don't, then you need u-boot to launch >>>> ubldr (loader(8) that uses the u-boot API, which requires a u-boot with >>>> the API option enabled). >>>> >>>> The kernel can be loaded at any 1MB-boundary address, and can be >>>> launched by jumping to the load address + 0x100, such as: >>>> >>>> fatload 11000000; go 11000100 >>>> >>>> If you are using a modern u-boot that enables data caches, you need to >>>> turn them off manually, like: >>>> >>>> fatload 11000000 >>>> dcache off; dcache flush >>>> go 11000100 >>>> >>>> This is just a u-boot quirk, it disables caches on bootm and bootelf >>>> commands, but not on a "go" command. >>>> >>>> -- Ian >>>> >>> >> > > From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 16:34:23 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09620A3D for ; Fri, 13 Jun 2014 16:34:23 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEBA32DD5 for ; Fri, 13 Jun 2014 16:34:22 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WvUQn-0008X1-5J; Fri, 13 Jun 2014 16:34:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5DGYInR002795; Fri, 13 Jun 2014 10:34:18 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19fW35dYFebVLTQAdKNqS7Z Subject: Re: Compilation for ARM From: Ian Lepore To: Stepan Dyatkovskiy In-Reply-To: <539B24DB.4090005@narod.ru> References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> <539B24DB.4090005@narod.ru> Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Jun 2014 10:34:18 -0600 Message-ID: <1402677258.20883.235.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:34:23 -0000 On Fri, 2014-06-13 at 22:20 +0600, Stepan Dyatkovskiy wrote: > Hi Ian, > Yup. I have done it with default options. That works fine. Thanks! > > But, currently we need to compare launch times for kernel that was > compiled with cortex-a9 options and for kernel that was compiled with > cortex-a15 options. > > The reason of doing that is some improvements in clang backend that > promises faster execution for (-mcpu=cortex-a15). So we would like to > check it on FreeBSD kernel, since we going to use this OS as base for > our applications. > > -Stepan I wonder if it is upset that the nesting is backwards, like NP_ENTRY(btext) ASENTRY_NP(_start) ... END(btext) END(_start) Maybe try switching the order of the END macros? If that doesn't help, try removing the btext macros completely, I don't think they're needed by anything these days. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 16:50:52 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2F7B617; Fri, 13 Jun 2014 16:50:52 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A08B22FA4; Fri, 13 Jun 2014 16:50:51 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s5DGlemL017953; Fri, 13 Jun 2014 11:50:49 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 1mfh28gecq-1; Fri, 13 Jun 2014 11:50:49 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 0AD48500116; Fri, 13 Jun 2014 11:50:49 -0500 (CDT) Message-ID: <539B2BE8.2090005@rice.edu> Date: Fri, 13 Jun 2014 11:50:48 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Hans Petter Selasky , Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> <5399FB57.8090102@rice.edu> <539A140F.6020107@selasky.org> In-Reply-To: <539A140F.6020107@selasky.org> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------010100090200080308020902" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=11 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406130185 Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:50:53 -0000 This is a multi-part message in MIME format. --------------010100090200080308020902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/12/2014 15:56, Hans Petter Selasky wrote: > On 06/12/14 21:11, Alan Cox wrote: >> On 06/12/2014 12:53, Hans Petter Selasky wrote: >>> On 06/12/14 19:41, Hans Petter Selasky wrote: >>>> On 06/12/14 19:32, Ian Lepore wrote: >>>>> On Thu, 2014-06-12 at 19:28 +0200, Hans Petter Selasky wrote: >>>>>> On 06/12/14 19:12, Alan Cox wrote: >>>>>>> On 06/12/2014 01:03, Hans Petter Selasky wrote: >>>>>>>> On 06/11/14 22:47, Alan Cox wrote: >>>>>>>>> >>>>>>>>> On Jun 11, 2014, at 3:45 PM, Hans Petter Selasky wrote: >>>>>>>>> >>>>>>>>>> On 06/11/14 22:20, Alan Cox wrote: >>>>>>>>>>> >>>>>>>>>>> On Jun 11, 2014, at 3:07 PM, Hans Petter Selasky wrote: >>>>>>>>>>> >>>>>>>>>>>> kernel: file format elf32-littlearm >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Then this problem is unrelated to the one that I just fixed. >>>>>>>>>>> It's >>>>>>>>>>> also not a problem that I've seen before. >>>>>>>>>> >>>>>>>>>> It is happening after your recent patches to -current, >>>>>>>>>> optimising >>>>>>>>>> the "page ordering". Happens every now and then during boot when >>>>>>>>>> stack is growing looks like. >>>>>>>>> >>>>>>>>> More precisely, which commit is that? >>>>>>>>> >>>>>>>> >>>>>>>>> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 >>>>>>>>> Author: alc >>>>>>>>> Date: Sun May 12 16:50:18 2013 +0000 >>>>>>>>> >>>>>>>>> Refactor vm_page_alloc()'s interactions with >>>>>>>>> vm_reserv_alloc_page() and >>>>>>>>> vm_page_insert() so that (1) vm_radix_lookup_le() is never >>>>>>>>> called >>>>>>>>> while the >>>>>>>>> free page queues lock is held and (2) >>>>>>>>> vm_radix_lookup_le() is >>>>>>>>> called at most >>>>>>>>> once. This change reduces the average time that the free >>>>>>>>> page >>>>>>>>> queues lock >>>>>>>>> is held by vm_page_alloc() as well as vm_page_alloc()'s >>>>>>>>> average >>>>>>>>> overall >>>>>>>>> running time. >>>>>>>>> >>>>>>>>> Sponsored by: EMC / Isilon Storage Division >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> That's not exactly a recent commit. It was 13 months ago. And, >>>>>>> this >>>>>>> code is exercised by all page allocations except for page table >>>>>>> pages >>>>>>> and uma_small_alloc(). >>>>>>> >>>>>>> What this assertion is telling us is that somewhere else we have >>>>>>> screwed >>>>>>> up the vm object to which we are now trying to allocate a page. >>>>>>> >>>>>>> Try the attached patch. It will provide additional information the >>>>>>> next >>>>>>> time that the assertion fails. >>>>>>> >>>>>> >>>>>> Here you go: >>>>>> >>>>>>> panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed >>>>>>> pindex 4 >>>>>>> object 0xc1a2b140 type 0 >>>>>>> KDB: enter: panic >>>>>>> [ thread pid 18 tid 100052 ] >>>>>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>>>>>> db> >>>>> >>>>> Could this be related to changing superpages to enabled by default >>>>> recently? Easy to test by setting vm.pmap.sp_enabled=0 in ubldr >>>>> >>>> >>>> Setting the sp_enabled to 0 does not fix the problem. >>>> >>>> --HPS >>> >>> Output from the debugger regarding the object: >>> >>>> panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed >>>> pindex 4 >>>> object 0xc1a2b1e0 type 0 >>>> KDB: enter: panic >>> >>>> db> show vmochk >>>> vmochk: internal obj is not in a map: ref: 1, size: 2: 0x2, >>>> backing_object: 0 >>>> vmochk: internal obj is not in a map: ref: 1, size: 2: 0x2, >>>> backing_object: 0 >>> >> >> Use the ddb command "object", not "vmochk". >> >>> .... >>> >>>> db> show vmopag >>> >>> .... >>> >>>> new object: 0xc1a2b1e0 >>>> index(0)run(1)pa(0x1766000) >>>> index(1)run(1)pa(0x1e17000) >>>> index(2)run(2)pa(0x1772000) >>>> index(4)run(1)pa(0x1e6a000) >>>> index(5)run(2)pa(0x1775000) >>>> index(7)run(1)pa(0x1778000) >>>> index(8)run(1)pa(0x1788000) >>>> index(9)run(1)pa(0x17e9000) >>> >>> --HPS >>> >>> >>> >> >> > > show object 0xc1a2b1e0 > Object 0xc1a2b1e0: type=0, size=0xa, res=10, ref=2, flags=0x3000 ruid > 0 charge a000 > sref=0, backing_object(0)=(0)+0x0 > > memory:=(off=0x0,page=0x1766000),(off=0x1,page=0x1e17000),(off=0x2,page=0x1772000),(off=0x3,page=0x1773000),(off=0x4,page=0x1e6a000),(off=0x5,page=0x177500) > > > ...(off=0x6,page=0x1776000),(off=0x7,page=0x1778000),(off=0x8,page=0x1788000),(off=0x9,page=0x17e9000) > > > This output shows that according to the object's list of pages there is already a page allocated at pindex 4 (or "off=0x4" above). If this list is correct, and not itself corrupted, then we shouldn't be making a call to vm_page_alloc() to allocate another page at the same pindex. Whether it is this list of pages that is corrupted or not, this means that the object's list of pages (shown above) and its radix tree of pages are out of sync. I'm curious to know what mpred is when the assertion fails. That will tell us something about the state of the radix tree. I've also modified ddb's "show object" to provide an additional bit of information. However, it would be really nice if "show object" displayed the state of the radix tree. In any case, At this point, --------------010100090200080308020902 Content-Type: text/plain; charset=ISO-8859-15; name="arm_final2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_final2.patch" Index: vm/vm_reserv.c =================================================================== --- vm/vm_reserv.c (revision 267282) +++ vm/vm_reserv.c (working copy) @@ -108,6 +108,46 @@ typedef u_long popmap_t; #define NPOPMAP howmany(VM_LEVEL_0_NPAGES, NBPOPMAP) /* + * Clear a bit in the population map. + */ +static __inline void +popmap_clear(popmap_t popmap[], int i) +{ + + popmap[i / NBPOPMAP] &= ~(1UL << (i % NBPOPMAP)); +} + +/* + * Set a bit in the population map. + */ +static __inline void +popmap_set(popmap_t popmap[], int i) +{ + + popmap[i / NBPOPMAP] |= 1UL << (i % NBPOPMAP); +} + +/* + * Is a bit in the population map clear? + */ +static __inline boolean_t +popmap_is_clear(popmap_t popmap[], int i) +{ + + return ((popmap[i / NBPOPMAP] & (1UL << (i % NBPOPMAP))) == 0); +} + +/* + * Is a bit in the population map set? + */ +static __inline boolean_t +popmap_is_set(popmap_t popmap[], int i) +{ + + return ((popmap[i / NBPOPMAP] & (1UL << (i % NBPOPMAP))) != 0); +} + +/* * The reservation structure * * A reservation structure is constructed whenever a large physical page is @@ -241,7 +281,7 @@ vm_reserv_depopulate(vm_reserv_t rv, int index) mtx_assert(&vm_page_queue_free_mtx, MA_OWNED); KASSERT(rv->object != NULL, ("vm_reserv_depopulate: reserv %p is free", rv)); - KASSERT(isset(rv->popmap, index), + KASSERT(popmap_is_set(rv->popmap, index), ("vm_reserv_depopulate: reserv %p's popmap[%d] is clear", rv, index)); KASSERT(rv->popcnt > 0, @@ -255,7 +295,7 @@ vm_reserv_depopulate(vm_reserv_t rv, int index) rv)); rv->pages->psind = 0; } - clrbit(rv->popmap, index); + popmap_clear(rv->popmap, index); rv->popcnt--; if (rv->popcnt == 0) { LIST_REMOVE(rv, objq); @@ -302,7 +342,7 @@ vm_reserv_populate(vm_reserv_t rv, int index) mtx_assert(&vm_page_queue_free_mtx, MA_OWNED); KASSERT(rv->object != NULL, ("vm_reserv_populate: reserv %p is free", rv)); - KASSERT(isclr(rv->popmap, index), + KASSERT(popmap_is_clear(rv->popmap, index), ("vm_reserv_populate: reserv %p's popmap[%d] is set", rv, index)); KASSERT(rv->popcnt < VM_LEVEL_0_NPAGES, @@ -313,7 +353,7 @@ vm_reserv_populate(vm_reserv_t rv, int index) TAILQ_REMOVE(&vm_rvq_partpop, rv, partpopq); rv->inpartpopq = FALSE; } - setbit(rv->popmap, index); + popmap_set(rv->popmap, index); rv->popcnt++; if (rv->popcnt < VM_LEVEL_0_NPAGES) { rv->inpartpopq = TRUE; @@ -503,7 +543,7 @@ found: return (NULL); /* Handle vm_page_rename(m, new_object, ...). */ for (i = 0; i < npages; i++) - if (isset(rv->popmap, index + i)) + if (popmap_is_set(rv->popmap, index + i)) return (NULL); for (i = 0; i < npages; i++) vm_reserv_populate(rv, index + i); @@ -628,7 +668,7 @@ found: index = VM_RESERV_INDEX(object, pindex); m = &rv->pages[index]; /* Handle vm_page_rename(m, new_object, ...). */ - if (isset(rv->popmap, index)) + if (popmap_is_set(rv->popmap, index)) return (NULL); vm_reserv_populate(rv, index); return (m); @@ -662,9 +702,9 @@ vm_reserv_break(vm_reserv_t rv, vm_page_t m) * to the physical memory allocator. */ i = m - rv->pages; - KASSERT(isclr(rv->popmap, i), + KASSERT(popmap_is_clear(rv->popmap, i), ("vm_reserv_break: reserv %p's popmap is corrupted", rv)); - setbit(rv->popmap, i); + popmap_set(rv->popmap, i); rv->popcnt++; } i = hi = 0; --------------010100090200080308020902-- From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 16:56:32 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3F3B8E9; Fri, 13 Jun 2014 16:56:32 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A47F42FF9; Fri, 13 Jun 2014 16:56:32 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s5DGpTco015602; Fri, 13 Jun 2014 11:56:24 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp1.rice.edu with ESMTP id 1megfvs77f-1; Fri, 13 Jun 2014 11:56:23 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 7916346014D; Fri, 13 Jun 2014 11:56:23 -0500 (CDT) Message-ID: <539B2D37.8050407@rice.edu> Date: Fri, 13 Jun 2014 11:56:23 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Hans Petter Selasky , Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> <5399FB57.8090102@rice.edu> <539A140F.6020107@selasky.org> <539ADD04.4000202@selasky.org> <539AED38.2000307@selasky.org> In-Reply-To: <539AED38.2000307@selasky.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406130186 Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:56:33 -0000 On 06/13/2014 07:23, Hans Petter Selasky wrote: > On 06/13/14 13:14, Hans Petter Selasky wrote: >> Hi, >> >> Some debugging reveals that the previous element has pindex == 0 aswell. >> So it turns out there can be multiple pages having same pindex, and then >> the "mpred" logic falls apart :-( >> >> --HPS >> > > Hi, > > Added some random printfs to vm_xxx.c: > > One observation is that allocated pages are busy, and we are not > waiting for then to become non-busy ? > By default, we mark a page as busy when we allocate it. At the end of vm_fault(_hold), we unbusy it after it is mapped. > I cannot debug this further until coming Monday ... Patch suggestions > are welcome! > > It happens approximately 1 of 2 times during boot. > > --HPS > > > From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 17:00:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34306AD7; Fri, 13 Jun 2014 17:00:41 +0000 (UTC) Received: from forward2l.mail.yandex.net (forward2l.mail.yandex.net [IPv6:2a02:6b8:0:1819::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C58192055; Fri, 13 Jun 2014 17:00:40 +0000 (UTC) Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [37.140.190.29]) by forward2l.mail.yandex.net (Yandex) with ESMTP id 6004B1AC108F; Fri, 13 Jun 2014 21:00:36 +0400 (MSK) Received: from smtp4o.mail.yandex.net (localhost [127.0.0.1]) by smtp4o.mail.yandex.net (Yandex) with ESMTP id DCB8C2321D8B; Fri, 13 Jun 2014 21:00:35 +0400 (MSK) Received: from adsl-71-135-103-89.dsl.pltn13.pacbell.net (adsl-71-135-103-89.dsl.pltn13.pacbell.net [71.135.103.89]) by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id rDmG0BCI32-0XG8OZ6r; Fri, 13 Jun 2014 21:00:34 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: e9a6492a-79f5-43af-97f0-0857c5fec0f2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402678835; bh=Nhmw46i3X92fjuTfKiBwPC7TFMpG1SLP9meMCleKtIc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=S+BUIKuyXOt7nE6E3VwZNtG9CaxhRQ4gC3mjJQMpa3DoUe5iFufetVZykQ5311A2M WUKnYoPUBwP03Mhn6iVuWxjLrhMa2S1fEXM9TLK5ZRczpcfYorEhahxQn/OG8wqBtE sjkVHF2vJF+XX+xavXtATYW+XAikG6aupGKd1jUs= Authentication-Results: smtp4o.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <539B2E2F.3070803@narod.ru> Date: Fri, 13 Jun 2014 23:00:31 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Compilation for ARM References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> <539B24DB.4090005@narod.ru> <1402677258.20883.235.camel@revolution.hippie.lan> In-Reply-To: <1402677258.20883.235.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:00:41 -0000 Hi Ian, Swaping didn't help. Neither -integrated-as. But I got your idea, I'll try to fix errors in .S files manually (hope there are few of them). -Stepan. Ian Lepore wrote: > On Fri, 2014-06-13 at 22:20 +0600, Stepan Dyatkovskiy wrote: >> Hi Ian, >> Yup. I have done it with default options. That works fine. Thanks! >> >> But, currently we need to compare launch times for kernel that was >> compiled with cortex-a9 options and for kernel that was compiled with >> cortex-a15 options. >> >> The reason of doing that is some improvements in clang backend that >> promises faster execution for (-mcpu=cortex-a15). So we would like to >> check it on FreeBSD kernel, since we going to use this OS as base for >> our applications. >> >> -Stepan > > I wonder if it is upset that the nesting is backwards, like > > NP_ENTRY(btext) > ASENTRY_NP(_start) > ... > END(btext) > END(_start) > > Maybe try switching the order of the END macros? If that doesn't help, > try removing the btext macros completely, I don't think they're needed > by anything these days. > > -- Ian > > From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 18:35:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF1D9E00; Fri, 13 Jun 2014 18:35:01 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90F70292A; Fri, 13 Jun 2014 18:35:01 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id w8so4318306qac.11 for ; Fri, 13 Jun 2014 11:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=l+9MsQGX7yg1dcaBIFyBG3QNAegouCNWp95E1bH6ugY=; b=IAuEI86M13GtCdh8cyHF7ge8FByRuwOV0xu4b+VrqdPM31rNMT2bjBq2lU/99a4mPt jjKSGWvDRGmJWk4nkxXH82SKJspT/fwSHnN8WQMSZM8tUzQNg3XPPsNuLn1Of5Hvin9s enAVBjG/eXEsVv5TXVU9GABzNS6yojLDH5gagXLtLVSvtQECPXEIbqBqf36kCsFRZY4U 0SILBmAE2eKtOTvgIm8HKZEv16U0s4vm1mAylCSovYH0lcZBt9QVeil+t5QnEVGJ6bVI /dumEE1NO6upRLYTBj2oQuFOkFK0XkwYGGWgoEEI5Y0/NXtAo7YsX5nGELTJAB/3xo1m v9Ow== MIME-Version: 1.0 X-Received: by 10.224.47.148 with SMTP id n20mr6410377qaf.90.1402684500756; Fri, 13 Jun 2014 11:35:00 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.140.49.239 with HTTP; Fri, 13 Jun 2014 11:35:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Jun 2014 14:35:00 -0400 X-Google-Sender-Auth: KNMBXmxgYzB0ED_IMBHBAl9CTBY Message-ID: Subject: Re: Superpages by default From: Ed Maste To: Zbigniew Bodek Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:35:02 -0000 On 14 May 2014 14:12, Zbigniew Bodek wrote: > > Since we have SMP fixed and it seems that there are no more known bugs > in ARM superpages then we could enable superpages by default. > I'm attaching the patch that is to be committed to make that happen. Zbigniew, Thanks again for wrapping this up and and enabling ARM superpages by default. -Ed From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 20:30:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC70E40F; Fri, 13 Jun 2014 20:30:41 +0000 (UTC) Received: from forward9l.mail.yandex.net (forward9l.mail.yandex.net [IPv6:2a02:6b8:0:1819::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EA152394; Fri, 13 Jun 2014 20:30:40 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward9l.mail.yandex.net (Yandex) with ESMTP id 1E85FE61A41; Sat, 14 Jun 2014 00:30:36 +0400 (MSK) Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id A69451B608CC; Sat, 14 Jun 2014 00:30:35 +0400 (MSK) Received: from unknown (unknown [12.202.173.169]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id DKYOAxpOvw-UYjOehN2; Sat, 14 Jun 2014 00:30:35 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: fe3262db-bab6-46e1-b5fb-3f081a197680 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402691435; bh=uPisSmMUZyBrhKYu1rJlLyMm+zyeI2d8MlpShfi1UZE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gS5Ec6NK3E52tdDq7MlsLTtXoeDzjsGZ+V1hfGIF/7XuSP8TGWLrryjDg7xSkffjz NpgJ+D77ueU3aPi+IqDm6jD4o6TR/AtWkR0hbH83P/rv5UYTxQOH4uoEbyt44tFpIk ObUGiLepdHXvkx34Z3p0aQR0qVtN7Ayi+I1P8XpE= Authentication-Results: smtp8.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <539B5F68.5020008@narod.ru> Date: Sat, 14 Jun 2014 02:30:32 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Compilation for ARM References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> <539B24DB.4090005@narod.ru> <1402677258.20883.235.camel@revolution.hippie.lan> In-Reply-To: <1402677258.20883.235.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:30:41 -0000 Modern compilers forbid to use nested .fnstart constructions (actually nested ENTRY uses). But FreeBSD code has them in few places. For example, in arm/exception.S file (see swi_entry). I saw the comment nearby swi_exit definition, but now quite understand how it relates with nested ENTRY uses... It looks like several entries were intruduced just because of alternative names for the same function. But I'm not sure... Thanks! -Stepan Why we need them Ian Lepore wrote: > On Fri, 2014-06-13 at 22:20 +0600, Stepan Dyatkovskiy wrote: >> Hi Ian, >> Yup. I have done it with default options. That works fine. Thanks! >> >> But, currently we need to compare launch times for kernel that was >> compiled with cortex-a9 options and for kernel that was compiled with >> cortex-a15 options. >> >> The reason of doing that is some improvements in clang backend that >> promises faster execution for (-mcpu=cortex-a15). So we would like to >> check it on FreeBSD kernel, since we going to use this OS as base for >> our applications. >> >> -Stepan > > I wonder if it is upset that the nesting is backwards, like > > NP_ENTRY(btext) > ASENTRY_NP(_start) > ... > END(btext) > END(_start) > > Maybe try switching the order of the END macros? If that doesn't help, > try removing the btext macros completely, I don't think they're needed > by anything these days. > > -- Ian > > From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 20:52:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B50C8C3 for ; Fri, 13 Jun 2014 20:52:14 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DEF452554 for ; Fri, 13 Jun 2014 20:52:13 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WvYSE-0004NK-D6; Fri, 13 Jun 2014 20:52:06 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5DKq35P002998; Fri, 13 Jun 2014 14:52:03 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/gXEi5CpomG6RJH7znsm5x Subject: Re: Compilation for ARM From: Ian Lepore To: Stepan Dyatkovskiy In-Reply-To: <539B5F68.5020008@narod.ru> References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> <539B24DB.4090005@narod.ru> <1402677258.20883.235.camel@revolution.hippie.lan> <539B5F68.5020008@narod.ru> Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Jun 2014 14:52:03 -0600 Message-ID: <1402692723.20883.237.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:52:14 -0000 That sounds like a compiler bug to me, there's nothing invalid about nesting a function within another function in assembler code. But, it's the only toolchain we've got, so I guess we'll have to figure out some other way to do things. That "nearby" comment I think is very old and outdated. -- Ian On Sat, 2014-06-14 at 02:30 +0600, Stepan Dyatkovskiy wrote: > Modern compilers forbid to use nested .fnstart constructions (actually > nested ENTRY uses). But FreeBSD code has them in few places. For > example, in arm/exception.S file (see swi_entry). I saw the comment > nearby swi_exit definition, but now quite understand how it relates with > nested ENTRY uses... > It looks like several entries were intruduced just because of > alternative names for the same function. But I'm not sure... > > Thanks! > > -Stepan > > Why we need them > Ian Lepore wrote: > > On Fri, 2014-06-13 at 22:20 +0600, Stepan Dyatkovskiy wrote: > >> Hi Ian, > >> Yup. I have done it with default options. That works fine. Thanks! > >> > >> But, currently we need to compare launch times for kernel that was > >> compiled with cortex-a9 options and for kernel that was compiled with > >> cortex-a15 options. > >> > >> The reason of doing that is some improvements in clang backend that > >> promises faster execution for (-mcpu=cortex-a15). So we would like to > >> check it on FreeBSD kernel, since we going to use this OS as base for > >> our applications. > >> > >> -Stepan > > > > I wonder if it is upset that the nesting is backwards, like > > > > NP_ENTRY(btext) > > ASENTRY_NP(_start) > > ... > > END(btext) > > END(_start) > > > > Maybe try switching the order of the END macros? If that doesn't help, > > try removing the btext macros completely, I don't think they're needed > > by anything these days. > > > > -- Ian > > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Jun 14 01:03:09 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82DF9D5D; Sat, 14 Jun 2014 01:03:09 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 123F02940; Sat, 14 Jun 2014 01:03:08 +0000 (UTC) Received: from smtp7.mail.yandex.net (smtp7.mail.yandex.net [77.88.61.55]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 97272BC12C9; Sat, 14 Jun 2014 05:03:05 +0400 (MSK) Received: from smtp7.mail.yandex.net (localhost [127.0.0.1]) by smtp7.mail.yandex.net (Yandex) with ESMTP id 2B9BB1580846; Sat, 14 Jun 2014 05:03:05 +0400 (MSK) Received: from unknown (unknown [12.202.173.169]) by smtp7.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Kj4NOLb14J-33aOxwnh; Sat, 14 Jun 2014 05:03:04 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: a0eb6360-c2c8-4eb7-8233-1988e9dbabe5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402707784; bh=524bnnj6z/900HLNPRp1A0vd8RVRocORLTFBBsASvww=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Vnj3MmRZ4uEv7/djzGReinhbWO4BH4LJiFN5P/DnXlsrV9N0ZIpGa9bV6xxWlKU63 Zz0bFHJAaxWaHl+0u6hZoiLz15nhRV3MOVgY6ziDriiPAiln8POnRMTgcz4h8YkbeB 4A1qSNCpIDUZ4g2I3Srrz0oD5l1/oH4XYs6ueRq0= Authentication-Results: smtp7.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <539B9F45.1030008@narod.ru> Date: Sat, 14 Jun 2014 07:03:01 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Compilation for ARM References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> <539B24DB.4090005@narod.ru> <1402677258.20883.235.camel@revolution.hippie.lan> <539B5F68.5020008@narod.ru> <1402692723.20883.237.camel@revolution.hippie.lan> In-Reply-To: <1402692723.20883.237.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 01:03:09 -0000 Hi all, I have managed to compile and launch kernel with cortex-a9 options; I have also managed to compile kernel for cortex-a15 options, but failed to launch it. What was done in .S files: I just replaced nested ENTRY definitions with labels. I think, I'll prepare patch after this work. Currently I have only replaced "as" (from old one, to the new one). I'll try to replace whole binutils and will report what I got. -Stepan Ian Lepore wrote: > That sounds like a compiler bug to me, there's nothing invalid about > nesting a function within another function in assembler code. But, it's > the only toolchain we've got, so I guess we'll have to figure out some > other way to do things. > > That "nearby" comment I think is very old and outdated. > > -- Ian > > On Sat, 2014-06-14 at 02:30 +0600, Stepan Dyatkovskiy wrote: >> Modern compilers forbid to use nested .fnstart constructions (actually >> nested ENTRY uses). But FreeBSD code has them in few places. For >> example, in arm/exception.S file (see swi_entry). I saw the comment >> nearby swi_exit definition, but now quite understand how it relates with >> nested ENTRY uses... >> It looks like several entries were intruduced just because of >> alternative names for the same function. But I'm not sure... >> >> Thanks! >> >> -Stepan >> >> Why we need them >> Ian Lepore wrote: >>> On Fri, 2014-06-13 at 22:20 +0600, Stepan Dyatkovskiy wrote: >>>> Hi Ian, >>>> Yup. I have done it with default options. That works fine. Thanks! >>>> >>>> But, currently we need to compare launch times for kernel that was >>>> compiled with cortex-a9 options and for kernel that was compiled with >>>> cortex-a15 options. >>>> >>>> The reason of doing that is some improvements in clang backend that >>>> promises faster execution for (-mcpu=cortex-a15). So we would like to >>>> check it on FreeBSD kernel, since we going to use this OS as base for >>>> our applications. >>>> >>>> -Stepan >>> >>> I wonder if it is upset that the nesting is backwards, like >>> >>> NP_ENTRY(btext) >>> ASENTRY_NP(_start) >>> ... >>> END(btext) >>> END(_start) >>> >>> Maybe try switching the order of the END macros? If that doesn't help, >>> try removing the btext macros completely, I don't think they're needed >>> by anything these days. >>> >>> -- Ian >>> >>> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@FreeBSD.ORG Sun Jun 15 19:43:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CABFC761 for ; Sun, 15 Jun 2014 19:43:55 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C7E82B3E for ; Sun, 15 Jun 2014 19:43:54 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s5FJOdsq034191 for freebsd-arm@freebsd.org; Sun, 15 Jun 2014 19:24:39 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id g2c3fv363wcvvc5fdaai83p762; for freebsd-arm@freebsd.org; Sun, 15 Jun 2014 19:24:39 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: required xdev line to build r-pi on crochet? From: Tim Kientzle In-Reply-To: Date: Sun, 15 Jun 2014 12:24:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <02A89B5B-5299-4341-978F-F6D4E16F7DCF@kientzle.com> References: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> <1399553779.22079.316.camel@revolution.hippie.lan> To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 19:43:56 -0000 Ugh. This seems to be broken again. On i386 -CURRENT from about a week ago: make XDEV=3Darm XDEV_ARCH=3Darmv6 WITH_GCC_BOOTSTRAP=3D1 = WITHOUT_CLANG_BOOTSTRAP=3D1 WITHOUT_CLANG=3D1 xdev Yields... =3D=3D=3D> gnu/lib/libgcc (obj,depend,all,install) make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile = MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile = GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h `unwind.h' is up to date. make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile = MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile = GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h `gthr-default.h' is up to date. cc -isystem //usr/armv6-freebsd/usr/include = -L//usr/armv6-freebsd/usr/lib --sysroot=3D//usr/armv6-freebsd/ = -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin = -B//usr/armv6-freebsd/usr/lib -c -O -pipe -DTARGET_ARM_EABI -DIN_GCC = -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. = -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Dinhibit_libc = -fno-inline -std=3Dgnu99 -fheinous-gnu-extensions -Qunused-arguments = -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 = -DElfW=3D__ElfN -o libunwind.o = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/arm/libunwind.S = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/arm/lib1funcs.asm:1:3:= error: unexpected token at start of statement @ libgcc routines for ARM cpu. ^ = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/arm/lib1funcs.asm:2:3:= error: unexpected token at start of statement @ Division routines, written by Richard Earnshaw, = (rearnsha@armltd.co.uk) ^ I'm upgrading to see if anything has changed... Tim P.S. Just got a BBB Rev C with the 4G eMMC chip. Under Debian, dd with a 1MiB block size shows around 10MB/s write, 30MB/s read performance. On May 8, 2014, at 10:06 AM, Adrian Chadd wrote: > [snip] >=20 > Ok. Thanks Ian/Warner. >=20 > The line that currently works for me is: >=20 > make XDEV=3Darm XDEV_ARCH=3Darmv6 WITH_GCC_BOOTSTRAP=3D1 > WITHOUT_CLANG_BOOTSTRAP=3D1 WITHOUT_CLANG=3D1 xdev >=20 >=20 >=20 > -a > _______________________________________________ > 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 Jun 15 22:58:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57187F60 for ; Sun, 15 Jun 2014 22:58:28 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 186792B02 for ; Sun, 15 Jun 2014 22:58:27 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id x19so4354215ier.30 for ; Sun, 15 Jun 2014 15:58:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=IZJCey+gDLlHGQ9MqwHT2oLIxsiES4yJDfBI7b1uRMw=; b=XOfuc89YazYL/L5sWVi2Fct2MojDD1MoMySiGlD0qgGfjEQ0VJuJyYghZkDlXiU1mn xUWT91iLcUnatta879G2U1N8fpbPyv4xTPTgnEdDpgNcjP/UnxoZ+97jmBoHzOJT5fuF cUgdntoHKoSHzi5XMRbvekVogy2kXFz/3sAzbOJJUUnAuNwnhdFRKT6SbXWHR//c6UD8 YnrCaNLFxAepxbL58E67Jj2ibaD25s/OAd+nXFtp29OWsqgCGx2A7BCKsI0GnCi6B9mN nQZmyjrsA9kS6IsbjVrrkPBQ9yDGab9JEVxhQ9VPn/Be6lfWoyTLYwP+k/Jq3bpB6IgY bEuw== X-Gm-Message-State: ALoCoQnQGQ1QZIjJgrJE2PgagI/TzU4tZY/+SN+Yt9D4PrUXwxxRUPWYcTiKnLqA3F4jDjRHXqIK X-Received: by 10.42.11.74 with SMTP id t10mr16427457ict.27.1402873101280; Sun, 15 Jun 2014 15:58:21 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id e4sm15660407igx.4.2014.06.15.15.58.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Jun 2014 15:58:20 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_7B5FB0F6-6B04-4BD4-A06A-3ACF401690CC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: required xdev line to build r-pi on crochet? From: Warner Losh In-Reply-To: <02A89B5B-5299-4341-978F-F6D4E16F7DCF@kientzle.com> Date: Sun, 15 Jun 2014 16:58:27 -0600 Message-Id: <2B7F498D-F459-4E69-9341-C13D34A312B1@bsdimp.com> References: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> <1399553779.22079.316.camel@revolution.hippie.lan> <02A89B5B-5299-4341-978F-F6D4E16F7DCF@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 22:58:28 -0000 --Apple-Mail=_7B5FB0F6-6B04-4BD4-A06A-3ACF401690CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 15, 2014, at 1:24 PM, Tim Kientzle wrote: > Ugh. This seems to be broken again. >=20 > On i386 -CURRENT from about a week ago: >=20 > make XDEV=3Darm XDEV_ARCH=3Darmv6 WITH_GCC_BOOTSTRAP=3D1 = WITHOUT_CLANG_BOOTSTRAP=3D1 WITHOUT_CLANG=3D1 xdev >=20 > Yields... >=20 > =3D=3D=3D> gnu/lib/libgcc (obj,depend,all,install) > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile = MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile = GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h > `unwind.h' is up to date. > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile = MFILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile = GCCDIR=3D/usr/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h > `gthr-default.h' is up to date. > cc -isystem //usr/armv6-freebsd/usr/include = -L//usr/armv6-freebsd/usr/lib --sysroot=3D//usr/armv6-freebsd/ = -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin = -B//usr/armv6-freebsd/usr/lib -c -O -pipe -DTARGET_ARM_EABI -DIN_GCC = -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. = -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Dinhibit_libc = -fno-inline -std=3Dgnu99 -fheinous-gnu-extensions -Qunused-arguments = -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 = -DElfW=3D__ElfN -o libunwind.o = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/arm/libunwind.S > = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/arm/lib1funcs.asm:1:3:= error: unexpected token at start of statement > @ libgcc routines for ARM cpu. > ^ > = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/arm/lib1funcs.asm:2:3:= error: unexpected token at start of statement > @ Division routines, written by Richard Earnshaw, = (rearnsha@armltd.co.uk) > ^ >=20 > I'm upgrading to see if anything has changed=85 With and without -j X would be helpful too. We=92ve had a few races = lately and that might help narrow it. > Tim >=20 > P.S. Just got a BBB Rev C with the 4G eMMC chip. Under Debian, > dd with a 1MiB block size shows around 10MB/s write, 30MB/s read > performance. Nice. Warner >=20 > On May 8, 2014, at 10:06 AM, Adrian Chadd wrote: >=20 >> [snip] >>=20 >> Ok. Thanks Ian/Warner. >>=20 >> The line that currently works for me is: >>=20 >> make XDEV=3Darm XDEV_ARCH=3Darmv6 WITH_GCC_BOOTSTRAP=3D1 >> WITHOUT_CLANG_BOOTSTRAP=3D1 WITHOUT_CLANG=3D1 xdev >>=20 >>=20 >>=20 >> -a >> _______________________________________________ >> 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 > _______________________________________________ > 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" --Apple-Mail=_7B5FB0F6-6B04-4BD4-A06A-3ACF401690CC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTniUTAAoJEGwc0Sh9sBEASfgP/R9Z7FAUrFDJiK0EJb2BQBZH UTIqheAYlOTwMxjIvtiUUmCMYLUUqilhcVwPTwI1/4NFi78XvG3b9Up9HqtOgsdr GXNzXh8nHn41nO4MsJNFinAvnRHaAIvae9OMYMFBEr8SBAI1C9l8hXtnl6d4LqRD JxXj2dmNiY9nY4NHZTeLeWhXPrvSPqzN5j+C1DrJmwwHbLTJfPQHfG+yc5kQPKJ7 hui5vgQVRV4jYSCtK7yKCZz4L9yMqAr4dk/X7RjYdkkbG/QXivfGQExPlXbS4sTV r2mk3s3nuvRiyWcO6eXLolrJcpJm0cYE6AHFJ0ikNGNeBN1PAAlDO14W805HWSuE 73T/I38bU0Cs2adpV6knE12zU0ttX3JSGa40kvuqJ7zrjGVi6SbshdnntcuaLb+q SfQR2jT6xjfJAAK3uBoNd0ASuON1iyuryX/n2xu8ab4vXSTsmb4DG1DR6R+q5DQa RSbfNeGAoh+AQajh9LwYBiTTeRnDKcDlHcwNdQ002OiLhakAf/j1jWaJxMAyRdQM 4I3olTt5Tcg2CTAdeAsarvDM6wCFUOD4Dw/RnQ29ioTOm+kY7jXh1AexNhgGgn7h P/JTgMmPJMsr8SeTUkXg+A5+Ff+ZmWKQ9w6lJX56VwB/VfofYczWcUi0Ak8uM1YQ 2SU3iB5vmbddTwzNASdH =Ljdp -----END PGP SIGNATURE----- --Apple-Mail=_7B5FB0F6-6B04-4BD4-A06A-3ACF401690CC-- From owner-freebsd-arm@FreeBSD.ORG Mon Jun 16 01:04:09 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8FF2F20 for ; Mon, 16 Jun 2014 01:04:09 +0000 (UTC) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D28C2405 for ; Mon, 16 Jun 2014 01:04:08 +0000 (UTC) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.14.8/8.14.8) with ESMTP id s5G144rC048167 for ; Mon, 16 Jun 2014 03:04:05 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Mon, 16 Jun 2014 03:04:03 +0200 (CEST) Message-ID: <44921fa0c7.323fafd0@mail.schwarzes.net> In-Reply-To: References: User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: FreeBSD doesn't boot anymore on RPi MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Mon, 16 Jun 2014 03:04:05 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 01:04:10 -0000 On 21.05.14, Michael Tuexen wrote: Hi all, > I just built r266500 and when booting that on a Raspberry Pi the booting stalls > after displaying Kernel args: (null). I run still in this problem, the last kernel which was working for me is r265403. Is this a know problem? regards, Andreas From owner-freebsd-arm@FreeBSD.ORG Mon Jun 16 01:43:00 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A329629A for ; Mon, 16 Jun 2014 01:43:00 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62A36267F for ; Mon, 16 Jun 2014 01:42:59 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WwLwn-000J0f-RP; Mon, 16 Jun 2014 01:42:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5G1gto3001483; Sun, 15 Jun 2014 19:42:55 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19aCCB4bAkMNF0h3NIFXJ/B Subject: Re: required xdev line to build r-pi on crochet? From: Ian Lepore To: Warner Losh In-Reply-To: <2B7F498D-F459-4E69-9341-C13D34A312B1@bsdimp.com> References: <8A277ED4-F041-4132-88C7-8F23BAA7F8C4@bsdimp.com> <1399553779.22079.316.camel@revolution.hippie.lan> <02A89B5B-5299-4341-978F-F6D4E16F7DCF@kientzle.com> <2B7F498D-F459-4E69-9341-C13D34A312B1@bsdimp.com> Content-Type: text/plain; charset="windows-1251" Date: Sun, 15 Jun 2014 19:42:55 -0600 Message-ID: <1402882975.20883.258.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s5G1gto3001483 Cc: Tim Kientzle , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 01:43:00 -0000 On Sun, 2014-06-15 at 16:58 -0600, Warner Losh wrote: > On Jun 15, 2014, at 1:24 PM, Tim Kientzle wrote: >=20 > > Ugh. This seems to be broken again. > >=20 > > On i386 -CURRENT from about a week ago: > >=20 > > make XDEV=3Darm XDEV_ARCH=3Darmv6 WITH_GCC_BOOTSTRAP=3D1 WITHOUT_CLAN= G_BOOTSTRAP=3D1 WITHOUT_CLANG=3D1 xdev > >=20 > > Yields... > >=20 > > =3D=3D=3D> gnu/lib/libgcc (obj,depend,all,install) > > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MF= ILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=3D= /usr/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h > > `unwind.h' is up to date. > > make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MF= ILE=3D/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=3D= /usr/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h > > `gthr-default.h' is up to date. > > cc -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr= /lib --sysroot=3D//usr/armv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec = -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib -c -O -pipe = -DTARGET_ARM_EABI -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAV= E_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/includ= e -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/l= ib/libgcc/../../../contrib/gcc -I. -I/usr/src/gnu/lib/libgcc/../../usr.b= in/cc/cc_tools -Dinhibit_libc -fno-inline -std=3Dgnu99 -fheinous-gnu-exte= nsions -Qunused-arguments -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fex= ceptions -D__GLIBC__=3D3 -DElfW=3D__ElfN -o libunwind.o /usr/src/gnu/lib/= libgcc/../../../contrib/gcc/config/arm/libunwind.S > > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/arm/lib1funcs.asm= :1:3: error: unexpected token at start of statement > > @ libgcc routines for ARM cpu. > > ^ > > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/arm/lib1funcs.asm= :2:3: error: unexpected token at start of statement > > @ Division routines, written by Richard Earnshaw, (rearnsha@armltd.co= .uk) > > ^ > >=20 > > I'm upgrading to see if anything has changed=85 >=20 > With and without -j X would be helpful too. We=92ve had a few races lat= ely and that might help narrow it. >=20 It's hard to see how -j would affect this, though. The @ symbol should be a comment delimiter and it appears to be complaining about what are clearly intended to be comment lines. Hmmm, I wonder if @ is only a comment delim in arm code and somehow the assembler thinks it's building x86 code? -- Ian > > Tim > >=20 > > P.S. Just got a BBB Rev C with the 4G eMMC chip. Under Debian, > > dd with a 1MiB block size shows around 10MB/s write, 30MB/s read > > performance. >=20 > Nice. >=20 > Warner >=20 >=20 > >=20 > > On May 8, 2014, at 10:06 AM, Adrian Chadd wrote: > >=20 > >> [snip] > >>=20 > >> Ok. Thanks Ian/Warner. > >>=20 > >> The line that currently works for me is: > >>=20 > >> make XDEV=3Darm XDEV_ARCH=3Darmv6 WITH_GCC_BOOTSTRAP=3D1 > >> WITHOUT_CLANG_BOOTSTRAP=3D1 WITHOUT_CLANG=3D1 xdev > >>=20 > >>=20 > >>=20 > >> -a > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or= g" > >=20 > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org= " >=20 From owner-freebsd-arm@FreeBSD.ORG Mon Jun 16 05:53:08 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3D96CD for ; Mon, 16 Jun 2014 05:53:08 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61C2328A1 for ; Mon, 16 Jun 2014 05:53:08 +0000 (UTC) Received: from [192.168.1.200] (p508F05E4.dip0.t-ipconnect.de [80.143.5.228]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 647951C10481A; Mon, 16 Jun 2014 07:53:04 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: FreeBSD doesn't boot anymore on RPi From: Michael Tuexen In-Reply-To: <44921fa0c7.323fafd0@mail.schwarzes.net> Date: Mon, 16 Jun 2014 07:53:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44921fa0c7.323fafd0@mail.schwarzes.net> To: Andreas Schwarz X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 05:53:08 -0000 On 16 Jun 2014, at 03:04, Andreas Schwarz = wrote: > On 21.05.14, Michael Tuexen wrote: >=20 > Hi all, >=20 >> I just built r266500 and when booting that on a Raspberry Pi the = booting stalls >> after displaying Kernel args: (null). >=20 > I run still in this problem, the last kernel which was working for me = is r265403. Is this > a know problem? Yes, it is known. There were two problems, one is fixed now. The other = problem is currently been worked on. Right now, you need to revert r266083 and = should get a working kernel. If not, please let us know. Best regards Michael >=20 > regards, > Andreas >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@FreeBSD.ORG Mon Jun 16 07:33:19 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C45985B; Mon, 16 Jun 2014 07:33:19 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC44820CD; Mon, 16 Jun 2014 07:33:18 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 205011FE045; Mon, 16 Jun 2014 09:33:18 +0200 (CEST) Message-ID: <539E9DD4.4080001@selasky.org> Date: Mon, 16 Jun 2014 09:33:40 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Alan Cox , Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> <5399FB57.8090102@rice.edu> <539A140F.6020107@selasky.org> <539B2BE8.2090005@rice.edu> In-Reply-To: <539B2BE8.2090005@rice.edu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 07:33:19 -0000 > > This output shows that according to the object's list of pages there is > already a page allocated at pindex 4 (or "off=0x4" above). If this list > is correct, and not itself corrupted, then we shouldn't be making a call > to vm_page_alloc() to allocate another page at the same pindex. > > Whether it is this list of pages that is corrupted or not, this means > that the object's list of pages (shown above) and its radix tree of > pages are out of sync. > > I'm curious to know what mpred is when the assertion fails. That will > tell us something about the state of the radix tree. > > I've also modified ddb's "show object" to provide an additional bit of > information. However, it would be really nice if "show object" > displayed the state of the radix tree. > > This patch makes no change. --HPS From owner-freebsd-arm@FreeBSD.ORG Mon Jun 16 08:59:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99BAEDC for ; Mon, 16 Jun 2014 08:59:23 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 8071D2880 for ; Mon, 16 Jun 2014 08:59:23 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 82E4F5DEBC for ; Mon, 16 Jun 2014 08:59:22 +0000 (UTC) Date: Mon, 16 Jun 2014 09:59:14 +0100 From: Andrew Turner To: freebsd-arm@freebsd.org Subject: Removing partially supported SoCs Message-ID: <20140616095914.21757989@bender.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 08:59:23 -0000 I'm looking at removing support for SoCs where we have code but nobody appears to be supporting it. Having this extra code means we have to update it, but are unable to test the changes as it may not boot. To begin with I'm planning on removing Tegra 2 and OMAP3 code. The Tegra 2 is quite old and, as far as I know, never got to single user mode. There is only one kernel config that builds the code. Along with this the SoC dependent code is very minimal as it only includes what appears to be the minimum code to build and start booting the kernel. For OMAP3 we don't have the std.omap3 or files.omap3 files, and therefore no kernel config. The omap3 directory only contains a file with the SoC specific register addresses. It also makes other Ti drivers more comples as they need to check which SoC they are running on. Removing OMAP3 will not affect the other Ti SoCs, i.e. OMAP4 and AM35xx. If anyone feels they wish to keep support for either of these SoCs they will need to work to improve the support of both getting the SoC booting to a useful state, and to help keep the code up to date with other kernel changes, i.e. to not leave when the SoC is booting to multi-user mode. If I get no complaints I'm planning on removing them this weekend. After this other SoCs will be evaluated to determine if we should still support them. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Jun 16 15:52:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7882484F for ; Mon, 16 Jun 2014 15:52:35 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 063432F78 for ; Mon, 16 Jun 2014 15:52:34 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id el20so3131671lab.15 for ; Mon, 16 Jun 2014 08:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jcnKpgmRtJ62UVDoEbSff7HPcyc3oBbsrufj86GvwpQ=; b=Nme0bLoJH86GuLMbB5PywLo+tx5bHIdv/A/SHoXMmrK+IQAM2SMYuPw4bEyeX0yXkQ OhVtlwv9tVeu3xavwrPyK4hgIes0E6S02wF5kPsVvvhEgnMEJ/eB/bM8YXybebWwvO5t P3Il6UJSLh2auLUxoLbxMk8lk4wOX6iGAldmdOMEl5O/X97q0Ku6mgInpcCwqhr/KAmq 8hFPR4HNG1vuFGTMFh8nJlQpsZGZhK3CIXIDJBtSAPqZa4fDKDYeH1Qp0EzIqQu4cfUn E/aghsgKCr8+XoRhowlqfrGwYntE7RvRvrOtKRO4k4l8lytKy8puqKsTwy/zOoUoePpA /LnA== MIME-Version: 1.0 X-Received: by 10.112.12.103 with SMTP id x7mr13428053lbb.36.1402933952889; Mon, 16 Jun 2014 08:52:32 -0700 (PDT) Received: by 10.112.45.8 with HTTP; Mon, 16 Jun 2014 08:52:32 -0700 (PDT) Date: Mon, 16 Jun 2014 11:52:32 -0400 Message-ID: Subject: Re: FreeBSD on HardKernel's ODROID platform From: Kris Smith To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:52:35 -0000 Hi, Is there a way to run FreeBSD on the Arndale Octa 5420 board. I am currently running Ubuntu packages by Linaro, but I am unable to switch between the little and big cores. The big (A15s) are the only ones that boot on startup w/ no way to switch to the little cores. Is there a way to do this in FreeBSD? Thank you. -- Sincerely, Kris Kristopher J. Smith Arizona State University Computer Systems Engineering Cell: 480.313.3974 From owner-freebsd-arm@FreeBSD.ORG Mon Jun 16 16:08:26 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB6D6DAA; Mon, 16 Jun 2014 16:08:26 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C0052142; Mon, 16 Jun 2014 16:08:25 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s5GG8G8W020831; Mon, 16 Jun 2014 11:08:24 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 1mgbwark0a-1; Mon, 16 Jun 2014 11:08:24 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id D3BBE50003F; Mon, 16 Jun 2014 11:08:23 -0500 (CDT) Message-ID: <539F1676.2020406@rice.edu> Date: Mon, 16 Jun 2014 11:08:22 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Hans Petter Selasky , Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> <5399FB57.8090102@rice.edu> <539A140F.6020107@selasky.org> <539B2BE8.2090005@rice.edu> <539E9DD4.4080001@selasky.org> In-Reply-To: <539E9DD4.4080001@selasky.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406160175 Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:08:26 -0000 On 06/16/2014 02:33, Hans Petter Selasky wrote: >> >> This output shows that according to the object's list of pages there is >> already a page allocated at pindex 4 (or "off=0x4" above). If this list >> is correct, and not itself corrupted, then we shouldn't be making a call >> to vm_page_alloc() to allocate another page at the same pindex. >> >> Whether it is this list of pages that is corrupted or not, this means >> that the object's list of pages (shown above) and its radix tree of >> pages are out of sync. >> >> I'm curious to know what mpred is when the assertion fails. That will >> tell us something about the state of the radix tree. >> >> I've also modified ddb's "show object" to provide an additional bit of >> information. However, it would be really nice if "show object" >> displayed the state of the radix tree. >> >> > > This patch makes no change. Can you please clarify? Did I not attach the new patch? The new patch changed the output of the KASSERT and ddb's "show object" so that we could get a better idea where the vm object corruption lies. From owner-freebsd-arm@FreeBSD.ORG Mon Jun 16 16:21:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FB13259 for ; Mon, 16 Jun 2014 16:21:14 +0000 (UTC) Received: from mail.machdep.com (mail.machdep.com [195.91.211.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CAB012252 for ; Mon, 16 Jun 2014 16:21:12 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=machdep.com) by mail.machdep.com with smtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WwZcY-000NfB-Sl; Mon, 16 Jun 2014 20:18:58 +0400 Received: by machdep.com (nbSMTP-1.00) for uid 1001 br@machdep.com; Mon, 16 Jun 2014 20:18:58 +0400 (MSK) Date: Mon, 16 Jun 2014 20:18:58 +0400 From: Ruslan Bukin To: Kris Smith Subject: Re: FreeBSD on HardKernel's ODROID platform Message-ID: <20140616161858.GA90762@machdep.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:21:14 -0000 Hi, Kris, On Mon, Jun 16, 2014 at 11:52:32AM -0400, Kris Smith wrote: > Is there a way to run FreeBSD on the Arndale Octa 5420 board. I am > currently running Ubuntu packages by Linaro, but I am unable to switch > between the little and big cores. The big (A15s) are the only ones that > boot on startup w/ no way to switch to the little cores. Is there a way to > do this in FreeBSD? I would be happy if someone will point me out on the information regarding booting A7 cores, but for now we support Arndale Octa with SMP on A15 cores only. Ruslan From owner-freebsd-arm@FreeBSD.ORG Mon Jun 16 20:45:00 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 198A07FE; Mon, 16 Jun 2014 20:45:00 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4D4E2C43; Mon, 16 Jun 2014 20:44:59 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 1A7F81FE045; Mon, 16 Jun 2014 22:44:58 +0200 (CEST) Message-ID: <539F575E.5070908@selasky.org> Date: Mon, 16 Jun 2014 22:45:18 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Alan Cox , Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> <5399FB57.8090102@rice.edu> <539A140F.6020107@selasky.org> <539B2BE8.2090005@rice.edu> <539E9DD4.4080001@selasky.org> <539F1676.2020406@rice.edu> In-Reply-To: <539F1676.2020406@rice.edu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:45:00 -0000 On 06/16/14 18:08, Alan Cox wrote: > On 06/16/2014 02:33, Hans Petter Selasky wrote: >>> >>> This output shows that according to the object's list of pages there is >>> already a page allocated at pindex 4 (or "off=0x4" above). If this list >>> is correct, and not itself corrupted, then we shouldn't be making a call >>> to vm_page_alloc() to allocate another page at the same pindex. >>> >>> Whether it is this list of pages that is corrupted or not, this means >>> that the object's list of pages (shown above) and its radix tree of >>> pages are out of sync. >>> >>> I'm curious to know what mpred is when the assertion fails. That will >>> tell us something about the state of the radix tree. >>> >>> I've also modified ddb's "show object" to provide an additional bit of >>> information. However, it would be really nice if "show object" >>> displayed the state of the radix tree. >>> >>> >> >> This patch makes no change. > > Can you please clarify? Did I not attach the new patch? The new patch > changed the output of the KASSERT and ddb's "show object" so that we > could get a better idea where the vm object corruption lies. > > Can you re-send the patch for ddb's show object? --HPS From owner-freebsd-arm@FreeBSD.ORG Tue Jun 17 01:22:00 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B1AEECF; Tue, 17 Jun 2014 01:22:00 +0000 (UTC) Received: from forward2l.mail.yandex.net (forward2l.mail.yandex.net [IPv6:2a02:6b8:0:1819::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7C3C233E; Tue, 17 Jun 2014 01:21:59 +0000 (UTC) Received: from smtp19.mail.yandex.net (smtp19.mail.yandex.net [95.108.252.19]) by forward2l.mail.yandex.net (Yandex) with ESMTP id 7DF301AC123C; Tue, 17 Jun 2014 05:21:56 +0400 (MSK) Received: from smtp19.mail.yandex.net (localhost [127.0.0.1]) by smtp19.mail.yandex.net (Yandex) with ESMTP id 11675BE00AC; Tue, 17 Jun 2014 05:21:55 +0400 (MSK) Received: from unknown (unknown [12.202.173.169]) by smtp19.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id drZcs2toy4-Ls549268; Tue, 17 Jun 2014 05:21:55 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 5b6edc8e-1c32-4122-8142-e9fbebd0a5e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402968115; bh=q7t6Yqe5cPbbtmOBTJrW57aUOeOj2xGfIqutJDQz5z4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=VND6IvgBL0NN7c4D3lTvsvF+PApADvRmI1EeCRlyt05nqH3i9jx3Jd/0yhB7uibFM qjq1GVTpeLsD1NSQYUsWGixj99OqbiYWcRXSCHxOyRYhWxNCAr8gPXPeG+KFU6YTJ+ i85aD8go3qit2qGxC5kRLBFWHOIij4MAmrndK12I= Authentication-Results: smtp19.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <539F9830.9030004@narod.ru> Date: Tue, 17 Jun 2014 07:21:52 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Compilation for ARM, patches References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> <539B24DB.4090005@narod.ru> <1402677258.20883.235.camel@revolution.hippie.lan> <539B5F68.5020008@narod.ru> <1402692723.20883.237.camel@revolution.hippie.lan> In-Reply-To: <1402692723.20883.237.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="------------000503000109070402010303" Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 01:22:00 -0000 This is a multi-part message in MIME format. --------------000503000109070402010303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Ian, May be you right about bug, but it's not allowed neither in gas, nor in clang. The issue actually was in double purpose of ENTRY: 1. It just defines function entry. 2. It defines .fnstart for exception unwinding. For example memset and bzero functions are overlapped in kernel, and this is a reason of producing overlapping of .fnstart/.fnend definitions. "bzero" starts earlier, and then enters into "memset" contents. So, it looks like, actually we need .fnstart for "dzero" only (am I right?). I have attached patches that allows to compile kernel with binutils-2.23 (compiled from ports/devel/cross-binutils, TGTARCH=arm, TGTABI=unknown-freebsd). I have introduced EENTRY, that just defines label without .fnstart. Please look what I did (I suppose I could be wrong with such approach, since after this patch I have a lot of Warning: null messages). Anyways these patches allows to run kernel with cortex-a9 options. P.S.: I also confused about u-boot version for pandaboard. uboot-2011.12 manages to load kernel.bin, but failed to deal with ubldr (perhaps because of absence of uboot-api). Latest u-boot version loads ubldr, but then it failes to boot kernel: loader> load boot/kernel/kernel boot/kernel/kernel data=0x492b48+0x2d4b8 <-- hangs here Thanks, Stepan. Ian Lepore wrote: > That sounds like a compiler bug to me, there's nothing invalid about > nesting a function within another function in assembler code. But, it's > the only toolchain we've got, so I guess we'll have to figure out some > other way to do things. > > That "nearby" comment I think is very old and outdated. > > -- Ian > > On Sat, 2014-06-14 at 02:30 +0600, Stepan Dyatkovskiy wrote: >> Modern compilers forbid to use nested .fnstart constructions (actually >> nested ENTRY uses). But FreeBSD code has them in few places. For >> example, in arm/exception.S file (see swi_entry). I saw the comment >> nearby swi_exit definition, but now quite understand how it relates with >> nested ENTRY uses... >> It looks like several entries were intruduced just because of >> alternative names for the same function. But I'm not sure... >> >> Thanks! >> >> -Stepan >> >> Why we need them >> Ian Lepore wrote: >>> On Fri, 2014-06-13 at 22:20 +0600, Stepan Dyatkovskiy wrote: >>>> Hi Ian, >>>> Yup. I have done it with default options. That works fine. Thanks! >>>> >>>> But, currently we need to compare launch times for kernel that was >>>> compiled with cortex-a9 options and for kernel that was compiled with >>>> cortex-a15 options. >>>> >>>> The reason of doing that is some improvements in clang backend that >>>> promises faster execution for (-mcpu=cortex-a15). So we would like to >>>> check it on FreeBSD kernel, since we going to use this OS as base for >>>> our applications. >>>> >>>> -Stepan >>> >>> I wonder if it is upset that the nesting is backwards, like >>> >>> NP_ENTRY(btext) >>> ASENTRY_NP(_start) >>> ... >>> END(btext) >>> END(_start) >>> >>> Maybe try switching the order of the END macros? If that doesn't help, >>> try removing the btext macros completely, I don't think they're needed >>> by anything these days. >>> >>> -- Ian >>> >>> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > --------------000503000109070402010303 Content-Type: text/x-diff; name="eentry.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="eentry.patch" Index: sys/arm/arm/cpufunc_asm_arm10.S =================================================================== --- sys/arm/arm/cpufunc_asm_arm10.S (revision 267429) +++ sys/arm/arm/cpufunc_asm_arm10.S (working copy) @@ -209,7 +209,7 @@ mcr p15, 0, r0, c7, c5, 0 /* Flush I cache */ /* Fall through to purge Dcache. */ -ENTRY(arm10_dcache_wbinv_all) +EENTRY(arm10_dcache_wbinv_all) .Larm10_dcache_wbinv_all: ldr ip, .Larm10_cache_data ldmia ip, {s_max, i_max, s_inc, i_inc} @@ -224,7 +224,7 @@ mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr END(arm10_idcache_wbinv_all) -END(arm10_dcache_wbinv_all) +/*END(arm10_dcache_wbinv_all)*/ .Larm10_cache_data: .word _C_LABEL(arm10_dcache_sets_max) Index: sys/arm/arm/cpufunc_asm_arm9.S =================================================================== --- sys/arm/arm/cpufunc_asm_arm9.S (revision 267429) +++ sys/arm/arm/cpufunc_asm_arm9.S (working copy) @@ -197,7 +197,7 @@ mcr p15, 0, r0, c7, c5, 0 /* Flush I cache */ /* Fall through */ -ENTRY(arm9_dcache_wbinv_all) +EENTRY(arm9_dcache_wbinv_all) .Larm9_dcache_wbinv_all: ldr ip, .Larm9_cache_data ldmia ip, {s_max, i_max, s_inc, i_inc} @@ -210,7 +210,7 @@ subs s_max, s_max, s_inc bhs .Lnext_set_inv /* Next set */ mov pc, lr -END(arm9_idcache_wbinv_all) +/*END(arm9_idcache_wbinv_all)*/ END(arm9_dcache_wbinv_all) .Larm9_cache_data: Index: sys/arm/arm/cpufunc_asm_armv5.S =================================================================== --- sys/arm/arm/cpufunc_asm_armv5.S (revision 267429) +++ sys/arm/arm/cpufunc_asm_armv5.S (working copy) @@ -194,6 +194,7 @@ END(armv5_idcache_wbinv_range) ENTRY_NP(armv5_idcache_wbinv_all) +armv5_idcache_wbinv_all: .Larmv5_idcache_wbinv_all: /* * We assume that the code here can never be out of sync with the @@ -203,7 +204,7 @@ mcr p15, 0, r0, c7, c5, 0 /* Flush I cache */ /* Fall through to purge Dcache. */ -ENTRY(armv5_dcache_wbinv_all) +EENTRY(armv5_dcache_wbinv_all) .Larmv5_dcache_wbinv_all: ldr ip, .Larmv5_cache_data ldmia ip, {s_max, i_max, s_inc, i_inc} @@ -220,7 +221,7 @@ mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ RET END(armv5_idcache_wbinv_all) -END(armv5_dcache_wbinv_all) +/*END(armv5_dcache_wbinv_all)*/ .Larmv5_cache_data: .word _C_LABEL(armv5_dcache_sets_max) Index: sys/arm/arm/cpufunc_asm_armv6.S =================================================================== --- sys/arm/arm/cpufunc_asm_armv6.S (revision 267429) +++ sys/arm/arm/cpufunc_asm_armv6.S (working copy) @@ -137,12 +137,12 @@ /* Fall through to purge Dcache. */ /* LINTSTUB: void armv6_dcache_wbinv_all(void); */ -ENTRY(armv6_dcache_wbinv_all) +EENTRY(armv6_dcache_wbinv_all) mcr p15, 0, r0, c7, c14, 0 /* clean & invalidate D cache */ mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ RET END(armv6_idcache_wbinv_all) -END(armv6_dcache_wbinv_all) +/*END(armv6_dcache_wbinv_all)*/ ENTRY(armv6_idcache_inv_all) mov r0, #0 Index: sys/arm/arm/cpufunc_asm_armv7.S =================================================================== --- sys/arm/arm/cpufunc_asm_armv7.S (revision 267429) +++ sys/arm/arm/cpufunc_asm_armv7.S (working copy) @@ -358,7 +358,7 @@ mcr p15, 0, r0, c7, c5, 0 @ invalidate instruction+branch cache isb @ instruction sync barrier bx lr @ return -END(armv7_l1cache_inv_all) +END(armv7_idcache_inv_all) ENTRY_NP(armv7_sleep) dsb Index: sys/arm/arm/cpufunc_asm_xscale.S =================================================================== --- sys/arm/arm/cpufunc_asm_xscale.S (revision 267429) +++ sys/arm/arm/cpufunc_asm_xscale.S (working copy) @@ -306,11 +306,12 @@ XSCALE_CACHE_CLEAN_UNBLOCK ENTRY_NP(xscale_cache_syncI) -ENTRY_NP(xscale_cache_purgeID) + +EENTRY_NP(xscale_cache_purgeID) mcr p15, 0, r0, c7, c5, 0 /* flush I cache (D cleaned below) */ -ENTRY_NP(xscale_cache_cleanID) -ENTRY_NP(xscale_cache_purgeD) -ENTRY(xscale_cache_cleanD) +EENTRY_NP(xscale_cache_cleanID) +EENTRY_NP(xscale_cache_purgeD) +EENTRY(xscale_cache_cleanD) XSCALE_CACHE_CLEAN_PROLOGUE 1: subs r0, r0, #32 @@ -327,10 +328,10 @@ XSCALE_CACHE_CLEAN_EPILOGUE RET END(xscale_cache_syncI) -END(xscale_cache_purgeID) -END(xscale_cache_cleanID) -END(xscale_cache_purgeD) -END(xscale_cache_cleanD) +/*END(xscale_cache_purgeID)*/ +/*END(xscale_cache_cleanID)*/ +/*END(xscale_cache_purgeD)*/ +/*END(xscale_cache_cleanD)*/ /* * Clean the mini-data cache. @@ -374,7 +375,7 @@ */ /* xscale_cache_syncI is identical to xscale_cache_purgeID */ -ENTRY(xscale_cache_cleanID_rng) +EENTRY(xscale_cache_cleanID_rng) ENTRY(xscale_cache_cleanD_rng) cmp r1, #0x4000 bcs _C_LABEL(xscale_cache_cleanID) @@ -393,7 +394,7 @@ mcr p15, 0, r0, c7, c10, 4 /* drain write buffer */ CPWAIT_AND_RETURN(r0) -END(xscale_cache_cleanID_rng) +/*END(xscale_cache_cleanID_rng)*/ END(xscale_cache_cleanD_rng) ENTRY(xscale_cache_purgeID_rng) Index: sys/arm/arm/cpufunc_asm_xscale_c3.S =================================================================== --- sys/arm/arm/cpufunc_asm_xscale_c3.S (revision 267429) +++ sys/arm/arm/cpufunc_asm_xscale_c3.S (working copy) @@ -143,11 +143,12 @@ ENTRY_NP(xscalec3_cache_syncI) -ENTRY_NP(xscalec3_cache_purgeID) +xscalec3_cache_purgeID: +EENTRY_NP(xscalec3_cache_purgeID) mcr p15, 0, r0, c7, c5, 0 /* flush I cache (D cleaned below) */ -ENTRY_NP(xscalec3_cache_cleanID) -ENTRY_NP(xscalec3_cache_purgeD) -ENTRY(xscalec3_cache_cleanD) +EENTRY_NP(xscalec3_cache_cleanID) +EENTRY_NP(xscalec3_cache_purgeD) +EENTRY(xscalec3_cache_cleanD) XSCALE_CACHE_CLEAN_BLOCK mov r0, #0 @@ -169,10 +170,10 @@ RET END(xscalec3_cache_syncI) -END(xscalec3_cache_purgeID) -END(xscalec3_cache_cleanID) -END(xscalec3_cache_purgeD) -END(xscalec3_cache_cleanD) +/*END(xscalec3_cache_purgeID)*/ +/*END(xscalec3_cache_cleanID)*/ +/*END(xscalec3_cache_purgeD)*/ +/*END(xscalec3_cache_cleanD)*/ ENTRY(xscalec3_cache_purgeID_rng) @@ -238,7 +239,7 @@ END(xscalec3_cache_purgeD_rng) ENTRY(xscalec3_cache_cleanID_rng) -ENTRY(xscalec3_cache_cleanD_rng) +EENTRY(xscalec3_cache_cleanD_rng) cmp r1, #0x4000 bcs _C_LABEL(xscalec3_cache_cleanID) @@ -258,7 +259,7 @@ CPWAIT_AND_RETURN(r0) END(xscalec3_cache_cleanID_rng) -END(xscalec3_cache_cleanD_rng) +/*END(xscalec3_cache_cleanD_rng)*/ ENTRY(xscalec3_l2cache_purge) /* Clean-up the L2 cache */ Index: sys/arm/arm/exception.S =================================================================== --- sys/arm/arm/exception.S (revision 267429) +++ sys/arm/arm/exception.S (working copy) @@ -280,13 +280,13 @@ * that a newly created thread appears to return from a SWI just like * the parent thread that created it. */ -ASENTRY_NP(swi_exit) +ASEENTRY_NP(swi_exit) DO_AST /* Handle pending signals. */ PULLFRAME /* Deallocate trapframe. */ movs pc, lr /* Return to userland. */ STOP_UNWINDING /* Don't unwind into user mode. */ END(swi_exit) -END(swi_entry) +/*END(swi_entry)*/ /* * Standard exception exit handler. Index: sys/arm/arm/fusu.S =================================================================== --- sys/arm/arm/fusu.S (revision 267429) +++ sys/arm/arm/fusu.S (working copy) @@ -54,7 +54,7 @@ * Fetch an int from the user's address space. */ -ENTRY_NP(casuword32) +EENTRY_NP(casuword32) ENTRY(casuword) GET_PCB(r3) ldr r3, [r3] @@ -91,7 +91,7 @@ mov r1, #0x00000000 str r1, [r3, #PCB_ONFAULT] RET -END(casuword32) +/*END(casuword32)*/ END(casuword) /* @@ -110,7 +110,7 @@ * Fetch an int from the user's address space. */ -ENTRY_NP(fuword32) +EENTRY_NP(fuword32) ENTRY(fuword) GET_PCB(r2) ldr r2, [r2] @@ -129,7 +129,7 @@ str r1, [r2, #PCB_ONFAULT] mov r0, r3 RET -END(fuword32) +/*END(fuword32)*/ END(fuword) /* @@ -277,7 +277,7 @@ * Store an int in the user's address space. */ -ENTRY_NP(suword32) +EENTRY_NP(suword32) ENTRY(suword) GET_PCB(r2) ldr r2, [r2] @@ -295,7 +295,7 @@ mov r0, #0x00000000 str r0, [r2, #PCB_ONFAULT] RET -END(suword32) +/*END(suword32)*/ END(suword) /* @@ -390,4 +390,3 @@ str r0, [r2, #PCB_ONFAULT] RET END(subyte) - Index: sys/arm/arm/locore.S =================================================================== --- sys/arm/arm/locore.S (revision 267429) +++ sys/arm/arm/locore.S (working copy) @@ -76,7 +76,7 @@ * structure and pass that to initarm. */ ENTRY_NP(btext) -ASENTRY_NP(_start) +ASEENTRY_NP(_start) STOP_UNWINDING /* Can't unwind into the bootloader! */ mov r9, r0 /* 0 or boot mode from boot2 */ @@ -285,9 +285,8 @@ adr r0, .Lmainreturned b _C_LABEL(panic) /* NOTREACHED */ +/*END(_start)*/ END(btext) -END(_start) - /* * Builds the page table * r0 - The table base address @@ -555,10 +554,10 @@ .align 0 .global _C_LABEL(esigcode) _C_LABEL(esigcode): - +END(sigcode) .data .global szsigcode szsigcode: .long esigcode-sigcode -END(sigcode) +/*END(sigcode)*/ /* End of locore.S */ Index: sys/arm/arm/setstack.s =================================================================== --- sys/arm/arm/setstack.s (revision 267429) +++ sys/arm/arm/setstack.s (working copy) @@ -71,7 +71,7 @@ msr cpsr_fsxc, r3 /* Restore the old mode */ mov pc, lr /* Exit */ - +END(set_stackptr) /* To get the stack pointer for a particular mode we must switch * to that mode copy the banked r13 and then switch back. * This routine provides an easy way of doing this for any mode @@ -90,5 +90,5 @@ msr cpsr_fsxc, r3 /* Restore the old mode */ mov pc, lr /* Exit */ - +END(get_stackptr) /* End of setstack.S */ Index: sys/arm/arm/support.S =================================================================== --- sys/arm/arm/support.S (revision 267429) +++ sys/arm/arm/support.S (working copy) @@ -130,7 +130,7 @@ .Lnormal0: mov r3, #0x00 b do_memset - +END(bzero) /* LINTSTUB: Func: void *memset(void *, int, size_t) */ ENTRY(memset) and r3, r1, #0xff /* We deal with bytes */ @@ -276,7 +276,6 @@ strgeb r3, [ip], #0x01 /* Set another byte */ strgtb r3, [ip] /* and a third */ RET /* Exit */ -END(bzero) END(memset) ENTRY(bcmp) @@ -394,7 +393,7 @@ eor r0, r1, r0 eor r1, r0, r1 eor r0, r1, r0 -ENTRY(memmove) +EENTRY(memmove) /* Do the buffers overlap? */ cmp r0, r1 RETeq /* Bail now if src/dst are the same */ @@ -932,7 +931,7 @@ add r1, r1, #1 b .Lmemmove_bl4 END(bcopy) -END(memmove) +/*END(memmove)*/ #if !defined(_ARM_ARCH_5E) ENTRY(memcpy) @@ -2945,13 +2944,17 @@ ENTRY(user) nop +END(user) ENTRY(btrap) nop +END(btrap) ENTRY(etrap) nop +END(etrap) ENTRY(bintr) nop +END(bintr) ENTRY(eintr) nop - +END(eintr) #endif Index: sys/arm/include/asm.h =================================================================== --- sys/arm/include/asm.h (revision 267429) +++ sys/arm/include/asm.h (working copy) @@ -74,6 +74,8 @@ #define GLOBAL(X) .globl x #define _ENTRY(x) \ .text; _ALIGN_TEXT; .globl x; .type x,_ASM_TYPE_FUNCTION; x: _FNSTART +#define _EENTRY(x) \ + .globl x; .type x,_ASM_TYPE_FUNCTION; x: #define _END(x) .size x, . - x; _FNEND @@ -85,10 +87,14 @@ #endif #define ENTRY(y) _ENTRY(_C_LABEL(y)); _PROF_PROLOGUE +#define EENTRY(y) _EENTRY(_C_LABEL(y)); _PROF_PROLOGUE #define ENTRY_NP(y) _ENTRY(_C_LABEL(y)) +#define EENTRY_NP(y) _EENTRY(_C_LABEL(y)) #define END(y) _END(_C_LABEL(y)) #define ASENTRY(y) _ENTRY(_ASM_LABEL(y)); _PROF_PROLOGUE +#define ASEENTRY(y) _EENTRY(_ASM_LABEL(y)); _PROF_PROLOGUE #define ASENTRY_NP(y) _ENTRY(_ASM_LABEL(y)) +#define ASEENTRY_NP(y) _EENTRY(_ASM_LABEL(y)) #define ASEND(y) _END(_ASM_LABEL(y)) #define ASMSTR .asciz Index: sys/libkern/arm/divsi3.S =================================================================== --- sys/libkern/arm/divsi3.S (revision 267429) +++ sys/libkern/arm/divsi3.S (working copy) @@ -52,8 +52,8 @@ END(__modsi3) #ifdef __ARM_EABI__ -ENTRY_NP(__aeabi_uidiv) -ENTRY_NP(__aeabi_uidivmod) +EENTRY_NP(__aeabi_uidiv) +EENTRY_NP(__aeabi_uidivmod) #endif ENTRY_NP(__udivsi3) .L_udivide: /* r0 = r0 / r1; r1 = r0 % r1 */ @@ -77,14 +77,14 @@ mov r1, #0 RET #ifdef __ARM_EABI__ -END(__aeabi_uidiv) -END(__aeabi_uidivmod) +/*END(__aeabi_uidiv)*/ +/*END(__aeabi_uidivmod)*/ #endif END(__udivsi3) #ifdef __ARM_EABI__ -ENTRY_NP(__aeabi_idiv) -ENTRY_NP(__aeabi_idivmod) +EENTRY_NP(__aeabi_idiv) +EENTRY_NP(__aeabi_idivmod) #endif ENTRY_NP(__divsi3) .L_divide: /* r0 = r0 / r1; r1 = r0 % r1 */ @@ -401,8 +401,8 @@ mov r0, r3 RET #ifdef __ARM_EABI__ -END(__aeabi_idiv) -END(__aeabi_idivmod) +/*END(__aeabi_idiv)*/ +/*END(__aeabi_idivmod)*/ #endif END(__divsi3) --------------000503000109070402010303 Content-Type: text/x-diff; name="arch-extension.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arch-extension.patch" Index: sys/arm/ti/ti_smc.S =================================================================== --- sys/arm/ti/ti_smc.S (revision 267429) +++ sys/arm/ti/ti_smc.S (working copy) @@ -27,6 +27,7 @@ __FBSDID("$FreeBSD$"); .arch armv7a +.arch_extension sec /* Issue a smc #0 call */ /* r0 and r1 contains the eventual arguments, r2 contains the function ID */ --------------000503000109070402010303-- From owner-freebsd-arm@FreeBSD.ORG Tue Jun 17 04:45:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD4508F4; Tue, 17 Jun 2014 04:45:29 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 832F9222A; Tue, 17 Jun 2014 04:45:29 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id m1so7267890oag.33 for ; Mon, 16 Jun 2014 21:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wXG9fZN+MrvHg0s8P0ezibhhnTYOGtz0TgB98SvGOok=; b=xzmdXqIjxXD3J9YO35EffNOsVZFzZgXW6+JapJ9RuyYLtXOW09BRlYf5xvn1Lz3imB 418yQqWkis2g/6y0SLgdade+UJQpVeTTmWebN0QfyBKJLlMDrattFW1TCPghzYz1KSUX RgxukZZb/qnjng4W/0yB+zSK/pALYalCNRHGbLBku09zO7k8z+8Fswj/FnVU6BU2KEGC ZH6fT4xS7I1aMt2XCRL+lF8RngOJB3gXJEEiFGCuiBZmtmD7Ccmrxd3pCZGONPQlfqNn /azYuFvJhRvqiknW5XIohfy795r+iOnVbYspQjyyid22OYcXjpraiev3voggtLmi6AT3 UypA== X-Received: by 10.182.89.164 with SMTP id bp4mr16244998obb.21.1402980328808; Mon, 16 Jun 2014 21:45:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.123.176 with HTTP; Mon, 16 Jun 2014 21:44:58 -0700 (PDT) In-Reply-To: References: <44921fa0c7.323fafd0@mail.schwarzes.net> From: Jia-Shiun Li Date: Tue, 17 Jun 2014 12:44:58 +0800 Message-ID: Subject: Re: FreeBSD doesn't boot anymore on RPi To: Michael Tuexen , markm@freebsd.org, Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , Andreas Schwarz X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 04:45:30 -0000 On Mon, Jun 16, 2014 at 1:53 PM, Michael Tuexen wrote: > On 16 Jun 2014, at 03:04, Andreas Schwarz wrote: >> On 21.05.14, Michael Tuexen wrote: >> >> Hi all, >> >>> I just built r266500 and when booting that on a Raspberry Pi the booting stalls >>> after displaying Kernel args: (null). >> >> I run still in this problem, the last kernel which was working for me is r265403. Is this >> a know problem? > Yes, it is known. There were two problems, one is fixed now. The other problem > is currently been worked on. Right now, you need to revert r266083 and should > get a working kernel. If not, please let us know. > adding ian@ and markm@. Hi, looks ARM1176, aka RPi, has different register location for performance counters. r266083 uses PMC registers defined at c9:c12~c14 of CP15. The location is true for Cortex-A8[1] onward. For ARM11 which predated A8, however, these registers are located at c15:c12[2]. c9:c12~c14 are undefined on ARM1176. According to ARMARM, pre-ARM11 cores do not have PMC. So they must have decided the debut location of PMC was not suitable anymore , and moved to c9 afterward. For RPi I think it is simpler to exclude ARM11 in original code for now. After making sure PMC registers on ARM11, despite different location, are still suitable for the purpose, it can have dedicated handling different from other cores. Other cores like pj4b and Krait may need additional check. [1] Ch.3.2.1 of Cortex-A8 TRM r3p2, http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/ch03s02s01.html [2] Ch.3.2.1 of ARM1176jz-s TRM r0p7, http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/ch03s02s01.html -Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Tue Jun 17 06:10:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 987BB528; Tue, 17 Jun 2014 06:10:10 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5873D281A; Tue, 17 Jun 2014 06:10:10 +0000 (UTC) Received: from [192.168.1.200] (p508F2AAE.dip0.t-ipconnect.de [80.143.42.174]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9CDCF1C10481A; Tue, 17 Jun 2014 08:10:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: FreeBSD doesn't boot anymore on RPi From: Michael Tuexen In-Reply-To: Date: Tue, 17 Jun 2014 08:10:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44921fa0c7.323fafd0@mail.schwarzes.net> To: Jia-Shiun Li X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" , Andreas Schwarz , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 06:10:10 -0000 On 17 Jun 2014, at 06:44, Jia-Shiun Li wrote: > On Mon, Jun 16, 2014 at 1:53 PM, Michael Tuexen = wrote: >> On 16 Jun 2014, at 03:04, Andreas Schwarz = wrote: >>> On 21.05.14, Michael Tuexen wrote: >>>=20 >>> Hi all, >>>=20 >>>> I just built r266500 and when booting that on a Raspberry Pi the = booting stalls >>>> after displaying Kernel args: (null). >>>=20 >>> I run still in this problem, the last kernel which was working for = me is r265403. Is this >>> a know problem? >> Yes, it is known. There were two problems, one is fixed now. The = other problem >> is currently been worked on. Right now, you need to revert r266083 = and should >> get a working kernel. If not, please let us know. >>=20 >=20 > adding ian@ and markm@. >=20 >=20 > Hi, >=20 > looks ARM1176, aka RPi, has different register location for > performance counters. >=20 > r266083 uses PMC registers defined at c9:c12~c14 of CP15. The location > is true for Cortex-A8[1] onward. For ARM11 which predated A8, however, > these registers are located at c15:c12[2]. c9:c12~c14 are undefined on > ARM1176. >=20 > According to ARMARM, pre-ARM11 cores do not have PMC. So they must > have decided the debut location of PMC was not suitable anymore , and > moved to c9 afterward. >=20 > For RPi I think it is simpler to exclude ARM11 in original code for > now. After making sure PMC registers on ARM11, despite different > location, are still suitable for the purpose, it can have dedicated > handling different from other cores. >=20 > Other cores like pj4b and Krait may need additional check. >=20 > [1] Ch.3.2.1 of Cortex-A8 TRM r3p2, > = http://infocenter.arm.com/help/index.jsp?topic=3D/com.arm.doc.ddi0344k/ch0= 3s02s01.html > [2] Ch.3.2.1 of ARM1176jz-s TRM r0p7, > = http://infocenter.arm.com/help/index.jsp?topic=3D/com.arm.doc.ddi0333h/ch0= 3s02s01.html Please have a look at the thread 'Re: svn commit: r266083 - in = head/sys/arm: arm include' on current@freebsd.org. The patches being discussed there allow the RPI. = Basically they use different registers on different platforms as you write. Best regards Michael >=20 > -Jia-Shiun. >=20 From owner-freebsd-arm@FreeBSD.ORG Tue Jun 17 13:11:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47C07C2F; Tue, 17 Jun 2014 13:11:52 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DC722E0F; Tue, 17 Jun 2014 13:11:51 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id bs8so5786452wib.15 for ; Tue, 17 Jun 2014 06:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BpgIXHVI7jRjLWvQ86n0Ath3bIjTWLFMFYwEwZmK8EU=; b=ZHyx6CeskynsnoyY6A2zDBVU/1q7/QGIYCMVGqgdg2bjWCOP0qPZTMn+K5qDkewkwS DLT3Qpym1Nt0hmEBKlt1x5+XmfJogxV53Me6twdYGQmba1rwYhSm3bmM+KDslpuH14G8 tLN0lQDNcB+ahsi28qsFPZzX6AftI+Cptr/8j1NSM/0dFmVi3iucJE1rs4H9QLNfMXG1 wM2Wv4mTV8Jt7dwsUIfjjyd3VqFq7KQeddCtB7VnmLoe0GfgxsLtQ60MYs+bjQMaTQSV Osaj9tLH5/MZlpYopthecgrDB+58qi9c/vQRisrz2CVqdZi3nnId5wthR6vvvDjsAxA0 Zk9g== MIME-Version: 1.0 X-Received: by 10.180.84.226 with SMTP id c2mr36625484wiz.50.1403010709514; Tue, 17 Jun 2014 06:11:49 -0700 (PDT) Received: by 10.180.90.15 with HTTP; Tue, 17 Jun 2014 06:11:49 -0700 (PDT) Date: Tue, 17 Jun 2014 17:11:49 +0400 Message-ID: Subject: FreeBSD on ARM Android Emulator [June 9 - 16] From: Alexander Tarasikov To: "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org, Gavin Atkinson , soc-status@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 13:11:52 -0000 Hi! I'll summarize what I've been up to recently. I have done a relatively large part of work at the start of May prior to the start of coding period but was unfortunately unable to work at the end of May due to my studies. Tonight I've pushed the code to my svn branch and updated the wiki. Here is my report on what has been done and what I want to work on next. I now have the FreeBSD 10 kernel starting up and writing text to emulator's UART (I was using fbsd10 during development to avoid switching versions in process. I have migrated the code to 'HEAD' yesterday, but it doesn't boot yet, I'm investigating). The following drivers are implemented: PIC (Interrupt controller), Timer, UART, Ethernet (the emulator emulates SMSC91xx, it's just MMIO). I have implemented the framebuffer driver, but have not fully tested it yet. I have tested that it initializes the device and the screen turns white when I memset framebuffer memory with 0xff, but I was unable to get SYSCONS working. If I attach the fb driver to sysbus, it doesn't register - I suppose it would if I actually mounted rootfs, but since I don't, it is just too early. On the other hand, if I attach it to fdtbus, I get a null pointer dereference in sc_attach_unit because syscons driver is not installed that early. Regarding the rootfs boot, I have discovered that Android Emulator uses the virtual NAND chip to access "system.img" file, which is what the user gets when they download an image for Android Emulator. Virtual MMC is only used to access user data image, which is generated at the user's machine. I could probably try NFS boot or booting from an MD ramdisk, but I want to have NAND working first. I have a question regarding the Device Tree. Android Emulator has a virtual device called "pdev" which allows to get the list of available devices and their MMIO ranges. Although this data is unlikely to change, it would be nice to implement it because this is an interesting use case. What is the advised way to do it? Should I register the PDEV as a simple-bus device and patch the FDT inside its probe function or will it not work? During the next two weeks I want to have the driver for NAND and get the kernel to boot the userland. After that I'll build an image which one can load into the emulator for testing. Next I'll write drivers for some peripherals. Android Emulator provides several virtual devices. Most interesting are sensors (accelerometer/gyroscope), multiple input event sources (keyboard, touchscreen), audio driver. I think they are important because only a few boards (rPI, IMX6, OMAP3) provide the support for display and I'm not sure if any board supports audio or sensors. Writing drivers for uncommon features will provide a set of sample code which can be used to bring up real boards. If I have spare time before the end of GSoC, I will start porting FreeBSD to Google Nexus 5 phone with Qualcomm MSM8974 CPU, I want to have at least framebuffer and touchscreen working. If I don't have extra time, I don't think I will port FreeBSD to Nexus after GSoC because writing drivers is rather boring, and since Qemu has recently gained support for AArch64 (which is 64-bit ARM), I think it is a more interesting area to experiment with. Overall I have found that some drivers like syscons (framebuffer), UART, become unnecessarily complicated with a lot of dummy functions which need to be implemented, but looks like some cleanup was done in HEAD as compared to 10.0. I think I'll look into it after I'm done with the emulator project. Maybe it would be good to factor out some common code into a generic driver ? -- Regards, Alexander From owner-freebsd-arm@FreeBSD.ORG Tue Jun 17 21:49:50 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBE54553 for ; Tue, 17 Jun 2014 21:49:50 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EFB42114 for ; Tue, 17 Jun 2014 21:49:50 +0000 (UTC) Received: from [192.168.1.200] (p508F288A.dip0.t-ipconnect.de [80.143.40.138]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 92E5D1C1047E4; Tue, 17 Jun 2014 23:49:46 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: FreeBSD doesn't boot anymore on RPi From: Michael Tuexen In-Reply-To: <44921fa0c7.323fafd0@mail.schwarzes.net> Date: Tue, 17 Jun 2014 23:49:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05FC286A-5306-4F77-A327-032F1F8126C0@fh-muenster.de> References: <44921fa0c7.323fafd0@mail.schwarzes.net> To: Andreas Schwarz X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:49:50 -0000 On 16 Jun 2014, at 03:04, Andreas Schwarz = wrote: > On 21.05.14, Michael Tuexen wrote: >=20 > Hi all, >=20 >> I just built r266500 and when booting that on a Raspberry Pi the = booting stalls >> after displaying Kernel args: (null). >=20 > I run still in this problem, the last kernel which was working for me = is r265403. Is this > a know problem? Fixed in http://svnweb.freebsd.org/changeset/base/267597 Best regards Michael >=20 > regards, > Andreas >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@FreeBSD.ORG Tue Jun 17 23:00:23 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 971922AC for ; Tue, 17 Jun 2014 23:00:23 +0000 (UTC) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F5AB288C for ; Tue, 17 Jun 2014 23:00:22 +0000 (UTC) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.14.8/8.14.8) with ESMTP id s5HN0CgF056065; Wed, 18 Jun 2014 01:00:12 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: Michael Tuexen Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Wed, 18 Jun 2014 01:00:11 +0200 (CEST) Message-ID: <4494a59023a.2da811a1@mail.schwarzes.net> In-Reply-To: <05FC286A-5306-4F77-A327-032F1F8126C0@fh-muenster.de> References: <44921fa0c7.323fafd0@mail.schwarzes.net> <05FC286A-5306-4F77-A327-032F1F8126C0@fh-muenster.de> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: FreeBSD doesn't boot anymore on RPi MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Wed, 18 Jun 2014 01:00:12 +0200 (CEST) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 23:00:23 -0000 On 17.06.14, Michael Tuexen wrote: > On 16 Jun 2014, at 03:04, Andreas Schwarz wrote: >> On 21.05.14, Michael Tuexen wrote: >>> I just built r266500 and when booting that on a Raspberry Pi the booting stalls >>> after displaying Kernel args: (null). >> >> I run still in this problem, the last kernel which was working for me is r265403. Is this >> a know problem? > Fixed in > http://svnweb.freebsd.org/changeset/base/267597 Ok, thank you, will try it. Regards Andreas From owner-freebsd-arm@FreeBSD.ORG Wed Jun 18 09:48:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FC1FE8A for ; Wed, 18 Jun 2014 09:48:03 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 17CF22CB8 for ; Wed, 18 Jun 2014 09:48:01 +0000 (UTC) Received: from work.netasq.com (localhost [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 21FD52700A17 for ; Wed, 18 Jun 2014 11:47:55 +0200 (CEST) Received: from [10.2.1.1] (unknown [91.212.116.2]) by work.netasq.com (Postfix) with ESMTPSA id E1E232700253 for ; Wed, 18 Jun 2014 11:47:54 +0200 (CEST) From: Fabien Thomas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [CFR] mge driver / elf reloc Message-Id: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> Date: Wed, 18 Jun 2014 11:47:54 +0200 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 09:48:03 -0000 Hello, I've some pending patches to review before commit. Fix reloc alignment in ELF: http://people.freebsd.org/~fabient/ARM/patch-arm_elf_alignfix Add missing stat counter: http://people.freebsd.org/~fabient/ARM/patch-mge_ipackets Add missing rcvif: http://people.freebsd.org/~fabient/ARM/patch-mge_rcvif Fix deadlock on transmit in error case: http://people.freebsd.org/~fabient/ARM/patch-mge_tx_deadlock Avoid packet copy on transmit: http://people.freebsd.org/~fabient/ARM/patch-mge_tx_optim Any comment ? Fabien From owner-freebsd-arm@FreeBSD.ORG Wed Jun 18 17:37:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42120F8C for ; Wed, 18 Jun 2014 17:37:30 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CC692CF9 for ; Wed, 18 Jun 2014 17:37:30 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id m1so2556344oag.35 for ; Wed, 18 Jun 2014 10:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C1x190N6W81s/+6qG7tDilE0+k/6vY61+5VSrbXkOCY=; b=xD/DKMZTS1OeD29qMhXUAWUtUQxJs0EkFogohpbulKo4FgD9jrOWKC1lg+QSmrx2nm vh/wz2i7M9I/H1grq7w4zPNscfaXGIOhQg6uysVvJsz4/3gnnN4aBEpPTfxbMRgQZzlI 1+sTA+yjBVeOuCRv8+rpW99KvCtMFw1Nz3jdIdDfF1+G6kj3ZZdIdZbVQTXqBw0YUSE6 kIVUSkaC35UAzP9TQdRtODv3HneOpe5CWW9i7vLrOosFTUhCPSdrysFFRPGmCinD9cEY ut0WvhXAhM/62sNe5U2gN3yhs1qk1uquM3J4LzYJDorUgqTX39vF71fvLfrf0acwU+gf ImoA== X-Received: by 10.60.175.163 with SMTP id cb3mr3346440oec.29.1403113049210; Wed, 18 Jun 2014 10:37:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.123.176 with HTTP; Wed, 18 Jun 2014 10:36:58 -0700 (PDT) In-Reply-To: <4494a59023a.2da811a1@mail.schwarzes.net> References: <44921fa0c7.323fafd0@mail.schwarzes.net> <05FC286A-5306-4F77-A327-032F1F8126C0@fh-muenster.de> <4494a59023a.2da811a1@mail.schwarzes.net> From: Jia-Shiun Li Date: Thu, 19 Jun 2014 01:36:58 +0800 Message-ID: Subject: Re: FreeBSD doesn't boot anymore on RPi To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Cc: Michael Tuexen X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 17:37:30 -0000 On Wed, Jun 18, 2014 at 7:00 AM, Andreas Schwarz wrote: > On 17.06.14, Michael Tuexen wrote: >> Fixed in >> http://svnweb.freebsd.org/changeset/base/267597 > > Ok, thank you, will try it. > Tested ok with r267607 on RPi. Thank you! -Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Wed Jun 18 22:58:10 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02A04B46; Wed, 18 Jun 2014 22:58:09 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B775E2A3E; Wed, 18 Jun 2014 22:58:09 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5IMw8qm041050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2014 15:58:08 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5IMw8OC041049; Wed, 18 Jun 2014 15:58:08 -0700 (PDT) (envelope-from jmg) Date: Wed, 18 Jun 2014 15:58:08 -0700 From: John-Mark Gurney To: arm@FreeBSD.org Subject: AVILA getting close! Message-ID: <20140618225808.GG31367@funkthat.com> Mail-Followup-To: arm@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 18 Jun 2014 15:58:08 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 22:58:10 -0000 So, w/ the recent couple of patches that alc has provided, I no longer receive kernel panics on my AVILA board! $ uname -a FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm $ uptime 12:15AM up 1 day, 15 mins, 2 users, load averages: 0.13, 0.11, 0.08 This survived a portsnap extract... This is all over NFS... Though the issue that I'm now having is that some binaries (newsyslog) and sometimes other binaries (awk, grep) core dump... I believe this is an issue w/ rtld, or related... If I compile newsyslog -static, it works fine... Otherwise I get a SIGILL, and that is because it jumps off into the weeds.. Though gdb on arm isn't very useful.. The trouble appears to be when resolving a symbol that hasn't been called yet... The trouble starts when newsyslog starts parsing a line that isn't a comment line and tries to strdup it... stepi'ing has me go into _rtld_bind_start -> _rtld_bind -> rlock_acquire -> thread_mask_set -> def_thread_set_flag (via function pointer) def_rlock_acquire -> atomic_add_acq_int Turning on rtld's debug doesn't tell me anything I didn't know already: "memchr" in "libc.so.7" ==> 0x2017af30 in "libc.so.7" "strdup" in "newsyslog" ==> 0x200cc8b0 in "libc.so.7" Bus error (core dumped) I've posted both a gdb log showing the stepi, and my copy of ld-elf.so.1 to: https://www.funkthat.com/~jmg/20140619/ Let me know if there is any additional information... Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Jun 18 23:09:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32E80CDE for ; Wed, 18 Jun 2014 23:09:45 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D9C02B36 for ; Wed, 18 Jun 2014 23:09:44 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s5IN9ahm015395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 18 Jun 2014 16:09:37 -0700 Message-ID: <53A21C30.7060601@freebsd.org> Date: Wed, 18 Jun 2014 16:09:36 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: AVILA getting close! References: <20140618225808.GG31367@funkthat.com> In-Reply-To: <20140618225808.GG31367@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;TGEmnj334xGlFzifdPQXfw== M;BCJOnj334xGlFzifdPQXfw== X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 23:09:45 -0000 On 06/18/14 15:58, John-Mark Gurney wrote: > So, w/ the recent couple of patches that alc has provided, I no longer > receive kernel panics on my AVILA board! > > $ uname -a > FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > $ uptime > 12:15AM up 1 day, 15 mins, 2 users, load averages: 0.13, 0.11, 0.08 > > This survived a portsnap extract... This is all over NFS... > > Though the issue that I'm now having is that some binaries (newsyslog) > and sometimes other binaries (awk, grep) core dump... > > I believe this is an issue w/ rtld, or related... If I compile newsyslog > -static, it works fine... Otherwise I get a SIGILL, and that is > because it jumps off into the weeds.. Though gdb on arm isn't very > useful.. > > The trouble appears to be when resolving a symbol that hasn't been > called yet... The trouble starts when newsyslog starts parsing a > line that isn't a comment line and tries to strdup it... stepi'ing > has me go into > _rtld_bind_start -> > _rtld_bind -> > rlock_acquire -> > thread_mask_set -> > def_thread_set_flag (via function pointer) > def_rlock_acquire -> > atomic_add_acq_int > > Turning on rtld's debug doesn't tell me anything I didn't know already: > "memchr" in "libc.so.7" ==> 0x2017af30 in "libc.so.7" > "strdup" in "newsyslog" ==> 0x200cc8b0 in "libc.so.7" > Bus error (core dumped) > > I've posted both a gdb log showing the stepi, and my copy of > ld-elf.so.1 to: > https://www.funkthat.com/~jmg/20140619/ > > Let me know if there is any additional information... > What happens if you set LD_BIND_NOW=1 in the environment first? -Nathan From owner-freebsd-arm@FreeBSD.ORG Wed Jun 18 23:14:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECB40EF0; Wed, 18 Jun 2014 23:14:52 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A4A0E2BD0; Wed, 18 Jun 2014 23:14:52 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5INEpW2041303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2014 16:14:51 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5INEpsO041302; Wed, 18 Jun 2014 16:14:51 -0700 (PDT) (envelope-from jmg) Date: Wed, 18 Jun 2014 16:14:51 -0700 From: John-Mark Gurney To: Nathan Whitehorn Subject: Re: AVILA getting close! Message-ID: <20140618231451.GI31367@funkthat.com> Mail-Followup-To: Nathan Whitehorn , freebsd-arm@freebsd.org References: <20140618225808.GG31367@funkthat.com> <53A21C30.7060601@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53A21C30.7060601@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 18 Jun 2014 16:14:51 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 23:14:53 -0000 Nathan Whitehorn wrote this message on Wed, Jun 18, 2014 at 16:09 -0700: > > On 06/18/14 15:58, John-Mark Gurney wrote: > >So, w/ the recent couple of patches that alc has provided, I no longer > >receive kernel panics on my AVILA board! > > > >$ uname -a > >FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 > >r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 > >jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > >$ uptime > >12:15AM up 1 day, 15 mins, 2 users, load averages: 0.13, 0.11, 0.08 > > > >This survived a portsnap extract... This is all over NFS... > > > >Though the issue that I'm now having is that some binaries (newsyslog) > >and sometimes other binaries (awk, grep) core dump... > > > >I believe this is an issue w/ rtld, or related... If I compile newsyslog > >-static, it works fine... Otherwise I get a SIGILL, and that is > >because it jumps off into the weeds.. Though gdb on arm isn't very > >useful.. > > > >The trouble appears to be when resolving a symbol that hasn't been > >called yet... The trouble starts when newsyslog starts parsing a > >line that isn't a comment line and tries to strdup it... stepi'ing > >has me go into > >_rtld_bind_start -> > > _rtld_bind -> > > rlock_acquire -> > > thread_mask_set -> > > def_thread_set_flag (via function pointer) > > def_rlock_acquire -> > > atomic_add_acq_int > > > >Turning on rtld's debug doesn't tell me anything I didn't know already: > >"memchr" in "libc.so.7" ==> 0x2017af30 in "libc.so.7" > >"strdup" in "newsyslog" ==> 0x200cc8b0 in "libc.so.7" > >Bus error (core dumped) > > > >I've posted both a gdb log showing the stepi, and my copy of > >ld-elf.so.1 to: > >https://www.funkthat.com/~jmg/20140619/ > > > >Let me know if there is any additional information... > > > What happens if you set LD_BIND_NOW=1 in the environment first? That causes newsyslog to work. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu Jun 19 06:05:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A2F16B8; Thu, 19 Jun 2014 06:05:44 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id C2BCA2A5D; Thu, 19 Jun 2014 06:05:42 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 6AFD5B828; Thu, 19 Jun 2014 08:05:31 +0200 (SAST) Date: Thu, 19 Jun 2014 08:05:31 +0200 From: John Hay To: Nathan Whitehorn , freebsd-arm@freebsd.org Subject: Re: AVILA getting close! Message-ID: <20140619060531.GA64180@zibbi.meraka.csir.co.za> References: <20140618225808.GG31367@funkthat.com> <53A21C30.7060601@freebsd.org> <20140618231451.GI31367@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140618231451.GI31367@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 06:05:44 -0000 On Wed, Jun 18, 2014 at 04:14:51PM -0700, John-Mark Gurney wrote: > Nathan Whitehorn wrote this message on Wed, Jun 18, 2014 at 16:09 -0700: > > > > On 06/18/14 15:58, John-Mark Gurney wrote: > > >So, w/ the recent couple of patches that alc has provided, I no longer > > >receive kernel panics on my AVILA board! > > > > > >$ uname -a > > >FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 > > >r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 > > >jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > > >$ uptime > > >12:15AM up 1 day, 15 mins, 2 users, load averages: 0.13, 0.11, 0.08 > > > > > >This survived a portsnap extract... This is all over NFS... > > > > > >Though the issue that I'm now having is that some binaries (newsyslog) > > >and sometimes other binaries (awk, grep) core dump... > > > > > >I believe this is an issue w/ rtld, or related... If I compile newsyslog > > >-static, it works fine... Otherwise I get a SIGILL, and that is > > >because it jumps off into the weeds.. Though gdb on arm isn't very > > >useful.. > > > > > >The trouble appears to be when resolving a symbol that hasn't been > > >called yet... The trouble starts when newsyslog starts parsing a > > >line that isn't a comment line and tries to strdup it... stepi'ing > > >has me go into > > >_rtld_bind_start -> > > > _rtld_bind -> > > > rlock_acquire -> > > > thread_mask_set -> > > > def_thread_set_flag (via function pointer) > > > def_rlock_acquire -> > > > atomic_add_acq_int > > > > > >Turning on rtld's debug doesn't tell me anything I didn't know already: > > >"memchr" in "libc.so.7" ==> 0x2017af30 in "libc.so.7" > > >"strdup" in "newsyslog" ==> 0x200cc8b0 in "libc.so.7" > > >Bus error (core dumped) > > > > > >I've posted both a gdb log showing the stepi, and my copy of > > >ld-elf.so.1 to: > > >https://www.funkthat.com/~jmg/20140619/ > > > > > >Let me know if there is any additional information... > > > > > What happens if you set LD_BIND_NOW=1 in the environment first? > > That causes newsyslog to work. Yes, that fix it for me too. On my box newsyslog seemed to crash early when it called getuid(). But I'm not nfs booting, but from a CF card. I still need "vfs.unmapped_buf_allowed=0" set in the env to have md ramdisks work for /var and /etc though. With this the box boot to multi-user. Now to see if all of this fixed the CAMBRIA boards too and starting to test the Atheros cards. Thanks to all for helping this along. Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Thu Jun 19 10:22:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7EF6329; Thu, 19 Jun 2014 10:22:22 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9519A2FD4; Thu, 19 Jun 2014 10:22:22 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5JAMLt5050243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2014 03:22:21 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5JAMLR2050242; Thu, 19 Jun 2014 03:22:21 -0700 (PDT) (envelope-from jmg) Date: Thu, 19 Jun 2014 03:22:21 -0700 From: John-Mark Gurney To: Nathan Whitehorn Subject: Re: AVILA getting close! Message-ID: <20140619102221.GL31367@funkthat.com> Mail-Followup-To: Nathan Whitehorn , freebsd-arm@freebsd.org References: <20140618225808.GG31367@funkthat.com> <53A21C30.7060601@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53A21C30.7060601@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 19 Jun 2014 03:22:21 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 10:22:22 -0000 Nathan Whitehorn wrote this message on Wed, Jun 18, 2014 at 16:09 -0700: > > On 06/18/14 15:58, John-Mark Gurney wrote: > >So, w/ the recent couple of patches that alc has provided, I no longer > >receive kernel panics on my AVILA board! > > > >$ uname -a > >FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 > >r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 > >jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > >$ uptime > >12:15AM up 1 day, 15 mins, 2 users, load averages: 0.13, 0.11, 0.08 > > > >This survived a portsnap extract... This is all over NFS... > > > >Though the issue that I'm now having is that some binaries (newsyslog) > >and sometimes other binaries (awk, grep) core dump... > > > >I believe this is an issue w/ rtld, or related... If I compile newsyslog > >-static, it works fine... Otherwise I get a SIGILL, and that is > >because it jumps off into the weeds.. Though gdb on arm isn't very > >useful.. > > > >The trouble appears to be when resolving a symbol that hasn't been > >called yet... The trouble starts when newsyslog starts parsing a > >line that isn't a comment line and tries to strdup it... stepi'ing > >has me go into > >_rtld_bind_start -> > > _rtld_bind -> > > rlock_acquire -> > > thread_mask_set -> > > def_thread_set_flag (via function pointer) > > def_rlock_acquire -> > > atomic_add_acq_int > > > >Turning on rtld's debug doesn't tell me anything I didn't know already: > >"memchr" in "libc.so.7" ==> 0x2017af30 in "libc.so.7" > >"strdup" in "newsyslog" ==> 0x200cc8b0 in "libc.so.7" > >Bus error (core dumped) > > > >I've posted both a gdb log showing the stepi, and my copy of > >ld-elf.so.1 to: > >https://www.funkthat.com/~jmg/20140619/ > > > >Let me know if there is any additional information... > > > What happens if you set LD_BIND_NOW=1 in the environment first? I identified where the SIGILL is coming from, it's coming from arm/undefined.c:272: http://fxr.watson.org/fxr/source/arm/arm/undefined.c#L272 Also, I forgot that I get a different fault when not running under gdb than I do under gdb... under gdb, I get the SIGILL... when not running under gdb, as far as I can tell, I jump through a bogus function pointer, and end up executing random code that gives me a SIGBUS instead... So, this whole SIGILL may be a problem w/ gdb, and not the final problem... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu Jun 19 15:59:06 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AE6F363; Thu, 19 Jun 2014 15:59:06 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 144FC2E9F; Thu, 19 Jun 2014 15:59:02 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wxejm-000NP0-QI; Thu, 19 Jun 2014 15:58:54 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5JFwqjx001259; Thu, 19 Jun 2014 09:58:52 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+DgdKx4U94WaNu8MaykbGV Subject: Re: Strange slowdown of zlib. From: Ian Lepore To: Magnus Nilsson In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 2014 09:58:51 -0600 Message-ID: <1403193531.20883.269.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-embedded@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 15:59:06 -0000 On Thu, 2014-06-19 at 17:44 +0200, Magnus Nilsson wrote: > I have the strangest behaviour of zlib on FreeBSD 8.2 (ARM, but I don't > think it's necessarily an ARM specific issue). > Doing > # md5 /lib/libz.so.5 > or > # cp /lib/libz.so.5 /tmp/ > # export LD_LIBRARY_PATH=/tmp/ > slows down applications (I've tested bsdtar and gzip) using zlib to a crawl > on my system. > > In the later case, doing > # unset LD_LIBRARY_PATH > reverts the issue. > However, I haven't found any way to recover from the first case, apart from > rebooting - then the execution time is back to normal. > > Here is a log of what I describe above (first moving zlib, then doing the > md5): > # cp some2MBfile /tmp/ > # time gzip /tmp/some2MBfile > real 0m0.325s > user 0m0.284s > sys 0m0.037s > # rm /tmp/some2MBfile.gz > # cp /lib/libz.so.5 /tmp/ > # export LD_LIBRARY_PATH=/tmp/ > # cp some2MBfile /tmp/ > # time gzip /tmp/some2MBfile > real 0m11.949s > user 0m11.635s > sys 0m0.035s > # rm /tmp/some2MBfile.gz > # unset LD_LIBRARY_PATH > # cp some2MBfile /tmp/ > # time gzip /tmp/some2MBfile > real 0m0.325s > user 0m0.288s > sys 0m0.035s > # rm /tmp/some2MBfile.gz > # md5 /lib/libz.so.5 > # cp some2MBfile /tmp/ > # time gzip /tmp/some2MBfile > real 0m11.919s > user 0m11.608s > sys 0m0.031s > # rm /tmp/some2MBfile.gz > > Do you have any idea what could be going on? > Any clues are welcome. > > Kind regards/Magnus This is a known problem on armv4/v5 in freebsd 8. Here is some archived info on it including patches that work around the problem (rather crudely, but good enough for our needs at $work). http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Jun 19 18:45:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CCB74DF; Thu, 19 Jun 2014 18:45:18 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 009D52E48; Thu, 19 Jun 2014 18:45:18 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 94D49B833; Thu, 19 Jun 2014 20:45:15 +0200 (SAST) Date: Thu, 19 Jun 2014 20:45:15 +0200 From: John Hay To: Nathan Whitehorn , freebsd-arm@freebsd.org Subject: Re: AVILA getting close! Message-ID: <20140619184515.GA35207@zibbi.meraka.csir.co.za> References: <20140618225808.GG31367@funkthat.com> <53A21C30.7060601@freebsd.org> <20140618231451.GI31367@funkthat.com> <20140619060531.GA64180@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140619060531.GA64180@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 18:45:18 -0000 On Thu, Jun 19, 2014 at 08:05:31AM +0200, John Hay wrote: > On Wed, Jun 18, 2014 at 04:14:51PM -0700, John-Mark Gurney wrote: > > Nathan Whitehorn wrote this message on Wed, Jun 18, 2014 at 16:09 -0700: > > > > > > On 06/18/14 15:58, John-Mark Gurney wrote: > > > >So, w/ the recent couple of patches that alc has provided, I no longer > > > >receive kernel panics on my AVILA board! > > > > > > > >$ uname -a > > > >FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 > > > >r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 > > > >jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > > > >$ uptime > > > >12:15AM up 1 day, 15 mins, 2 users, load averages: 0.13, 0.11, 0.08 > > > > > > > >This survived a portsnap extract... This is all over NFS... > > > > > > > What happens if you set LD_BIND_NOW=1 in the environment first? I'm now trying to build pkg from ports on a nfs booted CAMBRIA. I can build the whole pkg, but then when trying to install, I get pkg-static: failed to find the version elf note ############# root@:/usr/ports/ports-mgmt/pkg # make install ===> Installing for pkg-1.2.7_3 ===> Checking if ports-mgmt/pkg already installed pkg-static: failed to find the version elf note ===> Registering installation for pkg-1.2.7_3 pkg-static: failed to find the version elf note pkg-static: failed to find the version elf note Installing pkg-1.2.7_3...pkg-static: package field incomplete: architecture pkg-static: the package is not valid pkg-static: sqlite: cannot rollback - no transaction is active If you are upgrading from the old package format, first run: # pkg2ng *** Error code 70 Stop. make[1]: stopped in /export/ports/ports-mgmt/pkg *** Error code 1 Stop. make: stopped in /export/ports/ports-mgmt/pkg ############## Is there some bootstrapping that I need to do? My previous arm stuff used the old pkg system. Searching on Google I found these patches, but I'm unsure if they are meant to fix that. http://people.freebsd.org/~nwhitehorn/pkg_bootstrap_machinearch.diff http://people.freebsd.org/~nwhitehorn/pkg_machinearch.diff Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Thu Jun 19 22:18:21 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94ECCE8 for ; Thu, 19 Jun 2014 22:18:21 +0000 (UTC) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F41620D8 for ; Thu, 19 Jun 2014 22:18:20 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward5l.mail.yandex.net (Yandex) with ESMTP id C3C73C40F86 for ; Fri, 20 Jun 2014 02:18:09 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 7F0FB1704D2B for ; Fri, 20 Jun 2014 02:18:09 +0400 (MSK) Received: from unknown (unknown [12.202.173.169]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Mdn8Zx6na1-I7YmOiMQ; Fri, 20 Jun 2014 02:18:08 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: a24d5270-cacc-4de1-9ea6-37c605a388e7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1403216289; bh=NrWMbXq2iSgr+ExXeXjTtdhXFC19sXBpT61QauzQfPU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=vvDG+9E6yNYfQmm+d5NR+2VMowNO/imWmiO0jQ4SBYic38GHhUq2GXJHV3zE/pHjO CE9F6tz2ZbOy/5IsmvHtpBIHTMEsNfKg/sr64Cmtpb4ngm6StxyvGJxNIVxdvr6a4H REpW9cfOa4EFN/Yhjccp5jrLpcMB0+cBvBOjXsao= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <53A3619C.3020505@narod.ru> Date: Fri, 20 Jun 2014 04:18:04 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: locore.S and debugging initial stages of kernel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 22:18:21 -0000 Hi all, I would like to check several things in locore.S. But I don't have JTAG debugger, so I have to use printf-like functions. Are there any known ways to do it? Thanks! -Stepan From owner-freebsd-arm@FreeBSD.ORG Thu Jun 19 23:13:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CEBB784; Thu, 19 Jun 2014 23:13:43 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 63EC2253F; Thu, 19 Jun 2014 23:13:43 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5JNDZcW060046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2014 16:13:36 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5JNDZlD060044; Thu, 19 Jun 2014 16:13:35 -0700 (PDT) (envelope-from jmg) Date: Thu, 19 Jun 2014 16:13:35 -0700 From: John-Mark Gurney To: John Hay Subject: Re: AVILA getting close! Message-ID: <20140619231335.GN31367@funkthat.com> Mail-Followup-To: John Hay , Nathan Whitehorn , freebsd-arm@freebsd.org References: <20140618225808.GG31367@funkthat.com> <53A21C30.7060601@freebsd.org> <20140618231451.GI31367@funkthat.com> <20140619060531.GA64180@zibbi.meraka.csir.co.za> <20140619184515.GA35207@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140619184515.GA35207@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 19 Jun 2014 16:13:36 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 23:13:43 -0000 John Hay wrote this message on Thu, Jun 19, 2014 at 20:45 +0200: > On Thu, Jun 19, 2014 at 08:05:31AM +0200, John Hay wrote: > > On Wed, Jun 18, 2014 at 04:14:51PM -0700, John-Mark Gurney wrote: > > > Nathan Whitehorn wrote this message on Wed, Jun 18, 2014 at 16:09 -0700: > > > > > > > > On 06/18/14 15:58, John-Mark Gurney wrote: > > > > >So, w/ the recent couple of patches that alc has provided, I no longer > > > > >receive kernel panics on my AVILA board! > > > > > > > > > >$ uname -a > > > > >FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 > > > > >r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 > > > > >jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > > > > >$ uptime > > > > >12:15AM up 1 day, 15 mins, 2 users, load averages: 0.13, 0.11, 0.08 > > > > > > > > > >This survived a portsnap extract... This is all over NFS... > > > > > > > > > What happens if you set LD_BIND_NOW=1 in the environment first? > > I'm now trying to build pkg from ports on a nfs booted CAMBRIA. I can > build the whole pkg, but then when trying to install, I get > pkg-static: failed to find the version elf note > > ############# > root@:/usr/ports/ports-mgmt/pkg # make install > ===> Installing for pkg-1.2.7_3 > ===> Checking if ports-mgmt/pkg already installed > pkg-static: failed to find the version elf note > ===> Registering installation for pkg-1.2.7_3 > pkg-static: failed to find the version elf note > pkg-static: failed to find the version elf note > Installing pkg-1.2.7_3...pkg-static: package field incomplete: architecture > pkg-static: the package is not valid > pkg-static: sqlite: cannot rollback - no transaction is active > If you are upgrading from the old package format, first run: > > # pkg2ng > > *** Error code 70 > > Stop. > make[1]: stopped in /export/ports/ports-mgmt/pkg > *** Error code 1 > > Stop. > make: stopped in /export/ports/ports-mgmt/pkg > ############## Yeh, I'm seeing this too... > Is there some bootstrapping that I need to do? My previous arm stuff > used the old pkg system. > > Searching on Google I found these patches, but I'm unsure if they are > meant to fix that. > > http://people.freebsd.org/~nwhitehorn/pkg_bootstrap_machinearch.diff > http://people.freebsd.org/~nwhitehorn/pkg_machinearch.diff We should probably bring this up w/ the pkg folk to get their help w/ this.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu Jun 19 23:39:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0828BB0A for ; Thu, 19 Jun 2014 23:39:18 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3CBD26DE for ; Thu, 19 Jun 2014 23:39:17 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s5JNd7q2016725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Jun 2014 16:39:10 -0700 Message-ID: <53A3749B.5080206@freebsd.org> Date: Thu, 19 Jun 2014 16:39:07 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Hay , freebsd-arm@freebsd.org Subject: Re: AVILA getting close! References: <20140618225808.GG31367@funkthat.com> <53A21C30.7060601@freebsd.org> <20140618231451.GI31367@funkthat.com> <20140619060531.GA64180@zibbi.meraka.csir.co.za> <20140619184515.GA35207@zibbi.meraka.csir.co.za> In-Reply-To: <20140619184515.GA35207@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;kBe15wr44xGjyTifdPQXfw== M;kPCK6Ar44xGjyTifdPQXfw== X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 23:39:18 -0000 On 06/19/14 11:45, John Hay wrote: > On Thu, Jun 19, 2014 at 08:05:31AM +0200, John Hay wrote: >> On Wed, Jun 18, 2014 at 04:14:51PM -0700, John-Mark Gurney wrote: >>> Nathan Whitehorn wrote this message on Wed, Jun 18, 2014 at 16:09 -0700: >>>> On 06/18/14 15:58, John-Mark Gurney wrote: >>>>> So, w/ the recent couple of patches that alc has provided, I no longer >>>>> receive kernel panics on my AVILA board! >>>>> >>>>> $ uname -a >>>>> FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 >>>>> r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 >>>>> jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm >>>>> $ uptime >>>>> 12:15AM up 1 day, 15 mins, 2 users, load averages: 0.13, 0.11, 0.08 >>>>> >>>>> This survived a portsnap extract... This is all over NFS... >>>>> >>>> What happens if you set LD_BIND_NOW=1 in the environment first? > I'm now trying to build pkg from ports on a nfs booted CAMBRIA. I can > build the whole pkg, but then when trying to install, I get > pkg-static: failed to find the version elf note > > ############# > root@:/usr/ports/ports-mgmt/pkg # make install > ===> Installing for pkg-1.2.7_3 > ===> Checking if ports-mgmt/pkg already installed > pkg-static: failed to find the version elf note > ===> Registering installation for pkg-1.2.7_3 > pkg-static: failed to find the version elf note > pkg-static: failed to find the version elf note > Installing pkg-1.2.7_3...pkg-static: package field incomplete: architecture > pkg-static: the package is not valid > pkg-static: sqlite: cannot rollback - no transaction is active > If you are upgrading from the old package format, first run: > > # pkg2ng > > *** Error code 70 > > Stop. > make[1]: stopped in /export/ports/ports-mgmt/pkg > *** Error code 1 > > Stop. > make: stopped in /export/ports/ports-mgmt/pkg > ############## > > Is there some bootstrapping that I need to do? My previous arm stuff > used the old pkg system. > > Searching on Google I found these patches, but I'm unsure if they are > meant to fix that. > > http://people.freebsd.org/~nwhitehorn/pkg_bootstrap_machinearch.diff > http://people.freebsd.org/~nwhitehorn/pkg_machinearch.diff > > Regards > > John Those patches are for a different issue, although the first one will incidentally fix the pkg bootstrapper. The problem here is that pkg tries to get the machine architecture by parsing the ELF headers of /bin/sh and then trying to extract enough information from there to come up with a string to describe the architecture. This is, as you've noticed here, potentially error prone. The alternative would be looking at the return value of uname -p (=sysctl hw.machine_arch), but this prevents use of pkg to cross-install packages onto an image for an architecture whose binaries the host system can't execute, leading to the ELF-parsing design. I'm not sure whether this feature is worth the fragility, especially given that a lot of packages try to run binaries in their install scripts, but that's the rationale for it anyway. You could also imagine some hybrid design where it tries to use hw.machine_arch first and then falls back on ELF parsing only if installing into a different root and uname can't be executed or something, which preserves both behaviors. Worth bringing up with the pkg people in any case. -Nathan From owner-freebsd-arm@FreeBSD.ORG Fri Jun 20 00:43:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D817D195; Fri, 20 Jun 2014 00:43:22 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B49432BFF; Fri, 20 Jun 2014 00:43:22 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5K0hLqv061161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2014 17:43:21 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5K0hLZC061160; Thu, 19 Jun 2014 17:43:21 -0700 (PDT) (envelope-from jmg) Date: Thu, 19 Jun 2014 17:43:21 -0700 From: John-Mark Gurney To: Nathan Whitehorn Subject: Re: AVILA getting close! Message-ID: <20140620004320.GO31367@funkthat.com> Mail-Followup-To: Nathan Whitehorn , John Hay , freebsd-arm@freebsd.org References: <20140618225808.GG31367@funkthat.com> <53A21C30.7060601@freebsd.org> <20140618231451.GI31367@funkthat.com> <20140619060531.GA64180@zibbi.meraka.csir.co.za> <20140619184515.GA35207@zibbi.meraka.csir.co.za> <53A3749B.5080206@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53A3749B.5080206@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 19 Jun 2014 17:43:21 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 00:43:22 -0000 Nathan Whitehorn wrote this message on Thu, Jun 19, 2014 at 16:39 -0700: > > On 06/19/14 11:45, John Hay wrote: > >On Thu, Jun 19, 2014 at 08:05:31AM +0200, John Hay wrote: > >>On Wed, Jun 18, 2014 at 04:14:51PM -0700, John-Mark Gurney wrote: > >>>Nathan Whitehorn wrote this message on Wed, Jun 18, 2014 at 16:09 -0700: > >>>>On 06/18/14 15:58, John-Mark Gurney wrote: > >>>>>So, w/ the recent couple of patches that alc has provided, I no longer > >>>>>receive kernel panics on my AVILA board! > >>>>> > >>>>>$ uname -a > >>>>>FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 > >>>>>r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 > >>>>>jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > >>>>>$ uptime > >>>>>12:15AM up 1 day, 15 mins, 2 users, load averages: 0.13, 0.11, 0.08 > >>>>> > >>>>>This survived a portsnap extract... This is all over NFS... > >>>>> > >>>>What happens if you set LD_BIND_NOW=1 in the environment first? > >I'm now trying to build pkg from ports on a nfs booted CAMBRIA. I can > >build the whole pkg, but then when trying to install, I get > >pkg-static: failed to find the version elf note > > > >############# > >root@:/usr/ports/ports-mgmt/pkg # make install > >===> Installing for pkg-1.2.7_3 > >===> Checking if ports-mgmt/pkg already installed > >pkg-static: failed to find the version elf note > >===> Registering installation for pkg-1.2.7_3 > >pkg-static: failed to find the version elf note > >pkg-static: failed to find the version elf note > >Installing pkg-1.2.7_3...pkg-static: package field incomplete: architecture > >pkg-static: the package is not valid > >pkg-static: sqlite: cannot rollback - no transaction is active > >If you are upgrading from the old package format, first run: > > > > # pkg2ng > > > >*** Error code 70 > > > >Stop. > >make[1]: stopped in /export/ports/ports-mgmt/pkg > >*** Error code 1 > > > >Stop. > >make: stopped in /export/ports/ports-mgmt/pkg > >############## > > > >Is there some bootstrapping that I need to do? My previous arm stuff > >used the old pkg system. > > > >Searching on Google I found these patches, but I'm unsure if they are > >meant to fix that. > > > >http://people.freebsd.org/~nwhitehorn/pkg_bootstrap_machinearch.diff > >http://people.freebsd.org/~nwhitehorn/pkg_machinearch.diff > > > >Regards > > > >John > > Those patches are for a different issue, although the first one will > incidentally fix the pkg bootstrapper. > > The problem here is that pkg tries to get the machine architecture by > parsing the ELF headers of /bin/sh and then trying to extract enough > information from there to come up with a string to describe the > architecture. This is, as you've noticed here, potentially error prone. > The alternative would be looking at the return value of uname -p > (=sysctl hw.machine_arch), but this prevents use of pkg to cross-install > packages onto an image for an architecture whose binaries the host > system can't execute, leading to the ELF-parsing design. I'm not sure > whether this feature is worth the fragility, especially given that a lot > of packages try to run binaries in their install scripts, but that's the > rationale for it anyway. > > You could also imagine some hybrid design where it tries to use > hw.machine_arch first and then falls back on ELF parsing only if > installing into a different root and uname can't be executed or > something, which preserves both behaviors. Worth bringing up with the > pkg people in any case. Ok, so this is a bug in pkg then.. I asked about this earlier, and we don't have .note.tag entries in our executables since our arch is fully identified by other info in the ELF header... I'll track down the pkg maintainers and tell them to fix their code.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Fri Jun 20 01:59:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C5FCE46 for ; Fri, 20 Jun 2014 01:59:08 +0000 (UTC) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 133312229 for ; Fri, 20 Jun 2014 01:59:07 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id lx4so2738936iec.33 for ; Thu, 19 Jun 2014 18:59:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=iFo03iZgpj3FwEQ5fe/9xUfnJSHC9wiQLmRvenOcMfc=; b=Yvk8cukPpG57VEaouUcoc4Xpli0FeC/MXozgG3/kkhVbN++mut4X49BfMMUFR0qdim ZPI4K/1ATpAsswH32ef88a2gDUDfwY3ejMoQ297Zyf5Bi3XHJq2R0GzBlaykFc5hJT+5 GR5w7DdXTEZSD8nUUx6s+z8YUKVj4vhQWG4blv2P1JoI6YUiELd3cNdjbpmoNq+rz8V0 DsmsGbhxwXQxsj/WngqLt6L6qB5J2qefa/K0Zq6TkBQOrdx3kq5ty2qOLKoWmAb+cgjo 5Luqc8wHrn42Gayi4aBzFEsQGNpgEevmBmsbvwAa/o9kFSu8vJEnFhPQIIT9goTswkvF q5IQ== X-Gm-Message-State: ALoCoQmsairiLhVtYFmQhQzV/e9tfinn69++tQu1f0S3Ut7XGV//qic+Nj2IMxtbHCr8BR3Oi42v X-Received: by 10.50.97.68 with SMTP id dy4mr401024igb.8.1403229541251; Thu, 19 Jun 2014 18:59:01 -0700 (PDT) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id u10sm189917igz.21.2014.06.19.18.59.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Jun 2014 18:59:00 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_7C68AD24-D52C-40BC-8577-23F1A8285CAF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: locore.S and debugging initial stages of kernel From: Warner Losh In-Reply-To: <53A3619C.3020505@narod.ru> Date: Thu, 19 Jun 2014 19:59:01 -0600 Message-Id: <776BC360-5D2F-435C-B2B0-38449D4AB56D@bsdimp.com> References: <53A3619C.3020505@narod.ru> To: Stepan Dyatkovskiy X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 01:59:08 -0000 --Apple-Mail=_7C68AD24-D52C-40BC-8577-23F1A8285CAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Look at EARLY_PRINTF code, unless Ian has removed it because it isn=92t = needed once you have a static mapping for the UART in place=85 But if the code is really early, consider encoding numbers in the the = LEDs on your board. Warner On Jun 19, 2014, at 4:18 PM, Stepan Dyatkovskiy = wrote: > Hi all, > I would like to check several things in locore.S. But I don't have = JTAG debugger, so I have to use printf-like functions. Are there any = known ways to do it? >=20 > Thanks! > -Stepan > _______________________________________________ > 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" --Apple-Mail=_7C68AD24-D52C-40BC-8577-23F1A8285CAF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTo5VlAAoJEGwc0Sh9sBEA6scQAOpF8I7WxaOv4QnaEkdCLOZ6 hB8NTtztonnlywrtYEe+9aI7U/0wW8pkmn3L6YbFVr0vSRpcE35HfO36DL3Ocnh2 q6ym3OWjnk6YuxcGgIfrKMRaB8VI0vXctbydGhmcxrTtH0mOz8VDFtjssBTZTFIf +5htmc8IllpOxdMBghkbt47aahcK6wY0DVFDV6sxsI2l5NoR2IrxYTqazfnSS2OV vv0xcy6QuK3p3kSFsrr9pw9ZkVwl/NMsV2qVd/wrZtLIC6UAEebvzmWaS9LtRJS3 cmuoXYfDXsbBkukqzyHv2hdT8OKTAvKaAlQuunXrGq0KhQVWnYiLCDEF3lDZIuS7 6yq9B30B8jpmuwYnRmq1/Lcr7BN+w/X6qr/o3zaDRei3ozlEdktX3HhXimRmgEVO 3LOVH43fkca+Elux/M8sMSlsSq+HzEFhsEUvTTHzIMsuDv74W8L85z/lc5+u/Ns8 37d7uRx1v55C9aUlOh7uKTzjh3QI0wa3OK6Dc1z/X830GPTKMzSNbaYqTLd+AIT4 Sxs+Jaa/JSG2VpMRmeV6UBK5vEs9lksbCLAMcddQ8K/SCT/uZi+aQiQIY2nPHKou uFSyTIQh4X+kZosrEDvqP98GrqchhiIVQXZLBG94LL2uVfmTLRfjLntb+G6UKzBa hihEphAPPKkYM6mVmE2t =lGge -----END PGP SIGNATURE----- --Apple-Mail=_7C68AD24-D52C-40BC-8577-23F1A8285CAF-- From owner-freebsd-arm@FreeBSD.ORG Fri Jun 20 02:04:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55966FC5 for ; Fri, 20 Jun 2014 02:04:21 +0000 (UTC) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2948722DF for ; Fri, 20 Jun 2014 02:04:21 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id fp1so2412498pdb.2 for ; Thu, 19 Jun 2014 19:04:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=0iFX0HV4JxIKOCVLHsw10MKTO+xLEcXtpTAsxCfhYxQ=; b=QD7RFKaUtlDPbKk1WuVD7OZf8nxnsSksguqGzCAHXSdWDJxX8zbJwJPDgc/W9FhkTX JqJweA94YlGe4Bl5xtdhn/oulnkFTd5+vFiWFCr/ptWDageOXpNNGfuYqugRegefwqTY j3yllz6trNN+gIpO/vhCzDfoHfOfihDRfGaPZbxkMh/3HHhCzj8dCvF50ZmFxBgL/l6V r6CuFFhi6q2/sFZb35dDWXIpvaVL8b26xjYloSweePwsNydPxbp7SpCidU5UCfc6zlGF gLOPoSbkxIwa/Sf8ox6guqoZvVV8WnV5YS6wLuU1xqPt2AfQmZoi5UM9g6Fgz65FslJV hGRg== X-Gm-Message-State: ALoCoQnWYCscAkI95gBmCmPBSEjGFv2ez8/vu09PC+P/couW18ebUQ9BJ3anTF+PVo2Hr3VvobSw X-Received: by 10.66.161.69 with SMTP id xq5mr452463pab.62.1403229426409; Thu, 19 Jun 2014 18:57:06 -0700 (PDT) Received: from [192.168.1.2] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id gu1sm10703429pbd.0.2014.06.19.18.57.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Jun 2014 18:57:05 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: locore.S and debugging initial stages of kernel From: Tim Kientzle In-Reply-To: <53A3619C.3020505@narod.ru> Date: Thu, 19 Jun 2014 18:56:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1F054368-CAD3-4811-B03C-78C0B45D3C64@kientzle.com> References: <53A3619C.3020505@narod.ru> To: Stepan Dyatkovskiy X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 02:04:21 -0000 On Jun 19, 2014, at 3:18 PM, Stepan Dyatkovskiy = wrote: > Hi all, > I would like to check several things in locore.S. But I don't have = JTAG debugger, so I have to use printf-like functions. Are there any = known ways to do it? Depending on the particular board you=92re using, and what part of the boot process you=92re testing: * A few lines of assembly can blink an LED * A few more lines of assembly can bring up a UART * Allocate a static buffer and write events into it, then dump the = buffer after the kernel sets up the console Tim From owner-freebsd-arm@FreeBSD.ORG Fri Jun 20 02:19:37 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF772822 for ; Fri, 20 Jun 2014 02:19:37 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 919FE24F0 for ; Fri, 20 Jun 2014 02:19:37 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WxoQR-0006XY-Bp; Fri, 20 Jun 2014 02:19:35 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5K2JWet001761; Thu, 19 Jun 2014 20:19:32 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX182o4kPo+ry5Md8VZCzBy59 Subject: Re: locore.S and debugging initial stages of kernel From: Ian Lepore To: Warner Losh In-Reply-To: <776BC360-5D2F-435C-B2B0-38449D4AB56D@bsdimp.com> References: <53A3619C.3020505@narod.ru> <776BC360-5D2F-435C-B2B0-38449D4AB56D@bsdimp.com> Content-Type: text/plain; charset="windows-1251" Date: Thu, 19 Jun 2014 20:19:32 -0600 Message-ID: <1403230772.20883.281.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s5K2JWet001761 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 02:19:37 -0000 On Thu, 2014-06-19 at 19:59 -0600, Warner Losh wrote: > Look at EARLY_PRINTF code, unless Ian has removed it because it isn=92t= needed once you have a static mapping for the UART in place=85 >=20 > But if the code is really early, consider encoding numbers in the the L= EDs on your board. >=20 > Warner >=20 > On Jun 19, 2014, at 4:18 PM, Stepan Dyatkovskiy wro= te: >=20 > > Hi all, > > I would like to check several things in locore.S. But I don't have JT= AG debugger, so I have to use printf-like functions. Are there any known = ways to do it? > >=20 > > Thanks! > > -Stepan You can't really use the EARLY_PRINTF stuff in locore.S, at least, not until you get to the last few lines before calling initarm(). I usually emit single chars by writing directly the console uart register. This technique works up until the code that turns on the MMU. If you want to keep emitting chars after that point, you have to map the uart reg (va=3Dpa), and the EARLY_PRINTF mechanism will do that for you. = =20 In general the technique is purely machine-specific, so there's never been anything checked in for it. For example, here's how I do it for imx6, whose tx register is at 0x02020040: =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 --- locore.S (revision 266921) +++ locore.S (working copy) @@ -75,6 +75,9 @@ * For both types of boot we gather up the args, put them in a struct arm_boot_params * structure and pass that to initarm. */ + +#define EMIT(rg, chr) mov rg,chr ; str rg,[r10] + ENTRY_NP(btext) ASENTRY_NP(_start) STOP_UNWINDING /* Can't unwind into the bootloader! */ @@ -84,6 +87,11 @@ mov ip, r2 /* Save meta data */ mov fp, r3 /* Future expansion */ =20 + mov r10, #0x02000000 /* make r10 point */ + orr r10, #0x00020000 /* to imx6 uart */ + orr r10, #0x00000040 /* xmit register */ + EMIT(r1, #'a') + /* Make sure interrupts are disabled. */ mrs r7, cpsr orr r7, r7, #(I32_bit|F32_bit) @@ -144,6 +152,7 @@ nop mov pc, r7 Lunmapped: + EMIT(r1, #'b') /* * Build page table from scratch. */ -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jun 20 04:47:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A94222D for ; Fri, 20 Jun 2014 04:47:09 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A1C8221F for ; Fri, 20 Jun 2014 04:47:09 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id eb12so6805202oac.27 for ; Thu, 19 Jun 2014 21:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=FlmfVjLTNmYxIwsX/unm8L5ywS0sS+378DkhUCsLV4k=; b=yijiK8PwUklzx+1R2GwmP8nemB73FvFtMojmZSQ8kQthFaQ81SZLIGQhoe5YDpF2oh CcxDtNPaDbX4fzOQ8KRKMQ1uBEv+u5fqdaKw4J/wgrmQkal4/nBQn+LKmo6z4DZF0kQO kHfLrE6TGgTdqu5qD6AZeQsCgiNNfF6WjGs48pdB+U5MxymSpsmF9Hkmfg/gwvTONsEb cCHGmL32wwP92pquVJwHmGYpr+soROuP2x8HyDyMuUDM/GmYGIRphqMLOINlPuyOxGjH l1kie9H1IbwBzeawsFDd+2N8FAWWTS36EN7OWlI6k6Z8JsgUj4kYU7uv+yQvf4j6wkUr xczg== X-Received: by 10.182.126.47 with SMTP id mv15mr898996obb.26.1403239628344; Thu, 19 Jun 2014 21:47:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.123.176 with HTTP; Thu, 19 Jun 2014 21:46:38 -0700 (PDT) From: Jia-Shiun Li Date: Fri, 20 Jun 2014 12:46:38 +0800 Message-ID: Subject: BB panic a lot more To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 04:47:09 -0000 Hi, recently Beaglebone black seems to be more likely to panic than rpi. Wondering if anyone sees the same. bbb was powered by a 2A USB power adapter, but it happens too with PMIC tweaked, attached 1"x1" heat sink, and MPU clocked at 320MHz. Both are running r267607, built with crochet-build login: panic: Bad link elm 0xc0b7cf70 next->prev != elm KDB: enter: panic [ thread pid 49036 tid 100097 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 49036 tid 100097 td 0xc2f57960 db_trace_self() at db_trace_self pc = 0xc0544458 lr = 0xc0230648 (db_stack_trace+0xf4) sp = 0xde6ec670 fp = 0xde6ec688 r10 = 0xc092cb1c db_stack_trace() at db_stack_trace+0xf4 pc = 0xc0230648 lr = 0xc022ffb8 (db_command+0x270) sp = 0xde6ec690 fp = 0xde6ec730 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 db_command() at db_command+0x270 pc = 0xc022ffb8 lr = 0xc022fd1c (db_command_loop+0x60) sp = 0xde6ec738 fp = 0xde6ec748 r4 = 0xc058bcbf r5 = 0xc05a6989 r6 = 0xc092cb08 r7 = 0xc0645760 r8 = 0xc0688a94 r9 = 0xc0688a90 r10 = 0xde6ec918 db_command_loop() at db_command_loop+0x60 pc = 0xc022fd1c lr = 0xc02326e4 (db_trap+0xd8) sp = 0xde6ec750 fp = 0xde6ec870 r4 = 0x00000000 r5 = 0xc092cb14 r6 = 0xc0688ac0 db_trap() at db_trap+0xd8 pc = 0xc02326e4 lr = 0xc039c1b0 (kdb_trap+0xbc) sp = 0xde6ec878 fp = 0xde6ec898 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc0688ac0 r7 = 0xc0645760 kdb_trap() at kdb_trap+0xbc pc = 0xc039c1b0 lr = 0xc055a800 (undefinedinstruction+0x298) sp = 0xde6ec8a0 fp = 0xde6ec910 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc055a4b8 r7 = 0xe7ffffff r8 = 0xc2f57960 r9 = 0xc039ba80 r10 = 0xde6ec918 undefinedinstruction() at undefinedinstruction+0x298 pc = 0xc055a800 lr = 0xc0545fd4 (exception_exit) sp = 0xde6ec918 fp = 0xde6ec970 r4 = 0xc05a69e3 r5 = 0xde6ec9ac r6 = 0xc057fd1e r7 = 0xc067afd0 r8 = 0xc2f57960 r9 = 0xc092e55c r10 = 0xc067ae30 exception_exit() at exception_exit pc = 0xc0545fd4 lr = 0xc039ba74 (kdb_enter+0x40) sp = 0xde6ec968 fp = 0xde6ec970 r0 = 0xc0688aa4 r1 = 0x00000000 r2 = 0xc05aa380 r3 = 0x000000ab r4 = 0xc05a69e3 r5 = 0xde6ec9ac r6 = 0xc057fd1e r7 = 0xc067afd0 r8 = 0xc2f57960 r9 = 0xc092e55c r10 = 0xc067ae30 r12 = 0x00000000 $a() at $a pc = 0xc039ba84 lr = 0xc03650bc (vpanic+0xb4) sp = 0xde6ec978 fp = 0xde6ec998 r4 = 0x00000100 vpanic() at vpanic+0xb4 pc = 0xc03650bc lr = 0xc0365120 (kproc_shutdown) sp = 0xde6ec9a0 fp = 0xde6ec9a4 r4 = 0xc0b8a5a0 r5 = 0x00000000 r6 = 0xc0b8a65c r7 = 0xc0b7cf70 r8 = 0x00000000 r9 = 0xc0b8a658 r10 = 0xc05cace3 kproc_shutdown() at kproc_shutdown pc = 0xc0365120 lr = 0x00000000 (0) sp = 0xde6ec9ac fp = 0xde6ec9f8 r4 = 0xc0365120 r5 = 0xde6ec9ac Unable to unwind into user mode db> ps pid ppid pgrp uid state wmesg wchan cmd 49036 696 669 0 R+ CPU 0 mkdir 33298 13528 33298 1001 S+ select 0xc313aea4 systat 13528 631 13528 1001 Ss+ pause 0xc2f4bce8 tcsh 696 669 669 0 S+ wait 0xc2f4b640 sh 695 669 669 0 S+ pipewr 0xc2b6d558 cat 669 662 669 0 S+ wait 0xc2b01000 sh 662 661 662 0 S+ pause 0xc2d6f9c8 tcsh 661 632 661 1001 S+ wait 0xc2d6e320 su 632 631 632 1001 Ss+ pause 0xc2b02388 tcsh 631 1 631 1001 Ss select 0xc29d91e4 tmux 629 626 629 1001 S+ select 0xc29da224 tmux 626 625 626 1001 Ss+ pause 0xc2b026a8 tcsh 625 622 622 1001 S select 0xc29d9324 sshd 622 572 622 0 Ss select 0xc29d90e4 sshd 615 1 615 0 Ss+ ttyin 0xc28e0670 getty 576 1 576 0 Ss nanslp 0xc067c360 cron 572 1 572 0 Ss select 0xc29d9124 sshd 484 1 484 0 Ss select 0xc29dabe4 casperd 483 1 483 0 Ss select 0xc29db124 casperd 377 1 377 0 Ss select 0xc29d9da4 syslogd 302 1 302 0 Ss select 0xc29d94e4 devd 81 0 0 0 DL mdwait 0xc2aff800 [md2] 76 0 0 0 DL mdwait 0xc2b43800 [md1] 71 0 0 0 DL mdwait 0xc2c0a000 [md0] 17 0 0 0 DL - 0xc067b240 [schedcpu] 16 0 0 0 DL sdflush 0xc0928bac [softdepflush] 15 0 0 0 DL syncer 0xc092698c [syncer] 9 0 0 0 DL vlruwt 0xc2b02000 [vnlru] 8 0 0 0 DL psleep 0xc0926710 [bufdaemon] 7 0 0 0 DL pgzero 0xc09294c4 [pagezero] 6 0 0 0 DL psleep 0xc09292ec [vmdaemon] 5 0 0 0 DL psleep 0xc0930f44 [pagedaemon] 4 0 0 0 DL jobqueue 0xc29d2e80 [mmcsd1: mmc/sd card] 3 0 0 0 DL mmcreq 0xdd490ca8 [mmcsd0: mmc/sd card] 14 0 0 0 DL (threaded) [usb] 100048 D - 0xc29c92a4 [usbus1] 100047 D - 0xc29c9274 [usbus1] 100046 D - 0xc29c9244 [usbus1] 100045 D - 0xc29c9214 [usbus1] 100043 D - 0xc29c80bc [usbus0] 100042 D - 0xc29c808c [usbus0] 100041 D - 0xc29c805c [usbus0] 100040 D - 0xc29c802c [usbus0] 2 0 0 0 DL (threaded) [cam] 100058 D - 0xc0676128 [scanner] 100014 D - 0xc06760c0 [doneq0] 13 0 0 0 DL - 0xc0678f70 [rand_harvestq] 12 0 0 0 DL (threaded) [geom] 100008 D - 0xc092d73c [g_down] 100007 D - 0xc092d738 [g_up] 100006 D - 0xc092d734 [g_event] 11 0 0 0 WL (threaded) [intr] 100056 I [intr27: ti_pruss0] 100055 I [intr26: ti_pruss0] 100054 I [intr25: ti_pruss0] 100053 I [intr24: ti_pruss0] 100052 I [intr23: ti_pruss0] 100051 I [intr22: ti_pruss0] 100050 I [intr21: ti_pruss0] 100049 I [intr20: ti_pruss0] 100044 I [intr19: musbotg0] 100039 I [intr18: musbotg0] 100038 I [intr17: musbotg0] 100037 I [intr30: iichb2] 100036 I [intr71: iichb1] 100035 I [intr70: iichb0] 100034 I [intr43: cpsw0] 100033 I [intr41: cpsw0] 100032 I [intr40: cpsw0] 100031 I [intr28: sdhci_ti1] 100030 I [intr64: sdhci_ti0] 100029 I [intr14: ti_edma30] 100028 I [intr13: ti_edma30] 100027 I [intr12: ti_edma30] 100026 I [swi0: uart] 100025 I [intr63: gpio0] 100024 I [intr62: gpio0] 100023 I [intr33: gpio0] 100022 I [intr32: gpio0] 100021 I [intr99: gpio0] 100020 I [intr98: gpio0] 100019 I [intr97: gpio0] 100018 I [intr96: gpio0] 100017 I [intr16: ti_adc0] 100016 I [swi6: task queue] 100013 I [swi5: fast taskq] 100010 I [swi6: Giant taskq] 100005 I [swi3: vm] 100004 I [swi4: clock (0)] 100003 I [swi1: netisr 0] 10 0 0 0 RL [idle] 1 0 1 0 SLs wait 0xc2865640 [init] 0 0 0 0 DLs (threaded) [kernel] 100057 D - 0xc2896780 [CAM taskq] 100015 D - 0xc2895d00 [kqueue taskq] 100012 D - 0xc2896880 [thread taskq] 100011 D - 0xc2896900 [ffs_trim taskq] 100000 D swapin 0xc092d758 [swapper] db> -Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Fri Jun 20 05:23:03 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 397ADA1A; Fri, 20 Jun 2014 05:23:03 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2001:470:1:2d5:26:3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD372532; Fri, 20 Jun 2014 05:23:03 +0000 (UTC) Received: from [IPv6:2601:9:8280:426:e911:7046:4e11:b1fa] (unknown [IPv6:2601:9:8280:426:e911:7046:4e11:b1fa]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 3090A34A9E5; Thu, 19 Jun 2014 22:23:02 -0700 (PDT) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: locore.S and debugging initial stages of kernel From: Rui Paulo In-Reply-To: <1403230772.20883.281.camel@revolution.hippie.lan> Date: Thu, 19 Jun 2014 22:23:01 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <53A3619C.3020505@narod.ru> <776BC360-5D2F-435C-B2B0-38449D4AB56D@bsdimp.com> <1403230772.20883.281.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 05:23:03 -0000 On Jun 19, 2014, at 19:19, Ian Lepore wrote: > I usually emit single chars by writing directly the console uart > register. I use exactly the same method, but your code looks much better. :-) -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Fri Jun 20 15:10:25 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC3C590A for ; Fri, 20 Jun 2014 15:10:25 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8ED812AD9 for ; Fri, 20 Jun 2014 15:10:25 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5KFAO0P072805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Jun 2014 08:10:24 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5KFAOOW072804 for arm@FreeBSD.org; Fri, 20 Jun 2014 08:10:24 -0700 (PDT) (envelope-from jmg) Date: Fri, 20 Jun 2014 08:10:24 -0700 From: John-Mark Gurney To: arm@FreeBSD.org Subject: Re: AVILA getting close! Message-ID: <20140620151023.GZ31367@funkthat.com> Mail-Followup-To: arm@FreeBSD.org References: <20140618225808.GG31367@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140618225808.GG31367@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 20 Jun 2014 08:10:24 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 15:10:25 -0000 John-Mark Gurney wrote this message on Wed, Jun 18, 2014 at 15:58 -0700: > So, w/ the recent couple of patches that alc has provided, I no longer > receive kernel panics on my AVILA board! > > $ uname -a > FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > $ uptime > 12:15AM up 1 day, 15 mins, 2 users, load averages: 0.13, 0.11, 0.08 > > This survived a portsnap extract... This is all over NFS... > > Though the issue that I'm now having is that some binaries (newsyslog) > and sometimes other binaries (awk, grep) core dump... > > I believe this is an issue w/ rtld, or related... If I compile newsyslog > -static, it works fine... Otherwise I get a SIGILL, and that is > because it jumps off into the weeds.. Though gdb on arm isn't very > useful.. ok, so the SIGILL only occures under gdb, and this is because single stepping into a RAS sequence doesn't work very well... If you set a break point on the return (after the RAS sequence), you can get past this... I got to the point in rtld.c code: if (obj->pltrel) rel = (const Elf_Rel *) ((caddr_t) obj->pltrel + reloff); else rel = (const Elf_Rel *) ((caddr_t) obj->pltrela + reloffand was seeing gdb try to execute the pltrela line, but: i; and was seeing gdb try to execute the pltrela line, but: (gdb) print * (const Elf_Rel *) ((caddr_t) obj->pltrela + reloff) Error accessing memory address 0x118: Bad address. (gdb) print/x obj->pltrela $4 = 0x0 (gdb) print /x reloff $5 = 0x118 (gdb) print obj->pltrel $6 = (const Elf_Rel *) 0x94e8 Hun? obj->pltrel is non-zero, so it should have executed the other line... I recompiled rtld w/ -O0, and sure enough, newsyslog runs fine... If I compile w/o -O, or w/ -O1, it fails... Comments or suggestions? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Fri Jun 20 19:08:41 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34CC9CB for ; Fri, 20 Jun 2014 19:08:41 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 19E8B20C6 for ; Fri, 20 Jun 2014 19:08:41 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id B0EBB5DEBC; Fri, 20 Jun 2014 19:08:33 +0000 (UTC) Date: Fri, 20 Jun 2014 20:08:27 +0100 From: Andrew Turner To: John-Mark Gurney Subject: Re: AVILA getting close! Message-ID: <20140620200827.1c33c7da@bender.Home> In-Reply-To: <20140620151023.GZ31367@funkthat.com> References: <20140618225808.GG31367@funkthat.com> <20140620151023.GZ31367@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 19:08:41 -0000 On Fri, 20 Jun 2014 08:10:24 -0700 John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Wed, Jun 18, 2014 at 15:58 > -0700: > > So, w/ the recent couple of patches that alc has provided, I no > > longer receive kernel panics on my AVILA board! > > > > $ uname -a > > FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 > > r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 > > jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA > > arm $ uptime 12:15AM up 1 day, 15 mins, 2 users, load averages: > > 0.13, 0.11, 0.08 > > > > This survived a portsnap extract... This is all over NFS... > > > > Though the issue that I'm now having is that some binaries > > (newsyslog) and sometimes other binaries (awk, grep) core dump... > > > > I believe this is an issue w/ rtld, or related... If I compile > > newsyslog -static, it works fine... Otherwise I get a SIGILL, and > > that is because it jumps off into the weeds.. Though gdb on arm > > isn't very useful.. > > ok, so the SIGILL only occures under gdb, and this is because single > stepping into a RAS sequence doesn't work very well... If you set a > break point on the return (after the RAS sequence), you can get past > this... > > I got to the point in rtld.c code: > if (obj->pltrel) > rel = (const Elf_Rel *) ((caddr_t) obj->pltrel + reloff); > else > rel = (const Elf_Rel *) ((caddr_t) obj->pltrela + reloffand > was seeing gdb try to execute the pltrela line, but: i; > > and was seeing gdb try to execute the pltrela line, but: > (gdb) print * (const Elf_Rel *) ((caddr_t) obj->pltrela + reloff) > Error accessing memory address 0x118: Bad address. > (gdb) print/x obj->pltrela > $4 = 0x0 > (gdb) print /x reloff > $5 = 0x118 > (gdb) print obj->pltrel > $6 = (const Elf_Rel *) 0x94e8 Based on my copy of newsyslog I built for armeb this looks correct. To verify it could you dump the .dynamic section from the binary? Something like 'objdump -s newsyslog' will get it. > Hun? obj->pltrel is non-zero, so it should have executed the other > line... > > I recompiled rtld w/ -O0, and sure enough, newsyslog runs fine... If > I compile w/o -O, or w/ -O1, it fails... > > Comments or suggestions? > What is the value of rel after the if statement? In the -O/-O1 case the asm looks like: ldr r2, [sp, #20] ; Load obj to r2 ldr r3, [r2, #124] ; Load obj->pltrel to r3 cmp r3, #0 ; 0x0 ; if obj->pltrel: ldrne r2, [sp, #16] ; != NULL: Load reloff to r2 addne r4, r3, r2 ; != NULL: Add obj->pltrel + reloff to r4 ldreq r2, [sp, #20] ; == NULL: Load obj to r2 ldreq r3, [r2, #132] ; == NULL: Load obj->pltrela to r3 ldreq r2, [sp, #16] ; == NULL: Load reloff to r2 addeq r4, r2, r3 ; == NULL: Add obj->pltrela + reloff to r4 Given this I could see how gdb gets confused. It may also pay to get the registers from gdb at this point. Andrew From owner-freebsd-arm@FreeBSD.ORG Fri Jun 20 23:55:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F34064A0 for ; Fri, 20 Jun 2014 23:55:10 +0000 (UTC) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 770562884 for ; Fri, 20 Jun 2014 23:55:09 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id u10so2715462lbd.8 for ; Fri, 20 Jun 2014 16:55:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type:subject:from:date:to:cc :message-id; bh=yTx3mIN6zSYyj7l9mXIvEHFunlkCDBYmXfTDQ5M8crk=; b=cEDGruKHM2yQHbpTeWRZl3679Qlnyje9f7frFwOaVLG64PFVqXgVmmG8gSAX7TyvPl upQxUylBvCG2BAbpQWHSo5oQvzJUMUFohToCOBKDtkR4g2rhNbdGApcE1xYcHWkFcv6h 2Y51VpdAlT7KchlQatDnixDOa1jBcwncLsvFSLvZLP+Qczp5D3Jk7HJtwrYRMtxDJsUx ho9eysXnPTfDnRnJvUW09CmOK7cWBGluyof+ppadNxisJucP2b18UzYFnhyQZcxUoWfj KSu/gaGy4DySYoCVlFYhTNbCMdA3zrjDmlAqwKPW74tPF3Ns/eTAQwVJmg96FR4TgztQ 4MpA== X-Gm-Message-State: ALoCoQl2dibkT0L3zDfo31CC0m8kCtsZ3gC/OFyusuwfPfQ0fwOCUvo1Nnv7X4AhFy2c4llpJACR X-Received: by 10.112.13.137 with SMTP id h9mr4220349lbc.33.1403302706394; Fri, 20 Jun 2014 15:18:26 -0700 (PDT) Received: from [192.168.1.87] (137-15-133-95.pool.ukrtel.net. [95.133.15.137]) by mx.google.com with ESMTPSA id xa9sm7440692lbb.36.2014.06.20.15.18.24 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 20 Jun 2014 15:18:25 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <53A3619C.3020505@narod.ru> <776BC360-5D2F-435C-B2B0-38449D4AB56D@bsdimp.com> <1403230772.20883.281.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: locore.S and debugging initial stages of kernel From: Aleksandr Rybalko Date: Sat, 21 Jun 2014 01:18:10 +0300 To: Rui Paulo ,Ian Lepore Message-ID: <0eac2533-d4bb-4bc6-9ba1-3dae40aa4360@email.android.com> Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 23:55:11 -0000 On 20 червня 2014 р. 08:23:01 GMT+03:00, Rui Paulo wrote: >On Jun 19, 2014, at 19:19, Ian Lepore wrote: > >> I usually emit single chars by writing directly the console uart >> register. > >I use exactly the same method, but your code looks much better. :-) > >-- >Rui Paulo > > > >_______________________________________________ >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" Is not it would be better to just load txd address, instead of ORing 2-4 times? :-D WBW ------ Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Fri Jun 20 23:57:13 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCAC4508; Fri, 20 Jun 2014 23:57:13 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CCD1289D; Fri, 20 Jun 2014 23:57:12 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wy8g4-0000jf-Sg; Fri, 20 Jun 2014 23:57:05 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5KNv1eI001500; Fri, 20 Jun 2014 17:57:01 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19bp3vZ7IMPmn+5f7ZQB41M Subject: Re: locore.S and debugging initial stages of kernel From: Ian Lepore To: Aleksandr Rybalko In-Reply-To: <0eac2533-d4bb-4bc6-9ba1-3dae40aa4360@email.android.com> References: <53A3619C.3020505@narod.ru> <776BC360-5D2F-435C-B2B0-38449D4AB56D@bsdimp.com> <1403230772.20883.281.camel@revolution.hippie.lan> <0eac2533-d4bb-4bc6-9ba1-3dae40aa4360@email.android.com> Content-Type: text/plain; charset="koi8-r" Date: Fri, 20 Jun 2014 17:57:00 -0600 Message-ID: <1403308620.20883.288.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s5KNv1eI001500 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 23:57:13 -0000 On Sat, 2014-06-21 at 01:18 +0300, Aleksandr Rybalko wrote: > On 20 =DE=C5=D2=D7=CE=D1 2014 =D2. 08:23:01 GMT+03:00, Rui Paulo wrote: > >On Jun 19, 2014, at 19:19, Ian Lepore wrote: > > > >> I usually emit single chars by writing directly the console uart > >> register. > > > >I use exactly the same method, but your code looks much better. :-) > > > >-- > >Rui Paulo > > > > > > > >_______________________________________________ > >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 > Is not it would be better to just load txd address, instead of ORing 2-= 4 times? :-D > WBW > ------ > Aleksandr Rybalko >=20 >=20 You mean store the value in memory somewhere, and then at runtime load a pointer to where it's stored using only pc-relative instructions and then loading the actual value using the pointer? Harder to write, the code added for "quick debugging" would be more scattered, and it's actually slower (not that performance really matters here). It could be done as a 1-liner using "=3DVALUE" syntax, but chances are that turns int= o mov,orr,orr. :) -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Jun 21 01:08:06 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5958E6D0 for ; Sat, 21 Jun 2014 01:08:06 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 34E282DBF for ; Sat, 21 Jun 2014 01:08:05 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5L184CK082143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2014 18:08:04 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5L184L8082142; Fri, 20 Jun 2014 18:08:04 -0700 (PDT) (envelope-from jmg) Date: Fri, 20 Jun 2014 18:08:04 -0700 From: John-Mark Gurney To: Andrew Turner Subject: Re: AVILA getting close! Message-ID: <20140621010804.GD31367@funkthat.com> Mail-Followup-To: Andrew Turner , arm@FreeBSD.org References: <20140618225808.GG31367@funkthat.com> <20140620151023.GZ31367@funkthat.com> <20140620200827.1c33c7da@bender.Home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140620200827.1c33c7da@bender.Home> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 20 Jun 2014 18:08:05 -0700 (PDT) Cc: arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 01:08:06 -0000 Andrew Turner wrote this message on Fri, Jun 20, 2014 at 20:08 +0100: > On Fri, 20 Jun 2014 08:10:24 -0700 > John-Mark Gurney wrote: > > > John-Mark Gurney wrote this message on Wed, Jun 18, 2014 at 15:58 > > -0700: > > > So, w/ the recent couple of patches that alc has provided, I no > > > longer receive kernel panics on my AVILA board! > > > > > > $ uname -a > > > FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 > > > r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 > > > jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA > > > arm $ uptime 12:15AM up 1 day, 15 mins, 2 users, load averages: > > > 0.13, 0.11, 0.08 > > > > > > This survived a portsnap extract... This is all over NFS... > > > > > > Though the issue that I'm now having is that some binaries > > > (newsyslog) and sometimes other binaries (awk, grep) core dump... > > > > > > I believe this is an issue w/ rtld, or related... If I compile > > > newsyslog -static, it works fine... Otherwise I get a SIGILL, and > > > that is because it jumps off into the weeds.. Though gdb on arm > > > isn't very useful.. > > > > ok, so the SIGILL only occures under gdb, and this is because single > > stepping into a RAS sequence doesn't work very well... If you set a > > break point on the return (after the RAS sequence), you can get past > > this... > > > > I got to the point in rtld.c code: > > if (obj->pltrel) > > rel = (const Elf_Rel *) ((caddr_t) obj->pltrel + reloff); > > else > > rel = (const Elf_Rel *) ((caddr_t) obj->pltrela + reloffand > > was seeing gdb try to execute the pltrela line, but: i; > > > > and was seeing gdb try to execute the pltrela line, but: > > (gdb) print * (const Elf_Rel *) ((caddr_t) obj->pltrela + reloff) > > Error accessing memory address 0x118: Bad address. > > (gdb) print/x obj->pltrela > > $4 = 0x0 > > (gdb) print /x reloff > > $5 = 0x118 > > (gdb) print obj->pltrel > > $6 = (const Elf_Rel *) 0x94e8 > Based on my copy of newsyslog I built for armeb this looks correct. To > verify it could you dump the .dynamic section from the binary? > Something like 'objdump -s newsyslog' will get it. ok, available at: https://www.funkthat.com/~jmg/20140619/objdump.newsyslog > > Hun? obj->pltrel is non-zero, so it should have executed the other > > line... > > > > I recompiled rtld w/ -O0, and sure enough, newsyslog runs fine... If > > I compile w/o -O, or w/ -O1, it fails... > > > > Comments or suggestions? > > What is the value of rel after the if statement? In the -O/-O1 case the > asm looks like: > > ldr r2, [sp, #20] ; Load obj to r2 > ldr r3, [r2, #124] ; Load obj->pltrel to r3 > cmp r3, #0 ; 0x0 ; if obj->pltrel: > ldrne r2, [sp, #16] ; != NULL: Load reloff to r2 > addne r4, r3, r2 ; != NULL: Add obj->pltrel + reloff to r4 > ldreq r2, [sp, #20] ; == NULL: Load obj to r2 > ldreq r3, [r2, #132] ; == NULL: Load obj->pltrela to r3 > ldreq r2, [sp, #16] ; == NULL: Load reloff to r2 > addeq r4, r2, r3 ; == NULL: Add obj->pltrela + reloff to r4 > > Given this I could see how gdb gets confused. > > It may also pay to get the registers from gdb at this point. Arg! This is frustrating, I'm getting such different behaviors from time to time.. now it isn't having that fault.. but it's getting farther, but... I this is because our in tree gdb is messed up.. But, I am getting farther... now the last break at rtld.c:3651 looks like it's returning a bogus pointer: (gdb) print *req $12 = {name = 0x9190 "__aeabi_read_tp", hash = 0xf008a80, hash_gnu = 0x52432dd3, ventry = 0x2003b1d0, flags = 0x1, defobj_out = 0x2003c400, sym_out = 0x20062454, lockstate = 0xbfffeda0} defobj_out looks bogus to me... We don't have any object mapped there: (gdb) info shared >From To Syms Read Shared Object Library 0x200427c8 0x20048814 Yes /lib/libgcc_s.so.1 0x2007a4e8 0x2017f320 Yes /lib/libc.so.7 0x20018f14 0x2002c99c Yes /libexec/ld-elf.so.1 the data at 0x2003c400 doesn't look like code: (gdb) x/32x 0x2003c400 0x2003c400: 0xd550b87a 0x00000001 0x00000000 0x2003a080 0x2003c410: 0x00000000 0x00000001 0x00000000 0x20051000 0x2003c420: 0x0016a000 0x00143000 0x00000000 0x20051000 0x2003c430: 0x2019dfd0 0x2007a4e8 0x20051034 0x000000a0 0x2003c440: 0x00000000 0x00000007 0x00000002 0x2019bcf0 0x2003c450: 0x00000004 0x00000058 0x00000000 0x00000008 0x2003c460: 0x20051000 0x00000000 0x2019e0b8 0x200713e0 0x2003c470: 0x000040c0 0x00000000 0x00000000 0x200754a0 and then as I stepi out of symlook_global: (gdb) x/6i $pc 0x2001f0b4 : cmp r0, #0 ; 0x0 0x2001f0b8 : moveq r0, #3 ; 0x3 0x2001f0bc : movne r0, #0 ; 0x0 0x2001f0c0 : add sp, sp, #36 ; 0x24 0x2001f0c4 : pop {r4, r5, r6, r7, lr} 0x2001f0c8 : bx lr (gdb) info registers r0 0x20062454 0x20062454 r1 0x933b 0x933b r2 0x0 0x0 r3 0xa4 0xa4 r4 0x0 0x0 r5 0xbfffed3c 0xbfffed3c r6 0xbfffed08 0xbfffed08 r7 0x20037af4 0x20037af4 r8 0x0 0x0 r9 0x1 0x1 r10 0x8a2c 0x8a2c r11 0xbfffed30 0xbfffed30 r12 0x23de 0x23de sp 0xbfffec94 0xbfffec94 lr 0x2001efb0 0x2001efb0 pc 0x2001f0b4 0x2001f0b4 fps 0x0 0x0 cpsr 0x60000010 0x60000010 Then stepi till 0x2001f0c8: (gdb) info registers r0 0x0 0x0 r1 0x933b 0x933b r2 0x0 0x0 r3 0xa4 0xa4 r4 0x2003c000 0x2003c000 r5 0xbfffed3c 0xbfffed3c r6 0x20037af4 0x20037af4 r7 0xbfffece8 0xbfffece8 r8 0x0 0x0 r9 0x1 0x1 r10 0x8a2c 0x8a2c r11 0xbfffed30 0xbfffed30 r12 0x23de 0x23de sp 0xbfffeccc 0xbfffeccc lr 0x2003c000 0x2003c000 pc 0x2001f0c8 0x2001f0c8 fps 0x0 0x0 cpsr 0x20000010 0x20000010 and now the lr is bogus... it transfers control to 0x2003c000 which is before the fault at 0x2003c0f4... And again, this looks like data, not code: (gdb) x/64x 0x2003c000 0x2003c000: 0xd550b87a 0x00000001 0x2003c200 0xbfffffb8 0x2003c010: 0x00000000 0x00000001 0x00000000 0x00008000 0x2003c020: 0x00012000 0x00009000 0x00008000 0x00000000 0x2003c030: 0x00018724 0x00009ca8 0x00008034 0x000000e0 0x2003c040: 0x00008114 0x00000007 0x00000000 0x00000000 0x2003c050: 0x00000000 0x00000000 0x00000000 0x00000000 0x2003c060: 0x00000000 0x00000000 0x0001881c 0x000094a0 0x2003c070: 0x00000048 0x00000000 0x00000000 0x000094e8 0x2003c080: 0x00000308 0x00000000 0x00000000 0x0000888c 0x2003c090: 0x00008f9c 0x000003b1 0x00009430 0x00000002 0x2003c0a0: 0x00000000 0x00000000 0x0000934e 0x00008180 0x2003c0b0: 0x00000061 0x00008304 0x00000071 0x00000061 0x2003c0c0: 0x00000005 0x0000001f 0x0000000a 0x00000071 0x2003c0d0: 0x000084d8 0x00008558 0x000086c8 0x00000000 0x2003c0e0: 0x00000000 0x2003d000 0x00000000 0x00000000 0x2003c0f0: 0x00000000 0x2003c0f0 0x2003b180 0x00000007 If I continue to stepi from here, it will fault at f4... This looks like a stack smash issue as the lr we pop off the stack is incorrect.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Jun 21 07:08:32 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32F268B8 for ; Sat, 21 Jun 2014 07:08:32 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BE322799 for ; Sat, 21 Jun 2014 07:08:31 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5L78T95086982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jun 2014 00:08:29 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5L78SVe086981; Sat, 21 Jun 2014 00:08:28 -0700 (PDT) (envelope-from jmg) Date: Sat, 21 Jun 2014 00:08:28 -0700 From: John-Mark Gurney To: Andrew Turner , arm@FreeBSD.org Subject: Re: AVILA getting close! Message-ID: <20140621070827.GJ31367@funkthat.com> Mail-Followup-To: Andrew Turner , arm@FreeBSD.org References: <20140618225808.GG31367@funkthat.com> <20140620151023.GZ31367@funkthat.com> <20140620200827.1c33c7da@bender.Home> <20140621010804.GD31367@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140621010804.GD31367@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 21 Jun 2014 00:08:30 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 07:08:32 -0000 John-Mark Gurney wrote this message on Fri, Jun 20, 2014 at 18:08 -0700: > Andrew Turner wrote this message on Fri, Jun 20, 2014 at 20:08 +0100: > > On Fri, 20 Jun 2014 08:10:24 -0700 > > John-Mark Gurney wrote: > > > > > John-Mark Gurney wrote this message on Wed, Jun 18, 2014 at 15:58 > > > -0700: > > > > So, w/ the recent couple of patches that alc has provided, I no > > > > longer receive kernel panics on my AVILA board! > > > > > > > > $ uname -a > > > > FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27 > > > > r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 > > > > jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA > > > > arm $ uptime 12:15AM up 1 day, 15 mins, 2 users, load averages: > > > > 0.13, 0.11, 0.08 > > > > > > > > This survived a portsnap extract... This is all over NFS... > > > > > > > > Though the issue that I'm now having is that some binaries > > > > (newsyslog) and sometimes other binaries (awk, grep) core dump... > > > > > > > > I believe this is an issue w/ rtld, or related... If I compile > > > > newsyslog -static, it works fine... Otherwise I get a SIGILL, and > > > > that is because it jumps off into the weeds.. Though gdb on arm > > > > isn't very useful.. > > > > > > ok, so the SIGILL only occures under gdb, and this is because single > > > stepping into a RAS sequence doesn't work very well... If you set a > > > break point on the return (after the RAS sequence), you can get past > > > this... > > > > > > I got to the point in rtld.c code: > > > if (obj->pltrel) > > > rel = (const Elf_Rel *) ((caddr_t) obj->pltrel + reloff); > > > else > > > rel = (const Elf_Rel *) ((caddr_t) obj->pltrela + reloffand > > > was seeing gdb try to execute the pltrela line, but: i; > > > > > > and was seeing gdb try to execute the pltrela line, but: > > > (gdb) print * (const Elf_Rel *) ((caddr_t) obj->pltrela + reloff) > > > Error accessing memory address 0x118: Bad address. > > > (gdb) print/x obj->pltrela > > > $4 = 0x0 > > > (gdb) print /x reloff > > > $5 = 0x118 > > > (gdb) print obj->pltrel > > > $6 = (const Elf_Rel *) 0x94e8 > > Based on my copy of newsyslog I built for armeb this looks correct. To > > verify it could you dump the .dynamic section from the binary? > > Something like 'objdump -s newsyslog' will get it. > > ok, available at: > https://www.funkthat.com/~jmg/20140619/objdump.newsyslog > > > > Hun? obj->pltrel is non-zero, so it should have executed the other > > > line... > > > > > > I recompiled rtld w/ -O0, and sure enough, newsyslog runs fine... If > > > I compile w/o -O, or w/ -O1, it fails... > > > > > > Comments or suggestions? > > > > What is the value of rel after the if statement? In the -O/-O1 case the > > asm looks like: > > > > ldr r2, [sp, #20] ; Load obj to r2 > > ldr r3, [r2, #124] ; Load obj->pltrel to r3 > > cmp r3, #0 ; 0x0 ; if obj->pltrel: > > ldrne r2, [sp, #16] ; != NULL: Load reloff to r2 > > addne r4, r3, r2 ; != NULL: Add obj->pltrel + reloff to r4 > > ldreq r2, [sp, #20] ; == NULL: Load obj to r2 > > ldreq r3, [r2, #132] ; == NULL: Load obj->pltrela to r3 > > ldreq r2, [sp, #16] ; == NULL: Load reloff to r2 > > addeq r4, r2, r3 ; == NULL: Add obj->pltrela + reloff to r4 > > > > Given this I could see how gdb gets confused. > > > > It may also pay to get the registers from gdb at this point. > > Arg! This is frustrating, I'm getting such different behaviors from > time to time.. now it isn't having that fault.. but it's getting > farther, but... I this is because our in tree gdb is messed up.. > > But, I am getting farther... now the last break at rtld.c:3651 > looks like it's returning a bogus pointer: > (gdb) print *req > $12 = {name = 0x9190 "__aeabi_read_tp", hash = 0xf008a80, > hash_gnu = 0x52432dd3, ventry = 0x2003b1d0, flags = 0x1, > defobj_out = 0x2003c400, sym_out = 0x20062454, lockstate = 0xbfffeda0} > > defobj_out looks bogus to me... We don't have any object mapped > there: > (gdb) info shared > >From To Syms Read Shared Object Library > 0x200427c8 0x20048814 Yes /lib/libgcc_s.so.1 > 0x2007a4e8 0x2017f320 Yes /lib/libc.so.7 > 0x20018f14 0x2002c99c Yes /libexec/ld-elf.so.1 > > the data at 0x2003c400 doesn't look like code: > (gdb) x/32x 0x2003c400 > 0x2003c400: 0xd550b87a 0x00000001 0x00000000 0x2003a080 > 0x2003c410: 0x00000000 0x00000001 0x00000000 0x20051000 > 0x2003c420: 0x0016a000 0x00143000 0x00000000 0x20051000 > 0x2003c430: 0x2019dfd0 0x2007a4e8 0x20051034 0x000000a0 > 0x2003c440: 0x00000000 0x00000007 0x00000002 0x2019bcf0 > 0x2003c450: 0x00000004 0x00000058 0x00000000 0x00000008 > 0x2003c460: 0x20051000 0x00000000 0x2019e0b8 0x200713e0 > 0x2003c470: 0x000040c0 0x00000000 0x00000000 0x200754a0 > > and then as I stepi out of symlook_global: > (gdb) x/6i $pc > 0x2001f0b4 : cmp r0, #0 ; 0x0 > 0x2001f0b8 : moveq r0, #3 ; 0x3 > 0x2001f0bc : movne r0, #0 ; 0x0 > 0x2001f0c0 : add sp, sp, #36 ; 0x24 > 0x2001f0c4 : pop {r4, r5, r6, r7, lr} > 0x2001f0c8 : bx lr > (gdb) info registers > r0 0x20062454 0x20062454 > r1 0x933b 0x933b > r2 0x0 0x0 > r3 0xa4 0xa4 > r4 0x0 0x0 > r5 0xbfffed3c 0xbfffed3c > r6 0xbfffed08 0xbfffed08 > r7 0x20037af4 0x20037af4 > r8 0x0 0x0 > r9 0x1 0x1 > r10 0x8a2c 0x8a2c > r11 0xbfffed30 0xbfffed30 > r12 0x23de 0x23de > sp 0xbfffec94 0xbfffec94 > lr 0x2001efb0 0x2001efb0 > pc 0x2001f0b4 0x2001f0b4 > fps 0x0 0x0 > cpsr 0x60000010 0x60000010 > > Then stepi till 0x2001f0c8: > (gdb) info registers > r0 0x0 0x0 > r1 0x933b 0x933b > r2 0x0 0x0 > r3 0xa4 0xa4 > r4 0x2003c000 0x2003c000 > r5 0xbfffed3c 0xbfffed3c > r6 0x20037af4 0x20037af4 > r7 0xbfffece8 0xbfffece8 > r8 0x0 0x0 > r9 0x1 0x1 > r10 0x8a2c 0x8a2c > r11 0xbfffed30 0xbfffed30 > r12 0x23de 0x23de > sp 0xbfffeccc 0xbfffeccc > lr 0x2003c000 0x2003c000 > pc 0x2001f0c8 0x2001f0c8 > fps 0x0 0x0 > cpsr 0x20000010 0x20000010 > > and now the lr is bogus... it transfers control to 0x2003c000 which > is before the fault at 0x2003c0f4... And again, this looks like data, > not code: > (gdb) x/64x 0x2003c000 > 0x2003c000: 0xd550b87a 0x00000001 0x2003c200 0xbfffffb8 > 0x2003c010: 0x00000000 0x00000001 0x00000000 0x00008000 > 0x2003c020: 0x00012000 0x00009000 0x00008000 0x00000000 > 0x2003c030: 0x00018724 0x00009ca8 0x00008034 0x000000e0 > 0x2003c040: 0x00008114 0x00000007 0x00000000 0x00000000 > 0x2003c050: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2003c060: 0x00000000 0x00000000 0x0001881c 0x000094a0 > 0x2003c070: 0x00000048 0x00000000 0x00000000 0x000094e8 > 0x2003c080: 0x00000308 0x00000000 0x00000000 0x0000888c > 0x2003c090: 0x00008f9c 0x000003b1 0x00009430 0x00000002 > 0x2003c0a0: 0x00000000 0x00000000 0x0000934e 0x00008180 > 0x2003c0b0: 0x00000061 0x00008304 0x00000071 0x00000061 > 0x2003c0c0: 0x00000005 0x0000001f 0x0000000a 0x00000071 > 0x2003c0d0: 0x000084d8 0x00008558 0x000086c8 0x00000000 > 0x2003c0e0: 0x00000000 0x2003d000 0x00000000 0x00000000 > 0x2003c0f0: 0x00000000 0x2003c0f0 0x2003b180 0x00000007 > > If I continue to stepi from here, it will fault at f4... > > This looks like a stack smash issue as the lr we pop off the stack > is incorrect.. So, forgot I could set a watchpoint on the stack address, so I did: (gdb) c Continuing. Watchpoint 9: *0xbfffecc8 Old value = 0x2001f584 New value = 0x2003c000 0x20019960 in donelist_check (dlp=0xbfffed08, obj=0x2003c000) at /usr/src.avila/libexec/rtld-elf/rtld.c:1380 1380 dlp->objs[dlp->num_used++] = obj; I tracked dlp, and it's the donelist pointer, and it is allocated from symlook_default via donelist_init at the top of the function: #define donelist_init(dlp) \ ((dlp)->objs = alloca(obj_count * sizeof (dlp)->objs[0]), \ assert((dlp)->objs != NULL), \ (dlp)->num_alloc = obj_count, \ (dlp)->num_used = 0) Hmm... since obj_count is a global, and we are in a possibly threaded environment, we should probably move assigning num_alloc before the alloca, and then use num_alloc instead of obj_count just to be safe... but taht won't be the issue here, as num_used is 0 in my case... I've looked at the assembly for donelist_init for both the working and non-working case, and besides an extra store in the good version, which I think is just because of the unoptimized code, things look the same to me... I guess the next step is to make sure that the Donelist pointer is the same... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Jun 21 12:13:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A22C782C; Sat, 21 Jun 2014 12:13:05 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E89CC2D85; Sat, 21 Jun 2014 12:13:04 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi2so2111177wib.4 for ; Sat, 21 Jun 2014 05:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yHZR7G/LNwP1SKVPisnbW1QpvfnGA1D4zMWOs2DiV8o=; b=0OfSmqqkopMGqr/GBGl8CXwmg/hQo6/U33XVqbDlN1d0+bDDPrsvcq+s9tz1nEVB0D vr7qbd51AeE9xFe136+TAn6jmQA014fDRtfcomQccdqgtvhKJxiI93sQgIWGocpy8dwH BIeoRGXZXQwqNOirnFFPXyWklhWfrUKLQpzV84n1hfjwEyhlgOaz9L/xX+CTO7oSG7+e D6dzbYpG9PuKohL/WuJERVdbXffCqN6OXorpqXyceZCi7tMXsCRfvSBs3vKuzuxy096b UwsXNL+x5j87pspg9Ho47nF7Z+PfS1V9mpqHlSPiz755aexZ/dhdPdbKLU/ijpb+KCet LsQg== MIME-Version: 1.0 X-Received: by 10.194.91.144 with SMTP id ce16mr11446868wjb.18.1403352782359; Sat, 21 Jun 2014 05:13:02 -0700 (PDT) Received: by 10.216.23.1 with HTTP; Sat, 21 Jun 2014 05:13:01 -0700 (PDT) In-Reply-To: <1403193531.20883.269.camel@revolution.hippie.lan> References: <1403193531.20883.269.camel@revolution.hippie.lan> Date: Sat, 21 Jun 2014 14:13:01 +0200 Message-ID: Subject: Re: Strange slowdown of zlib. From: Magnus Nilsson To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm , freebsd-embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 12:13:05 -0000 On Thu, Jun 19, 2014 at 5:58 PM, Ian Lepore wrote: > On Thu, 2014-06-19 at 17:44 +0200, Magnus Nilsson wrote: >> I have the strangest behaviour of zlib on FreeBSD 8.2 (ARM, but I don't >> think it's necessarily an ARM specific issue). >> Doing >> # md5 /lib/libz.so.5 >> or >> # cp /lib/libz.so.5 /tmp/ >> # export LD_LIBRARY_PATH=/tmp/ >> slows down applications (I've tested bsdtar and gzip) using zlib to a crawl >> on my system. >> >> In the later case, doing >> # unset LD_LIBRARY_PATH >> reverts the issue. >> However, I haven't found any way to recover from the first case, apart from >> rebooting - then the execution time is back to normal. >> >> Here is a log of what I describe above (first moving zlib, then doing the >> md5): >> # cp some2MBfile /tmp/ >> # time gzip /tmp/some2MBfile >> real 0m0.325s >> user 0m0.284s >> sys 0m0.037s >> # rm /tmp/some2MBfile.gz >> # cp /lib/libz.so.5 /tmp/ >> # export LD_LIBRARY_PATH=/tmp/ >> # cp some2MBfile /tmp/ >> # time gzip /tmp/some2MBfile >> real 0m11.949s >> user 0m11.635s >> sys 0m0.035s >> # rm /tmp/some2MBfile.gz >> # unset LD_LIBRARY_PATH >> # cp some2MBfile /tmp/ >> # time gzip /tmp/some2MBfile >> real 0m0.325s >> user 0m0.288s >> sys 0m0.035s >> # rm /tmp/some2MBfile.gz >> # md5 /lib/libz.so.5 >> # cp some2MBfile /tmp/ >> # time gzip /tmp/some2MBfile >> real 0m11.919s >> user 0m11.608s >> sys 0m0.031s >> # rm /tmp/some2MBfile.gz >> >> Do you have any idea what could be going on? >> Any clues are welcome. >> >> Kind regards/Magnus > > This is a known problem on armv4/v5 in freebsd 8. Here is some archived > info on it including patches that work around the problem (rather > crudely, but good enough for our needs at $work). > > http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html > > -- Ian > > Unfortunately, both your patches from http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html were already in. Enabling O_DIRECT in ffs_read() in ffs_vnops_icache_hack.bin makes no difference either. I have patched r224049, r221844, r212507 and r209223 (r205028 and r203637 were already in) mentioned by Warner Losh in http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003292.html in case they'd make any difference, but no. If I run Maks Verver's simple testcase from http://lists.freebsd.org/pipermail/freebsd-arm/2010-March/002243.html , it consistently runs ~15s on my 1GHz CPU. After 'cat testcase > /dev/null', it takes ~14min of course. While e.g. cat or md5 of an executable affects its speed, e.g. cp does not. Could there be some read access that's unaffected by your patches? (As I said privately, thank you very much for setting me on the right track!) KR/Magnus From owner-freebsd-arm@FreeBSD.ORG Sat Jun 21 14:03:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03F17E69; Sat, 21 Jun 2014 14:03:02 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CEB9F2559; Sat, 21 Jun 2014 14:03:01 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5LE30gk098315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jun 2014 07:03:00 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5LE30CV098314; Sat, 21 Jun 2014 07:03:00 -0700 (PDT) (envelope-from jmg) Date: Sat, 21 Jun 2014 07:03:00 -0700 From: John-Mark Gurney To: Magnus Nilsson Subject: Re: Strange slowdown of zlib. Message-ID: <20140621140300.GO31367@funkthat.com> Mail-Followup-To: Magnus Nilsson , Ian Lepore , freebsd-arm , freebsd-embedded@freebsd.org References: <1403193531.20883.269.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 21 Jun 2014 07:03:00 -0700 (PDT) Cc: freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 14:03:02 -0000 Magnus Nilsson wrote this message on Sat, Jun 21, 2014 at 14:13 +0200: > While e.g. cat or md5 of an executable affects its speed, e.g. cp does not. > Could there be some read access that's unaffected by your patches? I believe that cp uses mmap instead of the read syscall like cat and md5... So this may be the case... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Jun 21 16:01:37 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E221A494 for ; Sat, 21 Jun 2014 16:01:37 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id B1B7A2DE4 for ; Sat, 21 Jun 2014 16:01:37 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 250905DEF9; Sat, 21 Jun 2014 16:01:36 +0000 (UTC) Date: Sat, 21 Jun 2014 17:01:29 +0100 From: Andrew Turner To: John-Mark Gurney Subject: Re: AVILA getting close! Message-ID: <20140621170129.76e62c27@bender.Home> In-Reply-To: <20140621070827.GJ31367@funkthat.com> References: <20140618225808.GG31367@funkthat.com> <20140620151023.GZ31367@funkthat.com> <20140620200827.1c33c7da@bender.Home> <20140621010804.GD31367@funkthat.com> <20140621070827.GJ31367@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 16:01:38 -0000 On Sat, 21 Jun 2014 00:08:28 -0700 John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Fri, Jun 20, 2014 at 18:08 > -0700: > > Andrew Turner wrote this message on Fri, Jun 20, 2014 at 20:08 > > +0100: > > > On Fri, 20 Jun 2014 08:10:24 -0700 > > > John-Mark Gurney wrote: > > > > > > > John-Mark Gurney wrote this message on Wed, Jun 18, 2014 at > > > > 15:58 -0700: > > > > > So, w/ the recent couple of patches that alc has provided, I > > > > > no longer receive kernel panics on my AVILA board! > > > > > > > > > > $ uname -a > > > > > FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT > > > > > #27 r267333:267349M: Wed Jun 11 09:57:58 PDT 2014 > > > > > jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA > > > > > arm $ uptime 12:15AM up 1 day, 15 mins, 2 users, load > > > > > averages: 0.13, 0.11, 0.08 > > > > > > > > > > This survived a portsnap extract... This is all over NFS... > > > > > > > > > > Though the issue that I'm now having is that some binaries > > > > > (newsyslog) and sometimes other binaries (awk, grep) core > > > > > dump... > > > > > > > > > > I believe this is an issue w/ rtld, or related... If I > > > > > compile newsyslog -static, it works fine... Otherwise I get > > > > > a SIGILL, and that is because it jumps off into the weeds.. > > > > > Though gdb on arm isn't very useful.. > > > > > > > > ok, so the SIGILL only occures under gdb, and this is because > > > > single stepping into a RAS sequence doesn't work very well... > > > > If you set a break point on the return (after the RAS > > > > sequence), you can get past this... > > > > > > > > I got to the point in rtld.c code: > > > > if (obj->pltrel) > > > > rel = (const Elf_Rel *) ((caddr_t) obj->pltrel + > > > > reloff); else > > > > rel = (const Elf_Rel *) ((caddr_t) obj->pltrela + > > > > reloffand was seeing gdb try to execute the pltrela line, but: > > > > i; > > > > > > > > and was seeing gdb try to execute the pltrela line, but: > > > > (gdb) print * (const Elf_Rel *) ((caddr_t) obj->pltrela + > > > > reloff) Error accessing memory address 0x118: Bad address. > > > > (gdb) print/x obj->pltrela > > > > $4 = 0x0 > > > > (gdb) print /x reloff > > > > $5 = 0x118 > > > > (gdb) print obj->pltrel > > > > $6 = (const Elf_Rel *) 0x94e8 > > > Based on my copy of newsyslog I built for armeb this looks > > > correct. To verify it could you dump the .dynamic section from > > > the binary? Something like 'objdump -s newsyslog' will get it. > > > > ok, available at: > > https://www.funkthat.com/~jmg/20140619/objdump.newsyslog > > > > > > Hun? obj->pltrel is non-zero, so it should have executed the > > > > other line... > > > > > > > > I recompiled rtld w/ -O0, and sure enough, newsyslog runs > > > > fine... If I compile w/o -O, or w/ -O1, it fails... > > > > > > > > Comments or suggestions? > > > > > > What is the value of rel after the if statement? In the -O/-O1 > > > case the asm looks like: > > > > > > ldr r2, [sp, #20] ; Load obj to r2 > > > ldr r3, [r2, #124] ; Load obj->pltrel to r3 > > > cmp r3, #0 ; 0x0 ; if obj->pltrel: > > > ldrne r2, [sp, #16] ; != NULL: Load reloff to r2 > > > addne r4, r3, r2 ; != NULL: Add obj->pltrel + reloff to r4 > > > ldreq r2, [sp, #20] ; == NULL: Load obj to r2 > > > ldreq r3, [r2, #132] ; == NULL: Load obj->pltrela to r3 > > > ldreq r2, [sp, #16] ; == NULL: Load reloff to r2 > > > addeq r4, r2, r3 ; == NULL: Add obj->pltrela + reloff to r4 > > > > > > Given this I could see how gdb gets confused. > > > > > > It may also pay to get the registers from gdb at this point. > > > > Arg! This is frustrating, I'm getting such different behaviors from > > time to time.. now it isn't having that fault.. but it's getting > > farther, but... I this is because our in tree gdb is messed up.. > > > > But, I am getting farther... now the last break at rtld.c:3651 > > looks like it's returning a bogus pointer: > > (gdb) print *req > > $12 = {name = 0x9190 "__aeabi_read_tp", hash = 0xf008a80, > > hash_gnu = 0x52432dd3, ventry = 0x2003b1d0, flags = 0x1, > > defobj_out = 0x2003c400, sym_out = 0x20062454, lockstate = > > 0xbfffeda0} > > > > defobj_out looks bogus to me... We don't have any object mapped > > there: > > (gdb) info shared > > >From To Syms Read Shared Object Library > > 0x200427c8 0x20048814 Yes /lib/libgcc_s.so.1 > > 0x2007a4e8 0x2017f320 Yes /lib/libc.so.7 > > 0x20018f14 0x2002c99c Yes /libexec/ld-elf.so.1 > > > > the data at 0x2003c400 doesn't look like code: > > (gdb) x/32x 0x2003c400 > > 0x2003c400: 0xd550b87a 0x00000001 0x00000000 > > 0x2003a080 0x2003c410: 0x00000000 0x00000001 > > 0x00000000 0x20051000 0x2003c420: 0x0016a000 > > 0x00143000 0x00000000 0x20051000 0x2003c430: > > 0x2019dfd0 0x2007a4e8 0x20051034 0x000000a0 > > 0x2003c440: 0x00000000 0x00000007 0x00000002 > > 0x2019bcf0 0x2003c450: 0x00000004 0x00000058 > > 0x00000000 0x00000008 0x2003c460: 0x20051000 > > 0x00000000 0x2019e0b8 0x200713e0 0x2003c470: > > 0x000040c0 0x00000000 0x00000000 0x200754a0 > > > > and then as I stepi out of symlook_global: > > (gdb) x/6i $pc > > 0x2001f0b4 : cmp r0, #0 ; 0x0 > > 0x2001f0b8 : moveq r0, #3 ; 0x3 > > 0x2001f0bc : movne r0, #0 ; 0x0 > > 0x2001f0c0 : add sp, sp, #36 ; > > 0x24 0x2001f0c4 : pop {r4, r5, r6, > > r7, lr} 0x2001f0c8 : bx lr > > (gdb) info registers > > r0 0x20062454 0x20062454 > > r1 0x933b 0x933b > > r2 0x0 0x0 > > r3 0xa4 0xa4 > > r4 0x0 0x0 > > r5 0xbfffed3c 0xbfffed3c > > r6 0xbfffed08 0xbfffed08 > > r7 0x20037af4 0x20037af4 > > r8 0x0 0x0 > > r9 0x1 0x1 > > r10 0x8a2c 0x8a2c > > r11 0xbfffed30 0xbfffed30 > > r12 0x23de 0x23de > > sp 0xbfffec94 0xbfffec94 The stack is bogus here, the stack should be 8-byte aligned in non-leaf functions. > > lr 0x2001efb0 0x2001efb0 > > pc 0x2001f0b4 0x2001f0b4 > > fps 0x0 0x0 > > cpsr 0x60000010 0x60000010 > > > > Then stepi till 0x2001f0c8: > > (gdb) info registers > > r0 0x0 0x0 > > r1 0x933b 0x933b > > r2 0x0 0x0 > > r3 0xa4 0xa4 > > r4 0x2003c000 0x2003c000 > > r5 0xbfffed3c 0xbfffed3c > > r6 0x20037af4 0x20037af4 > > r7 0xbfffece8 0xbfffece8 > > r8 0x0 0x0 > > r9 0x1 0x1 > > r10 0x8a2c 0x8a2c > > r11 0xbfffed30 0xbfffed30 > > r12 0x23de 0x23de > > sp 0xbfffeccc 0xbfffeccc It's still bogus suggesting someone in the call chain failed at aligning it correctly. > > lr 0x2003c000 0x2003c000 > > pc 0x2001f0c8 0x2001f0c8 > > fps 0x0 0x0 > > cpsr 0x20000010 0x20000010 > > > > and now the lr is bogus... it transfers control to 0x2003c000 which > > is before the fault at 0x2003c0f4... And again, this looks like > > data, not code: When the stack is incorrectly aligned all bets are off, I've seen strange errors when it's not 8-byte aligned. The compiler relies on this assumption to load/store stack based data. > > (gdb) x/64x 0x2003c000 > > 0x2003c000: 0xd550b87a 0x00000001 0x2003c200 > > 0xbfffffb8 0x2003c010: 0x00000000 0x00000001 > > 0x00000000 0x00008000 0x2003c020: 0x00012000 > > 0x00009000 0x00008000 0x00000000 0x2003c030: > > 0x00018724 0x00009ca8 0x00008034 0x000000e0 > > 0x2003c040: 0x00008114 0x00000007 0x00000000 > > 0x00000000 0x2003c050: 0x00000000 0x00000000 > > 0x00000000 0x00000000 0x2003c060: 0x00000000 > > 0x00000000 0x0001881c 0x000094a0 0x2003c070: > > 0x00000048 0x00000000 0x00000000 0x000094e8 > > 0x2003c080: 0x00000308 0x00000000 0x00000000 > > 0x0000888c 0x2003c090: 0x00008f9c 0x000003b1 > > 0x00009430 0x00000002 0x2003c0a0: 0x00000000 > > 0x00000000 0x0000934e 0x00008180 0x2003c0b0: > > 0x00000061 0x00008304 0x00000071 0x00000061 > > 0x2003c0c0: 0x00000005 0x0000001f 0x0000000a > > 0x00000071 0x2003c0d0: 0x000084d8 0x00008558 > > 0x000086c8 0x00000000 0x2003c0e0: 0x00000000 > > 0x2003d000 0x00000000 0x00000000 0x2003c0f0: > > 0x00000000 0x2003c0f0 0x2003b180 0x00000007 > > > > If I continue to stepi from here, it will fault at f4... > > > > This looks like a stack smash issue as the lr we pop off the stack > > is incorrect.. > > So, forgot I could set a watchpoint on the stack address, so I did: > (gdb) c > Continuing. > Watchpoint 9: *0xbfffecc8 > > Old value = 0x2001f584 > New value = 0x2003c000 > 0x20019960 in donelist_check (dlp=0xbfffed08, obj=0x2003c000) > at /usr/src.avila/libexec/rtld-elf/rtld.c:1380 > 1380 dlp->objs[dlp->num_used++] = obj; > > I tracked dlp, and it's the donelist pointer, and it is allocated > from symlook_default via donelist_init at the top of the function: > #define donelist_init(dlp) \ > ((dlp)->objs = alloca(obj_count * sizeof (dlp)->objs[0]), \ > assert((dlp)->objs != NULL), \ > (dlp)->num_alloc = obj_count, \ > (dlp)->num_used = 0) > > Hmm... since obj_count is a global, and we are in a possibly > threaded environment, we should probably move assigning num_alloc > before the alloca, and then use num_alloc instead of obj_count just > to be safe... but taht won't be the issue here, as num_used is 0 > in my case... > > I've looked at the assembly for donelist_init for both the working > and non-working case, and besides an extra store in the good version, > which I think is just because of the unoptimized code, things look > the same to me... I suspect it's more likely the working version is not making assumptions on the stack alignment, where the broken one is. Andrew From owner-freebsd-arm@FreeBSD.ORG Sat Jun 21 16:19:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB06DAA4 for ; Sat, 21 Jun 2014 16:19:21 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id A11672F3C for ; Sat, 21 Jun 2014 16:19:21 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 7C2AF5DEBC for ; Sat, 21 Jun 2014 16:19:20 +0000 (UTC) Date: Sat, 21 Jun 2014 17:19:14 +0100 From: Andrew Turner To: freebsd-arm@freebsd.org Subject: Re: Removing partially supported SoCs Message-ID: <20140621171914.26950010@bender.Home> In-Reply-To: <20140616095914.21757989@bender.Home> References: <20140616095914.21757989@bender.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 16:19:21 -0000 On Mon, 16 Jun 2014 09:59:14 +0100 Andrew Turner wrote: > I'm looking at removing support for SoCs where we have code but nobody > appears to be supporting it. Having this extra code means we have to > update it, but are unable to test the changes as it may not boot. > > To begin with I'm planning on removing Tegra 2 and OMAP3 code. > > The Tegra 2 is quite old and, as far as I know, never got to single > user mode. There is only one kernel config that builds the code. > Along with this the SoC dependent code is very minimal as it only > includes what appears to be the minimum code to build and start > booting the kernel. > > For OMAP3 we don't have the std.omap3 or files.omap3 files, and > therefore no kernel config. The omap3 directory only contains a file > with the SoC specific register addresses. It also makes other Ti > drivers more comples as they need to check which SoC they are running > on. > > Removing OMAP3 will not affect the other Ti SoCs, i.e. OMAP4 and > AM35xx. > > If anyone feels they wish to keep support for either of these SoCs > they will need to work to improve the support of both getting the SoC > booting to a useful state, and to help keep the code up to date with > other kernel changes, i.e. to not leave when the SoC is booting to > multi-user mode. > > If I get no complaints I'm planning on removing them this weekend. > After this other SoCs will be evaluated to determine if we should > still support them. I've had a little intrest in the OMAP3 support for the BeagleBoard-xM and Gumstix Overo boards. I will leave it in for now and remove only the Tegra 2 code. For people interested in either of these boards, or another OMAP3 board I would suggest you start working on bringing the support up to a level where we can boot on these boards otherwise the code will come up for removal again. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Jun 22 05:16:48 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF76820A for ; Sun, 22 Jun 2014 05:16:47 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C4AAC254C for ; Sun, 22 Jun 2014 05:16:47 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5M5GjNG009838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jun 2014 22:16:45 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5M5GilH009837; Sat, 21 Jun 2014 22:16:44 -0700 (PDT) (envelope-from jmg) Date: Sat, 21 Jun 2014 22:16:44 -0700 From: John-Mark Gurney To: Andrew Turner Subject: Re: AVILA getting close! Message-ID: <20140622051644.GT31367@funkthat.com> Mail-Followup-To: Andrew Turner , arm@FreeBSD.org References: <20140618225808.GG31367@funkthat.com> <20140620151023.GZ31367@funkthat.com> <20140620200827.1c33c7da@bender.Home> <20140621010804.GD31367@funkthat.com> <20140621070827.GJ31367@funkthat.com> <20140621170129.76e62c27@bender.Home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140621170129.76e62c27@bender.Home> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 21 Jun 2014 22:16:46 -0700 (PDT) Cc: arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 05:16:48 -0000 Andrew Turner wrote this message on Sat, Jun 21, 2014 at 17:01 +0100: > On Sat, 21 Jun 2014 00:08:28 -0700 > John-Mark Gurney wrote: > > I've looked at the assembly for donelist_init for both the working > > and non-working case, and besides an extra store in the good version, > > which I think is just because of the unoptimized code, things look > > the same to me... > I suspect it's more likely the working version is not making > assumptions on the stack alignment, where the broken one is. So, is there a way you can fix up the rtld tramp in rtld-elf/arm/rtld_start.S so that the stack can be traced through? Right now, when I'm in the plt code, I can get the userland stack, but once I end up in _rtld_bind_start, I can't get a trace back past the got which is making this next to imposible to debug.. (gdb) stepi 0x200774d4 in .plt () from /lib/libc.so.7 2: $pc = 0x200774d4 1: $sp = 0xbffff24c (gdb) bt #0 0x200774d4 in .plt () from /lib/libc.so.7 #1 0x20171804 in getenv (name=0x20184a98 "MALLOC_CONF") at /usr/src.avila/lib/libc/stdlib/getenv.c:144 #2 0x200f23b0 in malloc_init_hard () at jemalloc_jemalloc.c:464 #3 0x200f34d8 in jemalloc_constructor () at jemalloc_jemalloc.c:296 #4 0x2001dee0 in objlist_call_init (list=, lockstate=0xbffffb40) at /usr/src.avila/libexec/rtld-elf/rtld.c:2385 #5 0x200212b8 in $a () at /usr/src.avila/libexec/rtld-elf/rtld.c:640 #6 0x200212b8 in $a () at /usr/src.avila/libexec/rtld-elf/rtld.c:640 (gdb) stepi _rtld_bind_start () at /usr/src.avila/libexec/rtld-elf/arm/rtld_start.S:80 80 stmdb sp!,{r0-r4,sl,fp} 2: $pc = 0x20018f84 1: $sp = 0xbffff24c Current language: auto; currently asm (gdb) bt #0 _rtld_bind_start () at /usr/src.avila/libexec/rtld-elf/arm/rtld_start.S:80 #1 0x2019e0c0 in .got () from /lib/libc.so.7 #2 0x2019e0c0 in .got () from /lib/libc.so.7 Poof, now I have no clue where I am anymore... :( Or at least provide an option (enabled by -DDEBUG) to provide it.. Well, I did manage to work this out.. and I feel a little stupid since I saw this name and thought it a bit weird.. I believe that gcc is is not making sure that the stack is aligned when calling __aeabi_read_tp... I believe that gcc does not think that it is a full function, but it does go through relocation... If you look at the disassembly of the sob function in newsyslog, you'll see that it will leave the stack unaligned off the bat: 9f58: e92d4030 push {r4, r5, lr} and setting a breakpoint there confirms this: (gdb) c Continuing. Breakpoint 8, sob ( p=0xbfffef20 "/var/log/all.log\t\t\t600 7\t *\t@T00 J\n") at /usr/src.avila/usr.sbin/newsyslog/newsyslog.c:2400 2400 while (p && *p && isspace(*p)) 2: $pc = 0x9f5c 1: $sp = 0xbfffeeec So, gcc is generating broken code... Can you please fix this? Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Jun 22 07:26:26 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78E85A1F for ; Sun, 22 Jun 2014 07:26:26 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E81C2CD4 for ; Sun, 22 Jun 2014 07:26:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5M7QQU2009497 for ; Sun, 22 Jun 2014 08:26:26 +0100 (BST) (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 191261] New: [raspberry pi] no cursor on latest -HEAD Date: Sun, 22 Jun 2014 07:26:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 07:26:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191261 Bug ID: 191261 Summary: [raspberry pi] no cursor on latest -HEAD Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: adrian@freebsd.org There's no cursor visible on the raspberry pi console. SVN version: r267601 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun Jun 22 12:30:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 006FC6BD for ; Sun, 22 Jun 2014 12:30:02 +0000 (UTC) Received: from smtp1.hushmail.com (smtp1.hushmail.com [65.39.178.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "Self-signed" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D94F62197 for ; Sun, 22 Jun 2014 12:30:02 +0000 (UTC) Received: from smtp1.hushmail.com (localhost [127.0.0.1]) by smtp1.hushmail.com (Postfix) with SMTP id 18D6E400DE for ; Sun, 22 Jun 2014 11:56:34 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sun, 22 Jun 2014 11:56:34 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id E847320185; Sun, 22 Jun 2014 11:56:33 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 22 Jun 2014 04:56:33 -0700 To: freebsd-arm@freebsd.org Subject: build world cross compile From: falcon17@hushmail.com Message-Id: <20140622115633.E847320185@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 12:30:03 -0000 I would like to build 10-STABLE for arm on my amd64. I found some instructions here -https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD(i assume the third CPUTYPE example should be KERNCONF instead?) all looks good, except that make.conf and src.conf examples do not say a peep about arm! What are the right way of specifying these targets? Do I need to build a special compiler before starting? Thanks! From owner-freebsd-arm@FreeBSD.ORG Sun Jun 22 15:53:30 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9F005B6 for ; Sun, 22 Jun 2014 15:53:30 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 855AF203B for ; Sun, 22 Jun 2014 15:53:30 +0000 (UTC) Received: from bender.lan (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 852A05DEC1; Sun, 22 Jun 2014 15:53:28 +0000 (UTC) Date: Sun, 22 Jun 2014 16:53:21 +0100 From: Andrew Turner To: John-Mark Gurney Subject: Re: AVILA getting close! Message-ID: <20140622165321.04c0949a@bender.lan> In-Reply-To: <20140622051644.GT31367@funkthat.com> References: <20140618225808.GG31367@funkthat.com> <20140620151023.GZ31367@funkthat.com> <20140620200827.1c33c7da@bender.Home> <20140621010804.GD31367@funkthat.com> <20140621070827.GJ31367@funkthat.com> <20140621170129.76e62c27@bender.Home> <20140622051644.GT31367@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 15:53:30 -0000 On Sat, 21 Jun 2014 22:16:44 -0700 John-Mark Gurney wrote: > Andrew Turner wrote this message on Sat, Jun 21, 2014 at 17:01 +0100: > > On Sat, 21 Jun 2014 00:08:28 -0700 > > John-Mark Gurney wrote: > > > I've looked at the assembly for donelist_init for both the working > > > and non-working case, and besides an extra store in the good > > > version, which I think is just because of the unoptimized code, > > > things look the same to me... > > I suspect it's more likely the working version is not making > > assumptions on the stack alignment, where the broken one is. > > So, is there a way you can fix up the rtld tramp in > rtld-elf/arm/rtld_start.S so that the stack can be traced through? > > Right now, when I'm in the plt code, I can get the userland stack, > but once I end up in _rtld_bind_start, I can't get a trace back > past the got which is making this next to imposible to debug.. > > (gdb) stepi > 0x200774d4 in .plt () from /lib/libc.so.7 > 2: $pc = 0x200774d4 > 1: $sp = 0xbffff24c > (gdb) bt > #0 0x200774d4 in .plt () from /lib/libc.so.7 > #1 0x20171804 in getenv (name=0x20184a98 "MALLOC_CONF") > at /usr/src.avila/lib/libc/stdlib/getenv.c:144 > #2 0x200f23b0 in malloc_init_hard () at jemalloc_jemalloc.c:464 > #3 0x200f34d8 in jemalloc_constructor () at jemalloc_jemalloc.c:296 > #4 0x2001dee0 in objlist_call_init (list=, > lockstate=0xbffffb40) > at /usr/src.avila/libexec/rtld-elf/rtld.c:2385 #5 0x200212b8 in $a > () at /usr/src.avila/libexec/rtld-elf/rtld.c:640 #6 0x200212b8 in $a > () at /usr/src.avila/libexec/rtld-elf/rtld.c:640 (gdb) stepi > _rtld_bind_start () > at /usr/src.avila/libexec/rtld-elf/arm/rtld_start.S:80 > 80 stmdb sp!,{r0-r4,sl,fp} 2: $pc = 0x20018f84 > 1: $sp = 0xbffff24c > Current language: auto; currently asm > (gdb) bt > #0 _rtld_bind_start () > at /usr/src.avila/libexec/rtld-elf/arm/rtld_start.S:80 #1 0x2019e0c0 > in .got () from /lib/libc.so.7 #2 0x2019e0c0 in .got () > from /lib/libc.so.7 > > Poof, now I have no clue where I am anymore... :( Or at least > provide an option (enabled by -DDEBUG) to provide it.. > > Well, I did manage to work this out.. and I feel a little stupid since > I saw this name and thought it a bit weird.. I believe that gcc is > is not making sure that the stack is aligned when calling > __aeabi_read_tp... I believe that gcc does not think that it is a > full function, but it does go through relocation... If you look at the > disassembly of the sob function in newsyslog, you'll see that it will > leave the stack unaligned off the bat: > 9f58: e92d4030 push {r4, r5, lr} > > and setting a breakpoint there confirms this: > (gdb) c > Continuing. > > Breakpoint 8, sob ( > p=0xbfffef20 "/var/log/all.log\t\t\t600 7\t *\t@T00 J\n") > at /usr/src.avila/usr.sbin/newsyslog/newsyslog.c:2400 > 2400 while (p && *p && isspace(*p)) > 2: $pc = 0x9f5c > 1: $sp = 0xbfffeeec > > So, gcc is generating broken code... Can you please fix this? > > Thanks. > We tracked this down to a problem where, normally the stack is aligned to an 8-byte boundary, however in leaf functions the stack may be aligned to a 4-byte boundary. The problem is gcc and upstream clang/llvm don't detect that functions that use thread local storage as non-leaf. Functions that use tls call __aeabi_read_tp(). As this is implemented in libc it requires the symbol to be resolved first, however as the compiler doesn't see this as a function call it may align the stack to a non-8-byte address. I have a fix for this that has been tested on armeb. I'll commit it soon, after I've tested it on other platforms. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Jun 22 15:58:32 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C44D64E for ; Sun, 22 Jun 2014 15:58:32 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5295D2056 for ; Sun, 22 Jun 2014 15:58:31 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wyk9w-000N52-DX; Sun, 22 Jun 2014 15:58:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5MFwKLr001310; Sun, 22 Jun 2014 09:58:20 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18BD1KaTQpumX9AtquJZBJb Subject: Re: build world cross compile From: Ian Lepore To: falcon17@hushmail.com In-Reply-To: <20140622115633.E847320185@smtp.hushmail.com> References: <20140622115633.E847320185@smtp.hushmail.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 22 Jun 2014 09:58:19 -0600 Message-ID: <1403452699.20883.290.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 15:58:32 -0000 On Sun, 2014-06-22 at 04:56 -0700, falcon17@hushmail.com wrote: > I would like to build 10-STABLE for arm on my amd64. I found some > instructions here > -https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD(i > assume the third CPUTYPE example should be KERNCONF instead?) > all looks good, except that make.conf and src.conf examples do not say > a peep about arm! What are the right way of specifying these targets? > Do I need to build a special compiler before starting? > Thanks! Assuming that your /etc/make.conf and src.conf are empty, all you need to do to crossbuild for arm is: make builworld TARGET_ARCH=arm make buildkernel TARGET_ARCH=arm KERNCONF=whatever Use armv6 for the target arch if the target is a v6 or v7 chipset. There's no need to set CPUTYPE at all. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jun 23 00:09:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 723F3DB0 for ; Mon, 23 Jun 2014 00:09:09 +0000 (UTC) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08FBF2429 for ; Mon, 23 Jun 2014 00:09:08 +0000 (UTC) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.14.8/8.14.8) with ESMTP id s5N094NN085076 for ; Mon, 23 Jun 2014 02:09:04 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: "freebsd-arm@freebsd.org" Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Mon, 23 Jun 2014 02:09:03 +0200 (CEST) Message-ID: <449b4d3ca9.7f48a77c@mail.schwarzes.net> In-Reply-To: References: <44921fa0c7.323fafd0@mail.schwarzes.net> <05FC286A-5306-4F77-A327-032F1F8126C0@fh-muenster.de> <4494a59023a.2da811a1@mail.schwarzes.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: FreeBSD doesn't boot anymore on RPi MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Mon, 23 Jun 2014 02:09:04 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 00:09:09 -0000 On 19.06.14, Jia-Shiun Li wrote: > On Wed, Jun 18, 2014 at 7:00 AM, Andreas Schwarz wrote: >> On 17.06.14, Michael Tuexen wrote: >>> Fixed in >>> http://svnweb.freebsd.org/changeset/base/267597 >> >> Ok, thank you, will try it. >> > > Tested ok with r267607 on RPi. Thank you! Can also confirm. Compiled and installed r267600 (kernel, world) directly at the RPi. Regards Andreas From owner-freebsd-arm@FreeBSD.ORG Mon Jun 23 07:14:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 009F1580; Mon, 23 Jun 2014 07:14:29 +0000 (UTC) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [IPv6:2a02:6b8:0:801::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A262D25D7; Mon, 23 Jun 2014 07:14:29 +0000 (UTC) Received: from web5j.yandex.ru (web5j.yandex.ru [5.45.198.46]) by forward12.mail.yandex.net (Yandex) with ESMTP id B752CC20E9F; Mon, 23 Jun 2014 11:14:24 +0400 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web5j.yandex.ru (Yandex) with ESMTP id 28CF2268019B; Mon, 23 Jun 2014 11:14:24 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1403507664; bh=ye1+VqaglN7jXXpWMy2PakwW3aCe+/eWQr96cS47Ulw=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=tY7ntb6mJOypEYatJatJu5h14WDz4rvCLhxmXBeRzKtP7npbTOTX2EccwvYTVp1FR 77Yzazt2W3jO7KACaK0gXhGCIVbibusOVGXeGhcmEECcDfgrEmonXVL7rsmxXFZoT+ p8ZD3eyWmtHjb/I64A2YLiQxA4JL+MaWseNlnL0w= Received: from adsl-71-135-98-2.dsl.pltn13.pacbell.net (adsl-71-135-98-2.dsl.pltn13.pacbell.net [71.135.98.2]) by web5j.yandex.ru with HTTP; Mon, 23 Jun 2014 11:14:23 +0400 From: Stepan Dyatkovskiy Envelope-From: stpworld@yandex.ru To: Ian Lepore , Aleksandr Rybalko In-Reply-To: <1403308620.20883.288.camel@revolution.hippie.lan> References: <53A3619C.3020505@narod.ru> <776BC360-5D2F-435C-B2B0-38449D4AB56D@bsdimp.com> <1403230772.20883.281.camel@revolution.hippie.lan> <0eac2533-d4bb-4bc6-9ba1-3dae40aa4360@email.android.com> <1403308620.20883.288.camel@revolution.hippie.lan> Subject: Re: locore.S and debugging initial stages of kernel MIME-Version: 1.0 Message-Id: <188111403507663@web5j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 23 Jun 2014 11:14:23 +0400 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: "freebsd-arm@FreeBSD.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 07:14:30 -0000 Thank you guys! Currently I have to stop my kernel survey. Though I've managed to updated cross-binutils and compile (and then launch) kernel with -mcpu=cortex-a9 option. Where I can read rules about, how to prepare and send patch to freebsd-arm community, so could share my experience? Thanks! -Stepan 21.06.2014, 03:57, "Ian Lepore" : > On Sat, 2014-06-21 at 01:18 +0300, Aleksandr Rybalko wrote: >> On 20 2014 . 08:23:01 GMT+03:00, Rui Paulo wrote: >>> On Jun 19, 2014, at 19:19, Ian Lepore wrote: >>>> I usually emit single chars by writing directly the console uart >>>> register. >>> I use exactly the same method, but your code looks much better. :-) >>> >>> -- >>> Rui Paulo >>> >>> _______________________________________________ >>> 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" >> Is not it would be better to just load txd address, instead of ORing 2-4 times? :-D >> WBW >> ------ >> Aleksandr Rybalko > > You mean store the value in memory somewhere, and then at runtime load a > pointer to where it's stored using only pc-relative instructions and > then loading the actual value using the pointer? Harder to write, the > code added for "quick debugging" would be more scattered, and it's > actually slower (not that performance really matters here). It could be > done as a 1-liner using "=VALUE" syntax, but chances are that turns into > mov,orr,orr. :) > > -- Ian > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Mon Jun 23 18:34:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22E3918E for ; Mon, 23 Jun 2014 18:34:47 +0000 (UTC) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "Self-signed" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 05F292659 for ; Mon, 23 Jun 2014 18:34:47 +0000 (UTC) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id D429B604C3 for ; Mon, 23 Jun 2014 17:59:06 +0000 (UTC) Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP; Mon, 23 Jun 2014 17:59:06 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 8AB87203AB; Mon, 23 Jun 2014 17:59:06 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 23 Jun 2014 10:59:06 -0700 To: "Ian Lepore" Subject: Re: build world cross compile From: falcon17@hushmail.com In-Reply-To: <1403452699.20883.290.camel@revolution.hippie.lan> References: <20140622115633.E847320185@smtp.hushmail.com> <1403452699.20883.290.camel@revolution.hippie.lan> Message-Id: <20140623175906.8AB87203AB@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:34:47 -0000 Worked great. thanks! On June 22, 2014 at 8:58 AM, "Ian Lepore" wrote:On Sun, 2014-06-22 at 04:56 -0700, falcon17@hushmail.com wrote: > I would like to build 10-STABLE for arm on my amd64. I found some > instructions here > -https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD(i > assume the third CPUTYPE example should be KERNCONF instead?) > all looks good, except that make.conf and src.conf examples do not say > a peep about arm! What are the right way of specifying these targets? > Do I need to build a special compiler before starting? > Thanks! Assuming that your /etc/make.conf and src.conf are empty, all you need to do to crossbuild for arm is: make builworld TARGET_ARCH=arm make buildkernel TARGET_ARCH=arm KERNCONF=whatever Use armv6 for the target arch if the target is a v6 or v7 chipset. There's no need to set CPUTYPE at all. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jun 23 22:44:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7AF7C75; Mon, 23 Jun 2014 22:44:29 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A05E2DAE; Mon, 23 Jun 2014 22:44:29 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id q59so7751174wes.40 for ; Mon, 23 Jun 2014 15:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2PzU+UREL0fw6riva/9Ox7FINRm8T6mQLb2BoVjwLRY=; b=OAPtKOmpHPOEiaaa5bbsGQMP/iznyP2JsRIkEgOA9aTYGTPYTQCx0EgqlhFvcF/bX1 GMfJSWFvZ+kBirnelVg1f1yN+bPoJeg4j0QUpEbL8jCjWgz2EcSfvEvRl27T/bXNpwbf U0bgWRQRV1h6bs81R3ijn4Df8aBfdX2b1txPWiFwSYq1HInR23rs4tEbv3xfvKU+CJ2A BdvGAIfYhfIwY8YHRGAImV3cjK+fxb5A2G0kw59gRcrc38Zi+1dcDJG7Nt1/7UqhMBxH 3rFBvfF93/zLK6UQ2MRJDk31JzxuSLY7QoUbhT0/q4L7rAdAKc5vksQnqdHuKF0mIpsf 1wiw== MIME-Version: 1.0 X-Received: by 10.194.92.177 with SMTP id cn17mr18585857wjb.71.1403563467495; Mon, 23 Jun 2014 15:44:27 -0700 (PDT) Received: by 10.216.23.1 with HTTP; Mon, 23 Jun 2014 15:44:27 -0700 (PDT) In-Reply-To: <20140621140300.GO31367@funkthat.com> References: <1403193531.20883.269.camel@revolution.hippie.lan> <20140621140300.GO31367@funkthat.com> Date: Tue, 24 Jun 2014 00:44:27 +0200 Message-ID: Subject: Re: Strange slowdown of zlib. From: Magnus Nilsson To: John-Mark Gurney , freebsd-embedded@freebsd.org, freebsd-arm Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:44:30 -0000 On Sat, Jun 21, 2014 at 4:03 PM, John-Mark Gurney wrote: > Magnus Nilsson wrote this message on Sat, Jun 21, 2014 at 14:13 +0200: >> While e.g. cat or md5 of an executable affects its speed, e.g. cp does not. >> Could there be some read access that's unaffected by your patches? > > I believe that cp uses mmap instead of the read syscall like cat and > md5... So this may be the case... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." mmap() seems unaffected, well spotted. Not sure if it would be reasonable to use that fact for a workaround? I've done more patching and testing. Mark Tinguely's conservative, unofficial patch http://lists.freebsd.org/pipermail/freebsd-arm/2010-November/002635.html does not fix the issue. Grzegorz Bernacki's proof-of-concept patch http://lists.freebsd.org/pipermail/freebsd-arm/2010-March/002270.html /does/ fix the issue! But what's the potential downside? Debugging issues, as suggested in http://lists.freebsd.org/pipermail/freebsd-arm/2010-March/002290.html ? Performance issues? Something worse? I've looked at later releases (9.3) for backporting, but can't find anything that that handles PVF_EXEC as a special case like Mark and Grzegorz. From owner-freebsd-arm@FreeBSD.ORG Tue Jun 24 19:46:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D98D6AE7 for ; Tue, 24 Jun 2014 19:46:54 +0000 (UTC) Received: from nm27-vm5.access.bullet.mail.bf1.yahoo.com (nm27-vm5.access.bullet.mail.bf1.yahoo.com [216.109.115.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7881824F8 for ; Tue, 24 Jun 2014 19:46:53 +0000 (UTC) Received: from [66.196.81.162] by nm27.access.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jun 2014 19:44:17 -0000 Received: from [98.138.226.243] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jun 2014 19:44:17 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 24 Jun 2014 19:44:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1403639057; bh=WeUZOpDnK/sfD+J3vn7qL9jjzRy9HxzpqxWhHY5Cosk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; b=kOdZg0cbqqEKIlpcG1IuAPkKvEb4QbszCPM3Em4t3L/0HdjgyCHiLvlk2IvCXM6fdqgv2THWHcZJqOVrKs9idlxw3gRMZ/XgO+UZ1j0dh8XYf8VPhypLirl303w1dK4UU/9w4+TYRFlepJhzYjhjxvYb/huRTOgxajSDtkpKpo8= X-Yahoo-Newman-Id: 118473.12067.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tFiaCTkVM1mrZjmYWOV6bLOSNxAzJ64Aq9Mw0KdojcY_h0l cTTdXlvUaUtYce2QFLfmOxR76duDGI1bfTUQggKeD0JLz4n8M6F.ZkutZp8x 2BZQ9CmhwuQAKL7vteh4N5O8WGgBzryXdUlGcPOHMCdctb7Fuu.NkVVAjxF2 K.IhLAFLXHR11.1IZerXazNyfLrH2CyEb5eO_GzBD3Mm7O7u1hvmY43WBi51 GJsxh5d7k0.q4iP7fcrgFvRMFxMOd5swiRx7Fs_C5yJU9BGOSQoKH1QpTM8E 3aikUEhdgUchEck7Ci2QbJWpY_DnUM6wd7fLBfzGhANXdjpEopkU_uIPp6co s86slaBBgJuqOazb0v33Ap1EW35_.R30pbep5dne778SQtjnroYbczRpABlD AZBjU23clN2XQeaLNmc5Djv.ctZc05vcyqqOZcrparUuer9AfiqB_uwx1Y.C z4XBvXfyvJW6uk6z5ujPgVupCwQXv8hEUL1oyntp8cxjKPeOBlpr7gX7vzsy BcUFAnWnuCZDWUwZMvQEj1KnUt519tAZr.eZzjFGpIYOCq6lEEOkpqTf1 X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.167.11 with plain [98.138.31.74]) by smtp114.sbc.mail.ne1.yahoo.com with SMTP; 24 Jun 2014 19:44:17 +0000 UTC Message-ID: <53A9D50F.8030604@sbcglobal.net> Date: Tue, 24 Jun 2014 12:44:15 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm Subject: Some bug fixes for Zynq Ethernet Content-Type: multipart/mixed; boundary="------------030800060005090008020207" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:46:54 -0000 This is a multi-part message in MIME format. --------------030800060005090008020207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, all. I have some bug fixes for the Zynq/Zedboard Ethernet driver that have been laying around for a while and that I'm hoping to get committed. The main bug is that the driver doesn't handle media speed changes correctly so it can only connect to 1G switches. To fix this bug, the driver needs to be able to change the frequency of the ethernet core's reference clock. Because I am trying to keep if_cgem.c platform-independent, I've created a function called cgem_set_ref_clk() that a platform can override with a platform-specific function for changing the clock. This should make it easier if the Cadence GEM block shows up in other SoCs. Where it is a bit ugly is that the driver doesn't know which of two ethernet cores it controls so I created a device-tree property called "ref-clock-num" so that the platform-specific code knows which reference clock to change. I am open to other ideas on how to do this. Comments? I have a few other minor fixes and enhancements that I'll put in a different patch. Thanks, -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net --------------030800060005090008020207 Content-Type: text/plain; charset=UTF-8; name="patch.media-bug.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch.media-bug.txt" Index: sys/arm/xilinx/zy7_slcr.c =================================================================== --- sys/arm/xilinx/zy7_slcr.c (revision 267546) +++ sys/arm/xilinx/zy7_slcr.c (working copy) @@ -71,20 +71,22 @@ #define ZSLCR_UNLOCK(sc) mtx_unlock(&(sc)->sc_mtx) #define ZSLCR_LOCK_INIT(sc) \ mtx_init(&(sc)->sc_mtx, device_get_nameunit((sc)->dev), \ - "zy7_slcr", MTX_SPIN) + "zy7_slcr", MTX_DEF) #define ZSLCR_LOCK_DESTROY(_sc) mtx_destroy(&_sc->sc_mtx); #define RD4(sc, off) (bus_read_4((sc)->mem_res, (off))) #define WR4(sc, off, val) (bus_write_4((sc)->mem_res, (off), (val))) +#define ZYNQ_DEFAULT_PS_CLK_FREQUENCY 33333333 /* 33.3 Mhz */ + SYSCTL_NODE(_hw, OID_AUTO, zynq, CTLFLAG_RD, 0, "Xilinx Zynq-7000"); static char zynq_bootmode[64]; SYSCTL_STRING(_hw_zynq, OID_AUTO, bootmode, CTLFLAG_RD, zynq_bootmode, 0, "Zynq boot mode"); -static char zynq_pssid[80]; +static char zynq_pssid[100]; SYSCTL_STRING(_hw_zynq, OID_AUTO, pssid, CTLFLAG_RD, zynq_pssid, 0, "Zynq PSS IDCODE"); @@ -92,6 +94,22 @@ SYSCTL_INT(_hw_zynq, OID_AUTO, reboot_status, CTLFLAG_RD, &zynq_reboot_status, 0, "Zynq REBOOT_STATUS register"); +static int ps_clk_frequency; +SYSCTL_INT(_hw_zynq, OID_AUTO, ps_clk_frequency, CTLFLAG_RD, &ps_clk_frequency, + 0, "Zynq PS_CLK Frequency"); + +static int io_pll_frequency; +SYSCTL_INT(_hw_zynq, OID_AUTO, io_pll_frequency, CTLFLAG_RD, &io_pll_frequency, + 0, "Zynq IO PLL Frequency"); + +static int arm_pll_frequency; +SYSCTL_INT(_hw_zynq, OID_AUTO, arm_pll_frequency, CTLFLAG_RD, + &arm_pll_frequency, 0, "Zynq ARM PLL Frequency"); + +static int ddr_pll_frequency; +SYSCTL_INT(_hw_zynq, OID_AUTO, ddr_pll_frequency, CTLFLAG_RD, + &ddr_pll_frequency, 0, "Zynq DDR PLL Frequency"); + static void zy7_slcr_unlock(struct zy7_slcr_softc *sc) { @@ -189,6 +207,54 @@ ZSLCR_UNLOCK(sc); } +/* Override cgem_set_refclk() in gigabit ethernet driver + * (sys/dev/cadence/if_cgem.c). This function is called to + * request a change in the gem's reference clock speed. + */ +int +cgem_set_ref_clk(int unit, int frequency) +{ + struct zy7_slcr_softc *sc = zy7_slcr_softc_p; + int div0, div1; + + if (!sc) + return (-1); + + /* Find suitable divisor pairs. Round result to nearest khz + * to test for match. + */ + for (div1 = 1; div1 <= ZY7_SLCR_GEM_CLK_CTRL_DIVISOR1_MAX; div1++) { + div0 = (io_pll_frequency + div1 * frequency / 2) / + div1 / frequency; + if (div0 > 0 && div0 <= ZY7_SLCR_GEM_CLK_CTRL_DIVISOR_MAX && + ((io_pll_frequency / div0 / div1) + 500) / 1000 == + (frequency + 500) / 1000) + break; + } + + if (div1 > ZY7_SLCR_GEM_CLK_CTRL_DIVISOR1_MAX) + return (-1); + + ZSLCR_LOCK(sc); + + /* Unlock SLCR registers. */ + zy7_slcr_unlock(sc); + + /* Modify GEM reference clock. */ + WR4(sc, unit ? ZY7_SLCR_GEM1_CLK_CTRL : ZY7_SLCR_GEM0_CLK_CTRL, + (div1 << ZY7_SLCR_GEM_CLK_CTRL_DIVISOR1_SHIFT) | + (div0 << ZY7_SLCR_GEM_CLK_CTRL_DIVISOR_SHIFT) | + ZY7_SLCR_GEM_CLK_CTRL_SRCSEL_IO_PLL | + ZY7_SLCR_GEM_CLK_CTRL_CLKACT); + + /* Lock SLCR registers. */ + zy7_slcr_lock(sc); + + ZSLCR_UNLOCK(sc); + + return (0); +} + static int zy7_slcr_probe(device_t dev) { @@ -208,8 +274,13 @@ { struct zy7_slcr_softc *sc = device_get_softc(dev); int rid; + phandle_t node; + pcell_t cell; uint32_t bootmode; uint32_t pss_idcode; + uint32_t arm_pll_ctrl; + uint32_t ddr_pll_ctrl; + uint32_t io_pll_ctrl; static char *bootdev_names[] = { "JTAG", "Quad-SPI", "NOR", "(3?)", "NAND", "SD Card", "(6?)", "(7?)" @@ -260,6 +331,53 @@ zynq_reboot_status = RD4(sc, ZY7_SLCR_REBOOT_STAT); + /* Derive PLL frequencies from PS_CLK. */ + node = ofw_bus_get_node(dev); + if (OF_getprop(node, "clock-frequency", &cell, sizeof(cell)) > 0) + ps_clk_frequency = fdt32_to_cpu(cell); + else + ps_clk_frequency = ZYNQ_DEFAULT_PS_CLK_FREQUENCY; + + arm_pll_ctrl = RD4(sc, ZY7_SLCR_ARM_PLL_CTRL); + ddr_pll_ctrl = RD4(sc, ZY7_SLCR_DDR_PLL_CTRL); + io_pll_ctrl = RD4(sc, ZY7_SLCR_IO_PLL_CTRL); + + /* Determine ARM PLL frequency. */ + if (((arm_pll_ctrl & ZY7_SLCR_PLL_CTRL_BYPASS_QUAL) == 0 && + (arm_pll_ctrl & ZY7_SLCR_PLL_CTRL_BYPASS_FORCE) != 0) || + ((arm_pll_ctrl & ZY7_SLCR_PLL_CTRL_BYPASS_QUAL) != 0 && + (bootmode & ZY7_SLCR_BOOT_MODE_PLL_BYPASS) != 0)) + /* PLL is bypassed. */ + arm_pll_frequency = ps_clk_frequency; + else + arm_pll_frequency = ps_clk_frequency * + ((arm_pll_ctrl & ZY7_SLCR_PLL_CTRL_FDIV_MASK) >> + ZY7_SLCR_PLL_CTRL_FDIV_SHIFT); + + /* Determine DDR PLL frequency. */ + if (((ddr_pll_ctrl & ZY7_SLCR_PLL_CTRL_BYPASS_QUAL) == 0 && + (ddr_pll_ctrl & ZY7_SLCR_PLL_CTRL_BYPASS_FORCE) != 0) || + ((ddr_pll_ctrl & ZY7_SLCR_PLL_CTRL_BYPASS_QUAL) != 0 && + (bootmode & ZY7_SLCR_BOOT_MODE_PLL_BYPASS) != 0)) + /* PLL is bypassed. */ + ddr_pll_frequency = ps_clk_frequency; + else + ddr_pll_frequency = ps_clk_frequency * + ((ddr_pll_ctrl & ZY7_SLCR_PLL_CTRL_FDIV_MASK) >> + ZY7_SLCR_PLL_CTRL_FDIV_SHIFT); + + /* Determine IO PLL frequency. */ + if (((io_pll_ctrl & ZY7_SLCR_PLL_CTRL_BYPASS_QUAL) == 0 && + (io_pll_ctrl & ZY7_SLCR_PLL_CTRL_BYPASS_FORCE) != 0) || + ((io_pll_ctrl & ZY7_SLCR_PLL_CTRL_BYPASS_QUAL) != 0 && + (bootmode & ZY7_SLCR_BOOT_MODE_PLL_BYPASS) != 0)) + /* PLL is bypassed. */ + io_pll_frequency = ps_clk_frequency; + else + io_pll_frequency = ps_clk_frequency * + ((io_pll_ctrl & ZY7_SLCR_PLL_CTRL_FDIV_MASK) >> + ZY7_SLCR_PLL_CTRL_FDIV_SHIFT); + /* Lock SLCR registers. */ zy7_slcr_lock(sc); Index: sys/arm/xilinx/zy7_slcr.h =================================================================== --- sys/arm/xilinx/zy7_slcr.h (revision 267546) +++ sys/arm/xilinx/zy7_slcr.h (working copy) @@ -126,6 +126,18 @@ #define ZY7_SLCR_GEM1_RCLK_CTRL 0x013c #define ZY7_SLCR_GEM0_CLK_CTRL 0x0140 #define ZY7_SLCR_GEM1_CLK_CTRL 0x0144 +#define ZY7_SLCR_GEM_CLK_CTRL_DIVISOR1_MASK (0x3f<<20) +#define ZY7_SLCR_GEM_CLK_CTRL_DIVISOR1_SHIFT 20 +#define ZY7_SLCR_GEM_CLK_CTRL_DIVISOR1_MAX 0x3f +#define ZY7_SLCR_GEM_CLK_CTRL_DIVISOR_MASK (0x3f<<8) +#define ZY7_SLCR_GEM_CLK_CTRL_DIVISOR_SHIFT 8 +#define ZY7_SLCR_GEM_CLK_CTRL_DIVISOR_MAX 0x3f +#define ZY7_SLCR_GEM_CLK_CTRL_SRCSEL_MASK (7<<4) +#define ZY7_SLCR_GEM_CLK_CTRL_SRCSEL_IO_PLL (0<<4) +#define ZY7_SLCR_GEM_CLK_CTRL_SRCSEL_ARM_PLL (2<<4) +#define ZY7_SLCR_GEM_CLK_CTRL_SRCSEL_DDR_PLL (3<<4) +#define ZY7_SLCR_GEM_CLK_CTRL_SRCSEL_EMIO_CLK (4<<4) +#define ZY7_SLCR_GEM_CLK_CTRL_CLKACT 1 #define ZY7_SLCR_SMC_CLK_CTRL 0x0148 #define ZY7_SLCR_LQSPI_CLK_CTRL 0x014c #define ZY7_SLCR_SDIO_CLK_CTRL 0x0150 @@ -274,6 +286,7 @@ #ifdef _KERNEL extern void zy7_slcr_preload_pl(void); -extern void zy7_slcr_postload_pl(int); +extern void zy7_slcr_postload_pl(int en_level_shifters); +extern int cgem_set_ref_clk(int unit, int frequency); #endif #endif /* _ZY7_SLCR_H_ */ Index: sys/boot/fdt/dts/arm/zedboard.dts =================================================================== --- sys/boot/fdt/dts/arm/zedboard.dts (revision 267806) +++ sys/boot/fdt/dts/arm/zedboard.dts (working copy) @@ -63,6 +63,7 @@ slcr: slcr@7000 { compatible = "xlnx,zy7_slcr"; reg = <0x0 0x1000>; + clock-frequency = <33333333>; // 33Mhz PS_CLK }; // Interrupt controller @@ -175,6 +176,7 @@ reg = <0xb000 0x1000>; interrupts = <54 55>; interrupt-parent = <&GIC>; + ref-clock-num = <0>; }; // SDIO Index: sys/dev/cadence/if_cgem.c =================================================================== --- sys/dev/cadence/if_cgem.c (revision 267546) +++ sys/dev/cadence/if_cgem.c (working copy) @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2012-2013 Thomas Skibo + * Copyright (c) 2012-2014 Thomas Skibo * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -108,6 +108,7 @@ void *intrhand; struct callout tick_ch; uint32_t net_ctl_shadow; + int ref_clk_num; u_char eaddr[6]; bus_dma_tag_t desc_dma_tag; @@ -149,6 +150,9 @@ #define CGEM_LOCK_DESTROY(sc) mtx_destroy(&(sc)->sc_mtx) #define CGEM_ASSERT_LOCKED(sc) mtx_assert(&(sc)->sc_mtx, MA_OWNED) +/* Allow platforms to optionally provide a way to set the reference clock. */ +int cgem_set_ref_clk(int unit, int frequency); + static devclass_t cgem_devclass; static int cgem_probe(device_t dev); @@ -707,47 +719,18 @@ CGEM_UNLOCK(sc); } -/* Respond to changes in media. */ static void -cgem_media_update(struct cgem_softc *sc, int active) -{ - uint32_t net_cfg; - - CGEM_ASSERT_LOCKED(sc); - - /* Update hardware to reflect phy status. */ - net_cfg = RD4(sc, CGEM_NET_CFG); - net_cfg &= ~(CGEM_NET_CFG_SPEED100 | CGEM_NET_CFG_GIGE_EN | - CGEM_NET_CFG_FULL_DUPLEX); - - if (IFM_SUBTYPE(active) == IFM_1000_T) - net_cfg |= (CGEM_NET_CFG_SPEED100 | CGEM_NET_CFG_GIGE_EN); - else if (IFM_SUBTYPE(active) == IFM_100_TX) - net_cfg |= CGEM_NET_CFG_SPEED100; - - if ((active & IFM_FDX) != 0) - net_cfg |= CGEM_NET_CFG_FULL_DUPLEX; - WR4(sc, CGEM_NET_CFG, net_cfg); -} - -static void cgem_tick(void *arg) { struct cgem_softc *sc = (struct cgem_softc *)arg; struct mii_data *mii; - int active; CGEM_ASSERT_LOCKED(sc); /* Poll the phy. */ if (sc->miibus != NULL) { mii = device_get_softc(sc->miibus); - active = mii->mii_media_active; mii_tick(mii); - if ((mii->mii_media_status & (IFM_ACTIVE | IFM_AVALID)) == - (IFM_ACTIVE | IFM_AVALID) && - active != mii->mii_media_active) - cgem_media_update(sc, mii->mii_media_active); } /* Next callout in one second. */ @@ -894,7 +884,6 @@ mii = device_get_softc(sc->miibus); mii_pollstat(mii); - cgem_media_update(sc, mii->mii_media_active); cgem_start_locked(sc->ifp); callout_reset(&sc->tick_ch, hz, cgem_tick, sc); @@ -1073,12 +1066,13 @@ { struct cgem_softc *sc = (struct cgem_softc *) ifp->if_softc; struct mii_data *mii; + int error; mii = device_get_softc(sc->miibus); CGEM_LOCK(sc); - mii_mediachg(mii); + error = mii_mediachg(mii); CGEM_UNLOCK(sc); - return (0); + return (error); } static void @@ -1148,7 +1142,61 @@ return (0); } +/* + * Overridable weak symbol cgem_set_ref_clk(). This allows platforms to + * provide a function to set the cgem's reference clock. + */ +static int __used +cgem_default_set_ref_clk(int unit, int frequency) +{ + return 0; +} +__weak_reference(cgem_default_set_ref_clk, cgem_set_ref_clk); + +static void +cgem_miibus_statchg(device_t dev) +{ + struct cgem_softc *sc; + struct mii_data *mii; + uint32_t net_cfg; + int ref_clk_freq; + + sc = device_get_softc(dev); + + mii = device_get_softc(sc->miibus); + + if ((mii->mii_media_status & IFM_AVALID) != 0) { + /* Update hardware to reflect phy status. */ + net_cfg = RD4(sc, CGEM_NET_CFG); + net_cfg &= ~(CGEM_NET_CFG_SPEED100 | CGEM_NET_CFG_GIGE_EN | + CGEM_NET_CFG_FULL_DUPLEX); + + switch (IFM_SUBTYPE(mii->mii_media_active)) { + case IFM_1000_T: + net_cfg |= (CGEM_NET_CFG_SPEED100 | + CGEM_NET_CFG_GIGE_EN); + ref_clk_freq = 125000000; + break; + case IFM_100_TX: + net_cfg |= CGEM_NET_CFG_SPEED100; + ref_clk_freq = 25000000; + break; + default: + ref_clk_freq = 2500000; + } + + if ((mii->mii_media_active & IFM_FDX) != 0) + net_cfg |= CGEM_NET_CFG_FULL_DUPLEX; + WR4(sc, CGEM_NET_CFG, net_cfg); + + /* Set the reference clock if necessary. */ + if (cgem_set_ref_clk(sc->ref_clk_num, ref_clk_freq)) + device_printf(dev, "could not set ref clk%d to %d.\n", + sc->ref_clk_num, ref_clk_freq); + } +} + static int cgem_probe(device_t dev) { @@ -1165,12 +1213,20 @@ { struct cgem_softc *sc = device_get_softc(dev); struct ifnet *ifp = NULL; + phandle_t node; + pcell_t cell; int rid, err; u_char eaddr[ETHER_ADDR_LEN]; sc->dev = dev; CGEM_LOCK_INIT(sc); + /* Get reference clock number and base divider from fdt. */ + node = ofw_bus_get_node(dev); + sc->ref_clk_num = 0; + if (OF_getprop(node, "ref-clock-num", &cell, sizeof(cell)) > 0) + sc->ref_clk_num = fdt32_to_cpu(cell); + /* Get memory resource. */ rid = 0; sc->mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, @@ -1364,6 +1414,7 @@ /* MII interface */ DEVMETHOD(miibus_readreg, cgem_miibus_readreg), DEVMETHOD(miibus_writereg, cgem_miibus_writereg), + DEVMETHOD(miibus_statchg, cgem_miibus_statchg), DEVMETHOD_END }; --------------030800060005090008020207-- From owner-freebsd-arm@FreeBSD.ORG Wed Jun 25 11:47:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D92682A9 for ; Wed, 25 Jun 2014 11:47:41 +0000 (UTC) Received: from eu1sys200aog120.obsmtp.com (eu1sys200aog120.obsmtp.com [207.126.144.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 397AE2D01 for ; Wed, 25 Jun 2014 11:47:40 +0000 (UTC) Received: from mail-we0-f177.google.com ([74.125.82.177]) (using TLSv1) by eu1sys200aob120.postini.com ([207.126.147.11]) with SMTP ID DSNKU6q2vc8xm7GKWKb3cCNQUzlfjFUSLMA5@postini.com; Wed, 25 Jun 2014 11:47:41 UTC Received: by mail-we0-f177.google.com with SMTP id u56so1839366wes.36 for ; Wed, 25 Jun 2014 04:47:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=tVWliFnMa8NwuXco8/Qqvbu1efNdirKVcKMLmu2pODI=; b=V0jViWHfqELF5ffHAGZ8OYBg20VizPaEG96UW9YKkmLDeicutlTvH68NdhOZO69jep 2HJzh1TO1/O82QOMqzoyUEK6Vd5djYC+4ufzmzB/w61TlDVi6x6pGdfzriBwJmpuf9ZR 4J7cEjAPqc17Gaw9Xe9ijxBZY7JYidI9wMgqvrGFc6VkjFuJvV42sQbghWGerIR3vlgz Ykgw8KJ2tNfQuvPU+cjmlk9UqQMQ4caCqVEVxbSmfJAPaUofry7l8MGYmxGBTPdA2oSK ZDq33JOEHHRAgAlz6FlW8LgvJE05i5rcaeOdeI5IQ2FDqiBGYA/ngE5g9J5su0T/tVGF tFdg== X-Gm-Message-State: ALoCoQkGbai1fWoT2s9l0KhrKEsB3vNjhNYm5Ox2lwA/xQNS7y4FFWXR5KzyHlLgKd79VQpVTtb/3XQHaHqSdSAAkJNp78dI3jkL95DKSKp7EWI+v8YUeI7Lt0jVD7S1ebHnsdAUvdH2 X-Received: by 10.194.221.6 with SMTP id qa6mr8984875wjc.39.1403696829335; Wed, 25 Jun 2014 04:47:09 -0700 (PDT) X-Received: by 10.194.221.6 with SMTP id qa6mr8984775wjc.39.1403696828474; Wed, 25 Jun 2014 04:47:08 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id ev9sm11477839wic.24.2014.06.25.04.47.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jun 2014 04:47:07 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s5PBl4xo011053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 25 Jun 2014 12:47:05 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s5PBl42l011052 for freebsd-arm@freebsd.org; Wed, 25 Jun 2014 12:47:04 +0100 (BST) (envelope-from mexas) Date: Wed, 25 Jun 2014 12:47:04 +0100 (BST) From: Anton Shterenlikht Message-Id: <201406251147.s5PBl42l011052@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: RPi model B - svnlite segfaults a lot - power? Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 11:47:41 -0000 Just trying Raspberry Pi model B. Booting with this snapshot: # uname -a FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267801: Tue Jun 24 11:03:28 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm I wanted to check the feasibility of various ports running on this hardware. While checking out the ports tree svnlite segfaults a lot. I've seen many threads urging the importance of correct power source. I'm powering this RPi from a laptop via USB. Is there any way to check either on the laptop or on the RPi the current drawn via the USB port? The only connected devices are the SD card and the ethernet. I imagine there are no prebuild packages for RPi model 2, are there? Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Fri Jun 27 10:47:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C568B2A; Fri, 27 Jun 2014 10:47:41 +0000 (UTC) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [IPv6:2a02:6b8:0:1819::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E15ED2E85; Fri, 27 Jun 2014 10:47:40 +0000 (UTC) Received: from smtp9.mail.yandex.net (smtp9.mail.yandex.net [77.88.61.35]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 8D4B814E149A; Fri, 27 Jun 2014 14:47:28 +0400 (MSK) Received: from smtp9.mail.yandex.net (localhost [127.0.0.1]) by smtp9.mail.yandex.net (Yandex) with ESMTP id 2C671152019B; Fri, 27 Jun 2014 14:47:28 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp9.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id pw097bQDjW-lR4qWVb9; Fri, 27 Jun 2014 14:47:27 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: adab250e-b2dd-433e-8a0f-8885dff43046 Message-ID: <53AD4BBF.9060202@passap.ru> Date: Fri, 27 Jun 2014 14:47:27 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org, kientzle@FreeBSD.org Subject: [crochet] Introduce SVN_CMD at lib/subversion.sh X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 10:47:41 -0000 Hi Tim, All! Sometimes I use systems which have only svnlite version. I propose a patch to let crochet work at those systems as well: ----- --- lib/subversion.sh.orig 2014-03-30 13:28:41.000000000 +0400 +++ lib/subversion.sh 2014-06-27 14:37:01.668105743 +0400 @@ -1,15 +1,16 @@ +: ${SVN_CMD:=`which svn 2>/dev/null || which svnlite 2>/dev/null`} svn_update_sourcetree ( ) { echo "Updating source tree ${FREEBSD_SRC}" cd ${FREEBSD_SRC} - svn update > ${WORKDIR}/_.svnupdate.log + ${SVN_CMD} update > ${WORKDIR}/_.svnupdate.log cd ${TOPDIR} } svn_get_revision ( ) { _PWD=`pwd` cd ${FREEBSD_SRC} - SOURCE_VERSION=`svn info |grep Revision: |cut -c11-` + SOURCE_VERSION=`${SVN_CMD} info |grep Revision: |cut -c11-` cd $_PWD echo "Source version is: ${SOURCE_VERSION:-unknown}"; } ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Fri Jun 27 14:53:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9752563 for ; Fri, 27 Jun 2014 14:53:09 +0000 (UTC) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98A4C2845 for ; Fri, 27 Jun 2014 14:53:09 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id fp1so4503651pdb.39 for ; Fri, 27 Jun 2014 07:53:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=SBe28TvEqZJ9u0MJisTF0ZInQNCfmAHEzafgvRRKQEk=; b=bEiRLTccjc2Pwbqu+eWJCyln2I/GVPN9POR08BltLNBPg/Z8d0WFNFlNhOVewDi2kQ Qkz3nHQEoJEYjiJX/NsHVxCs8zYQnjl9S8ZUv5Y5/9tUXzZuYCBJDnPlAMlAooxvGwp1 XhXQSKvbcWWscG7ggEUcWNHQ4f+1R8EPtbZ9WpjV2XGpaN9lTZqUzk698oS2DhyI7Ypd zq8BJUY9BunWURaAy/S36wCuV4dIldpvBjCq12zgtIYr9OQy6GK9cnzxvOifStvmqnq1 BWrkNdnZgCNfKk/FWqQekm1fqL/SKhvb39dI0kPKoGFI2SFbUHsgHp3/NGqvijCnO6O8 jHRA== X-Gm-Message-State: ALoCoQkXueLy3Z7qHSZ/GSE9SyrtwkTYuf4H7WdLXxyY2GRXXpwsn6r3hPYk+B7aV1YDsEm+LLDz X-Received: by 10.66.132.70 with SMTP id os6mr9840501pab.110.1403880783644; Fri, 27 Jun 2014 07:53:03 -0700 (PDT) Received: from lgmac-sckelly.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id xz7sm52652217pac.3.2014.06.27.07.53.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 07:53:03 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_C9CC2792-3C35-4A03-A5AA-6BFB9B26102D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [crochet] Introduce SVN_CMD at lib/subversion.sh From: Warner Losh In-Reply-To: <53AD4BBF.9060202@passap.ru> Date: Fri, 27 Jun 2014 08:53:01 -0600 Message-Id: References: <53AD4BBF.9060202@passap.ru> To: Boris Samorodov X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 14:53:10 -0000 --Apple-Mail=_C9CC2792-3C35-4A03-A5AA-6BFB9B26102D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 27, 2014, at 4:47 AM, Boris Samorodov wrote: > Hi Tim, All! >=20 > Sometimes I use systems which have only svnlite version. > I propose a patch to let crochet work at those systems as well: Where is SVN_CMD set? Most other things in the system would just call this SVN. Is there a = reason we need the _CMD? Warner > ----- > --- lib/subversion.sh.orig 2014-03-30 13:28:41.000000000 +0400 > +++ lib/subversion.sh 2014-06-27 14:37:01.668105743 +0400 > @@ -1,15 +1,16 @@ > +: ${SVN_CMD:=3D`which svn 2>/dev/null || which svnlite 2>/dev/null`} >=20 > svn_update_sourcetree ( ) { > echo "Updating source tree ${FREEBSD_SRC}" > cd ${FREEBSD_SRC} > - svn update > ${WORKDIR}/_.svnupdate.log > + ${SVN_CMD} update > ${WORKDIR}/_.svnupdate.log > cd ${TOPDIR} > } >=20 > svn_get_revision ( ) { > _PWD=3D`pwd` > cd ${FREEBSD_SRC} > - SOURCE_VERSION=3D`svn info |grep Revision: |cut -c11-` > + SOURCE_VERSION=3D`${SVN_CMD} info |grep Revision: |cut -c11-` > cd $_PWD > echo "Source version is: ${SOURCE_VERSION:-unknown}"; > } > ----- >=20 > --=20 > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > _______________________________________________ > 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" --Apple-Mail=_C9CC2792-3C35-4A03-A5AA-6BFB9B26102D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTrYVOAAoJEGwc0Sh9sBEAnBQP/3yv8s98aREGtwiwosDIGhZL Bv6ANyZXRdYW7l4e5sBQeATVO9ZWYjTw+rbqI2WblZG3uiWkoFFPL3NpQlVlqW6L HtW2y0Uso2M5UdCmj9RAU1iANFTYzEXtlUT+pR/TT9Lf61NWMpQbNNOVUGqEUk64 SOx/R79wVEcyoVzCw+Y6M9bUCzkV5ZwpHVRDqeDt13CEDPZaWTPK23OaWjZho/Wb ghRPGRwWa6sWYdiCznFJ6ZqmgR9TOi+6k3eNQFve+TuLstBJkPtahMoQm6LPz/xV i6WnwqkLzDUQ3BqQ9dEt8FXPE/Si5iUSZTY7OPwnK4/fIoSpiGaAT7oHpp4V1+ps UPub/UGHjQ8quZ1uIzi0MuwKCoHqNxwE9aJ9F6GqpXAtbTwHjfBg9PEVX9LO0xGj Ttw6g6LZOWpPL3vjVmezIZBvxNDZmXMDh5xE8HH+Olf9oFHF768mQFzpob7jKucs OYoO6+3yLg7+61jtXBvG0JYKmuzZ7QoYv3gyhSq1oGiq8qbhrKLAWdumXYvMxq5j SL0gPEMkSzHVDKXsSmxsccqTEfTPz7O2g6Bq87L45Q7dft1X/npAtwH18icJtPbo AdywspHfYQMpnliciSWnoI/udL/rXip+pFNgjAKcyePS1HrZczZ6d0hBNh/Z4Rk3 ejZ0DIwO9J2cR4pPEhyP =Zcf5 -----END PGP SIGNATURE----- --Apple-Mail=_C9CC2792-3C35-4A03-A5AA-6BFB9B26102D-- From owner-freebsd-arm@FreeBSD.ORG Fri Jun 27 15:12:13 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F04B928; Fri, 27 Jun 2014 15:12:13 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [IPv6:2a02:6b8:0:1819::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D3CB29F3; Fri, 27 Jun 2014 15:12:13 +0000 (UTC) Received: from smtp7.mail.yandex.net (smtp7.mail.yandex.net [77.88.61.55]) by forward4l.mail.yandex.net (Yandex) with ESMTP id 8D7E614417CF; Fri, 27 Jun 2014 19:12:09 +0400 (MSK) Received: from smtp7.mail.yandex.net (localhost [127.0.0.1]) by smtp7.mail.yandex.net (Yandex) with ESMTP id 252B41580991; Fri, 27 Jun 2014 19:12:09 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp7.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id NVRAFhVhD0-C88m80CD; Fri, 27 Jun 2014 19:12:08 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: a97e9ac0-ffdc-4675-a281-741687d2c690 Message-ID: <53AD89C7.7010403@passap.ru> Date: Fri, 27 Jun 2014 19:12:07 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: [crochet] Introduce SVN_CMD at lib/subversion.sh References: <53AD4BBF.9060202@passap.ru> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 15:12:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 27.06.2014 18:53, Warner Losh пишет: > > On Jun 27, 2014, at 4:47 AM, Boris Samorodov wrote: > >> Hi Tim, All! >> >> Sometimes I use systems which have only svnlite version. >> I propose a patch to let crochet work at those systems as well: > > Where is SVN_CMD set? Look further at [*] > Most other things in the system would just call this SVN. Is there a reason we need the _CMD? No reason. The name was inspired by the port's system (like ECHO_CMD, etc.). I'm fine with whatever name. > Warner > >> ----- >> --- lib/subversion.sh.orig 2014-03-30 13:28:41.000000000 +0400 >> +++ lib/subversion.sh 2014-06-27 14:37:01.668105743 +0400 >> @@ -1,15 +1,16 @@ >> +: ${SVN_CMD:=`which svn 2>/dev/null || which svnlite 2>/dev/null`} [*] >> svn_update_sourcetree ( ) { >> echo "Updating source tree ${FREEBSD_SRC}" >> cd ${FREEBSD_SRC} >> - svn update > ${WORKDIR}/_.svnupdate.log >> + ${SVN_CMD} update > ${WORKDIR}/_.svnupdate.log >> cd ${TOPDIR} >> } >> >> svn_get_revision ( ) { >> _PWD=`pwd` >> cd ${FREEBSD_SRC} >> - SOURCE_VERSION=`svn info |grep Revision: |cut -c11-` >> + SOURCE_VERSION=`${SVN_CMD} info |grep Revision: |cut -c11-` >> cd $_PWD >> echo "Source version is: ${SOURCE_VERSION:-unknown}"; >> } >> ----- - -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTrYnHAAoJEJYOILA6P20oh0YP/3V4QOnGwsJrCgy0/1rWrRiG bj+B7dd8knDS/XuKmuS2+qFgeXE59tQtUvh1U6SnZsUk/Xttse/JXc3H1iroG/VW aVcqgjjTgjySVQfBhhPgXGaaimbPGLdA2ScSi4doub52xr3Nx+jC1NQzyyhZ2my0 Ot3lp6UZoPxjzOq/hWXdUxHWX69c5TIm/qqOj64pYa7Uhxys7iCHHKSaDy0O/9HN VwsBYqjnNXZM+yZJMT6JwV+RFEvK+IElXGT6Qsk5uK3XMyPGkTfCKUbVURGWK9dN xpH4yeF8BJN1qQ0IDsRyFhEGaUrVBgrfz8afJKppRpQFeGZ1Bw+N1V6dWt6NtbJx rMSBwMOFI2NCQ2hN35GuER5Xh6dNmrJGbsjU6Ypc6SLhgxkDunKZOPyQJobilV4I Fn/fH0yqda4gdBv260csd2ly3ogreYEswizKafOsTkphIP3eaZK3znYFmsXmMEU/ aHPVsz+MZEg5mqDrRi4gF20rnqfoJtmr55CgDyhNuL6h4imxBCE+oLDxu9UmHJ0H JI2uaLhZ1d07cuUiNqk4SyWbMnJWINZcLgrJz1pIDRTeBSIUfV6PSSlQbKQstpEF dfLBT8WCqyitY3THsYMuQhLibWjA2+OhRSMqcn0RuPqPrIATisrevPtSnzAPFJGf S4DT2VpBb6lkktTwMa1v =AU2E -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Fri Jun 27 15:25:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29BFCE76 for ; Fri, 27 Jun 2014 15:25:02 +0000 (UTC) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC1582B1E for ; Fri, 27 Jun 2014 15:25:01 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id w10so4534765pde.31 for ; Fri, 27 Jun 2014 08:24:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=57UDh30YrlnejcQ1leF2yDqhOE5wGOPfQ1oiIQaESZA=; b=jaOLyPoki3XgtUf0GS1KePESGpQuDOoqNI7VfFKtfiCttrA7+UpKVL/4O5DXkzFhrP rmNy62AQihjhQ2Gi4x8ny4Am0LZs6ilwvliPoMelqPmT/oVu23boDD9ykrj1zUuB9n5R EsXhvMyC7Qx4MJ7Y0eE12Ej1UACRJAXwcvQZ8UMdYfWhkJVhz/GrZ/iHf2Jix3fh2U1F 3Rmjmfja4OfmhdEOc4khaOk9IM09e+JXRoHygEERLmd8uBiJMvGLAQlGB5ISYHTCMRrG ywjR74C1r96Y9cIbRbTfrFilo6tkfXbSvliLX3inyuvRaD3gh9Xjl6fUwM870hEeqrA4 nCUA== X-Gm-Message-State: ALoCoQle8vsoAI75yNmGtpihVxYgyEJM8Y8Km4OQRvNbq2AN+UrBwnJi7sds1ctBDkig250Fojbl X-Received: by 10.68.164.100 with SMTP id yp4mr31297117pbb.136.1403882695122; Fri, 27 Jun 2014 08:24:55 -0700 (PDT) Received: from lgmac-sckelly.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id yv7sm52930357pac.33.2014.06.27.08.24.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 08:24:54 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_559AF028-445E-4F13-9B08-1DDA32A60904"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [crochet] Introduce SVN_CMD at lib/subversion.sh From: Warner Losh In-Reply-To: <53AD89C7.7010403@passap.ru> Date: Fri, 27 Jun 2014 09:24:53 -0600 Message-Id: References: <53AD4BBF.9060202@passap.ru> <53AD89C7.7010403@passap.ru> To: Boris Samorodov X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 15:25:02 -0000 --Apple-Mail=_559AF028-445E-4F13-9B08-1DDA32A60904 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 27, 2014, at 9:12 AM, Boris Samorodov wrote: > Signed PGP part > 27.06.2014 18:53, Warner Losh =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > On Jun 27, 2014, at 4:47 AM, Boris Samorodov wrote: > > > >> Hi Tim, All! > >> > >> Sometimes I use systems which have only svnlite version. > >> I propose a patch to let crochet work at those systems as well: > > > > Where is SVN_CMD set? >=20 > Look further at [*] Ah. Need more caffeine. > > Most other things in the system would just call this SVN. Is there a = reason we need the _CMD? >=20 > No reason. The name was inspired by the port's system (like ECHO_CMD, > etc.). I'm fine with whatever name. Yea, some parts of the project like to have a _CMD (like ports), while = other parts only do _CMD when the command name has been stolen for something else (like the build = and nanobsd). Warner > > Warner > > > >> ----- > >> --- lib/subversion.sh.orig 2014-03-30 13:28:41.000000000 +0400 > >> +++ lib/subversion.sh 2014-06-27 14:37:01.668105743 +0400 > >> @@ -1,15 +1,16 @@ > >> +: ${SVN_CMD:=3D`which svn 2>/dev/null || which svnlite = 2>/dev/null`} >=20 > [*] >=20 > >> svn_update_sourcetree ( ) { > >> echo "Updating source tree ${FREEBSD_SRC}" > >> cd ${FREEBSD_SRC} > >> - svn update > ${WORKDIR}/_.svnupdate.log > >> + ${SVN_CMD} update > ${WORKDIR}/_.svnupdate.log > >> cd ${TOPDIR} > >> } > >> > >> svn_get_revision ( ) { > >> _PWD=3D`pwd` > >> cd ${FREEBSD_SRC} > >> - SOURCE_VERSION=3D`svn info |grep Revision: |cut -c11-` > >> + SOURCE_VERSION=3D`${SVN_CMD} info |grep Revision: |cut -c11-` > >> cd $_PWD > >> echo "Source version is: ${SOURCE_VERSION:-unknown}"; > >> } > >> ----- >=20 > -- > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve >=20 --Apple-Mail=_559AF028-445E-4F13-9B08-1DDA32A60904 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTrYzFAAoJEGwc0Sh9sBEAWo0P/1HndbBjtbeiVFN5867Lg58c 4hkixd8fwlpoxPxA5IGcWSV1G/cGE1Wv5PASadQfg5DSZ7jKrCgFAmqr2UczTIG+ 8oTct32Su9UGGI6OGVQEYebUgB/C7Tr0NS0D8AwoXmxLHdmgzha8eAE2aoqzl4pi cfXqWFJ6OT1cBUnNyV2cgm9KB3zgr/5FIXCQPOMeBtCS2hzG6LKfK2vfptRAyXVk plUrDSjcOXYgANWSjyi8JylXf4Z4Gnmp08itQ3jtxI0pJmBqDjjv1WGAccPsmKFP 0H7GMWquJ96d0Uxir16T20HcStCOcaFAbWx6rJvFCg0pYMkeXSNg9mxsYoKlFjeu gFZhx/ouSkjrjy3xp/mSFAXIT7TYeLjTF0Ao9fiEOe5BI5rrozBqZKuiXxT/R0sK dPY1xDjPsGqGvk97vVEK0czN3nZWTO4khaB8VCd6JBJkg8NrJpaKvPBDp2s7stAW QSSIuRx6ARcse7stq24htmNHk81a5vSN1q+8l+RM3i9yK5M4EGA9RfSvy3mJ1/Fb Z5RhJR+wYNae+8xzPnYYcRaP403NPwLEA0DhyU4kDMYSiuiOIgowiMlh4dabFNBC ayU4dlBNuCyeyZeW5cC/q9qAKpQO9b+Zw4pUn9ZR/Esm2LIFr2+K04OcHSH96/LD KA0il6QmFTJN+0iwEm1Z =K8J+ -----END PGP SIGNATURE----- --Apple-Mail=_559AF028-445E-4F13-9B08-1DDA32A60904-- From owner-freebsd-arm@FreeBSD.ORG Fri Jun 27 23:57:41 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCA41A22; Fri, 27 Jun 2014 23:57:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9156F2B42; Fri, 27 Jun 2014 23:57:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s5RNvdwE050200; Fri, 27 Jun 2014 19:57:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s5RNvdXB050199; Fri, 27 Jun 2014 23:57:39 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jun 2014 23:57:39 GMT Message-Id: <201406272357.s5RNvdXB050199@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 23:57:41 -0000 TB --- 2014-06-27 22:50:50 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-06-27 22:50:50 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-06-27 22:50:50 - starting HEAD tinderbox run for arm/arm TB --- 2014-06-27 22:50:50 - cleaning the object tree TB --- 2014-06-27 22:50:50 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-06-27 22:50:55 - At svn revision 267987 TB --- 2014-06-27 22:50:56 - building world TB --- 2014-06-27 22:50:56 - CROSS_BUILD_TESTING=YES TB --- 2014-06-27 22:50:56 - MAKEOBJDIRPREFIX=/obj TB --- 2014-06-27 22:50:56 - MAKESYSPATH=/src/share/mk TB --- 2014-06-27 22:50:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-06-27 22:50:56 - SRCCONF=/dev/null TB --- 2014-06-27 22:50:56 - TARGET=arm TB --- 2014-06-27 22:50:56 - TARGET_ARCH=arm TB --- 2014-06-27 22:50:56 - TZ=UTC TB --- 2014-06-27 22:50:56 - __MAKE_CONF=/dev/null TB --- 2014-06-27 22:50:56 - cd /src TB --- 2014-06-27 22:50:56 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Fri Jun 27 22:51:03 UTC 2014 >>> 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 [...] ===> lib/clang/libllvmmipsinfo (all) c++ -O2 -pipe -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/include -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/lib/Target/Mips/TargetInfo -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/lib/Target/Mips -I. -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/lib/Target/Mips/TargetInfo/MipsTargetInfo.cpp -o MipsTargetInfo.o building static llvmmipsinfo library ranlib -D libllvmmipsinfo.a ===> lib/clang/libllvmmipsinstprinter (all) c++ -O2 -pipe -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/lib/Target/Mips/InstPrinter -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/lib/Target/Mips -I. -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/lib/Target/Mips/InstPrinter/MipsInstPrinter.cpp -o MipsInstPrinter.o building static llvmmipsinstprinter library ranlib -D libllvmmipsinstprinter.a ===> lib/clang/libllvmpowerpcasmparser (all) c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/lib/Target/PowerPC/AsmParser -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp -o PPCAsmParser.o building static llvmpowerpcasmparser library ranlib -D libllvmpowerpcasmparser.a ===> lib/clang/libllvmpowerpccodegen (all) c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp -o PPCAsmPrinter.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCBranchSelector.cpp -o PPCBranchSelector.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp -o PPCCTRLoops.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCCodeEmitter.cpp -o PPCCodeEmitter.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCFastISel.cpp -o PPCFastISel.o /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCFastISel.cpp: In member function 'bool::PPCFastISel::SelectFPToI(const llvm::Instruction*, bool)': /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCFastISel.cpp:1030: error: base operand of '->' has non-pointer type 'const llvm::PPCSubtarget' *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmpowerpccodegen *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-06-27 23:57:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-06-27 23:57:39 - ERROR: failed to build world TB --- 2014-06-27 23:57:39 - 3641.97 user 310.05 system 4008.87 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Jun 28 05:18:39 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13D7638C; Sat, 28 Jun 2014 05:18:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD368244D; Sat, 28 Jun 2014 05:18:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s5S5Ib6Y086158; Sat, 28 Jun 2014 01:18:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s5S5IbQE086156; Sat, 28 Jun 2014 05:18:37 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 28 Jun 2014 05:18:37 GMT Message-Id: <201406280518.s5S5IbQE086156@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 05:18:39 -0000 TB --- 2014-06-28 04:10:47 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-06-28 04:10:47 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-06-28 04:10:47 - starting HEAD tinderbox run for arm/arm TB --- 2014-06-28 04:10:47 - cleaning the object tree TB --- 2014-06-28 04:11:58 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-06-28 04:12:02 - At svn revision 267993 TB --- 2014-06-28 04:12:03 - building world TB --- 2014-06-28 04:12:03 - CROSS_BUILD_TESTING=YES TB --- 2014-06-28 04:12:03 - MAKEOBJDIRPREFIX=/obj TB --- 2014-06-28 04:12:03 - MAKESYSPATH=/src/share/mk TB --- 2014-06-28 04:12:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-06-28 04:12:03 - SRCCONF=/dev/null TB --- 2014-06-28 04:12:03 - TARGET=arm TB --- 2014-06-28 04:12:03 - TARGET_ARCH=arm TB --- 2014-06-28 04:12:03 - TZ=UTC TB --- 2014-06-28 04:12:03 - __MAKE_CONF=/dev/null TB --- 2014-06-28 04:12:03 - cd /src TB --- 2014-06-28 04:12:03 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Sat Jun 28 04:12:10 UTC 2014 >>> 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 [...] ===> lib/clang/libllvmmipsinfo (all) c++ -O2 -pipe -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/include -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/lib/Target/Mips/TargetInfo -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/lib/Target/Mips -I. -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/lib/Target/Mips/TargetInfo/MipsTargetInfo.cpp -o MipsTargetInfo.o building static llvmmipsinfo library ranlib -D libllvmmipsinfo.a ===> lib/clang/libllvmmipsinstprinter (all) c++ -O2 -pipe -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/lib/Target/Mips/InstPrinter -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/lib/Target/Mips -I. -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/lib/Target/Mips/InstPrinter/MipsInstPrinter.cpp -o MipsInstPrinter.o building static llvmmipsinstprinter library ranlib -D libllvmmipsinstprinter.a ===> lib/clang/libllvmpowerpcasmparser (all) c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/lib/Target/PowerPC/AsmParser -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp -o PPCAsmParser.o building static llvmpowerpcasmparser library ranlib -D libllvmpowerpcasmparser.a ===> lib/clang/libllvmpowerpccodegen (all) c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp -o PPCAsmPrinter.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCBranchSelector.cpp -o PPCBranchSelector.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp -o PPCCTRLoops.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCCodeEmitter.cpp -o PPCCodeEmitter.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCFastISel.cpp -o PPCFastISel.o /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCFastISel.cpp: In member function 'bool::PPCFastISel::SelectFPToI(const llvm::Instruction*, bool)': /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCFastISel.cpp:1030: error: base operand of '->' has non-pointer type 'const llvm::PPCSubtarget' *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmpowerpccodegen *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-06-28 05:18:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-06-28 05:18:37 - ERROR: failed to build world TB --- 2014-06-28 05:18:37 - 3644.60 user 309.99 system 4069.98 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Jun 28 09:40:08 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 084E4426; Sat, 28 Jun 2014 09:40:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CFBF12642; Sat, 28 Jun 2014 09:40:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s5S9e667007518; Sat, 28 Jun 2014 05:40:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s5S9e6jS007517; Sat, 28 Jun 2014 09:40:06 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 28 Jun 2014 09:40:06 GMT Message-Id: <201406280940.s5S9e6jS007517@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 09:40:08 -0000 TB --- 2014-06-28 08:30:46 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-06-28 08:30:46 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-06-28 08:30:46 - starting HEAD tinderbox run for arm/arm TB --- 2014-06-28 08:30:46 - cleaning the object tree TB --- 2014-06-28 08:32:02 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-06-28 08:32:07 - At svn revision 268002 TB --- 2014-06-28 08:32:08 - building world TB --- 2014-06-28 08:32:08 - CROSS_BUILD_TESTING=YES TB --- 2014-06-28 08:32:08 - MAKEOBJDIRPREFIX=/obj TB --- 2014-06-28 08:32:08 - MAKESYSPATH=/src/share/mk TB --- 2014-06-28 08:32:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-06-28 08:32:08 - SRCCONF=/dev/null TB --- 2014-06-28 08:32:08 - TARGET=arm TB --- 2014-06-28 08:32:08 - TARGET_ARCH=arm TB --- 2014-06-28 08:32:08 - TZ=UTC TB --- 2014-06-28 08:32:08 - __MAKE_CONF=/dev/null TB --- 2014-06-28 08:32:08 - cd /src TB --- 2014-06-28 08:32:08 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Sat Jun 28 08:32:14 UTC 2014 >>> 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 [...] ===> lib/clang/libllvmmipsinfo (all) c++ -O2 -pipe -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/include -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/lib/Target/Mips/TargetInfo -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/lib/Target/Mips -I. -I/src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmmipsinfo/../../../contrib/llvm/lib/Target/Mips/TargetInfo/MipsTargetInfo.cpp -o MipsTargetInfo.o building static llvmmipsinfo library ranlib -D libllvmmipsinfo.a ===> lib/clang/libllvmmipsinstprinter (all) c++ -O2 -pipe -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/lib/Target/Mips/InstPrinter -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/lib/Target/Mips -I. -I/src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmmipsinstprinter/../../../contrib/llvm/lib/Target/Mips/InstPrinter/MipsInstPrinter.cpp -o MipsInstPrinter.o building static llvmmipsinstprinter library ranlib -D libllvmmipsinstprinter.a ===> lib/clang/libllvmpowerpcasmparser (all) c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/lib/Target/PowerPC/AsmParser -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpcasmparser/../../../contrib/llvm/lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp -o PPCAsmParser.o building static llvmpowerpcasmparser library ranlib -D libllvmpowerpcasmparser.a ===> lib/clang/libllvmpowerpccodegen (all) c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp -o PPCAsmPrinter.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCBranchSelector.cpp -o PPCBranchSelector.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp -o PPCCTRLoops.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCCodeEmitter.cpp -o PPCCodeEmitter.o c++ -O2 -pipe -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC -I. -I/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCFastISel.cpp -o PPCFastISel.o /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCFastISel.cpp: In member function 'bool::PPCFastISel::SelectFPToI(const llvm::Instruction*, bool)': /src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/lib/Target/PowerPC/PPCFastISel.cpp:1030: error: base operand of '->' has non-pointer type 'const llvm::PPCSubtarget' *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmpowerpccodegen *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-06-28 09:40:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-06-28 09:40:06 - ERROR: failed to build world TB --- 2014-06-28 09:40:06 - 3646.03 user 324.91 system 4160.37 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Jun 28 16:23:37 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47D0991; Sat, 28 Jun 2014 16:23:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EB332356; Sat, 28 Jun 2014 16:23:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s5SGNZNf021965; Sat, 28 Jun 2014 12:23:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s5SGNZS8021952; Sat, 28 Jun 2014 16:23:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 28 Jun 2014 16:23:35 GMT Message-Id: <201406281623.s5SGNZS8021952@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 16:23:37 -0000 TB --- 2014-06-28 12:50:35 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-06-28 12:50:35 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-06-28 12:50:35 - starting HEAD tinderbox run for arm/arm TB --- 2014-06-28 12:50:35 - cleaning the object tree TB --- 2014-06-28 12:52:05 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-06-28 12:52:08 - At svn revision 268003 TB --- 2014-06-28 12:52:09 - building world TB --- 2014-06-28 12:52:09 - CROSS_BUILD_TESTING=YES TB --- 2014-06-28 12:52:09 - MAKEOBJDIRPREFIX=/obj TB --- 2014-06-28 12:52:09 - MAKESYSPATH=/src/share/mk TB --- 2014-06-28 12:52:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-06-28 12:52:09 - SRCCONF=/dev/null TB --- 2014-06-28 12:52:09 - TARGET=arm TB --- 2014-06-28 12:52:09 - TARGET_ARCH=arm TB --- 2014-06-28 12:52:09 - TZ=UTC TB --- 2014-06-28 12:52:09 - __MAKE_CONF=/dev/null TB --- 2014-06-28 12:52:09 - cd /src TB --- 2014-06-28 12:52:09 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Sat Jun 28 12:52:16 UTC 2014 >>> 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 Sat Jun 28 16:10:47 UTC 2014 TB --- 2014-06-28 16:10:47 - generating LINT kernel config TB --- 2014-06-28 16:10:47 - cd /src/sys/arm/conf TB --- 2014-06-28 16:10:47 - /usr/bin/make -B LINT TB --- 2014-06-28 16:10:47 - cd /src/sys/arm/conf TB --- 2014-06-28 16:10:47 - /obj/arm.arm/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-06-28 16:10:47 - building LINT kernel TB --- 2014-06-28 16:10:47 - CROSS_BUILD_TESTING=YES TB --- 2014-06-28 16:10:47 - MAKEOBJDIRPREFIX=/obj TB --- 2014-06-28 16:10:47 - MAKESYSPATH=/src/share/mk TB --- 2014-06-28 16:10:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-06-28 16:10:47 - SRCCONF=/dev/null TB --- 2014-06-28 16:10:47 - TARGET=arm TB --- 2014-06-28 16:10:47 - TARGET_ARCH=arm TB --- 2014-06-28 16:10:47 - TZ=UTC TB --- 2014-06-28 16:10:47 - __MAKE_CONF=/dev/null TB --- 2014-06-28 16:10:48 - cd /src TB --- 2014-06-28 16:10:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jun 28 16:10:48 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ /src/sys/sys/sysctl.h:284:20: note: expanded from macro 'SYSCTL_OID_RAW' struct sysctl_oid id = { \ ^ /src/sys/kern/kern_ktr.c:109:1: note: previous definition is here SYSCTL_INT(_debug_ktr, OID_AUTO, mask, CTLFLAG_RDTUN, ^ /src/sys/sys/sysctl.h:340:2: note: expanded from macro 'SYSCTL_INT' SYSCTL_OID(parent, nbr, name, \ ^ /src/sys/sys/sysctl.h:300:27: note: expanded from macro 'SYSCTL_OID' static SYSCTL_OID_RAW(sysctl__##parent##_##name, \ ^ :107:1: note: expanded from here sysctl___debug_ktr_mask ^ /src/sys/sys/sysctl.h:284:20: note: expanded from macro 'SYSCTL_OID_RAW' struct sysctl_oid id = { \ ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-06-28 16:23:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-06-28 16:23:35 - ERROR: failed to build LINT kernel TB --- 2014-06-28 16:23:35 - 10215.70 user 1705.12 system 12779.45 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Jun 28 16:29:03 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5588F3D1; Sat, 28 Jun 2014 16:29:03 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1347E2393; Sat, 28 Jun 2014 16:29:02 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AE8E51FE02D; Sat, 28 Jun 2014 18:28:54 +0200 (CEST) Message-ID: <53AEED54.60907@selasky.org> Date: Sat, 28 Jun 2014 18:29:08 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: FreeBSD Tinderbox , current@freebsd.org, arm@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm References: <201406281623.s5SGNZS8021952@freebsd-current.sentex.ca> In-Reply-To: <201406281623.s5SGNZS8021952@freebsd-current.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 16:29:03 -0000 > TB --- 2014-06-28 16:10:48 - /usr/bin/make -B buildkernel KERNCONF=LINT I'm fixing this one shortly and a few others. Just waiting for my "make universe" to complete. --HPS From owner-freebsd-arm@FreeBSD.ORG Sat Jun 28 20:43:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0555384 for ; Sat, 28 Jun 2014 20:43:58 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11AA32687 for ; Sat, 28 Jun 2014 20:43:57 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s5SKZwli007884; Sat, 28 Jun 2014 20:35:58 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id k439dkn9nuks34tzqxrkr2uehw; Sat, 28 Jun 2014 20:35:58 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [crochet] Introduce SVN_CMD at lib/subversion.sh From: Tim Kientzle In-Reply-To: <53AD4BBF.9060202@passap.ru> Date: Sat, 28 Jun 2014 13:35:58 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0CE742D9-F2F6-4ACA-B5B2-93C1D19DE1F8@freebsd.org> References: <53AD4BBF.9060202@passap.ru> To: Boris Samorodov X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 20:43:59 -0000 On Jun 27, 2014, at 3:47 AM, Boris Samorodov wrote: > Hi Tim, All! > > Sometimes I use systems which have only svnlite version. > I propose a patch to let crochet work at those systems as well: Crochet already supports svn, svnlite, git, and hg. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 03:38:32 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04103DB5 for ; Sun, 29 Jun 2014 03:38:32 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CE870229C for ; Sun, 29 Jun 2014 03:38:31 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5T3cNOT006078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Jun 2014 20:38:23 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5T3cNi3006077 for arm@FreeBSD.org; Sat, 28 Jun 2014 20:38:23 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Jun 2014 20:38:23 -0700 From: John-Mark Gurney To: arm@FreeBSD.org Subject: arm alignment faults... Message-ID: <20140629033823.GN1560@funkthat.com> Mail-Followup-To: arm@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 28 Jun 2014 20:38:23 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 03:38:32 -0000 So, one of the little projects I'd like to see is the removal of ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use of bouncing durning DMA ops on all ethernet frames... In investigating this issue, I found CPU_CONTROL_AFLT_ENABLE... The interesting part is that it looks like most of the code in arm/cpufunc.c has dead code: cpuctrlmask = CPU_CONTROL_MMU_ENABLE | CPU_CONTROL_32BP_ENABLE | CPU_CONTROL_32BD_ENABLE | CPU_CONTROL_SYST_ENABLE | CPU_CONTROL_IC_ENABLE | CPU_CONTROL_DC_ENABLE | CPU_CONTROL_WBUF_ENABLE | CPU_CONTROL_ROM_ENABLE | CPU_CONTROL_BEND_ENABLE | CPU_CONTROL_AFLT_ENABLE | CPU_CONTROL_LABT_ENABLE | CPU_CONTROL_VECRELOC | CPU_CONTROL_ROUNDROBIN; #ifndef ARM32_DISABLE_ALIGNMENT_FAULTS cpuctrl |= CPU_CONTROL_AFLT_ENABLE; #endif If you define ARM32_DISABLE_ALIGNMENT_FAULTS, you'll still get alignment faults since that is what is specified above... If anything, the code needs to be changed to: #ifdef ARM32_DISABLE_ALIGNMENT_FAULTS cpuctrl &= ~CPU_CONTROL_AFLT_ENABLE; #endif Though mv_pj4b is the only one to get this correct... It looks like it was this way when the original code was imported.. Shall we just delete the ifndef ARM32_DISABLE_ALIGNMENT_FAULTS sections then? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 03:44:41 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99C46E22 for ; Sun, 29 Jun 2014 03:44:41 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DD032326 for ; Sun, 29 Jun 2014 03:44:41 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id cm18so5377274qab.28 for ; Sat, 28 Jun 2014 20:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=lVNjNeYsPPOZmgohGGPsgKTP/jIgk+looODjoTsAHp0=; b=WmLFMtc5Lp7L2R+p4phGfQ5LXwSm1MD+wbqD578Tky1cQQPzz0Y4YwV0I7c/26pVJI h5kmevU1k8E50/9tImQ0jVaKxRYM1AP/1oYvkGCX2Z0PZZQohO56X5ZrshqS/V9ZSrn1 Ir/yLyJzdNpQtPzLgjHNxzfSxoHcYZaR540Z4Umb96T4ayi7xEpiAGMjPI4/WaA2khrb qpNKaUtDoej5izrNvwXimX4/6+gkgxz+MnPpO1UysVVaOmlw1DYRYFCQ0zJNk0rfftO4 MVJka+r9Hm7aOFS6R/w8BAmFPqFZc2m6tuGz/Olyv8ZD9bWZhF97xOkTM/qATZe0J9VT 8LEg== MIME-Version: 1.0 X-Received: by 10.224.66.70 with SMTP id m6mr49949130qai.55.1404013480454; Sat, 28 Jun 2014 20:44:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Sat, 28 Jun 2014 20:44:40 -0700 (PDT) In-Reply-To: <20140629033823.GN1560@funkthat.com> References: <20140629033823.GN1560@funkthat.com> Date: Sat, 28 Jun 2014 20:44:40 -0700 X-Google-Sender-Auth: ue_izXNgT-ED6I8ZN0kZOqVNa14 Message-ID: Subject: Re: arm alignment faults... From: Adrian Chadd To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 03:44:41 -0000 On 28 June 2014 20:38, John-Mark Gurney wrote: > So, one of the little projects I'd like to see is the removal of > ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use > of bouncing durning DMA ops on all ethernet frames... Well, as long as you're not doing it by forcing the various CPUs to handle unaligned accesses. The cost of those unaligned accesses on some CPUs that support them is not trivial. We benchmarked some of the ARM cores at Qualcomm back when looking to migrate stuff to ARM and it wasn't very quick. -a From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 04:01:52 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5036EF70; Sun, 29 Jun 2014 04:01:52 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 13ED923E6; Sun, 29 Jun 2014 04:01:51 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5T41prf006384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jun 2014 21:01:51 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5T41pdt006383; Sat, 28 Jun 2014 21:01:51 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Jun 2014 21:01:51 -0700 From: John-Mark Gurney To: Adrian Chadd Subject: Re: arm alignment faults... Message-ID: <20140629040150.GO1560@funkthat.com> Mail-Followup-To: Adrian Chadd , "freebsd-arm@freebsd.org" References: <20140629033823.GN1560@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 28 Jun 2014 21:01:51 -0700 (PDT) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 04:01:52 -0000 Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700: > On 28 June 2014 20:38, John-Mark Gurney wrote: > > So, one of the little projects I'd like to see is the removal of > > ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use > > of bouncing durning DMA ops on all ethernet frames... Now that I think about it, total removal may not be necessary, just the requirement to use it... If the ethernet dma engine can do half word aligned dma, then there would be benifit on those to keep ETHER_ALIGN... > Well, as long as you're not doing it by forcing the various CPUs to > handle unaligned accesses. Hard to do on armv4 which I don't believe supports unaligned access... > The cost of those unaligned accesses on some CPUs that support them is > not trivial. We benchmarked some of the ARM cores at Qualcomm back > when looking to migrate stuff to ARM and it wasn't very quick. I plan on fixing the TCP/IP stack to copy data to an aligned buffer (maybe only if the original buffer isn't aligned) on the stack when __NO_STRICT_ALIGNMENT is not defined... I can't see how copying the entire packet is cheaper than copying 20 bytes or so... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 04:52:20 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B563D205; Sun, 29 Jun 2014 04:52:20 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68166273B; Sun, 29 Jun 2014 04:52:20 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id x12so5304433qac.7 for ; Sat, 28 Jun 2014 21:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=HhL+IQrlFThjPGUjJ/9/NsDLfMGmnClMQo3DwmWnaSg=; b=ws8cZBqTfnyt9u2Q8LrLH325ceDF1HEKDm3qrjAm03pPpokrm/8+jKH8LEyYzY48aE BsskpggcizO5D2KdaQIVC2UZVb7l8JhVoyhYejFlR2UgPlq39d1ikdq17XpL1aIaRce1 mDlZCJL0lmWJEG3ou48BwuLodjx15TDzqPAuIvYZHrsXAGyqZziEbhOqSBryHDrX7UVt 33pwVp8dvn/hoBqH8Ca8OWM2w+R/w1LCDOCN5HfWIGtQacAprLn4f8lDn5MPT5hdSD36 uxe+4yRvpEBDCGRPrMUFrY/4uzuZiGNVZ0ZiOOuwtklFNrVh5Bhe6OVmvQ7jjAKzEshy OZ5g== MIME-Version: 1.0 X-Received: by 10.140.47.48 with SMTP id l45mr7318416qga.24.1404017539582; Sat, 28 Jun 2014 21:52:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Sat, 28 Jun 2014 21:52:19 -0700 (PDT) In-Reply-To: <20140629040150.GO1560@funkthat.com> References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> Date: Sat, 28 Jun 2014 21:52:19 -0700 X-Google-Sender-Auth: 8TOPShALHd7NbFYty_UIWwQ4R28 Message-ID: Subject: Re: arm alignment faults... From: Adrian Chadd To: Adrian Chadd , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 04:52:20 -0000 On 28 June 2014 21:01, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700: >> On 28 June 2014 20:38, John-Mark Gurney wrote: >> > So, one of the little projects I'd like to see is the removal of >> > ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use >> > of bouncing durning DMA ops on all ethernet frames... > > Now that I think about it, total removal may not be necessary, just > the requirement to use it... If the ethernet dma engine can do half > word aligned dma, then there would be benifit on those to keep > ETHER_ALIGN... > >> Well, as long as you're not doing it by forcing the various CPUs to >> handle unaligned accesses. > > Hard to do on armv4 which I don't believe supports unaligned access... > >> The cost of those unaligned accesses on some CPUs that support them is >> not trivial. We benchmarked some of the ARM cores at Qualcomm back >> when looking to migrate stuff to ARM and it wasn't very quick. > > I plan on fixing the TCP/IP stack to copy data to an aligned buffer > (maybe only if the original buffer isn't aligned) on the stack when > __NO_STRICT_ALIGNMENT is not defined... I can't see how copying the > entire packet is cheaper than copying 20 bytes or so... There's lots of other stupid corner cases that screw you. VLAN headers add extra bytes. 802.11 headers can offset things depending upon the 802.11 frame type (3-addr, 4-addr, vlan, no vlan, etc.) There's no guarantee all ethernet DMA engines can do the alignment as required. :( -a From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 04:53:48 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4999424B for ; Sun, 29 Jun 2014 04:53:48 +0000 (UTC) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D2812744 for ; Sun, 29 Jun 2014 04:53:47 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id c1so3218269igq.2 for ; Sat, 28 Jun 2014 21:53:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=25WvpouB30/kMBRdNSl6HVkDNVRBlKCLAYdalmtGckQ=; b=e2TFAaHlcbbQ2RJsdj+cWGrXjmuS3NEtGJ5RO6+pRcul0+Zee8zrRb5gwGUE283YfA +d2hAuw0RsoC1+MoaQdY/4U7TmuM4hPov7wXNoohroRq0lA0BcbMVbYCotNa6UvBciUU TP0qOye91UI89g0MvDuWbGhYSJ/8EiZq3RYGinWhYNaD9Ap6hTHacy6MAAc6L0jeHEcL yzNwmtJaB35u2PQyvVyNfSA+I08mbfeKDoVF3EUsEogbFFMDgQw/+7z3j+MoPzSzhdeK UyPB9Ir1lMrQx11TQB9mi3UjT+HZe7mwpZUh9XYXtIS2YZR5xtrT9+qVAd+Jtq4k4Fxx 82sA== X-Gm-Message-State: ALoCoQmj9+f5o3CO7l8Tu/fiRB0Y/9NhpfJ0eMajMEkTFECMyrWhG3Htx+JcXuzXYKNBWLpy+fMZ X-Received: by 10.43.104.132 with SMTP id dm4mr19295371icc.56.1404017621124; Sat, 28 Jun 2014 21:53:41 -0700 (PDT) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qa4sm12649569igb.10.2014.06.28.21.53.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 21:53:40 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_005AB40D-F243-4D5B-8DBE-0D20FAE096C1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: arm alignment faults... From: Warner Losh In-Reply-To: Date: Sat, 28 Jun 2014 22:53:37 -0600 Message-Id: <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 04:53:48 -0000 --Apple-Mail=_005AB40D-F243-4D5B-8DBE-0D20FAE096C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 28, 2014, at 10:52 PM, Adrian Chadd wrote: > On 28 June 2014 21:01, John-Mark Gurney wrote: >> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700: >>> On 28 June 2014 20:38, John-Mark Gurney wrote: >>>> So, one of the little projects I'd like to see is the removal of >>>> ETHER_ALIGN from the tree.. This bogosity can (and does) cause the = use >>>> of bouncing durning DMA ops on all ethernet frames... >>=20 >> Now that I think about it, total removal may not be necessary, just >> the requirement to use it... If the ethernet dma engine can do half >> word aligned dma, then there would be benifit on those to keep >> ETHER_ALIGN... >>=20 >>> Well, as long as you're not doing it by forcing the various CPUs to >>> handle unaligned accesses. >>=20 >> Hard to do on armv4 which I don't believe supports unaligned = access... >>=20 >>> The cost of those unaligned accesses on some CPUs that support them = is >>> not trivial. We benchmarked some of the ARM cores at Qualcomm back >>> when looking to migrate stuff to ARM and it wasn't very quick. >>=20 >> I plan on fixing the TCP/IP stack to copy data to an aligned buffer >> (maybe only if the original buffer isn't aligned) on the stack when >> __NO_STRICT_ALIGNMENT is not defined... I can't see how copying the >> entire packet is cheaper than copying 20 bytes or so... >=20 > There's lots of other stupid corner cases that screw you. >=20 > VLAN headers add extra bytes. >=20 > 802.11 headers can offset things depending upon the 802.11 frame type > (3-addr, 4-addr, vlan, no vlan, etc.) >=20 > There's no guarantee all ethernet DMA engines can do the alignment as > required. :( The ate driver for Atmel=92s AT91RM9200 is one such beast. Warner --Apple-Mail=_005AB40D-F243-4D5B-8DBE-0D20FAE096C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTr5vSAAoJEGwc0Sh9sBEAxMAQAJ8fOipAInrkGmn/EDLSVlbR FDJfXVW03PIlMFs8dC43dTIi2sbBQ/q90v6ByCveYIRXQn5D+yQykDgF01VUlJOw cFHPyn/Emm68NwX8uhjKgGaGEuNIoEo0pH8L9vfBItSqMcN6J9qAIP0tXjk4r3ZQ BvZNl+B6M9sfbh3NG97a4v+N9FqWohdVBKnzZ4mxGCzBOPigxuFQgf5EkAKR6/By M1lJ7P57ro+8iIXxQg8QXwKtkwPINBX4HoMF2V2Md1LRQuC8VWGzxmSbWOlXbiUz 4sQyx08iYRLRl8hpg21Jx6uOQa78dy9fwRuZA+XbvYT36Ks1MxMqlHeeW0jqYjOA JPKkrjCXhD1T6K8fTE0IAck2Z8+xItB18M51xaP1l3StJCvPiD0POeuKWdJGbO44 VtQi/zv4TlxQnBB8OMHn4JGCSUr/KEIuzg2DqCtifisKhUaHAQnHoW+tC1ShWGTK Qnlji/VpNuzeGzvBOvAsWd24kofD82JUOQBlsacvPddVu/K02cw5rJTuvd/ev/lD X+G/Ul/DsDLTzI3yvk32X7wayFxTKdHYe8iFHL5rPi8Ysn/R1P+ueaaTMF4cz7ww 5nlYNZ/EHCL/E3BjJKr0gXLCB34pCrReuoo8/EIQMZRgHN612f0PqxUOwX0gjdhv qog5XtQ26LuAvG3krbOJ =WNRz -----END PGP SIGNATURE----- --Apple-Mail=_005AB40D-F243-4D5B-8DBE-0D20FAE096C1-- From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 05:40:42 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56FB2572; Sun, 29 Jun 2014 05:40:42 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 324D229A6; Sun, 29 Jun 2014 05:40:41 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5T5edw6007510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jun 2014 22:40:39 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5T5edDA007509; Sat, 28 Jun 2014 22:40:39 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Jun 2014 22:40:39 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: arm alignment faults... Message-ID: <20140629054039.GP1560@funkthat.com> Mail-Followup-To: Warner Losh , Adrian Chadd , "freebsd-arm@freebsd.org" References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 28 Jun 2014 22:40:40 -0700 (PDT) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 05:40:42 -0000 Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600: > > On Jun 28, 2014, at 10:52 PM, Adrian Chadd wrote: > > > On 28 June 2014 21:01, John-Mark Gurney wrote: > >> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700: > >>> On 28 June 2014 20:38, John-Mark Gurney wrote: > >>>> So, one of the little projects I'd like to see is the removal of > >>>> ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use > >>>> of bouncing durning DMA ops on all ethernet frames... > >> > >> Now that I think about it, total removal may not be necessary, just > >> the requirement to use it... If the ethernet dma engine can do half > >> word aligned dma, then there would be benifit on those to keep > >> ETHER_ALIGN... > >> > >>> Well, as long as you're not doing it by forcing the various CPUs to > >>> handle unaligned accesses. > >> > >> Hard to do on armv4 which I don't believe supports unaligned access... > >> > >>> The cost of those unaligned accesses on some CPUs that support them is > >>> not trivial. We benchmarked some of the ARM cores at Qualcomm back > >>> when looking to migrate stuff to ARM and it wasn't very quick. > >> > >> I plan on fixing the TCP/IP stack to copy data to an aligned buffer > >> (maybe only if the original buffer isn't aligned) on the stack when > >> __NO_STRICT_ALIGNMENT is not defined... I can't see how copying the > >> entire packet is cheaper than copying 20 bytes or so... > > > > There's lots of other stupid corner cases that screw you. > > > > VLAN headers add extra bytes. > > > > 802.11 headers can offset things depending upon the 802.11 frame type > > (3-addr, 4-addr, vlan, no vlan, etc.) > > > > There's no guarantee all ethernet DMA engines can do the alignment as > > required. :( > > The ate driver for Atmel?s AT91RM9200 is one such beast. Are you sure? The tag for data says alignment 1: if (bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0, BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES, 1, MCLBYTES, 0, busdma_lock_mutex, &sc->sc_mtx, &sc->mtag)) Or is that a limitation on the parent? I did an audit of the arm drivers (not mips), but I didn't see any that have the restriction... The one that I'm thinking of was the Cirrus EP9302 in the TS-7200 port that I did years ago.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 11:23:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A958EE00; Sun, 29 Jun 2014 11:23:14 +0000 (UTC) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6871E2121; Sun, 29 Jun 2014 11:23:13 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward5l.mail.yandex.net (Yandex) with ESMTP id 3DB32C41192; Sun, 29 Jun 2014 15:23:03 +0400 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id D98471B60668; Sun, 29 Jun 2014 15:23:02 +0400 (MSK) Received: from 78.108.206.106.tel.ru (78.108.206.106.tel.ru [78.108.206.106]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id PZkSVIlENe-N2n4ejHH; Sun, 29 Jun 2014 15:23:02 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 074cc509-0d5e-47c8-a4ba-86d440ad66ec Message-ID: <53AFF716.5030002@passap.ru> Date: Sun, 29 Jun 2014 15:23:02 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: [crochet] Introduce SVN_CMD at lib/subversion.sh References: <53AD4BBF.9060202@passap.ru> <0CE742D9-F2F6-4ACA-B5B2-93C1D19DE1F8@freebsd.org> In-Reply-To: <0CE742D9-F2F6-4ACA-B5B2-93C1D19DE1F8@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 11:23:14 -0000 29.06.2014 00:35, Tim Kientzle пишет: > > Crochet already supports svn, svnlite, git, and hg. Great. I've loaded the latest version and it works fine. Thank you! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 16:34:05 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E371E30 for ; Sun, 29 Jun 2014 16:34:05 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41BC12694 for ; Sun, 29 Jun 2014 16:34:04 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id x19so6053572ier.2 for ; Sun, 29 Jun 2014 09:33:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=+3nAi3fOGkkDFqr5yOvPo8lvPi5ePRKZoqyB1NSKmPQ=; b=gTkps+4j4VBR6iUNBTavq3iiMdRQSTex3r8j0B2+Z8ge8zi1UAuKuyBfcXnmtfWICp HOa19i06u72IySNN5EOxSbnDK+yi6mkfPqLROhvbvbx6nSjWwRLTJ8IKNCHlo4vHgXNr vNJhCcIhUSZmEpOmr5bg/STN5rVBIRuhjfJ8zhHzKRZwMwHWn73J2lMUo2Ct38qBDLmD yoNPKS0MQW6vyTqQWIUpnhBar1kGBwQncjec/74NnyafX8u7SSDy8x39EHScaQBW57QK VI02e7lIbH2j0Kp22zhEQlU3yKut0L4PV0NHPfNX3ALou8LOj4SbYqrzOKPHIjXlD7rd uSCA== X-Gm-Message-State: ALoCoQneGVFereTNrlgzbF8jaMfq5wCxdNZRi/+N1OokK6sivruW5m+Ir6+cZLJ72TVRY3BsXCcc X-Received: by 10.42.201.84 with SMTP id ez20mr2565081icb.74.1404059638707; Sun, 29 Jun 2014 09:33:58 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id b2sm17011862igg.1.2014.06.29.09.33.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Jun 2014 09:33:57 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_FC3C17ED-70FE-4F36-B52F-701032B569AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: arm alignment faults... From: Warner Losh In-Reply-To: <20140629054039.GP1560@funkthat.com> Date: Sun, 29 Jun 2014 10:33:59 -0600 Message-Id: <039F8A84-0193-424C-8093-E411957817E9@bsdimp.com> References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> <20140629054039.GP1560@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 16:34:05 -0000 --Apple-Mail=_FC3C17ED-70FE-4F36-B52F-701032B569AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 28, 2014, at 11:40 PM, John-Mark Gurney wrote: > Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600: >>=20 >> On Jun 28, 2014, at 10:52 PM, Adrian Chadd = wrote: >>=20 >>> On 28 June 2014 21:01, John-Mark Gurney wrote: >>>> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 = -0700: >>>>> On 28 June 2014 20:38, John-Mark Gurney wrote: >>>>>> So, one of the little projects I'd like to see is the removal of >>>>>> ETHER_ALIGN from the tree.. This bogosity can (and does) cause = the use >>>>>> of bouncing durning DMA ops on all ethernet frames... >>>>=20 >>>> Now that I think about it, total removal may not be necessary, just >>>> the requirement to use it... If the ethernet dma engine can do = half >>>> word aligned dma, then there would be benifit on those to keep >>>> ETHER_ALIGN... >>>>=20 >>>>> Well, as long as you're not doing it by forcing the various CPUs = to >>>>> handle unaligned accesses. >>>>=20 >>>> Hard to do on armv4 which I don't believe supports unaligned = access... >>>>=20 >>>>> The cost of those unaligned accesses on some CPUs that support = them is >>>>> not trivial. We benchmarked some of the ARM cores at Qualcomm back >>>>> when looking to migrate stuff to ARM and it wasn't very quick. >>>>=20 >>>> I plan on fixing the TCP/IP stack to copy data to an aligned buffer >>>> (maybe only if the original buffer isn't aligned) on the stack when >>>> __NO_STRICT_ALIGNMENT is not defined... I can't see how copying = the >>>> entire packet is cheaper than copying 20 bytes or so... >>>=20 >>> There's lots of other stupid corner cases that screw you. >>>=20 >>> VLAN headers add extra bytes. >>>=20 >>> 802.11 headers can offset things depending upon the 802.11 frame = type >>> (3-addr, 4-addr, vlan, no vlan, etc.) >>>=20 >>> There's no guarantee all ethernet DMA engines can do the alignment = as >>> required. :( >>=20 >> The ate driver for Atmel?s AT91RM9200 is one such beast. >=20 > Are you sure? The tag for data says alignment 1: > if (bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0, > BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, = MCLBYTES, > 1, MCLBYTES, 0, busdma_lock_mutex, &sc->sc_mtx, &sc->mtag)) >=20 > Or is that a limitation on the parent? It is a limitation in hardware. You have to DMA to a 4 byte boundary. = That might be a bug in the above line though=85 Warner > I did an audit of the arm drivers (not mips), but I didn't see any = that > have the restriction... The one that I'm thinking of was the Cirrus > EP9302 in the TS-7200 port that I did years ago.. --Apple-Mail=_FC3C17ED-70FE-4F36-B52F-701032B569AD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTsD/3AAoJEGwc0Sh9sBEAPEkP/2nWdgA6WJQzATfBDtpFYbBQ lvh6B4Updblfehjknav+Pt+kGp3LSR15Ev5BDHeffjMZt/HLJkG2yyaSiwS+QdSZ D9WMLPFeX+gJfNkul2/STV0XUwv/fcflRyYr2LaNnvccnPqvWRM8bZ++hLgssZmc CG9JTSq6mygTQwel/zISOiJRbAhEKa5iQ7UjvB1Ropli08QgMOJr/DkGQChe3fYU kg0KQXElRC5ser/W0vKTxM7pL4S5ITctXeKV+gMbg9CzxwgbM4Y+sDpqXh8e18kC oMx2B2DOQUgxycV5cO5p2srrz62VRklQmbTZhd2y6NfJjgjCPM1m6l/1Ek39lQ6b rW0Ct40i2R6dlMP/1UnwCV9piVA0Xy/eFr4kaQ04b4J/qadLo4rJlEFFBTD7cRu3 8knBYCuqggMlmOwXBrDV3w9YS845R+kSpHwMB2KvFShmD1AKioauGOmomo2oS1ec jwTAFohxRoF1rZi92I+6VzVN7RfdZI5Oq1LXuJHc5BbiKqre50GxYad/HVlIFji6 qPOrFSvZiAL0TJbR0KK9+heidF1Iq2neQl8MIsjZ0bWA9JbCsSHV/avIaH71UG9R qudby5xCMQpwaIc7EYed/UcV+18SBaQP1kyRcUdWJGacZG34WYWuH/emNxh2Ns2p dStTWQa0/mjvzC6drmU7 =Gi2m -----END PGP SIGNATURE----- --Apple-Mail=_FC3C17ED-70FE-4F36-B52F-701032B569AD-- From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 17:57:48 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E0F7964; Sun, 29 Jun 2014 17:57:48 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BE412C23; Sun, 29 Jun 2014 17:57:47 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id mc6so4298240lab.27 for ; Sun, 29 Jun 2014 10:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=s3S9MGdkayLGmg9ljUSbH1FE2eENoT7dIZOwagTSVIg=; b=pHNP9x1fgi7S6lkRk6L5ji5ggZr/fFlzlLyg/xqPITv9Tov+TYNywtfQ5Df1EBOycM XPHUxVZdzy2tdQL90PIZ4CtLsVykEyFiSuxt7wQM92/nkrBspEs4zWG+DDJhx3D/YSgz b9wTZ3573UuoZpwcxZDeoHdCEUZNzQodCd5+AFMPRDoOv/wTGH85UtC5oALPMUKKiK5i tJrWyhGtf9Ii7EJ6Lz6VsWela8Qi7i5hxPeQFvO9PHEQAAfgMBRIt/9dvzaBHogwIq9E BHux7lyrcHeyRV0osfRsej546ffOUGMxF5JTRJhvp7StM0h3+ao2rTH9FAEffbT+GueE R3ag== MIME-Version: 1.0 X-Received: by 10.152.204.102 with SMTP id kx6mr27632805lac.32.1404064665332; Sun, 29 Jun 2014 10:57:45 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.22.232 with HTTP; Sun, 29 Jun 2014 10:57:45 -0700 (PDT) In-Reply-To: <20140629040150.GO1560@funkthat.com> References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> Date: Sun, 29 Jun 2014 13:57:45 -0400 X-Google-Sender-Auth: i1bMgpTEX36PHRNCZrUIpyC66Ig Message-ID: Subject: Re: arm alignment faults... From: Patrick Kelsey To: Adrian Chadd , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 17:57:48 -0000 On Sun, Jun 29, 2014 at 12:01 AM, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700: > > On 28 June 2014 20:38, John-Mark Gurney wrote: > > > So, one of the little projects I'd like to see is the removal of > > > ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use > > > of bouncing durning DMA ops on all ethernet frames... > > Now that I think about it, total removal may not be necessary, just > the requirement to use it... If the ethernet dma engine can do half > word aligned dma, then there would be benifit on those to keep > ETHER_ALIGN... > > > Well, as long as you're not doing it by forcing the various CPUs to > > handle unaligned accesses. > > Hard to do on armv4 which I don't believe supports unaligned access... > > > The cost of those unaligned accesses on some CPUs that support them is > > not trivial. We benchmarked some of the ARM cores at Qualcomm back > > when looking to migrate stuff to ARM and it wasn't very quick. > > I plan on fixing the TCP/IP stack to copy data to an aligned buffer > (maybe only if the original buffer isn't aligned) on the stack when > __NO_STRICT_ALIGNMENT is not defined... I can't see how copying the > entire packet is cheaper than copying 20 bytes or so... > > I like the idea of getting away from the concept of ETHER_ALIGN. This will also be nice when feeding the TCP/IP stack using netmap. There's no facility in netmap for landing receive data at an offset in the word-aligned ring buffer, so using netmap to receive frames for the TCP/IP stack relies on unaligned access support from the platform. For platforms where there is not unaligned access support, or it comes with a noticeable penalty, it would become easier to consider using a netmap + TCP/IP stack approach to some problems. I wonder if it's really worth having the copy action be conditional on an alignment check - it seems to me the cycle savings would be modest at best for the half-word-aligned-capable ethernet dma engine crowd, at the cost of having two different header access paths in the code. Also, getting away from the current business of modifying the mbuf via in-place header byteswaps will make the stack friendlier for building things that inspect packets up through tcp headers/connection lookup and then possibly decide to bridge them out some interface as a result (as then in such cases, one won't have to ever unwind the changes to mbuf contents). If I'm thinking about this right, pr_input_t will have to grow a new parameter to support passing the on-stack IP header pointer along. I suppose this could be considered a generic 'encapsulation header' pointer, so as not to taint the protosw interface with something ip-specific. -Patrick From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 19:00:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0FBD4B7 for ; Sun, 29 Jun 2014 19:00:40 +0000 (UTC) Received: from nm27-vm8.bullet.mail.ir2.yahoo.com (nm27-vm8.bullet.mail.ir2.yahoo.com [212.82.97.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E0F4210D for ; Sun, 29 Jun 2014 19:00:40 +0000 (UTC) Received: from [212.82.98.56] by nm27.bullet.mail.ir2.yahoo.com with NNFMP; 29 Jun 2014 18:57:25 -0000 Received: from [212.82.98.101] by tm9.bullet.mail.ir2.yahoo.com with NNFMP; 29 Jun 2014 18:57:25 -0000 Received: from [127.0.0.1] by omp1038.mail.ir2.yahoo.com with NNFMP; 29 Jun 2014 18:57:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 707694.28998.bm@omp1038.mail.ir2.yahoo.com Received: (qmail 59317 invoked by uid 60001); 29 Jun 2014 18:57:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1404068245; bh=Zo1WCk1ibFVj4IhYaJS7Cf2konxj+BydWtNIjnLHbVM=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=PcuHFG9+kYALg4r7TVSy55jyaiZ1IOIs82hczs5xSKf2pVfZ17kZUbvzm30Je6GdiPPvsgty0ffeFtLEGJX+aRmt9LH2cDfynQP2i57uDVur1tN+wCjQwkJZFY5IADXjchoR92+GaRXLkwXGVH95UHFfOoz26yTd24w2s6VA6SU= X-YMail-OSG: CewvwQ8VM1nJiiYPy_Z_D_Hs3br0QrdkT.au8gpeCKbHZsb HiKijinwv7F1H7lUA44WCbXCqv4nQsPWpAA6C1dzCn0vanOwq1q1fiWdCKzj bOjVFGdHoSJvm0ElkayInqe9LM9.hffaqAZdbiYfwOi84lFWmggBockNjJzH g.SLGxj00m3wB3ygTw7j519XnimRVdLJ_BXxZQ6zm81YZkYro3VprndPvgIW EO2zg32BskEPSYwGJESESynVbQoNZn7umbtaKHEaIFSsJ0FHaKUwq82AAdfv FHTzeFiee_BpC1xnATaEnquHSrL50NEyEH7KY0Gd_SGjNoFx7W_CPeLzjjkq An7UnU84jDcZTRZeDNqwDl31b8QG1wWOABrTZP9ffewliItfj4KrnnQ2FmzG r07nr2bk2l21_DolluhHWd0N0AkZsk7ee2nw0H3W.ZBEQfrq7N7MW6YZ7XUm iXi6S8CcaDvRAwTYpgwvUYEbdpe9_Wp4BxCqScdSbiXJ3zeAL_qcm4VZXXLU BcE_amfOyrXzlWQC7SzWk8dsMFVEtoGUATNhyR6mdYct9rNuCNNAr Received: from [92.254.163.13] by web172801.mail.ir2.yahoo.com via HTTP; Sun, 29 Jun 2014 19:57:25 BST X-Rocket-MIMEInfo: 002.001, SGVsbG8sCkkgYW0gdXNpbmcgRnJlZUJTRCA4LjIgaW4gYSBNYXJ2ZWwgIGFybSBjcHUgKG12NzgxMDApLgpJIGFtCiBoYXZpbmcgYSBwcm9ibGVtIHdoaWxlIHdyaXRpbmcgaW50byBzb21lIEdQSU9zICB0aHJvdWdoIHRoZSBJMkMsIHRoZSAKcHJvYmxlbSBpcyB0aGF0IGl0IHRha2VzIHZlcnkgbG9uZyB0aW1lICgxMCBtc2VjKSBmb3Igd3JpdGluZyAyIGJ5dGVzLiBJCiBjYW4gc2VlIHRoYXQgdGhlIGRyaXZlciB0d3NpLmMgbWFrZXMgIHZlcnkgbG9uZyBERUxBWSAoMSBtc2VjIHggc2V2ZXJhbCB0aW1lcywBMAEBAQE- X-Mailer: YahooMailWebService/0.8.191.1 Message-ID: <1404068245.38508.YahooMailNeo@web172801.mail.ir2.yahoo.com> Date: Sun, 29 Jun 2014 19:57:25 +0100 From: Tony Moseby Reply-To: Tony Moseby Subject: i2c To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 19:00:41 -0000 Hello,=0AI am using FreeBSD 8.2 in a Marvel arm cpu (mv78100).=0AI am=0A h= aving a problem while writing into some GPIOs through the I2C, the =0Aprob= lem is that it takes very long time (10 msec) for writing 2 bytes. I=0A can= see that the driver twsi.c makes very long DELAY (1 msec x several times,= during a byte writing). Does any one know what is the reason for those del= ays?=0AThanks.=0A From owner-freebsd-arm@FreeBSD.ORG Sun Jun 29 20:27:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 218CB318 for ; Sun, 29 Jun 2014 20:27:04 +0000 (UTC) Received: from nm15-vm8.bullet.mail.ir2.yahoo.com (nm15-vm8.bullet.mail.ir2.yahoo.com [212.82.96.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7081226E6 for ; Sun, 29 Jun 2014 20:27:02 +0000 (UTC) Received: from [212.82.98.53] by nm15.bullet.mail.ir2.yahoo.com with NNFMP; 29 Jun 2014 20:24:38 -0000 Received: from [212.82.98.111] by tm6.bullet.mail.ir2.yahoo.com with NNFMP; 29 Jun 2014 20:24:38 -0000 Received: from [127.0.0.1] by omp1048.mail.ir2.yahoo.com with NNFMP; 29 Jun 2014 20:24:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 93205.25966.bm@omp1048.mail.ir2.yahoo.com Received: (qmail 66696 invoked by uid 60001); 29 Jun 2014 20:24:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1404073478; bh=9pacPc/NNuw/qI/705Fy/d4MJpVOVZl7DSJHnZm2IqU=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=a/vgiXatFAVD90/X9NSonZHss3SblZUF+kuVTUvtc6S/K5WfIfZUeBjxUsrDZ4tSHLke10O7yw+ha3GWFqLU7fGJgKdoD0BG7DNMamVcCgxSU2GINm3swY0y2zvDWBuSq1IZ1BCTPD5L3C0uH0xokaHKyjiGcc6km+CQOC0Pgvc= X-YMail-OSG: kwImZqQVM1k84CIwDJhMsOLio04bNrM6KcCklTCa82AE1cq SuPYDhRNH9IWwnS5WrFwkRcWQEoddew9OKJImhVQjjCOAjDt8.uuWaoF8v4t UOBCuYuI3zkTWyGIDaCST2auVwTyyOuNcD4yjjDeSwtVEgdejhLIL8aR8dhj X7oynnjyCywpixsVV.jR_3Wz7WdToEVY6u7gfEOcO_cXcCsNKWewGvJBx6Oq 8nlljKezVvWpiGZkEEwS7y4ULt05EwbXCeTKWh7IN6C_l3gfe6chKy4GM4CZ mT1YfDInnKO9AWpXvh1OSzwBP2OipGrY1a.yLxAQ5ctYBUQNKlF08exc17aY ARSv5LawJMt3THZW8kmRDJLZirPlZmeoJOxy1L8.ywUVWCWqMRwmXsIXfMsC EEC_eJvtNEsyQkDf2B.yylJlD5HJ0YXNjBPxoTi7QKzu.UfJhMKGCTaeC9wj XNwsvJfuAok2p6L738TkICMFlwBHHG8.OdTmwOUMud_fzz5AbbcjbyDreGNI e7ehJzTkxf__oPtHvlmnv6PGpoc54Uj8RClk6gjadj6.y.mDv6w-- Received: from [92.254.163.13] by web172804.mail.ir2.yahoo.com via HTTP; Sun, 29 Jun 2014 21:24:37 BST X-Rocket-MIMEInfo: 002.001, SGVsbG8sCkkgYW0gdXNpbmcgRnJlZUJTRCA4LjIgaW4gYSBNYXJ2ZWzCoCBhcm0gY3B1IChtdjc4MTAwKS4KSSBhbQpoYXZpbmcgYSBwcm9ibGVtIHdoaWxlIHdyaXRpbmcgaW50byBzb21lIEdQSU9zwqAgdGhyb3VnaCB0aGUgSTJDLCB0aGXCoApwcm9ibGVtIGlzIHRoYXQgaXQgdGFrZXMgdmVyeSBsb25nIHRpbWUgKDEwIG1zZWMpIGZvciB3cml0aW5nIDIgYnl0ZXMuIEkKY2FuIHNlZSB0aGF0IHRoZSBkcml2ZXIgdHdzaS5jIG1ha2VzwqAgdmVyeSBsb25nIERFTEFZICgxIG1zZWMgeCBzZXZlcmFsIHRpbWUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.191.1 Message-ID: <1404073477.9112.YahooMailNeo@web172804.mail.ir2.yahoo.com> Date: Sun, 29 Jun 2014 21:24:37 +0100 From: Tony Moseby Reply-To: Tony Moseby Subject: i2c To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:27:04 -0000 Hello,=0AI am using FreeBSD 8.2 in a Marvel=A0 arm cpu (mv78100).=0AI am=0A= having a problem while writing into some GPIOs=A0 through the I2C, the=A0= =0Aproblem is that it takes very long time (10 msec) for writing 2 bytes. I= =0Acan see that the driver twsi.c makes=A0 very long DELAY (1 msec x severa= l times, during a byte writing). Does any one know what is the reason for t= hose delays?=0AThanks.=0A From owner-freebsd-arm@FreeBSD.ORG Mon Jun 30 00:47:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E70C1AFA for ; Mon, 30 Jun 2014 00:47:36 +0000 (UTC) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B328228F0 for ; Mon, 30 Jun 2014 00:47:35 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id j17so8024698oag.38 for ; Sun, 29 Jun 2014 17:47:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=tBUPb1VX1g+1xFhi0wBeC5ROaX8NPAQq3JP/JcDttxI=; b=D1P10jBIqR2+7xza2CELYKjjX+0gT/+WZJbIoQJ2ANSi3+3UcwBfTtFDjKCqw7BWlM W/a+xMAEXPE7mvskMzrgU/8kVSCeySYxE54Hriiz2jwlK5HB/lanxQqfKFgEBw383/e9 NTy6//tjfZHFSY0A68BGnGXzW/6ySj4/pfAixOJ0xOLd1aqGpy3GTQF5oqsPJM7maLaM Nm8OAqzqn5XrGkIX4b5p2gOYC+Ek246cpxywKwxUmNwu20UGODJMrBxxHNlR6YlFG25H 9bNeU58xfrSGKkQV19JQ1Yg0m8mnrfZM5U0rUPci5upY7eTDCMPKFjVYerCXiQn3ppfq H7OQ== X-Gm-Message-State: ALoCoQlCuB2/H0HU9MWSe8fpX7xu1qQZj7pIfw6Roryhj31taG5BrqC5oGCARaiQelvpcnZV8/5H MIME-Version: 1.0 X-Received: by 10.60.65.170 with SMTP id y10mr17284352oes.45.1404089249114; Sun, 29 Jun 2014 17:47:29 -0700 (PDT) Received: by 10.182.96.101 with HTTP; Sun, 29 Jun 2014 17:47:29 -0700 (PDT) Date: Sun, 29 Jun 2014 18:47:29 -0600 Message-ID: Subject: Status of iic on wandboard From: Tom Everett To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 00:47:37 -0000 I see that there is an i2c driver for imx on the source tree, and there are iic kernel options in /conf/IMX6, commented out. Does anyone know the status of i2c for IMX? -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Jun 30 13:11:59 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61FB644D for ; Mon, 30 Jun 2014 13:11:59 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E0BB25F6 for ; Mon, 30 Jun 2014 13:11:58 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s5UDBcCO040903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Jun 2014 15:11:39 +0200 (CEST) (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 s5UDBSL1037823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2014 15:11:28 +0200 (CEST) (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 s5UDBSXK056097; Mon, 30 Jun 2014 15:11:28 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s5UDBQat056096; Mon, 30 Jun 2014 15:11:26 +0200 (CEST) (envelope-from ticso) Date: Mon, 30 Jun 2014 15:11:26 +0200 From: Bernd Walter To: Warner Losh Subject: Re: arm alignment faults... Message-ID: <20140630131126.GB55631@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> <20140629054039.GP1560@funkthat.com> <039F8A84-0193-424C-8093-E411957817E9@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <039F8A84-0193-424C-8093-E411957817E9@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 13:11:59 -0000 On Sun, Jun 29, 2014 at 10:33:59AM -0600, Warner Losh wrote: > > On Jun 28, 2014, at 11:40 PM, John-Mark Gurney wrote: > > > Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600: > >> > >> On Jun 28, 2014, at 10:52 PM, Adrian Chadd wrote: > >> > >>> On 28 June 2014 21:01, John-Mark Gurney wrote: > >>>> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700: > >>>>> On 28 June 2014 20:38, John-Mark Gurney wrote: > >>>>>> So, one of the little projects I'd like to see is the removal of > >>>>>> ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use > >>>>>> of bouncing durning DMA ops on all ethernet frames... > >>>> > >>>> Now that I think about it, total removal may not be necessary, just > >>>> the requirement to use it... If the ethernet dma engine can do half > >>>> word aligned dma, then there would be benifit on those to keep > >>>> ETHER_ALIGN... > >>>> > >>>>> Well, as long as you're not doing it by forcing the various CPUs to > >>>>> handle unaligned accesses. > >>>> > >>>> Hard to do on armv4 which I don't believe supports unaligned access... > >>>> > >>>>> The cost of those unaligned accesses on some CPUs that support them is > >>>>> not trivial. We benchmarked some of the ARM cores at Qualcomm back > >>>>> when looking to migrate stuff to ARM and it wasn't very quick. > >>>> > >>>> I plan on fixing the TCP/IP stack to copy data to an aligned buffer > >>>> (maybe only if the original buffer isn't aligned) on the stack when > >>>> __NO_STRICT_ALIGNMENT is not defined... I can't see how copying the > >>>> entire packet is cheaper than copying 20 bytes or so... > >>> > >>> There's lots of other stupid corner cases that screw you. > >>> > >>> VLAN headers add extra bytes. > >>> > >>> 802.11 headers can offset things depending upon the 802.11 frame type > >>> (3-addr, 4-addr, vlan, no vlan, etc.) > >>> > >>> There's no guarantee all ethernet DMA engines can do the alignment as > >>> required. :( > >> > >> The ate driver for Atmel?s AT91RM9200 is one such beast. > > > > Are you sure? The tag for data says alignment 1: > > if (bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0, > > BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES, > > 1, MCLBYTES, 0, busdma_lock_mutex, &sc->sc_mtx, &sc->mtag)) > > > > Or is that a limitation on the parent? > > It is a limitation in hardware. You have to DMA to a 4 byte boundary. That might be a bug in the above line though? It is a limitation of the AT91RM9200. More recent ate hardware (e.g. AT91SAM9260) don't have this limitation. > > I did an audit of the arm drivers (not mips), but I didn't see any that > > have the restriction... The one that I'm thinking of was the Cirrus > > EP9302 in the TS-7200 port that I did years ago.. > -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Jun 30 17:41:24 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23493BC1 for ; Mon, 30 Jun 2014 17:41:24 +0000 (UTC) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D97A02115 for ; Mon, 30 Jun 2014 17:41:23 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id at1so7316593iec.28 for ; Mon, 30 Jun 2014 10:41:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8zk5+Rx9Huu17VehQnoc5nMKpEME7kCaRt14oSEiaOk=; b=NVMu30pweezYf1+dirtnjj6OoRxw8NSCyRnoJljTwzHDcpsSLxBhRdlBcqX7uGqhH6 NxC9mIObYU0dI7Y9oTw0fMwvmDxaiCOupWtcpC/SPefn8we64Of2lJX093oZUGeH3Q80 EzoW+oUMMSvsIWU80zWGVw/oSuE/njnCsEGtnMuoJHYeVYq3g6jSD898RWwH7RR7Gb9d 6bDtxmpY8QP7LjKtn8/rzwbjJCYlw1LlDnoUKVgsuR0V4DlMQKNG/rMWySnYyw1U+2Gw wksTdojYbttliecXxJVqEhpc/52Mff0YSfB+13B3QtZC898nOAwN95F006z8F+A0yOMy o4nA== X-Gm-Message-State: ALoCoQmOTSThy6aP5sEq42Z2RjwfDtOxyxJhXZ2pjtoFJgDFi7wnVzEPPlKfqMOvJ6J8/SgneYoV X-Received: by 10.42.203.202 with SMTP id fj10mr3960339icb.86.1404150077769; Mon, 30 Jun 2014 10:41:17 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id o2sm26585704igp.12.2014.06.30.10.41.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 10:41:17 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: arm alignment faults... From: Warner Losh In-Reply-To: <20140630131126.GB55631@cicely7.cicely.de> Date: Mon, 30 Jun 2014 11:41:25 -0600 Message-Id: <31EF05A5-0886-4F5C-97BB-2EF749533633@bsdimp.com> References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> <20140629054039.GP1560@funkthat.com> <039F8A84-0193-424C-8093-E411957817E9@bsdimp.com> <20140630131126.GB55631@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 17:41:24 -0000 --Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 30, 2014, at 7:11 AM, Bernd Walter = wrote: > On Sun, Jun 29, 2014 at 10:33:59AM -0600, Warner Losh wrote: >>=20 >> On Jun 28, 2014, at 11:40 PM, John-Mark Gurney = wrote: >>=20 >>> Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600: >>>>=20 >>>> On Jun 28, 2014, at 10:52 PM, Adrian Chadd = wrote: >>>>=20 >>>>> On 28 June 2014 21:01, John-Mark Gurney wrote: >>>>>> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 = -0700: >>>>>>> On 28 June 2014 20:38, John-Mark Gurney = wrote: >>>>>>>> So, one of the little projects I'd like to see is the removal = of >>>>>>>> ETHER_ALIGN from the tree.. This bogosity can (and does) cause = the use >>>>>>>> of bouncing durning DMA ops on all ethernet frames... >>>>>>=20 >>>>>> Now that I think about it, total removal may not be necessary, = just >>>>>> the requirement to use it... If the ethernet dma engine can do = half >>>>>> word aligned dma, then there would be benifit on those to keep >>>>>> ETHER_ALIGN... >>>>>>=20 >>>>>>> Well, as long as you're not doing it by forcing the various CPUs = to >>>>>>> handle unaligned accesses. >>>>>>=20 >>>>>> Hard to do on armv4 which I don't believe supports unaligned = access... >>>>>>=20 >>>>>>> The cost of those unaligned accesses on some CPUs that support = them is >>>>>>> not trivial. We benchmarked some of the ARM cores at Qualcomm = back >>>>>>> when looking to migrate stuff to ARM and it wasn't very quick. >>>>>>=20 >>>>>> I plan on fixing the TCP/IP stack to copy data to an aligned = buffer >>>>>> (maybe only if the original buffer isn't aligned) on the stack = when >>>>>> __NO_STRICT_ALIGNMENT is not defined... I can't see how copying = the >>>>>> entire packet is cheaper than copying 20 bytes or so... >>>>>=20 >>>>> There's lots of other stupid corner cases that screw you. >>>>>=20 >>>>> VLAN headers add extra bytes. >>>>>=20 >>>>> 802.11 headers can offset things depending upon the 802.11 frame = type >>>>> (3-addr, 4-addr, vlan, no vlan, etc.) >>>>>=20 >>>>> There's no guarantee all ethernet DMA engines can do the alignment = as >>>>> required. :( >>>>=20 >>>> The ate driver for Atmel?s AT91RM9200 is one such beast. >>>=20 >>> Are you sure? The tag for data says alignment 1: >>> if (bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0, >>> BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, = MCLBYTES, >>> 1, MCLBYTES, 0, busdma_lock_mutex, &sc->sc_mtx, = &sc->mtag)) >>>=20 >>> Or is that a limitation on the parent? >>=20 >> It is a limitation in hardware. You have to DMA to a 4 byte boundary. = That might be a bug in the above line though? >=20 > It is a limitation of the AT91RM9200. > More recent ate hardware (e.g. AT91SAM9260) don't have this = limitation. Yea, the problem is that the packet has to start on a % 4 =3D=3D = 0boundary, which means the ether header is aligned, but nothing else in = the IP header is aligned, so bad things happen. The lame thing we did in = the ate driver was to copy the whole packet. A smarter thing to do would = be to just do a m_pullup() of the IP header. The even smarter thing to = do is to limit this to the AT91RM9200, or make the ate driver at91rm9200 = only and fix the macb(4) driver which currently doesn=92t work at all = for the boards I have. On the SAM9 SoCs we can do a smart thing and have = the DMA start % 4 =3D=3D 2, which naturally aligns the headers that are = assumed to be naturally aligned, at least in the NFS root boot code = (which IIRC was the only thing I hit where any of this matters). Warner --Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTsaFFAAoJEGwc0Sh9sBEAFDIP/2CD46M1/Utd827ZghHHxJRW AeH/MDqx9oDzxgdt0WFfOTa9WK8Got3QHmgPCnLRb3jB/d8XHe1g3ElNK5LkyviK 7UDt38I+pU8ICbJNRGWnE3nyMYY9FB+0WHUBsfJYYJLFfF8ZfDnhWXCxvOGvaQsX Ew8AhJ6FQFrNZR8ifZVZBroJTg89MLKhp9MeLIeNjdHR4yo5uri8cmOt4mkfujsy hw5L+CduCThYUD/wO4mZ0Lj0xKbpwTF+uiX9qK+QDF7COiWXC98qpntjmfh3AXOE S0qZTZ8aq7J4r6Nc4CjhUOAX7PeM2Idy53lDpo8AfPbM5tL2xz/23/nztKM8+1Uk 8clS82NCveUCW/4ijvyXdDS8GAkhIXjZfA1TzL5yTOiaRCMD6neEi/heDi9xxJQA wD6F7uLONguMBK3nQhZiQqdIaly0jQjjo4dndm26E8wK3LKGXyLrGI3QySyI6nU8 pbNsvavq8awboBnU8OLP5JgfeRN6kD50CcRvbXruSFP5D887IBYt+HKcF8bMm578 j4Y6ae1VNjbSbu0zFaqHRvzB9EQSNlcM3XMT2GvnauwNSai7fB+PAo3pfKI1Afsn 86Yq4r6HEf9V4Hxn+WX3c6iO0uvDnGYjs+9cdpjqEtS/PQQcpkOzBMQkI2am8Mmt KYIrPS1y7lEe3gn42hoj =pPNx -----END PGP SIGNATURE----- --Apple-Mail=_30CFD111-0A1A-4EF4-BD68-ABB421ACB224-- From owner-freebsd-arm@FreeBSD.ORG Mon Jun 30 18:02:20 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23B10519 for ; Mon, 30 Jun 2014 18:02:20 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A35972362 for ; Mon, 30 Jun 2014 18:02:19 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s5UI2944045419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Jun 2014 20:02:09 +0200 (CEST) (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 s5UI24Re040113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2014 20:02:04 +0200 (CEST) (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 s5UI24FC057332; Mon, 30 Jun 2014 20:02:04 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s5UI23Ne057331; Mon, 30 Jun 2014 20:02:03 +0200 (CEST) (envelope-from ticso) Date: Mon, 30 Jun 2014 20:02:03 +0200 From: Bernd Walter To: Warner Losh Subject: Re: arm alignment faults... Message-ID: <20140630180203.GE55631@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140629033823.GN1560@funkthat.com> <20140629040150.GO1560@funkthat.com> <86E20F1C-C161-45B2-AC82-11738596E004@bsdimp.com> <20140629054039.GP1560@funkthat.com> <039F8A84-0193-424C-8093-E411957817E9@bsdimp.com> <20140630131126.GB55631@cicely7.cicely.de> <31EF05A5-0886-4F5C-97BB-2EF749533633@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31EF05A5-0886-4F5C-97BB-2EF749533633@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:02:20 -0000 On Mon, Jun 30, 2014 at 11:41:25AM -0600, Warner Losh wrote: > > On Jun 30, 2014, at 7:11 AM, Bernd Walter wrote: > > > On Sun, Jun 29, 2014 at 10:33:59AM -0600, Warner Losh wrote: > >> > >> On Jun 28, 2014, at 11:40 PM, John-Mark Gurney wrote: > >> > >>> Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600: > >>>> > >>>> On Jun 28, 2014, at 10:52 PM, Adrian Chadd wrote: > >>>> > >>>>> On 28 June 2014 21:01, John-Mark Gurney wrote: > >>>>>> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700: > >>>>>>> On 28 June 2014 20:38, John-Mark Gurney wrote: > >>>>>>>> So, one of the little projects I'd like to see is the removal of > >>>>>>>> ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use > >>>>>>>> of bouncing durning DMA ops on all ethernet frames... > >>>>>> > >>>>>> Now that I think about it, total removal may not be necessary, just > >>>>>> the requirement to use it... If the ethernet dma engine can do half > >>>>>> word aligned dma, then there would be benifit on those to keep > >>>>>> ETHER_ALIGN... > >>>>>> > >>>>>>> Well, as long as you're not doing it by forcing the various CPUs to > >>>>>>> handle unaligned accesses. > >>>>>> > >>>>>> Hard to do on armv4 which I don't believe supports unaligned access... > >>>>>> > >>>>>>> The cost of those unaligned accesses on some CPUs that support them is > >>>>>>> not trivial. We benchmarked some of the ARM cores at Qualcomm back > >>>>>>> when looking to migrate stuff to ARM and it wasn't very quick. > >>>>>> > >>>>>> I plan on fixing the TCP/IP stack to copy data to an aligned buffer > >>>>>> (maybe only if the original buffer isn't aligned) on the stack when > >>>>>> __NO_STRICT_ALIGNMENT is not defined... I can't see how copying the > >>>>>> entire packet is cheaper than copying 20 bytes or so... > >>>>> > >>>>> There's lots of other stupid corner cases that screw you. > >>>>> > >>>>> VLAN headers add extra bytes. > >>>>> > >>>>> 802.11 headers can offset things depending upon the 802.11 frame type > >>>>> (3-addr, 4-addr, vlan, no vlan, etc.) > >>>>> > >>>>> There's no guarantee all ethernet DMA engines can do the alignment as > >>>>> required. :( > >>>> > >>>> The ate driver for Atmel?s AT91RM9200 is one such beast. > >>> > >>> Are you sure? The tag for data says alignment 1: > >>> if (bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0, > >>> BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES, > >>> 1, MCLBYTES, 0, busdma_lock_mutex, &sc->sc_mtx, &sc->mtag)) > >>> > >>> Or is that a limitation on the parent? > >> > >> It is a limitation in hardware. You have to DMA to a 4 byte boundary. That might be a bug in the above line though? > > > > It is a limitation of the AT91RM9200. > > More recent ate hardware (e.g. AT91SAM9260) don't have this limitation. > > Yea, the problem is that the packet has to start on a % 4 == 0boundary, which means the ether header is aligned, but nothing else in the IP header is aligned, so bad things happen. The lame thing we did in the ate driver was to copy the whole packet. A smarter thing to do would be to just do a m_pullup() of the IP header. The even smarter thing to do is to limit this to the AT91RM9200, or make the ate driver at91rm9200 only and fix the macb(4) driver which currently doesn?t work at all for the boards I have. On the SAM9 SoCs we can do a smart thing and have the DMA start % 4 == 2, which naturally aligns the headers that are assumed to be naturally aligned, at least in the NFS root boot code (which IIRC was the only thing I hit where any of this matters). Worse of all I had been using a switch chip with VLAN trunk to the RM9200. However those boards worked fine besides of several hardware drawbacks on the RM9200. One of those boards is still running my home automation with amazing 1283 days uptime. In the meantime I'm trying to switch over to Wandboard Modules. If anyone needs a GNU PCB EDM header footprint for vendor supplied Foxconn sockets, just mail me. I've done one last week, but it is not tested in real hardware so far. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Jul 1 09:25:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD860CB7 for ; Tue, 1 Jul 2014 09:25:50 +0000 (UTC) Received: from eu1sys200aog129.obsmtp.com (eu1sys200aog129.obsmtp.com [207.126.144.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A3002976 for ; Tue, 1 Jul 2014 09:25:49 +0000 (UTC) Received: from mail-wi0-f182.google.com ([209.85.212.182]) (using TLSv1) by eu1sys200aob129.postini.com ([207.126.147.11]) with SMTP ID DSNKU7J+gBVONHiTdS4wK05a/9pIhh8r0nrm@postini.com; Tue, 01 Jul 2014 09:25:50 UTC Received: by mail-wi0-f182.google.com with SMTP id bs8so7327228wib.9 for ; Tue, 01 Jul 2014 02:25:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=xzOTapa808LuUVtZJ/DXhyAjGUxDOs0XVYlPCU55agQ=; b=MPOXnjl5U1ZakVRLMr4GwfZhQdv0EsmZp+Z7poy1idsAbArmbxXHtOO6LmjX1/weiB JOLzAhUR26p+BVqcHIoRPja9WN+T7LzX0jcz8+NGG/BP67AmA3+5j6BEsvCiOVA4KYN4 LwryU5yGtMVyNSxWtAiqCKHVfs8i7X2Isj6xa6xdrrZAcGPcnBy0dgHyhOxlz4avaAc0 Ktzbi5clsTjOCM8JwcEpe236FdkxJroYBbM9h63KOGsQ6RCSzyi2EaSAamU7nOCJqQpU V6f8OrdBE28cSMzF15h5vBACA7wAug6gaV2t6mu4KxPEpKoj5KV9+zaDO90tVSNucKD4 0zQQ== X-Gm-Message-State: ALoCoQlaOl+lpOg1AIfGnu4Mnwu2yvbDAEj5RsEZmpzGhSM9Lc/Ju664xImGfgOLWdU3cRyIXUnoeUeZHnZP+OKcO9rKqNtOCdW6b3a0yQAdEBMtNM/Hw2ARTYa1uxXET/pOZNyh9rYy X-Received: by 10.194.63.228 with SMTP id j4mr50450887wjs.7.1404206720084; Tue, 01 Jul 2014 02:25:20 -0700 (PDT) X-Received: by 10.194.63.228 with SMTP id j4mr50450877wjs.7.1404206719980; Tue, 01 Jul 2014 02:25:19 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id 19sm46969479wjz.3.2014.07.01.02.25.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Jul 2014 02:25:19 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s619PIXX006680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 1 Jul 2014 10:25:18 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s619PHeT006679 for freebsd-arm@freebsd.org; Tue, 1 Jul 2014 10:25:17 +0100 (BST) (envelope-from mexas) Date: Tue, 1 Jul 2014 10:25:17 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: /tmp, /var/log, /var/tmp as /dev/md - why? Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 09:25:50 -0000 Why is it a good idea to mount /tmp and some var dirs on memory disks: root@raspberry-pi:/usr/ports # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/mmcsd0s2a 14694 777 12742 6% / devfs 0 0 0 100% /dev /dev/mmcsd0s1 16 3 13 20% /boot/msdos /dev/md0 28 4 22 16% /tmp /dev/md1 14 0 12 0% /var/log /dev/md2 4 0 4 0% /var/tmp root@raspberry-pi:/usr/ports # Is this about speed or power, or maybe space? Can I not put all these dirs on sd card? I'm new to arm, so maybe things are different to other arches. Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Tue Jul 1 09:30:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7113DD46 for ; Tue, 1 Jul 2014 09:30:56 +0000 (UTC) Received: from eu1sys200aog105.obsmtp.com (eu1sys200aog105.obsmtp.com [207.126.144.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4CB02A0B for ; Tue, 1 Jul 2014 09:30:55 +0000 (UTC) Received: from mail-we0-f169.google.com ([74.125.82.169]) (using TLSv1) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP ID DSNKU7J/yN/HX1h/+N5Zmtu0QJSNHNAVkiKr@postini.com; Tue, 01 Jul 2014 09:30:55 UTC Received: by mail-we0-f169.google.com with SMTP id t60so9425936wes.28 for ; Tue, 01 Jul 2014 02:30:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=8J2Hgfps8MrGDbZpUU7qUau7YjgfhPDti81OVozs8m0=; b=bzTUw0dehJidPykVbQte2f7zpuLYBBdgKCuZmDbw6GtG76AFkrQAOojyOy9e7vzClL 39xsmw67UXQpUPkBgzUZpQFjnwR3KQ4Op0SbLIW/OL9xNNandUNrubDCJTNaW9bGemIB 3hkPKUi7B+h5SNjcHJuVF1R/i9z2UtkLYNwx8HP4ahpFkjZX11oWymHzAc7dSBcm6+yC wsRyJGdnPsC7cVghzkZdm6NMnREl2IPDiMguY4T5d80A8xk4kvPU51SMXEyNeJE5U1+w X/B+QIEbKFlhWlweGlHNrpgg0Kt6ixPYXJ6hgnpjLgaRHCFG4ZS2+40xrbSvOEjZGkmT Fs3A== X-Gm-Message-State: ALoCoQlYq/IA21VmdEmbqPFU6yZcfExhguV3Iv6Lgw72PRKKtXmue2dVGJQOOXoNX28V8PGCkJ9cnbY9x/4ZRpx0F9aK38gcwSCRUxHCxv96XeM+I2ZdBHRrU0+42z/HryeuUFjyeS33 X-Received: by 10.194.10.69 with SMTP id g5mr1820261wjb.116.1404207048130; Tue, 01 Jul 2014 02:30:48 -0700 (PDT) X-Received: by 10.194.10.69 with SMTP id g5mr1820252wjb.116.1404207048048; Tue, 01 Jul 2014 02:30:48 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id q11sm41271428wib.14.2014.07.01.02.30.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Jul 2014 02:30:47 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s619UkjC006690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 1 Jul 2014 10:30:46 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s619Uk9X006689 for freebsd-arm@freebsd.org; Tue, 1 Jul 2014 10:30:46 +0100 (BST) (envelope-from mexas) Date: Tue, 1 Jul 2014 10:30:46 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407010930.s619Uk9X006689@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: svnlite segfaults a lot Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 09:30:56 -0000 # uname -a FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267801: Tue Jun 24 11:03:28 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm I'm trying to pull the ports tree to rasp. pi model B. svnlite up (or co) segfaults after pulling 1-5 MB. Is this expected? I'm powering via a bench power supply, so I can monitor the current. It is only about 400mA, occasionally raising to maybe 450mA. So my earlier suspicion, that an inadequate power was to blame, was wrong. Anybody else seeing svnlite segfaults? Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Tue Jul 1 09:43:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFBFE2BA for ; Tue, 1 Jul 2014 09:43:54 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7896D2B4B for ; Tue, 1 Jul 2014 09:43:54 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id m1so10158753oag.19 for ; Tue, 01 Jul 2014 02:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/8rzmNCP5/qd7HmLmhtSNTQCRLuFtHMggX0Uqrt1w20=; b=mquTAD4rReqYeX9BJFrYBbm49Ye9c3L54JXNV4YhfdsAfZcWXPZwxhESWxBK5MjLgB scl/kS39jzrh7YsT4NLGU/1S9ob9etUPbwOf4P1aRWDiAz/Sjb0rWhpbp7OX32u3BcX6 O1keos/BMHVn2CKKQt/LB5hqiHu1l+xN18roUNoZcGD9BjslCvQFAasVrZ6pfC0Ej5rU cX0DNgRlPVgL3o9TAkUrFvx/MWFtwq37AkuIUSYNtO7KoUPMnatnvzaYS5fr1ULxAF8Y 5f2bzBx23EujtOQwg0tQkDZpaf4xmNCKcphRm3oZXivAHayKYLRZ9Y8kjIKC/B/sbynD xrYQ== MIME-Version: 1.0 X-Received: by 10.182.96.71 with SMTP id dq7mr48166848obb.42.1404207833849; Tue, 01 Jul 2014 02:43:53 -0700 (PDT) Sender: r.c.ladan@gmail.com Received: by 10.182.146.46 with HTTP; Tue, 1 Jul 2014 02:43:53 -0700 (PDT) In-Reply-To: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> References: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> Date: Tue, 1 Jul 2014 11:43:53 +0200 X-Google-Sender-Auth: FaBYt6mhDm562Gur7kV_XwzReto Message-ID: Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? From: =?UTF-8?Q?Ren=C3=A9_Ladan?= To: mexas@bris.ac.uk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 09:43:54 -0000 2014-07-01 11:25 GMT+02:00 Anton Shterenlikht : > Why is it a good idea to mount /tmp and some var dirs on memory disks: > > root@raspberry-pi:/usr/ports # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/mmcsd0s2a 14694 777 12742 6% / > devfs 0 0 0 100% /dev > /dev/mmcsd0s1 16 3 13 20% /boot/msdos > /dev/md0 28 4 22 16% /tmp > /dev/md1 14 0 12 0% /var/log > /dev/md2 4 0 4 0% /var/tmp > root@raspberry-pi:/usr/ports # > > Is this about speed or power, or maybe space? > > Mostly write tear because you're using an SD card, and it improves speed too. > Can I not put all these dirs on sd card? > > You could, but see above. > I'm new to arm, so maybe things are different > to other arches. > Regards, Ren=C3=A9 From owner-freebsd-arm@FreeBSD.ORG Tue Jul 1 10:46:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4C14FCE for ; Tue, 1 Jul 2014 10:46:50 +0000 (UTC) Received: from eu1sys200aog134.obsmtp.com (eu1sys200aog134.obsmtp.com [207.126.144.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2195A204D for ; Tue, 1 Jul 2014 10:46:49 +0000 (UTC) Received: from mail-wg0-f46.google.com ([74.125.82.46]) (using TLSv1) by eu1sys200aob134.postini.com ([207.126.147.11]) with SMTP ID DSNKU7KRfhNLPa8J7T9hoqTHGapbG1t7zKdL@postini.com; Tue, 01 Jul 2014 10:46:50 UTC Received: by mail-wg0-f46.google.com with SMTP id y10so9438615wgg.17 for ; Tue, 01 Jul 2014 03:46:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=ZkvhC9g7IRt2+sLERqUvWP0OOaqazdH2wNt8cY+GSgw=; b=JxBusodoroIcWhAXDHinwyGZsHxM3FAN+fqi+S6rtDnLdNcKO6I14cKqJYEVBbOQKf bViVF/C+0wVZljsqP4W7/n/lBYYIr4bwd4twFoV2s0RbtdwKAWaDKUcpLf/6O/PffwJ1 AOYDO7tI0brz4CRLb32mYas6+iwh5TTfG58Z7hW7i/qwVbG5/PKz6ELkaaWCQhIVrvta XjlisvwIUGnL19tSEIhEoWLwekw1IHz9Tl/fD4usTKGu1yuXM5uOx9gKeXDra+f9jEXo v1F1tD0D7CFDHn2T8cw6u3uCzaU2z+qWtQUz+mmd8kdaOmB3wQwYdAmqdG4Wf6tC8PLh ltrw== X-Received: by 10.194.10.69 with SMTP id g5mr2298224wjb.116.1404211582073; Tue, 01 Jul 2014 03:46:22 -0700 (PDT) X-Gm-Message-State: ALoCoQlQ8ojlmEyytWvF/2C7GQ/8dwQSTgH8hYbuKmFEUitsg9iTqgq3moO5pwlM3BpNcCv367qgc3VSfiDw3X3QMv7uMX2cCGkz6OGs1QYOkKdLWjxiLQh1NGTHkuNJNL7o7CtALSt2 X-Received: by 10.194.10.69 with SMTP id g5mr2298203wjb.116.1404211581926; Tue, 01 Jul 2014 03:46:21 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id q11sm41957402wib.14.2014.07.01.03.46.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Jul 2014 03:46:21 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s61AkJZc006891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Jul 2014 11:46:20 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s61AkJpj006890; Tue, 1 Jul 2014 11:46:19 +0100 (BST) (envelope-from mexas) Date: Tue, 1 Jul 2014 11:46:19 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407011046.s61AkJpj006890@mech-cluster241.men.bris.ac.uk> To: mexas@bris.ac.uk, rene@freebsd.org Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? Reply-To: mexas@bris.ac.uk In-Reply-To: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 10:46:50 -0000 >From r.c.ladan@gmail.com Tue Jul 1 11:37:35 2014 > >2014-07-01 11:25 GMT+02:00 Anton Shterenlikht : > >> Why is it a good idea to mount /tmp and some var dirs on memory disks: >> >> root@raspberry-pi:/usr/ports # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/mmcsd0s2a 14694 777 12742 6% / >> devfs 0 0 0 100% /dev >> /dev/mmcsd0s1 16 3 13 20% /boot/msdos >> /dev/md0 28 4 22 16% /tmp >> /dev/md1 14 0 12 0% /var/log >> /dev/md2 4 0 4 0% /var/tmp >> root@raspberry-pi:/usr/ports # >> >> Is this about speed or power, or maybe space? >> >> Mostly write tear because you're using an SD card, and it improves speed >too. "write tear"? Is this a joke, or some technical term? I cannot find what it means. I get these messages on the console (well, on hdmi port...): pid ... (svnlite), uid 0 inumber 13 on /tmp: filesystem full If I unmount /tmp from md and leave it on sd card, then I don't see these anymore. What does this mean? Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Tue Jul 1 11:33:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84C9ABCE; Tue, 1 Jul 2014 11:33:41 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45DCC24AD; Tue, 1 Jul 2014 11:33:40 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1X1wJd-0002mU-19; Tue, 01 Jul 2014 13:33:37 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: mexas@bris.ac.uk, rene@freebsd.org Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? References: <201407011046.s61AkJpj006890@mech-cluster241.men.bris.ac.uk> Date: Tue, 01 Jul 2014 13:33:35 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <201407011046.s61AkJpj006890@mech-cluster241.men.bris.ac.uk> User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_20 autolearn=disabled version=3.3.1 X-Scan-Signature: 788438cbfdc4dc137ce560360a3a99c7 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 11:33:41 -0000 On Tue, 01 Jul 2014 12:46:19 +0200, Anton Shterenlikht wrote: >> From r.c.ladan@gmail.com Tue Jul 1 11:37:35 2014 >> >> 2014-07-01 11:25 GMT+02:00 Anton Shterenlikht : >> >>> Why is it a good idea to mount /tmp and some var dirs on memory disks: >>> >>> root@raspberry-pi:/usr/ports # df -m >>> Filesystem 1M-blocks Used Avail Capacity Mounted on >>> /dev/mmcsd0s2a 14694 777 12742 6% / >>> devfs 0 0 0 100% /dev >>> /dev/mmcsd0s1 16 3 13 20% /boot/msdos >>> /dev/md0 28 4 22 16% /tmp >>> /dev/md1 14 0 12 0% /var/log >>> /dev/md2 4 0 4 0% /var/tmp >>> root@raspberry-pi:/usr/ports # >>> >>> Is this about speed or power, or maybe space? >>> >>> Mostly write tear because you're using an SD card, and it improves >>> speed >> too. > > "write tear"? > Is this a joke, or some technical term? > I cannot find what it means. If you search for "write tear ssd" you get a lot of hits. It means that a lot of people like to reduce the number of writes to flash disks. > I get these messages on the console (well, on hdmi port...): > > pid ... (svnlite), uid 0 inumber 13 on /tmp: filesystem full > > If I unmount /tmp from md and leave it on sd card, > then I don't see these anymore. What does this mean? That the default setup is not suitable for your use case, because you write more to /tmp than the person who made the installation. And that you can change the /tmp mount as you like. Regards, Ronald. From owner-freebsd-arm@FreeBSD.ORG Tue Jul 1 14:07:50 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 139D13A1; Tue, 1 Jul 2014 14:07:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DEB8B24D1; Tue, 1 Jul 2014 14:07:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s61E7mOu089449; Tue, 1 Jul 2014 10:07:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s61E7mlV089445; Tue, 1 Jul 2014 14:07:48 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 1 Jul 2014 14:07:48 GMT Message-Id: <201407011407.s61E7mlV089445@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 14:07:50 -0000 TB --- 2014-07-01 10:30:46 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-01 10:30:46 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-01 10:30:46 - starting HEAD tinderbox run for arm/arm TB --- 2014-07-01 10:30:46 - cleaning the object tree TB --- 2014-07-01 10:30:46 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-01 10:30:51 - At svn revision 268087 TB --- 2014-07-01 10:30:52 - building world TB --- 2014-07-01 10:30:52 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 10:30:52 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 10:30:52 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 10:30:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 10:30:52 - SRCCONF=/dev/null TB --- 2014-07-01 10:30:52 - TARGET=arm TB --- 2014-07-01 10:30:52 - TARGET_ARCH=arm TB --- 2014-07-01 10:30:52 - TZ=UTC TB --- 2014-07-01 10:30:52 - __MAKE_CONF=/dev/null TB --- 2014-07-01 10:30:52 - cd /src TB --- 2014-07-01 10:30:52 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Tue Jul 1 10:30:59 UTC 2014 >>> 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 Tue Jul 1 13:50:26 UTC 2014 TB --- 2014-07-01 13:50:26 - generating LINT kernel config TB --- 2014-07-01 13:50:26 - cd /src/sys/arm/conf TB --- 2014-07-01 13:50:26 - /usr/bin/make -B LINT TB --- 2014-07-01 13:50:26 - cd /src/sys/arm/conf TB --- 2014-07-01 13:50:26 - /obj/arm.arm/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-01 13:50:26 - building LINT kernel TB --- 2014-07-01 13:50:26 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 13:50:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 13:50:26 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 13:50:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 13:50:26 - SRCCONF=/dev/null TB --- 2014-07-01 13:50:26 - TARGET=arm TB --- 2014-07-01 13:50:26 - TARGET_ARCH=arm TB --- 2014-07-01 13:50:26 - TZ=UTC TB --- 2014-07-01 13:50:26 - __MAKE_CONF=/dev/null TB --- 2014-07-01 13:50:26 - cd /src TB --- 2014-07-01 13:50:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 1 13:50:26 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `kernelstack' at91_machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `minidataclean' ep80219_machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `msgbufpv' at91_machdep.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_mem' uart_cpu_fdt.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_io' uart_cpu_fdt.o: warning: previous common is here kbd.o: In function `kbd_register': /src/sys/dev/kbd/kbd.c:(.text+0x42c): undefined reference to `__stop_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x430): undefined reference to `__start_set_kbddriver_set' kbd.o: In function `kbd_get_switch': /src/sys/dev/kbd/kbd.c:(.text+0x5c0): undefined reference to `__start_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x5c4): undefined reference to `__stop_set_kbddriver_set' kbd.o: In function `kbd_configure': /src/sys/dev/kbd/kbd.c:(.text+0x898): undefined reference to `__start_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x89c): undefined reference to `__stop_set_kbddriver_set' *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-07-01 14:07:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-07-01 14:07:48 - ERROR: failed to build LINT kernel TB --- 2014-07-01 14:07:48 - 10431.13 user 1766.10 system 13021.20 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Jul 1 15:35:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D25B9A for ; Tue, 1 Jul 2014 15:35:23 +0000 (UTC) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D87CA2DFA for ; Tue, 1 Jul 2014 15:35:22 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id tp5so8247140ieb.36 for ; Tue, 01 Jul 2014 08:35:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=SWxdHsj8+YP6zmx4Z3eINWK18Lb1vd/0N9K4cB+gaTw=; b=LYFG2pIVaUtoGXZeYrmQ3Ckw/Pmzgwn8n/JmapZCxUMxrFQAd6/osGpRyabKu/2kl+ 4yvmOkE/zydtztyTPywj/hvbo78AmiaZErtnOE8mc8tORyoAiq6krvEHCULFhgoOq9PS 8G5WbUqqsiAEyRgI+RAj5I1H4pAhTueg8v/Xx3uI2x6boLF5vYyUx+JdGr2oG5jI+mpx gbeUqVGLPeuZyzYX3FYGQDl4eFXOQIMohmTOwahNpxzaWdFvA7TiN0TIOn5Ghnsdsgi6 4jYM3fip3xLlCFf5xNw/S/eSqsmhh66d5Z1tsZK4AnZwpSnS+4AHsqeWxKWEI9HOh0FX HwPw== X-Gm-Message-State: ALoCoQmtojVZwyu+G1yiDZyIsHJ5+RCGiEPWM9QOjtxiRZOxSJhGUYkIn7MnxJWGx4NUe38Soa8J X-Received: by 10.42.118.9 with SMTP id v9mr44705228icq.26.1404228916080; Tue, 01 Jul 2014 08:35:16 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id d4sm14797255igc.5.2014.07.01.08.35.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 08:35:15 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_6751D0A8-49EB-4125-B282-7935AE8F50C0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? From: Warner Losh In-Reply-To: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> Date: Tue, 1 Jul 2014 09:35:29 -0600 Message-Id: References: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> To: mexas@bris.ac.uk X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 15:35:23 -0000 --Apple-Mail=_6751D0A8-49EB-4125-B282-7935AE8F50C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 1, 2014, at 3:25 AM, Anton Shterenlikht wrote: > Why is it a good idea to mount /tmp and some var dirs on memory disks: >=20 > root@raspberry-pi:/usr/ports # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/mmcsd0s2a 14694 777 12742 6% / > devfs 0 0 0 100% /dev > /dev/mmcsd0s1 16 3 13 20% /boot/msdos > /dev/md0 28 4 22 16% /tmp > /dev/md1 14 0 12 0% /var/log > /dev/md2 4 0 4 0% /var/tmp > root@raspberry-pi:/usr/ports #=20 >=20 > Is this about speed or power, or maybe space? >=20 > Can I not put all these dirs on sd card? >=20 > I'm new to arm, so maybe things are different > to other arches. It isn=92t so much about ARM as it is about SD cards. Each write to a = file causes wear and tear on the card. Each update of metadata likewise. = There are things that can be done (like enabling trim) that reduce the = wear and tear on the card, NAND flash only has so much life. Do you = really want to use it for data that=92s at best disposable? No. SD cards = these days are made from NAND that=92s lucky to get 3k separate writes = to it (or even worse: 500 in the case of TLC NAND). Given such a limited = resource, nanobsd, and others, use MD devices to eliminate that wear and = tear. It is the same rason there=92s no swap partition... Having said that, I=92ve run many development systems without doing = this. They work fine, but doing it in production has shown to result in = some SD cards (not all) breaking prematurely. Warner --Apple-Mail=_6751D0A8-49EB-4125-B282-7935AE8F50C0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTstVCAAoJEGwc0Sh9sBEA1fAP/05hPbwe8Nh03ZKbUoJTSIJV P23q8KXX0ocRKwT8AJedhpNqTWHFTkAzF0cIGLEiatxQnsRSAosVDisAxZNlqYxH uA417z6EWt68R9BnTBCFu5/UmagszH1i6KSWTXWmxR2e8ltGSqf4RgXRj9qzJKKo UhNOsHsoI29820kErS7oykCMBSL+EinVOs/HI6OGm4Lnnu3crUHTMdces+TMXTk9 oG4R7KLPWNDJTXBdPrNyJysVnrM94/GvG+/6C1qG8T2b30oLdOS8jj7OU3mtkYJv QHBsiz011LxZAsLXpCQcTZj0xb/SzJ1jdI3p8XlBAVNNsWtxcpARV+3HuO1fBfOJ Psxyv0urhIAOsRqSZ63bg/MWP0U+3p3nGCV/0z5xmZV6iiXpexertFj+1/WOyvU2 nxxmbvpNtplQLI5jJCSCdBhKVqO2risEOxetSgMFCHLUTPMZ2eMsIVWATPSO0fiI M1XqR7eKaLcpnJZZtk9Gc6zet1CfiwxeLQzR8Thd56pgQpt7k0+Lul99Lxq9qe4K GumOGLF3SOV+282K/XJMCu5eNl+90HA51X6HZ+Gkj9PSI+rFGNcqOyOmmbn8RHWV yOpaX43fqX75GtjYIBWhRE/wJpUa7V3wgHDjGBQYv1RwzwlLO+eaeRI0efvT3lfW hM/LVl5NvOVtZ5J3behQ =yh03 -----END PGP SIGNATURE----- --Apple-Mail=_6751D0A8-49EB-4125-B282-7935AE8F50C0-- From owner-freebsd-arm@FreeBSD.ORG Tue Jul 1 19:27:30 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51873C37 for ; Tue, 1 Jul 2014 19:27:30 +0000 (UTC) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0CA8261C for ; Tue, 1 Jul 2014 19:27:29 +0000 (UTC) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.14.8/8.14.8) with ESMTP id s61JRQIs037080 for ; Tue, 1 Jul 2014 21:27:26 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Tue, 01 Jul 2014 21:27:26 +0200 (CEST) Message-ID: <44a6e8a451a.810fa8f@mail.schwarzes.net> In-Reply-To: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> References: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Tue, 01 Jul 2014 21:27:26 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 19:27:30 -0000 On 01.07.14, Anton Shterenlikht wrote: > Why is it a good idea to mount /tmp and some var dirs on memory disks: > > root@raspberry-pi:/usr/ports # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/mmcsd0s2a 14694 777 12742 6% / > devfs 0 0 0 100% /dev > /dev/mmcsd0s1 16 3 13 20% /boot/msdos > /dev/md0 28 4 22 16% /tmp > /dev/md1 14 0 12 0% /var/log > /dev/md2 4 0 4 0% /var/tmp > root@raspberry-pi:/usr/ports # > > Is this about speed or power, or maybe space? Speed and speed, but I can't understand why using md here, there is already tmpfs, which optimzed for such cases (dynamic allocation, etc.). root@pizelot:~ # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mmcsd0s2a 983680 57252 847736 6% / devfs 1 1 0 100% /dev /dev/mmcsd0s2d 8106716 3068708 4389472 41% /usr /dev/mmcsd0s2e 8106716 155976 7302204 2% /var /dev/mmcsd0s2f 8106716 236 7457944 0% /home tmpfs 1097160 4 1097156 0% /tmp tmpfs 1097160 4 1097156 0% /var/tmp Regards, Andreas From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 02:20:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CCF2ED; Wed, 2 Jul 2014 02:20:47 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DEB7B296B; Wed, 2 Jul 2014 02:20:46 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s622KglY060851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2014 19:20:43 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s622KggZ060850; Tue, 1 Jul 2014 19:20:42 -0700 (PDT) (envelope-from jmg) Date: Tue, 1 Jul 2014 19:20:42 -0700 From: John-Mark Gurney To: Anton Shterenlikht Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? Message-ID: <20140702022042.GG45513@funkthat.com> Mail-Followup-To: Anton Shterenlikht , rene@freebsd.org, freebsd-arm@freebsd.org References: <201407011046.s61AkJpj006890@mech-cluster241.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407011046.s61AkJpj006890@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 01 Jul 2014 19:20:43 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 02:20:47 -0000 Anton Shterenlikht wrote this message on Tue, Jul 01, 2014 at 11:46 +0100: > >From r.c.ladan@gmail.com Tue Jul 1 11:37:35 2014 > > > >2014-07-01 11:25 GMT+02:00 Anton Shterenlikht : > > > >> Why is it a good idea to mount /tmp and some var dirs on memory disks: > >> > >> root@raspberry-pi:/usr/ports # df -m > >> Filesystem 1M-blocks Used Avail Capacity Mounted on > >> /dev/mmcsd0s2a 14694 777 12742 6% / > >> devfs 0 0 0 100% /dev > >> /dev/mmcsd0s1 16 3 13 20% /boot/msdos > >> /dev/md0 28 4 22 16% /tmp > >> /dev/md1 14 0 12 0% /var/log > >> /dev/md2 4 0 4 0% /var/tmp > >> root@raspberry-pi:/usr/ports # > >> > >> Is this about speed or power, or maybe space? > >> > >> Mostly write tear because you're using an SD card, and it improves speed > >too. > > "write tear"? > Is this a joke, or some technical term? > I cannot find what it means. it is a technical term, though I'd be surprised if any SD card had an issue w/ that anymore... write tear is where when writing data, only part of the data gets written and then you loose power... This is mostly an issue on flash where you have to erase the data beforey ou can program it... Most flash now have a layer of indirection so that they copy/write the data to a new flash block, and then point the block there before erasing the old data... (kinda like a log FS)... > I get these messages on the console (well, on hdmi port...): > > pid ... (svnlite), uid 0 inumber 13 on /tmp: filesystem full > > If I unmount /tmp from md and leave it on sd card, > then I don't see these anymore. What does this mean? I means that your /tmp fs is to small, and you should either increase the size of it, or clean it out... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 03:30:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24D67C7E for ; Wed, 2 Jul 2014 03:30:15 +0000 (UTC) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECDC22EB8 for ; Wed, 2 Jul 2014 03:30:14 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id y10so11050411pdj.8 for ; Tue, 01 Jul 2014 20:30:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3m8HgSxAuoFp8Ki43VugDpdmdP9WFhHQL4S/wjciJtI=; b=Tk0z6erDhTHaomls1SNHAeZuCu+d1y+Zcik/srkMYJHnbOsl09ti9cE7mEwXaYGIWF YDuDM5HEiCSKvP640XV+2h1t9H9mvzGCCq9WvbcnQ+poQwVpxYHA99k0fPzoWZZrxDl+ wQMfiX2K0vOXyO3WNE2ov26zJzbJ3djI1c/78t5n6teo80+a73fmBzSWefEfu4Gducka vE5BQadi0P408IIh7ze1AZzAs4ykK8FQcNGmkLQY4ZoGMo5TPXQeair2Jvb73QQAKJT4 YlJb8v7G6fAGi387KV1N9E8bwxkGoFjDaiLvrpS5NyL04Nmfv1zVk12pHKgl59laKFgk wJeg== X-Gm-Message-State: ALoCoQnLhHioUhlO7lHk9CgVB1SrMKzonmpDpic39gM7fzf3ET7+mqojKc7k/SXDhIw8zr5qmU1h X-Received: by 10.68.116.235 with SMTP id jz11mr42539370pbb.149.1404270354722; Tue, 01 Jul 2014 20:05:54 -0700 (PDT) Received: from [192.168.1.103] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id qk9sm123773407pac.16.2014.07.01.20.05.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 20:05:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: RPi model B - svnlite segfaults a lot - power? From: Tim Kientzle In-Reply-To: <201406251147.s5PBl42l011052@mech-cluster241.men.bris.ac.uk> Date: Tue, 1 Jul 2014 20:05:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201406251147.s5PBl42l011052@mech-cluster241.men.bris.ac.uk> To: mexas@bris.ac.uk X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 03:30:15 -0000 On Jun 25, 2014, at 4:47 AM, Anton Shterenlikht = wrote: > Just trying Raspberry Pi model B. > Booting with this snapshot: >=20 > # uname -a > FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267801: Tue = Jun 24 11:03:28 UTC 2014 = root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >=20 > I wanted to check the feasibility of various ports > running on this hardware. While checking out the ports > tree svnlite segfaults a lot. >=20 > I've seen many threads urging the importance of correct > power source. When I have insufficient power, I usually just see the board shut down. Segfaults are probably a software problem. Do you have a stack trace? From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 03:37:12 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63389E3F; Wed, 2 Jul 2014 03:37:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 352122F67; Wed, 2 Jul 2014 03:37:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.8/8.14.8) with ESMTP id s623b9eg025114; Tue, 1 Jul 2014 23:37:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.8/8.14.8/Submit) id s623b9wL025078; Wed, 2 Jul 2014 03:37:09 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 2 Jul 2014 03:37:09 GMT Message-Id: <201407020337.s623b9wL025078@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.18 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 03:37:12 -0000 TB --- 2014-07-02 00:00:50 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-02 00:00:50 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-02 00:00:50 - starting HEAD tinderbox run for arm/arm TB --- 2014-07-02 00:00:50 - cleaning the object tree TB --- 2014-07-02 00:02:09 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-02 00:02:12 - At svn revision 268131 TB --- 2014-07-02 00:02:13 - building world TB --- 2014-07-02 00:02:13 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 00:02:13 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 00:02:13 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 00:02:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 00:02:13 - SRCCONF=/dev/null TB --- 2014-07-02 00:02:13 - TARGET=arm TB --- 2014-07-02 00:02:13 - TARGET_ARCH=arm TB --- 2014-07-02 00:02:13 - TZ=UTC TB --- 2014-07-02 00:02:13 - __MAKE_CONF=/dev/null TB --- 2014-07-02 00:02:13 - cd /src TB --- 2014-07-02 00:02:13 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Wed Jul 2 00:02:20 UTC 2014 >>> 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 Wed Jul 2 03:19:53 UTC 2014 TB --- 2014-07-02 03:19:53 - generating LINT kernel config TB --- 2014-07-02 03:19:53 - cd /src/sys/arm/conf TB --- 2014-07-02 03:19:53 - /usr/bin/make -B LINT TB --- 2014-07-02 03:19:53 - cd /src/sys/arm/conf TB --- 2014-07-02 03:19:53 - /obj/arm.arm/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-02 03:19:53 - building LINT kernel TB --- 2014-07-02 03:19:53 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 03:19:53 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 03:19:53 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 03:19:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 03:19:53 - SRCCONF=/dev/null TB --- 2014-07-02 03:19:53 - TARGET=arm TB --- 2014-07-02 03:19:53 - TARGET_ARCH=arm TB --- 2014-07-02 03:19:53 - TZ=UTC TB --- 2014-07-02 03:19:53 - __MAKE_CONF=/dev/null TB --- 2014-07-02 03:19:53 - cd /src TB --- 2014-07-02 03:19:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 2 03:19:53 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `kernelstack' at91_machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `minidataclean' ep80219_machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `msgbufpv' at91_machdep.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_mem' uart_cpu_fdt.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_io' uart_cpu_fdt.o: warning: previous common is here kbd.o: In function `kbd_register': /src/sys/dev/kbd/kbd.c:(.text+0x42c): undefined reference to `__stop_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x430): undefined reference to `__start_set_kbddriver_set' kbd.o: In function `kbd_get_switch': /src/sys/dev/kbd/kbd.c:(.text+0x5c0): undefined reference to `__start_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x5c4): undefined reference to `__stop_set_kbddriver_set' kbd.o: In function `kbd_configure': /src/sys/dev/kbd/kbd.c:(.text+0x898): undefined reference to `__start_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x89c): undefined reference to `__stop_set_kbddriver_set' *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-07-02 03:37:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-07-02 03:37:09 - ERROR: failed to build LINT kernel TB --- 2014-07-02 03:37:09 - 10432.02 user 1715.45 system 12978.79 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 07:46:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18F7FF34 for ; Wed, 2 Jul 2014 07:46:58 +0000 (UTC) Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6920323E7 for ; Wed, 2 Jul 2014 07:46:56 +0000 (UTC) Received: from mail-we0-f180.google.com ([74.125.82.180]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKU7O42slZkvetIzABxp+mj8WoUIpD7E7E@postini.com; Wed, 02 Jul 2014 07:46:57 UTC Received: by mail-we0-f180.google.com with SMTP id x48so10713808wes.39 for ; Wed, 02 Jul 2014 00:46:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=TkVZ22EkJAccWxbk+xnfeCZk2ukW3f96HuB0Oin/PWY=; b=YqXgzWj4FyFn5j4lYOw0NeBk1g+tT0g4ctsj5ZCM0GT+Iopi0YmPsSQ7UcqQMLhubT sWqIP0zhxijD5YPWcpRhWU2P5vF7sm2qzGC27asAYZAIBarT9U/ja6mZxNMC2oLKxZD3 dwtVsMm2BIIHXzsFGhy203rBu2kXTKHuA7i0A9tFxDnOf/BKvDgmb87DKNcqYEUITJ1U 8LPL+gXUdD0htp7AasyJ886OXh2IxTtYGgKHiOunPfJxspoJWiMeHVOhG8KtRw/UwowC sNzYAmdn2NmrX9Toba9MS98RwtUN+0c2tcUuzM5PiLFE+OVH+MLwwVlO5cgZguVGNYtA HFKQ== X-Gm-Message-State: ALoCoQmPH8KYbMBCljX/BBFk+it0wa/77CoMm8wxh4Y6zoDvtvdllHPrzIIkK6b5QbTtcy8/UZ/HSn0v8gttkyBlVEy8A5vmZOBGiyM934N+84J4aoEttIebYC2NTCMFLjKmP/dCGBxs X-Received: by 10.180.73.112 with SMTP id k16mr2666811wiv.35.1404287193959; Wed, 02 Jul 2014 00:46:33 -0700 (PDT) X-Received: by 10.180.73.112 with SMTP id k16mr2666807wiv.35.1404287193893; Wed, 02 Jul 2014 00:46:33 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id i4sm52261977wib.21.2014.07.02.00.46.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Jul 2014 00:46:33 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s627kVOV014820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Jul 2014 08:46:32 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s627kTl7014819; Wed, 2 Jul 2014 08:46:29 +0100 (BST) (envelope-from mexas) Date: Wed, 2 Jul 2014 08:46:29 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407020746.s627kTl7014819@mech-cluster241.men.bris.ac.uk> To: tim@kientzle.com Subject: Re: RPi model B - svnlite segfaults a lot - power? Reply-To: mexas@bris.ac.uk In-Reply-To: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 07:46:58 -0000 >From tim@kientzle.com Wed Jul 2 04:16:53 2014 > >On Jun 25, 2014, at 4:47 AM, Anton Shterenlikht wrote: > >> Just trying Raspberry Pi model B. >> Booting with this snapshot: >> >> # uname -a >> FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267801: Tue Jun 24 11:03:28 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >> >> I wanted to check the feasibility of various ports >> running on this hardware. While checking out the ports >> tree svnlite segfaults a lot. >> >> I've seen many threads urging the importance of correct >> power source. > >When I have insufficient power, I usually just see the >board shut down. > >Segfaults are probably a software problem. > >Do you have a stack trace? no. I'll try 10-stable first. Anton From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 08:26:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F6E8DCE for ; Wed, 2 Jul 2014 08:26:33 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 53AF12770 for ; Wed, 2 Jul 2014 08:26:33 +0000 (UTC) Received: from bender.lan (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 8BAF15DEBC; Wed, 2 Jul 2014 08:20:49 +0000 (UTC) Date: Wed, 2 Jul 2014 09:20:41 +0100 From: Andrew Turner To: mexas@bris.ac.uk Subject: Re: svnlite segfaults a lot Message-ID: <20140702092041.716a7413@bender.lan> In-Reply-To: <201407010930.s619Uk9X006689@mech-cluster241.men.bris.ac.uk> References: <201407010930.s619Uk9X006689@mech-cluster241.men.bris.ac.uk> 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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 08:26:33 -0000 On Tue, 1 Jul 2014 10:30:46 +0100 (BST) Anton Shterenlikht wrote: > # uname -a > FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267801: > Tue Jun 24 11:03:28 UTC 2014 > root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm > > I'm trying to pull the ports tree to rasp. pi model B. > svnlite up (or co) segfaults after pulling 1-5 MB. > Is this expected? > > I'm powering via a bench power supply, so I can > monitor the current. It is only about 400mA, > occasionally raising to maybe 450mA. > So my earlier suspicion, that an inadequate > power was to blame, was wrong. > > Anybody else seeing svnlite segfaults? Yes, however I never tracked it down. I found svn from ports to work as expected. Andrew From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 08:33:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99D1EF1 for ; Wed, 2 Jul 2014 08:33:04 +0000 (UTC) Received: from eu1sys200aog119.obsmtp.com (eu1sys200aog119.obsmtp.com [207.126.144.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA8F72821 for ; Wed, 2 Jul 2014 08:33:03 +0000 (UTC) Received: from mail-we0-f174.google.com ([74.125.82.174]) (using TLSv1) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKU7PDt9JnYFJWrXxMX9nJdPdVBM+NA4dy@postini.com; Wed, 02 Jul 2014 08:33:04 UTC Received: by mail-we0-f174.google.com with SMTP id u57so10954673wes.19 for ; Wed, 02 Jul 2014 01:32:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=4Dj3AuuQ5C6JftnZ8D8fGZoTPJzx1qXTKIeQzKYrwzA=; b=BVS0ZlFxbE9zuO5E/mzaM25KCRU4zK3QMq9MJFPvKjXUSeECm4dVgYJPHONs9zRoRK suSQjYx3mqZnI7kLMikA+TfHqV2Moff2b+vbPw4upvb4JyeaFaLzscVquNhgAA7/kFmZ oBdOiL0z4MPKlRXU8o1koJQB7DmGhbmiziE9me9ymuDXOqhmLp986DIZH7R9kkaG25FV 1+SgxUAdFUAp7PeyjlCkotd49oNA+wh1fG1mMhrs+cL6Zk0SDcc9Swr36nWFBJ96NnVj aqNZRvBujYejeO2198QC9naf28SIKf7b5+KHSnnD/X5kXVWDsykwpIh3iitFxrW6ZtEr LZig== X-Gm-Message-State: ALoCoQmR2P2uxEhlKqMl/SvDa3nBmh5Hi3V9tbBPo7x2lazYlu+wNQsIZwOkYT38g/GDmN9pGJJ8U5nCDraseYeJ6DLA/WNU9jTEjZyUHpa9MCyvyxBsnejXHolJsgngyZ/44rnu7fWZ X-Received: by 10.194.190.78 with SMTP id go14mr1242052wjc.128.1404289975837; Wed, 02 Jul 2014 01:32:55 -0700 (PDT) X-Received: by 10.194.190.78 with SMTP id go14mr1242001wjc.128.1404289975287; Wed, 02 Jul 2014 01:32:55 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id cz4sm52625102wib.23.2014.07.02.01.32.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Jul 2014 01:32:54 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s628Wrta014904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Jul 2014 09:32:53 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s628WqWE014903; Wed, 2 Jul 2014 09:32:52 +0100 (BST) (envelope-from mexas) Date: Wed, 2 Jul 2014 09:32:52 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407020832.s628WqWE014903@mech-cluster241.men.bris.ac.uk> To: imp@bsdimp.com, mexas@bris.ac.uk Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? Reply-To: mexas@bris.ac.uk In-Reply-To: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 08:33:04 -0000 >From imp@bsdimp.com Tue Jul 1 18:09:59 2014 > >On Jul 1, 2014, at 3:25 AM, Anton Shterenlikht wrote: > >> Why is it a good idea to mount /tmp and some var dirs on memory disks: >>=20 >> root@raspberry-pi:/usr/ports # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/mmcsd0s2a 14694 777 12742 6% / >> devfs 0 0 0 100% /dev >> /dev/mmcsd0s1 16 3 13 20% /boot/msdos >> /dev/md0 28 4 22 16% /tmp >> /dev/md1 14 0 12 0% /var/log >> /dev/md2 4 0 4 0% /var/tmp >> root@raspberry-pi:/usr/ports #=20 >>=20 >> Is this about speed or power, or maybe space? >>=20 >> Can I not put all these dirs on sd card? >>=20 >> I'm new to arm, so maybe things are different >> to other arches. > >It isn=92t so much about ARM as it is about SD cards. Each write to a = >file causes wear and tear on the card. Each update of metadata likewise. = >There are things that can be done (like enabling trim) that reduce the = >wear and tear on the card, NAND flash only has so much life. Do you = >really want to use it for data that=92s at best disposable? No. SD cards = >these days are made from NAND that=92s lucky to get 3k separate writes = >to it (or even worse: 500 in the case of TLC NAND). Given such a limited = >resource, nanobsd, and others, use MD devices to eliminate that wear and = >tear. It is the same rason there=92s no swap partition... > >Having said that, I=92ve run many development systems without doing = >this. They work fine, but doing it in production has shown to result in = >some SD cards (not all) breaking prematurely. > >Warner Wow, thank you! I knew nothing about sd cards, so this is very helpful. So, if I need to build kernel, world and ports often, sd card is a poor choice? I better use an external disk? What I really want to find out is whether I can have a dumb graphical terminal from Rpi-B. Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 11:21:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 929F74D8 for ; Wed, 2 Jul 2014 11:21:18 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2757828F5 for ; Wed, 2 Jul 2014 11:21:18 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi2so8817727wib.2 for ; Wed, 02 Jul 2014 04:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=KOVVO6XiLZws8cHU+qqv/VzGUx+gXZb7BH7kZZ3EVqo=; b=SlxE91eAxqABwzQbnmfCYX5C0C6KQE6lVHKn5AKcoQ2hRkYT+mTh4mbsNEf4rEfeVM lYEyo/6k9r99m7R3aLyrUHlbdpbtt8J0b83xcxGYoVhRMi2bZ2US8HEVZQDEvp33aDOW fq1k4ZPaY+jso4FZkcKhNYf47sc/4Bo/Oyg8giKSjX2RLiP+sXJkHhUBeiGWCwknZ7cG gS6qB2J6dTKpmuF0kR6NMfWNq6E/iezJASaDUjLubPFn2MuV8oB8lTAN4JQ5juGhXclC V6XnD/2V9jBK65uEyKyHphnujZ+pKC7q435KB3Na3unm1CGlH+Lm4/V9XHtyZGFUdRxL wb8A== X-Received: by 10.194.185.238 with SMTP id ff14mr36180151wjc.9.1404300074489; Wed, 02 Jul 2014 04:21:14 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:511:badc:418a:8c96? ([2001:1620:ff0:c51:511:badc:418a:8c96]) by mx.google.com with ESMTPSA id fn1sm54156326wib.18.2014.07.02.04.21.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 04:21:13 -0700 (PDT) Message-ID: <53B3EB29.4030908@gmail.com> Date: Wed, 02 Jul 2014 13:21:13 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? References: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> <44a6e8a451a.810fa8f@mail.schwarzes.net> In-Reply-To: <44a6e8a451a.810fa8f@mail.schwarzes.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 11:21:18 -0000 Am 01.07.2014 21:27, schrieb Andreas Schwarz: > Speed and speed, but I can't understand why using md here, there is already tmpfs, > which optimzed for such cases (dynamic allocation, etc.). > > root@pizelot:~ # df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/mmcsd0s2a 983680 57252 847736 6% / > devfs 1 1 0 100% /dev > /dev/mmcsd0s2d 8106716 3068708 4389472 41% /usr > /dev/mmcsd0s2e 8106716 155976 7302204 2% /var > /dev/mmcsd0s2f 8106716236 7457944 0% /home > tmpfs 1097160 4 1097156 0% /tmp > tmpfs 1097160 4 1097156 0% /var/tmp > On an embedded systems with little memory I prefer to limit the partitions to a certain size, like 32M, so dynamic allocation is no advantage. What other differences are there between tmpfs and a simple md device? I'd be interested in knowing any tricks, that can make the system faster :-) So yes, it's about speed. Especially mounting /var/log on development systems, where some errors can result in massive logging it's better to have that on a ramdisk rather than on the slow SD card. Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 11:38:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE3A2910 for ; Wed, 2 Jul 2014 11:38:57 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC9EC2A89 for ; Wed, 2 Jul 2014 11:38:57 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s62BcJbO068993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jul 2014 04:38:20 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s62BcJWW068992; Wed, 2 Jul 2014 04:38:19 -0700 (PDT) (envelope-from jmg) Date: Wed, 2 Jul 2014 04:38:19 -0700 From: John-Mark Gurney To: Anton Shterenlikht Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? Message-ID: <20140702113819.GO45513@funkthat.com> Mail-Followup-To: Anton Shterenlikht , imp@bsdimp.com, freebsd-arm@freebsd.org References: <201407020832.s628WqWE014903@mech-cluster241.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407020832.s628WqWE014903@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 02 Jul 2014 04:38:20 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 11:38:58 -0000 Anton Shterenlikht wrote this message on Wed, Jul 02, 2014 at 09:32 +0100: > >From imp@bsdimp.com Tue Jul 1 18:09:59 2014 > > > >On Jul 1, 2014, at 3:25 AM, Anton Shterenlikht wrote: > > > >> Why is it a good idea to mount /tmp and some var dirs on memory disks: > >>=20 > >> root@raspberry-pi:/usr/ports # df -m > >> Filesystem 1M-blocks Used Avail Capacity Mounted on > >> /dev/mmcsd0s2a 14694 777 12742 6% / > >> devfs 0 0 0 100% /dev > >> /dev/mmcsd0s1 16 3 13 20% /boot/msdos > >> /dev/md0 28 4 22 16% /tmp > >> /dev/md1 14 0 12 0% /var/log > >> /dev/md2 4 0 4 0% /var/tmp > >> root@raspberry-pi:/usr/ports #=20 > >>=20 > >> Is this about speed or power, or maybe space? > >>=20 > >> Can I not put all these dirs on sd card? > >>=20 > >> I'm new to arm, so maybe things are different > >> to other arches. > > > >It isn=92t so much about ARM as it is about SD cards. Each write to a = > >file causes wear and tear on the card. Each update of metadata likewise. = > >There are things that can be done (like enabling trim) that reduce the = > >wear and tear on the card, NAND flash only has so much life. Do you = > >really want to use it for data that=92s at best disposable? No. SD cards = > >these days are made from NAND that=92s lucky to get 3k separate writes = > >to it (or even worse: 500 in the case of TLC NAND). Given such a limited = > >resource, nanobsd, and others, use MD devices to eliminate that wear and = > >tear. It is the same rason there=92s no swap partition... > > > >Having said that, I=92ve run many development systems without doing = > >this. They work fine, but doing it in production has shown to result in = > >some SD cards (not all) breaking prematurely. > > > >Warner > > Wow, thank you! > > I knew nothing about sd cards, so this is very helpful. > > So, if I need to build kernel, world and ports often, > sd card is a poor choice? I better use an external disk? If often, you mean once a week, then probably you'll be fine w/ SD cards... If often you mean in a continuous loop, you still might be fine as long as your life time of the SD card is fine at a couple years, partly because w/ how slow ARM compiles code, you wouldn't be writing that much data out... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 12:24:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49B06D47 for ; Wed, 2 Jul 2014 12:24:01 +0000 (UTC) Received: from eu1sys200aob121.obsmtp.com (eu1sys200aob121.obsmtp.com [207.126.144.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A88052EF8 for ; Wed, 2 Jul 2014 12:24:00 +0000 (UTC) Received: from mail-wi0-f170.google.com ([209.85.212.170]) (using TLSv1) by eu1sys200aob121.postini.com ([207.126.147.11]) with SMTP ID DSNKU7P50YpohlB+bZ6QMbtXkZDZkmQ7Hp7K@postini.com; Wed, 02 Jul 2014 12:23:53 UTC Received: by mail-wi0-f170.google.com with SMTP id cc10so8983988wib.3 for ; Wed, 02 Jul 2014 05:23:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=9no+6/b2wnnFvrBduqsWLKxtOoe2Y/v00tfQQ/6WMy0=; b=mdtPyFDjoILKXk+eQn481GT4u8fZ46yPa/JB2MkIK3dpVmhVpdOx8iNCaTGaM3V/qT M50vy3/gDtXOmgUcsy6uQWGLJoiUFj5InqYj9FmHNgymRHhPqjwSTVAHTOSZopvcFAAU plf/3MT89KxYEyarXLMIfd2F0yl5X1dLchc0wviDavW24PLs3UAor7myuTarUPL7ufAt smTZCriBBLhBNmZExSJ3t1xO5GKCpgbqpyuXBDk4iqm5ApHphOSHuIBcwYANmAVbT2A5 Zx3+oJYID8Z8strfF4VvO8eAWpp87RPZCy3LcDUxl54k3s6EXWulxk6vG9rMgiCIOdiy uZ1g== X-Received: by 10.194.7.167 with SMTP id k7mr57530719wja.11.1404303512435; Wed, 02 Jul 2014 05:18:32 -0700 (PDT) X-Gm-Message-State: ALoCoQkumi5h3jNFViT8NBAUjpDwv89qcf84l4deMARDOCfauHjvpBvBCrYHGDVrDYcH4ptjGqmYgxD6DoES1tW05jMUrPuseuiawQZpQsJp1QCNItj7yGzpa2BK5rLpotkr3R2ZCpun X-Received: by 10.194.7.167 with SMTP id k7mr57530695wja.11.1404303512141; Wed, 02 Jul 2014 05:18:32 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id ft2sm45594943wib.1.2014.07.02.05.18.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Jul 2014 05:18:31 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s62CITbx015475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 2 Jul 2014 13:18:30 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s62CITOU015474 for freebsd-arm@freebsd.org; Wed, 2 Jul 2014 13:18:29 +0100 (BST) (envelope-from mexas) Date: Wed, 2 Jul 2014 13:18:29 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407021218.s62CITOU015474@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: svnlite segfaults in 11 but not in 10 Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 12:24:01 -0000 I confirm that svnlite does not segfault on: $ uname -a FreeBSD raspberry-pi 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul 1 04:29:43 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm Shall I submit a PR on this? Anton From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 14:49:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A4D06E9 for ; Wed, 2 Jul 2014 14:49:04 +0000 (UTC) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2D772D76 for ; Wed, 2 Jul 2014 14:49:03 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id rl12so678928iec.14 for ; Wed, 02 Jul 2014 07:49:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=RZ/1vuNPGZ0Bn09/f+sVry5LKnxQ833hjuuX803XlY0=; b=RsMIZMEwbFeLwJyA62klG5dMggkZxvHfEkx1ziyG+Nl+Thm7NkjfIzYn7r0ZXlWs5f NOJvMg6Obwle8kkaYUXlWfSCsunDDfBa5OZDx8o2jbXdjXkxr1z5yZAqUnN9pBLNNeRg 5A4lORX2vBkqKIw3ZzzcYZ1F7kQVSa/J48xq6/xucVH+XVyaWHqnKzby15pxUQXARxSj KCA4LCrddOoK8Wjh5KxZv3UkovFjbIBEiw8062u8cxt3hpcWLchP/+jkbpAg+05K6Fe3 LVGNbIEJl4M7u5ACDrQdCCwMKdFIaqIHxKZjezSV2BFT/BivHl65GcQ7ZOnL6iAARpT1 5B6g== X-Gm-Message-State: ALoCoQk+xXReYJNR3fIs9bgHnCClNarAY1kMCnPrtYJFDn6xkB1LWOo60xB16FTPwP5SG9X2Pv90 X-Received: by 10.50.79.196 with SMTP id l4mr5359069igx.16.1404312542521; Wed, 02 Jul 2014 07:49:02 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ky9sm43967900igb.13.2014.07.02.07.49.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 07:49:01 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_BCF575E8-B9A5-4E90-AF57-EAF27CE0393B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? From: Warner Losh In-Reply-To: <20140702022042.GG45513@funkthat.com> Date: Wed, 2 Jul 2014 08:49:22 -0600 Message-Id: <8756CB42-0B1B-4191-8A63-9D54FEE5D877@bsdimp.com> References: <201407011046.s61AkJpj006890@mech-cluster241.men.bris.ac.uk> <20140702022042.GG45513@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 14:49:04 -0000 --Apple-Mail=_BCF575E8-B9A5-4E90-AF57-EAF27CE0393B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 1, 2014, at 8:20 PM, John-Mark Gurney wrote: > Anton Shterenlikht wrote this message on Tue, Jul 01, 2014 at 11:46 = +0100: >>> =46rom r.c.ladan@gmail.com Tue Jul 1 11:37:35 2014 >>>=20 >>> 2014-07-01 11:25 GMT+02:00 Anton Shterenlikht : >>>=20 >>>> Why is it a good idea to mount /tmp and some var dirs on memory = disks: >>>>=20 >>>> root@raspberry-pi:/usr/ports # df -m >>>> Filesystem 1M-blocks Used Avail Capacity Mounted on >>>> /dev/mmcsd0s2a 14694 777 12742 6% / >>>> devfs 0 0 0 100% /dev >>>> /dev/mmcsd0s1 16 3 13 20% /boot/msdos >>>> /dev/md0 28 4 22 16% /tmp >>>> /dev/md1 14 0 12 0% /var/log >>>> /dev/md2 4 0 4 0% /var/tmp >>>> root@raspberry-pi:/usr/ports # >>>>=20 >>>> Is this about speed or power, or maybe space? >>>>=20 >>>> Mostly write tear because you're using an SD card, and it improves = speed >>> too. >>=20 >> "write tear"? >> Is this a joke, or some technical term? >> I cannot find what it means. >=20 > it is a technical term, though I'd be surprised if any SD card had > an issue w/ that anymore=85 SD cards are made from NAND flash. NAND flash is different than a hard = disk in that it has only a limited number of times you can write to a = given spot before it becomes unusable (well, hard drives have this too, = but the numbers are huge (1e20 or something like that if memory serves). = This number can be as low as a few hundred for the really low-end cheap = crap parts, but typically is a few thousand. The reason for this is = because you have to erase each NAND page before you can program it, and = each time you erase it you expose the cell to a huge negative potential = voltage. This leads to trapping of electrons, as well as some minor = physical damage, usually along tiny flaws in the manufacturing process. = The net effect is that the dynamic range of the cell is reduced, which = leads to errors which eventually get bad enough that the pages become = useless. Since there=92s actual physical damage to each program/erase = cycle, it is referred to as =93wear and tear.=94 You=92ll see references = to =93wear leveling=94 which attempts to wear out each block at about = the same rate. > write tear is where when writing data, only part of the data gets > written and then you loose power... This is mostly an issue on flash > where you have to erase the data beforey ou can program it... Most > flash now have a layer of indirection so that they copy/write the > data to a new flash block, and then point the block there before > erasing the old data... (kinda like a log FS)=85 Yes, nearly all block devices based on flash have some kind of log-based = system under the covers. It is a shame they don=92t expose the log = directly, since a number of interesting optimizations could be made in = host software that are not possible going through the translation layer = a log-bsed system imposes on the card. But we get what we get... Warner --Apple-Mail=_BCF575E8-B9A5-4E90-AF57-EAF27CE0393B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTtBvyAAoJEGwc0Sh9sBEARMwP/jg2oo8B1pcn2rXvmkv8/FbJ 4Qcgr3VPrEoU6lKkbpBdbRPJN9lG+TSqZu0YT3ie6cG9bQ7A+Y5cc2a4zr+pav02 HeFsOU0IMsvZj1eePhaAS6Zz4naw3ZLG/9bE8sORCLMhXv2kKmyMg2Vi4PILq36m sMG1yRV+3ohP0YZ0enJwoAZ8h1HGrl/emOlXQgVL1+E2F5r8YGnWE0XgRc3n9qi2 lDGVVxQCRkLlTge8W+Fkh5lxqb1e0Tj4A8zpnhko/XkriFlM8nkn5vm6hfBHbqHW 9D61QxPoFnJa6sE0rB0wNpPk7D26njA0GoRKvNAcm6waBajlabZEDSPGif88oZv9 tshflFG4Z7AgCU03R2sv3w9fkKSR2NpAQOvjhMxUeBI26PXuY4KrnFu6aa8LeMVd /HjyM6kyUehOzCARGHDt1yGKAG9OSpQQqh8Fkai/kVY4OcGERPYf+OtAkqx25Ymj +cTihDVXlsVtO+OVAICqB6teeMWsZXOPEar1RmN+wCjHNstwdMnpt1Q7ud9kgxOW d/plyvwVkg0ulYvZa69sUrF8fe1XgErgLsW2ZX1wV968C5FNaCaoJB9df2a4M1ib BZA9TW2mtclzulMp5u4xcHCrqhL97sUkco7pE1K0EVJqOQtKNw4KSvENr/YrXb+k yPU18zre1L9bwvaUegon =igD5 -----END PGP SIGNATURE----- --Apple-Mail=_BCF575E8-B9A5-4E90-AF57-EAF27CE0393B-- From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 20:49:08 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8601BE55 for ; Wed, 2 Jul 2014 20:49:08 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B2F92FF9 for ; Wed, 2 Jul 2014 20:49:08 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X2PXo-000Ou4-RI; Wed, 02 Jul 2014 18:46:13 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s62Ik91S000972; Wed, 2 Jul 2014 12:46:10 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/eQH5uRyWkrozBM1VVpI82 Subject: Re: Status of iic on wandboard From: Ian Lepore To: Tom Everett In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Jul 2014 12:46:09 -0600 Message-ID: <1404326769.20883.396.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 20:49:08 -0000 On Sun, 2014-06-29 at 18:47 -0600, Tom Everett wrote: > I see that there is an i2c driver for imx on the source tree, and there are > iic kernel options in /conf/IMX6, commented out. Does anyone know the > status of i2c for IMX? > > It works. I used it to write values to an i2c eeprom and read them back a few weeks ago. I haven't tested any other devices yet. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jul 2 21:47:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B06485E4 for ; Wed, 2 Jul 2014 21:47:26 +0000 (UTC) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 774EE257A for ; Wed, 2 Jul 2014 21:47:25 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id uy5so12983855obc.17 for ; Wed, 02 Jul 2014 14:47:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SCWKZyY1et7vkNIBy+A0E1E49y5miubHDP15qNR47+4=; b=S9GVqJF03nC0cwvs4S+9SW5RuJN6D4BOKoERmrAOjvpErnSfd1y8JgMyDUEKTZb4W+ tHQdjPbHnTwCOt6g48nMFiw2t1kTGrKtCDlROVQg8pAg715lUrkW5Jr04BpbIQ3kmM7N y87MtbHP813856n3rGJ6RW9S2FG/orAQ4zlufAo6iqAZTs+jpWTIV9LCHgOf5E+YDpyB XmZgScHUG4TNXQuS5sRuSCEHKP7ZAyvLAdzOFMkOtkQRq/jNbH9/gqyUVad2ld4nFC59 Fnce6Aji9HJxjyEPCaOW+VR7cUWStlaXRIhMsOPXtEuITZlpNrwfEtltFicq0wMzVT/o wNWA== X-Gm-Message-State: ALoCoQlT5Edt6eN/4fjuJfAs4qvSW2qZZI5dM5VXNRz44pZtlQr4b2V94OpqOcK/sUOHOEmcb0gM MIME-Version: 1.0 X-Received: by 10.60.143.37 with SMTP id sb5mr633496oeb.38.1404337638952; Wed, 02 Jul 2014 14:47:18 -0700 (PDT) Received: by 10.182.96.101 with HTTP; Wed, 2 Jul 2014 14:47:18 -0700 (PDT) In-Reply-To: <1404326769.20883.396.camel@revolution.hippie.lan> References: <1404326769.20883.396.camel@revolution.hippie.lan> Date: Wed, 2 Jul 2014 15:47:18 -0600 Message-ID: Subject: Re: Status of iic on wandboard From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 21:47:26 -0000 I'll enable iic, and build a wandboard image. I'll let the list know what happens. On Wed, Jul 2, 2014 at 12:46 PM, Ian Lepore wrote: > On Sun, 2014-06-29 at 18:47 -0600, Tom Everett wrote: > > I see that there is an i2c driver for imx on the source tree, and there > are > > iic kernel options in /conf/IMX6, commented out. Does anyone know the > > status of i2c for IMX? > > > > > > It works. I used it to write values to an i2c eeprom and read them back > a few weeks ago. I haven't tested any other devices yet. > > -- Ian > > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Thu Jul 3 01:00:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08DC09B0 for ; Thu, 3 Jul 2014 01:00:11 +0000 (UTC) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D013E274C for ; Thu, 3 Jul 2014 01:00:10 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id y10so12695699pdj.8 for ; Wed, 02 Jul 2014 18:00:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cZTVk/3JWLt1UuOutI320F8D6FPp+Md2KjCCtgbalCk=; b=UporbEv1S/toevSWcbCSm8KPhq/p/Ma2HeiyATy7tBYi/Az1zSQ0IBjwWW2SLiWaDq 4qbGkAr6b4lIM9ukKcQw9KEeHHuTm7dEMuIgFttVvTGge9hlGxD6q9u/PLJ9vxA5y5vk J88Rwb1AK3H6gCKvy3MitcXPKH0XiLalKGaNbvl5M3xgZ0avyj3TnUwm1pLehB/7LvsW tnMhlB1dr6A8Bkdnyf41Ao2cFwrtajXyDVQnxwpH4tMDmmZIEdcLLv7HboqNiHF9gNy6 ZD0/eEzr766axSzrQUJFjtvfCkSll9hR8+UW7HBlDD8ygak5xyIPMNznjVdNZxqlL/nx 5uJw== X-Gm-Message-State: ALoCoQl1PEwvf2/jqpjTcH/H5K5QpZ//1cZe1fsdSI3UlmiDQnl3i99ikKa/ZXUjHe1A2RVZH68/ X-Received: by 10.68.181.165 with SMTP id dx5mr1402349pbc.38.1404349209775; Wed, 02 Jul 2014 18:00:09 -0700 (PDT) Received: from [192.168.1.103] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id pn4sm38815645pbb.7.2014.07.02.18.00.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 18:00:09 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: svnlite segfaults a lot From: Tim Kientzle In-Reply-To: <20140702092041.716a7413@bender.lan> Date: Wed, 2 Jul 2014 17:59:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87CAF73D-A744-472D-B9B0-BA2E5B2B8158@kientzle.com> References: <201407010930.s619Uk9X006689@mech-cluster241.men.bris.ac.uk> <20140702092041.716a7413@bender.lan> To: FreeBSD ARM X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 01:00:11 -0000 On Jul 2, 2014, at 1:20 AM, Andrew Turner wrote: > On Tue, 1 Jul 2014 10:30:46 +0100 (BST) > Anton Shterenlikht wrote: >=20 >> # uname -a >> FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267801: >> Tue Jun 24 11:03:28 UTC 2014 >> root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >>=20 >> I'm trying to pull the ports tree to rasp. pi model B. >> svnlite up (or co) segfaults after pulling 1-5 MB. >> Is this expected? >>=20 >> I'm powering via a bench power supply, so I can >> monitor the current. It is only about 400mA, >> occasionally raising to maybe 450mA. >> So my earlier suspicion, that an inadequate >> power was to blame, was wrong. >>=20 >> Anybody else seeing svnlite segfaults? >=20 > Yes, however I never tracked it down. I found svn from ports to work = as > expected. It wasn=92t this way a month or two ago when I used it last. But I tried just now and it=92s pretty bad. Trying to check out http://svn.freebsd.org/base/head segfaults after a thousand or so items (not always at the same point). Of course, gdb doesn=92t seem to be able to make any sense of the core file: $ gdb /usr/bin/svnlite ... (gdb) core svnlite.core =85 loading many symbols ... (gdb) bt #0 0x0008dbac in ?? () (gdb) =85 Trying to =93run update=94 from inside GDB immediately hits SIGILL in _rtld_get_stack_prot() Tim From owner-freebsd-arm@FreeBSD.ORG Thu Jul 3 06:20:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B5A9ABA; Thu, 3 Jul 2014 06:20:23 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF7E22FB3; Thu, 3 Jul 2014 06:20:22 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id a1so12388320wgh.24 for ; Wed, 02 Jul 2014 23:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Xger8mFH1ABgJmzlfDkRUnIHxKcSLRYzsfyeaCOWEtc=; b=K5cjfA9XDnmCYNgHnYJUgcIwixkrw99NcpRQda3OPEPe5i1YMyyV0n5M1NBuA9Fg0a EzfscRqZVdM0IzP9pLxds26OJ42sKaW772k1iR71mb7R7YlykbrMEvzZB6xHCYN+cOGP u+yY2S7ctWzGDTxoK5XdF6NyeAP1YeokuFNHfoOUdsXyBDZIy5u3cBrEdAg5L6aYETGc Ng65uyTxKlEFpaRXRaEjbbkAj0lQgLtKJFIwYpDJ/fDlLzGIl4V6yLQf34CpAh7RJMGo HP2Z5hDTSmbXeRbZaFITr9vkAdBhvsMpXs9jbx8ynN+EfoW2zjqlbe8nLFNlZUf3C7vJ 3q7A== X-Received: by 10.180.19.40 with SMTP id b8mr9169469wie.77.1404368421077; Wed, 02 Jul 2014 23:20:21 -0700 (PDT) Received: from [192.168.0.10] (178-83-152-199.dynamic.hispeed.ch. [178.83.152.199]) by mx.google.com with ESMTPSA id gq4sm29581781wib.8.2014.07.02.23.20.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 23:20:20 -0700 (PDT) From: Mattia Rossi X-Google-Original-From: Mattia Rossi Message-ID: <53B4F621.3040306@gmail.com> Date: Thu, 03 Jul 2014 08:20:17 +0200 Reply-To: mattia.rossi.mate@gmail.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Anton Shterenlikht , rene@freebsd.org, freebsd-arm@freebsd.org Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? References: <201407011046.s61AkJpj006890@mech-cluster241.men.bris.ac.uk> <20140702022042.GG45513@funkthat.com> In-Reply-To: <20140702022042.GG45513@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 06:20:23 -0000 On 02/07/14 04:20, John-Mark Gurney wrote: > Anton Shterenlikht wrote this message on Tue, Jul 01, 2014 at 11:46 +0100: >> >From r.c.ladan@gmail.com Tue Jul 1 11:37:35 2014 >>> 2014-07-01 11:25 GMT+02:00 Anton Shterenlikht : >>> >>>> Why is it a good idea to mount /tmp and some var dirs on memory disks: >>>> >>>> root@raspberry-pi:/usr/ports # df -m >>>> Filesystem 1M-blocks Used Avail Capacity Mounted on >>>> /dev/mmcsd0s2a 14694 777 12742 6% / >>>> devfs 0 0 0 100% /dev >>>> /dev/mmcsd0s1 16 3 13 20% /boot/msdos >>>> /dev/md0 28 4 22 16% /tmp >>>> /dev/md1 14 0 12 0% /var/log >>>> /dev/md2 4 0 4 0% /var/tmp >>>> root@raspberry-pi:/usr/ports # >>>> >>>> Is this about speed or power, or maybe space? >>>> >>>> Mostly write tear because you're using an SD card, and it improves speed >>> too. >> "write tear"? >> Is this a joke, or some technical term? >> I cannot find what it means. > it is a technical term, though I'd be surprised if any SD card had > an issue w/ that anymore... > > write tear is where when writing data, only part of the data gets > written and then you loose power... This is mostly an issue on flash > where you have to erase the data beforey ou can program it... Most > flash now have a layer of indirection so that they copy/write the > data to a new flash block, and then point the block there before > erasing the old data... (kinda like a log FS)... > > Something like this will happen once your SD card is weared off.... grmbl: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 19 5c 26 00 00 80 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:30,0 (Incompatible medium i nstalled) (da0:umass-sim0:0:0:0): Retrying command (per sense data) (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 19 5c 26 00 00 80 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) (da0:umass-sim0:0:0:0): Retrying command (per sense data) g_vfs_done():da0s2[WRITE(offset=799834112, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=799965184, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=800096256, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=800227328, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem softdep_deallocate_dependencies: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=800391168, length=131072)]error = 6 g_vfs_done():da0s2[WRITE(offset=800522240, length=131072)]error = 6 g_vfs_done():da0s2[WRITE(offset=800653312, length=131072)]error = 6 g_vfs_done():da0s2[WRITE(offset=800391168, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=800522240, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=800653312, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=800817152, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=800948224, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=801079296, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=801210368, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=801341440, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=801472512, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=801603584, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=801734656, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=801865728, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=801996800, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=802127872, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem softdep_deallocate_dependencies: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=802324480, length=131072)]error = 6 g_vfs_done():da0s2[WRITE(offset=802455552, length=131072)]error = 6 g_vfs_done():da0s2[WRITE(offset=802586624, length=131072)]error = 6 g_vfs_done():da0s2[WRITE(offset=802324480, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=802455552, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=802586624, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=802750464, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=802881536, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=803012608, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=803143680, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=803274752, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=803405824, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=803536896, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=803667968, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=803799040, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=803930112, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem g_vfs_done():da0s2[WRITE(offset=804061184, length=131072)]error = 6 /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem softdep_deallocate_dependencies: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem /: got error 6 while accessing filesystem softdep_deallocate_dependencies: got error 6 while accessing filesystem panic: Bad link elm 0xc5418700 prev->next != elm KDB: enter: panic [ thread pid 62848 tid 100082 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> From owner-freebsd-arm@FreeBSD.ORG Thu Jul 3 10:47:26 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DD37438 for ; Thu, 3 Jul 2014 10:47:26 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 18D6C27D5 for ; Thu, 3 Jul 2014 10:47:25 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s63AlOeS099531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jul 2014 04:47:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s63AlODs099528; Thu, 3 Jul 2014 04:47:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 3 Jul 2014 04:47:24 -0600 (MDT) From: Warren Block To: Mattia Rossi Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? In-Reply-To: <53B3EB29.4030908@gmail.com> Message-ID: References: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> <44a6e8a451a.810fa8f@mail.schwarzes.net> <53B3EB29.4030908@gmail.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 03 Jul 2014 04:47:24 -0600 (MDT) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 10:47:26 -0000 On Wed, 2 Jul 2014, Mattia Rossi wrote: > > Am 01.07.2014 21:27, schrieb Andreas Schwarz: >> Speed and speed, but I can't understand why using md here, there is already >> tmpfs, >> which optimzed for such cases (dynamic allocation, etc.). >> >> root@pizelot:~ # df >> Filesystem 1K-blocks Used Avail Capacity Mounted on >> /dev/mmcsd0s2a 983680 57252 847736 6% / >> devfs 1 1 0 100% /dev >> /dev/mmcsd0s2d 8106716 3068708 4389472 41% /usr >> /dev/mmcsd0s2e 8106716 155976 7302204 2% /var >> /dev/mmcsd0s2f 8106716236 7457944 0% /home >> tmpfs 1097160 4 1097156 0% /tmp >> tmpfs 1097160 4 1097156 0% /var/tmp >> > > On an embedded systems with little memory I prefer to limit the partitions to > a certain size, like 32M, so dynamic allocation is no advantage. What other > differences are there between tmpfs and a simple md device? > I'd be interested in knowing any tricks, that can make the system faster :-) The white paper on tmpfs (wiki.deimos.fr/images/1/1e/Solaris_tmpfs.pdf) says: "RAM disks use memory inefficiently; file data exists twice in both RAM disk memory and kernel memory, and RAM disk memory that is not being used by the file system is wasted. RAM disk memory is maintained separately from kernel memory, so that multiple memory-to-memory copies are needed to update file system data." So a limited-size tmpfs will be faster and use less memory overall. A benchmark comparison would be interesting. From owner-freebsd-arm@FreeBSD.ORG Thu Jul 3 10:55:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E61F7CC for ; Thu, 3 Jul 2014 10:55:29 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9E228DB for ; Thu, 3 Jul 2014 10:55:28 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id B94C3B843; Thu, 3 Jul 2014 12:55:19 +0200 (SAST) Date: Thu, 3 Jul 2014 12:55:19 +0200 From: John Hay To: Warren Block Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? Message-ID: <20140703105519.GA37593@zibbi.meraka.csir.co.za> References: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> <44a6e8a451a.810fa8f@mail.schwarzes.net> <53B3EB29.4030908@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 10:55:29 -0000 On Thu, Jul 03, 2014 at 04:47:24AM -0600, Warren Block wrote: > On Wed, 2 Jul 2014, Mattia Rossi wrote: > > > > > Am 01.07.2014 21:27, schrieb Andreas Schwarz: > >> Speed and speed, but I can't understand why using md here, there is already > >> tmpfs, > >> which optimzed for such cases (dynamic allocation, etc.). > >> > >> root@pizelot:~ # df > >> Filesystem 1K-blocks Used Avail Capacity Mounted on > >> /dev/mmcsd0s2a 983680 57252 847736 6% / > >> devfs 1 1 0 100% /dev > >> /dev/mmcsd0s2d 8106716 3068708 4389472 41% /usr > >> /dev/mmcsd0s2e 8106716 155976 7302204 2% /var > >> /dev/mmcsd0s2f 8106716236 7457944 0% /home > >> tmpfs 1097160 4 1097156 0% /tmp > >> tmpfs 1097160 4 1097156 0% /var/tmp > >> > > > > On an embedded systems with little memory I prefer to limit the partitions to > > a certain size, like 32M, so dynamic allocation is no advantage. What other > > differences are there between tmpfs and a simple md device? > > I'd be interested in knowing any tricks, that can make the system faster :-) > > The white paper on tmpfs (wiki.deimos.fr/images/1/1e/Solaris_tmpfs.pdf) > says: > > "RAM disks use memory inefficiently; file data exists twice in both > RAM disk memory and kernel memory, and RAM disk memory that is not > being used by the file system is wasted. RAM disk memory is > maintained separately from kernel memory, so that multiple > memory-to-memory copies are needed to update file system data." > > So a limited-size tmpfs will be faster and use less memory overall. A > benchmark comparison would be interesting. Last time I looked the rc scripts that create /etc, /var and /tmp ramdisks only did it using md devices. It would be great if it was easily tunable from say rc.conf or if could detect which one is available and use that. John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Thu Jul 3 14:07:56 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75C0DCD8 for ; Thu, 3 Jul 2014 14:07:56 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4848B2C87 for ; Thu, 3 Jul 2014 14:07:56 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X2hfx-000L17-9Y; Thu, 03 Jul 2014 14:07:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s63E7j5K001246; Thu, 3 Jul 2014 08:07:45 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18dRbW9ABnZUARIalIyngZb Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? From: Ian Lepore To: John Hay In-Reply-To: <20140703105519.GA37593@zibbi.meraka.csir.co.za> References: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> <44a6e8a451a.810fa8f@mail.schwarzes.net> <53B3EB29.4030908@gmail.com> <20140703105519.GA37593@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset="us-ascii" Date: Thu, 03 Jul 2014 08:07:44 -0600 Message-ID: <1404396464.20883.404.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:07:56 -0000 On Thu, 2014-07-03 at 12:55 +0200, John Hay wrote: > On Thu, Jul 03, 2014 at 04:47:24AM -0600, Warren Block wrote: > > On Wed, 2 Jul 2014, Mattia Rossi wrote: > > > > > > > > Am 01.07.2014 21:27, schrieb Andreas Schwarz: > > >> Speed and speed, but I can't understand why using md here, there is already > > >> tmpfs, > > >> which optimzed for such cases (dynamic allocation, etc.). > > >> > > >> root@pizelot:~ # df > > >> Filesystem 1K-blocks Used Avail Capacity Mounted on > > >> /dev/mmcsd0s2a 983680 57252 847736 6% / > > >> devfs 1 1 0 100% /dev > > >> /dev/mmcsd0s2d 8106716 3068708 4389472 41% /usr > > >> /dev/mmcsd0s2e 8106716 155976 7302204 2% /var > > >> /dev/mmcsd0s2f 8106716236 7457944 0% /home > > >> tmpfs 1097160 4 1097156 0% /tmp > > >> tmpfs 1097160 4 1097156 0% /var/tmp > > >> > > > > > > On an embedded systems with little memory I prefer to limit the partitions to > > > a certain size, like 32M, so dynamic allocation is no advantage. What other > > > differences are there between tmpfs and a simple md device? > > > I'd be interested in knowing any tricks, that can make the system faster :-) > > > > The white paper on tmpfs (wiki.deimos.fr/images/1/1e/Solaris_tmpfs.pdf) > > says: > > > > "RAM disks use memory inefficiently; file data exists twice in both > > RAM disk memory and kernel memory, and RAM disk memory that is not > > being used by the file system is wasted. RAM disk memory is > > maintained separately from kernel memory, so that multiple > > memory-to-memory copies are needed to update file system data." > > > > So a limited-size tmpfs will be faster and use less memory overall. A > > benchmark comparison would be interesting. > > Last time I looked the rc scripts that create /etc, /var and /tmp > ramdisks only did it using md devices. It would be great if it was > easily tunable from say rc.conf or if could detect which one is > available and use that. > > John I have patches ready to commit that do exactly that, but they weren't exactly enthusiastically received when I posted them on arch@ for review. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Jul 3 15:36:48 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D394CC4 for ; Thu, 3 Jul 2014 15:36:48 +0000 (UTC) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id D011A25F6 for ; Thu, 3 Jul 2014 15:36:46 +0000 (UTC) Received: (qmail 95277 invoked by uid 1004); 3 Jul 2014 15:30:00 -0000 Message-ID: <53B576F0.60609@uffe.org> Date: Thu, 03 Jul 2014 17:29:52 +0200 From: Uffe Jakobsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? References: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> <44a6e8a451a.810fa8f@mail.schwarzes.net> <53B3EB29.4030908@gmail.com> <20140703105519.GA37593@zibbi.meraka.csir.co.za> <1404396464.20883.404.camel@revolution.hippie.lan> In-Reply-To: <1404396464.20883.404.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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 15:36:48 -0000 On 2014-07-03 16:07, Ian Lepore wrote: > On Thu, 2014-07-03 at 12:55 +0200, John Hay wrote: >> >> Last time I looked the rc scripts that create /etc, /var and /tmp >> ramdisks only did it using md devices. It would be great if it was >> easily tunable from say rc.conf or if could detect which one is >> available and use that. >> > > I have patches ready to commit that do exactly that, but they weren't > exactly enthusiastically received when I posted them on arch@ for > review. > IMHO: such rc.conf config option would be highly useful /Uffe From owner-freebsd-arm@FreeBSD.ORG Thu Jul 3 17:49:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51149DBB; Thu, 3 Jul 2014 17:49:41 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F09C622FB; Thu, 3 Jul 2014 17:49:40 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s63Hnddp004088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jul 2014 11:49:39 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s63HndsR004085; Thu, 3 Jul 2014 11:49:39 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 3 Jul 2014 11:49:39 -0600 (MDT) From: Warren Block To: Ian Lepore Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? In-Reply-To: <1404396464.20883.404.camel@revolution.hippie.lan> Message-ID: References: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> <44a6e8a451a.810fa8f@mail.schwarzes.net> <53B3EB29.4030908@gmail.com> <20140703105519.GA37593@zibbi.meraka.csir.co.za> <1404396464.20883.404.camel@revolution.hippie.lan> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 03 Jul 2014 11:49:39 -0600 (MDT) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 17:49:41 -0000 On Thu, 3 Jul 2014, Ian Lepore wrote: > On Thu, 2014-07-03 at 12:55 +0200, John Hay wrote: >> On Thu, Jul 03, 2014 at 04:47:24AM -0600, Warren Block wrote: >>> >>> So a limited-size tmpfs will be faster and use less memory overall. A >>> benchmark comparison would be interesting. >> >> Last time I looked the rc scripts that create /etc, /var and /tmp >> ramdisks only did it using md devices. It would be great if it was >> easily tunable from say rc.conf or if could detect which one is >> available and use that. > > I have patches ready to commit that do exactly that, but they weren't > exactly enthusiastically received when I posted them on arch@ for > review. This thread? http://lists.freebsd.org/pipermail/freebsd-arch/2014-March/015141.html Have not read it fully yet, but it sounds exactly right: everything acts the same, the user can just pick tmpfs or mfs. From owner-freebsd-arm@FreeBSD.ORG Fri Jul 4 07:11:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C7EB848 for ; Fri, 4 Jul 2014 07:11:35 +0000 (UTC) Received: from felyko.com (felyko.com [65.49.80.26]) by mx1.freebsd.org (Postfix) with ESMTP id 09D9327C4 for ; Fri, 4 Jul 2014 07:11:34 +0000 (UTC) Received: from [IPv6:2601:9:8280:426:7822:e465:96a2:deb9] (unknown [IPv6:2601:9:8280:426:7822:e465:96a2:deb9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id B496034A9E4; Fri, 4 Jul 2014 00:11:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: svnlite segfaults in 11 but not in 10 From: Rui Paulo In-Reply-To: <201407021218.s62CITOU015474@mech-cluster241.men.bris.ac.uk> Date: Fri, 4 Jul 2014 00:11:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201407021218.s62CITOU015474@mech-cluster241.men.bris.ac.uk> To: mexas@bris.ac.uk X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 07:11:35 -0000 On Jul 2, 2014, at 5:18, Anton Shterenlikht wrote: > I confirm that svnlite does not segfault on: >=20 > $ uname -a > FreeBSD raspberry-pi 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue = Jul 1 04:29:43 UTC 2014 = root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >=20 >=20 > Shall I submit a PR on this? Yes, please. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Fri Jul 4 08:07:40 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D322E81 for ; Fri, 4 Jul 2014 08:07:40 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 258832C75 for ; Fri, 4 Jul 2014 08:07:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6487e7b031538 for ; Fri, 4 Jul 2014 09:07:40 +0100 (BST) (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 191599] New: base OS svnlite segfaults at random Date: Fri, 04 Jul 2014 08:07:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mexas@bris.ac.uk X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 08:07:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191599 Bug ID: 191599 Summary: base OS svnlite segfaults at random Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: mexas@bris.ac.uk On raspberry pi model B, with r267801 11-curent, the base OS svnlite segfauts a lot on pulling the ports tree. By "a lot" I mean that it segfaults after pulling about 3-10MB of data, sometimes less, sometimes more. In the end I gave up and installed FreeBSD raspberry-pi 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul 1 04:29:43 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm I haven't seen svnlite segfault once yet in that version. Somebody tried to dig deeper, with little success: http://lists.freebsd.org/pipermail/freebsd-arm/2014-July/008759.html -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jul 4 08:14:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA865208 for ; Fri, 4 Jul 2014 08:14:09 +0000 (UTC) Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4987D2D33 for ; Fri, 4 Jul 2014 08:14:08 +0000 (UTC) Received: from mail-wi0-f179.google.com ([209.85.212.179]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKU7ZiSMYiDlXm7UgVED3Bc/ae/5XbXuZ/@postini.com; Fri, 04 Jul 2014 08:14:09 UTC Received: by mail-wi0-f179.google.com with SMTP id cc10so3410198wib.0 for ; Fri, 04 Jul 2014 01:14:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=44yCDZjLo0FMY5x6QhrmpVprKv9xOwqnf3RHw6egdhg=; b=f8VmMeoJthREFfNcsUp1S/oBQFPah1vkQejUaOPKct3+I+DvyJ8VKA7RqxSVNdsC5V P3ldJsbwFStdmUB89wOemVhXf2hQZXxyZ8UlOuHRA9K/AuSysD9+yeueAqBpOyq0CRRQ amEY+eAWIoVnHABXqV1yTptzCt5WO1vaIIR0Mbh3HZrwTRAXrKISG8iQ89EdoxuEiLMQ X62NLiVte1TgA4C4vrXD9OM+A4WejMY+X6E2uix9kG9ffyIIP5fmx/mlhrEOglRqoJ65 uA+eZN3ApXnAbo0mWxh8H03hd9j7leWC38/wGZFkNSM0k3IUDDt1ndxxUHWU2om43NL9 xm/g== X-Received: by 10.194.63.77 with SMTP id e13mr8388469wjs.104.1404461319344; Fri, 04 Jul 2014 01:08:39 -0700 (PDT) X-Gm-Message-State: ALoCoQlmP+0uhasPjEUAf9+ElMMmMQLsjgsWUEblUKL2GuRO3Ply/4Gd+Ox5Qni2s/izuthz1wNjZhrWYAks3IxFqjKiKp4AhWbkH6VZZuxWQIMCiOCPNxfAodctiRu7EhpIvlMbLIm4 X-Received: by 10.194.63.77 with SMTP id e13mr8388449wjs.104.1404461319229; Fri, 04 Jul 2014 01:08:39 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id kp5sm67374159wjb.30.2014.07.04.01.08.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jul 2014 01:08:38 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6488YaB031236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Jul 2014 09:08:35 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6488YB1031235; Fri, 4 Jul 2014 09:08:34 +0100 (BST) (envelope-from mexas) Date: Fri, 4 Jul 2014 09:08:34 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407040808.s6488YB1031235@mech-cluster241.men.bris.ac.uk> To: mexas@bris.ac.uk, rpaulo@FreeBSD.org Subject: Re: svnlite segfaults in 11 but not in 10 Reply-To: mexas@bris.ac.uk In-Reply-To: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 08:14:10 -0000 >From rpaulo@freebsd.org Fri Jul 4 08:15:40 2014 > >On Jul 2, 2014, at 5:18, Anton Shterenlikht wrote: > >> I confirm that svnlite does not segfault on: >> >> $ uname -a >> FreeBSD raspberry-pi 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul 1 04:29:43 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >> >> >> Shall I submit a PR on this? > >Yes, please. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191599 Anton From owner-freebsd-arm@FreeBSD.ORG Fri Jul 4 10:26:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1498A3E for ; Fri, 4 Jul 2014 10:26:19 +0000 (UTC) Received: from eu1sys200aog106.obsmtp.com (eu1sys200aog106.obsmtp.com [207.126.144.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14C362975 for ; Fri, 4 Jul 2014 10:26:18 +0000 (UTC) Received: from mail-wi0-f179.google.com ([209.85.212.179]) (using TLSv1) by eu1sys200aob106.postini.com ([207.126.147.11]) with SMTP ID DSNKU7aBLuTwXCA1t+R2RSSfTrCupU80TPvv@postini.com; Fri, 04 Jul 2014 10:26:19 UTC Received: by mail-wi0-f179.google.com with SMTP id cc10so3593807wib.0 for ; Fri, 04 Jul 2014 03:25:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=WMYFio76XLHKyyMFPTexCx5ZDAvCV8H4AvbnvnM2jgc=; b=iRoJj2UnbfNM3BO1zheTegv3SJWBc/OsWQl40Ivff5LK9icv4r6eY3AoybQN2YBUnZ BwmTXf/+tQf5QiA/I31e0mNh1a+NKVnSddvAYB0Jb8aM4kEKZYN5ym3Js/CHytc+u/yh 55M+sWF4aOs3eL3R9C6yu/37Twb9kut7xFVYpeFWUNQ4yuWJOMp6yr2NMuHs9HYkBA27 5Ljfca184w8jACKimvCyVVkoDGlBxPIb8Iytu1AqO3ITYnyTyHuZqKoaHFhBlR2juRVB 6EcZ21DS58OMbdudG+825Py3Guco3Gv0UA80jz69wTN07AJRvMcA+NNFuDzcV+QkdY0s g1Qg== X-Gm-Message-State: ALoCoQmNZ5OJfQBpf5Skp0Y/ubN5NxUnXhoLtZ72x9PvaXe5CByqTVEMVskaWm/v5r4CU2SU3nEic7DUN2PP8lGgyczoa/Aj0xYVWWammGIi0CVK0u2cpVMCWc7VfoOc86kueOcMjYaR X-Received: by 10.180.189.234 with SMTP id gl10mr16909155wic.56.1404469550627; Fri, 04 Jul 2014 03:25:50 -0700 (PDT) X-Received: by 10.180.189.234 with SMTP id gl10mr16909146wic.56.1404469550544; Fri, 04 Jul 2014 03:25:50 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id ex4sm77674157wic.2.2014.07.04.03.25.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jul 2014 03:25:50 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s64APmaP031650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 4 Jul 2014 11:25:48 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s64APml0031649 for freebsd-arm@freebsd.org; Fri, 4 Jul 2014 11:25:48 +0100 (BST) (envelope-from mexas) Date: Fri, 4 Jul 2014 11:25:48 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: official packages for arm? Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 10:26:19 -0000 Few silly questions, please don't shoot. 1. Why are there no official arm packages? Lack of interest from users? Lack of volunteers maintaining the arm portscluster infrastructure? The fact that arm is actually several implementations (RPI, wandboard, etc. OABI vs EABI)? 2. Are there any specific arm considerations when building ports? To do with build time? To do with processor capabilities? 3. As a guideline, if using external disk for building ports (e.g. usb flash media, usb hard disk, usb SSD) is the I/O speed important? Or is the bottleneck the processor speed? 4. Of the three external media: (1) usb flash drive, (2) usb hard (moving parts) disk, (3) usb SSD, which is faster in broad terms. I understand YMMV. 5. The default RPI-B kernel is very lean: http://svnweb.freebsd.org/base/head/sys/arm/conf/RPI-B?view=markup Still there are things which (I think) I don't need, e.g. USB ethernet. Will I gain anything by removing USB ethernet from the kernel? 6. What is spibus? Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Fri Jul 4 16:12:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E996AA5C for ; Fri, 4 Jul 2014 16:12:41 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id BD3B92945 for ; Fri, 4 Jul 2014 16:12:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id BA1DC3806F for ; Fri, 4 Jul 2014 11:12:34 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id TzdnkY4W_KaO for ; Fri, 4 Jul 2014 11:12:34 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 28BBF3806D for ; Fri, 4 Jul 2014 11:12:34 -0500 (CDT) Message-ID: <53B6D26F.8080905@freebsd.org> Date: Fri, 04 Jul 2014 09:12:31 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: official packages for arm? References: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:12:42 -0000 On 07/04/14 03:25, Anton Shterenlikht wrote: > Few silly questions, please don't shoot. > > 1. Why are there no official arm packages? > Lack of interest from users? > Lack of volunteers maintaining the arm portscluster > infrastructure? > The fact that arm is actually several implementations > (RPI, wandboard, etc. OABI vs EABI)? The basic issue is that building packages takes a lot of CPU time (it's about a CPU-month with moderately fast CPUs) and the project doesn't have the hardware to do it. -Nathan From owner-freebsd-arm@FreeBSD.ORG Fri Jul 4 16:21:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C1EAD4F for ; Fri, 4 Jul 2014 16:21:55 +0000 (UTC) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44CD929BF for ; Fri, 4 Jul 2014 16:21:54 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id i7so1991018oag.3 for ; Fri, 04 Jul 2014 09:21:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TvCI2fHn8O0S7B2r1g0OD5UV2YJq6Tuvb+++n+u+2Ds=; b=MRfRTo/FrsDJGYQTt1id3kdzM3S8uwMzYvYoRO3GrzS1Uz/WkJXbmv2LGWeG1NAq8F ixc3A1T6vz0Av8dsQQT75AG0rUGTia0lM4sSL9lXsW2q2rpahBouIv813+WFeDlEXJLJ WZLaYTx/R4jJ6NvbpQSG7uPqL+C9++7fgzYltuDwW+NQuuLFV1f8U9EoXF+b8LXvg1T9 Czf9dtN45xPV3wGyoqCPr6oaRJsdiOMnfetHJW+RURWRAIg/3nmyOvNk4A+HUSQHy1lZ BZ7bMp3qrk2GLKW5YcaG4ei6XNB9C3MhrPkXM2K7DPnruIN/IKnhB0jLp7t4xtpF1yjO GPTA== X-Gm-Message-State: ALoCoQnjJxLFLtmZ3tF9mfTSIWotf71+QnbdPR5bHZjt7sMXdusxJX44XtzGdUz6T8g69VoTlbq2 MIME-Version: 1.0 X-Received: by 10.60.220.131 with SMTP id pw3mr13523024oec.62.1404490908697; Fri, 04 Jul 2014 09:21:48 -0700 (PDT) Received: by 10.182.96.101 with HTTP; Fri, 4 Jul 2014 09:21:48 -0700 (PDT) In-Reply-To: <53B6D26F.8080905@freebsd.org> References: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> <53B6D26F.8080905@freebsd.org> Date: Fri, 4 Jul 2014 10:21:48 -0600 Message-ID: Subject: Re: official packages for arm? From: Tom Everett To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:21:55 -0000 How much hardware does it actually need? For that matter, how do the other architectures handle this problem? On Fri, Jul 4, 2014 at 10:12 AM, Nathan Whitehorn wrote: > On 07/04/14 03:25, Anton Shterenlikht wrote: > >> Few silly questions, please don't shoot. >> >> 1. Why are there no official arm packages? >> Lack of interest from users? >> Lack of volunteers maintaining the arm portscluster >> infrastructure? >> The fact that arm is actually several implementations >> (RPI, wandboard, etc. OABI vs EABI)? >> > > The basic issue is that building packages takes a lot of CPU time (it's > about a CPU-month with moderately fast CPUs) and the project doesn't have > the hardware to do it. > -Nathan > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Fri Jul 4 18:28:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7994BC20 for ; Fri, 4 Jul 2014 18:28:29 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 49C3F24EF for ; Fri, 4 Jul 2014 18:28:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 443E23806E; Fri, 4 Jul 2014 13:28:28 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id kIVGBe2S6HnT; Fri, 4 Jul 2014 13:28:28 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id CAAB73806D; Fri, 4 Jul 2014 13:28:27 -0500 (CDT) Message-ID: <53B6F24A.2070703@freebsd.org> Date: Fri, 04 Jul 2014 11:28:26 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Everett Subject: Re: official packages for arm? References: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> <53B6D26F.8080905@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 18:28:29 -0000 There are no longer any packages for any non-x86 architecture as a result of the security breach last year. There are basically three reasons for this: 1. The old package build infrastructure got abandoned. 2. The new scheme requires one giant machine to build all the packages, which is hard for ARM. 3. There seems to be some policy that package-build latency should be less than a day or two for security reasons, which is hard without huge numbers of CPUs. These aren't that hard to fix. There are two ways to fix (2). There has been a bunch of effort from many people in being able to cross-build packages. An alternative is to distribute the builds over a cluster, which I've been doing for 32-bit PPC (thanks to clusteradm@ providing some resources!). That works well, and if ARM hardware appeared in the cluster, it would be easy to set that up tomorrow. From the OS development side, native builds are nice because they stress-test the operating system in a way that cross-builds don't. Fixing (3) requires a policy change. I think the easiest would be a Tier-1/Tier-2 thing like for the base system. x86 packages are guaranteed to get prompt security updates and have more paranoid validation. Tier-2 might be slower, or built on non-centrally controlled hardware, or whatever. -Nathan On 07/04/14 09:21, Tom Everett wrote: > How much hardware does it actually need? For that matter, how do the > other architectures handle this problem? > > > > On Fri, Jul 4, 2014 at 10:12 AM, Nathan Whitehorn > > wrote: > > On 07/04/14 03:25, Anton Shterenlikht wrote: > > Few silly questions, please don't shoot. > > 1. Why are there no official arm packages? > Lack of interest from users? > Lack of volunteers maintaining the arm portscluster > infrastructure? > The fact that arm is actually several implementations > (RPI, wandboard, etc. OABI vs EABI)? > > > The basic issue is that building packages takes a lot of CPU time > (it's about a CPU-month with moderately fast CPUs) and the project > doesn't have the hardware to do it. > -Nathan > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to > "freebsd-arm-unsubscribe@freebsd.org > " > > > > > -- > A better world shall emerge based on faith and understanding - > Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Fri Jul 4 18:39:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4D65FE2 for ; Fri, 4 Jul 2014 18:39:54 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B16B625E7 for ; Fri, 4 Jul 2014 18:39:54 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s64IdoJ5041357; Fri, 4 Jul 2014 18:39:50 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id mn8uuqfce66ta3s2wyed5x9ave; Fri, 04 Jul 2014 18:39:50 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: official packages for arm? From: Tim Kientzle In-Reply-To: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> Date: Fri, 4 Jul 2014 11:39:49 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> To: mexas@bris.ac.uk X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 18:39:54 -0000 On Jul 4, 2014, at 3:25 AM, Anton Shterenlikht wrote: > Few silly questions, please don't shoot. > > 1. Why are there no official arm packages? Nathan answered this pretty completely, I think. > 2. Are there any specific arm considerations when > building ports? To do with build time? To do with > processor capabilities? Biggest issue is simply that key ports still don't build on ARM. For example, a default build of git breaks because libgcrypt requires GCC 4.7 port, which doesn't build on ARM. > 3. As a guideline, if using external disk > for building ports (e.g. usb flash media, > usb hard disk, usb SSD) is the I/O speed > important? Or is the bottleneck the processor speed? My impression is that I/O is the major problem. Especially for larger packages where the compiler can end up swapping. > 4. Of the three external media: (1) usb flash > drive, (2) usb hard (moving parts) disk, > (3) usb SSD, which is faster in broad terms. > I understand YMMV. I haven't experimented with different USB drives. > 5. The default RPI-B kernel is very lean: > http://svnweb.freebsd.org/base/head/sys/arm/conf/RPI-B?view=markup > > Still there are things which (I think) > I don't need, e.g. USB ethernet. > Will I gain anything by removing USB ethernet > from the kernel? The on-board Ethernet for RPi is actually connected through USB. If you remove USB Ethernet, you have removed Ethernet. Removing what you don't need will free up more RAM, which is always good. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Fri Jul 4 18:56:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46114706 for ; Fri, 4 Jul 2014 18:56:47 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 089212783 for ; Fri, 4 Jul 2014 18:56:47 +0000 (UTC) Received: from [192.168.1.200] (p508F0AD6.dip0.t-ipconnect.de [80.143.10.214]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3F77F1C0B4620; Fri, 4 Jul 2014 20:56:43 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: official packages for arm? From: Michael Tuexen In-Reply-To: Date: Fri, 4 Jul 2014 20:56:40 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> To: Tim Kientzle X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 18:56:47 -0000 On 04 Jul 2014, at 20:39, Tim Kientzle wrote: > > On Jul 4, 2014, at 3:25 AM, Anton Shterenlikht wrote: > >> Few silly questions, please don't shoot. >> >> 1. Why are there no official arm packages? > > Nathan answered this pretty completely, I think. > >> 2. Are there any specific arm considerations when >> building ports? To do with build time? To do with >> processor capabilities? > > Biggest issue is simply that key ports still > don't build on ARM. For example, a default > build of git breaks because libgcrypt requires > GCC 4.7 port, which doesn't build on ARM. Is it possible to build libgcrypt with clang? > > >> 3. As a guideline, if using external disk >> for building ports (e.g. usb flash media, >> usb hard disk, usb SSD) is the I/O speed >> important? Or is the bottleneck the processor speed? > > My impression is that I/O is the major problem. > Especially for larger packages where the compiler > can end up swapping. > >> 4. Of the three external media: (1) usb flash >> drive, (2) usb hard (moving parts) disk, >> (3) usb SSD, which is faster in broad terms. >> I understand YMMV. > > I haven't experimented with different USB drives. > >> 5. The default RPI-B kernel is very lean: >> http://svnweb.freebsd.org/base/head/sys/arm/conf/RPI-B?view=markup >> >> Still there are things which (I think) >> I don't need, e.g. USB ethernet. >> Will I gain anything by removing USB ethernet >> from the kernel? > > The on-board Ethernet for RPi is actually connected > through USB. If you remove USB Ethernet, you have > removed Ethernet. > > Removing what you don't need will free up more RAM, > which is always good. > > Cheers, > > 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 Fri Jul 4 19:55:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F7A17AB for ; Fri, 4 Jul 2014 19:55:51 +0000 (UTC) Received: from eu1sys200aog129.obsmtp.com (eu1sys200aog129.obsmtp.com [207.126.144.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2F4A2C31 for ; Fri, 4 Jul 2014 19:55:50 +0000 (UTC) Received: from mail-wi0-f182.google.com ([209.85.212.182]) (using TLSv1) by eu1sys200aob129.postini.com ([207.126.147.11]) with SMTP ID DSNKU7cGpvoipMUq42FesvX/cx4c5FABNLC8@postini.com; Fri, 04 Jul 2014 19:55:51 UTC Received: by mail-wi0-f182.google.com with SMTP id bs8so4212694wib.15 for ; Fri, 04 Jul 2014 12:55:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=44sp1al/ktiPZac0831g8NFJdx/7f4Jp/y55673aR88=; b=JnOwesNlQUgdD1YDfgV6w9u+B+T09/9ir4/dopIojawH8Pk0fAdMuembjIzLH+Oviz /MyIECnpUcRGWso8x8bsMrAIL+R3HdR3/BWaCdL40Pb2z7taY9N8Z8RhREFCKhsi2mGB T3Tt6QcLtpIzHY3v8GxNZDEIxOGb8jpdVfjMUGmX1bFCibus7qGBKG3Hd2RPIt8dj6Tg /SxAJ59u9Tf4rBq/iUkLZy/MlSnT9EodjD/z6p1p7E6Z5b6SOmN95gFi7aVnpNqP4u5i rHzOll0Pb9rPiFvsmn13+onJZfx6g6EIsObK+LGgQx/24XnMOi1mT1A5IySIlAVPWMe0 0f5g== X-Gm-Message-State: ALoCoQkUtQ9tPi3vZW4c/T1NWjJMivaptJxYyR2kLm7mHQ+Y4pDCflDro/7NPuSW+4XNGcgKX0bX+j4DWWQLWIht6fcDhTCnV69gAskOG7LN/BAhypLNExaTjLst4sSNw25tJx+wRzYk X-Received: by 10.180.205.138 with SMTP id lg10mr19528255wic.49.1404503718559; Fri, 04 Jul 2014 12:55:18 -0700 (PDT) X-Received: by 10.180.205.138 with SMTP id lg10mr19528244wic.49.1404503718289; Fri, 04 Jul 2014 12:55:18 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id u10sm82661689wix.11.2014.07.04.12.55.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jul 2014 12:55:17 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s64JtGNU032933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Jul 2014 20:55:16 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s64JtGD4032932; Fri, 4 Jul 2014 20:55:16 +0100 (BST) (envelope-from mexas) Date: Fri, 4 Jul 2014 20:55:16 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407041955.s64JtGD4032932@mech-cluster241.men.bris.ac.uk> To: nwhitehorn@freebsd.org, tom@khubla.com Subject: Re: official packages for arm? Reply-To: mexas@bris.ac.uk In-Reply-To: <53B6F24A.2070703@freebsd.org> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 19:55:51 -0000 >There are no longer any packages for any non-x86 architecture as a >result of the security breach last year. There are basically three >reasons for this: >1. The old package build infrastructure got abandoned. Please give more details on this. I follow quite a few freebsd lists but don't remember seeing an explanation. My feeling was that when linimon@ stepped down as... well whatever official role he had in the portscluster, things stopped. But there is probably more to it. >and if ARM hardware appeared in the cluster, it would be easy to set >that up tomorrow. From the OS development side, native builds are nice I'm happy to contribute a new RPI-B, or make an equivalent monetary contribution, about 25 UK pounds. Anton From owner-freebsd-arm@FreeBSD.ORG Sat Jul 5 18:35:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EC16D9D for ; Sat, 5 Jul 2014 18:35:09 +0000 (UTC) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467C521A9 for ; Sat, 5 Jul 2014 18:35:09 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id uy5so2952304obc.3 for ; Sat, 05 Jul 2014 11:35:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=myOj3HgwUr7GBz57QXhJr/amN9COUNB87JV8n3/RWhQ=; b=hgvDFw5scD9SI2clfyBSKW2ok6h91mJzwrwPkaaqxz9rQKH6ycCWOXWuKw/qAqj8vh mmSavTiDgNMCBuRNrC6g2jxXDgxu4h/G/9zrdXBJYm9/XuYZ83wZxu8GkUep5/M//ALC 3egjgeUQ+R/nfZzqmyEIzcLfPJZ8eX0TAQ2feKCdTenuHoe82YRH+6O1K0y65w1qmLDT 2vruS5DIAph7UXcJjb2WuhjnFaApuENyh1dmDi5/3gUJo/cGY9RLnxgR7GdW8rGsJoCF pMeRUg/G+dnCYpAMgE2GGrsqiL1XDVlznVehXdHIPG5gYZCpYAcTB5TYW7irEYRmM06w /B0g== X-Gm-Message-State: ALoCoQlCI9vrqjQBMy+I9miP03bSwwxmM8oNfsVg4d8VcAdJZbJimwvo3PtWnD2JPPDeYHhSpLeJ MIME-Version: 1.0 X-Received: by 10.182.22.111 with SMTP id c15mr20495729obf.32.1404585301895; Sat, 05 Jul 2014 11:35:01 -0700 (PDT) Received: by 10.182.96.101 with HTTP; Sat, 5 Jul 2014 11:35:01 -0700 (PDT) In-Reply-To: <1404326769.20883.396.camel@revolution.hippie.lan> References: <1404326769.20883.396.camel@revolution.hippie.lan> Date: Sat, 5 Jul 2014 12:35:01 -0600 Message-ID: Subject: Re: Status of iic on wandboard From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 18:35:09 -0000 ok, so I enabled iic and iicbus in the IMX6 kernel config. I also added this to imx6.dtsi (below). i2c@021a0000 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,imx-i2c"; reg = <0x021a0000 0x4000>; interrupt-parent = <&gic>; interrupts = <68>; }; i2c@021a4000 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,imx-i2c"; reg = <0x021a4000 0x4000>; interrupt-parent = <&gic>; interrupts = <69>; }; i2c@021a8000 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,imx-i2c"; reg = <0x021a8000 0x4000>; interrupt-parent = <&gic>; interrupts = <70>; }; kldstat shows that the modules are there: $ kldstat -v | grep iic 13 iichb/iicbus 12 iicbus/iic 55 iichb/ofw_iicbus 54 iicbb/ofw_iicbus and opfwdump shows that the DTS data is there: root@wandboard:/dev # ofwdump -a Node 0x38: Node 0xa8: cpus Node 0xd4: cpu@0 Node 0x190: aliases Node 0x1bc: soc@00000000 Node 0x230: generic-interrupt-controller@00a00100 Node 0x2cc: mp_tmr0@00a00200 Node 0x348: l2-cache@00a02000 Node 0x3d0: aips@02000000 Node 0x458: ccm@020c4000 Node 0x4b4: anatop@020c8000 Node 0x520: timer@02098000 Node 0x594: gpio@0209c000 Node 0x668: gpio@020a0000 Node 0x71c: gpio@020a4000 Node 0x7f0: gpio@020a8000 Node 0x8a4: gpio@020ac000 Node 0x958: gpio@020b0000 Node 0xa0c: gpio@020b4000 Node 0xac0: serial@02020000 Node 0xb4c: serial@021e8000 Node 0xbdc: serial@021ec000 Node 0xc6c: serial@021f0000 Node 0xcfc: serial@021f4000 Node 0xd8c: usbphy@020c9000 Node 0xe2c: usbphy@020ca000 Node 0xed0: aips@02100000 Node 0xf58: ethernet@02188000 Node 0xfec: usb@02184000 Node 0x1088: usb@02184200 Node 0x1124: usb@02184400 Node 0x11b4: usb@02184600 Node 0x1244: usbmisc@02184800 Node 0x12c4: usdhc@02190000 Node 0x1368: usdhc@02194000 Node 0x1404: usdhc@02198000 Node 0x14a8: usdhc@0219c000 Node 0x1538: i2c@021a0000 Node 0x15d0: i2c@021a4000 Node 0x1668: i2c@021a8000 Node 0x1700: ocotp@021bc000 Node 0x1750: memory Node 0x1774: chosen However, the device is not detected on boot. Where do I look next? On Wed, Jul 2, 2014 at 12:46 PM, Ian Lepore wrote: > On Sun, 2014-06-29 at 18:47 -0600, Tom Everett wrote: > > I see that there is an i2c driver for imx on the source tree, and there > are > > iic kernel options in /conf/IMX6, commented out. Does anyone know the > > status of i2c for IMX? > > > > > > It works. I used it to write values to an i2c eeprom and read them back > a few weeks ago. I haven't tested any other devices yet. > > -- Ian > > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sun Jul 6 02:01:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4353937B for ; Sun, 6 Jul 2014 02:01:49 +0000 (UTC) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00078243B for ; Sun, 6 Jul 2014 02:01:48 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id j17so3049077oag.25 for ; Sat, 05 Jul 2014 19:01:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=euNZVdGEA8ksltTsViF7RqZeVx6ixs4VbwtHKDulPNs=; b=Yaf9cYhE+96XujYRLZFxzNGw5b2xlBeLfdz9cxvXRFivVfPUGuAwTmfFItUbvGWiq2 75pCZPpG60ArpqT6k7y7J9zMmzTdbSuz/laG5+zoqbmz2veH1wXoTyM2atJQxSlk4Ee9 L0dKiCTQ/m6eltafHAF7uussflgypukIqWDG/SeQLH9MX8cszdWu75sPXTs5cQ3+kvmS 7jyduIJi24mKaPa9DRGnpNDhO5FjW1YBoBwiRJ+j8AV3PteTTNJRPEU4orzmGbLn2omX 7gBqYnMdl4lFKqIwxH0p5yCjZTHN3UqsQkHo5SQW2UCGRiMsqBVVNUGz9AcQbalI/vpW scfg== X-Gm-Message-State: ALoCoQkqjay7ojnhA/rKnEu6uYM18MZN0lsBLlKXKu08ma+fl1EKmISGg9/nmSYS3Z4Vx1uUTbnH MIME-Version: 1.0 X-Received: by 10.182.3.10 with SMTP id 10mr21943917oby.22.1404612102481; Sat, 05 Jul 2014 19:01:42 -0700 (PDT) Received: by 10.182.96.101 with HTTP; Sat, 5 Jul 2014 19:01:42 -0700 (PDT) In-Reply-To: References: <1404326769.20883.396.camel@revolution.hippie.lan> Date: Sat, 5 Jul 2014 20:01:42 -0600 Message-ID: Subject: Re: Status of iic on wandboard From: Tom Everett To: Ian Lepore Content-Type: multipart/mixed; boundary=001a113487746a949d04fd7cbd86 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 02:01:49 -0000 --001a113487746a949d04fd7cbd86 Content-Type: text/plain; charset=UTF-8 After some help from Ian on IRC, I have a working kernel here , and a bootlog here . I've attached some patch files. On Sat, Jul 5, 2014 at 12:35 PM, Tom Everett wrote: > ok, so I enabled iic and iicbus in the IMX6 kernel config. I also added > this to imx6.dtsi (below). > > i2c@021a0000 { > > #address-cells = <1>; > > #size-cells = <0>; > > compatible = "fsl,imx-i2c"; > > reg = <0x021a0000 0x4000>; > > interrupt-parent = <&gic>; interrupts = > <68>; > > }; > > > i2c@021a4000 { > > #address-cells = <1>; > > #size-cells = <0>; > > compatible = "fsl,imx-i2c"; > > reg = <0x021a4000 0x4000>; > > interrupt-parent = <&gic>; interrupts = > <69>; > > }; > > > i2c@021a8000 { > > #address-cells = <1>; > > #size-cells = <0>; > > compatible = "fsl,imx-i2c"; > > reg = <0x021a8000 0x4000>; > > interrupt-parent = <&gic>; interrupts = > <70>; > > }; > > kldstat shows that the modules are there: > > > $ kldstat -v | grep iic > > 13 iichb/iicbus > > 12 iicbus/iic > > 55 iichb/ofw_iicbus > > 54 iicbb/ofw_iicbus > > > and opfwdump shows that the DTS data is there: > > root@wandboard:/dev # ofwdump -a > > Node 0x38: > > Node 0xa8: cpus > > Node 0xd4: cpu@0 > > Node 0x190: aliases > > Node 0x1bc: soc@00000000 > > Node 0x230: generic-interrupt-controller@00a00100 > > Node 0x2cc: mp_tmr0@00a00200 > > Node 0x348: l2-cache@00a02000 > > Node 0x3d0: aips@02000000 > > Node 0x458: ccm@020c4000 > > Node 0x4b4: anatop@020c8000 > > Node 0x520: timer@02098000 > > Node 0x594: gpio@0209c000 > > Node 0x668: gpio@020a0000 > > Node 0x71c: gpio@020a4000 > > Node 0x7f0: gpio@020a8000 > > Node 0x8a4: gpio@020ac000 > > Node 0x958: gpio@020b0000 > > Node 0xa0c: gpio@020b4000 > > Node 0xac0: serial@02020000 > > Node 0xb4c: serial@021e8000 > > Node 0xbdc: serial@021ec000 > > Node 0xc6c: serial@021f0000 > > Node 0xcfc: serial@021f4000 > > Node 0xd8c: usbphy@020c9000 > > Node 0xe2c: usbphy@020ca000 > > Node 0xed0: aips@02100000 > > Node 0xf58: ethernet@02188000 > > Node 0xfec: usb@02184000 > > Node 0x1088: usb@02184200 > > Node 0x1124: usb@02184400 > > Node 0x11b4: usb@02184600 > > Node 0x1244: usbmisc@02184800 > > Node 0x12c4: usdhc@02190000 > > Node 0x1368: usdhc@02194000 > > Node 0x1404: usdhc@02198000 > > Node 0x14a8: usdhc@0219c000 > > Node 0x1538: i2c@021a0000 > > Node 0x15d0: i2c@021a4000 > > Node 0x1668: i2c@021a8000 > > Node 0x1700: ocotp@021bc000 > > Node 0x1750: memory > > Node 0x1774: chosen > > > However, the device is not detected on boot. Where do I look next? > > > > > > > On Wed, Jul 2, 2014 at 12:46 PM, Ian Lepore wrote: > >> On Sun, 2014-06-29 at 18:47 -0600, Tom Everett wrote: >> > I see that there is an i2c driver for imx on the source tree, and there >> are >> > iic kernel options in /conf/IMX6, commented out. Does anyone know the >> > status of i2c for IMX? >> > >> > >> >> It works. I used it to write values to an i2c eeprom and read them back >> a few weeks ago. I haven't tested any other devices yet. >> >> -- Ian >> >> >> > > > -- > A better world shall emerge based on faith and understanding - Douglas > MacArthur > -- A better world shall emerge based on faith and understanding - Douglas MacArthur --001a113487746a949d04fd7cbd86 Content-Type: text/plain; charset=US-ASCII; name="files.imx6.diff" Content-Disposition: attachment; filename="files.imx6.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hx9pqetr0 LS0tIDExL2hlYWQvc3lzL2FybS9mcmVlc2NhbGUvaW14L2ZpbGVzLmlteDYJMjAxNC0wNy0wNSAx OTo1MTozMi40ODMxODM1MzYgLTA2MDAKKysrIEZyZWVCU0RIZWFkL2hlYWQvc3lzL2FybS9mcmVl c2NhbGUvaW14L2ZpbGVzLmlteDYJMjAxNC0wNy0wNSAxNzoxMjowNS4xODM4Njc2NDkgLTA2MDAK QEAgLTUyLDYgKzUyLDYgQEAKICNhcm0vZnJlZXNjYWxlL2lteC9pbXg1MV9pb211eC5jICAJb3B0 aW9uYWwgaW9tdXgKICNhcm0vZnJlZXNjYWxlL2lteC9pbXg1MV9ncGlvLmMgIAlvcHRpb25hbCBn cGlvCiAjZGV2L2F0YS9jaGlwc2V0cy9hdGEtZnNsLmMgIAkJb3B0aW9uYWwgaW14YXRhCi0jYXJt L2ZyZWVzY2FsZS9pbXgvaTJjLmMgIAkJb3B0aW9uYWwgZnNsaWljCithcm0vZnJlZXNjYWxlL2lt eC9pMmMuYyAgCQlvcHRpb25hbCBmc2xpaWMKICNhcm0vZnJlZXNjYWxlL2lteC9pbXg1MV9pcHV2 My5jICAJb3B0aW9uYWwgc2MKIAo= --001a113487746a949d04fd7cbd86 Content-Type: text/plain; charset=US-ASCII; name="IMX6.diff" Content-Disposition: attachment; filename="IMX6.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hx9pqeu01 LS0tIDExL2hlYWQvc3lzL2FybS9jb25mL0lNWDYJMjAxNC0wNy0wNSAxOTo1MTozMi4yNzMxODk5 ODUgLTA2MDAKKysrIEZyZWVCU0RIZWFkL2hlYWQvc3lzL2FybS9jb25mL0lNWDYJMjAxNC0wNy0w NSAxNzoxMDozOS4wOTg4NjA1NjQgLTA2MDAKQEAgLTE1MSw4ICsxNTEsOCBAQAogCiAjIFNvQy1z cGVjaWZpYyBkZXZpY2VzCiBkZXZpY2UgIAlmZmVjCQkJIyBGcmVlc2NhbGUgRmFzdCBFdGhlcm5l dCBDb250cm9sbGVyCi0jZGV2aWNlICAJZnNsaWljCQkJIyBGcmVlc2NhbGUgaTJjL2lpYyAobm90 IHJlYWR5IHlldCkKLSNkZXZpY2UgIAlpaWMJCQkjIGlpYyBwcm90b2NvbAotI2RldmljZSAgCWlp Y2J1cwkJCSMgaWljIGJ1cworZGV2aWNlICAJZnNsaWljCQkJIyBGcmVlc2NhbGUgaTJjL2lpYyAo bm90IHJlYWR5IHlldCkKK2RldmljZSAgCWlpYwkJCSMgaWljIHByb3RvY29sCitkZXZpY2UgIAlp aWNidXMJCQkjIGlpYyBidXMKICNkZXZpY2UgIAlpbXh3ZHQJCQkjIFdhdGNoZG9nLiBXQVJOSU5H OiBjYW4ndCBiZSBkaXNhYmxlZCEhIQogCg== --001a113487746a949d04fd7cbd86 Content-Type: text/plain; charset=US-ASCII; name="imx6.dtsi.diff" Content-Disposition: attachment; filename="imx6.dtsi.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hx9pqeu22 LS0tIDExL2hlYWQvc3lzL2Jvb3QvZmR0L2R0cy9hcm0vaW14Ni5kdHNpCTIwMTQtMDctMDUgMTk6 NTE6MjQuNTE5MTkxODE5IC0wNjAwCisrKyBGcmVlQlNESGVhZC9oZWFkL3N5cy9ib290L2ZkdC9k dHMvYXJtL2lteDYuZHRzaQkyMDE0LTA3LTA0IDE3OjA1OjQwLjI1NzgzMTM5OCAtMDYwMApAQCAt MzQ4LDYgKzM0OCwzMCBAQAogCQkJCXN0YXR1cyA9ImRpc2FibGVkIjsKIAkJCX07CiAKKwkJCWky Y0AwMjFhMDAwMCB7CisJCQkJI2FkZHJlc3MtY2VsbHMgPSA8MT47CisJCQkJI3NpemUtY2VsbHMg PSA8MD47CisJCQkJY29tcGF0aWJsZSA9ICJmc2wsaW14LWkyYyI7CisJCQkJcmVnID0gPDB4MDIx YTAwMDAgMHg0MDAwPjsKKwkJCQlpbnRlcnJ1cHQtcGFyZW50ID0gPCZnaWM+OyBpbnRlcnJ1cHRz ID0gPDY4PjsKKwkJCX07CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGkyY0AwMjFhNDAwMCB7 CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gPDE+Owor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwwPjsKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJmc2wsaW14LWkyYyI7Cisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDAyMWE0MDAwIDB4NDAwMD47 CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycnVwdC1wYXJlbnQgPSA8Jmdp Yz47IGludGVycnVwdHMgPSA8Njk+OworICAgICAgICAgICAgICAgICAgICAgICAgfTsKKworICAg ICAgICAgICAgICAgICAgICAgICAgaTJjQDAyMWE4MDAwIHsKKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8MT47CisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICNzaXplLWNlbGxzID0gPDA+OworICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBjb21wYXRpYmxlID0gImZzbCxpbXgtaTJjIjsKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgcmVnID0gPDB4MDIxYTgwMDAgMHg0MDAwPjsKKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaW50ZXJydXB0LXBhcmVudCA9IDwmZ2ljPjsgaW50ZXJydXB0cyA9IDw3MD47 CisgICAgICAgICAgICAgICAgICAgICAgICB9OworCiAJCQlvY290cDA6IG9jb3RwQDAyMWJjMDAw IHsKIAkJCQljb21wYXRpYmxlID0gImZzbCxpbXg2cS1vY290cCI7CiAJCQkJcmVnID0gPDB4MDIx YmMwMDAgMHg0MDAwPjsK --001a113487746a949d04fd7cbd86 Content-Type: text/plain; charset=US-ASCII; name="wandboard-quad.dts.diff" Content-Disposition: attachment; filename="wandboard-quad.dts.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hx9pqeu43 LS0tIDExL2hlYWQvc3lzL2Jvb3QvZmR0L2R0cy9hcm0vd2FuZGJvYXJkLXF1YWQuZHRzCTIwMTQt MDctMDUgMTk6NTE6MjQuNTM0MTg0MDYwIC0wNjAwCisrKyBGcmVlQlNESGVhZC9oZWFkL3N5cy9i b290L2ZkdC9kdHMvYXJtL3dhbmRib2FyZC1xdWFkLmR0cwkyMDE0LTA3LTA0IDE5OjU1OjQ4LjU2 OTEyOTIwMiAtMDYwMApAQCAtNzEsNiArNzEsOSBAQAogCQkJdXNkaGNAMDIxOTQwMDAJCXsgc3Rh dHVzID0gImRpc2FibGVkIjsgfTsKIAkJCXVzZGhjQDAyMTk4MDAwCQl7IHN0YXR1cyA9ICJva2F5 IjsgfTsKIAkJCXVzZGhjQDAyMTljMDAwCQl7IHN0YXR1cyA9ICJkaXNhYmxlZCI7IH07CisgICAg ICAgICAgICAgICAgICAgICAgICBpMmNAMDIxYTAwMDAgICAgICAgICAgICB7IHN0YXR1cyA9ICJv a2F5IjsgfTsJCQorICAgICAgICAgICAgICAgICAgICAgICAgaTJjQDAyMWE0MDAwICAgICAgICAg ICAgeyBzdGF0dXMgPSAib2theSI7IH07CisJCQlpMmNAMDIxYTgwMDAgICAgICAgICAgICB7IHN0 YXR1cyA9ICJva2F5IjsgfTsKIAkJfTsKIAl9OwogCg== --001a113487746a949d04fd7cbd86-- From owner-freebsd-arm@FreeBSD.ORG Sun Jul 6 17:37:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44F85529 for ; Sun, 6 Jul 2014 17:37:27 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A28524B3 for ; Sun, 6 Jul 2014 17:37:26 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id rd18so2908462iec.17 for ; Sun, 06 Jul 2014 10:37:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=h+qBi496LMh3Wi1jEzke3lta44P0FE1iAf0i65MSJLE=; b=aNsMtzYm/f2+Lr9TEMoQ8c0IBSaQL+fTm9+ovHYkZl6ppjV+xqmpBZpOEK16KOmNKf vVBNyXQUutvcsCB4U31emB8OFC5IUoRBs6ebRm15DsP0SkHwku3JTvUu5DLgaFTyItD/ 8AlibxJVNF23geeK9zZqRgmd7IVUsXzyHMnLxSohRQxFIoI88nbgvaG/CYN4lr/2d+As ls0CNH4qCp0/Sn51pE/neFYyLwFhASkL4mu7DxGlXlvutTQRiC/FC629xRrU5hQGxQd7 /cYb+Fsqh8+qHpKosIp8yUFPwJY6b4pVYpU3bO9fGUmOz6m9vX6LET3MrgO1tOwCElD1 o4Cg== X-Gm-Message-State: ALoCoQlEnNzrdg5gOJk82zPWTkK3yNo/u6/GL4OGil27bYDAXOa+AF0QziE2kvlYJDKzWFtPUwKN X-Received: by 10.42.39.199 with SMTP id i7mr28129075ice.23.1404668239835; Sun, 06 Jul 2014 10:37:19 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id l9sm18587677ige.2.2014.07.06.10.37.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Jul 2014 10:37:18 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_A5CBFFA3-D08B-45F7-B587-49F92049CB87"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: official packages for arm? From: Warner Losh In-Reply-To: Date: Sun, 6 Jul 2014 11:37:16 -0600 Message-Id: <556332C8-9EE8-4B94-829B-9D3A6DCC7FC8@bsdimp.com> References: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> To: Tim Kientzle X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 17:37:27 -0000 --Apple-Mail=_A5CBFFA3-D08B-45F7-B587-49F92049CB87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 4, 2014, at 12:39 PM, Tim Kientzle wrote: >=20 > On Jul 4, 2014, at 3:25 AM, Anton Shterenlikht = wrote: >=20 >> Few silly questions, please don't shoot. >>=20 >> 1. Why are there no official arm packages? >=20 > Nathan answered this pretty completely, I think. >=20 >> 2. Are there any specific arm considerations when >> building ports? To do with build time? To do with >> processor capabilities? >=20 > Biggest issue is simply that key ports still > don't build on ARM. For example, a default > build of git breaks because libgcrypt requires > GCC 4.7 port, which doesn't build on ARM. I have forward ports of our patches that could help this. >> 3. As a guideline, if using external disk >> for building ports (e.g. usb flash media, >> usb hard disk, usb SSD) is the I/O speed >> important? Or is the bottleneck the processor speed? >=20 > My impression is that I/O is the major problem. > Especially for larger packages where the compiler > can end up swapping. Yes. Why not do the qemu user mode emulation route that we do for mips? >> 4. Of the three external media: (1) usb flash >> drive, (2) usb hard (moving parts) disk, >> (3) usb SSD, which is faster in broad terms. >> I understand YMMV. >=20 > I haven't experimented with different USB drives. >=20 >> 5. The default RPI-B kernel is very lean: >> http://svnweb.freebsd.org/base/head/sys/arm/conf/RPI-B?view=3Dmarkup >>=20 >> Still there are things which (I think) >> I don't need, e.g. USB ethernet. >> Will I gain anything by removing USB ethernet >> from the kernel? >=20 > The on-board Ethernet for RPi is actually connected > through USB. If you remove USB Ethernet, you have > removed Ethernet. >=20 > Removing what you don't need will free up more RAM, > which is always good. Short of a dedicated building cluster of about 30 ARM machines, doing a = full package build on ARM within a few days is a pipe-dream. We might be = able to get it under a week with qemu. Warner --Apple-Mail=_A5CBFFA3-D08B-45F7-B587-49F92049CB87 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTuYlMAAoJEGwc0Sh9sBEAN2cQAINiNQ3zwW+Ofl6x4Q4aJwRq gBKdYehHWbRDCb3hcBen1yTv2McxZU0HWBFx5chQQ0X3fzpiAny71zyyOklTSRyW Lq+WsrYIjDekc38sRK/Zu2iSeBPYzN5YBxy02/2YYRNpCVweXO3IO7FAPxnHntqh y+DICue/Tl5TIiobaNE/ZYNAPwhfGn0wYzZw/J6Jn5Xo8bsIeu55Ncy1jgy5nxU/ NY1eouH7NDrjFaL4YtTFJ9THNPJ+bn3MVyqE9KO+z3nUISfw0oAfnz16WGNfa/PG 7g8NFo5Ehtpmp3r84LOPgwqD5uhbI5DWbNE3LJ1d71gqdvpxXMlVfHaCnQJAJjZi nD1LYJbgJtueWrI6eQnBWOpPlFEu+RCv6UHDxxz6ES7Z4C58BSJyYdeow/5KmhPp 6RwEggCQ9+0+4YUoNLLAr3gL+fzw4dKWG4Uvf5oHxR2eubuiXzSFydEwdNLZQ9Il OSccAOCY4QdBagKTDm7VjZZQoj0/DiZjPciKsiEnOIB4DCAToiSHy+sJIj/9VjZ+ nOsNGAb4rvlqLOwDJtTYDRusUfX0pnRsW96OKmarsEcCoEphIUK2n+JUScNrSPo7 x2m9k0BO/hs9XIDXFL1SVGXymTL7e94D9WNGc3Y43laEwOU6GdUoMkGPNLUw9Rus Y1xnMQa5zcY7mTO+vIw1 =5UJp -----END PGP SIGNATURE----- --Apple-Mail=_A5CBFFA3-D08B-45F7-B587-49F92049CB87-- From owner-freebsd-arm@FreeBSD.ORG Sun Jul 6 18:39:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61B48A49 for ; Sun, 6 Jul 2014 18:39:51 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23D6F293B for ; Sun, 6 Jul 2014 18:39:50 +0000 (UTC) Received: from [192.168.1.200] (p54819DC9.dip0.t-ipconnect.de [84.129.157.201]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B752D1C104DA8; Sun, 6 Jul 2014 20:39:46 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: official packages for arm? From: Michael Tuexen In-Reply-To: <556332C8-9EE8-4B94-829B-9D3A6DCC7FC8@bsdimp.com> Date: Sun, 6 Jul 2014 20:39:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2BA5E26E-4D82-488A-A1FE-8FD8F6C46024@fh-muenster.de> References: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> <556332C8-9EE8-4B94-829B-9D3A6DCC7FC8@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1878.6) Cc: Tim Kientzle , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 18:39:51 -0000 On 06 Jul 2014, at 19:37, Warner Losh wrote: >=20 > On Jul 4, 2014, at 12:39 PM, Tim Kientzle wrote: >=20 >>=20 >> On Jul 4, 2014, at 3:25 AM, Anton Shterenlikht = wrote: >>=20 >>> Few silly questions, please don't shoot. >>>=20 >>> 1. Why are there no official arm packages? >>=20 >> Nathan answered this pretty completely, I think. >>=20 >>> 2. Are there any specific arm considerations when >>> building ports? To do with build time? To do with >>> processor capabilities? >>=20 >> Biggest issue is simply that key ports still >> don't build on ARM. For example, a default >> build of git breaks because libgcrypt requires >> GCC 4.7 port, which doesn't build on ARM. I just tested this. libgcrypt builds on a RPi using clang. Best regards Michael >=20 > I have forward ports of our patches that could help this. >=20 >>> 3. As a guideline, if using external disk >>> for building ports (e.g. usb flash media, >>> usb hard disk, usb SSD) is the I/O speed >>> important? Or is the bottleneck the processor speed? >>=20 >> My impression is that I/O is the major problem. >> Especially for larger packages where the compiler >> can end up swapping. >=20 > Yes. Why not do the qemu user mode emulation route that we do for = mips? >=20 >>> 4. Of the three external media: (1) usb flash >>> drive, (2) usb hard (moving parts) disk, >>> (3) usb SSD, which is faster in broad terms. >>> I understand YMMV. >>=20 >> I haven't experimented with different USB drives. >>=20 >>> 5. The default RPI-B kernel is very lean: >>> http://svnweb.freebsd.org/base/head/sys/arm/conf/RPI-B?view=3Dmarkup >>>=20 >>> Still there are things which (I think) >>> I don't need, e.g. USB ethernet. >>> Will I gain anything by removing USB ethernet >>> from the kernel? >>=20 >> The on-board Ethernet for RPi is actually connected >> through USB. If you remove USB Ethernet, you have >> removed Ethernet. >>=20 >> Removing what you don't need will free up more RAM, >> which is always good. >=20 > Short of a dedicated building cluster of about 30 ARM machines, doing = a full package build on ARM within a few days is a pipe-dream. We might = be able to get it under a week with qemu. >=20 > Warner >=20 From owner-freebsd-arm@FreeBSD.ORG Sun Jul 6 18:57:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C69C695 for ; Sun, 6 Jul 2014 18:57:34 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1C92B25 for ; Sun, 6 Jul 2014 18:57:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 3C31738060 for ; Sun, 6 Jul 2014 13:57:33 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id tSLMyVq5jlM1 for ; Sun, 6 Jul 2014 13:57:33 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id EC75338059 for ; Sun, 6 Jul 2014 13:57:32 -0500 (CDT) Message-ID: <53B99C1B.7000806@freebsd.org> Date: Sun, 06 Jul 2014 11:57:31 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: official packages for arm? References: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> <556332C8-9EE8-4B94-829B-9D3A6DCC7FC8@bsdimp.com> In-Reply-To: <556332C8-9EE8-4B94-829B-9D3A6DCC7FC8@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 18:57:34 -0000 On 07/06/14 10:37, Warner Losh wrote: > >>> 5. The default RPI-B kernel is very lean: >>> http://svnweb.freebsd.org/base/head/sys/arm/conf/RPI-B?view=markup >>> >>> Still there are things which (I think) >>> I don't need, e.g. USB ethernet. >>> Will I gain anything by removing USB ethernet >>> from the kernel? >> The on-board Ethernet for RPi is actually connected >> through USB. If you remove USB Ethernet, you have >> removed Ethernet. >> >> Removing what you don't need will free up more RAM, >> which is always good. > Short of a dedicated building cluster of about 30 ARM machines, doing a full package build on ARM within a few days is a pipe-dream. We might be able to get it under a week with qemu. > For sure. From the project perspective, though, I don't see a huge problem with it taking a few weeks on a handful of CPUs rather than a few days on 30. We've waited years for packages anyway. As a happy side-effect, we also get to stress-test the operating system. -Nathan From owner-freebsd-arm@FreeBSD.ORG Mon Jul 7 00:54:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1C062D0 for ; Mon, 7 Jul 2014 00:54:53 +0000 (UTC) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACB7E2721 for ; Mon, 7 Jul 2014 00:54:53 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id at1so3127709iec.35 for ; Sun, 06 Jul 2014 17:54:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E+ElKQP6mQO+Z/C/6PIZ4Jq6669+FEa9aXcReG7/HHw=; b=iD0xiDpwP3J4LgGQt9+IdNAViz+bgPeE8tp/fK619Vt3KMvxDZ+SsMYyaUhQoVFBjB xkjO3bisYnS36V1umg3U2w/i5HfYtaRodUTPWHwZ+AY4BGdoLuvCmhW7yOKHYNo3vKeu CWZH+XMazptqGI176zMxTkwA8ucbPlaxRaivOrVM32fHuIE9YzBqQbGFAWyBZNN6C58K N3x2CI/2hi6qPTewloj7fnTRXcGwQZLdLZwX3yqTYmlM9qppTYW0pkFpxCPq0w0v2qk/ 9JSUyNND85p+60MR9y/ATQUNY/Xo37hvVZ+4u2rNMCbXaZaySNalaW6RNpfxq9Ly/9uc hIUA== X-Gm-Message-State: ALoCoQlHusIAqCN5NvNDsBxp74bsCBkiJ6DDiUiOeNVAfIT4iEb/WvFEsez0oCjgi5hw+tkHWricDw36fbiVkTmDaTbRWxONdddLOxU7dF/oKKErRfV8P/M= X-Received: by 10.50.12.38 with SMTP id v6mr78265793igb.29.1404694021546; Sun, 06 Jul 2014 17:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.69.131 with HTTP; Sun, 6 Jul 2014 17:46:46 -0700 (PDT) In-Reply-To: <53B99C1B.7000806@freebsd.org> References: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> <556332C8-9EE8-4B94-829B-9D3A6DCC7FC8@bsdimp.com> <53B99C1B.7000806@freebsd.org> From: "Lundberg, Johannes" Date: Mon, 7 Jul 2014 09:46:46 +0900 Message-ID: Subject: Re: official packages for arm? To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 00:54:54 -0000 SXMgYnVpbGRpbmcgYSBzdWJzZXQgb2YgdGhlIHBhY2thZ2VzIGFuIG9wdGlvbj8gSSBtZWFuLCBt YXliZSBvbmx5IHRoZSB0b3ANCjEwJSBvZiBtb3N0IGZyZXF1ZW50IGluc3RhbGxlZCBwYWNrYWdl cyB3b3VsZCBjb3ZlciA5OSUgb2YgYWxsIHVzZSBjYXNlcw0KKG51bWJlcnMganVzdCBhIGd1ZXNz KS4uIFRoZSByZW1haW5pbmcgMSUgd291bGQgaGF2ZSB0byBidWlsZCBmcm9tIHBvcnRzDQp0aGVt c2VsdmVzLg0KDQotLQ0KSm9oYW5uZXMgTHVuZGJlcmcNCg0KDQpPbiBNb24sIEp1bCA3LCAyMDE0 IGF0IDM6NTcgQU0sIE5hdGhhbiBXaGl0ZWhvcm4gPG53aGl0ZWhvcm5AZnJlZWJzZC5vcmc+DQp3 cm90ZToNCg0KPiBPbiAwNy8wNi8xNCAxMDozNywgV2FybmVyIExvc2ggd3JvdGU6DQo+DQo+Pg0K Pj4gIDUuIFRoZSBkZWZhdWx0IFJQSS1CIGtlcm5lbCBpcyB2ZXJ5IGxlYW46DQo+Pj4+IGh0dHA6 Ly9zdm53ZWIuZnJlZWJzZC5vcmcvYmFzZS9oZWFkL3N5cy9hcm0vY29uZi9SUEktQj92aWV3PW1h cmt1cA0KPj4+Pg0KPj4+PiBTdGlsbCB0aGVyZSBhcmUgdGhpbmdzIHdoaWNoIChJIHRoaW5rKQ0K Pj4+PiBJIGRvbid0IG5lZWQsIGUuZy4gVVNCIGV0aGVybmV0Lg0KPj4+PiBXaWxsIEkgZ2FpbiBh bnl0aGluZyBieSByZW1vdmluZyBVU0IgZXRoZXJuZXQNCj4+Pj4gZnJvbSB0aGUga2VybmVsPw0K Pj4+Pg0KPj4+IFRoZSBvbi1ib2FyZCBFdGhlcm5ldCBmb3IgUlBpIGlzIGFjdHVhbGx5IGNvbm5l Y3RlZA0KPj4+IHRocm91Z2ggVVNCLiAgSWYgeW91IHJlbW92ZSBVU0IgRXRoZXJuZXQsIHlvdSBo YXZlDQo+Pj4gcmVtb3ZlZCBFdGhlcm5ldC4NCj4+Pg0KPj4+IFJlbW92aW5nIHdoYXQgeW91IGRv bid0IG5lZWQgd2lsbCBmcmVlIHVwIG1vcmUgUkFNLA0KPj4+IHdoaWNoIGlzIGFsd2F5cyBnb29k Lg0KPj4+DQo+PiBTaG9ydCBvZiBhIGRlZGljYXRlZCBidWlsZGluZyBjbHVzdGVyIG9mIGFib3V0 IDMwIEFSTSBtYWNoaW5lcywgZG9pbmcgYQ0KPj4gZnVsbCBwYWNrYWdlIGJ1aWxkIG9uIEFSTSB3 aXRoaW4gYSBmZXcgZGF5cyBpcyBhIHBpcGUtZHJlYW0uIFdlIG1pZ2h0IGJlDQo+PiBhYmxlIHRv IGdldCBpdCB1bmRlciBhIHdlZWsgd2l0aCBxZW11Lg0KPj4NCj4+DQo+IEZvciBzdXJlLiBGcm9t IHRoZSBwcm9qZWN0IHBlcnNwZWN0aXZlLCB0aG91Z2gsIEkgZG9uJ3Qgc2VlIGEgaHVnZSBwcm9i bGVtDQo+IHdpdGggaXQgdGFraW5nIGEgZmV3IHdlZWtzIG9uIGEgaGFuZGZ1bCBvZiBDUFVzIHJh dGhlciB0aGFuIGEgZmV3IGRheXMgb24NCj4gMzAuIFdlJ3ZlIHdhaXRlZCB5ZWFycyBmb3IgcGFj a2FnZXMgYW55d2F5LiBBcyBhIGhhcHB5IHNpZGUtZWZmZWN0LCB3ZSBhbHNvDQo+IGdldCB0byBz dHJlc3MtdGVzdCB0aGUgb3BlcmF0aW5nIHN5c3RlbS4NCj4gLU5hdGhhbg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmcmVlYnNkLWFybUBm cmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxt YW4vbGlzdGluZm8vZnJlZWJzZC1hcm0NCj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwg dG8gImZyZWVic2QtYXJtLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0KPg0KCi0tIAo9LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS0K56eY5a+G5L+d 5oyB44Gr44Gk44GE44Gm77ya44GT44Gu6Zu75a2Q44Oh44O844Or44Gv44CB5ZCN5a6b5Lq644Gr 6YCB5L+h44GX44Gf44KC44Gu44Gn44GC44KK44CB56eY5Yy/54m55qip44Gu5a++6LGh44Go44Gq 44KL5oOF5aCx44KS5ZCr44KT44Gn44GE44G+44GZ44CCCuOCguOBl+OAgeWQjeWum+S6uuS7peWk luOBruaWueOBjOWPl+S/oeOBleOCjOOBn+WgtOWQiOOAgeOBk+OBruODoeODvOODq+OBruegtOaj hOOAgeOBiuOCiOOBs+OBk+OBruODoeODvOODq+OBq+mWouOBmeOCi+S4gOWIh+OBrumWi+ekuuOA gQropIflhpnjgIHphY3luIPjgIHjgZ3jga7ku5bjga7liKnnlKjjgIHjgb7jgZ/jga/oqJjovInl hoXlrrnjgavln7rjgaXjgY/jgYTjgYvjgarjgovooYzli5XjgoLjgZXjgozjgarjgYTjgojjgYbj gYrpoZjjgYTnlLPjgZfkuIrjgZLjgb7jgZnjgIIKLS0tCkNPTkZJREVOVElBTElUWSBOT1RFOiBU aGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpcyBjb25maWRlbnRpYWwKYW5kIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZS4KRGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0 aW9uIG9yIGFueSBvdGhlciBhY3Rpb24gb2YgdXNlIG9mIHRoaXMKZW1haWwgYnkgcGVyc29uIG90 aGVyIHRoYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBpcyBwcm9oaWJpdGVkLgpJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFuZCBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4K ZXJyb3IsIHBsZWFzZSBkZXN0cm95IHRoZSBvcmlnaW5hbCBtZXNzYWdlLgo= From owner-freebsd-arm@FreeBSD.ORG Mon Jul 7 00:58:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2095431A for ; Mon, 7 Jul 2014 00:58:04 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id CFDA22731 for ; Mon, 7 Jul 2014 00:58:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 7D1C338064; Sun, 6 Jul 2014 19:58:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 2gBycPC8adZV; Sun, 6 Jul 2014 19:58:03 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id EEA5138061; Sun, 6 Jul 2014 19:58:02 -0500 (CDT) Message-ID: <53B9F099.4090307@freebsd.org> Date: Sun, 06 Jul 2014 17:58:01 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Lundberg, Johannes" Subject: Re: official packages for arm? References: <201407041025.s64APml0031649@mech-cluster241.men.bris.ac.uk> <556332C8-9EE8-4B94-829B-9D3A6DCC7FC8@bsdimp.com> <53B99C1B.7000806@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 00:58:04 -0000 Also something that could be done. -Nathan On 07/06/14 17:46, Lundberg, Johannes wrote: > Is building a subset of the packages an option? I mean, maybe only the > top 10% of most frequent installed packages would cover 99% of all use > cases (numbers just a guess).. The remaining 1% would have to build > from ports themselves. > > -- > Johannes Lundberg > > > On Mon, Jul 7, 2014 at 3:57 AM, Nathan Whitehorn > > wrote: > > On 07/06/14 10:37, Warner Losh wrote: > > > 5. The default RPI-B kernel is very lean: > http://svnweb.freebsd.org/base/head/sys/arm/conf/RPI-B?view=markup > > Still there are things which (I think) > I don't need, e.g. USB ethernet. > Will I gain anything by removing USB ethernet > from the kernel? > > The on-board Ethernet for RPi is actually connected > through USB. If you remove USB Ethernet, you have > removed Ethernet. > > Removing what you don't need will free up more RAM, > which is always good. > > Short of a dedicated building cluster of about 30 ARM > machines, doing a full package build on ARM within a few days > is a pipe-dream. We might be able to get it under a week with > qemu. > > > For sure. From the project perspective, though, I don't see a huge > problem with it taking a few weeks on a handful of CPUs rather > than a few days on 30. We've waited years for packages anyway. As > a happy side-effect, we also get to stress-test the operating system. > -Nathan > > _______________________________________________ > 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 > " > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 秘密保持に ついて：この電子メールは、名 宛人に送信したものであり、秘 > 匿特権の対象となる情報を含んでいます。 > も し、名宛人以外の方が受信された場合、このメールの破棄、お よびこの > メールに関する一切の開示、 > 複 写、配布、その他の利用、ま たは記載内容に基づくいかなる行動もされな > いようお願い申し上げ ます。 > --- > CONFIDENTIALITY NOTE: The information in this email is confidential > and intended solely for the addressee. > Disclosure, copying, distribution or any other action of use of this > email by person other than intended recipient, is prohibited. > If you are not the intended recipient and have received this email in > error, please destroy the original message. From owner-freebsd-arm@FreeBSD.ORG Mon Jul 7 08:11:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F14B4233 for ; Mon, 7 Jul 2014 08:11:34 +0000 (UTC) Received: from eu1sys200aog118.obsmtp.com (eu1sys200aog118.obsmtp.com [207.126.144.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 207202709 for ; Mon, 7 Jul 2014 08:11:33 +0000 (UTC) Received: from mail-wi0-f170.google.com ([209.85.212.170]) (using TLSv1) by eu1sys200aob118.postini.com ([207.126.147.11]) with SMTP ID DSNKU7pWGvyAkUxd0aoL62Ua6BKtm6rZyx4e@postini.com; Mon, 07 Jul 2014 08:11:34 UTC Received: by mail-wi0-f170.google.com with SMTP id cc10so14595576wib.3 for ; Mon, 07 Jul 2014 01:11:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=09cqba8tW6T9Vrg9+hInCxF+plEmFkTol+Y6j+eeZcQ=; b=XB1VsZ7JLSAv0Ca2P5vBQwCGZ+T9FwlGs0cRKiJQOmotF1aSBIswxYqzWyUFrXx+K0 ePah9EOsaIimauYGOCUEMrd5rgWgFXgVpFOSJsu51PGgElx+KiH8so4don8NjkeYTTIS YaM4UyeU1CQodqJWcIGkVhHAImM1l0jzF0xcNxZMkiYUC535ong0OXk4N2JVf3sGfjQd u4N7gU3l6X9qlfD5rz8+KxKlywrpJx6fEs+mZeTf5cegqR5UdM3+7/xGSic1pLBerHKw SDV32JOz7TW64+PrfFfjvLljEuWlh842WI55SpUqRgBY1MQb9l7+VqyKi1HXhL4/yghJ C5ag== X-Gm-Message-State: ALoCoQl0TEh4LPVB4O5AH6PAlk3t4cW5fQ0N+71VPzT7TP5NJfqCQ2ItrTFMgfglS/Ds7IGOEj0dKTNqyMjnn7s0uL5bLyXl2j3yLPSXZxvrQzgRABUmbp9yZRgDAbWyIbuPVE/af5yz X-Received: by 10.194.86.74 with SMTP id n10mr1053305wjz.132.1404720665954; Mon, 07 Jul 2014 01:11:05 -0700 (PDT) X-Received: by 10.194.86.74 with SMTP id n10mr1053297wjz.132.1404720665887; Mon, 07 Jul 2014 01:11:05 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id fb15sm112357275wid.23.2014.07.07.01.11.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jul 2014 01:11:05 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s678B3l1055730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Jul 2014 09:11:03 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s678B3V3055729; Mon, 7 Jul 2014 09:11:03 +0100 (BST) (envelope-from mexas) Date: Mon, 7 Jul 2014 09:11:03 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407070811.s678B3V3055729@mech-cluster241.men.bris.ac.uk> To: imp@bsdimp.com, tim@kientzle.com Subject: Re: official packages for arm? Reply-To: mexas@bris.ac.uk In-Reply-To: <556332C8-9EE8-4B94-829B-9D3A6DCC7FC8@bsdimp.com> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 08:11:35 -0000 >From imp@bsdimp.com Sun Jul 6 18:56:54 2014 >>=20 >> Biggest issue is simply that key ports still >> don't build on ARM. For example, a default >> build of git breaks because libgcrypt requires >> GCC 4.7 port, which doesn't build on ARM. > >I have forward ports of our patches that could help this. devel/binutils does not build: checking for cos in -lm... yes *** BFD does not support target armv6-portbld-freebsd10.0. *** Look in bfd/config.bfd for supported targets. gmake[3]: *** [configure-bfd] Error 1 gmake[3]: Leaving directory `/usr/ports/devel/binutils/work/binutils-2.24' Anton From owner-freebsd-arm@FreeBSD.ORG Mon Jul 7 11:12:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1022A5DA for ; Mon, 7 Jul 2014 11:12:03 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2FE528A3 for ; Mon, 7 Jul 2014 11:12:02 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s67BBt9S079747 for ; Mon, 7 Jul 2014 07:12:00 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <53BA807B.9080304@m5p.com> Date: Mon, 07 Jul 2014 07:11:55 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: official packages for arm? References: <201407070811.s678B3V3055729@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201407070811.s678B3V3055729@mech-cluster241.men.bris.ac.uk> Content-Type: multipart/mixed; boundary="------------020002020100050408020108" 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, 07 Jul 2014 07:12:00 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 11:12:03 -0000 This is a multi-part message in MIME format. --------------020002020100050408020108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/07/14 04:11, Anton Shterenlikht wrote: >>From imp@bsdimp.com Sun Jul 6 18:56:54 2014 >>> =20 >>> Biggest issue is simply that key ports still >>> don't build on ARM. For example, a default >>> build of git breaks because libgcrypt requires >>> GCC 4.7 port, which doesn't build on ARM. >> >> I have forward ports of our patches that could help this. > > devel/binutils does not build: > > checking for cos in -lm... yes > *** BFD does not support target armv6-portbld-freebsd10.0. > *** Look in bfd/config.bfd for supported targets. > gmake[3]: *** [configure-bfd] Error 1 > gmake[3]: Leaving directory `/usr/ports/devel/binutils/work/binutils-2.24' > > Anton > [...] By an interesting coincidence, I came across this yesterday. Add the two attached files to /usr/ports/devel/binutils/files and build again. -- George --------------020002020100050408020108 Content-Type: text/plain; charset=us-ascii; name="patch-bfd__config.bfd" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-bfd__config.bfd" --- bfd/config.bfd.orig 2013-11-04 10:33:37.000000000 -0500 +++ bfd/config.bfd 2014-07-06 18:15:06.000000000 -0400 @@ -331,8 +331,8 @@ targ_defvec=bfd_elf32_littlearm_vec targ_selvecs=bfd_elf32_bigarm_vec ;; - arm-*-elf | arm-*-freebsd* | arm*-*-linux-* | arm*-*-conix* | \ - arm*-*-uclinux* | arm-*-kfreebsd*-gnu | \ + arm-*-elf | arm*-*-freebsd* | arm*-*-linux-* | arm*-*-conix* | \ + arm*-*-uclinux* | arm*-*-kfreebsd*-gnu | \ arm*-*-eabi* ) targ_defvec=bfd_elf32_littlearm_vec targ_selvecs=bfd_elf32_bigarm_vec --------------020002020100050408020108 Content-Type: text/plain; charset=us-ascii; name="patch-ld__configure.tgt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-ld__configure.tgt" --- ld/configure.tgt 2014-07-06 20:28:51.000000000 -0400 +++ ld/configure.tgt.orig 2013-11-26 06:37:33.000000000 -0500 @@ -81,7 +81,7 @@ arm-*-aout | armel-*-aout) targ_emul=armaoutl ;; armeb-*-aout) targ_emul=armaoutb ;; arm-*-coff) targ_emul=armcoff ;; -arm*-*-freebsd* | arm*-*-kfreebsd*-gnu) +arm-*-freebsd* | arm-*-kfreebsd*-gnu) targ_emul=armelf_fbsd targ_extra_emuls="armelf" ;; armeb-*-netbsdelf*) targ_emul=armelfb_nbsd; --------------020002020100050408020108-- From owner-freebsd-arm@FreeBSD.ORG Mon Jul 7 12:31:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D10D8A56 for ; Mon, 7 Jul 2014 12:31:30 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BA1B2FC9 for ; Mon, 7 Jul 2014 12:31:30 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id r20so6780491wiv.4 for ; Mon, 07 Jul 2014 05:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=He/ccsP3Z28688CePZAxE8SLxwjWsPLHOAvq9X+2JI8=; b=hmgxQffh8phQ7BLcVn00N1PHkWN84zlIXUwtf3/ywTlqh/d9yHKn1+4gB5Ncfk+cZe nNAEy8Cmv5ADroasFT8zHKi7FNAbSiNZeCFsx/fNqrD+wKOD/MFFbfmE7MmdAn/mnWyG qKoTcL5PPkRT+cJrafCloDLv1GBx0OQ7OzqZisDeeYlM1e4hb5kI3R7T0sVocBt+76xc uCzOtt62LyA9JpfRH3nQ+UdUQRy9kZ7KCtNGKmsmV48uzYFX7tt46HiqBO3Eye17tNz6 1p3cvRZnkh0h+dZfFh+2U3DYQrbCEEXaAyzZlv8oYBrgLBWhg5sXtXMQEPacbYVqhNBr IwJg== MIME-Version: 1.0 X-Received: by 10.194.9.198 with SMTP id c6mr2743642wjb.131.1404736288547; Mon, 07 Jul 2014 05:31:28 -0700 (PDT) Received: by 10.194.47.38 with HTTP; Mon, 7 Jul 2014 05:31:28 -0700 (PDT) In-Reply-To: <53BA807B.9080304@m5p.com> References: <201407070811.s678B3V3055729@mech-cluster241.men.bris.ac.uk> <53BA807B.9080304@m5p.com> Date: Mon, 7 Jul 2014 14:31:28 +0200 Message-ID: Subject: Re: official packages for arm? From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= To: George Mitchell Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 12:31:30 -0000 2014-07-07 13:11 GMT+02:00 George Mitchell : > By an interesting coincidence, I came across this yesterday. Add the > two attached files to /usr/ports/devel/binutils/files and build again. This will produce a broken ld (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605) You should try the port from Andreas Tobler, he sent a CFT back in may on this list with the following subject: CFT binutils-ports From owner-freebsd-arm@FreeBSD.ORG Tue Jul 8 00:52:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AE6B20E for ; Tue, 8 Jul 2014 00:52:12 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1246A2416 for ; Tue, 8 Jul 2014 00:52:11 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s680q4tM085287; Mon, 7 Jul 2014 20:52:09 -0400 (EDT) (envelope-from george@m5p.com) Message-ID: <53BB40B4.3080403@m5p.com> Date: Mon, 07 Jul 2014 20:52:04 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlrYcOrbCBVcmFua2Fy?= , George Mitchell Subject: Re: official packages for arm? References: <201407070811.s678B3V3055729@mech-cluster241.men.bris.ac.uk> <53BA807B.9080304@m5p.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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, 07 Jul 2014 20:52:10 -0400 (EDT) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 00:52:12 -0000 On 07/07/14 08:31, Mikaël Urankar wrote: > 2014-07-07 13:11 GMT+02:00 George Mitchell : >> By an interesting coincidence, I came across this yesterday. Add the >> two attached files to /usr/ports/devel/binutils/files and build again. > > This will produce a broken ld (see > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605) > You should try the port from Andreas Tobler, he sent a CFT back in may > on this list with the following subject: CFT binutils-ports > Oh, okay. Sorry. -- George From owner-freebsd-arm@FreeBSD.ORG Tue Jul 8 05:15:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2A28991 for ; Tue, 8 Jul 2014 05:15:23 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 774C82B53 for ; Tue, 8 Jul 2014 05:15:23 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id f51so4491398qge.8 for ; Mon, 07 Jul 2014 22:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7nTS0jsofY85Z36mJL2J6niTZVWNuK7KqR4IP9Gf0Uo=; b=qEgpAGqTeF4Z3UxpdNQ5rm6dCSeAfkh+yav6ChG/zw57by+i0kdpBIpM9rGFRTpGqs 9VMn7qY1bMTLO6CQfcV4PmU48ILelKhGLAM5BMrjLtNXjXIFnet+6ID5N1xBW47hRFj/ QhJXuR049MSuSZOFdsFFOL1Dh4HFkVYexqyACHJunDXZ0PqU3/1lbMQ8lK/7yIpvLw3q U7Ob0mUXpAR8fkQROqUSTbMFM4e1DoW1JxAu4A4DTx/2n1zdxMueuNm2aPyz4yUeZFa8 aQUfg0m6OlVvTj/m1vR+fZzneftLb588k0m6gVPxw6y/L5t6h3O6RfFL0P1S5/rdpNK7 GDCA== MIME-Version: 1.0 X-Received: by 10.140.19.109 with SMTP id 100mr53482634qgg.80.1404796522679; Mon, 07 Jul 2014 22:15:22 -0700 (PDT) Received: by 10.140.93.247 with HTTP; Mon, 7 Jul 2014 22:15:22 -0700 (PDT) Date: Tue, 8 Jul 2014 10:45:22 +0530 Message-ID: Subject: ARMv8 FreeBSD porting support From: Chandrasekhar Nagarajan To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 05:15:23 -0000 Hello, I have been trying to port FreeBSD on ARMv8 (64 bit architecture). I followed the steps given in [1] and could successfully start the UEFI boot manager on the foundation model of ARMv8. I am not able to figure out the boot process that has to be followed, to boot FreeBSD on the foundation model. Any help is appreciated. [1] https://wiki.freebsd.org/arm64 Thank you Regards -- Chandrasekhar From owner-freebsd-arm@FreeBSD.ORG Tue Jul 8 17:34:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B36AE6B for ; Tue, 8 Jul 2014 17:34:23 +0000 (UTC) Received: from eu1sys200aog130.obsmtp.com (eu1sys200aog130.obsmtp.com [207.126.144.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF3D32C8C for ; Tue, 8 Jul 2014 17:34:21 +0000 (UTC) Received: from mail-wg0-f46.google.com ([74.125.82.46]) (using TLSv1) by eu1sys200aob130.postini.com ([207.126.147.11]) with SMTP ID DSNKU7wrlUFUZFlWNvv5NOUJskTK7mxkoza9@postini.com; Tue, 08 Jul 2014 17:34:22 UTC Received: by mail-wg0-f46.google.com with SMTP id m15so939490wgh.5 for ; Tue, 08 Jul 2014 10:34:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=IeG0QZkaP/JoLcQyQ365B3eeOh1SFy/hsdoQWiqjEPc=; b=NUjaXh9iYQYWj193Lt6ChR146h+PG4XtdpYtGWY20hBJcOXUOzh7wXeLyORp+hYfJi 1VA8NAN94K9A6KQkbTn6opyDCHv9qJI9K4xCEwhW+BNFh9BBdryWl8nz8hcUZrSBesk6 q4PCA9aKb92nT+kOAr+4EcBuHw/ZbLidk05IVY1jgMw/2A09UqDMNf5XFQqeKNyEX80F XCnU8x7MaXhWXpfDDu+6MtBwM0KlqNoSZw+OB85piqd344r5U8APJ6qG2stuaznU1iS0 DOqeDiwUIJuDZvbxKI8W16Xr1RBjEuO1qS2vgTNYGTkWzvwmARWbSpDBmZGiP0gdPQ/g u3cA== X-Received: by 10.180.206.73 with SMTP id lm9mr5484458wic.54.1404839061483; Tue, 08 Jul 2014 10:04:21 -0700 (PDT) X-Gm-Message-State: ALoCoQlGurtRYcafZ0DegDzzzH5SN1PQX19TQVTLuhWDYu8n05qufOfv8sNnHls5iD2vsV+gbA19kXXkk2U3vhcQE58EfVQTXvDJ+KqGTZ0qUqvl/l1lBQFQ2ys3FQLSZXxjJXTZpTC/ X-Received: by 10.180.206.73 with SMTP id lm9mr5484442wic.54.1404839061282; Tue, 08 Jul 2014 10:04:21 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id pq9sm97550247wjc.35.2014.07.08.10.04.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jul 2014 10:04:20 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s68H4Jk0065653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 8 Jul 2014 18:04:19 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s68H4Jjf065652 for freebsd-arm@freebsd.org; Tue, 8 Jul 2014 18:04:19 +0100 (BST) (envelope-from mexas) Date: Tue, 8 Jul 2014 18:04:19 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407081704.s68H4Jjf065652@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: graphics/dri installation errors Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:34:23 -0000 ===> Registering installation for dri-9.1.7_4,2 pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/libdricore9.1.7.la): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/libdricore9.1.7.so): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/libdricore9.1.7.so.1): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/libdricore9.1.7.so.1.0.0): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/dri/): No such file or directory *** Error code 74 Stop. # uname -a FreeBSD raspberry-pi 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul 1 04:29:43 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm # svn info /usr/ports/ Path: /usr/ports Working Copy Root Path: /usr/ports URL: https://svn0.eu.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn0.eu.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 361055 Node Kind: directory Schedule: normal Last Changed Author: robak Last Changed Rev: 361055 Last Changed Date: 2014-07-07 11:48:48 +0000 (Mon, 07 Jul 2014) Anybody else is seeing this? Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Tue Jul 8 19:24:20 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C05CBF10 for ; Tue, 8 Jul 2014 19:24:20 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C3F7279A for ; Tue, 8 Jul 2014 19:24:20 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X4azy-0004Md-U9; Tue, 08 Jul 2014 19:24:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s68JOFEi001419; Tue, 8 Jul 2014 13:24:15 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1++hS1eIoNwqBTlFH6FXjGY Subject: Re: /tmp, /var/log, /var/tmp as /dev/md - why? From: Ian Lepore To: Warren Block In-Reply-To: References: <201407010925.s619PHeT006679@mech-cluster241.men.bris.ac.uk> <44a6e8a451a.810fa8f@mail.schwarzes.net> <53B3EB29.4030908@gmail.com> <20140703105519.GA37593@zibbi.meraka.csir.co.za> <1404396464.20883.404.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="=-G5VN/5bc443ZriXVTaAl" Date: Tue, 08 Jul 2014 13:24:15 -0600 Message-ID: <1404847455.65432.67.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:24:20 -0000 --=-G5VN/5bc443ZriXVTaAl Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, 2014-07-03 at 11:49 -0600, Warren Block wrote: > On Thu, 3 Jul 2014, Ian Lepore wrote: > > On Thu, 2014-07-03 at 12:55 +0200, John Hay wrote: > >> On Thu, Jul 03, 2014 at 04:47:24AM -0600, Warren Block wrote: > >>> > >>> So a limited-size tmpfs will be faster and use less memory overall. A > >>> benchmark comparison would be interesting. > >> > >> Last time I looked the rc scripts that create /etc, /var and /tmp > >> ramdisks only did it using md devices. It would be great if it was > >> easily tunable from say rc.conf or if could detect which one is > >> available and use that. > > > > I have patches ready to commit that do exactly that, but they weren't > > exactly enthusiastically received when I posted them on arch@ for > > review. > > This thread? > http://lists.freebsd.org/pipermail/freebsd-arch/2014-March/015141.html > > Have not read it fully yet, but it sounds exactly right: everything acts > the same, the user can just pick tmpfs or mfs. Yeah, that one. I've reworked it this morning to incorporate the earlier suggestion to avoid adding a FEATURE macro to indicate the presence of tmpfs. With today's changes it will work right if tmpfs is either already in the kernel or available to load as tmpfs.ko. I'll attach the updated patchset in case anyone wants to test it. The only blocker to committing it at this point is that the mdmfs(8) manpage needs a lot of changes to become less md(4)-centric and more about how it configures and mounts memory filesystems. I'm not sure when I'll find time for that. -- Ian --=-G5VN/5bc443ZriXVTaAl Content-Disposition: inline; filename="mdmfs_tmpfs2.diff" Content-Type: text/x-patch; name="mdmfs_tmpfs2.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sbin/mdmfs/mdmfs.c =================================================================== --- sbin/mdmfs/mdmfs.c (revision 268402) +++ sbin/mdmfs/mdmfs.c (working copy) @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); #include +#include #include #include #include @@ -41,6 +42,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include #include @@ -78,7 +80,8 @@ static void debugprintf(const char *, ...) __prin static void do_mdconfig_attach(const char *, const enum md_types); static void do_mdconfig_attach_au(const char *, const enum md_types); static void do_mdconfig_detach(void); -static void do_mount(const char *, const char *); +static void do_mount_md(const char *, const char *); +static void do_mount_tmpfs(const char *, const char *); static void do_mtptsetup(const char *, struct mtpt_info *); static void do_newfs(const char *); static void extract_ugid(const char *, struct mtpt_info *); @@ -90,13 +93,13 @@ main(int argc, char **argv) { struct mtpt_info mi; /* Mountpoint info. */ char *mdconfig_arg, *newfs_arg, /* Args to helper programs. */ - *mount_arg; + *mount_arg, *size_arg; enum md_types mdtype; /* The type of our memory disk. */ - bool have_mdtype; + bool have_mdtype, mlmac; bool detach, softdep, autounit, newfs; - char *mtpoint, *unitstr; + const char *mtpoint, *unitstr; char *p; - int ch; + int ch, fileid; void *set; unsigned long ul; @@ -105,6 +108,7 @@ main(int argc, char **argv) detach = true; softdep = true; autounit = false; + mlmac = false; newfs = true; have_mdtype = false; mdtype = MD_SWAP; @@ -119,6 +123,7 @@ main(int argc, char **argv) mdconfig_arg = strdup(""); newfs_arg = strdup(""); mount_arg = strdup(""); + size_arg = NULL; /* If we were started as mount_mfs or mfs, imply -C. */ if (strcmp(getprogname(), "mount_mfs") == 0 || @@ -175,6 +180,7 @@ main(int argc, char **argv) loudsubs = true; break; case 'l': + mlmac = true; argappend(&newfs_arg, "-l"); break; case 'M': @@ -213,7 +219,7 @@ main(int argc, char **argv) softdep = false; break; case 's': - argappend(&mdconfig_arg, "-s %s", optarg); + size_arg = optarg; break; case 't': argappend(&newfs_arg, "-t"); @@ -239,42 +245,68 @@ main(int argc, char **argv) if (argc < 2) usage(); - /* Derive 'unit' (global). */ + /* + * Based on the command line 'md-device' either mount a tmpfs filesystem + * or configure the md device then format and mount a filesystem on it. + * If the device is "auto" use tmpfs if it is available and there is no + * request for multilabel MAC (which tmpfs does not support) on the + * filesystem. The only way to know whether tmpfs is available is to + * attempt to kldload() it. If it loads (or fails with EEXIST because + * it is already present) then we can use it. + */ unitstr = argv[0]; - if (strncmp(unitstr, "/dev/", 5) == 0) - unitstr += 5; - if (strncmp(unitstr, mdname, mdnamelen) == 0) - unitstr += mdnamelen; - if (!isdigit(*unitstr)) { - autounit = true; - unit = -1; - mdsuffix = unitstr; + mtpoint = argv[1]; + + if (strcmp(unitstr, "auto") == 0) { + fileid = kldload("tmpfs"); + if (mlmac || (fileid == -1 && errno != EEXIST)) + unitstr = "md"; + else + unitstr = "tmpfs"; + } + + if (strcmp(unitstr, "tmpfs") == 0) { + if (size_arg != NULL) + argappend(&mount_arg, "-o size=%s", size_arg); + do_mount_tmpfs(mount_arg, mtpoint); } else { - ul = strtoul(unitstr, &p, 10); - if (ul == ULONG_MAX) - errx(1, "bad device unit: %s", unitstr); - unit = ul; - mdsuffix = p; /* can be empty */ + if (size_arg != NULL) + argappend(&mdconfig_arg, "-s %s", size_arg); + if (strncmp(unitstr, "/dev/", 5) == 0) + unitstr += 5; + if (strncmp(unitstr, mdname, mdnamelen) == 0) + unitstr += mdnamelen; + if (!isdigit(*unitstr)) { + autounit = true; + unit = -1; + mdsuffix = unitstr; + } else { + ul = strtoul(unitstr, &p, 10); + if (ul == ULONG_MAX) + errx(1, "bad device unit: %s", unitstr); + unit = ul; + mdsuffix = p; /* can be empty */ + } + + if (!have_mdtype) + mdtype = MD_SWAP; + if (softdep) + argappend(&newfs_arg, "-U"); + if (mdtype != MD_VNODE && !newfs) + errx(1, "-P requires a vnode-backed disk"); + + /* Do the work. */ + if (detach && !autounit) + do_mdconfig_detach(); + if (autounit) + do_mdconfig_attach_au(mdconfig_arg, mdtype); + else + do_mdconfig_attach(mdconfig_arg, mdtype); + if (newfs) + do_newfs(newfs_arg); + do_mount_md(mount_arg, mtpoint); } - mtpoint = argv[1]; - if (!have_mdtype) - mdtype = MD_SWAP; - if (softdep) - argappend(&newfs_arg, "-U"); - if (mdtype != MD_VNODE && !newfs) - errx(1, "-P requires a vnode-backed disk"); - - /* Do the work. */ - if (detach && !autounit) - do_mdconfig_detach(); - if (autounit) - do_mdconfig_attach_au(mdconfig_arg, mdtype); - else - do_mdconfig_attach(mdconfig_arg, mdtype); - if (newfs) - do_newfs(newfs_arg); - do_mount(mount_arg, mtpoint); do_mtptsetup(mtpoint, &mi); return (0); @@ -431,7 +463,7 @@ do_mdconfig_detach(void) * Mount the configured memory disk. */ static void -do_mount(const char *args, const char *mtpoint) +do_mount_md(const char *args, const char *mtpoint) { int rv; @@ -442,6 +474,19 @@ static void } /* + * Mount the configured tmpfs. + */ +static void +do_mount_tmpfs(const char *args, const char *mtpoint) +{ + int rv; + + rv = run(NULL, "%s -t tmpfs %s tmp %s", _PATH_MOUNT, args, mtpoint); + if (rv) + errx(1, "tmpfs mount exited with error code %d", rv); +} + +/* * Various configuration of the mountpoint. Mostly, enact 'mip'. */ static void Index: etc/defaults/rc.conf =================================================================== --- etc/defaults/rc.conf (revision 268402) +++ etc/defaults/rc.conf (working copy) @@ -51,6 +51,7 @@ tmpmfs_flags="-S" # Extra mdmfs options for the mf varmfs="AUTO" # Set to YES to always create an mfs /var, NO to never varsize="32m" # Size of mfs /var if created varmfs_flags="-S" # Extra mount options for the mfs /var +mfs_type="auto" # "md", "tmpfs", or "auto" to choose tmpfs when available populate_var="AUTO" # Set to YES to always (re)populate /var, NO to never cleanvar_enable="YES" # Clean the /var directory local_startup="/usr/local/etc/rc.d" # startup script dirs. Index: etc/rc.initdiskless =================================================================== --- etc/rc.initdiskless (revision 268402) +++ etc/rc.initdiskless (working copy) @@ -198,7 +198,7 @@ handle_remount() { # $1 = mount point # Create a generic memory disk # mount_md() { - /sbin/mdmfs -S -i 4096 -s $1 -M md $2 + /sbin/mdmfs -S -i 4096 -s $1 -M auto $2 } # Create the memory filesystem if it has not already been created Index: etc/rc.subr =================================================================== --- etc/rc.subr (revision 268402) +++ etc/rc.subr (working copy) @@ -1728,7 +1728,7 @@ mount_md() if [ -n "$3" ]; then flags="$3" fi - /sbin/mdmfs $flags -s $1 md $2 + /sbin/mdmfs $flags -s $1 ${mfs_type} $2 } # Code common to scripts that need to load a kernel module --=-G5VN/5bc443ZriXVTaAl-- From owner-freebsd-arm@FreeBSD.ORG Tue Jul 8 19:55:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66C7DFD9 for ; Tue, 8 Jul 2014 19:55:26 +0000 (UTC) Received: from eu1sys200aog107.obsmtp.com (eu1sys200aog107.obsmtp.com [207.126.144.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBDF62AE1 for ; Tue, 8 Jul 2014 19:55:25 +0000 (UTC) Received: from mail-wi0-f178.google.com ([209.85.212.178]) (using TLSv1) by eu1sys200aob107.postini.com ([207.126.147.11]) with SMTP ID DSNKU7xMiYuDJQOJ61/4L3S+Uui5dwkOLyMD@postini.com; Tue, 08 Jul 2014 19:55:25 UTC Received: by mail-wi0-f178.google.com with SMTP id f8so1110673wiw.5 for ; Tue, 08 Jul 2014 12:54:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=LsaRrkz1PQ1AWL3Q/ARx1FxzJSsapPI39j0czkzFL2s=; b=I2hhv1BZ2h7okQlmjynJ/e1FNYzhFuyQhdj3Jp7bBd86pXHnRXuTXWWRON0WkNDZcq szNfod7PE9+bo7/MrwxUvuKUtP6SJfdRWeSEP0IL9wGHxMeQt3tMAHJ6i4XZ+exq9brL n6eL/qUDhWrcrxvZAsZfKGRfGeiNZvxsZ3RaIOmsTSHI/cqGLdhmf4fHBcKYlxFhzhAn mSGh/Bsq77j4UN5zrJUGsGG/ILctzI+uFIlrQ3tFC9hPX8EOzSutmjfBaZ+VVxuvED5v VO2TqgWpcH0epgV9AqRFbDLyJ6tjjMfv7zeJ1Qduk94bRN4pnlZMWVcjziroEy1wr/Lb C8rQ== X-Gm-Message-State: ALoCoQmKHtdmkZw4daBYpNLZD6/0TySjdVlbxHQ3cgUi+ZPvvk7NZu1sBPjH2xehvz9J7KIMHYjD4JkjK54Ps5MLyrdYTIOMmQi3HI5IB6d/O9zdM5UH0HQDhQEAa+nWWdC1OnglQT+/ X-Received: by 10.194.92.115 with SMTP id cl19mr43195087wjb.29.1404849289103; Tue, 08 Jul 2014 12:54:49 -0700 (PDT) X-Received: by 10.194.92.115 with SMTP id cl19mr43195071wjb.29.1404849288934; Tue, 08 Jul 2014 12:54:48 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id ex4sm10631411wic.2.2014.07.08.12.54.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jul 2014 12:54:48 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s68Jsl8S066070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 8 Jul 2014 20:54:47 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s68Jsk7q066069 for freebsd-arm@freebsd.org; Tue, 8 Jul 2014 20:54:47 +0100 (BST) (envelope-from mexas) Date: Tue, 8 Jul 2014 20:54:47 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407081954.s68Jsk7q066069@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: sound on RPi-B? Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:55:26 -0000 If I want sound from an RPi-B, do I just follow the handbook, or are there any special considerations? In particular, it seems I can draw sound in 2 ways, via a dedicated sound port, or via HDMI. I'm using an HDMI to VGA adapter that provides a separate sound output. I see there is no sound driver in the default kernel, but since HDMI is supported, I wonder if I have sound support already? Please advise Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Tue Jul 8 20:00:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E374652 for ; Tue, 8 Jul 2014 20:00:50 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C55512B27 for ; Tue, 8 Jul 2014 20:00:49 +0000 (UTC) Received: from [192.168.1.200] (p508F159A.dip0.t-ipconnect.de [80.143.21.154]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1CB9B1C10462D; Tue, 8 Jul 2014 22:00:46 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: svnlite segfaults a lot From: Michael Tuexen In-Reply-To: <20140702092041.716a7413@bender.lan> Date: Tue, 8 Jul 2014 22:00:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201407010930.s619Uk9X006689@mech-cluster241.men.bris.ac.uk> <20140702092041.716a7413@bender.lan> To: Andrew Turner X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:00:50 -0000 On 02 Jul 2014, at 10:20, Andrew Turner wrote: > On Tue, 1 Jul 2014 10:30:46 +0100 (BST) > Anton Shterenlikht wrote: >=20 >> # uname -a >> FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267801: >> Tue Jun 24 11:03:28 UTC 2014 >> root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >>=20 >> I'm trying to pull the ports tree to rasp. pi model B. >> svnlite up (or co) segfaults after pulling 1-5 MB. >> Is this expected? >>=20 >> I'm powering via a bench power supply, so I can >> monitor the current. It is only about 400mA, >> occasionally raising to maybe 450mA. >> So my earlier suspicion, that an inadequate >> power was to blame, was wrong. >>=20 >> Anybody else seeing svnlite segfaults? >=20 > Yes, however I never tracked it down. I found svn from ports to work = as > expected. Using r267055 svn build from ports also segfaults a lot. The backtrace: (gdb) where #0 0x20116494 in window_handler () from /usr/local/lib/libsvn_wc-1.so.0 #1 0x2026e12c in handle_fetch () from = /usr/local/lib/libsvn_ra_serf-1.so.0 #2 0x20271c10 in handle_response_cb () from = /usr/local/lib/libsvn_ra_serf-1.so.0 #3 0x20288168 in serf__process_connection () from = /usr/local/lib/libserf-1.so.1 #4 0x20286f6c in serf_event_trigger () from = /usr/local/lib/libserf-1.so.1 #5 0x20287088 in serf_context_run () from /usr/local/lib/libserf-1.so.1 #6 0x2026ad18 in finish_report () from = /usr/local/lib/libsvn_ra_serf-1.so.0 #7 0x200dcc94 in svn_wc_crawl_revisions5 () from = /usr/local/lib/libsvn_wc-1.so.0 #8 0x200bdbc0 in update_internal () from = /usr/local/lib/libsvn_client-1.so.0 #9 0x200bd350 in svn_client__update_internal () from = /usr/local/lib/libsvn_client-1.so.0 #10 0x200bdeb8 in svn_client_update4 () from = /usr/local/lib/libsvn_client-1.so.0 #11 0x00026918 in svn_cl__check_cancel () #12 0x00000000 in ?? () Best regards Michael >=20 > 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" >=20 From owner-freebsd-arm@FreeBSD.ORG Thu Jul 10 09:54:35 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D778E95 for ; Thu, 10 Jul 2014 09:54:35 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AC8027BF for ; Thu, 10 Jul 2014 09:54:34 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6A9sXkd025730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Jul 2014 02:54:34 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6A9sXU3025729 for freebsd-arm@FreeBSD.org; Thu, 10 Jul 2014 02:54:33 -0700 (PDT) (envelope-from jmg) Date: Thu, 10 Jul 2014 02:54:33 -0700 From: John-Mark Gurney To: freebsd-arm@FreeBSD.org Subject: [andrew@freebsd.org: svn commit: r268310 - head/libexec/rtld-elf/arm] Message-ID: <20140710095433.GV45513@funkthat.com> Mail-Followup-To: freebsd-arm@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 10 Jul 2014 02:54:34 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 09:54:35 -0000 I believe that this commit makes AVILA boards stable on -HEAD now... This includes building ports (though it takes a LONG time) and other things... Let me know if anyone has issues, and I'll try to reproduce and track them down.. This means I may finally be able to upgrade my router from 9 to HEAD and have my guest network finally support 11n... :) ----- Forwarded message from Andrew Turner ----- From: Andrew Turner Date: Sun, 6 Jul 2014 10:24:06 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r268310 - head/libexec/rtld-elf/arm Author: andrew Date: Sun Jul 6 10:24:06 2014 New Revision: 268310 URL: http://svnweb.freebsd.org/changeset/base/268310 Log: Align the stack in _rtld_bind_start. Normally this is called with the correct stack alignment, however when we have a leaf function that uses thread local storage it calls __aeabi_read_tp to get the thread pointer. Neither GCC or clang see this as a function call so will align the stack to a 4-byte boundary. This may be a problem as _rtld_bind expects to be on an 8-byte boundary. The solution is to store a copy of the stack pointer and force the alignment before calling _rtld_bind. This fixes a problem with armeb where applications would crash in odd ways. It should also remove the need for a local patch to clang to force the stack alignment to an 8-byte boundary, even for leaf functions. Further testing will be needed before reverting this local change to clang as we may rely on it in other places. Reviewed by: jmg@ Modified: head/libexec/rtld-elf/arm/rtld_start.S Modified: head/libexec/rtld-elf/arm/rtld_start.S ============================================================================== --- head/libexec/rtld-elf/arm/rtld_start.S Sun Jul 6 07:34:18 2014 (r268309) +++ head/libexec/rtld-elf/arm/rtld_start.S Sun Jul 6 10:24:06 2014 (r268310) @@ -77,7 +77,7 @@ __FBSDID("$FreeBSD$"); * lr = &GOT[2] */ _rtld_bind_start: - stmdb sp!,{r0-r4,sl,fp} + stmdb sp!,{r0-r5,sl,fp} sub r1, ip, lr /* r1 = 4 * (n + 1) */ sub r1, r1, #4 /* r1 = 4 * n */ @@ -86,11 +86,14 @@ _rtld_bind_start: ldr r0, [lr, #-4] /* get obj ptr from GOT[1] */ mov r4, ip /* save GOT location */ + mov r5, sp /* Save the stack pointer */ + bic sp, sp, #7 /* Align the stack pointer */ bl _rtld_bind /* Call the binder */ + mov sp, r5 /* Restore the old stack pointer */ str r0, [r4] /* save address in GOT */ mov ip, r0 /* save new address */ - ldmia sp!,{r0-r4,sl,fp,lr} /* restore the stack */ + ldmia sp!,{r0-r5,sl,fp,lr} /* restore the stack */ mov pc, ip /* jump to the new address */ ----- End forwarded message ----- -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu Jul 10 12:58:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4514AC26 for ; Thu, 10 Jul 2014 12:58:01 +0000 (UTC) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 0627227F7 for ; Thu, 10 Jul 2014 12:58:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 78AC74E698 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1404997075; bh=GOhwhBICZxQITK1D46D0ZJdh42RYJYCjPR1XdhIsYEc=; h=Date:From:To:Subject:References:In-Reply-To; b=fFuPnwtbreomH/P0Qn+gQ+AMUwKOKFInlUoCBvC/1rfx0IgKz9MYHloBaGQP70Pzz PqstM918RMyHNMG7H5/W80FZZObmWHDe75yoP3IhNMkGKskDNUJjPwzBtpgZ5D7sRU 6Yv71PRVCCNaB+pHEBWHzT1c7aA+QcoUQEjCExl8= Message-ID: <53BE8DD5.4010608@bakulin.de> Date: Thu, 10 Jul 2014 13:57:57 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: Chandrasekhar Nagarajan , freebsd-arm@freebsd.org Subject: Re: ARMv8 FreeBSD porting support References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:58:01 -0000 Hi, check out projects/arm64 branch in Subversion / Git -- it already has some stuff. On 08.07.14, 06:15, Chandrasekhar Nagarajan wrote: > Hello, > I have been trying to port FreeBSD on ARMv8 (64 bit architecture). I > followed the steps given in [1] and could successfully start the UEFI boot > manager on the foundation model of ARMv8. I am not able to figure out the > boot process that has to be followed, to boot FreeBSD on the foundation > model. > > Any help is appreciated. > > [1] https://wiki.freebsd.org/arm64 > > Thank you > Regards > -- Regards, Ilya Bakulin From owner-freebsd-arm@FreeBSD.ORG Thu Jul 10 14:15:40 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 035EC86E for ; Thu, 10 Jul 2014 14:15:40 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 890312F5A for ; Thu, 10 Jul 2014 14:15:39 +0000 (UTC) Received: from [192.168.1.200] (p508F3FFA.dip0.t-ipconnect.de [80.143.63.250]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D67C71C104DFB for ; Thu, 10 Jul 2014 16:15:35 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RPi panic Message-Id: Date: Thu, 10 Jul 2014 16:15:34 +0200 To: "freebsd-arm@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:15:40 -0000 Dear all, I just installed r268460 on a Raspberry Pi and started a portsnap fetch It resulted in root@bsd6:/home/tuexen # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Thu Jul 10 03:57:53 UTC 2014: 440edc07cb0d0ad05ffe81a943b0da4ded08aeadeae664100% of 68 MB 395 kBps = 02m57s Extracting snapshot... done. Verifying snapshot integrity... panic: ffs_clusteralloc: map mismatch KDB: enter: panic [ thread pid 733 tid 100075 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> where Tracing pid 733 tid 100075 td 0xc2a34960 db_trace_self() at db_trace_self pc =3D 0xc049be6c lr =3D 0xc013218c (db_stack_trace+0xf4) sp =3D 0xdcfd3478 fp =3D 0xdcfd3490 r10 =3D 0xc066ff6c db_stack_trace() at db_stack_trace+0xf4 pc =3D 0xc013218c lr =3D 0xc0131afc (db_command+0x270) sp =3D 0xdcfd3498 fp =3D 0xdcfd3538 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000072 db_command() at db_command+0x270 pc =3D 0xc0131afc lr =3D 0xc0131860 (db_command_loop+0x60) sp =3D 0xdcfd3540 fp =3D 0xdcfd3550 r4 =3D 0xc04dbba0 r5 =3D 0xc04f617b r6 =3D 0xc066ff58 r7 =3D 0xc05989d8 r8 =3D 0xc06661c4 r9 =3D 0xc06661c0 r10 =3D 0xdcfd3720 db_command_loop() at db_command_loop+0x60 pc =3D 0xc0131860 lr =3D 0xc0134228 (db_trap+0xd8) sp =3D 0xdcfd3558 fp =3D 0xdcfd3678 r4 =3D 0x00000000 r5 =3D 0xc066ff64 r6 =3D 0xc06661f0 db_trap() at db_trap+0xd8 pc =3D 0xc0134228 lr =3D 0xc0290ae0 (kdb_trap+0xbc) sp =3D 0xdcfd3680 fp =3D 0xdcfd36a0 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0xc06661f0 r7 =3D 0xc05989d8 kdb_trap() at kdb_trap+0xbc pc =3D 0xc0290ae0 lr =3D 0xc04af8e0 = (undefinedinstruction+0x298) sp =3D 0xdcfd36a8 fp =3D 0xdcfd3718 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xc04af598 r7 =3D 0xe7ffffff r8 =3D 0xc2a34960 r9 =3D 0xc02903b0 r10 =3D 0xdcfd3720 undefinedinstruction() at undefinedinstruction+0x298 pc =3D 0xc04af8e0 lr =3D 0xc049d9e8 (exception_exit) sp =3D 0xdcfd3720 fp =3D 0xdcfd3778 r4 =3D 0xc04f61d0 r5 =3D 0xdcfd37b4 r6 =3D 0xc0518e99 r7 =3D 0xc0658708 r8 =3D 0xc2a34960 r9 =3D 0xc067191c r10 =3D 0xc0658570 exception_exit() at exception_exit pc =3D 0xc049d9e8 lr =3D 0xc02903a4 (kdb_enter+0x40) sp =3D 0xdcfd3770 fp =3D 0xdcfd3778 r0 =3D 0xc06661d4 r1 =3D 0x00000000 r2 =3D 0xc04f9c1d r3 =3D 0x000000aa r4 =3D 0xc04f61d0 r5 =3D 0xdcfd37b4 r6 =3D 0xc0518e99 r7 =3D 0xc0658708 r8 =3D 0xc2a34960 r9 =3D 0xc067191c r10 =3D 0xc0658570 r12 =3D 0x00000000 $a() at $a pc =3D 0xc02903b4 lr =3D 0xc0259a30 (vpanic+0xb4) sp =3D 0xdcfd3780 fp =3D 0xdcfd37a0 r4 =3D 0x00000100 vpanic() at vpanic+0xb4 pc =3D 0xc0259a30 lr =3D 0xc0259a94 (kproc_shutdown) sp =3D 0xdcfd37a8 fp =3D 0xdcfd37ac r4 =3D 0x000009d9 r5 =3D 0x00000002 r6 =3D 0x00000002 r7 =3D 0x00000000 r8 =3D 0xcc601028 r9 =3D 0x000009d8 r10 =3D 0xc2812000 kproc_shutdown() at kproc_shutdown pc =3D 0xc0259a94 lr =3D 0x0000f800 (0xf800) sp =3D 0xdcfd37b4 fp =3D 0xdcfd3810 r4 =3D 0xc0259a94 r5 =3D 0xdcfd37b4 Unable to unwind into user mode db>=20 Any idea? Best regards Michael= From owner-freebsd-arm@FreeBSD.ORG Thu Jul 10 16:56:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0973DE5F for ; Thu, 10 Jul 2014 16:56:04 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E64072E26 for ; Thu, 10 Jul 2014 16:56:03 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s6AGttPV021708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 10 Jul 2014 09:55:55 -0700 Message-ID: <53BEC59B.8080402@freebsd.org> Date: Thu, 10 Jul 2014 09:55:55 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: [andrew@freebsd.org: svn commit: r268310 - head/libexec/rtld-elf/arm] References: <20140710095433.GV45513@funkthat.com> In-Reply-To: <20140710095433.GV45513@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;AoAFD1MI5BGhwmuUdPQXfw== M;+BsoD1MI5BGhwmuUdPQXfw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 16:56:04 -0000 I updated my AVILA router to HEAD over the weekend. Working beautifully. Thanks! -Nathan On 07/10/14 02:54, John-Mark Gurney wrote: > I believe that this commit makes AVILA boards stable on -HEAD now... > This includes building ports (though it takes a LONG time) and other > things... Let me know if anyone has issues, and I'll try to reproduce > and track them down.. > > This means I may finally be able to upgrade my router from 9 to HEAD > and have my guest network finally support 11n... :) > > ----- Forwarded message from Andrew Turner ----- > > From: Andrew Turner > Date: Sun, 6 Jul 2014 10:24:06 +0000 (UTC) > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > Subject: svn commit: r268310 - head/libexec/rtld-elf/arm > > Author: andrew > Date: Sun Jul 6 10:24:06 2014 > New Revision: 268310 > URL: http://svnweb.freebsd.org/changeset/base/268310 > > Log: > Align the stack in _rtld_bind_start. Normally this is called with the > correct stack alignment, however when we have a leaf function that uses > thread local storage it calls __aeabi_read_tp to get the thread pointer. > Neither GCC or clang see this as a function call so will align the stack > to a 4-byte boundary. This may be a problem as _rtld_bind expects to be > on an 8-byte boundary. > > The solution is to store a copy of the stack pointer and force the > alignment before calling _rtld_bind. > > This fixes a problem with armeb where applications would crash in odd ways. > It should also remove the need for a local patch to clang to force the > stack alignment to an 8-byte boundary, even for leaf functions. Further > testing will be needed before reverting this local change to clang as we > may rely on it in other places. > > Reviewed by: jmg@ > > Modified: > head/libexec/rtld-elf/arm/rtld_start.S > > Modified: head/libexec/rtld-elf/arm/rtld_start.S > ============================================================================== > --- head/libexec/rtld-elf/arm/rtld_start.S Sun Jul 6 07:34:18 2014 (r268309) > +++ head/libexec/rtld-elf/arm/rtld_start.S Sun Jul 6 10:24:06 2014 (r268310) > @@ -77,7 +77,7 @@ __FBSDID("$FreeBSD$"); > * lr = &GOT[2] > */ > _rtld_bind_start: > - stmdb sp!,{r0-r4,sl,fp} > + stmdb sp!,{r0-r5,sl,fp} > > sub r1, ip, lr /* r1 = 4 * (n + 1) */ > sub r1, r1, #4 /* r1 = 4 * n */ > @@ -86,11 +86,14 @@ _rtld_bind_start: > ldr r0, [lr, #-4] /* get obj ptr from GOT[1] */ > mov r4, ip /* save GOT location */ > > + mov r5, sp /* Save the stack pointer */ > + bic sp, sp, #7 /* Align the stack pointer */ > bl _rtld_bind /* Call the binder */ > + mov sp, r5 /* Restore the old stack pointer */ > > str r0, [r4] /* save address in GOT */ > mov ip, r0 /* save new address */ > > - ldmia sp!,{r0-r4,sl,fp,lr} /* restore the stack */ > + ldmia sp!,{r0-r5,sl,fp,lr} /* restore the stack */ > mov pc, ip /* jump to the new address */ > > > ----- End forwarded message ----- > From owner-freebsd-arm@FreeBSD.ORG Fri Jul 11 09:16:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F45AACD for ; Fri, 11 Jul 2014 09:16:01 +0000 (UTC) Received: from eu1sys200aog124.obsmtp.com (eu1sys200aog124.obsmtp.com [207.126.144.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73518226A for ; Fri, 11 Jul 2014 09:15:59 +0000 (UTC) Received: from mail-we0-f173.google.com ([74.125.82.173]) (using TLSv1) by eu1sys200aob124.postini.com ([207.126.147.11]) with SMTP ID DSNKU7+rNLTkEaqKpUiJqTS9NI16wynRBQvd@postini.com; Fri, 11 Jul 2014 09:16:00 UTC Received: by mail-we0-f173.google.com with SMTP id t60so776580wes.18 for ; Fri, 11 Jul 2014 02:15:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=NQI7Hj7N8tP+31ZLOHW5BNX5qBfqBjBEp2ZSpUTBDWU=; b=b4+2T+JNYBNcT/wwV+f5JydJ7BIlRu86cCM9+Lde/vR5euxQCsytydMv3tA9Xhh+VR EbTxqTdEoraXZl6XOu6X9z1PoWKjjskA1Aen6CR8qq4a9dhGH3aAKF4BF33OZOUEBCfA CrSx6M/3ojjtDz6+caKJFwy1euxEKml+R+pOCt2K8Wq2Jt9Qzp4CvVGZ2KzUQYf6qO5q 72TXlimPjn9E8KNcz9yXm8vihKP2cVGKRw0HrP+PC/IJ1zU/RjV7vD3R42jlL5ILSDNV 3dF0MDX+z4qB+ZnO0T5sRgiiVI+C4w/HHROo9v3oR9rRlxXA3aCy828+3RvKDOULjHuu jAew== X-Gm-Message-State: ALoCoQmQgLDHQrjqhy65mbXi5/CpYQIIMT/jVTlj/fhKlvqWpgYiRDV0sm/4FbyVMBRRqyhUr2iLPAl4ELtTV9PI/mvLoE6G4zF4YOA5OnkL4D7+1EFHbN6/1/wTKlg4Zp/zuL75iLor X-Received: by 10.180.104.40 with SMTP id gb8mr3199546wib.59.1405070132173; Fri, 11 Jul 2014 02:15:32 -0700 (PDT) X-Received: by 10.180.104.40 with SMTP id gb8mr3199411wib.59.1405070130759; Fri, 11 Jul 2014 02:15:30 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id fs17sm3927580wjc.6.2014.07.11.02.15.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jul 2014 02:15:30 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6B9FQ5R088626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Jul 2014 10:15:26 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6B9FQnW088625 for freebsd-arm@freebsd.org; Fri, 11 Jul 2014 10:15:26 +0100 (BST) (envelope-from mexas) Date: Fri, 11 Jul 2014 10:15:26 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407110915.s6B9FQnW088625@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: binutils on arm Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 09:16:01 -0000 binutils is clearly a show stopper on arm. Is anybody working on it? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 hasn't been touched for 5 months. Anybody knows if it builds on linux/armv6? Worth asking for help in https://sourceware.org/bugzilla/? Anton From owner-freebsd-arm@FreeBSD.ORG Fri Jul 11 11:03:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B96FD32A for ; Fri, 11 Jul 2014 11:03:39 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 552A82C18 for ; Fri, 11 Jul 2014 11:03:39 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id z12so873101wgg.0 for ; Fri, 11 Jul 2014 04:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xJSCBs9e5YN124BwLL4rLqf14VTLnMRmsyYNvL8oMKU=; b=dV3uhgTvIiLPMliTDOXHIsxbtjTOnqVvW+gga3IP07bYps9Gq5X8GQ/5YTcqjfSEdR mhqxisd0pmdSsmf6zHqExSPZn8ttDALuE3fIzL/NZc6aU7nGSqkA2zGJJHa3OVvJ0vOj cssQ/+ZX4FVkRszZgbDgAgOqxFybpafsDia2sfYhEzOLXGsrrWgeiC1i9UsZakjI89j9 iTaQ89AyKanZAlfF0Twu41SDQIhDOtNWP90Hr5EeTtkLN+Cx1jJYzN3ZBsCOBaG2CiRa SO+BfI8I6aPTAPYpfOGvzYDx43cKc2AwUHfaSEZNQ0ubAWZNG18xRm5ZA0LyIREYyoFJ ON8g== MIME-Version: 1.0 X-Received: by 10.180.10.98 with SMTP id h2mr4054589wib.29.1405076615972; Fri, 11 Jul 2014 04:03:35 -0700 (PDT) Received: by 10.194.16.6 with HTTP; Fri, 11 Jul 2014 04:03:35 -0700 (PDT) In-Reply-To: <201407110915.s6B9FQnW088625@mech-cluster241.men.bris.ac.uk> References: <201407110915.s6B9FQnW088625@mech-cluster241.men.bris.ac.uk> Date: Fri, 11 Jul 2014 13:03:35 +0200 Message-ID: Subject: Re: binutils on arm From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= To: mexas@bris.ac.uk Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 11:03:39 -0000 2014-07-11 11:15 GMT+02:00 Anton Shterenlikht : > binutils is clearly a show stopper on arm. > Is anybody working on it? > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 > hasn't been touched for 5 months. > Anybody knows if it builds on linux/armv6? > Worth asking for help in https://sourceware.org/bugzilla/? You should try the CFT from Andreas Tobler: http://lists.freebsd.org/pipermail/freebsd-arm/2014-May/008413.html From owner-freebsd-arm@FreeBSD.ORG Fri Jul 11 11:07:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7B1B400 for ; Fri, 11 Jul 2014 11:07:39 +0000 (UTC) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48A682C41 for ; Fri, 11 Jul 2014 11:07:39 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s6BB7VTS019148 for ; Fri, 11 Jul 2014 07:07:36 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <53BFC573.9030606@m5p.com> Date: Fri, 11 Jul 2014 07:07:31 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: binutils on arm References: <201407110915.s6B9FQnW088625@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201407110915.s6B9FQnW088625@mech-cluster241.men.bris.ac.uk> Content-Type: multipart/mixed; boundary="------------050905030606090909080408" 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]); Fri, 11 Jul 2014 07:07:37 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 11:07:39 -0000 This is a multi-part message in MIME format. --------------050905030606090909080408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/11/14 05:15, Anton Shterenlikht wrote: > binutils is clearly a show stopper on arm. > Is anybody working on it? > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 > hasn't been touched for 5 months. > Anybody knows if it builds on linux/armv6? > Worth asking for help in https://sourceware.org/bugzilla/? > > Anton > [...] I followed up on a hint in this email from the ports mailing list from the 12th of May: > Geoff Speicher geoff at sea-incorporated.com > Mon May 12 00:04:46 UTC 2014 > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > On Sun, May 11, 2014 at 5:41 PM, Geoff Speicher > wrote: > > > Actually, I have a question about ports/184327. This bug report asserts > > that ansidecl.h is an internal file necessary only to build the GNU > > toolchain and should not be installed by devel/binutils. However, binutils > > also installs bfd.h which happens to include ansidecl.h (at least, it does > > in v2.24). Therefore, the installed bfd.h is broken. This fact either > > contradicts the original assertion that ansidecl.h should not be installed, > > or else it implies that bfd.h should not be installed either. > > > > There was a third possibility that I had overlooked, and appears to be a > decent compromise: bfd.h doesn't actually need to directly include > ansidecl.h for anything that I can see, so if we patch the port to remove > the include directive then bfd.h is no longer broken and ports/184327 is > also satisfied. Any objections to this? and came up with the attached patches. I can compile and use binutils on the arm with these patches, although it is claimed that they result in a non-functioning "ld". I don't know. -- George --------------050905030606090909080408 Content-Type: text/x-patch; name="binutils.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="binutils.patch" Index: Makefile =================================================================== --- Makefile (revision 357979) +++ Makefile (working copy) @@ -3,6 +3,7 @@ PORTNAME= binutils PORTVERSION= 2.24 +PORTREVISION= 1 CATEGORIES= devel MASTER_SITES= ${MASTER_SITE_SOURCEWARE} MASTER_SITE_SUBDIR= binutils/releases @@ -75,5 +76,6 @@ @${FIND} -ds ${STAGEDIR}${PREFIX}/${CONFIGURE_TARGET} -type d | \ ${SED} -e 's,^${STAGEDIR}${PREFIX}/,@dirrm ,' >> ${TMPPLIST} ${RM} ${STAGEDIR}${PREFIX}/include/ansidecl.h + ${REINPLACE_CMD} '/#include "ansidecl.h"/d' ${STAGEDIR}${PREFIX}/include/bfd.h .include --------------050905030606090909080408 Content-Type: text/x-patch; name="gnulibiberty.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gnulibiberty.patch" Index: Makefile =================================================================== --- Makefile (revision 357979) +++ Makefile (working copy) @@ -2,8 +2,7 @@ # $FreeBSD$ PORTNAME= gnulibiberty -PORTVERSION= 2.19.1 -PORTREVISION= 2 +PORTVERSION= 2.24 CATEGORIES= devel MASTER_SITES= ${MASTER_SITE_SOURCEWARE} MASTER_SITE_SUBDIR= binutils/releases @@ -17,7 +16,7 @@ USES= gmake USE_BZIP2= yes -CONFIGURE_ARGS= --enable-install-libiberty +CONFIGURE_ARGS= --enable-install-libiberty=${PREFIX}/include GNU_CONFIGURE= yes CONFLICTS= freelibiberty-[0-9]* Index: distinfo =================================================================== --- distinfo (revision 357979) +++ distinfo (working copy) @@ -1,2 +1,2 @@ -SHA256 (binutils-2.19.1.tar.bz2) = 3e8225b4d7ace0a2039de752e11fd6922d3b89a7259a292c347391c4788739f6 -SIZE (binutils-2.19.1.tar.bz2) = 16245771 +SHA256 (binutils-2.24.tar.bz2) = e5e8c5be9664e7f7f96e0d09919110ab5ad597794f5b1809871177a0f0f14137 +SIZE (binutils-2.24.tar.bz2) = 22716802 Index: files/patch-Makefile.in =================================================================== --- files/patch-Makefile.in (revision 357979) +++ files/patch-Makefile.in (working copy) @@ -1,19 +1,28 @@ ---- Makefile.in.orig Thu Jul 24 15:51:49 2008 -+++ Makefile.in Mon Apr 6 09:05:19 2009 -@@ -348,11 +348,15 @@ - INSTALL_DEST = @INSTALL_DEST@ - install: install_to_$(INSTALL_DEST) install-subdir +--- Makefile.in.orig 2013-11-04 10:33:40.000000000 -0500 ++++ Makefile.in 2014-06-24 10:22:37.000000000 -0400 +@@ -349,11 +349,15 @@ + .PHONY: install install-strip + +## FreeBSD port removed this: otherwise, FreeBSD 6.x would end up installing +## in ${prefix}/lib/elf rather than ${prefix}/lib +## # This is tricky. Even though CC in the Makefile contains # multilib-specific flags, it's overridden by FLAGS_TO_PASS from the - # default multilib, so we have to take LIBCFLAGS into account as well, + # default multilib, so we have to take CFLAGS into account as well, # since it will be passed the multilib flags. --MULTIOSDIR = `$(CC) $(LIBCFLAGS) -print-multi-os-directory` -+##MULTIOSDIR = `$(CC) $(LIBCFLAGS) -print-multi-os-directory` +-MULTIOSDIR = `$(CC) $(CFLAGS) -print-multi-os-directory` ++##MULTIOSDIR = `$(CC) $(CFLAGS) -print-multi-os-directory` +MULTIOSDIR = . install_to_libdir: all - ${mkinstalldirs} $(DESTDIR)$(libdir)/$(MULTIOSDIR) - $(INSTALL_DATA) $(TARGETLIB) $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n + if test -n "${target_header_dir}"; then \ + ${mkinstalldirs} $(DESTDIR)$(libdir)/$(MULTIOSDIR); \ +@@ -361,7 +365,7 @@ + ( cd $(DESTDIR)$(libdir)/$(MULTIOSDIR) ; chmod 644 $(TARGETLIB)n ;$(RANLIB) $(TARGETLIB)n ); \ + mv -f $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB); \ + case "${target_header_dir}" in \ +- /*) thd=${target_header_dir};; \ ++ /*) thd=${target_header_dir}/libiberty;; \ + *) thd=${includedir}/${target_header_dir};; \ + esac; \ + ${mkinstalldirs} $(DESTDIR)$${thd}; \ Index: files/patch-configure =================================================================== --- files/patch-configure (revision 357979) +++ files/patch-configure (working copy) @@ -1,31 +1,11 @@ ---- configure.orig Fri Apr 7 02:01:25 2006 -+++ configure Tue Oct 10 13:00:57 2006 -@@ -5679,6 +5679,14 @@ +--- configure.orig 2013-11-08 05:13:49.000000000 -0500 ++++ configure 2014-06-24 10:08:53.000000000 -0400 +@@ -5507,7 +5507,7 @@ - fi + setobjs= + CHECK= +-target_header_dir= ++# target_header_dir= + if test -n "${with_target_subdir}"; then -+ -+else -+ -+ # Not a target library, so we set things up to run the test suite. -+ CHECK=really-check -+ -+fi -+ - # We may wish to install the target headers somewhere. - # Check whether --enable-install-libiberty or --disable-install-libiberty was given. - if test "${enable_install_libiberty+set}" = set; then -@@ -5701,13 +5709,6 @@ - ;; - esac - -- --else -- -- # Not a target library, so we set things up to run the test suite. -- CHECK=really-check -- --fi - - - + # We are being configured as a target library. AC_REPLACE_FUNCS --------------050905030606090909080408-- From owner-freebsd-arm@FreeBSD.ORG Fri Jul 11 14:23:21 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7E41EB6 for ; Fri, 11 Jul 2014 14:23:21 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E0C02EA7 for ; Fri, 11 Jul 2014 14:23:21 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6BENLKR085312 for ; Fri, 11 Jul 2014 14:23:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Date: Fri, 11 Jul 2014 14:23:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports Tree X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mexas@bris.ac.uk X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 14:23:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 mexas@bris.ac.uk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mexas@bris.ac.uk --- Comment #4 from mexas@bris.ac.uk --- Another patchset: http://lists.freebsd.org/pipermail/freebsd-arm/2014-May/008413.html Just to keep this all in one place. I'm building it right now. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jul 11 15:22:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E24DF4AC for ; Fri, 11 Jul 2014 15:22:20 +0000 (UTC) Received: from eu1sys200aog124.obsmtp.com (eu1sys200aog124.obsmtp.com [207.126.144.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 368E824A1 for ; Fri, 11 Jul 2014 15:22:18 +0000 (UTC) Received: from mail-wi0-f173.google.com ([209.85.212.173]) (using TLSv1) by eu1sys200aob124.postini.com ([207.126.147.11]) with SMTP ID DSNKU8ABE0ZC2PL9/aMruEtNmQR0vRdbgaId@postini.com; Fri, 11 Jul 2014 15:22:20 UTC Received: by mail-wi0-f173.google.com with SMTP id cc10so6488867wib.12 for ; Fri, 11 Jul 2014 08:21:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=GxqSniK12UUGQkR2YFP62q+q/rcpO23VCoBgNORtmjI=; b=hBubu21DwD6rl1Dk0x1/0kSlmlmqvTEaFmi/iaXef0/MQcfVFL2hpTnJGNVDb7zt9G GW92fGacxGPd303NvilL4aIZKpoNQz/tClVnDTyo2wMu++Fm429E1YZN5obYZgGRrVFR Wwi2E5FTyohdKxuEPuaSAfi5ZA6jDS/1gyjzdKeRFZmpUtVqmv9MyGxLQ+WlUDMQP4Kf dZ/QfrexT2mPFxf9qTYAHNFb77LPUsuhsIvKVuziGjcaTQVauN3Wl6A6rUY2qJxEcJJ9 uA1l7hH05jP4zrVIRJmKbA3mN4sYebSIfu97FVyja919mc+LviviG81LOhRTneIdxUun Ol+A== X-Gm-Message-State: ALoCoQmkxnn+W0KGe/P+KdOnanD0BVyNj/xc3g2KKZyLQ3xQ7QHjCjj8y6jm8hNFCeuGOJERoS9PRdk8MS/Fu5+pNYdJ3y3au+tqvml4CuxOL08Y1VJgmFyFgP66TyRCcWgGDvcV4bMO X-Received: by 10.194.173.7 with SMTP id bg7mr65093217wjc.3.1405092115651; Fri, 11 Jul 2014 08:21:55 -0700 (PDT) X-Received: by 10.194.173.7 with SMTP id bg7mr65093059wjc.3.1405092114257; Fri, 11 Jul 2014 08:21:54 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id jb16sm8513346wic.10.2014.07.11.08.21.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jul 2014 08:21:53 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6BFLoaV089418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Jul 2014 16:21:50 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6BFLorC089417 for freebsd-arm@freebsd.org; Fri, 11 Jul 2014 16:21:50 +0100 (BST) (envelope-from mexas) Date: Fri, 11 Jul 2014 16:21:50 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407111521.s6BFLorC089417@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: acpi_thermal(4) - not relevant for arm? Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 15:22:21 -0000 The RPi-B snapshot contains the man page for acpi_thermal(4) but since there is no ACPI, there are no hw.acpi sysctl variables. So, are there any other variables giving temperature on arm? Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Fri Jul 11 15:46:13 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E0502FB for ; Fri, 11 Jul 2014 15:46:13 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 143E02712 for ; Fri, 11 Jul 2014 15:46:13 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6BFkCMe010630 for ; Fri, 11 Jul 2014 15:46:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Date: Fri, 11 Jul 2014 15:46:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports Tree X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mexas@bris.ac.uk X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 15:46:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 --- Comment #5 from mexas@bris.ac.uk --- executable segfaults: $ cc -c z.c -Wall $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc $ file z z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for FreeBSD 10.0 (1000710), not stripped $ ldd ./z ./z: libc.so.7 => /lib/libc.so.7 (0x2003c000) $ ./z Segmentation fault (core dumped) $ $ pkg info -xo binu binutils-2.24 devel/binutils $ uname -a FreeBSD BOZO 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul 1 04:29:43 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm $ -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jul 11 15:51:25 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 262904D0 for ; Fri, 11 Jul 2014 15:51:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CC1E27C6 for ; Fri, 11 Jul 2014 15:51:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6BFpOcA022921 for ; Fri, 11 Jul 2014 15:51:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Date: Fri, 11 Jul 2014 15:51:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports Tree X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mexas@bris.ac.uk X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 15:51:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 --- Comment #6 from mexas@bris.ac.uk --- Forgot to say that this was with Andreas Tobler's patchset. Also, it segfaults with the OS default ld too: $ cat z.c #include int main(int argc, char **argv) { printf("mumu\n"); return 0; } $ cc -c z.c -Wall $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc $ ldd z z: libc.so.7 => /lib/libc.so.7 (0x2003c000) $ file z z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for FreBSD 10.0 (1000710), not stripped $ ./z Segmentation fault (core dumped) $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc $ ldd z z: libc.so.7 => /lib/libc.so.7 (0x2003c000) $ file z z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for FreBSD 10.0 (1000710), not stripped $ ./z Segmentation fault (core dumped) $ -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jul 11 15:53:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 886AF626 for ; Fri, 11 Jul 2014 15:53:11 +0000 (UTC) Received: from eu1sys200aog105.obsmtp.com (eu1sys200aog105.obsmtp.com [207.126.144.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB5C527E5 for ; Fri, 11 Jul 2014 15:53:10 +0000 (UTC) Received: from mail-we0-f173.google.com ([74.125.82.173]) (using TLSv1) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP ID DSNKU8AIXzN0r9PCyrbVXHGQzAiUYLY7dJcM@postini.com; Fri, 11 Jul 2014 15:53:10 UTC Received: by mail-we0-f173.google.com with SMTP id t60so1279932wes.32 for ; Fri, 11 Jul 2014 08:53:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=UOsbJ40Dgdrj+CrYiuQPKBIIPCAHo+7PW63jqVFmxTs=; b=b8OlqYF4f6Eo8AEzLDAkon4KDmnp032av7HMWriEzSDd87O90u085TqYRFOc/5QiWj DnObtH67yv3IxIRp85hhFrlNwHCfrKDJJoGQ3f1q2DwSQWdwrK6juw7uurchMVwmxlWN XeXWY33wyohAsEm+pYUygzczVETslhXpaTkOHJ7GY8YfA3dpxyhu5WrmomYZ2jqq1Nq3 E0TwOOtZAdXqwpRubhmG5xpktO03Vkxc99P8Aa4sfu1g6PPZvOHpgsL+PcqB+WzUfKE3 O6SlbH7DwnkCQLhEEsRhDf74NhySzs/tXHXAehHYaQ4ixS8JxlhyPDaoQQcelTr0KlR0 XR/g== X-Gm-Message-State: ALoCoQk+3+SkvkV1A3lKmEZnDcu3PHn4MkhCKMy9wTNUcArt4qU4HQgKzt+f5Z66LvWXKCecD9QvbNTwHhnrlGaLplkhw43bw86lNVhBchNwo5nG8Sv9q8Mp0LFXnOytyDEZx6clwt3v X-Received: by 10.180.81.68 with SMTP id y4mr6119589wix.26.1405093983237; Fri, 11 Jul 2014 08:53:03 -0700 (PDT) X-Received: by 10.180.81.68 with SMTP id y4mr6119570wix.26.1405093983119; Fri, 11 Jul 2014 08:53:03 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id cx5sm5952732wjb.8.2014.07.11.08.53.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jul 2014 08:53:02 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6BFqwYK089506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Jul 2014 16:52:58 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6BFqwbN089505; Fri, 11 Jul 2014 16:52:58 +0100 (BST) (envelope-from mexas) Date: Fri, 11 Jul 2014 16:52:58 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407111552.s6BFqwbN089505@mech-cluster241.men.bris.ac.uk> To: mexas@bris.ac.uk, mikael.urankar@gmail.com Subject: Re: binutils on arm Reply-To: mexas@bris.ac.uk In-Reply-To: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 15:53:11 -0000 >From mikael.urankar@gmail.com Fri Jul 11 12:42:41 2014 > >2014-07-11 11:15 GMT+02:00 Anton Shterenlikht : >> binutils is clearly a show stopper on arm. >> Is anybody working on it? >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 >> hasn't been touched for 5 months. >> Anybody knows if it builds on linux/armv6? >> Worth asking for help in https://sourceware.org/bugzilla/? > >You should try the CFT from Andreas Tobler: >http://lists.freebsd.org/pipermail/freebsd-arm/2014-May/008413.html segfault: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 From owner-freebsd-arm@FreeBSD.ORG Fri Jul 11 20:02:56 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CE706E7 for ; Fri, 11 Jul 2014 20:02:56 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6445F2151 for ; Fri, 11 Jul 2014 20:02:56 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6BK2uo4021485 for ; Fri, 11 Jul 2014 20:02:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Date: Fri, 11 Jul 2014 20:02:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports Tree X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: andreast@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 20:02:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 Andreas Tobler changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andreast@FreeBSD.org --- Comment #7 from Andreas Tobler --- To get the right linker command do this: (the -v is for verbose) andreast@wandquad:~ % cc -o z z.c -v Using built-in specs. Target: armv6-undermydesk-freebsd Configured with: FreeBSD/armv6 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] /usr/libexec/cc1 -quiet -v -D_LONGLONG z.c -quiet -dumpbase z.c -auxbase z -version -o /tmp//ccMJ520s.s #include "..." search starts here: #include <...> search starts here: /usr/include/gcc/4.2 /usr/include End of search list. GNU C version 4.2.1 20070831 patched [FreeBSD] (armv6-undermydesk-freebsd) compiled by GNU C version 4.2.1 20070831 patched [FreeBSD]. GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=130664 Compiler executable checksum: 20743f84b7aef1f094db166caa2fbdf7 /usr/bin/as -mfpu=softvfp -meabi=4 -o /tmp//ccNNWzRe.o /tmp//ccMJ520s.s /usr/bin/ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -X -o z /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -L/usr/lib /tmp//ccNNWzRe.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o GNU ld 2.17.50 [FreeBSD] 2007-07-03 Supported emulations: armelf_fbsd -->> Then build only the z.o: andreast@wandquad:~ % cc -c z.c -v Using built-in specs. Target: armv6-undermydesk-freebsd Configured with: FreeBSD/armv6 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] /usr/libexec/cc1 -quiet -v -D_LONGLONG z.c -quiet -dumpbase z.c -auxbase z -version -o /tmp//ccoqB09j.s #include "..." search starts here: #include <...> search starts here: /usr/include/gcc/4.2 /usr/include End of search list. GNU C version 4.2.1 20070831 patched [FreeBSD] (armv6-undermydesk-freebsd) compiled by GNU C version 4.2.1 20070831 patched [FreeBSD]. GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=130664 Compiler executable checksum: 20743f84b7aef1f094db166caa2fbdf7 /usr/bin/as -mfpu=softvfp -meabi=4 -o z.o /tmp//ccoqB09j.s --> And last, link the z.o to z: andreast@wandquad:~ % /build/gdb/testbin_armv6/bin/ld -V -Bstatic -X -o z /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o -L/usr/lib z.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/crtend.o /usr/lib/crtn.o GNU ld (GNU Binutils) 2.24.51.20140706 Supported emulations: armelf_fbsd armelfb_fbsd armelf andreast@wandquad:~ % ./z mumu Doesn't matter if static or dynamic, at least for me. And I'm on current. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 00:16:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DB1D4EE for ; Sat, 12 Jul 2014 00:16:51 +0000 (UTC) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFDB32736 for ; Sat, 12 Jul 2014 00:16:50 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s6C0GhMH024703 for ; Fri, 11 Jul 2014 20:16:48 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <53C07E6B.9040303@m5p.com> Date: Fri, 11 Jul 2014 20:16:43 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi References: In-Reply-To: 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]); Fri, 11 Jul 2014 20:16:48 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 00:16:51 -0000 On 07/11/14 11:51, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 > > --- Comment #6 from mexas@bris.ac.uk --- > Forgot to say that this was with Andreas Tobler's patchset. > Also, it segfaults with the OS default ld too: > > $ cat z.c > #include > int main(int argc, char **argv) > { > printf("mumu\n"); > return 0; > } > $ cc -c z.c -Wall > $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc > $ ldd z > z: > libc.so.7 => /lib/libc.so.7 (0x2003c000) > $ file z > z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses > shared libs), for FreBSD 10.0 (1000710), not stripped > $ ./z > Segmentation fault (core dumped) > $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc > $ ldd z > z: > libc.so.7 => /lib/libc.so.7 (0x2003c000) > $ file z > z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses > shared libs), for FreBSD 10.0 (1000710), not stripped > $ ./z > Segmentation fault (core dumped) > $ > Why are you using this strange invocation of the linker? If I run "cc -v -o z z.c", here is how it invokes ld: "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o z /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o The resulting program runs without difficulty. -- George From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 13:14:03 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF4D8AC5 for ; Sat, 12 Jul 2014 13:14:03 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [84.201.143.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1F521CF for ; Sat, 12 Jul 2014 13:14:02 +0000 (UTC) Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [37.140.190.29]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 8E1CB1A40F05 for ; Sat, 12 Jul 2014 17:13:53 +0400 (MSK) Received: from smtp4o.mail.yandex.net (localhost [127.0.0.1]) by smtp4o.mail.yandex.net (Yandex) with ESMTP id 411DD2322722 for ; Sat, 12 Jul 2014 17:13:53 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Dq9rymqecF-DqoeSvpQ; Sat, 12 Jul 2014 17:13:52 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 61991641-a881-419c-91a4-e2cfdd2a9803 Message-ID: <53C1348E.1000801@passap.ru> Date: Sat, 12 Jul 2014 17:13:50 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: [make xdev] cc1plus: error: unrecognized command line option "-std=c++0x" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 13:14:03 -0000 Hi All, I try to build cross development tools for crochet build: ----- % uname -a FreeBSD bsam.int.wart.ru 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r268566: Sat Jul 12 16:12:58 SAMT 2014 bsam@bsam.int.wart.ru:/usr/obj/usr/src/sys/BB64X amd64 % sudo make -C /usr/src XDEV=arm XDEV_ARCH=armv6 WITH_GCC=1 WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 WITHOUT_CLANG_IS_CC=1 xdev [...] ===> lib/libc++ (depend) rm -f .depend CC='cc -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a -I/usr/src/lib/libc++/../../contrib/libc++/include -I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT -std=c++0x /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp /usr/src/lib/libc++/../../contrib/libc++/src/bind.cpp /usr/src/lib/libc++/../../contrib/libc++/src/chrono.cpp /usr/src/lib/libc++/../../contrib/libc++/src/condition_variable.cpp /usr/src/lib/libc++/../../contrib/libc++/src/debug.cpp /usr/src/lib/libc++/../../contrib/libc++/src/exception.cpp /usr/src/lib/libc++/../../contrib/libc++/src/future.cpp /usr/src/lib/libc++/../../contrib/libc++/src/hash.cpp /usr/src/lib/libc++/../../contrib/libc++/src/ios.cpp /usr/src/lib/libc++/../../contrib/libc++/src/iostream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp /usr/src/lib/libc++/../../contrib/libc++/src/memory.cpp /usr/src/lib/libc++/../../contrib/libc++/src/mutex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/new.cpp /usr/src/lib/libc++/../../contrib/libc++/src/optional.cpp /usr/src/lib/libc++/../../contrib/libc++/src/random.cpp /usr/src/lib/libc++/../../contrib/libc++/src/regex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/shared_mutex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/stdexcept.cpp /usr/src/lib/libc++/../../contrib/libc++/src/string.cpp /usr/src/lib/libc++/../../contrib/libc++/src/strstream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp /usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp /usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp /usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp cc1plus: error: unrecognized command line option "-std=c++0x" [...] mkdep: compile failed *** Error code 1 Stop. make[5]: stopped in /usr/src/lib/libc++ ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 14:00:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2991228 for ; Sat, 12 Jul 2014 14:00:36 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E11724E1 for ; Sat, 12 Jul 2014 14:00:35 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s6CDoi6f053941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 12 Jul 2014 15:50:45 +0200 (CEST) (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 s6CDoegG025038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jul 2014 15:50:40 +0200 (CEST) (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 s6CDoedV035197; Sat, 12 Jul 2014 15:50:40 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s6CDod8v035196; Sat, 12 Jul 2014 15:50:39 +0200 (CEST) (envelope-from ticso) Date: Sat, 12 Jul 2014 15:50:39 +0200 From: Bernd Walter To: Boris Samorodov Subject: Re: [make xdev] cc1plus: error: unrecognized command line option "-std=c++0x" Message-ID: <20140712135039.GB35142@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <53C1348E.1000801@passap.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53C1348E.1000801@passap.ru> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 14:00:36 -0000 On Sat, Jul 12, 2014 at 05:13:50PM +0400, Boris Samorodov wrote: > Hi All, > > I try to build cross development tools for crochet build: > ----- > % uname -a > FreeBSD bsam.int.wart.ru 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r268566: > Sat Jul 12 16:12:58 SAMT 2014 > bsam@bsam.int.wart.ru:/usr/obj/usr/src/sys/BB64X amd64 > > % sudo make -C /usr/src XDEV=arm XDEV_ARCH=armv6 WITH_GCC=1 > WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 > WITHOUT_CLANG_IS_CC=1 xdev > [...] > ===> lib/libc++ (depend) > rm -f .depend > CC='cc -isystem //usr/armv6-freebsd/usr/include > -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6-freebsd/ > -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin > -B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a > -I/usr/src/lib/libc++/../../contrib/libc++/include > -I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT -std=c++0x > /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/bind.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/chrono.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/condition_variable.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/debug.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/exception.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/future.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/hash.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/ios.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/iostream.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/memory.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/mutex.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/new.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/optional.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/random.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/regex.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/shared_mutex.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/stdexcept.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/string.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/strstream.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp > cc1plus: error: unrecognized command line option "-std=c++0x" This should be "-std=c++11" with newer compiler. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 15:24:12 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D296A753 for ; Sat, 12 Jul 2014 15:24:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1AC92B7E for ; Sat, 12 Jul 2014 15:24:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6CFOCuw090699 for ; Sat, 12 Jul 2014 15:24:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Date: Sat, 12 Jul 2014 15:24:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports Tree X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mexas@bris.ac.uk X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 15:24:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605 --- Comment #8 from mexas@bris.ac.uk --- Now I'm confused even further. Your cc is GCC, whereas mine is clang: $ cc -o z z.c -v FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: armv6--freebsd10.0-gnueabi Thread model: posix Selected GCC installation: "/usr/bin/cc" -cc1 -triple armv6--freebsd10.0-gnueabi -S -disable-free -disable-ll vm-verifier -main-file-name z.c -mrelocation-model static -mdisable-fp-elim -mconst ructor-aliases -target-cpu arm1136jf-s -target-feature +soft-float -target-feature +soft-float-abi -target-feature -neon -target-abi aapcs-linux -msoft-float -mfloat- abi soft -v -resource-dir /usr/bin/../lib/clang/3.4.1 -fno-dwarf-directory-asm -fde bug-compilation-dir /usr/home/mexas -ferror-limit 19 -fmessage-length 0 -mstackreal ign -fno-signed-char -fobjc-runtime=gnustep -fdiagnostics-show-option -vectorize-sl p -o /tmp/z-900faf.s -x c z.c clang -cc1 version 3.4.1 based upon LLVM 3.4.1 default target armv6-gnueabi-freebsd 10.0 ignoring nonexistent directory "/usr/bin/../lib/clang/3.4.1/include" #include "..." search starts here: #include <...> search starts here: /usr/include/clang/3.4.1 /usr/include End of search list. "/usr/bin/as" -mfpu=softvfp -meabi=5 -o /tmp/z-669589.o /tmp/z-900faf.s "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=bot h --enable-new-dtags -o z /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/us r/lib /tmp/z-669589.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-neede d -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o Clearly I need to build binutils first, before I can build GCC, right? Anyway, your other instructions helped. I could compile z.c into z.o and link it like this: /usr/local/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o z /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib z.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o $ ./z mumu $ So I'd say your patchset should be committed. Many thanks Anton -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 19:11:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C5DECCC for ; Sat, 12 Jul 2014 19:11:06 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D37A2BA9 for ; Sat, 12 Jul 2014 19:11:05 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id cc10so767581wib.6 for ; Sat, 12 Jul 2014 12:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mo4lODU0YN5e7NPjww3xuDQJBU5sNRcf7xEq2yx+oyI=; b=CZ7hBD0hcJbgSO4ADK9cDu+1rctbdRT6ZQIfs3ZHmjVKrNd95lAyCJ2auB4Oar3jEf lxE1QV+XA6q9pjllFHhRhDNZ8lYNe0l25EoIvGmikKTUNDizcPbbNGiQHAfQcpIEkMSi /82wUYbbozQ6NjbvbqrxwrQZeWiZhZwlGcG/35dCjdo9p3+c3xD6xdhkrfvSeHrpvoqD iD9gPS+kiF8QYsEkzZFOzLudqZIGR9yB+laxdKlhiZ9cIJ1lvtHfyhWHO71svdWE1CyA 0vKFs31PrnvyIgpGBOvm1Zhz6UWgfQakN5O1wa+S7jIlGcy8iI4k4FVYzc6XaVsQW3v4 aSbA== MIME-Version: 1.0 X-Received: by 10.181.8.204 with SMTP id dm12mr13969379wid.67.1405192263756; Sat, 12 Jul 2014 12:11:03 -0700 (PDT) Received: by 10.194.16.6 with HTTP; Sat, 12 Jul 2014 12:11:03 -0700 (PDT) In-Reply-To: <201407111521.s6BFLorC089417@mech-cluster241.men.bris.ac.uk> References: <201407111521.s6BFLorC089417@mech-cluster241.men.bris.ac.uk> Date: Sat, 12 Jul 2014 21:11:03 +0200 Message-ID: Subject: Re: acpi_thermal(4) - not relevant for arm? From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= To: mexas@bris.ac.uk Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 19:11:06 -0000 2014-07-11 17:21 GMT+02:00 Anton Shterenlikht : > The RPi-B snapshot contains the man page for acpi_thermal(4) > but since there is no ACPI, there are no hw.acpi sysctl > variables. So, are there any other variables giving > temperature on arm? You can get the temperature of the RPi with the vchiq stuff (https://github.com/gonzoua/vchiq-freebsd and https://github.com/gonzoua/userland): root@raspberry-pi:/opt/vc/bin/vcgencmd measure_temp temp=48.7'C From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 19:28:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7310F91 for ; Sat, 12 Jul 2014 19:28:00 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A52072CF2 for ; Sat, 12 Jul 2014 19:28:00 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s6CJRqCL088892 for freebsd-arm@freebsd.org; Sat, 12 Jul 2014 19:27:52 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id hk3r3m6usbppvgzukgtpafhtke; for freebsd-arm@freebsd.org; Sat, 12 Jul 2014 19:27:51 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Impressive CPU usage Message-Id: <64FC570A-8FAF-4366-A9CA-6F91EBB6739B@freebsd.org> Date: Sat, 12 Jul 2014 12:27:51 -0700 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 19:28:00 -0000 While building the git port on my BeagleBone Black: last pid: 87645; load averages: 1.05, 0.93, 0.72 up 0+13:15:47 = 19:24:42 19 processes: 2 running, 17 sleeping CPU: 68.4% user, 0.0% nice, 28.5% system, 3.0% interrupt, 0.0% idle Mem: 57M Active, 352M Inact, 77M Wired, 1804K Cache, 67M Buf, 4280K Free Swap:=20 PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU = COMMAND 87645 root 1 69 0 44792K 33288K RUN 0:02 1777.13% cc 87644 root 1 8 0 35336K 22832K wait 0:00 107.14% cc 87633 root 1 40 0 11568K 3056K RUN 0:00 0.84% top 87564 root 1 8 0 10304K 1932K wait 0:01 0.53% gmake 677 root 1 40 0 18880K 5136K select 0:16 0.04% sshd For the record: root@beaglebone:~ # uname -a FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r266929: Sun Jun = 1 00:29:41 PDT 2014 = root@thinkpad:/usr/home/tim/crochet-freebsd/work/obj/arm.armv6/usr/src/sys= /BEAGLEBONE arm From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 19:44:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33459204 for ; Sat, 12 Jul 2014 19:44:06 +0000 (UTC) Received: from eu1sys200aog101.obsmtp.com (eu1sys200aog101.obsmtp.com [207.126.144.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86A282E22 for ; Sat, 12 Jul 2014 19:44:04 +0000 (UTC) Received: from mail-wi0-f175.google.com ([209.85.212.175]) (using TLSv1) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKU8GP5ExAJ6HhlpwuY4lroT9yrN+eYWfp@postini.com; Sat, 12 Jul 2014 19:44:05 UTC Received: by mail-wi0-f175.google.com with SMTP id ho1so789765wib.8 for ; Sat, 12 Jul 2014 12:43:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to :in-reply-to; bh=Ei9i8POd+CENLlTIZRUGUSirFK7n8fyUtXxl9qgq9Xc=; b=R0XvFfrh1YPmCN833Uf1lLRnhamhg+ao6YDL07BZ2asm5w4ZNAJQ2q7ibq0w0d/LsA vTSgN6tZC2Q/2U5Z/uZn0kis2FCAS3eS5Ec5rjkVG25a+ol87Rn8Ldvuzyt6Af4gDfPV ijnQFgaM8eYsdhd97gTLfLK0FyBrjiJIHlr2VEBeGjR68D9ikJv0I+s9KoSS/9EygT57 AYzTivNQNg6ISU6avo8fAsWWlQbxzjwxMBUC0QoE0n2uIK6qUjDBTC8rTsX1HH4so1cq ugx2soN351BweAhcjm1SAqhjgXM2Bvm68mtMBDDah6/I3iMuwwEtApZ1rvyPxXSRchvC FuQA== X-Gm-Message-State: ALoCoQlEWMxlshvRxtjVeAi5JfT74qlm9+pJRJMyA9L3Zr/hezqPK25Jk7W3q0cBL7gd0jBZTq8KIVsfiEfwSk6aYafRASCCL2jbLcLZMTpHx0Rdje0o55XKxWaxncl/QnYdd4LKNXtA X-Received: by 10.194.185.238 with SMTP id ff14mr8231040wjc.9.1405194212191; Sat, 12 Jul 2014 12:43:32 -0700 (PDT) X-Received: by 10.194.185.238 with SMTP id ff14mr8231037wjc.9.1405194212115; Sat, 12 Jul 2014 12:43:32 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id nc19sm10044098wic.4.2014.07.12.12.43.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Jul 2014 12:43:31 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6CJhUUl097910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Jul 2014 20:43:30 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6CJhT2p097909; Sat, 12 Jul 2014 20:43:29 +0100 (BST) (envelope-from mexas) Date: Sat, 12 Jul 2014 20:43:29 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407121943.s6CJhT2p097909@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org, george+freebsd@m5p.com Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Reply-To: mexas@bris.ac.uk In-Reply-To: <53C07E6B.9040303@m5p.com> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 19:44:06 -0000 >> --- Comment #6 from mexas@bris.ac.uk --- >> Forgot to say that this was with Andreas Tobler's patchset. >> Also, it segfaults with the OS default ld too: >> >> $ cat z.c >> #include >> int main(int argc, char **argv) >> { >> printf("mumu\n"); >> return 0; >> } >> $ cc -c z.c -Wall >> $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >> $ ldd z >> z: >> libc.so.7 => /lib/libc.so.7 (0x2003c000) >> $ file z >> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >> shared libs), for FreBSD 10.0 (1000710), not stripped >> $ ./z >> Segmentation fault (core dumped) >> $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >> $ ldd z >> z: >> libc.so.7 => /lib/libc.so.7 (0x2003c000) >> $ file z >> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >> shared libs), for FreBSD 10.0 (1000710), not stripped >> $ ./z >> Segmentation fault (core dumped) >> $ >> >Why are you using this strange invocation of the linker? If I run >"cc -v -o z z.c", here is how it invokes ld: > > "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 >--hash-style=both --enable-new-dtags -o z /usr/lib/crt1.o >/usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o -lgcc >--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s >--no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o > >The resulting program runs without difficulty. -- George well, I copied my invocation from: http://people.freebsd.org/~rene/patches/binutils-rpi-bug.txt but you are right. I have now did just the same using /usr/local/bin/ld, and the executable worked. So probably Andreas Tobler's patchset should be committed? I'm building lang/gcc right now, will see how it goes. Anton From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 19:44:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76BE1242 for ; Sat, 12 Jul 2014 19:44:33 +0000 (UTC) Received: from eu1sys200aog122.obsmtp.com (eu1sys200aog122.obsmtp.com [207.126.144.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB1412E27 for ; Sat, 12 Jul 2014 19:44:32 +0000 (UTC) Received: from mail-wg0-f46.google.com ([74.125.82.46]) (using TLSv1) by eu1sys200aob122.postini.com ([207.126.147.11]) with SMTP ID DSNKU8GQGZK3keB1B1wrh3nD6v1GK/x+a81b@postini.com; Sat, 12 Jul 2014 19:44:32 UTC Received: by mail-wg0-f46.google.com with SMTP id m15so2503730wgh.17 for ; Sat, 12 Jul 2014 12:44:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=4qyaCqOG48U0qInlmzO+TXtIY0mydbgDICsSqPBicrI=; b=VPKmLgvw+pWCCLsCA5xL0+Psc4lwlqECo+2wR+xrRkQ+o5suY8yDfQ+0TlqsgnuOLh w61FNrguZLhNjelfl+wOo4e5ei00VA/zNX6RF16g/1cI9wSSxmvwNNeGl4iv/2y/K3eh iOV57s5EXaOcIrpELnd6/wNs/AjwxDJhnlIJF/DWByMT5nJD7igSshu/cfdl46ceCx3x yq5Lwf+xMw0n8HDX934EE1z5GR9eoervYqKZWMNkpZEtPzLjane7do90s2AjZ7ZR/q3t XeUE09QGoIaEAI57tMRC4yOmuGUpYbxVxsaGoxUsyzklDErtRigg31e5E65DFUDXUFh7 4l5w== X-Received: by 10.194.1.164 with SMTP id 4mr8063687wjn.17.1405193870753; Sat, 12 Jul 2014 12:37:50 -0700 (PDT) X-Gm-Message-State: ALoCoQlnoTuXc04Roo09Iobd7nU/0OEm5mk7QPPKvzdW4+JQ+hI6OLDSgn03APZGFDmTZwRVXCUfx0xAmIb2ujP6XeqP7EPHXadXf6At+4xU6jl1/QNMWEsuVPzjPAICeoSwdNMSssZf X-Received: by 10.194.1.164 with SMTP id 4mr8063679wjn.17.1405193870676; Sat, 12 Jul 2014 12:37:50 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id o2sm9952450wia.16.2014.07.12.12.37.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Jul 2014 12:37:50 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6CJbm0W097892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Jul 2014 20:37:48 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6CJbmQX097891; Sat, 12 Jul 2014 20:37:48 +0100 (BST) (envelope-from mexas) Date: Sat, 12 Jul 2014 20:37:48 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407121937.s6CJbmQX097891@mech-cluster241.men.bris.ac.uk> To: mexas@bris.ac.uk, mikael.urankar@gmail.com Subject: Re: acpi_thermal(4) - not relevant for arm? Reply-To: mexas@bris.ac.uk In-Reply-To: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 19:44:33 -0000 >From mikael.urankar@gmail.com Sat Jul 12 20:11:52 2014 > >2014-07-11 17:21 GMT+02:00 Anton Shterenlikht : >> The RPi-B snapshot contains the man page for acpi_thermal(4) >> but since there is no ACPI, there are no hw.acpi sysctl >> variables. So, are there any other variables giving >> temperature on arm? > >You can get the temperature of the RPi with the vchiq stuff >(https://github.com/gonzoua/vchiq-freebsd and >https://github.com/gonzoua/userland): >root@raspberry-pi:/opt/vc/bin/vcgencmd measure_temp >temp=48.7'C > ok thanks. So the port contains "ARM side code to interface to: EGL, mmal, GLESv2, vcos, openmaxil, vchiq_arm, bcm_host, WFC, OpenVG." Is there any easy introduction to these? Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 19:59:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B2633D7; Sat, 12 Jul 2014 19:59:50 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 040AE2EDB; Sat, 12 Jul 2014 19:59:48 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s6CJYXNx044417; Sat, 12 Jul 2014 21:34:41 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53C18DC9.2020205@fgznet.ch> Date: Sat, 12 Jul 2014 21:34:33 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Kientzle , freebsd-arm Subject: Re: Impressive CPU usage References: <64FC570A-8FAF-4366-A9CA-6F91EBB6739B@freebsd.org> In-Reply-To: <64FC570A-8FAF-4366-A9CA-6F91EBB6739B@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 19:59:50 -0000 On 12.07.14 21:27, Tim Kientzle wrote: > While building the git port on my BeagleBone Black: > > > last pid: 87645; load averages: 1.05, 0.93, 0.72 up 0+13:15:47 > 19:24:42 19 processes: 2 running, 17 sleeping CPU: 68.4% user, 0.0% > nice, 28.5% system, 3.0% interrupt, 0.0% idle Mem: 57M Active, 352M > Inact, 77M Wired, 1804K Cache, 67M Buf, 4280K Free Swap: > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU > COMMAND 87645 root 1 69 0 44792K 33288K RUN 0:02 > 1777.13% cc 87644 root 1 8 0 35336K 22832K wait > 0:00 107.14% cc 87633 root 1 40 0 11568K 3056K RUN > 0:00 0.84% top 87564 root 1 8 0 10304K 1932K wait > 0:01 0.53% gmake 677 root 1 40 0 18880K 5136K select > 0:16 0.04% sshd > > > For the record: > > root@beaglebone:~ # uname -a FreeBSD beaglebone 11.0-CURRENT FreeBSD > 11.0-CURRENT #0 r266929: Sun Jun 1 00:29:41 PDT 2014 > root@thinkpad:/usr/home/tim/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE > arm +1: andreast@wandquad:~ % uname -ra FreeBSD wandquad 11.0-CURRENT FreeBSD 11.0-CURRENT #12 r268501M: Thu Jul 10 21:02:32 CEST 2014 andreast@tcx58.andreas.nets:/usr/obj/arm.armv6/export/devel/fbsd/src/sys/WANDQUAD arm last pid: 30275; load averages: 8.51, 7.73, 5.25 up 2+00:19:10 21:32:22 50 processes: 9 running, 41 sleeping CPU: 71.2% user, 0.0% nice, 18.8% system, 9.9% interrupt, 0.2% idle Mem: 233M Active, 260M Inact, 159M Wired, 244K Cache, 114M Buf, 1349M Free Swap: 4096M Total, 4096M Free PID UID THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 30214 0 1 88 0 92960K 80676K CPU2 2 84:48 72432.14% cc1plus 30251 0 1 79 0 52408K 41180K CPU1 1 32:36 72425.26% cc1plus 30274 0 1 74 0 22424K 14368K RUN 0 13:02 72410.40% cc1plus 30257 0 1 78 0 48280K 36688K RUN 1 19:34 36229.29% cc1plus 30271 0 1 74 0 26544K 16940K CPU3 3 13:02 36220.42% cc1plus From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 20:01:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EE3F426 for ; Sat, 12 Jul 2014 20:01:10 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 136612F52 for ; Sat, 12 Jul 2014 20:01:09 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s6CK14UE063704; Sat, 12 Jul 2014 22:01:05 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53C19400.6050404@fgznet.ch> Date: Sat, 12 Jul 2014 22:01:04 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mexas@bris.ac.uk, freebsd-arm@freebsd.org, george+freebsd@m5p.com Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi References: <201407121943.s6CJhT2p097909@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201407121943.s6CJhT2p097909@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 20:01:10 -0000 On 12.07.14 21:43, Anton Shterenlikht wrote: >>> --- Comment #6 from mexas@bris.ac.uk --- >>> Forgot to say that this was with Andreas Tobler's patchset. >>> Also, it segfaults with the OS default ld too: >>> >>> $ cat z.c >>> #include >>> int main(int argc, char **argv) >>> { >>> printf("mumu\n"); >>> return 0; >>> } >>> $ cc -c z.c -Wall >>> $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>> $ ldd z >>> z: >>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>> $ file z >>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>> shared libs), for FreBSD 10.0 (1000710), not stripped >>> $ ./z >>> Segmentation fault (core dumped) >>> $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>> $ ldd z >>> z: >>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>> $ file z >>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>> shared libs), for FreBSD 10.0 (1000710), not stripped >>> $ ./z >>> Segmentation fault (core dumped) >>> $ >>> >> Why are you using this strange invocation of the linker? If I run >> "cc -v -o z z.c", here is how it invokes ld: >> >> "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 >> --hash-style=both --enable-new-dtags -o z /usr/lib/crt1.o >> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o -lgcc >> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s >> --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o >> >> The resulting program runs without difficulty. -- George > > well, I copied my invocation from: > http://people.freebsd.org/~rene/patches/binutils-rpi-bug.txt > > but you are right. I have now did just the same > using /usr/local/bin/ld, and the executable worked. > > So probably Andreas Tobler's patchset should > be committed? > > I'm building lang/gcc right now, will see how it goes. You can save the time for gcc. Nothing else than the system gcc works. I do some work on gcc-4.10 and it is hairy. I can bootstrap gcc-4.10 but I have some issues with tls which blocks me to come out with my patch set. The overall view is good. I even have C++ exceptions working with EABI. Also, the binutils patch set is not satisfying for me. I do not have feedback for arm*b nor for arm* < FreeBSD 10.0. And last but not least, my time slot is shrinking, summer holidays ;) Anton, thanks for your testing and feedback. Andreas From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 20:28:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C283674 for ; Sat, 12 Jul 2014 20:28:50 +0000 (UTC) Received: from eu1sys200aog107.obsmtp.com (eu1sys200aog107.obsmtp.com [207.126.144.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DBC620E3 for ; Sat, 12 Jul 2014 20:28:48 +0000 (UTC) Received: from mail-wg0-f47.google.com ([74.125.82.47]) (using TLSv1) by eu1sys200aob107.postini.com ([207.126.147.11]) with SMTP ID DSNKU8GaePsseQecBKIizBJJFbbYV2Q+uNRb@postini.com; Sat, 12 Jul 2014 20:28:49 UTC Received: by mail-wg0-f47.google.com with SMTP id b13so402279wgh.18 for ; Sat, 12 Jul 2014 13:28:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to :in-reply-to; bh=lBCGWaHTn5G9czUsidgSmX6HhvSfokkUiM8jY/MDtF4=; b=cEohet6S21YPR+vKt+H8Y7NAu3f9Iq1neAZU17noN3CRxrT7BGDAo4wugniugyfrwX OmkFDdtkOA4vzTYvD9JdCfa/0CHbGM0J1EFY0F5VLGApkFSkeiwF2/yHc5Fsrq8eua++ D5eWp4S8uWkbxFRIQlrGepHolkbBMWRPDwuxAG5qSoHG2+vfl5upLkSb2UB/nmyqfTPM iigwsEZ97QW+I8mO2lrPQrOzujn+I2YmDTbzm5luuuOkSKrKvLa/iEbHuYzyKtjilfiu A5fzaolAiXQyBcZ4Ylo095GdGREVXJ87Vy+bPnz5wB+Un5RDxkBHyM9qMathb1Eox1lP d+mw== X-Gm-Message-State: ALoCoQlnhUI+Mt6CF1qHBPbO63E66eydI5DkHmgo1EWxkNTLkCNc7l9gcqTGNFkU65X1xxdaxl3u8Nr/yTsuIecMnfvdToTWagfOuPQjJ5J48XKrr5SUHE3uo/4K/50IiWdJdsA00hf0 X-Received: by 10.194.84.101 with SMTP id x5mr8449793wjy.52.1405196920910; Sat, 12 Jul 2014 13:28:40 -0700 (PDT) X-Received: by 10.194.84.101 with SMTP id x5mr8449780wjy.52.1405196920819; Sat, 12 Jul 2014 13:28:40 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id x3sm10396460wia.11.2014.07.12.13.28.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Jul 2014 13:28:40 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6CKScDV098049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Jul 2014 21:28:39 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6CKSch3098048; Sat, 12 Jul 2014 21:28:38 +0100 (BST) (envelope-from mexas) Date: Sat, 12 Jul 2014 21:28:38 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407122028.s6CKSch3098048@mech-cluster241.men.bris.ac.uk> To: andreast-list@fgznet.ch, freebsd-arm@freebsd.org, george+freebsd@m5p.com, mexas@bris.ac.uk Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Reply-To: mexas@bris.ac.uk In-Reply-To: <53C19400.6050404@fgznet.ch> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 20:28:50 -0000 >From andreast-list@fgznet.ch Sat Jul 12 21:07:05 2014 >On 12.07.14 21:43, Anton Shterenlikht wrote: >>>> --- Comment #6 from mexas@bris.ac.uk --- >>>> Forgot to say that this was with Andreas Tobler's patchset. >>>> Also, it segfaults with the OS default ld too: >>>> >>>> $ cat z.c >>>> #include >>>> int main(int argc, char **argv) >>>> { >>>> printf("mumu\n"); >>>> return 0; >>>> } >>>> $ cc -c z.c -Wall >>>> $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>> $ ldd z >>>> z: >>>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>>> $ file z >>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>> $ ./z >>>> Segmentation fault (core dumped) >>>> $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>> $ ldd z >>>> z: >>>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>>> $ file z >>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>> $ ./z >>>> Segmentation fault (core dumped) >>>> $ >>>> >>> Why are you using this strange invocation of the linker? If I run >>> "cc -v -o z z.c", here is how it invokes ld: >>> >>> "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 >>> --hash-style=both --enable-new-dtags -o z /usr/lib/crt1.o >>> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o -lgcc >>> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s >>> --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o >>> >>> The resulting program runs without difficulty. -- George >> >> well, I copied my invocation from: >> http://people.freebsd.org/~rene/patches/binutils-rpi-bug.txt >> >> but you are right. I have now did just the same >> using /usr/local/bin/ld, and the executable worked. >> >> So probably Andreas Tobler's patchset should >> be committed? >> >> I'm building lang/gcc right now, will see how it goes. > >You can save the time for gcc. Nothing else than the system gcc works. Sorry, I still don't get you. What is the "system gcc"? I thought the system C compiler is clang, in 10-stable and above. I'm not intersted in gcc itself. I just want to build xorg-server. Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 20:39:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 819B3935 for ; Sat, 12 Jul 2014 20:39:15 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 109B62193 for ; Sat, 12 Jul 2014 20:39:13 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s6CKd8fA039060; Sat, 12 Jul 2014 22:39:09 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53C19CEC.7080101@fgznet.ch> Date: Sat, 12 Jul 2014 22:39:08 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mexas@bris.ac.uk, freebsd-arm@freebsd.org, george+freebsd@m5p.com Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi References: <201407122028.s6CKSch3098048@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201407122028.s6CKSch3098048@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 20:39:15 -0000 On 12.07.14 22:28, Anton Shterenlikht wrote: >>From andreast-list@fgznet.ch Sat Jul 12 21:07:05 2014 >> On 12.07.14 21:43, Anton Shterenlikht wrote: >>>>> --- Comment #6 from mexas@bris.ac.uk --- >>>>> Forgot to say that this was with Andreas Tobler's patchset. >>>>> Also, it segfaults with the OS default ld too: >>>>> >>>>> $ cat z.c >>>>> #include >>>>> int main(int argc, char **argv) >>>>> { >>>>> printf("mumu\n"); >>>>> return 0; >>>>> } >>>>> $ cc -c z.c -Wall >>>>> $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>>> $ ldd z >>>>> z: >>>>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>>>> $ file z >>>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>>> $ ./z >>>>> Segmentation fault (core dumped) >>>>> $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>>> $ ldd z >>>>> z: >>>>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>>>> $ file z >>>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>>> $ ./z >>>>> Segmentation fault (core dumped) >>>>> $ >>>>> >>>> Why are you using this strange invocation of the linker? If I run >>>> "cc -v -o z z.c", here is how it invokes ld: >>>> >>>> "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 >>>> --hash-style=both --enable-new-dtags -o z /usr/lib/crt1.o >>>> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o -lgcc >>>> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s >>>> --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o >>>> >>>> The resulting program runs without difficulty. -- George >>> >>> well, I copied my invocation from: >>> http://people.freebsd.org/~rene/patches/binutils-rpi-bug.txt >>> >>> but you are right. I have now did just the same >>> using /usr/local/bin/ld, and the executable worked. >>> >>> So probably Andreas Tobler's patchset should >>> be committed? >>> >>> I'm building lang/gcc right now, will see how it goes. >> >> You can save the time for gcc. Nothing else than the system gcc works. > > Sorry, I still don't get you. > What is the "system gcc"? Hm, we have clang or gcc for CC. When I talk about 'system gcc' I mean: [andreast@wandquad] /build/gcc/objdir_armv6/> gcc -v Using built-in specs. Target: armv6-undermydesk-freebsd Configured with: FreeBSD/armv6 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] Currently I have no clang installed since it does not build/bootstrap gcc-4.10. This is my game. > I thought the system C compiler is clang, in 10-stable and above. It can either be gcc or clang. > I'm not intersted in gcc itself. :) nobody seems and nobody is happy with a half backed clang ;) > I just want to build xorg-server. No experience here, sorry. Andreas From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 20:51:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45325BEF for ; Sat, 12 Jul 2014 20:51:49 +0000 (UTC) Received: from eu1sys200aog107.obsmtp.com (eu1sys200aog107.obsmtp.com [207.126.144.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97C0F22BE for ; Sat, 12 Jul 2014 20:51:48 +0000 (UTC) Received: from mail-wg0-f47.google.com ([74.125.82.47]) (using TLSv1) by eu1sys200aob107.postini.com ([207.126.147.11]) with SMTP ID DSNKU8GfuSrMqbcdswKHRNGYqa60687bZkok@postini.com; Sat, 12 Jul 2014 20:51:48 UTC Received: by mail-wg0-f47.google.com with SMTP id b13so413216wgh.18 for ; Sat, 12 Jul 2014 13:51:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to :in-reply-to; bh=qba0J0BIV7LMH/qC73DrZu5T+v2KnRlSSRA7FT8XA/k=; b=IrFiDrdtq01U4dAyA80yqqHkkBXk38X4i7srW+B5SbOoboIvko17tjxuj68zLyDD0M u5AbeA7ko4UmW9gIR7PUPmp6azdGWe2Li+1txz+HsBv3uddZK9z//w0UEqM4jp8SQ83N SjV37++bHQzCqgHV9IqSvCbtNYHdWlWxHbh4tliYxGEp2767sTgFFy9hlOYPrWc59/tD n0JXRzihXjwejdD95m5YJrNHbeRzFAbmD+2Kl3cHqtEp1AdpzFM0yCJqVOq04vkP8LZy 73METL7A8rhIcGkU1DWtLPGT/lj7fqjj6HEVs9bL+okfz5rFlMcZamp7r/g0ma06XAvx nNkA== X-Gm-Message-State: ALoCoQkc3Vtgl7o0mFdFkf/laAof8x8wsDE1tFxJIquUTW3aeNG12j3WUMHdPoIgViUWtfMWlDT6HUlz6JOUEfeDGvJyZFkgtsVGKzKR6OcQ36PCSQne5BAy0X8C0dlIDCO2OS0drhFv X-Received: by 10.194.58.199 with SMTP id t7mr8751920wjq.14.1405198265735; Sat, 12 Jul 2014 13:51:05 -0700 (PDT) X-Received: by 10.194.58.199 with SMTP id t7mr8751916wjq.14.1405198265667; Sat, 12 Jul 2014 13:51:05 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id gd13sm10593287wic.6.2014.07.12.13.51.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Jul 2014 13:51:05 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6CKp3Qh098113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Jul 2014 21:51:03 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6CKp3Yq098112; Sat, 12 Jul 2014 21:51:03 +0100 (BST) (envelope-from mexas) Date: Sat, 12 Jul 2014 21:51:03 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407122051.s6CKp3Yq098112@mech-cluster241.men.bris.ac.uk> To: andreast-list@fgznet.ch, freebsd-arm@freebsd.org, george+freebsd@m5p.com, mexas@bris.ac.uk Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Reply-To: mexas@bris.ac.uk In-Reply-To: <53C19CEC.7080101@fgznet.ch> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 20:51:49 -0000 >From andreast-list@fgznet.ch Sat Jul 12 21:40:44 2014 >>> >>> You can save the time for gcc. Nothing else than the system gcc works. >> >> Sorry, I still don't get you. >> What is the "system gcc"? > >Hm, we have clang or gcc for CC. When I talk about 'system gcc' I mean: >[andreast@wandquad] /build/gcc/objdir_armv6/> gcc -v >Using built-in specs. >Target: armv6-undermydesk-freebsd >Configured with: FreeBSD/armv6 system compiler >Thread model: posix >gcc version 4.2.1 20070831 patched [FreeBSD] Oh, I get it, I installed the snapshot: # uname -a FreeBSD BOZO 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul 1 04:29:43 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm which was build with the default WITHOUT_GCC, whereas you probably built world youself with WITH_GCC. Am I right? Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 20:52:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC5A3C28 for ; Sat, 12 Jul 2014 20:52:04 +0000 (UTC) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B449322C1 for ; Sat, 12 Jul 2014 20:52:04 +0000 (UTC) Received: from 127.0.0.1 (exit5.telostor.ca [62.210.74.143]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id s6CKQFIu056627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 12 Jul 2014 16:26:18 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Message-ID: <53C1993B.7040900@ceetonetechnology.com> Date: Sat, 12 Jul 2014 16:23:23 -0400 From: George Rosamond MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Impressive CPU usage References: <64FC570A-8FAF-4366-A9CA-6F91EBB6739B@freebsd.org> <53C18DC9.2020205@fgznet.ch> In-Reply-To: <53C18DC9.2020205@fgznet.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 20:52:05 -0000 Andreas Tobler: > On 12.07.14 21:27, Tim Kientzle wrote: >> While building the git port on my BeagleBone Black: >> >> >> last pid: 87645; load averages: 1.05, 0.93, 0.72 up 0+13:15:47 >> 19:24:42 19 processes: 2 running, 17 sleeping CPU: 68.4% user, 0.0% >> nice, 28.5% system, 3.0% interrupt, 0.0% idle Mem: 57M Active, 352M >> Inact, 77M Wired, 1804K Cache, 67M Buf, 4280K Free Swap: >> >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU >> COMMAND 87645 root 1 69 0 44792K 33288K RUN 0:02 >> 1777.13% cc 87644 root 1 8 0 35336K 22832K wait >> 0:00 107.14% cc 87633 root 1 40 0 11568K 3056K RUN >> 0:00 0.84% top 87564 root 1 8 0 10304K 1932K wait >> 0:01 0.53% gmake 677 root 1 40 0 18880K 5136K select >> 0:16 0.04% sshd >> >> >> For the record: >> >> root@beaglebone:~ # uname -a FreeBSD beaglebone 11.0-CURRENT FreeBSD >> 11.0-CURRENT #0 r266929: Sun Jun 1 00:29:41 PDT 2014 >> root@thinkpad:/usr/home/tim/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE >> >> arm > > > +1: > > andreast@wandquad:~ % uname -ra > FreeBSD wandquad 11.0-CURRENT FreeBSD 11.0-CURRENT #12 r268501M: Thu Jul > 10 21:02:32 CEST 2014 > andreast@tcx58.andreas.nets:/usr/obj/arm.armv6/export/devel/fbsd/src/sys/WANDQUAD > arm > > last pid: 30275; load averages: 8.51, 7.73, 5.25 up 2+00:19:10 > 21:32:22 > 50 processes: 9 running, 41 sleeping > CPU: 71.2% user, 0.0% nice, 18.8% system, 9.9% interrupt, 0.2% idle > Mem: 233M Active, 260M Inact, 159M Wired, 244K Cache, 114M Buf, 1349M Free Great stuff. This could allow me to start up that selection of ARMv6 pkgs I had on mirrors.nycbug.org, since I was doing native, sans-poudriere builds. What exactly is enabling this performance increase? Has/can it be MFC'd to 10.x? g From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 21:00:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79760DE7 for ; Sat, 12 Jul 2014 21:00:29 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D9BA230E for ; Sat, 12 Jul 2014 21:00:28 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s6CL0Nbe026154; Sat, 12 Jul 2014 23:00:24 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53C1A1E7.5040807@fgznet.ch> Date: Sat, 12 Jul 2014 23:00:23 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mexas@bris.ac.uk, freebsd-arm@freebsd.org, george+freebsd@m5p.com Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi References: <201407122051.s6CKp3Yq098112@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201407122051.s6CKp3Yq098112@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 21:00:29 -0000 On 12.07.14 22:51, Anton Shterenlikht wrote: >>From andreast-list@fgznet.ch Sat Jul 12 21:40:44 2014 >>>> >>>> You can save the time for gcc. Nothing else than the system gcc works. >>> >>> Sorry, I still don't get you. >>> What is the "system gcc"? >> >> Hm, we have clang or gcc for CC. When I talk about 'system gcc' I mean: >> [andreast@wandquad] /build/gcc/objdir_armv6/> gcc -v >> Using built-in specs. >> Target: armv6-undermydesk-freebsd >> Configured with: FreeBSD/armv6 system compiler >> Thread model: posix >> gcc version 4.2.1 20070831 patched [FreeBSD] > > Oh, I get it, I installed the snapshot: > > # uname -a > FreeBSD BOZO 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul 1 04:29:43 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm > > which was build with the default WITHOUT_GCC, > whereas you probably built world youself with WITH_GCC. > Am I right? Yes, my make.conf entries: /etc/make.conf # for armv6 WITH_GCC=yes WITH_GNUCXX=yes WITH_GCC_BOOTSTRAP=yes WITHOUT_CLANG=yes WITHOUT_CLANG_IS_CC=yes WITHOUT_CLANG_BOOTSTRAP=yes # end for armv6 Andreas From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 21:18:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61FA045D for ; Sat, 12 Jul 2014 21:18:26 +0000 (UTC) Received: from eu1sys200aog122.obsmtp.com (eu1sys200aog122.obsmtp.com [207.126.144.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B608824D1 for ; Sat, 12 Jul 2014 21:18:25 +0000 (UTC) Received: from mail-we0-f170.google.com ([74.125.82.170]) (using TLSv1) by eu1sys200aob122.postini.com ([207.126.147.11]) with SMTP ID DSNKU8GmH/0UL1QTw59jkDE84IiZ+ePcVt8V@postini.com; Sat, 12 Jul 2014 21:18:25 UTC Received: by mail-we0-f170.google.com with SMTP id w62so2258482wes.29 for ; Sat, 12 Jul 2014 14:18:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to :in-reply-to; bh=e3njJwK4ZN6P+vsB+eXR3jiYkhKaBM9A9sPJ5iKGFVw=; b=Ciqs2I5vrNI982+rSBKDJZygaNf/HTVUqPsDEqSTq41tgCvN8PmVaz0SQJP3iD0hXF A6TETPuFaE4GplG5pXWru7f7JmpVMEZf6RQbpLGfustfV0imBCDqEb+VFUHhvS0cCBnk +j7mwY0GtU3N4Ten9q70np3g0iWp48xWwhqgKujX4ygbiTaYKVZQIoIdHfFZwz5pmzTE KhoU0FtNkLA6c+lw7W72aDXtMiwaC2BtcCsOt9WcEuOEtBLQj4cMjREvHRZeDQe75J+U NSnPix/N3/xLGuJFqEW90hT41fwVMadhEJ2WQ02OnSCB/NdR1jdjLaNabBTNFSBo1lfi EnFA== X-Gm-Message-State: ALoCoQnACYdbMwWfAKvchj9EYDGNxpO5YgOvZ5ORHpmqbg0HbkLIeZlYeRG5Mvpe+gpqRElbNf5wAPMBcL+UcLu9uCto8V0hpsEYFL14TLXInMm4HsDkPkn2ktvTgZ/MSzy2AO1BQJQ/ X-Received: by 10.180.91.194 with SMTP id cg2mr14788969wib.12.1405199903433; Sat, 12 Jul 2014 14:18:23 -0700 (PDT) X-Received: by 10.180.91.194 with SMTP id cg2mr14788963wib.12.1405199903362; Sat, 12 Jul 2014 14:18:23 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id jv9sm14057718wjc.28.2014.07.12.14.18.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Jul 2014 14:18:22 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6CLILBg098207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Jul 2014 22:18:21 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6CLILAP098206; Sat, 12 Jul 2014 22:18:21 +0100 (BST) (envelope-from mexas) Date: Sat, 12 Jul 2014 22:18:21 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407122118.s6CLILAP098206@mech-cluster241.men.bris.ac.uk> To: andreast-list@fgznet.ch, freebsd-arm@freebsd.org, george+freebsd@m5p.com, mexas@bris.ac.uk Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Reply-To: mexas@bris.ac.uk In-Reply-To: <53C1A1E7.5040807@fgznet.ch> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 21:18:26 -0000 >From andreast-list@fgznet.ch Sat Jul 12 22:17:07 2014 >>> Hm, we have clang or gcc for CC. When I talk about 'system gcc' I mean: >>> [andreast@wandquad] /build/gcc/objdir_armv6/> gcc -v >>> Using built-in specs. >>> Target: armv6-undermydesk-freebsd >>> Configured with: FreeBSD/armv6 system compiler >>> Thread model: posix >>> gcc version 4.2.1 20070831 patched [FreeBSD] >> >> Oh, I get it, I installed the snapshot: >> >> # uname -a >> FreeBSD BOZO 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul 1 04:29:43 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >> >> which was build with the default WITHOUT_GCC, >> whereas you probably built world youself with WITH_GCC. >> Am I right? > >Yes, my make.conf entries: > >/etc/make.conf ># for armv6 >WITH_GCC=yes >WITH_GNUCXX=yes >WITH_GCC_BOOTSTRAP=yes >WITHOUT_CLANG=yes >WITHOUT_CLANG_IS_CC=yes >WITHOUT_CLANG_BOOTSTRAP=yes ># end for armv6 > >Andreas > Cool, thanks, I'll try the same. Anton From owner-freebsd-arm@FreeBSD.ORG Sat Jul 12 23:52:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DDBB294 for ; Sat, 12 Jul 2014 23:52:13 +0000 (UTC) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AA7C2F7B for ; Sat, 12 Jul 2014 23:52:12 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id hq11so3721478vcb.3 for ; Sat, 12 Jul 2014 16:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ptE+z1Yfi4n+s3q9eK8xC4I/czU6DgYoRdiFGcfz3MY=; b=wPnQPzaTM2DSM15/DJ0q96hQS99UL88GIKwAqHxJpS9GZhhSZbjxbvK5q/bJXzOH4C pvrLr7v5X370QU/0eQKQmAftWR/W6N+uyLAZLEMhVDJAWJH3af/NaUdOYIjUExfpjTe+ QHWNTAFjBbg/Ui5wcvZa1rqc929u9a6LPJdq/4TAtu6vbGhMxKEHDJsN85ZrtuAT+luR 1yrkYLujiL6/EhYv2uJU4uFG6hYSPXiTDpzrjCdskRcvWmiHA7yzBBqrG2m4QlWrJ90T AEzEH8DisyWKofQdP4truN52GywHgArk7QTyeZNPixo58Pdicx9i+11st4cSWr69pRDt fWEA== MIME-Version: 1.0 X-Received: by 10.220.251.134 with SMTP id ms6mr7773035vcb.10.1405209131901; Sat, 12 Jul 2014 16:52:11 -0700 (PDT) Sender: johny.mattsson@gmail.com Received: by 10.221.10.148 with HTTP; Sat, 12 Jul 2014 16:52:11 -0700 (PDT) In-Reply-To: <201407121937.s6CJbmQX097891@mech-cluster241.men.bris.ac.uk> References: <201407121937.s6CJbmQX097891@mech-cluster241.men.bris.ac.uk> Date: Sun, 13 Jul 2014 09:52:11 +1000 X-Google-Sender-Auth: hSS3tEqcEaNVkkRoZrh_7qhdwdg Message-ID: Subject: Re: acpi_thermal(4) - not relevant for arm? From: Johny Mattsson To: mexas@bris.ac.uk Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 23:52:13 -0000 On 13 July 2014 05:37, Anton Shterenlikht wrote: > > So the port contains > "ARM side code to interface to: > EGL, mmal, GLESv2, vcos, openmaxil, vchiq_arm, bcm_host, WFC, OpenVG." > > Is there any easy introduction to these? Assuming it's just a straight port (I haven't tried FBSD on a Pi yet), here are a couple of links: http://elinux.org/RPI_vcgencmd_usage http://elinux.org/Raspberry_Pi_VideoCore_APIs Undoubtedly there'd be more information on the Pi forums. Cheers, /Johny From owner-freebsd-arm@FreeBSD.ORG Mon Jul 14 20:41:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8A2CF62 for ; Mon, 14 Jul 2014 20:41:59 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7913D21B1 for ; Mon, 14 Jul 2014 20:41:59 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X6n4K-000Dua-Dx; Mon, 14 Jul 2014 20:41:52 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6EKfn6d007871; Mon, 14 Jul 2014 14:41:50 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Wd9vjkSmLj25Q2NuXn7ol X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi From: Ian Lepore To: Andreas Tobler In-Reply-To: <53C19400.6050404@fgznet.ch> References: <201407121943.s6CJhT2p097909@mech-cluster241.men.bris.ac.uk> <53C19400.6050404@fgznet.ch> Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Jul 2014 14:41:49 -0600 Message-ID: <1405370509.1312.11.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 20:41:59 -0000 On Sat, 2014-07-12 at 22:01 +0200, Andreas Tobler wrote: > On 12.07.14 21:43, Anton Shterenlikht wrote: > >>> --- Comment #6 from mexas@bris.ac.uk --- > >>> Forgot to say that this was with Andreas Tobler's patchset. > >>> Also, it segfaults with the OS default ld too: > >>> > >>> $ cat z.c > >>> #include > >>> int main(int argc, char **argv) > >>> { > >>> printf("mumu\n"); > >>> return 0; > >>> } > >>> $ cc -c z.c -Wall > >>> $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc > >>> $ ldd z > >>> z: > >>> libc.so.7 => /lib/libc.so.7 (0x2003c000) > >>> $ file z > >>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses > >>> shared libs), for FreBSD 10.0 (1000710), not stripped > >>> $ ./z > >>> Segmentation fault (core dumped) > >>> $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc > >>> $ ldd z > >>> z: > >>> libc.so.7 => /lib/libc.so.7 (0x2003c000) > >>> $ file z > >>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses > >>> shared libs), for FreBSD 10.0 (1000710), not stripped > >>> $ ./z > >>> Segmentation fault (core dumped) > >>> $ > >>> > >> Why are you using this strange invocation of the linker? If I run > >> "cc -v -o z z.c", here is how it invokes ld: > >> > >> "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 > >> --hash-style=both --enable-new-dtags -o z /usr/lib/crt1.o > >> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o -lgcc > >> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s > >> --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o > >> > >> The resulting program runs without difficulty. -- George > > > > well, I copied my invocation from: > > http://people.freebsd.org/~rene/patches/binutils-rpi-bug.txt > > > > but you are right. I have now did just the same > > using /usr/local/bin/ld, and the executable worked. > > > > So probably Andreas Tobler's patchset should > > be committed? > > > > I'm building lang/gcc right now, will see how it goes. > > You can save the time for gcc. Nothing else than the system gcc works. > I do some work on gcc-4.10 and it is hairy. > I can bootstrap gcc-4.10 but I have some issues with tls which blocks me > to come out with my patch set. The overall view is good. > I even have C++ exceptions working with EABI. We are actively working on this at $work (using clang, not gcc) and I'd love to see whatever patches you've got. I was about to import netbsd's find_exidx.c for ld-elf.so, but if you've already done it I won't bother. There are other aspects of it still not working for us, so maybe you've solved things we're still working on. > > Also, the binutils patch set is not satisfying for me. I do not have > feedback for arm*b nor for arm* < FreeBSD 10.0. > I doubt you'll ever get feedback for either of these. We only have 2 or 3 users who have hardware and are even trying to use armeb these days. The hardware is old and rare. -current only became usable again on armeb in the past week or two. As for arm on < 10, there's not much support. and not many active users. It's not an official project policy or anything, but in effect we've abandoned active support on anything older than 10 due to lack of resources. We use 8.2 with arm at work, and all the patches we've generated there over the years have been merged to 8, 10, and 11. 9.x on arm has always been a nonexistant thing for me. I don't know of anybody even trying to use it, based on the traffic on irc and mailing lists. -- Ian > And last but not least, my time slot is shrinking, summer holidays ;) > > Anton, thanks for your testing and feedback. > > Andreas > From owner-freebsd-arm@FreeBSD.ORG Mon Jul 14 20:46:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44E77DB for ; Mon, 14 Jul 2014 20:46:14 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08F2321FB for ; Mon, 14 Jul 2014 20:46:13 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id at20so3655674iec.25 for ; Mon, 14 Jul 2014 13:46:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=szQc4uvD6W1idWwmsJDqDZVR4PJld3xN7Rj70nSlRfM=; b=NkACqplzBxuMlqOfW5FVHAsaUzdZmSynLX+nAI3VdlFtAN+nssExGN9MVcEr55zvsX TPSU0QPQjekGY3H/Mw39vvpuCG5gGdvMevH+lm0qYjWcDiOz6AvPgLbZAGnebZNhdTZH Cc8i2YLXnNJ3jMds8R+IVxV0gcTh+r/CvQHhE0hIzMfjwoxnlKFeC5mkMEicNRub/67/ LvYHzFlw5OHZk+l9XozfZOnCA3SQVwui7g/xyezA+AlF98EXEBLYakZlmBTh+n0YDoyg C8HQ1K94lMP/QnN6uxSZWZJkQ5fxupYLQFllv9kUjtTeFntX2HxRQCztGtzU8UxPkM0D zskg== X-Gm-Message-State: ALoCoQk0/fDMtpq/jTbFHjDefZHysRzaSiBMnjHLe/BmFKXNEKAGxoS6D/SdvLF0EQRFJcylJCag X-Received: by 10.50.142.97 with SMTP id rv1mr581083igb.13.1405370766894; Mon, 14 Jul 2014 13:46:06 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qa4sm27900937igb.10.2014.07.14.13.46.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 13:46:06 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_75F2E4A3-904E-4D57-982E-8A4D389BE5EB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi From: Warner Losh In-Reply-To: <1405370509.1312.11.camel@revolution.hippie.lan> Date: Mon, 14 Jul 2014 14:45:40 -0600 Message-Id: <9C3614F7-C311-453F-B0E7-BE0312766640@bsdimp.com> References: <201407121943.s6CJhT2p097909@mech-cluster241.men.bris.ac.uk> <53C19400.6050404@fgznet.ch> <1405370509.1312.11.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 20:46:14 -0000 --Apple-Mail=_75F2E4A3-904E-4D57-982E-8A4D389BE5EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 14, 2014, at 2:41 PM, Ian Lepore wrote: > On Sat, 2014-07-12 at 22:01 +0200, Andreas Tobler wrote: >> On 12.07.14 21:43, Anton Shterenlikht wrote: >>>>> --- Comment #6 from mexas@bris.ac.uk --- >>>>> Forgot to say that this was with Andreas Tobler's patchset. >>>>> Also, it segfaults with the OS default ld too: >>>>>=20 >>>>> $ cat z.c >>>>> #include >>>>> int main(int argc, char **argv) >>>>> { >>>>> printf("mumu\n"); >>>>> return 0; >>>>> } >>>>> $ cc -c z.c -Wall >>>>> $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>>> $ ldd z >>>>> z: >>>>> libc.so.7 =3D> /lib/libc.so.7 (0x2003c000) >>>>> $ file z >>>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically = linked (uses >>>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>>> $ ./z >>>>> Segmentation fault (core dumped) >>>>> $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>>> $ ldd z >>>>> z: >>>>> libc.so.7 =3D> /lib/libc.so.7 (0x2003c000) >>>>> $ file z >>>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically = linked (uses >>>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>>> $ ./z >>>>> Segmentation fault (core dumped) >>>>> $ >>>>>=20 >>>> Why are you using this strange invocation of the linker? If I run >>>> "cc -v -o z z.c", here is how it invokes ld: >>>>=20 >>>> "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 >>>> --hash-style=3Dboth --enable-new-dtags -o z /usr/lib/crt1.o >>>> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o = -lgcc >>>> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s >>>> --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o >>>>=20 >>>> The resulting program runs without difficulty. -- George >>>=20 >>> well, I copied my invocation from: >>> http://people.freebsd.org/~rene/patches/binutils-rpi-bug.txt >>>=20 >>> but you are right. I have now did just the same >>> using /usr/local/bin/ld, and the executable worked. >>>=20 >>> So probably Andreas Tobler's patchset should >>> be committed? >>>=20 >>> I'm building lang/gcc right now, will see how it goes. >>=20 >> You can save the time for gcc. Nothing else than the system gcc = works. >> I do some work on gcc-4.10 and it is hairy. >> I can bootstrap gcc-4.10 but I have some issues with tls which blocks = me=20 >> to come out with my patch set. The overall view is good.=20 >=20 >=20 >> I even have C++ exceptions working with EABI. >=20 > We are actively working on this at $work (using clang, not gcc) and = I'd > love to see whatever patches you've got. I was about to import = netbsd's > find_exidx.c for ld-elf.so, but if you've already done it I won't > bother. There are other aspects of it still not working for us, so > maybe you've solved things we're still working on. >=20 >>=20 >> Also, the binutils patch set is not satisfying for me. I do not have=20= >> feedback for arm*b nor for arm* < FreeBSD 10.0. >>=20 >=20 > I doubt you'll ever get feedback for either of these. We only have 2 = or > 3 users who have hardware and are even trying to use armeb these days. > The hardware is old and rare. -current only became usable again on > armeb in the past week or two. >=20 > As for arm on < 10, there's not much support. and not many active = users. > It's not an official project policy or anything, but in effect we've > abandoned active support on anything older than 10 due to lack of > resources. We use 8.2 with arm at work, and all the patches we've > generated there over the years have been merged to 8, 10, and 11. =20 >=20 > 9.x on arm has always been a nonexistant thing for me. I don't know = of > anybody even trying to use it, based on the traffic on irc and mailing > lists. I have a 9.x arm-based (atmel) dhcpd and other network services server = that I run since I couldn=92t get the 10.x MCI driver on atmel to work on the = newer SAM9 SoCs. All the optimizations for it work great on the AT91RM9200, but = break newer ones. That said, there are a number of bumps in the 9.x support in arm. :( = I=92ve worked around them, but most of the issues have since been fixed in -current = and 10. Warner --Apple-Mail=_75F2E4A3-904E-4D57-982E-8A4D389BE5EB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTxEF0AAoJEGwc0Sh9sBEAaawP/A9RGw9KnScxSqmJLPnqWBeL CsbNdx/8pgiz74UOnYWK87iHcJ0KRd9emNHl9eqAwfh12oxSiPPPIeeE1GgtOxJg HB+1YIcSLsbVLwaNCPZRxtYusU1ECmKYp9GNL9prjXGPaX4gjJopaCMuzsMVTIcd p6O6apkdP1yPJZZi23/5IWzyz+VfIs8rjFWDg5LNHW0uj6PttFI+5YkLNQdhf710 OMBexVFIm+6BcHguUB+wUCYegEhjuswv7vtIc0JpjMIlthoU7WFvrVXp3Y5l9wjx oYMjt24MouCgp5Rhg8i6eo2N3tqmP+R0eaHjh4/iSd6j6k0nbjSjPkJDPmdW/b3v N/FXAmm6c4Mft2YMmGZZqJve8/xgOby4lFKDR9if6gF2Bv74vAGEduJpYFS/o7Hi Wvupp3KyKjKPutokzb93IgmEjl0JrulDAAZe+dGh3BM0ltLupNdg4e3VRk8IWhQQ iuy1UMjp29gCstZ86JDLRmh1ONJ2okTHGh2UihNYuskx49VMCYIfiYjOXHpAwFTk RFQfba+XohOQjF8tGWmxnibaQ/CD2NNdDJncUNw6S/RLLavn12GzyGCheGprZTOM AJFJzLFoYC2+du194+SPx75iNFFrlDL5em6XtLBMFwQTvsMtze/9DUmcK8Dh6aHO YAV0VV3lb6DfF2kGm1Pl =IDjU -----END PGP SIGNATURE----- --Apple-Mail=_75F2E4A3-904E-4D57-982E-8A4D389BE5EB-- From owner-freebsd-arm@FreeBSD.ORG Mon Jul 14 21:11:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C9A0B53 for ; Mon, 14 Jul 2014 21:11:13 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 20FCB2464 for ; Mon, 14 Jul 2014 21:11:12 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X6nWh-0007BR-VM; Mon, 14 Jul 2014 21:11:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6ELBBJ4007961; Mon, 14 Jul 2014 15:11:11 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/7aXCTukDskuvLfED8TU3m X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Some bug fixes for Zynq Ethernet From: Ian Lepore To: Thomas Skibo In-Reply-To: <53A9D50F.8030604@sbcglobal.net> References: <53A9D50F.8030604@sbcglobal.net> Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Jul 2014 15:11:10 -0600 Message-ID: <1405372270.1312.14.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.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 21:11:13 -0000 On Tue, 2014-06-24 at 12:44 -0700, Thomas Skibo wrote: > Hello, all. > > I have some bug fixes for the Zynq/Zedboard Ethernet driver that have > been laying around for a while and that I'm hoping to get committed. > The main bug is that the driver doesn't handle media speed changes > correctly so it can only connect to 1G switches. > > To fix this bug, the driver needs to be able to change the frequency of > the ethernet core's reference clock. Because I am trying to keep > if_cgem.c platform-independent, I've created a function called > cgem_set_ref_clk() that a platform can override with a platform-specific > function for changing the clock. This should make it easier if the > Cadence GEM block shows up in other SoCs. > > Where it is a bit ugly is that the driver doesn't know which of two > ethernet cores it controls so I created a device-tree property called > "ref-clock-num" so that the platform-specific code knows which reference > clock to change. I am open to other ideas on how to do this. > > Comments? > > I have a few other minor fixes and enhancements that I'll put in a > different patch. > > Thanks, > Committed as r268633. Sorry it took so long, $work got crazy last month and I'm way behind. BTW, the weak-reference function and need for ref-clock-num property are fine for now... there's not much else we can do until we get a proper device/soc-independent clock API that can read and handle the standard clock=<...> properties in dts files. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jul 14 21:16:30 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 304A2D09 for ; Mon, 14 Jul 2014 21:16:30 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17D9F248D for ; Mon, 14 Jul 2014 21:16:30 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6ELGTBN052311 for ; Mon, 14 Jul 2014 21:16:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 177686] assertion failed in ld-elf.so.1 when invoking telnet with parameters (clang, EABI) Date: Mon, 14 Jul 2014 21:16:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: v1ne2go@gmail.com X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 21:16:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D177686 v1ne2go@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |v1ne2go@gmail.com --- Comment #3 from v1ne2go@gmail.com --- As a quick workaround, setting LD_BIND_NOW helps. I tried this on gmp, which passes make check with this flag -- except C++ t= ests due to broken exceptions. Without this, I also got some ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld_lock.c:233 messages. So, what exactly is the difference when lazy binding comes into play? >From my underst=C3=A4nding, if a symbol is not bound, the process is as fol= lows: - I call some function func(), stack is 8-byte aligned - func points to an rtld handler that loads the function and patches the function table, stack is 8-byte aligned at the start and we crash somewhere= in rtld. - rtld calls func() vs. - I call func(), stack is 8-byte aligned at this point - func is being called Was there any progress since the last year? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@FreeBSD.ORG Tue Jul 15 20:14:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A98E52D9; Tue, 15 Jul 2014 20:14:51 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 397E42FEF; Tue, 15 Jul 2014 20:14:50 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s6FKEYUS097206; Tue, 15 Jul 2014 22:14:40 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53C58BAA.5040701@fgznet.ch> Date: Tue, 15 Jul 2014 22:14:34 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warner Losh , Ian Lepore Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi References: <201407121943.s6CJhT2p097909@mech-cluster241.men.bris.ac.uk> <53C19400.6050404@fgznet.ch> <1405370509.1312.11.camel@revolution.hippie.lan> <9C3614F7-C311-453F-B0E7-BE0312766640@bsdimp.com> In-Reply-To: <9C3614F7-C311-453F-B0E7-BE0312766640@bsdimp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 20:14:51 -0000 Hi all, thanks for the feedback! On 14.07.14 22:45, Warner Losh wrote: > > On Jul 14, 2014, at 2:41 PM, Ian Lepore wrote: > >> On Sat, 2014-07-12 at 22:01 +0200, Andreas Tobler wrote: >>> On 12.07.14 21:43, Anton Shterenlikht wrote: >>>>>> --- Comment #6 from mexas@bris.ac.uk --- >>>>>> Forgot to say that this was with Andreas Tobler's patchset. >>>>>> Also, it segfaults with the OS default ld too: >>>>>> >>>>>> $ cat z.c >>>>>> #include >>>>>> int main(int argc, char **argv) >>>>>> { >>>>>> printf("mumu\n"); >>>>>> return 0; >>>>>> } >>>>>> $ cc -c z.c -Wall >>>>>> $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>>>> $ ldd z >>>>>> z: >>>>>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>>>>> $ file z >>>>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>>>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>>>> $ ./z >>>>>> Segmentation fault (core dumped) >>>>>> $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>>>> $ ldd z >>>>>> z: >>>>>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>>>>> $ file z >>>>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>>>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>>>> $ ./z >>>>>> Segmentation fault (core dumped) >>>>>> $ >>>>>> >>>>> Why are you using this strange invocation of the linker? If I run >>>>> "cc -v -o z z.c", here is how it invokes ld: >>>>> >>>>> "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 >>>>> --hash-style=both --enable-new-dtags -o z /usr/lib/crt1.o >>>>> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o -lgcc >>>>> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s >>>>> --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o >>>>> >>>>> The resulting program runs without difficulty. -- George >>>> >>>> well, I copied my invocation from: >>>> http://people.freebsd.org/~rene/patches/binutils-rpi-bug.txt >>>> >>>> but you are right. I have now did just the same >>>> using /usr/local/bin/ld, and the executable worked. >>>> >>>> So probably Andreas Tobler's patchset should >>>> be committed? >>>> >>>> I'm building lang/gcc right now, will see how it goes. >>> >>> You can save the time for gcc. Nothing else than the system gcc works. >>> I do some work on gcc-4.10 and it is hairy. >>> I can bootstrap gcc-4.10 but I have some issues with tls which blocks me >>> to come out with my patch set. The overall view is good. >> >> >>> I even have C++ exceptions working with EABI. >> >> We are actively working on this at $work (using clang, not gcc) and I'd >> love to see whatever patches you've got. I was about to import netbsd's >> find_exidx.c for ld-elf.so, but if you've already done it I won't >> bother. There are other aspects of it still not working for us, so >> maybe you've solved things we're still working on. >> >>> >>> Also, the binutils patch set is not satisfying for me. I do not have >>> feedback for arm*b nor for arm* < FreeBSD 10.0. >>> >> >> I doubt you'll ever get feedback for either of these. We only have 2 or >> 3 users who have hardware and are even trying to use armeb these days. >> The hardware is old and rare. -current only became usable again on >> armeb in the past week or two. >> >> As for arm on < 10, there's not much support. and not many active users. >> It's not an official project policy or anything, but in effect we've >> abandoned active support on anything older than 10 due to lack of >> resources. We use 8.2 with arm at work, and all the patches we've >> generated there over the years have been merged to 8, 10, and 11. >> >> 9.x on arm has always been a nonexistant thing for me. I don't know of >> anybody even trying to use it, based on the traffic on irc and mailing >> lists. > > I have a 9.x arm-based (atmel) dhcpd and other network services server that > I run since I couldnt get the 10.x MCI driver on atmel to work on the newer SAM9 > SoCs. All the optimizations for it work great on the AT91RM9200, but break newer > ones. > > That said, there are a number of bumps in the 9.x support in arm. :( Ive worked > around them, but most of the issues have since been fixed in -current and 10. My issue is here: +++ gas/configure.tgt 1970-01-01 00:16:31.000000000 +0000 @@ -136,6 +136,9 @@ arm-*-symbianelf*) fmt=elf em=symbian ;; arm-*-kaos*) fmt=elf ;; arm-*-conix*) fmt=elf ;; + arm-*-freebsd9* | armeb-*-freebsd9*) fmt=elf em=freebsd ;; + arm-*-freebsd* | armeb-*-freebsd*) fmt=elf em=armfbsdeabi ;; + arm*-*-freebsd*) fmt=elf em=armfbsdvfp ;; fyi: -> armfbsdeabi sets EABI_DEFAULT EF_ARM_EABI_VER5 and -> armfbsdvfp sets the same as armfbsdeabi plus FPU_DEFAULT FPU_ARCH_VFP On freebsd9 I leave the 'old' abi and I'm not sure if I should do so. As I understand you both, 9.x is not something official working. It works if one puts his hands on it and does the mods needed. On 10.x and up we have the eabi and everthing is nearly fine. Except the vfp support which is only for armv6* and up. Here I'm not so sure if I do the right thing. The test cases look right, around 4 fails of 500 tests on my arm- and my armv6 board. I hope I could show my issues. Thanks again. Andreas