From owner-freebsd-arm@freebsd.org Sun Dec 6 07:16:37 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 207F6A3BFCF for ; Sun, 6 Dec 2015 07:16:37 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C939C1BEA for ; Sun, 6 Dec 2015 07:16:36 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkca188 with SMTP id a188so87788281vkc.0 for ; Sat, 05 Dec 2015 23:16:35 -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:cc :content-type; bh=ZwYUD6T1G/WY9bUR3eqavNt8PKLKvLfKx7nhwCl23uI=; b=mFTaR1rzxw74XNBwbLnRusWHMeqpXiUwt9Mxb6AMNxtBeQl7P8i26QsZa817nPpeCI D+p+9clp6IwDYCG9Js4XGsogI0k5OKVG0p4JXfEzbifjLoLjZMYvaX0Mb0nzn6ZiDU+e Adu6XHqaxeE8MZvV1PUVYtaKuSUoRLzjZIh24qdpPhfXvFwvO8slpAjYXAHUEfKP5L2p bmc32r1cl0DpeyqDSIgiL7yIPiLDeMSoDoGcaorv2+TJUd39BDx20lVVR0Ef/pCmHy23 QDJXz+RuvhzVghKPV5Ivx/kwVgDFOeSfptcNOZqLo8zMZuJcE19YaHe+NRQ7bT9Qf7jx H//Q== MIME-Version: 1.0 X-Received: by 10.31.168.143 with SMTP id r137mt18359309vke.13.1449386195416; Sat, 05 Dec 2015 23:16:35 -0800 (PST) Received: by 10.31.47.137 with HTTP; Sat, 5 Dec 2015 23:16:35 -0800 (PST) In-Reply-To: <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> Date: Sat, 5 Dec 2015 23:16:35 -0800 Message-ID: Subject: Re: Raspberry Pi Zero From: Russell Haley Cc: Erik Moe , freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 07:16:37 -0000 For what it's worth, I found this the other day... https://www.bidouilliste.com/blog/2015/11/27/Porting-FreeBSD-to-a-new-ARM-B= oard-Part-1/ Cheers, Russ On Sat, Dec 5, 2015 at 8:20 AM, Warner Losh wrote: > > > On Dec 5, 2015, at 8:14 AM, Erik Moe wrote: > > > > I got my hands on one of the new Raspberry Pi Zeros. I was curious if > would run the latest version of FreeBSD so I downloaded the latest > snapshot, FreeBSD-11.0-CURRENT-arm-armv6-RPI-B-20151130-r291495.img. > Unfortunately it doesn=E2=80=99t boot. There is no output to the console= and the > activity LED doesn=E2=80=99t light. I know there was a new release of Ra= spbian > Jessie to support the Zero and I was successful in getting that to run, b= ut > I was wondering if anybody knew what the issue might be and what it would > take to get FreeBSD to run on the Zero. > > I haven=E2=80=99t looked, but most likely a new u-boot and/or other firmw= are is > required. From what I understand of the board itself, though, the RPI-B > kernel has an excellent chance of running on it. > > Warner > > From owner-freebsd-arm@freebsd.org Sun Dec 6 07:21:39 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63F79A41150 for ; Sun, 6 Dec 2015 07:21:39 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D7FFB1F9B for ; Sun, 6 Dec 2015 07:21:38 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (89-27-2-202.bb.dnainternet.fi [89.27.2.202]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id tB67LZ1p046850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 6 Dec 2015 07:21:36 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org Subject: Re: Raspberry Pi Zero References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> To: freebsd-arm@freebsd.org From: Stefan Parvu Organization: kronometrix.org Message-ID: <5663E1FA.3060602@kronometrix.org> Date: Sun, 6 Dec 2015 09:21:30 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 07:21:39 -0000 > I haven’t looked, but most likely a new u-boot and/or other firmware is required. Talking about this, reminds me something I always wanted to ask. Q: cant we deliver one image for RBPI, RBPI2, RBPI0 boards for example ? Currently one has to download & use a different image for a different board. Linux Raspbian does not have this model. Why is this on FreeBSD ARM ? thanks, -- Stefan Parvu From owner-freebsd-arm@freebsd.org Sun Dec 6 07:31:40 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23E95A4139F for ; Sun, 6 Dec 2015 07:31:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4BC9133C for ; Sun, 6 Dec 2015 07:31:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkeg192 with SMTP id g192so14781528qke.1 for ; Sat, 05 Dec 2015 23:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=u4iVabdlmlP4ukuiJBKP1zZI1pjOH/NRdJdjEKsKYRI=; b=VARh3U6FxJpj0QQM8X/tZwZNpVDIwidpINJb73iPognQMQ0CxwwUsILlRzUNIdPAYC ImtlzxRfMPbkQDx8q4IT/n/etMO6WeMXbas6owV+VXmIfdNIayaoPmCGvg2WgGnU6EqU 9KhMlqmA21A4vlZRKQ6LlzxxLJBLXMBR3i1yH/qkU+rTH5EUHsNtBUYXedchBz5/H50i Un+8RJYkrw4fBYFnV5uH5QbZVkc3lNTxynPURwe1svBnX+HuxvGelO6C9eBgChAHU8wB 84qUvwAx1vpqYbb+E0IFMJHW5e3iP/IWwY3gv9l4+yZ229D4/w11ESMN51S4PUYTdvIh OFCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u4iVabdlmlP4ukuiJBKP1zZI1pjOH/NRdJdjEKsKYRI=; b=ZNGrjp1oNx7KfycCXsyHGVSgt4q5MP96YYL1cHdHakhLNVhDRNbe1o7j+kUnwmywZN YDrEDdZ9yMh6r+w/lqde+fYZDvDSZ/FwI8NbfmpNyPALeDZcXJhiH86y8UIJXRH2z8EI OSiFonh+ZBeQauIcOzJLo8FY45DYPKlhsZpXQ3T17YII8tOysClD5A8Jjw8BucZLGNoo J6Uu4ax7XKLyv3tdDf6AwFB+WEmvlkj6G8QmytWMayo+mSfukwqQiZ+7/okZfetOeP/s +nb3VJQwItCMW5T9NaV6DPielWDO+y16b/8TQjL07kfQ4VbhQy4CHij4LzvR7dTTFJcJ 5PTA== X-Gm-Message-State: ALoCoQmb072DThzoPnv+Yjo2qd5/OjuSP1YhRzZRgT7Za4mDAcPNR4MBTxQ2hw0O1jnqE+wIKF5R MIME-Version: 1.0 X-Received: by 10.55.81.11 with SMTP id f11mr29002992qkb.10.1449387098831; Sat, 05 Dec 2015 23:31:38 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Sat, 5 Dec 2015 23:31:38 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <5663E1FA.3060602@kronometrix.org> References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> <5663E1FA.3060602@kronometrix.org> Date: Sun, 6 Dec 2015 00:31:38 -0700 X-Google-Sender-Auth: zd8894K__3eXaFUa0xLy-SEn9Ao Message-ID: Subject: Re: Raspberry Pi Zero From: Warner Losh To: sparvu@kronometrix.org Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 07:31:40 -0000 On Sun, Dec 6, 2015 at 12:21 AM, Stefan Parvu wrote: > > > I haven=E2=80=99t looked, but most likely a new u-boot and/or other fir= mware is > required. > > Talking about this, reminds me something I always wanted to ask. > > Q: cant we deliver one image for RBPI, RBPI2, RBPI0 boards for example ? > Currently one has to download & use a different image for a different > board. Linux Raspbian does not have this model. > There's a number of minor technical hurdles in the way. There's different kernels so the boot loader would have to load the right one based on info from uboot. It isn't insurmountable, just nobody has broken down and done it yet. Warner From owner-freebsd-arm@freebsd.org Sun Dec 6 10:02:58 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0EEA7683 for ; Sun, 6 Dec 2015 10:02:58 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FFA8194C for ; Sun, 6 Dec 2015 10:02:58 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by wmuu63 with SMTP id u63so108337859wmu.0 for ; Sun, 06 Dec 2015 02:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=zdu1dtZoSipTCoqibY+U7NmpBCpoKr3DHwMw4FEJm3I=; b=FsUGGMj08tQAbANiG4HSc3lNGF6eGZdxign7tmNA8CeSS5TlTCpFG0mFhCUjOuT9qq UipXWzm1F47hLDRxg+H5xRmiQGZDTnypkZi+slkNlwOrlW7wCk1ktKWOmwzHg9URt6d9 0JKHM9NjKPHcHu/JEnB1zSP4hjlajXfeDXUTYoOEI18W6y4rwuQNzqe8vPUt5NZLhL+g dXDKNvicpRQGwV+oJs34RzjwgnUJQ9oR6doD2YRjzZTZx5q8altAnqBguRydmpO06b8X 4/bHqheqwoQV7mUb5O6m+bH+2eytcoBnW+jYPe5qS1YZXchcKTGOiCKS+J3WyZvUMM0W wc/w== X-Received: by 10.28.158.198 with SMTP id h189mr14232600wme.15.1449396176880; Sun, 06 Dec 2015 02:02:56 -0800 (PST) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id h4sm19833092wjx.41.2015.12.06.02.02.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 02:02:56 -0800 (PST) Subject: Re: Raspberry Pi Zero To: freebsd-arm@freebsd.org, Stefan Parvu References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> <5663E1FA.3060602@kronometrix.org> From: Jukka Ukkonen X-Enigmail-Draft-Status: N1110 Message-ID: <566407CE.4020403@gmail.com> Date: Sun, 6 Dec 2015 12:02:54 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5663E1FA.3060602@kronometrix.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 10:02:58 -0000 On 12/06/15 09:21, Stefan Parvu wrote: > >> I haven’t looked, but most likely a new u-boot and/or other firmware is required. > > Talking about this, reminds me something I always wanted to ask. > > Q: cant we deliver one image for RBPI, RBPI2, RBPI0 boards for example ? > Currently one has to download & use a different image for a different > board. Linux Raspbian does not have this model. > > Why is this on FreeBSD ARM ? > > thanks, > I guess there is also the little issue that because RPI2 supports hardware floating point operations, it also makes sense to compile the user space with the hardware floating enabled. So, in addition to separate kernels one might quite reasonably wish to have also separate user space libraries and binaries. Additionally RPI2 needs SMP support RPI-B does not. If the same common image had to support both, the image would end up being suboptimal for both. --jau From owner-freebsd-arm@freebsd.org Sun Dec 6 12:53:46 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EBE4A44A for ; Sun, 6 Dec 2015 12:53:46 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B6991C97 for ; Sun, 6 Dec 2015 12:53:45 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (188-127-209-196.cust.suomicom.net [188.127.209.196]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id tB6CraaR049734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 6 Dec 2015 12:53:37 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org Subject: Re: Raspberry Pi Zero References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> <5663E1FA.3060602@kronometrix.org> To: "freebsd-arm@freebsd.org" From: Stefan Parvu Organization: kronometrix.org Message-ID: <56642FCB.80407@kronometrix.org> Date: Sun, 6 Dec 2015 14:53:31 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 12:53:46 -0000 > There's a number of minor technical hurdles in the way. There's > different kernels > so the boot loader would have to load the right one based on info from > uboot. > It isn't insurmountable, just nobody has broken down and done it yet. Right. Thanks. Would make sense to have a single image for armv6, v7 to easy freebsd adoption vs linux on RBPI platform. > > Warner -- Stefan Parvu From owner-freebsd-arm@freebsd.org Sun Dec 6 16:20:46 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83D659A0106 for ; Sun, 6 Dec 2015 16:20:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FE6610F4 for ; Sun, 6 Dec 2015 16:20:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkeg192 with SMTP id g192so17150097qke.1 for ; Sun, 06 Dec 2015 08:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=grfqogDX0P6CCcXzR1+zGs20InZHiQPswqbqRB5PTWE=; b=GJFQBmUvLYJdQv/c4Q1OKNGrXA/fQsoaLh1uLUDpMoH65sP7lB3P2QiQQEGZhDRKEK 68E2sGoA4L5R+GWG8girCDzDUI5W71SiA0F3lmOqYTTJD7cj7yll2m15EV4WLORPpBNA KG13r30UEzcWJXfNt6By/I1MFsgzsJIDsJZfhV6y/F6Xs2HOIatCtwTNHTyw3svvjPj9 0cBMrLGM1ulbhLX4KCXLy/pKqlnP4rm0YykQpxD+fx3m3p34vQSmsKDfcninDL/Zvrh6 pplH5KOhbGgtHWW6XqU8Pf5vxn3DrC0V4K+6yhTfM0CuY2TuKs60D31JhjF6cxIt/1uL 23gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=grfqogDX0P6CCcXzR1+zGs20InZHiQPswqbqRB5PTWE=; b=DvW4K3ErHb74eFntdNwuhN+cvC//Hh2D+dfrF48tX+BGrvkZeQNgYvfZTzOaKzTrVr KMCnyrDEf4BWi15WXDgtg1PUXVvNLezddSkCLNOd6bsCbH+CSmt3O4axBMp+yB9S+mrv nuEHmItV6Y1TWpOC44eTZVtXXm6U40J+ypVQM8zJk/NMZQUfyb7DiDlgwL3pPqX/KcYF RvPGLxtOK4dNulA/LvIvew5z5zAaosUY8T1PzRb2GvzRoEpW+9Re4mPEtVQe9AhObwaA DxcfCC8VbGRd7v9L2LNAH1RhcfGzUSZg6K7wF/nR2aU2rFvzwpjHw3yQGBc1KizYLJrS 4Q8Q== X-Gm-Message-State: ALoCoQlrc9gVcj1xU6ywxH48RJk7ZzX1UzHBC2JkD6OMNRuopqg3yvXrb+meSFguomkj4BaNOIEU MIME-Version: 1.0 X-Received: by 10.55.23.170 with SMTP id 42mr30851776qkx.42.1449418844356; Sun, 06 Dec 2015 08:20:44 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Sun, 6 Dec 2015 08:20:44 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <566407CE.4020403@gmail.com> References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> <5663E1FA.3060602@kronometrix.org> <566407CE.4020403@gmail.com> Date: Sun, 6 Dec 2015 09:20:44 -0700 X-Google-Sender-Auth: 3N8_U14igVUHhkgQY0IXuZb-B0A Message-ID: Subject: Re: Raspberry Pi Zero From: Warner Losh To: Jukka Ukkonen Cc: "freebsd-arm@freebsd.org" , Stefan Parvu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 16:20:46 -0000 On Sun, Dec 6, 2015 at 3:02 AM, Jukka Ukkonen wrote: > On 12/06/15 09:21, Stefan Parvu wrote: > > > >> I haven=E2=80=99t looked, but most likely a new u-boot and/or other fi= rmware is > required. > > > > Talking about this, reminds me something I always wanted to ask. > > > > Q: cant we deliver one image for RBPI, RBPI2, RBPI0 boards for example = ? > > Currently one has to download & use a different image for a different > > board. Linux Raspbian does not have this model. > > > > Why is this on FreeBSD ARM ? > > > > thanks, > > > > I guess there is also the little issue that because > RPI2 supports hardware floating point operations, > Both support hardware floating point. RPi B vfp v2, and the RPi2 vfp v3. > it also makes sense to compile the user space with > the hardware floating enabled. So, in addition to > separate kernels one might quite reasonably wish to > have also separate user space libraries and binaries. > It's desirable, but not for the floating point reason. > Additionally RPI2 needs SMP support RPI-B does not. > If the same common image had to support both, the > image would end up being suboptimal for both. The suboptimality isn't so great. After I sent the mail last night, I realized that there's other differences between the two CPUs that require different DTBs, different firmware to be loaded into the GPU, and likely a host of other minor things. Surmountable (since the base firmware / IPL supports it), but lots of work. Warner From owner-freebsd-arm@freebsd.org Sun Dec 6 16:45:46 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCA289A073C for ; Sun, 6 Dec 2015 16:45:46 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 8F8741F57 for ; Sun, 6 Dec 2015 16:45:46 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.1 cv=C8BJsV7+ c=1 sm=1 tr=0 a=kLIaxcRmAfIWWG5Fo3VFTQ==:117 a=kLIaxcRmAfIWWG5Fo3VFTQ==:17 a=K-v-2zaBAAAA:8 a=OA2lqS22AAAA:8 a=NEAV23lmAAAA:8 a=7Qk2ozbKAAAA:8 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=xOAbDO-GYFArAQ9I_9oA:9 a=QEXdDO2ut3YA:10 a=DovCaeFo1AtV_PTIHfoA:9 a=b-JxYfF9AKXlYkD5:21 a=_W_S_7VecoQA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 24.148.20.83 is neither permitted nor denied by domain of rcn.com) Received: from [24.148.20.83] ([24.148.20.83:11047] helo=[192.168.1.175]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPSA (cipher=AES256-SHA) id B5/71-12961-23664665; Sun, 06 Dec 2015 11:45:39 -0500 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Raspberry Pi Zero From: Erik Moe In-Reply-To: Date: Sun, 6 Dec 2015 10:45:38 -0600 Cc: Jukka Ukkonen , "freebsd-arm@freebsd.org" Message-Id: References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> <5663E1FA.3060602@kronometrix.org> <566407CE.4020403@gmail.com> To: Warner Losh X-Mailer: Apple Mail (2.3096.5) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 16:45:46 -0000 Firmware was the issue. I mounted the MSDOS partition of the latest = RPI-B snapshot, replaced bootcode.bin, fixup.dat, fixup_cd.dat, = start.elf and start_cd.elf from https://github.com/raspberrypi/firmware = and the Zero booted right up = into multi-user mode. It didn=E2=80=99t seem to mind that the DTB was = for the RPI-B. Erik > On Dec 6, 2015, at 10:20 AM, Warner Losh wrote: >=20 > On Sun, Dec 6, 2015 at 3:02 AM, Jukka Ukkonen = wrote: >=20 >> On 12/06/15 09:21, Stefan Parvu wrote: >>>=20 >>>> I haven=E2=80=99t looked, but most likely a new u-boot and/or other = firmware is >> required. >>>=20 >>> Talking about this, reminds me something I always wanted to ask. >>>=20 >>> Q: cant we deliver one image for RBPI, RBPI2, RBPI0 boards for = example ? >>> Currently one has to download & use a different image for a = different >>> board. Linux Raspbian does not have this model. >>>=20 >>> Why is this on FreeBSD ARM ? >>>=20 >>> thanks, >>>=20 >>=20 >> I guess there is also the little issue that because >> RPI2 supports hardware floating point operations, >>=20 >=20 > Both support hardware floating point. RPi B vfp v2, and > the RPi2 vfp v3. >=20 >=20 >> it also makes sense to compile the user space with >> the hardware floating enabled. So, in addition to >> separate kernels one might quite reasonably wish to >> have also separate user space libraries and binaries. >>=20 >=20 > It's desirable, but not for the floating point reason. >=20 >=20 >> Additionally RPI2 needs SMP support RPI-B does not. >> If the same common image had to support both, the >> image would end up being suboptimal for both. >=20 >=20 > The suboptimality isn't so great. >=20 > After I sent the mail last night, I realized that there's > other differences between the two CPUs that require different > DTBs, different firmware to be loaded into the GPU, and > likely a host of other minor things. Surmountable (since the > base firmware / IPL supports it), but lots of work. >=20 > Warner > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://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 Dec 6 16:47:10 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 520A39A077C for ; Sun, 6 Dec 2015 16:47:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C8881FBD for ; Sun, 6 Dec 2015 16:47:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgcc31 with SMTP id c31so126995500qgc.3 for ; Sun, 06 Dec 2015 08:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Bfn1BWjjKve21aXJClLTZZkUjBbnyV4LrgQcWOx6NYY=; b=jZ5tkK543GqdkpScx6k09GFK2Dgs6mu1EJ7udWzagFU4PmGNba+eNAxXQ2fTer1bjY UiRW+WytN1XIWtPYr0rsQQXgaYd9mhK3oQL2Et5TvNhooqOqQDbMiM63tqPgcH5DmKm1 rrgJZ4FKCuOjlj2QyJez7cAIPANCeMx20S5z5awY3B2aM84izvpceqtcScvLw7J+Yjdm vYr8YZW7iHJGmAJO3i1BQfPZNyZMvHTm7N25sjQ43iQ5hisshDQ3qAwXJMTlBHvP5U18 K7tpxiNonS0wCehvZQtmPYeCbpgU/g00VGnz/nz+DKiY9ZUy8A8wk9455ztxMFobkAY9 X3LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bfn1BWjjKve21aXJClLTZZkUjBbnyV4LrgQcWOx6NYY=; b=TdaSJLv3dhtt0i4Ek3BiOU2I4txpvZCVulOrUpoJRg7Zn57H79TceO7uWxbcuOvv3a wpMEb4iFbxzCv/AIaZpcaoLASf6Gxokcn5K1Y2yg/I+ibqPi85m8+e1xpaGziqaFkbec RGts4fWl17EHP+GJO9TUF0s6mXdthbdY/kIhJxWRHEYDLi7hzjIsp1tvGe78VnQSGw9L qCgYzGX2ou6Y70aoUyPjtxX9NMM3mB9BVASizEXS81Ns21gZFw3Ktxz2aE4FZ0ANfgkk cYnTH3kPP+tEEhv5PgPNti5lcIs1pkKPlA3R7JIYXe8+OebYg2ZhW2E2pS42XjTog+TZ T9SQ== X-Gm-Message-State: ALoCoQnSLAd04HUiaL0F1mvfE79egRWHYsg6x/4/mVcabFXngp7eTT/wwf1SgS25ClNXnGsDMMXA MIME-Version: 1.0 X-Received: by 10.140.141.138 with SMTP id 132mr33283397qhn.74.1449420429050; Sun, 06 Dec 2015 08:47:09 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Sun, 6 Dec 2015 08:47:08 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> <5663E1FA.3060602@kronometrix.org> <566407CE.4020403@gmail.com> Date: Sun, 6 Dec 2015 09:47:08 -0700 X-Google-Sender-Auth: yA-K6kqhxBNjCzf9l0Puxk2Y5CU Message-ID: Subject: Re: Raspberry Pi Zero From: Warner Losh To: Erik Moe Cc: Jukka Ukkonen , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 16:47:10 -0000 On Sun, Dec 6, 2015 at 9:45 AM, Erik Moe wrote: > Firmware was the issue. I mounted the MSDOS partition of the latest RPI-= B > snapshot, replaced bootcode.bin, fixup.dat, fixup_cd.dat, start.elf and s= tart_cd.elf > from https://github.com/raspberrypi/firmware and the Zero booted right up > into multi-user mode. It didn=E2=80=99t seem to mind that the DTB was fo= r the > RPI-B. > > Cool. Any chance you can try the same image on an RPI-B? Warner From owner-freebsd-arm@freebsd.org Sun Dec 6 17:01:24 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DD2E9A09FE for ; Sun, 6 Dec 2015 17:01:24 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 EF5ED1867 for ; Sun, 6 Dec 2015 17:01:23 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.1 cv=A9fMR/iG c=1 sm=1 tr=0 a=kLIaxcRmAfIWWG5Fo3VFTQ==:117 a=kLIaxcRmAfIWWG5Fo3VFTQ==:17 a=K-v-2zaBAAAA:8 a=OA2lqS22AAAA:8 a=7Qk2ozbKAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=3olvETLvasRbs0x_uWIA:9 a=l1Fal589WkurqDKp:21 a=y7qbqilgmPMjeASx:21 a=QEXdDO2ut3YA:10 a=gKhY3kPDe0u02uml8FEA:9 a=HoCJXkmyxLhEHF5G:21 a=sv9QtaAm2QeMUOUd:21 a=wU1EUh2A8kUv6J3k:21 a=_W_S_7VecoQA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 24.148.20.83 is neither permitted nor denied by domain of rcn.com) Received: from [24.148.20.83] ([24.148.20.83:65156] helo=[192.168.1.175]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPSA (cipher=AES256-SHA) id 87/DC-58680-2E964665; Sun, 06 Dec 2015 12:01:22 -0500 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Raspberry Pi Zero From: Erik Moe In-Reply-To: Date: Sun, 6 Dec 2015 11:01:21 -0600 Cc: Jukka Ukkonen , "freebsd-arm@freebsd.org" Message-Id: References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> <5663E1FA.3060602@kronometrix.org> <566407CE.4020403@gmail.com> To: Warner Losh X-Mailer: Apple Mail (2.3096.5) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 17:01:24 -0000 > On Dec 6, 2015, at 10:47 AM, Warner Losh wrote: >=20 >=20 >=20 > On Sun, Dec 6, 2015 at 9:45 AM, Erik Moe > wrote: > Firmware was the issue. I mounted the MSDOS partition of the latest = RPI-B snapshot, replaced bootcode.bin, fixup.dat, fixup_cd.dat, = start.elf and start_cd.elf from https://github.com/raspberrypi/firmware = and the Zero booted right up = into multi-user mode. It didn=E2=80=99t seem to mind that the DTB was = for the RPI-B. >=20 >=20 > Cool. Any chance you can try the same image on an RPI-B?=20 Yes, I=E2=80=99m curious myself. I=E2=80=99ll give it a try >=20 > Warner=20 Granted it=E2=80=99s only running at 700Mhz. Is that a DTB thing or a = kernel thing? reading ubldr.bin 214704 bytes read in 29 ms (7.1 MiB/s) ## No elf image at address 0x00200000 ## Starting application at 0x00200000 ... Consoles: U-Boot console Compatible U-Boot API signature found @1db474d0 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@releng2.nyi.freebsd.org, Tue Dec 1 08:17:13 UTC 2015) DRAM: 480MB Number of U-Boot devices: 1 U-Boot env: loaderdev=3D'mmc 0' Found U-Boot device: disk Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2a: % /boot/kernel/kernel data=3D0x5d6aa4+0xe555c = syms=3D[0x4+0xc5fb0+0x4+0x94dbb] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x400100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2015 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 r291495: Tue Dec 1 08:23:29 UTC 2015 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B = arm FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 VT: init without driver. sema_sysinit 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 503312384 (479 MB) avail memory =3D 481800192 (459 MB) random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: mem 0x20000000-0x20ffffff = on ofwbus0 cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 intc0: mem 0xb200-0xb3ff on simplebus0 systimer0: mem 0x3000-0x3fff irq 8,9,10,11 on = simplebus0 Event timer "BCM2835-3" frequency 1000000 Hz quality 1000 Timecounter "BCM2835-3" 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-53. gpio0: reserved pins: 48-53. gpiobus0: on gpio0 gpioled0: at pin 16 on gpiobus0 gpioc0: on gpio0 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) vchiq0: mem 0xb800-0xb84f irq 2 on simplebus0 vchiq: local ver 8 (min 3), remote ver 8. pcm0: on vchiq0 bcm283x_dwcotg0: mem = 0x980000-0x99ffff irq 17 on simplebus0 usbus0 on bcm283x_dwcotg0 fb0: on ofwbus0 fbd0 on fb0 VT: initialize with new VT driver "fb". fb0: 656x416(656x416@0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x1eaac000, screen_size 818688 cryptosoft0: Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. usbus0: 480Mbps High Speed USB v2.0 bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF ugen0.1: at usbus0 uhub0: on usbus0 mmcsd0: 8GB at mmc0 = 41.6MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/rootfs [rw]... warning: no time-of-day clock registered, system time will not be set = accurately uhub0: 1 port with 1 removable, self powered Setting hostuuid: 83cb9b0d-9805-11e5-a352-0d59aa7881dc. Setting hostid: 0xb11e12a1. No suitable dump device was found. Starting file system checks: /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/rootfs: clean, 1736538 free (194 frags, 217043 blocks, 0.0% = fragmentation) Mounting local file systems:. Setting hostname: rpi-b. Setting up = harvesting:[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,K= EYBOARD,ATTACH,CACHED Feeding entropy:random: unblocking device. . Starting Network: lo0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=3D21 ELF ldconfig path: /lib /usr/lib /usr/lib/compat Starting devd. 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 Creating and/or trimming log files. Starting syslogd. Starting casperd. Clearing /tmp (X related). Updating motd:. Mounting late file systems:. Configuring vt: blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Tue Dec 1 08:34:11 UTC 2015 FreeBSD/arm (rpi-b) (ttyu0) login: Erik From owner-freebsd-arm@freebsd.org Sun Dec 6 22:56:11 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5118D9A0023 for ; Sun, 6 Dec 2015 22:56:11 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 11D731CF6 for ; Sun, 6 Dec 2015 22:56:11 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.1 cv=A9fMR/iG c=1 sm=1 tr=0 a=kLIaxcRmAfIWWG5Fo3VFTQ==:117 a=kLIaxcRmAfIWWG5Fo3VFTQ==:17 a=K-v-2zaBAAAA:8 a=OA2lqS22AAAA:8 a=IkcTkHD0fZMA:10 a=7Qk2ozbKAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=dekyxvedQrBI6J3IMO4A:9 a=ZdcB0r2LmxTnfm1T:21 a=z8sIpWzd745f_Kdb:21 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 24.148.20.83 is neither permitted nor denied by domain of rcn.com) Received: from [24.148.20.83] ([24.148.20.83:2447] helo=[192.168.1.175]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPSA (cipher=AES256-SHA) id AA/DB-58680-90DB4665; Sun, 06 Dec 2015 17:56:09 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Raspberry Pi Zero From: Erik Moe In-Reply-To: Date: Sun, 6 Dec 2015 16:56:07 -0600 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> <5663E1FA.3060602@kronometrix.org> <566407CE.4020403@gmail.com> To: Warner Losh X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 22:56:11 -0000 So the new firmware works on a RPI-B, RPI-B+, RPI-2 with the RPI-2 image = and RPI-Zero. So whatever changes were made to make the RPI-Zero work = are compatible with all the previous version of the Pi. So it just = seems a matter updating the u-boot-rpi and u-boot-rpi2 ports. Erik > On Dec 6, 2015, at 11:01 AM, Erik Moe wrote: >=20 >=20 >> On Dec 6, 2015, at 10:47 AM, Warner Losh wrote: >>=20 >>=20 >>=20 >> On Sun, Dec 6, 2015 at 9:45 AM, Erik Moe > wrote: >> Firmware was the issue. I mounted the MSDOS partition of the latest = RPI-B snapshot, replaced bootcode.bin, fixup.dat, fixup_cd.dat, = start.elf and start_cd.elf from https://github.com/raspberrypi/firmware = and the Zero booted right up = into multi-user mode. It didn=E2=80=99t seem to mind that the DTB was = for the RPI-B. >>=20 >>=20 >> Cool. Any chance you can try the same image on an RPI-B?=20 >=20 > Yes, I=E2=80=99m curious myself. I=E2=80=99ll give it a try >=20 >>=20 >> Warner=20 >=20 > Granted it=E2=80=99s only running at 700Mhz. Is that a DTB thing or a = kernel thing? >=20 > reading ubldr.bin > 214704 bytes read in 29 ms (7.1 MiB/s) > ## No elf image at address 0x00200000 > ## Starting application at 0x00200000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @1db474d0 >=20 > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@releng2.nyi.freebsd.org, Tue Dec 1 08:17:13 UTC 2015) >=20 > DRAM: 480MB > Number of U-Boot devices: 1 > U-Boot env: loaderdev=3D'mmc 0' > Found U-Boot device: disk > Checking unit=3D0 slice=3D partition=3D... good. > Booting from disk0s2a: % > /boot/kernel/kernel data=3D0x5d6aa4+0xe555c = syms=3D[0x4+0xc5fb0+0x4+0x94dbb] >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by U-Boot at address 0x100. > Kernel entry at 0x400100... > Kernel args: (null) > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2015 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 r291495: Tue Dec 1 08:23:29 UTC 2015 > root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B = arm > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 > VT: init without driver. > sema_sysinit > 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 503312384 (479 MB) > avail memory =3D 481800192 (459 MB) > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > simplebus0: mem = 0x20000000-0x20ffffff on ofwbus0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > bcm2835_cpufreq0: on cpu0 > intc0: mem 0xb200-0xb3ff on simplebus0 > systimer0: mem 0x3000-0x3fff irq 8,9,10,11 on = simplebus0 > Event timer "BCM2835-3" frequency 1000000 Hz quality 1000 > Timecounter "BCM2835-3" 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-53. > gpio0: reserved pins: 48-53. > gpiobus0: on gpio0 > gpioled0: at pin 16 on gpiobus0 > gpioc0: on gpio0 > 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) > vchiq0: mem 0xb800-0xb84f irq 2 on simplebus0 > vchiq: local ver 8 (min 3), remote ver 8. > pcm0: on vchiq0 > bcm283x_dwcotg0: mem = 0x980000-0x99ffff irq 17 on simplebus0 > usbus0 on bcm283x_dwcotg0 > fb0: on ofwbus0 > fbd0 on fb0 > VT: initialize with new VT driver "fb". > fb0: 656x416(656x416@0,0) 24bpp > fb0: fbswap: 1, pitch 1968, base 0x1eaac000, screen_size 818688 > cryptosoft0: > Timecounters tick every 10.000 msec > IPsec: Initialized Security Association Processing. > usbus0: 480Mbps High Speed USB v2.0 > bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF > ugen0.1: at usbus0 > uhub0: on = usbus0 > mmcsd0: 8GB at mmc0 = 41.6MHz/4bit/65535-block > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > warning: no time-of-day clock registered, system time will not be set = accurately > uhub0: 1 port with 1 removable, self powered > Setting hostuuid: 83cb9b0d-9805-11e5-a352-0d59aa7881dc. > Setting hostid: 0xb11e12a1. > No suitable dump device was found. > Starting file system checks: > /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/ufs/rootfs: clean, 1736538 free (194 frags, 217043 blocks, 0.0% = fragmentation) > Mounting local file systems:. > Setting hostname: rpi-b. > Setting up = harvesting:[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,K= EYBOARD,ATTACH,CACHED > Feeding entropy:random: unblocking device. > . > Starting Network: lo0. > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=3D21 > ELF ldconfig path: /lib /usr/lib /usr/lib/compat > Starting devd. > 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 > Creating and/or trimming log files. > Starting syslogd. > Starting casperd. > Clearing /tmp (X related). > Updating motd:. > Mounting late file systems:. > Configuring vt: blanktime. > Performing sanity check on sshd configuration. > Starting sshd. > Starting cron. > Starting background file system checks in 60 seconds. >=20 > Tue Dec 1 08:34:11 UTC 2015 >=20 > FreeBSD/arm (rpi-b) (ttyu0) >=20 > login: >=20 > Erik >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://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 Dec 6 22:56:11 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBF8D9A001D for ; Sun, 6 Dec 2015 22:56:10 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 B9E381CF5 for ; Sun, 6 Dec 2015 22:56:10 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.1 cv=A9fMR/iG c=1 sm=1 tr=0 a=kLIaxcRmAfIWWG5Fo3VFTQ==:117 a=kLIaxcRmAfIWWG5Fo3VFTQ==:17 a=K-v-2zaBAAAA:8 a=OA2lqS22AAAA:8 a=IkcTkHD0fZMA:10 a=7Qk2ozbKAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=dekyxvedQrBI6J3IMO4A:9 a=ZdcB0r2LmxTnfm1T:21 a=z8sIpWzd745f_Kdb:21 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 24.148.20.83 is neither permitted nor denied by domain of rcn.com) Received: from [24.148.20.83] ([24.148.20.83:2447] helo=[192.168.1.175]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPSA (cipher=AES256-SHA) id 4A/DB-58680-80DB4665; Sun, 06 Dec 2015 17:56:08 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Raspberry Pi Zero From: Erik Moe In-Reply-To: Date: Sun, 6 Dec 2015 16:56:07 -0600 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1BA9B6BD-A0C1-4E15-852B-A82D5A0416C5@rcn.com> References: <44D770D9-F1EF-461E-BB1A-8A19E9FB4BC8@rcn.com> <4D7C44B3-8135-4431-A07B-6135284D0C02@bsdimp.com> <5663E1FA.3060602@kronometrix.org> <566407CE.4020403@gmail.com> To: Warner Losh X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 22:56:11 -0000 So the new firmware works on a RPI-B, RPI-B+, RPI-2 with the RPI-2 image = and RPI-Zero. So whatever changes were made to make the RPI-Zero work = are compatible with all the previous version of the Pi. So it just = seems a matter updating the u-boot-rpi and u-boot-rpi2 ports. Erik > On Dec 6, 2015, at 11:01 AM, Erik Moe wrote: >=20 >=20 >> On Dec 6, 2015, at 10:47 AM, Warner Losh wrote: >>=20 >>=20 >>=20 >> On Sun, Dec 6, 2015 at 9:45 AM, Erik Moe > wrote: >> Firmware was the issue. I mounted the MSDOS partition of the latest = RPI-B snapshot, replaced bootcode.bin, fixup.dat, fixup_cd.dat, = start.elf and start_cd.elf from https://github.com/raspberrypi/firmware = and the Zero booted right up = into multi-user mode. It didn=E2=80=99t seem to mind that the DTB was = for the RPI-B. >>=20 >>=20 >> Cool. Any chance you can try the same image on an RPI-B?=20 >=20 > Yes, I=E2=80=99m curious myself. I=E2=80=99ll give it a try >=20 >>=20 >> Warner=20 >=20 > Granted it=E2=80=99s only running at 700Mhz. Is that a DTB thing or a = kernel thing? >=20 > reading ubldr.bin > 214704 bytes read in 29 ms (7.1 MiB/s) > ## No elf image at address 0x00200000 > ## Starting application at 0x00200000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @1db474d0 >=20 > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@releng2.nyi.freebsd.org, Tue Dec 1 08:17:13 UTC 2015) >=20 > DRAM: 480MB > Number of U-Boot devices: 1 > U-Boot env: loaderdev=3D'mmc 0' > Found U-Boot device: disk > Checking unit=3D0 slice=3D partition=3D... good. > Booting from disk0s2a: % > /boot/kernel/kernel data=3D0x5d6aa4+0xe555c = syms=3D[0x4+0xc5fb0+0x4+0x94dbb] >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by U-Boot at address 0x100. > Kernel entry at 0x400100... > Kernel args: (null) > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2015 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 r291495: Tue Dec 1 08:23:29 UTC 2015 > root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B = arm > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 > VT: init without driver. > sema_sysinit > 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 503312384 (479 MB) > avail memory =3D 481800192 (459 MB) > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > simplebus0: mem = 0x20000000-0x20ffffff on ofwbus0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > bcm2835_cpufreq0: on cpu0 > intc0: mem 0xb200-0xb3ff on simplebus0 > systimer0: mem 0x3000-0x3fff irq 8,9,10,11 on = simplebus0 > Event timer "BCM2835-3" frequency 1000000 Hz quality 1000 > Timecounter "BCM2835-3" 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-53. > gpio0: reserved pins: 48-53. > gpiobus0: on gpio0 > gpioled0: at pin 16 on gpiobus0 > gpioc0: on gpio0 > 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) > vchiq0: mem 0xb800-0xb84f irq 2 on simplebus0 > vchiq: local ver 8 (min 3), remote ver 8. > pcm0: on vchiq0 > bcm283x_dwcotg0: mem = 0x980000-0x99ffff irq 17 on simplebus0 > usbus0 on bcm283x_dwcotg0 > fb0: on ofwbus0 > fbd0 on fb0 > VT: initialize with new VT driver "fb". > fb0: 656x416(656x416@0,0) 24bpp > fb0: fbswap: 1, pitch 1968, base 0x1eaac000, screen_size 818688 > cryptosoft0: > Timecounters tick every 10.000 msec > IPsec: Initialized Security Association Processing. > usbus0: 480Mbps High Speed USB v2.0 > bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF > ugen0.1: at usbus0 > uhub0: on = usbus0 > mmcsd0: 8GB at mmc0 = 41.6MHz/4bit/65535-block > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > warning: no time-of-day clock registered, system time will not be set = accurately > uhub0: 1 port with 1 removable, self powered > Setting hostuuid: 83cb9b0d-9805-11e5-a352-0d59aa7881dc. > Setting hostid: 0xb11e12a1. > No suitable dump device was found. > Starting file system checks: > /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/ufs/rootfs: clean, 1736538 free (194 frags, 217043 blocks, 0.0% = fragmentation) > Mounting local file systems:. > Setting hostname: rpi-b. > Setting up = harvesting:[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,K= EYBOARD,ATTACH,CACHED > Feeding entropy:random: unblocking device. > . > Starting Network: lo0. > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=3D21 > ELF ldconfig path: /lib /usr/lib /usr/lib/compat > Starting devd. > 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 > Creating and/or trimming log files. > Starting syslogd. > Starting casperd. > Clearing /tmp (X related). > Updating motd:. > Mounting late file systems:. > Configuring vt: blanktime. > Performing sanity check on sshd configuration. > Starting sshd. > Starting cron. > Starting background file system checks in 60 seconds. >=20 > Tue Dec 1 08:34:11 UTC 2015 >=20 > FreeBSD/arm (rpi-b) (ttyu0) >=20 > login: >=20 > Erik >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://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 Dec 7 17:18:10 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AB539B9D1D for ; Mon, 7 Dec 2015 17:18:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 D0FB81066 for ; Mon, 7 Dec 2015 17:18:09 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 6FBF622C0A8 for ; Mon, 7 Dec 2015 11:18:01 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Supported WiFi adapters on the Pi2? Message-ID: <5665BF2F.1010207@denninger.net> Date: Mon, 7 Dec 2015 11:17:35 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000803010106080807080200" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 17:18:10 -0000 This is a cryptographically signed message in MIME format. --------------ms000803010106080807080200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have the following in the machine that is not being found: ugen0.4: at usbus0 urtwn0: on usbus0 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R There's a kernel module for if_urtwn, but it's not showing up. There is also a rtl8188_*eu*_fw.ko kernel module (which I can manually load) but it does not attach (that looks like a Euro-area one, if the EU is meaningful) This adapter does identify and work under Rasperian; what can I expect to have work under FreeBSD 11-CURRENT? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000803010106080807080200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMDcxNzE3MzVaME8GCSqGSIb3DQEJBDFCBECC zRoXzDob1CZWUEyhSEFsJY98wIL+zuiLunKrBuSLJNO8TudStRVgFuoeYOiAUj7dDQEb4Yd0 sxhWRzY8qorPMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAQfLytkLK GMZvtM6wYttQuV+Y3rAJYXohAPgJyJNzeubJjITysWfhzgtvPs1R5FMKTUaAF//ur+wYEvQj k7/OszoMshG2HtXIFA+mBpJfHJr6vZ2WZglbD08K9X3aDb7+SWyA1dZrkTw3XCBXdli+7x0T 5f8FyHoKrl5sJVTliAQuWnwLl/gSSNBMVPb7UMbR/7uLI+PGJdAvon4PTjVXC6UtuwjZZQeC j4SMjH/W+5ukBVsIU8QXnUgI5EiVFnS09vjPyRmnijHO5bn5H5VLPUzeCmHsJtbbrNJ8vffB Yl2YkYgiC+U+WX6uVFtnh4oAbwl2BVBeJitixjcYjRnlLWzwTiLIUen5K7Vk3EXocKA4LeWH MtEYaOK1leKVkarOBMntfkH32mfjm0YS1BbQnsvEM6VTkj/q4y1XfbKLtt8HaXR7s8P8UnI2 AXVDws2oxaTR2NNx/qOeddv9/nIYMu+U6whNV03l2OQfVL+N9nzcmXQBkqRKGyiJoo08TDdP 6bVhzqNyK7islgWXOKHZVNiN9DSFc3K69CYmTX0isI8KaNkjEbtzQOOcO6eaGxUFz+GDlhp1 zM0jdsO7TIf9bTyXhwRU2TZ8x9c2qUnkgJmb/kC4CxRAtmcaKUhNZXxbKpqA41ihH1XGRIUl lMKRU8tZODYtB5sp/S4BOqVdk1kAAAAAAAA= --------------ms000803010106080807080200-- From owner-freebsd-arm@freebsd.org Mon Dec 7 17:45:52 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B19F99B7816 for ; Mon, 7 Dec 2015 17:45:52 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 527041827 for ; Mon, 7 Dec 2015 17:45:52 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: by wmuu63 with SMTP id u63so150628322wmu.0 for ; Mon, 07 Dec 2015 09:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bris-ac-uk.20150623.gappssmtp.com; s=20150623; h=date:from:message-id:to:subject:reply-to:in-reply-to; bh=ZYpTjsWFcOC9cjd9WjZwwsSGPynQJkgocxnOkOdVKgo=; b=L5LkB2vcj4HxinN48Ta16Z5omS6QOUzD+e+FL3vvRE5J5pjY/740p+BzZcwXcCcrGq SGBeaVimtfJFlXSaFgpcdOXORfa8L1FsZMRJmodZaqQi8VLvScYrCpcxQ9kyT+Etg6Y8 Gn3LMEZmLBaO80SZuG8M+WUhVrucaaNXaJmPNcpOmyF/iz11Mz8drygS8B35koYrq8Gx /XtnuB1btZ8/h4viVK7Zl7GOIw3Hl5ShnLhMVeFQLoY9tntzk/Y7oqjcWOM9kXNbSomv tEH+FrhRY1Aqz1VrNMUKul59EIpd+N9JuUMG8Y2rnUQrhG3oxw9xh5prEY3ZxAUggY+K 3s/A== 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=ZYpTjsWFcOC9cjd9WjZwwsSGPynQJkgocxnOkOdVKgo=; b=ML2kpgsqKA7tVeOjNaOPYX6LrtN4mjR6UVw9tiDalgqe7aKNf0XHYP6xivFSwFROTt qWiOC6JvXtxDEeGh4gLuU0th7hdqdB3An8xXTzCFrA/nHpXxKiSYJRDt43+5cioPygSX bDpZsooRI5YLIADfRSBQ617AHiI63kvlAQ/i8edTu/7sJWMC/XEIvCy81Ug95e+zgBOV 1My79ravv6YFrcmcb1uENPlCLtvXNxqytGiZ8lztcP6MkTnNvh6oTUM9amW/mN74UJ/C W4YUCamL5cKXoLk0+1Z7B7B/BGYkiz6KkKIHYpanSW1fvkViye0FlaXaXZ5JUftLVIoG 1KjA== X-Gm-Message-State: ALoCoQnWeisEwUCgMtv0n/dkFJFXkHYZhkFN75KPK1mojSRJTTyLS8PcBTDRGyJLUCZSIpMUenXat2ihoD0+D797qpO3Ttysgw== X-Received: by 10.28.189.11 with SMTP id n11mr24317971wmf.27.1449510350647; Mon, 07 Dec 2015 09:45:50 -0800 (PST) Received: from mech-as222.men.bris.ac.uk (mech-as222.men.bris.ac.uk. [137.222.170.4]) by smtp.gmail.com with ESMTPSA id 186sm17749264wmv.9.2015.12.07.09.45.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2015 09:45:50 -0800 (PST) Date: Mon, 07 Dec 2015 09:45:50 -0800 (PST) X-Google-Original-Date: Mon, 7 Dec 2015 17:45:46 GMT Received: from mech-as222.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2) with ESMTP id tB7Hjk6P048428; Mon, 7 Dec 2015 17:45:46 GMT (envelope-from mexas@mech-as222.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2/Submit) id tB7Hjkqu048427; Mon, 7 Dec 2015 17:45:46 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201512071745.tB7Hjkqu048427@mech-as222.men.bris.ac.uk> To: freebsd-arm@freebsd.org, karl@denninger.net Subject: Re: Supported WiFi adapters on the Pi2? Reply-To: mexas@bris.ac.uk In-Reply-To: <5665BF2F.1010207@denninger.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 17:45:52 -0000 >I have the following in the machine that is not being found: > >ugen0.4: at usbus0 >urtwn0: >on usbus0 >urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R http://lists.freebsd.org/pipermail/freebsd-wireless/2015-December/006320.html Anton From owner-freebsd-arm@freebsd.org Mon Dec 7 19:53:59 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 342D59C1970 for ; Mon, 7 Dec 2015 19:53:59 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 D692C173E for ; Mon, 7 Dec 2015 19:53:58 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 262F222CCD2 for ; Mon, 7 Dec 2015 13:53:56 -0600 (CST) Subject: Re: Supported WiFi adapters on the Pi2? References: <201512071745.tB7Hjkqu048427@mech-as222.men.bris.ac.uk> To: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <5665E3BA.5070808@denninger.net> Date: Mon, 7 Dec 2015 13:53:30 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <201512071745.tB7Hjkqu048427@mech-as222.men.bris.ac.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090808040905050302080400" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 19:53:59 -0000 This is a cryptographically signed message in MIME format. --------------ms090808040905050302080400 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/7/2015 11:45, Anton Shterenlikht wrote: >> I have the following in the machine that is not being found: >> >> ugen0.4: at usbus0 >> urtwn0: >> on usbus0 >> urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > http://lists.freebsd.org/pipermail/freebsd-wireless/2015-December/00632= 0.html > > Anton Uh, nope. Not fixed with kernel just re-compiled after an "svn update" Seems to be solved in r291907. Can anybody reproduce this? Anton $ uname -v FreeBSD 11.0-CURRENT #3 r291949M: Mon Dec 7 13:37:41 CST 2015 karl@I= PGw.Denninger.Net:/mnt/obj/mnt/usr/src/sys/RPI2 =2E... urtwn0: = on usbus0 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R $ kldstat Id Refs Address Size Name 1 11 0xc0100000 7eef24 kernel 2 1 0xc41de000 1a000 if_urtwn.ko 3 1 0xc41f8000 51000 wlan.ko 4 1 0xc4253000 b000 firmware.ko $ $ ifconfig -a lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=3D21 ue0: flags=3D8843 metric 0 mtu 15= 00 options=3D80001 ether b8:27:eb:0d:05:01 inet 192.168.1.215 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 Not found. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090808040905050302080400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMDcxOTUzMzBaME8GCSqGSIb3DQEJBDFCBEDN CY0GuBE0pPX57gj0hztEPZTS/40l/egyl8hqjGJbE0frjCNnjDRo9seO4wHHugHhUk3qNlIx xgVCRgNilr/iMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAHstIJjon A3YuanGWI448IkslgLK5OqrqtE1WLAhQbc+cCyofX3mUMuTy2JeCg0IQEsZrl1Iu1k5GuLXE s14x+WS9mggSpj6vblEKsgJ9nL6X6OSF70PEUc3Yr2BqBBCqsQOTNjUCmuz5Qbxt49lY0tkG /JVO8szViKWklvJfW6Zc25DOEaa2SmwhsQLGrNjqvJxx7kyzBn8T0PEjByF/e1TDQ3OICX+h cKsecc9vTb2lloSYfCl6AbLIikvW8ufcTaLe6FDd47Ptya6C1z0+oXefIqIZNUtiMXGwnZqJ jKZKEiTUipHoTnWq+e6+ye6RldKBkRocJ+X860UxcUcPKISzu+43pShJ1Dfl4gZ4xU7qaIdS 0e2kFJeKrgIdxaJFfl1cnluD0mqQnTOhKq00wTwuaY8VD3/N6oBetKPzbgMcWv7lACF/q9+i i3i4iBj72aTyJ2W53XS0xwuDtFkhYWOC01Uzk7apkdljzqgU8CC1wNLF7xHDMMieGkk94b6L JW02/vFoR10bzz1qdOhCwAPjJFahner21ny7uOO3PrAkun6mqv1Sko9ioQ68So5FanWFUfTP tXyqtgHec5JhdDNG5Xmrcfc1A0X+hDtZ7xbfq7s97+kV2eWkNYgpByO9q4eBYYBIRBcPCLQK F/8822q2H1Y9zAEspJJPMUcGnZgAAAAAAAA= --------------ms090808040905050302080400-- From owner-freebsd-arm@freebsd.org Mon Dec 7 20:03:02 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2E529B7169 for ; Mon, 7 Dec 2015 20:03:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C75B61B12 for ; Mon, 7 Dec 2015 20:03:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioir85 with SMTP id r85so1768786ioi.1 for ; Mon, 07 Dec 2015 12:03:01 -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=gRb6YJkPEEY74CReAOKZSsXY0UKmeWjykbppYqtUoes=; b=QnpaXFxeP5KC84H0rOv8qfn6ajhzk8WnuWqXEA3w6KIz6YechfISvkrcF+/EDL6xJL xKMhCxGcQHuzlQQKvbE8n63vy0r3Td1C2Rt/oWlQ20H9uGB2lNLt0laJpBNf7+lOGmvN +zuopBicwViKNFdFKN/33kG8dxXplkm1lDJaNWTBwbkJNASfTNdoIfO2f6aMa7KmXWYA rnT8W3KbnfbMcfEKG7lrf43oo9AszbF06xkuz046JZBmLAGANe26oQ1F9eG6q9UHFE/V 237XipcEHQX9n1rISOIuNXA47hZAynK+2R5RPDfiy4t5rAps5Aof9A8fe6TkmAb0snOB A8Vw== MIME-Version: 1.0 X-Received: by 10.107.11.147 with SMTP id 19mr143223iol.165.1449518581312; Mon, 07 Dec 2015 12:03:01 -0800 (PST) Received: by 10.36.217.196 with HTTP; Mon, 7 Dec 2015 12:03:01 -0800 (PST) In-Reply-To: <5665E3BA.5070808@denninger.net> References: <201512071745.tB7Hjkqu048427@mech-as222.men.bris.ac.uk> <5665E3BA.5070808@denninger.net> Date: Mon, 7 Dec 2015 12:03:01 -0800 Message-ID: Subject: Re: Supported WiFi adapters on the Pi2? From: Adrian Chadd To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 20:03:02 -0000 it's there; sysctl net.wlan.devices -HEAD no longer lists the top level interfaces; you have to create wlan clones for them to show up. -a On 7 December 2015 at 11:53, Karl Denninger wrote: > > > On 12/7/2015 11:45, Anton Shterenlikht wrote: >>> I have the following in the machine that is not being found: >>> >>> ugen0.4: at usbus0 >>> urtwn0: >>> on usbus0 >>> urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R >> http://lists.freebsd.org/pipermail/freebsd-wireless/2015-December/006320.html >> >> Anton > Uh, nope. Not fixed with kernel just re-compiled after an "svn update" > > Seems to be solved in r291907. > Can anybody reproduce this? > > Anton > > $ uname -v > FreeBSD 11.0-CURRENT #3 r291949M: Mon Dec 7 13:37:41 CST 2015 karl@IPGw.Denninger.Net:/mnt/obj/mnt/usr/src/sys/RPI2 > > > .... > > urtwn0: on usbus0 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > > $ kldstat > Id Refs Address Size Name > 1 11 0xc0100000 7eef24 kernel > 2 1 0xc41de000 1a000 if_urtwn.ko > 3 1 0xc41f8000 51000 wlan.ko > 4 1 0xc4253000 b000 firmware.ko > $ > > > $ ifconfig -a > 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 > groups: lo > nd6 options=21 > ue0: flags=8843 metric 0 mtu 1500 > options=80001 > ether b8:27:eb:0d:05:01 > inet 192.168.1.215 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > > Not found. > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ From owner-freebsd-arm@freebsd.org Tue Dec 8 15:13:29 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB1439B9F32 for ; Tue, 8 Dec 2015 15:13:29 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 9E2551193 for ; Tue, 8 Dec 2015 15:13:28 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id AABE622CDFE for ; Tue, 8 Dec 2015 09:13:26 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Updating / keeping current strategies? Message-ID: <5666F37C.4060908@denninger.net> Date: Tue, 8 Dec 2015 09:13:00 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020804000302040202080407" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 15:13:30 -0000 This is a cryptographically signed message in MIME format. --------------ms020804000302040202080407 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What are people doing in this regard with devices like the Raspberry Pi2?= Build times for a "make buildworld" are measured in (many) hours to a day or more and require a USB-attached disk for temporary storage, as the ramdisk for /tmp that is typically mounted blows up due to lack of space and SD cards are slow enough on writes (especially small writes) as to make the process virtually impossible. But even with a USB-attached disk the process is ridiculous in terms of consumed walllclock time. Further, "make installworld" sometimes fails inexplicably. Kernel builds are a bit more reasonable, only requiring a couple of hours= =2E I'm wondering what the best option is to not only build current code on a regular basis (since -CURRENT is a "work in progress") but also to deploy and update existing devices. What are people doing that has a history of working well? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020804000302040202080407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMDgxNTEzMDBaME8GCSqGSIb3DQEJBDFCBEDy WS0njcixIZ4svEsThqA1tAsJmMcUZW+YjpFluq0++dk3Sgt5xa6myETSNMVJJiP08s7PJQAH 8/ReB2z68tMHMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAp8Xirgu5 6IFaYscRF+Ifa0rXcB7HLgdbNGrZe6BH8xlZJrUjcQC/mQDclgYF8mH6KOBX2/Qn8950lMhM XzpfffPOqYNZiXspKv7rIF0pLpTEEDQcRJr4VaL7hGrVsBhQ+yilFTvb95J1egmYtz9IREzz lZ/AKMJQfp33uGRYbVFTFafTyieYJbXbdMsYBU8boUn/ng2bWF5LPUgcd00VojYsQ68GanBm p+Ko9cxPQg9IggmWre2RruDG+hUuAFZY4SLnDLMSGIfwiiHmJGPn96JaBeixNvetsx9ELiHk sxN49Ge+ROlNMWEJzHoRv5JhWgabMvO4/KbBl/xkwn5d72CbbWV9Lyw9M6DJP5eGboctfTwR sK6+o/2HAG4afdf4jyRq9gqG+GEI8Y4BbNLVCRA7T9g+rbwEIFEvdTEfOTCiQmFbWjzxQmYo km2/HpH2fcoI+Y1lBnfKeSfMQvISVRzp3dKXDLWlgJ3j9RxCTsK1NvAWSAiVs+MNyci1DiA6 s+cV7uL6/1j+SO3ixUO+l3Kok9QWU8fSV3SFjx8Dvrqs17Z60QYnaE1X0TYbfL63zVGdhtry xAYebHzQ90LChFth5a3BrRRAXzbEJekeH1+3lyPA0zNIUTWA10ZHJWQwJIzaHmEK6fgUkzNA 1fBASu9vALA/QkopNII7qHl5MkMAAAAAAAA= --------------ms020804000302040202080407-- From owner-freebsd-arm@freebsd.org Tue Dec 8 15:52:03 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7E849D4D6A for ; Tue, 8 Dec 2015 15:52:03 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8398A1BFE for ; Tue, 8 Dec 2015 15:52:03 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from [10.23.5.100] (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id DF977151; Tue, 8 Dec 2015 10:42:03 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_FE4BA79A-1118-4940-87DE-76607F94AAEB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Updating / keeping current strategies? From: Paul Mather In-Reply-To: <5666F37C.4060908@denninger.net> Date: Tue, 8 Dec 2015 10:41:57 -0500 Cc: "freebsd-arm@freebsd.org" Message-Id: <10BBDDBB-75AA-4034-B494-9EB28D009882@gromit.dlib.vt.edu> References: <5666F37C.4060908@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 15:52:03 -0000 --Apple-Mail=_FE4BA79A-1118-4940-87DE-76607F94AAEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 8, 2015, at 10:13 AM, Karl Denninger wrote: > What are people doing in this regard with devices like the Raspberry = Pi2? >=20 > Build times for a "make buildworld" are measured in (many) hours to a > day or more and require a USB-attached disk for temporary storage, as > the ramdisk for /tmp that is typically mounted blows up due to lack of > space and SD cards are slow enough on writes (especially small writes) > as to make the process virtually impossible. But even with a > USB-attached disk the process is ridiculous in terms of consumed > walllclock time. >=20 > Further, "make installworld" sometimes fails inexplicably. >=20 > Kernel builds are a bit more reasonable, only requiring a couple of = hours. >=20 > I'm wondering what the best option is to not only build current code = on > a regular basis (since -CURRENT is a "work in progress") but also to > deploy and update existing devices. What are people doing that has a > history of working well? I cross-build kernel and world on a FreeBSD/amd64 system. It takes = about 30 minutes to do a full buildkernel and buildworld there. Then, = when I want to update my Raspberry Pi, I shut down the Pi and move the = SD card from it to the FreeBSD/amd64 system. Having mounted the SD = card, I cross-install kernel and world onto the SD card and then run = mergemaster against it. I use the wrapper script from = https://wiki.freebsd.org/FreeBSD/arm/crossbuild to make things easier. After updating the SD card, I unmount it from the FreeBSD/amd64 system = and move it back to the Raspberry Pi. Finally, I boot up the Raspberry = Pi. This has proved a reliable way for me to update my Raspberry Pi and = BeagleBone Black. The manual step of moving the SD card isn't ideal, = but has proved to be the most pragmatic approach for me. (Clang seems = more reliable on FreeBSD/amd64, for one.:) Someone suggested once to do = the cross build/install on the FreeBSD/amd64 system and then rsync over = to the Pi/BBB to update the SD card, but I could never get that to work. = Similarly, I could never get a NFS install to work either. To be fair, = I didn't troubleshoot that problem very much. Cheers, Paul. --Apple-Mail=_FE4BA79A-1118-4940-87DE-76607F94AAEB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDGDCCAxQw ggH8oAMCAQICAQIwCwYJKoZIhvcNAQEFMF8xFDASBgNVBAMMC1BhdWwgTWF0aGVyMR4wHAYDVQQL DBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgkqhkiG9w0BCQEMGHBhdWxAZ3JvbWl0LmhvbWV1 bml4Lm9yZzAeFw0wNzAxMTUwMTEwMjRaFw0zNDA2MDIwMTEwMjRaMD4xFDASBgNVBAMMC1BhdWwg TWF0aGVyMSYwJAYJKoZIhvcNAQkBDBdwYXVsQGdyb21pdC5kbGliLnZ0LmVkdTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANuOyAW3ePaKIkGeA9TBTmX1/zgeYrpVEv+GATC1wWV64nun lPyjRMVThrHwOG8OIZOZ0+Gm68Mbpf5xNodG9GoB0c6/bf14Rz/AOPTWE2ZIcDgfwvpYeZ3QwjpF o+8zKx0cVw1ZG/frLeYyQAReTbDun0zOo9xgiGXbMsiRZJfGKOjmY/aIg2sw0+Dze8qa8u24VbnE 7XJre24ZBkpVa5gdfdjS+2byqNnGf4NrCkf/3rRNRTS576K1e0R8VeRu9pYtcvMW8A+wILIEkrQX PjTDIdn2aDzc7CONJfFBvAjUw3npmt8ZpCVZgMmbZE1yDy2ksBB1SvKTCT+RFJpbRaMCAwEAATAN BgkqhkiG9w0BAQUFAAOCAQEAqHjAejHbhB48WVQ3MJAdSh4H9HRCou6O+NIctaE3NNv9ygX3oGLt dTDh8QTFp+Sgarm7evsUeYRUv5iPimV2/illl6CCr12m+csuNfVlHoqNSXJlqCiw+/YLTXz+uVCQ 9V5j3hEXYM+f6zKsEVA7ShB7fv4H994gsF/14m0wgnQd7jS1u0G2RJGOnPn7veiBlKz7C3mnMi8H NRKXR/oDJxGYa9FKO+f8KVu6PWULvrtjVi6Xu3jjd9lJabIYsvdNNiV6OS6na72QhyRIoNtMI0nk oMISL3jRU5HwHl/V8RkfRm+x3GX7vIfxMgSux3MLY766CAIgfhcGY83dgxjFCjGCAtgwggLUAgEB MGQwXzEUMBIGA1UEAwwLUGF1bCBNYXRoZXIxHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGCSqGSIb3DQEJAQwYcGF1bEBncm9taXQuaG9tZXVuaXgub3JnAgECMAkGBSsOAwIaBQCg ggFJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTIwODE1NDE1 OFowIwYJKoZIhvcNAQkEMRYEFCDhbO2FnFNGKCwJ5qQtN1F2+M3zMHMGCSsGAQQBgjcQBDFmMGQw XzEUMBIGA1UEAwwLUGF1bCBNYXRoZXIxHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0eTEn MCUGCSqGSIb3DQEJAQwYcGF1bEBncm9taXQuaG9tZXVuaXgub3JnAgECMHUGCyqGSIb3DQEJEAIL MWagZDBfMRQwEgYDVQQDDAtQYXVsIE1hdGhlcjEeMBwGA1UECwwVQ2VydGlmaWNhdGUgQXV0aG9y aXR5MScwJQYJKoZIhvcNAQkBDBhwYXVsQGdyb21pdC5ob21ldW5peC5vcmcCAQIwDQYJKoZIhvcN AQEBBQAEggEAzHbGFIXF5ZLKwAl21eUoVrS4A82GyGySE9TEBb7qLADUMen8n05D9SE3BECvRpdV kj6380INw1vUxyIi9nTfvqJwFQms7H4dlkeiUgN0fmUe84IKReuLyjg6FI5e73XLfeKvDXE1tgtx lvAIR9l9Dp7ShUJYsVae8qZIgJOTpfpHbTU/2VGH9dyJQVVBZP3pFXT58IS7rS/BHqSrU0XxYV1L V1DO/aYRdCv6ZVFu4V0ELj6KJgFk1ObrFFk8leLchr8VBmVexnV4UChEuWWIzNJi16e/ejJeYiEl mf34zszInQ7L1hKktYnB0mw2otkKPMsLuuUFfL/SjDqXrblTlgAAAAAAAA== --Apple-Mail=_FE4BA79A-1118-4940-87DE-76607F94AAEB-- From owner-freebsd-arm@freebsd.org Tue Dec 8 15:55:14 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 216FA9D30F3 for ; Tue, 8 Dec 2015 15:55:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFC8A1038 for ; Tue, 8 Dec 2015 15:55:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgcc31 with SMTP id c31so22028993qgc.3 for ; Tue, 08 Dec 2015 07:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=R0+sVJJl1NBTLugjb7zkay2LWBMtm2RzdLdig1cPMbg=; b=TIMCrnqRHTZG6rnhZqSh2bZ9DLtDRIG10oJ2O//saUKBowkAAuaKt2REu8ZP3kC4Ok 2pT1uBwMhnygqLqA2FHlqT2xVcFsm/xtAKh1JXlqsAZPoJgu+jNkiY4+oI2Vn1lHc5CV 3FYaFoAM5UCbBmV8VTFRlveucfaZTHD1cOLIEvLU8G0JSg3smgi+1qravnMytTvi+T7H 26tyT6bDxcePnVWyOigGW0LLlprlmi8/af8t70nZc2cqPRyyjKM1GwgHWnuV/PMJkWam U3rjZWCy6Ho3z5RoBTxvJw73kxDHUgK86oqnQGDIt6s0egFw1klqg0iUt1in07jgLrwD SCEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R0+sVJJl1NBTLugjb7zkay2LWBMtm2RzdLdig1cPMbg=; b=Cxa1Tx1UvdrBKdPNAuH8EkIa7jNN5JfcARWIjysXxsaAeZ2s1CqUYWi5dQQZlcp87v 0Q3js2kWX8FrxW68vntqbWtqJvONe7PxG50WkuHtLruwb9/yQBwJctFXHIa61ryNwlav veFKJlOZZkWN164XRmGXw+5Lx/a0xgk6rxOChsJ5OyJDPRgyZwbUTeeF3UPcOQ/ZKJQ4 Ae3xv8r8uNGimWTIXAEnw1Cgvmt9yIblgF/xIBczabdYd4eIp7RnCsQnzNsGXAdBje40 bnTTBEmIImbKm2ExyLUKhL3BifgxQpyVkx6Xf08FhLxnX/j4UIJ6FY0/PeYvB5mUgR7z pbaQ== X-Gm-Message-State: ALoCoQlEdhOX7kwXXQFgZPcuku4ujehDbuz4VEonEFmbr1BMU7VO6GCcB+wQv+Zp/eP5s11tzsvVb/lBUbaBjFAjDAO0Lgu0Gg== MIME-Version: 1.0 X-Received: by 10.140.176.143 with SMTP id w137mr6068104qhw.20.1449590112866; Tue, 08 Dec 2015 07:55:12 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Tue, 8 Dec 2015 07:55:12 -0800 (PST) X-Originating-IP: [2601:280:4900:3700:4d3f:8eba:ea86:7700] In-Reply-To: <5666F37C.4060908@denninger.net> References: <5666F37C.4060908@denninger.net> Date: Tue, 8 Dec 2015 08:55:12 -0700 X-Google-Sender-Auth: x1ezv3dnZu_UVXyeXk0lgNus6jk Message-ID: Subject: Re: Updating / keeping current strategies? From: Warner Losh To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 15:55:14 -0000 On Tue, Dec 8, 2015 at 8:13 AM, Karl Denninger wrote: > What are people doing in this regard with devices like the Raspberry Pi2? > > Build times for a "make buildworld" are measured in (many) hours to a > day or more and require a USB-attached disk for temporary storage, as > the ramdisk for /tmp that is typically mounted blows up due to lack of > space and SD cards are slow enough on writes (especially small writes) > as to make the process virtually impossible. But even with a > USB-attached disk the process is ridiculous in terms of consumed > walllclock time. > > Further, "make installworld" sometimes fails inexplicably. > > Kernel builds are a bit more reasonable, only requiring a couple of hours. > > I'm wondering what the best option is to not only build current code on > a regular basis (since -CURRENT is a "work in progress") but also to > deploy and update existing devices. What are people doing that has a > history of working well? > I've been updating for years. But usually building on another machine and then installing to the media of the embedded machine via NFS. This mostly works and isn't too sucky. But there are problems with this approach, since high write work loads tend to bog down the embedded box due to crappy storage being used (eg SD cards, USB attachment or both). You may have noticed some commits to nanobsd I've been making lately. I'm moving all my local boards over to nanobsd with a ping-pong partition. I'd create a new image for a new partition, splat it on to the 'pong' partition, adjust the active flags and reboot. NanoBSD has supported this operation for a while, and this works well in the hand-built images I've done. I'm polishing off the rough edges for this by making it possible to dynamically resize the first time. FreeBSD supports this for one partition today. But it doesn't provide a good way to do a divide by 2. The support in FreeBSD for writing MSDOS partitions as a regular user is also weak, so there's bits from mtools in my build. I've also not completely integrated the u-boot ports into the build. There's also an open question about the proper way to install packages on these boxes. One school of thought says that nanobsd should put the packages you want onto the image, and that's all you'll ever get. Another says that nanobsd should keep the database of packages off the ping or pong partitions so that when you upgrade, the packages are refreshed to the old set. There's other in-between positions I've heard articulated. So I can't help you today, but I'll be able to help you soon. Warner From owner-freebsd-arm@freebsd.org Tue Dec 8 17:03:06 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE2B99D49FC for ; Tue, 8 Dec 2015 17:03:06 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C92012C6 for ; Tue, 8 Dec 2015 17:03:06 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by ioc74 with SMTP id 74so30563300ioc.2 for ; Tue, 08 Dec 2015 09:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references:to:cc; bh=NbPvUpYAxT61l43chph5wuvVmR8pESWenOdGahlYT1c=; b=bM3EGJrybs8JprA2DWaDsZpjrR9AKn4ycNrdECVPx4TLutyTZZkYe3p23eavgfqcRI 6v29kFozKxeqgemd0p/UMjfQjf+5BR3ErsGw0hHqZX7/jW1DmKMUUJY7Lzmgl9ehil+7 J6wksSeuxxnV36RVHJHxlVPzT3GLcTo1z54EWtGuxgFhTWmS8eJa+TwD4nh0la4riYer gB8BmjaogeFOgVMeJgxxUFCIy8pX4j+dQFIRN0M6jY1/VkXn3iH1wGKxOCnLbscOWPi/ 0UScstp1JF5zShR6qSFA0524QI39R5vHGSbpw4ir2kSN2kL+frJiNruP+5yh3PK60SU5 Y2xA== X-Received: by 10.107.133.205 with SMTP id p74mr1092136ioi.44.1449594185851; Tue, 08 Dec 2015 09:03:05 -0800 (PST) Received: from [127.0.0.1] ([209.52.88.83]) by smtp.gmail.com with ESMTPSA id c21sm1683206ioc.24.2015.12.08.09.03.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Dec 2015 09:03:05 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2639) Message-ID: <20151208170304.4386897.13959.1326@gmail.com> Date: Tue, 08 Dec 2015 09:03:04 -0800 Subject: Re: Updating / keeping current strategies? From: Russell Haley In-Reply-To: References: <5666F37C.4060908@denninger.net> To: Warner Losh , Karl Denninger Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 17:03:06 -0000 We do a ping pong at work for our embedded linux upgrades. It ensures that = we can fall back to the original install if the update fails. However, we u= se a sata drive. =A0Do you gave an documentation for this? Thanks Russ Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the=A0Koodo=A0networ= k. =A0 Original Message =A0 From: Warner Losh Sent: Tuesday, December 8, 2015 7:55 AM To: Karl Denninger Cc: freebsd-arm@freebsd.org Subject: Re: Updating / keeping current strategies? On Tue, Dec 8, 2015 at 8:13 AM, Karl Denninger wrote: > What are people doing in this regard with devices like the Raspberry Pi2? > > Build times for a "make buildworld" are measured in (many) hours to a > day or more and require a USB-attached disk for temporary storage, as > the ramdisk for /tmp that is typically mounted blows up due to lack of > space and SD cards are slow enough on writes (especially small writes) > as to make the process virtually impossible. But even with a > USB-attached disk the process is ridiculous in terms of consumed > walllclock time. > > Further, "make installworld" sometimes fails inexplicably. > > Kernel builds are a bit more reasonable, only requiring a couple of hours. > > I'm wondering what the best option is to not only build current code on > a regular basis (since -CURRENT is a "work in progress") but also to > deploy and update existing devices. What are people doing that has a > history of working well? > I've been updating for years. But usually building on another machine and then installing to the media of the embedded machine via NFS. This mostly works and isn't too sucky. But there are problems with this approach, since high write work loads tend to bog down the embedded box due to crappy storage being used (eg SD cards, USB attachment or both). You may have noticed some commits to nanobsd I've been making lately. I'm moving all my local boards over to nanobsd with a ping-pong partition. I'd create a new image for a new partition, splat it on to the 'pong' partition, adjust the active flags and reboot. NanoBSD has supported this operation for a while, and this works well in the hand-built images I've done. I'm polishing off the rough edges for this by making it possible to dynamically resize the first time. FreeBSD supports this for one partition today. But it doesn't provide a good way to do a divide by 2. The support in FreeBSD for writing MSDOS partitions as a regular user is also weak, so there's bits from mtools in my build. I've also not completely integrated the u-boot ports into the build. There's also an open question about the proper way to install packages on these boxes. One school of thought says that nanobsd should put the packages you want onto the image, and that's all you'll ever get. Another says that nanobsd should keep the database of packages off the ping or pong partitions so that when you upgrade, the packages are refreshed to the old set. There's other in-between positions I've heard articulated. So I can't help you today, but I'll be able to help you soon. Warner _______________________________________________ freebsd-arm@freebsd.org mailing list https://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 Dec 8 17:12:08 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99B6B9D31CD for ; Tue, 8 Dec 2015 17:12:08 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73D9D1D70 for ; Tue, 8 Dec 2015 17:12:08 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by pabur14 with SMTP id ur14so14930278pab.0 for ; Tue, 08 Dec 2015 09:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references:to; bh=pU1RnefMe1Z4GwBR17aon47cQ0K5lU/rmoG6TgesBFQ=; b=X+AUBOVw37gKLF88VpF4aUAlueY/ywBpeY59+iKiAfMyuNu7gkfApk70EB7mYGfuk4 t4L2EmTTBSeCGlO4+SiWSiBtuvQTaCCmYsH8EJeh91PQ+C22MJGfcQivf8CWC7tpcA5B GFmWZ0OVQqiqv5N/0D5l/zjHbRWMyf7Cy7ZmaXfkbp4xm+bIFrvON0e1ZzZ8/gpu7THj 3J6NQhpqL2Oh2G+3Ws1OzDO7vuu4drxNsAR0MGIivtNg/tVpjeKAsDdrEyBLdEz2kuxM tKZHwBEDQvLLAcOUhx3f8aDd7oSzUAVVSfxpFD/aWt94lZUMcx0jSMDshHzdCQPVu8c4 Pf6w== X-Received: by 10.66.254.39 with SMTP id af7mr1399417pad.43.1449594728106; Tue, 08 Dec 2015 09:12:08 -0800 (PST) Received: from [127.0.0.1] ([209.52.88.83]) by smtp.gmail.com with ESMTPSA id ud10sm6068838pab.27.2015.12.08.09.12.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Dec 2015 09:12:07 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2639) Message-ID: <20151208171206.4386897.79614.1328@gmail.com> Date: Tue, 08 Dec 2015 09:12:06 -0800 Subject: Re: Updating / keeping current strategies? From: Russell Haley In-Reply-To: <5666F37C.4060908@denninger.net> References: <5666F37C.4060908@denninger.net> To: Karl Denninger , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 17:12:08 -0000 Not sure about RPi or bbb but for my imx53 digi som I had my userland on a = USB stick and loaded the kernel using tftp from u-boot. That was good for d= evelopment because I could have two USB sticks and did all my cross compili= ng on an amd64 box. Tftp is reasonably fast but setup is finiky. =C2=A0Not = so great for production though.=C2=A0 Remember also Ian Lapore has documented a -DNO_CLEAN option for make. =C2= =A0It's on the wiki but I don't have the page handy. =E2=80=8E Not sure whi= ch targets it's applicable to. =C2=A0Also there is an option for specifying= parts of the base os to build. I don't Remeber whe name (srcconf?). I subm= itted a patch for the man pages but it's just sitting there in bugzilla. le= t me know if you want it and I'll dig my notes out.=C2=A0 Russ Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the=C2=A0Koodo=C2=A0network. =C2=A0 Original Message =C2=A0 From: Karl Denninger Sent: Tuesday, December 8, 2015 7:13 AM To: freebsd-arm@freebsd.org Subject: Updating / keeping current strategies? What are people doing in this regard with devices like the Raspberry Pi2? Build times for a "make buildworld" are measured in (many) hours to a day or more and require a USB-attached disk for temporary storage, as the ramdisk for /tmp that is typically mounted blows up due to lack of space and SD cards are slow enough on writes (especially small writes) as to make the process virtually impossible. But even with a USB-attached disk the process is ridiculous in terms of consumed walllclock time. Further, "make installworld" sometimes fails inexplicably. Kernel builds are a bit more reasonable, only requiring a couple of hours. I'm wondering what the best option is to not only build current code on a regular basis (since -CURRENT is a "work in progress") but also to deploy and update existing devices. What are people doing that has a history of working well? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ From owner-freebsd-arm@freebsd.org Tue Dec 8 17:29:34 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F0DD9D4018 for ; Tue, 8 Dec 2015 17:29:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0151D1AB8 for ; Tue, 8 Dec 2015 17:29:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgea14 with SMTP id a14so26744706qge.0 for ; Tue, 08 Dec 2015 09:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=s2FsGUtBrds41YepNvlfCZZd3plgnPxyPEu2lMgw6bg=; b=Xn1aQPs2gv/c269V3DQ7KclBuVeHrxSZWSxxJ0p/YYJn4gQXq16Mq4ALBTfwdDFgZ/ c0NB+I9Djz+pHVsIVJCS+InPzHppHptj38Vld2NwxQb7vnLzNP+SqhH4h2uHWrHchV// 5WeoGLs5bvNdv+7LqRkfXkw+hVlzccePDz1sDtNXk9ckXjniMy5rKc8F/wuqnSSDL5WU TW2t0D06vEDx4dkCa+rUHuG7eFJTbg2XYHIeR4VATTxPRdS/lP6Wo3DZZHE5bGN+L7Pr ZxQNAwHOCHLMYJrtylvEbpDcvpxTF/6KGxy9XiQjgYuV/uMO9uR1bj7y4ukPUGY/fM1n tEZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s2FsGUtBrds41YepNvlfCZZd3plgnPxyPEu2lMgw6bg=; b=SIf7AXMFQX17POLNYVMq8bOsKuSmf4ioaT9LWqLFOSIWUKtYjMXVKb/MnoF0h5npbF 2ztuPJscRtvVr92ilaQy2WU7i2bTIAlnpQk0b/u4txtaEvnRfSEAi5/mfvt5oKVY2YnA gyBUZebeTX5/zNGYMHQ/JjG2pZzS4pMvXFgIgkCIMBuddK4J1ZVvGbhrv5S93t3ZYfvE 4ZVfnxYcXgNNSnom0LM/hB83vj23FapUC3ThptWYs+TWKgfyOTpxWquYVmnb15PxQvBM rqwy4jEOaMC/oGSOQY6dAuSN0xl1aVD4DQMmIy0LTC4CXO/gUdpBWU1M4vOB6aAsgcG+ 2AIg== X-Gm-Message-State: ALoCoQkiqGvtXe+JK5191Y6bLDg45F1+1yuEWtrw7V+GVZJwVQs7/p1WNSyLOH2edTrR8NZpLIYkK8kHhd1mvpxayKt61vhMsw== MIME-Version: 1.0 X-Received: by 10.140.176.143 with SMTP id w137mr6825193qhw.20.1449595772866; Tue, 08 Dec 2015 09:29:32 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Tue, 8 Dec 2015 09:29:32 -0800 (PST) X-Originating-IP: [2601:280:4900:3700:4d3f:8eba:ea86:7700] In-Reply-To: <20151208170304.4386897.13959.1326@gmail.com> References: <5666F37C.4060908@denninger.net> <20151208170304.4386897.13959.1326@gmail.com> Date: Tue, 8 Dec 2015 10:29:32 -0700 X-Google-Sender-Auth: _zL-PcLkGAdEcRVtg3XFmDA5-Xs Message-ID: Subject: Re: Updating / keeping current strategies? From: Warner Losh To: Russell Haley Cc: Karl Denninger , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 17:29:34 -0000 On Tue, Dec 8, 2015 at 10:03 AM, Russell Haley wrote: > We do a ping pong at work for our embedded linux upgrades. It ensures that > we can fall back to the original install if the update fails. However, we > use a sata drive. Do you gave an documentation for this? > It's a work in progress, but https://www.freebsd.org/doc/en/articles/nanobsd/article.html has the basics. Warner > Thanks > > Russ > > Sent from my BlackBerry 10 smartphone on the Koodo network. > Original Message > From: Warner Losh > Sent: Tuesday, December 8, 2015 7:55 AM > To: Karl Denninger > Cc: freebsd-arm@freebsd.org > Subject: Re: Updating / keeping current strategies? > > On Tue, Dec 8, 2015 at 8:13 AM, Karl Denninger wrote: > > > What are people doing in this regard with devices like the Raspberry Pi2? > > > > Build times for a "make buildworld" are measured in (many) hours to a > > day or more and require a USB-attached disk for temporary storage, as > > the ramdisk for /tmp that is typically mounted blows up due to lack of > > space and SD cards are slow enough on writes (especially small writes) > > as to make the process virtually impossible. But even with a > > USB-attached disk the process is ridiculous in terms of consumed > > walllclock time. > > > > Further, "make installworld" sometimes fails inexplicably. > > > > Kernel builds are a bit more reasonable, only requiring a couple of > hours. > > > > I'm wondering what the best option is to not only build current code on > > a regular basis (since -CURRENT is a "work in progress") but also to > > deploy and update existing devices. What are people doing that has a > > history of working well? > > > > I've been updating for years. But usually building on another machine and > then > installing to the media of the embedded machine via NFS. This mostly works > and isn't too sucky. But there are problems with this approach, since high > write work loads tend to bog down the embedded box due to crappy storage > being used (eg SD cards, USB attachment or both). > > You may have noticed some commits to nanobsd I've been making lately. > I'm moving all my local boards over to nanobsd with a ping-pong partition. > I'd create a new image for a new partition, splat it on to the 'pong' > partition, > adjust the active flags and reboot. NanoBSD has supported this operation > for a while, and this works well in the hand-built images I've done. > > I'm polishing off the rough edges for this by making it possible to > dynamically > resize the first time. FreeBSD supports this for one partition today. But > it > doesn't provide a good way to do a divide by 2. The support in FreeBSD > for writing MSDOS partitions as a regular user is also weak, so there's > bits from mtools in my build. I've also not completely integrated the > u-boot > ports into the build. There's also an open question about the proper way > to install packages on these boxes. One school of thought says that nanobsd > should put the packages you want onto the image, and that's all you'll > ever get. Another says that nanobsd should keep the database of packages > off the ping or pong partitions so that when you upgrade, the packages > are refreshed to the old set. There's other in-between positions I've heard > articulated. > > So I can't help you today, but I'll be able to help you soon. > > Warner > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://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 Dec 8 18:54:39 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B5999D34B6 for ; Tue, 8 Dec 2015 18:54:39 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 899851ABF; Tue, 8 Dec 2015 18:54:39 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B1FC61CF0; Tue, 8 Dec 2015 18:54:38 +0000 (UTC) Date: Tue, 8 Dec 2015 18:54:28 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: brueffer@FreeBSD.org, smh@FreeBSD.org, ngie@FreeBSD.org, kib@FreeBSD.org, vangyzen@FreeBSD.org, imp@FreeBSD.org, arybchik@FreeBSD.org, emaste@FreeBSD.org, jhb@FreeBSD.org, uqs@FreeBSD.org, np@FreeBSD.org, tuexen@FreeBSD.org, jilles@FreeBSD.org, kevlo@FreeBSD.org, cem@FreeBSD.org, avos@FreeBSD.org, bapt@FreeBSD.org, melifaro@FreeBSD.org, markj@FreeBSD.org, andrew@FreeBSD.org, benno@FreeBSD.org, ken@FreeBSD.org, dim@FreeBSD.org, jkim@FreeBSD.org, hselasky@FreeBSD.org, sjg@FreeBSD.org, nwhitehorn@FreeBSD.org, mav@FreeBSD.org, mckusick@FreeBSD.org, bdrewery@FreeBSD.org, maxim@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <358635345.1.1449600877149.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1853 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk X-Mailman-Approved-At: Tue, 08 Dec 2015 19:02:11 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 18:54:39 -0000 FreeBSD_HEAD_arm64 - Build #1853 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1853/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1853/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1853/console Change summaries: 291996 by emaste: Update after r291955, build/install userland debug by default Sponsored by: The FreeBSD Foundation 291995 by bdrewery: Fix some makeman issues. - Don't bother looking up REVISION/BRANCH/etc from release/, or the CPUTYPE check, as these are not used for makeman and wastes time. The also invokes auto.obj.mk after I reverted auto.obj.mk ignoring -V in r291312. - Don't modify CC or PATH when WITH_CCACHE_BUILD or WITH_META_MODE is enabled as it leads to bsd.compiler.mk errors. Sponsored by: EMC / Isilon Storage Division 291994 by vangyzen: resolver: fix the build of some ports, broken by r289315 r289315 required time_t and struct timespec to be defined before including . This broke the build of net-mgmt/sx, at least. Include in resolv.h to fix this with minimal pollution. Reported by: Raphael Kubo da Costa MFC after: 3 days Sponsored by: Dell Inc. 291993 by melifaro: Merge helper fib* functions used for basic lookups. Vast majority of rtalloc(9) users require only basic info from route table (e.g. "does the rtentry interface match with the interface I have?". "what is the MTU?", "Give me the IPv4 source address to use", etc..). Instead of hand-rolling lookups, checking if rtentry is up, valid, dealing with IPv6 mtu, finding "address" ifp (almost never done right), provide easy-to-use API hiding all the complexity and returning the needed info into small on-stack structure. This change also helps hiding route subsystem internals (locking, direct rtentry accesses). Additionaly, using this API improves lookup performance since rtentry is not locked. (This is safe, since all the rtentry changes happens under both radix WLOCK and rtentry WLOCK). Sponsored by: Yandex LLC 291989 by uqs: Fix make depend 291985 by arybchik: sfxge: [3/6] rework MCDI response handling Required for MCDI proxy authorization support. Submitted by: Andy Moreton Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D4420 291984 by ngie: Add missing stdlib.h header Apply some minor style(9) fixes MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 291983 by ngie: Fix compilation warnings by adding unistd.h #include and missing return statements MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 291982 by ngie: Skip the MAC portacl tests if MAC_PORTACL support is missing instead of marking them failed MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 291981 by ngie: Delete bogus freeing of uninitialized data MFC after: 3 days Reported by: cppcheck Sponsored by: EMC / Isilon Storage Division 291980 by ngie: Add missing va_ends for corresponding va_starts to clean up variable arguments initialized in _test_fmt(..) MFC after: 3 days Reported by: cppcheck Sponsored by: EMC / Isilon Storage Division 291979 by ngie: Unbreak compiling getnetgrent.c with -DDEBUG after r236402 by adding a missing "}" MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 291978 by sjg: Merge bmake-20151201 291977 by maxim: o DragonFly 4.4.1 release added. 291973 by bdrewery: local.meta.sys.mk already defines TARGET_ARCHES_arm 291972 by bdrewery: DIRDEPS_BUILD: Update dependencies. Sponsored by: EMC / Isilon Storage Division 291968 by markj: Actually add the proc_rwmem(9) man page, missed in r291961. 291967 by markj: Fix a couple misspellings of "environment." MFC after: 3 days 291966 by markj: Add a trailing newline to the expected output for tst.walltimestamp.ksh. MFC after: 1 week 291965 by markj: Fix a discrepancy in r291738. The script that generates these makefiles was changed to modify LIBADD rather than LDADD/DPADD, but the makefile itself was also changed in a slightly different way. 291964 by markj: Update DTrace test suite makefiles after r291963. 291963 by markj: MFV r289003: 6271 dtrace caused excessive fork time Author: Bryan Cantrill Reviewed by: Adam Leventhal Reviewed by: Dan McDonald Reviewed by: Richard Lowe Approved by: Gordon Ross illumos/illumos-gate@7bd3c1d12d0c764e1517c3aca62c634409356764 291962 by markj: Modify DTRACEHIOC_ADDDOF to copy the DOF section from the target process. r281257 added support for lazyload mode by allowing dtrace(1) to register a DOF section on behalf of a traced process. This was implemented by having libdtrace copy the DOF section into a heap-allocated buffer and passing its address to the ioctl handler. However, DTrace uses the DOF section address as a lookup key in certain cases, so the ioctl handler should be given the target process' DOF section address instead. This change modifies the ADDDOF handler to copy the DOF section in from the target process, rather than from dtrace(1). 291961 by markj: Add helper functions proc_readmem() and proc_writemem(). These helper functions can be used to read in or write a buffer from or to an arbitrary process' address space. Without them, this can only be done using proc_rwmem(), which requires the caller to fill out a uio. This is onerous and results in code duplication; the new functions provide a simpler interface which is sufficient for most existing callers of proc_rwmem(). This change also adds a manual page for proc_rwmem() and the new functions. Reviewed by: jhb, kib Differential Revision: https://reviews.freebsd.org/D4245 291960 by ken: The ccb_xflags enumeration was removed from FreeBSD/head in r259397 (it contained the CAM_EXTLUN_VALID bit) and I added the same type name with a different set of values back in r291716. The old ccb_xflags enumeration still exists in FreeBSD stable/10. Shift all of the new values by one bit to avoid compatibility issues when merged to stable/10. MFC after: 3 days Sponsored by: Spectra Logic 291959 by bapt: Fix ls -l alignement with new locales Latest update of locales introduced abbreviated month that follows the regionale rules meaning that they can be of variable length instead of being arbitrary truncated to top 3 characters. To fix alignement, ls now computes the visible length of the abbreviated month, pads the shorter month with spaces in order to make sure everything is properly aligned Reviewed by: ache, ed, jilles Differential Revision: https://reviews.freebsd.org/D4239 291958 by emaste: elfcopy: exclude extension when converting from binary When converting from binary to ELF, elfcopy creates symbols _binary__start_, _binary__end, and _binary__size. For compatibility with GNU objcopy (and to produce sensible symbol names) the extension must be stripped off. Reviewed by: imp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D4238 291957 by brueffer: Fix a comment typo in the code example. PR: 203497 Submitted by: chadf@triularity.org MFC after: 1 week 291955 by emaste: Build and install userland .debug files by default Debug data files are now built by default with 'make buildworld' and installed with 'make installworld'. This facilitates debugging but requires more disk space both during the build and for the installed world. Debug files may be disabled by setting WITHOUT_DEBUG_FILES=yes in src.conf(5). Reviewed by: bdrewery, eadler, vangyzen Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D4018 291954 by brueffer: Add an MLINK for m_collapse. PR: 204205 Submitted by: avos MFC after: 1 week 291953 by hselasky: When setting up VLANs on a Raspberry Pi ethernet port, the MTU drops from 1500 to 1496 bytes. The MTU should remain at 1500, extending the frame size as per IEEE 802.3. Adding IFCAP_VLAN_MTU to the if_capabilities field in the smsc driver solves the problem. The datasheet for the LAN9512 chip, section 3.2.3 states that the chip supports the extended frame. Submitted by: rpp@ci.com.au MFC after: 1 week PR: 205050 291952 by bdrewery: Fix spelling of internal hack. Reported by: ngie 291951 by emaste: Replace magic value ELF note type with NT_FREEBSD_ABI_TAG As of r291909 elf_common.h provides a definition. Suggested by: kib Sponsored by: The FreeBSD Foundation 291950 by brueffer: Fix a typo in the CPUTYPE list. PR: 205099 Submitted by: xxjack12xx@gmail.com MFC after: 1 week 291949 by kib: Merge common parts of i386 and amd64 md_var.h and smp.h into new headers x86/include x86_var.h and x86_smp.h. Reviewed by: emaste, jhb Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D4358 291948 by kib: Use ANSI C definition. MFC after: 1 week 291947 by jhb: Set %esp correctly in the extended TSS. The pcb is saved at the top of the kernel stack on x86 platforms. The initial kenrel stack pointer is set in the TSS so that the trapframe from user -> kernel transitions begins directly below the pcb and grows down. The XSAVE changes moved the FPU save area out of the pcb and into a variable-sized area after the pcb. This required updating the expressions to calculate the initial stack pointer from 'stacktop - sizeof(pcb)' to 'stacktop - sizeof(pcb) + FPU save area size'. The i386_set_ioperm() system call allows user applications to access individual I/O ports via the I/O port permission bitmap in the TSS. On FreeBSD this requires allocating a custom per-process TSS instead of using the shared per-CPU TSS. The expression to initialize the initial kernel stack pointer in the per-process TSS created for i386_set_ioperm() was not properly updated after the XSAVE changes. Processes that used i386_set_ioperm() would trash the trapframe during subsequent context switches resulting in panics from memory corruption. This changes fixes the kernel stack pointer calculation for the per-process TSS. Reviewed by: kib, n_hibma Reported by: n_hibma MFC after: 1 week 291946 by bdrewery: Garbage collect removed directories. Sponsored by: EMC / Isilon Storage Division 291945 by bdrewery: FAST_DEPEND: Only pass -MF if we care about the object being compiled. This will save time generating dependency files that we didn't expect due to cases where SRCS!=OBJS or for building custom targetted objects in Makefiles that do not end up in the DEPENDOBJS list. This uses a bmake trick to modify CFLAGS based on ${.TARGET}. A .PARSEDIR check is done for the sake of MFC safety. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 291944 by bdrewery: FAST_DEPEND: Move handling code below yacc/lex/dtrace code that modified SRCS. This fixes some of those newly added SRCS not having their depend files included. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 291943 by bdrewery: FAST_DEPEND: Only try to use dependencies from C/C++ SRCS as mkdep did. Rather than try to guess at all of the OBJS variables just use SRCS using the same patterns that mkdep does. This also fixes a mistake where dependencies were being generated with FAST_DEPEND when they were not for mkdep. This happens when OBJS!=SRCS as is the case in gnu/lib/csu where SRCS has 1 file and OBJS has several other files that does not even contain the 1 SRCS file. Generally in these cases the OBJS have custom dependencies defined in their Makefile. If we generate dependencies for those and then load a .depend file, then .IMPSRC may contain duplicate sources and lead to errors such as: cc: error: cannot specify -o when generating multiple output files MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 291942 by bdrewery: Add missing CLEANFILES. MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 291941 by bdrewery: Replace unneeded manual dependency on header by adding it to SRCS. bsd.lib.mk and bsd.prog.mk already depend all objs on headers in SRCS if there is not yet a depend file. The headers in SRCS are never built or installed. After 'make depend' the header was already added as a proper dependency on the objects where needed. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 291939 by hselasky: Update the mlx5 shared driver code to the latest version, which include the following list of changes: - Added eswitch ACL table management Introduce API for managing ACL table. This API include the following features: 1) vlan filter - for VST/VGT+ support. 2) spoofcheck. 3) robust functionality to allow/drop general untagged/tagged traffic. 4) support for both ingress and egress ACL types. - Added loopback filter to the vacl table. - Added multicast list set in the vPort context - Added promiscuous mode set in the vPort context - Set the vlan list in vPort context 1) Check caps if VLAN list is not longer than FW supports 2) Set MODIFY_NIC_VPORT_CONTEXT command - Changed MLX5_EEPROM_MAX_BYTES from 48 to 32 so that a single EEPROM reading cannot cross the 128-byte boundary. Previously reading the MCIA register was done in batches of 48 bytes. The third reading would then by-pass the 127th byte, which means that part of the low page and part of the high page would be read at the same time, which created a bug: 1st: 0-47 bytes 2nd: 48-95 bytes 3rd: 96-143 bytes MFC after: 1 week Sponsored by: Mellanox Technologies Differential Revision: https://reviews.freebsd.org/D4411 291938 by hselasky: Add full support for Receive Side Scaling, RSS, to the mlx5en driver. This includes binding all interrupt and worker threads according to the RSS configuration, setting up correct Toeplitz hashing keys as given by RSS and setting the correct mbuf hashtype for all received traffic. MFC after: 1 week Sponsored by: Mellanox Technologies Differential Revision: https://reviews.freebsd.org/D4410 291937 by kib: Add support for usermode (vdso-like) gettimeofday(2) and clock_gettime(2) on ARMv7 and ARMv8 systems which have architectural generic timer hardware. It is similar how the RDTSC timer is used in userspace on x86. Fix a permission problem where generic timer access from EL0 (or userspace on v7) was not properly initialized on APs. For ARMv7, mark the stack non-executable. The shared page is added for all arms (including ARMv8 64bit), and the signal trampoline code is moved to the page. Reviewed by: andrew Discussed with: emaste, mmel Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D4209 291936 by kib: Update ctime when atime or birthtime are updated. Cleanup setting of ctime/mtime/birthtime: do not set IN_ACCESS or IN_UPDATE, then clear them with ufs_itimes(), making transient (possibly inconsistent) change to the times, and then copy user-supplied times into the inode. Instead, directly clear IN_ACCESS or IN_UPDATE when user supplied the time, and copy the value into the inode. Minor inconsistency left is that the inode ctime is updated even when birthtime update attempt is performed on a UFS1 volume. Submitted by: bde MFC after: 2 weeks 291932 by hselasky: Add support for setting the TX moderation mode via a sysctl entry. TX completion events can be moderated in the same way like RX completion events. Expose this functionality by a sysctl variable. MFC after: 1 week Sponsored by: Mellanox Technologies Differential Revision: https://reviews.freebsd.org/D4409 291931 by hselasky: The firmware no longer supports setting a port MTU of zero bytes. Set the port MTU and then query it and report if any problems instead. MFC after: 1 week Submitted by: Shahar Klein Sponsored by: Mellanox Technologies Differential Revision: https://reviews.freebsd.org/D4408 291930 by imp: Start to split apart the different image formats that we need to make. Add support for generating powerpc64 qemu images. We can generate them, but there's something wrong booting them. This also simplifies the user config files a bit, and removes bits no longer true. 291929 by imp: Make sure to quote the arg after -n and -z tests. 291928 by arybchik: sfxge: [2/6] rework MCDI response polling Required to support MCDI proxy authorization. Submitted by: Andy Moreton Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D4418 291927 by arybchik: sfxge: [1/6] add common code MCDI proxy auth build option Submitted by: Andy Moreton Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D4417 291926 by arybchik: sfxge: fix pointer parameter/value signedness mismatch warnings TLV routines use 'uint8_t *', NVRAM code uses caddr_t. Just cast to required type to fix the warning. Required to build with -Werror=pointer-signg. Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4391 291925 by arybchik: sfxge: fix name conflict with crc32_table from sys/crc32.h The header is not present on FreeBSD, but exists on OmniOS where sfxge common code is used as well. Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4390 291924 by arybchik: sfxge: switch to TxQ creation specific flags It is better do not mix TxQ creation and receive event flags since only checksum flags are applicable to TxQ. Also it will allow to add a new TxQ creation specific flags. Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4389 291923 by arybchik: sfxge: [Sorrento] support writing of MUM firmware When writing the MUM firmware the chunk size must be equal to the erase size. Submitted by: Laurence Evans Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4388 291922 by arybchik: sfxge: support PERMIT_SET_MAC_WHEN_FILTERS_INSTALLED flag Use flag on vadapter alloc when reported as a supported capability. Use the slow device reset only when the capability is missing. Submitted by: Richard Houldsworth Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4387 291921 by imp: Document the different config files. Document how to run qemu for the ones I've run. Use qcow2 for all qemu images. 291920 by imp: Improve cam tracing a little by including the function code in the traces for xpt_action. Note up-calls (down-calls?) to the SIM as well. Differential Review: https://reviews.freebsd.org/D4382 291919 by ngie: Enable bin/ls testcases disabled previously because of issues with how kyua 0.11's version of report-junit was rendering non-printable characters Upgrade to kyua 0.12 to obtain a fixed version of the command Output verified with python 2.7.10's xml.dom.minidom module MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 291918 by imp: Now that we have dedup of mtree elements in nanobsd, remove the primitive attempt we made here. 291917 by imp: Fix up mtree with additional entries written to it by nanobsd. implement support for NanoBSD touching a file (and possibly recording that fact) as well as replacing a directory with a symlink. Also specify the default uname and gname for files and use that as a /set command at the top of the generated METALOG file. 291916 by imp: Disable /entropy by default. /var/db/entropy should be enough. # This eliminates the warning message at boot, but more work may be # needed. 291915 by imp: imported patch dedup 291914 by imp: Allow the .cfg files to specify the ultimate format for the images created. 291913 by imp: Generally use shorter, more idiomatic sh expressions in a bunch of places. 291912 by imp: Default serial connection to 115200. Hardly anybody uses slower these days, and those that do can use NANO_BOOT2CFG to change it. 291911 by smh: Fix panic on shutdown due to iscsi event priority iscsi's shutdown_pre_sync prio was SHUTDOWN_PRI_FIRST which caused it to run before other high priority handlers such as filesystems e.g. ZFS. This meant the iscsi sessions where removed before the ZFS geom consumer was closed, resulting in a panic from g_access calls on debug kernels due to negative acr. Instead use the same as the old iscsi_initiator SHUTDOWN_PRI_DEFAULT-1 which allows it to run before dashutdown etc but after filesystems. MFC after: 2 weeks Sponsored by: Multiplay 291909 by emaste: Add definitions for ELF note types used in executables Sponsored by: The FreeBSD Foundation 291908 by ngie: Fix leak in mkfs_msdos(..) by initializing img to NULL and free'ing at the end of the function Differential Revision: https://reviews.freebsd.org/D4405 MFC after: 1 week PR: 204943 Reviewed by: emaste, jilles Reported by: David Binderman Sponsored by: EMC / Isilon Storage Division 291907 by cem: vm_fault_hold: handle vm_page_rename failure On vm_page_rename failure, fix a missing object unlock and a double free of a page. First remove the old page, then rename into other page into first_object, then free the old page. This avoids the problem on rename failure. This is a little ugly but seems to be the most straightforward solution. Tested with: $ sysctl debug.fail_point.uma_zalloc_arg="1%return" $ kyua test -k /usr/tests/sys/Kyuafile Submitted by: Ryan Libby Reviewed by: kib Seen by: alc Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D4326 291906 by cem: pmap_invalidate_range: For very large ranges, flush the whole TLB Typical TLBs have 40-512 entries available. At some point, iterating every single page in a requested invalidation range and issuing invlpg on it is more expensive than flushing the TLB and allowing it to reload on demand. Broadwell CPUs have 1536 L2 TLB entries, so I've picked the arbitrary number 4096 entries as a hueristic at which point we flush TLB rather than invalidating every single potential page. Reviewed by: alc Feedback from: jhb, kib MFC notes: Depends on r291688 Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D4280 291904 by tuexen: Fix the allocation of outgoing streams: * When processing a cookie, use the number of streams announced in the INIT-ACK. * When sending an INIT-ACK for an existing association, use the value from the association, not from the end-point. MFC after: 1 week 291903 by jilles: sh: Add limited test for ${#@} and ${#*}. POSIX leaves the result of expanding ${#@} and ${#*} unspecified, but ensure it is numeric. 291902 by kevlo: - Fix Tx queues to USB endpoints mapping - Merge urtwn_r92c_dma_init() and urtwn_r88e_dma_init() into one Reviewed by: adrian, avos Differential Revision: https://reviews.freebsd.org/D4381 291896 by ngie: Remove unused atf.test.mk variables - ATF_BUILD_CC - ATF_BUILD_CPP - ATF_BUILD_CXX - ATF_SHELL - ATF_PREFIX MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 291892 by ngie: Remove redundant default TESTSDIR that is already defined in bsd.test.mk after r289158 MFC after: 1 week X-MFC with: r289158 Sponsored by: EMC / Isilon Storage Division 291891 by ngie: Use .Fx instead of explicitly spelling out FreeBSD Fix several warnings reported by igor MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 291877 by nwhitehorn: Adapt to new wireless scheme where base wlan interfaces do not show up in ifconfig anymore. 291876 by ngie: Remove stray unescaped `%` in `Booting from ...` informational message PR: 204944 MFC after: 1 week X-MFC with: r291164 Reported by: David Binderman Sponsored by: EMC / Isilon Storage Division 291872 by mav: There is no priority request queue on 16Gig chips. 291868 by mav: Rework WWNs generation to make cards without NVRAM more useful. 291864 by bdrewery: Fix regression in r291738: This really wants -lssp. The normal LIBADD is ssp_nonshared. This also had a DPADD on LIBSSP which does not actually exist, it is blank. Sponsored by: EMC / Isilon Storage Division 291863 by imp: When building no-priv, chmod etc/defaults/rc.conf before appending to it and then chmod back. There's no chmod -push / chmod -pop so hard code 444 as the right permissions here. Also, fix more stray detritus that crept in (out?) while re-arranging the deck chairs. 291862 by arybchik: sfxge: erase nvram partitions in chunks equal to their erase size The erase size is reported by the nvram info command. Submitted by: Paul Fox Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4386 291861 by cem: style.9: Add a small blurb about allowing bool It was allowed before, but make it very explicit it is allowed now. And prefer 'bool' to older types that were used for the same purpose -- int and boolean_t. Like with the C99 fixed-width types, use common sense when changing old code. No igor regressions. Suggested by: bde <20151205031713.T3286@besplex.bde.org> Reviewed by: glebius, davide, bapt (earlier versions) Reviewed by: imp Feedback from: julian Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D4384 291860 by imp: Stupid last minute changes: Add missing } and fi Pointed out by: Howard Su 291859 by kevlo: Remove a duplicate definition. 291858 by avos: urtwn: fix some regressions after r290630 - Restore R92C_TXDW4_HWSEQ_EN bit - it is used by non-8188EU chips. - Fix DRVRATE bit usage. Tested with: - RTL8188EU, STA mode. - RTL8188CUS, STA mode. Reviewed by: kevlo Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D4352 291857 by jilles: sh: Link tests/parameters/positional8.0 to the build. This was forgotten in r291025. 291856 by np: Fix RSS build. Reported by: arybchik@ 291855 by andrew: Allow the artificial profile frames to be adjusted as needed by the user. While here update for armv6 to a tested value. Submitted by: Howard Su Reviewed by: stat Differential Revision: https://reviews.freebsd.org/D4315 291853 by melifaro: Remove LLE read lock from IPv4 fast path. LLE structure is mostly unchanged during its lifecycle. To be more specific, there are 2 things relevant for fast path lookup code: 1) link-level address change. Since r286722, these updates are performed under AFDATA WLOCK. 2) Some sort of feedback indicating that this particular entry is used so we re-send arp request to perform reachability verification instead of expiring entry. The only signal that is needed from fast path is something like binary yes/no. The latter is solved by the following changes: 1) introduce special r_skip_req field which is read lockless by fast path, but updated under (new) req_mutex mutex. If this field is non-zero, then fast path will acquire lock and set it back to 0. 2) introduce simple state machine: incomplete->reachable<->verify->deleted. Before that we implicitely had incomplete->reachable->deleted state machine, with V_arpt_keep between "reachable" and "deleted". Verification was performed in runtime 5 seconds before V_arpt_keep expire. This is changed to "change state to verify 5 seconds before V_arpt_keep, set r_skip_req to non-zero value and check it every second". If the value is zero - then send arp verification probe. These changes do not introduce any signifficant control plane overhead: typically lle callout timer would fire 1 time more each V_arpt_keep (1200s) for used lles and up to arp_maxtries (5) for dead lles. As a result, all packets towards "reachable" lle are handled by fast path without acquiring lle read lock. Additional "req_mutex" is needed because callout / arpresolve_slow() or eventhandler might keep LLE lock for signifficant amount of time, which might not be feasible for fast path locking (e.g. having rmlock as ether AFDATA or lltable own lock). Differential Revision: https://reviews.freebsd.org/D3688 291852 by andrew: Move the check to see if we are tracing a function with the DTrace Function Boundary Trace to assembly to reduce the overhead of these checks. Submitted by: Howard Su Relnotes: Yes Differential Revision: https://reviews.freebsd.org/D4266 291851 by kib: It seems that at least some KVM versions advertise support for EIO suppression but the version of the IOAPIC reported is 0x11 and neither IOAPIC EOIR nor the Linux trick of temporal reprogramming of the pin to edge-trigger mode to issue EOI work. Disable eoi suppression if KVM is detected. The mode can still be forced with the tunable. Reported and tested by: Roman Mamontov Sponsored by: The FreeBSD Foundation 291850 by kib: In the pmap_set_pg() function, which enables the global bit on the ptes mapping the kernel on CPUs where global TLB entries are supported, revert to flushing only non-global entries, i.e. to the pre-r291688 state. There is no need to flush global TLB entries, since only global entries created during the previous iterations of the loop could exist at this moment. Submitted by: alc Differential revision: https://reviews.freebsd.org/D4368 291849 by arybchik: sfxge: pick up the new TLV structures The header is auto-generated from firmware sources. Sponsored by: Solarflare Communications, Inc. MFC after: 2 days 291848 by arybchik: sfxge: cleanup: remove set but not used trailer variable Required to build with -Werror=unused-but-set-variable. Sponsored by: Solarflare Communications, Inc. MFC after: 2 days 291847 by arybchik: sfxge: cleanup: remove set but not used variable with parse error indication Required to build with -Werror=unused-but-set-variable. Keep it under #if 0 as a reminder for parse error processing. Sponsored by: Solarflare Communications, Inc. MFC after: 2 days 291846 by arybchik: sfxge: cleanup: remove set but not used saved_spec variable Required to build with -Werror=unused-but-set-variable. Sponsored by: Solarflare Communications, Inc. MFC after: 2 days 291845 by arybchik: sfxge: cleanup: remove SFL9122 "Huntington" PCI IDs The SFL9122 "Huntington" controller was never built. Submitted by: Mark Spender Sponsored by: Solarflare Communications, Inc. MFC after: 2 days 291843 by arybchik: sfxge: support for MCDI logging implemented Submitted by: Artem V. Andreev Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4355 291842 by imp: New config files for embedded boards. Build with ../nanobsd.sh -c rpi.cfg, for example. This can be done as a normal user. This is a work in progress. It relies on the new nopriv build stuff committed to nanobsd, but isn't complete yet. Currently, one must copy files into the DOS partition in the image. Also, ownership isn't preserved because this doesn't use the new mtree-dedup.awk yet, but rather some crazy mtree stuff. The image building bits will move up into nanobsd when they are ready. Also includes very preliminary support for building qemu images for all platforms that we can for qemu. It is missing aarch64, and we put the image on s2 instead of s1 and mkimg can't mark s2 as active, so there's some issues. Oh, and I didn't do it for arm. Take a look, kick the tires, expect problems. 291839 by ngie: Initialize errno to 0 in the nul testcase before testing it For some odd reason stable/10 requires this, otherwise it always fails the errno == 0 check on line 196. Sponsored by: EMC / Isilon Storage Division 291838 by ngie: Fix -Wformat issues and minor whitespace issues in surrounding areas MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 291837 by ngie: split.ih: - Create automatically generated include header for split.c main.c: - Use function definitions from debug.ih and split.ih instead of externs Sponsored by: EMC / Isilon Storage Division 291836 by ngie: Use `==` instead of `=` in the function comment above split(..) so mkh -p exposes split(..). MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 291835 by ngie: Use ANSI C function prototypes/definitions instead of K&R style ones MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 291834 by ngie: Add missing headers and sort #includes per style(9) MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 291833 by ngie: - Use ANSI C function prototypes/definitions instead of K&R style ones - Add a missing return type for main(..) MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 291832 by ngie: Fix -Wformat warnings by using the correct format qualifiers MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 291831 by imp: Awk helper script that reads in a mtree METALOG file from installworld (and soon augmented by nanobsd), performs the actions documented in the script, and then spits out a new mtree file suitable for feeding to makefs. Discussed on: arch@ 291830 by imp: Setting NANO_NOPRIV_BUILD will now add -DNO_ROOT and METALOG=xxxx as appropriate. First step in supporting a build w/o root. More to follow as actions by customization scripts are not (yet) recorded in the metalog, and duplicate entries in it aren't removed. 291829 by imp: SRCCONF makes no sense in make.conf. Don't set it there. Rely on it being in the environment. Also filter out the new SRC_ENV_CONF as well. If you really need these set, set them in your config file, not in the build environment used to launch nanobsd. Pointed out by: bdrewery@ 291828 by imp: Minor cleanup in how we run make: o Move SRCCONF and __MAKE_CONF into the environment to cope with file paths with spaces in them better. o Move the rest of the variable setting command line args into __MAKE_CONF files. o Trace the commands that we're using to build so they appear at the top of the log. o Be more consistent about quoting paths for cd and similar commands to better cope with paths with spaces in them, though some more work is likely needed. o Add some comments about all this. o Minor formatting tweaks in a couple places Sponsored by: Netflix, Inc 291827 by imp: Remove commented out junk. 291826 by cem: ioat(4): Add MODULE_VERSION so MODULE_DEPEND works Suggested by: jhb Review in progress: cc Sponsored by: EMC / Isilon Storage Division 291825 by imp: Since this is an almost identical copy of ALIX_DSK, just include it and add the bits we need at the end. 291821 by mav: Make 16Gig chips to use new queue pointer registers. While 24xx-style ATIO and reply queue registers seems like still working, request queue doesn't. So instead of that use registers from PCI BAR(4). 291793 by hselasky: Fix i386 build WITH_OFED=YES. Remove some redundant KASSERTs. Suggested by: kib, ian Sponsored by: Mellanox Technologies MFC after: 1 week 291771 by dim: Add clang patch corresponding to r291701. 291770 by jilles: rc.subr: Check for running daemons before a custom start_cmd is executed. Currently rc scripts implementing their own start_cmd do not enjoy the benefits of rc.subr's own check for rc_pid. This leads to around a third of ports with such a start_cmd not to check for the process at all and two thirds of ports to re-implement this check (sometimes wrongly). This patch moves the check for rc_pid to before ${rc_arg}_cmd is executed. Submitted by: Dirk Engling Reviewed by: feld MFC after: 1 week Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4156 291768 by andrew: Add ahci_generic to the ahci module on arm64. Pointed out by: kib 291766 by brueffer: ARC-1203 is supported since the latest driver update. 291753 by ngie: Fix scope of bridge_header and bridge_pcix_cap in mthca_reset(..) They're only used in the __linux__ case Differential Revision: https://reviews.freebsd.org/D4332 MFC after: 1 week Reported by: cppcheck Reviewed by: hselasky Sponsored by: EMC / Isilon Storage Division 291752 by tuexen: Fix a bug where a stream reset request wasn't retranmitted when the peer indicated "In progress". MFC after: 1 week 291751 by bdrewery: Fix 'install*' and many other missing targets with DIRDEPS_BUILD. My changes in r291635 broke 'make install*' for DIRDEPS_BUILD but also revealed that some other targets were not guaranteed to be created if there was a SUBDIR defined. One example is 'installfiles' was never defined if SUBDIR was not empty. Sponsored by: EMC / Isilon Storage Division 291750 by bdrewery: The .if redirection on .WAIT is no longer needed with bmake. Sponsored by: EMC / Isilon Storage Division 291749 by bdrewery: Fix 'afterinstall' order not being respected after my changes in r291635. The problem was that 'afterinstall' was not coming after SUBDIRs were installed which was the expectation at least in sys/modules for kldxref. Reported by: np Pointyhat to: bdrewery Sponsored by: EMC / Isilon Storage Division 291748 by bdrewery: Rearrange some common logic. 291747 by arybchik: sfxge: [EF10] support RxQ scattering control If, for example, a VF is configured to use a 1500 byte MTU, but the port it is attached to is set to 9000 bytes, overlength frames can be received by the VF. As Huntington scatters by default, these overlength packets would be scattered across several descriptors, with all except the last having the CONT bit set. To avoid this, disable scatter when creating RXQs if the firmware supports doing so, which all recent versions do. Then we only get a single descriptor from an overlength frame. This will have the CONT bit set to indicate it was truncated, so we can discard it. Submitted by: Mark Spender Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4354 291746 by arybchik: sfxge: add additional WRITESIZE value for NVRAM_INFO command Submitted by: Paul Fox Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4353 291745 by bdrewery: Remove disconnected directory RETEST. 291744 by bdrewery: Calculate MPATH for sys/modules to save 92% time in a basic 'obj' tree-walk. Sponsored by: EMC / Isilon Storage Division 291743 by mckusick: We need to zero out the clustering variables in a freed vnode structure. For completeness add a VNASSERT that there are no threads waiting on a range lock (this was previously checked on every vnode free). Reported by; Rick Macklem Fix from: Mateusz Guzik PR: 204949 291742 by ken: Fix a style issue in g_disk_limit(). Noticed by: bdrewery MFC after: 1 week 291741 by ken: Fix g_disk_vlist_limit() to work properly with deletes. Add a new bp argument to g_disk_maxsegs(), and add a new function, g_disk_maxsize() tha will properly determine the maximum I/O size for a delete or non-delete bio. Submitted by: will MFC after: 1 week Sponsored by: Spectra Logic 291740 by bdrewery: Move obscure lib/ installation of /usr/lib/include symlink to include/. This avoids the need for an afterinstall: hook and a check for LIBRARIES_ONLY. It also now respects INCLUDEDIR. This came in r249484. Sponsored by: EMC / Isilon Storage Division 291739 by bdrewery: Add assertion for when LIBADD should be used rather than LDADD/DPADD. Sponsored by: EMC / Isilon Storage Division 291738 by bdrewery: Fix LDADD/DPADD that should be LIBADD. Sponsored by: EMC / Isilon Storage Division 291737 by bdrewery: Rework unknown LIBADD assertion to be more clear and to not suggest adding DPADD/LDADD_ variables that are a special case. Sponsored by: EMC / Isilon Storage Division 291736 by bdrewery: Support all of the CDDL/ZFS libraries for LIBADD. Sponsored by: EMC / Isilon Storage Division 291735 by bdrewery: For INTERNALLIB always add in the corresponding _DP_ and use LIBADD in the real build file. This lessens the need to define DPADD_ and LDADD_ to just very special cases. Sponsored by: EMC / Isilon Storage Division 291734 by bdrewery: Replace ln -s calls with INSTALL_SYMLINK Sponsored by: EMC / Isilon Storage Division 291733 by bdrewery: Don't create a Makefile.depend in share/mk. This would cause it to be included everywhere in the build since it is the MAKESYSPATH. This leads to including dirdeps.mk more times than desired. Sponsored by: EMC / Isilon Storage Division 291732 by bdrewery: DIRDEPS_BUILD: Install new Makefile.depend files atomically. Sponsored by: EMC / Isilon Storage Division 291731 by bdrewery: DIRDEPS_BUILD: For the bootstrapped LIBADD from DPADD, resolve paths to RELDIR. This allows the LIBDEPS/DPADD for the clang build to not have ../../../lib/clang/* in DIRDEPS. Sponsored by: EMC / Isilon Storage Division 291730 by mav: Update isp_put_icb_2400() for new structure fields. 291729 by bdrewery: Simplify the LIBRARIES_ONLY hacks so that install: is not needed here. This uses the same pattern that I applied to the other cases of this in the csu directories. Sponsored by: EMC / Isilon Storage Division 291728 by benno: Tweak some unused field defines to have the correct number of zeroes. Reviewed by: jhb Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D4365 291727 by mav: Enable interrupt handshake for 16Gig chips. We don't support MSI-X so far, so it is always required. 291726 by bdrewery: rescue/rescue does not yet build in meta mode. 291725 by bdrewery: Revert r288966 as it is redundant and not right. bsd.prog.mk and bsd.lib.mk already make OBJS depend on headers when there is not .OBJDIR/.depend file, which is still true for the initial meta mode builds. If there was something to benefit the meta mode build here then it should be extended to the non-meta mode build as well. Some of the problems here were just DPSRCS being hooked up wrongly, fixed in r291330. The logic itself is flawed as 'buildfiles' is in a different part of the dependency tree than the objects and headers are, so the objects will still be built independent from 'buildfiles'. 'buildfiles' is not ordered in the build before objects. Sponsored by: EMC / Isilon Storage Division 291724 by ken: Fix typos in the camdd(8) usage() function output caused by an error in my diff filter script. Sponsored by: Spectra Logic MFC after: 1 week 291723 by nwhitehorn: Follow-on to r291666: use -ffreestanding instead of -fno-builtin. Requested by: kib 291720 by bdrewery: Convert to LIBADD Sponsored by: EMC / Isilon Storage Division 291719 by jkim: Merge OpenSSL 1.0.2e. 291718 by bdrewery: Use proper LIBADD. Sponsored by: EMC / Isilon Storage Division 291717 by bdrewery: DIRDEPS_BUILD: Connect usr.sbin/camdd Sponsored by: EMC / Isilon Storage Division 291716 by ken: Add asynchronous command support to the pass(4) driver, and the new camdd(8) utility. CCBs may be queued to the driver via the new CAMIOQUEUE ioctl, and completed CCBs may be retrieved via the CAMIOGET ioctl. User processes can use poll(2) or kevent(2) to get notification when I/O has completed. While the existing CAMIOCOMMAND blocking ioctl interface only supports user virtual data pointers in a CCB (generally only one per CCB), the new CAMIOQUEUE ioctl supports user virtual and physical address pointers, as well as user virtual and physical scatter/gather lists. This allows user applications to have more flexibility in their data handling operations. Kernel memory for data transferred via the queued interface is allocated from the zone allocator in MAXPHYS sized chunks, and user data is copied in and out. This is likely faster than the vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in configurations with many processors (there are more TLB shootdowns caused by the mapping/unmapping operation) but may not be as fast as running with unmapped I/O. The new memory handling model for user requests also allows applications to send CCBs with request sizes that are larger than MAXPHYS. The pass(4) driver now limits queued requests to the I/O size listed by the SIM driver in the maxio field in the Path Inquiry (XPT_PATH_INQ) CCB. There are some things things would be good to add: 1. Come up with a way to do unmapped I/O on multiple buffers. Currently the unmapped I/O interface operates on a struct bio, which includes only one address and length. It would be nice to be able to send an unmapped scatter/gather list down to busdma. This would allow eliminating the copy we currently do for data. 2. Add an ioctl to list currently outstanding CCBs in the various queues. 3. Add an ioctl to cancel a request, or use the XPT_ABORT CCB to do that. 4. Test physical address support. Virtual pointers and scatter gather lists have been tested, but I have not yet tested physical addresses or scatter/gather lists. 5. Investigate multiple queue support. At the moment there is one queue of commands per pass(4) device. If multiple processes open the device, they will submit I/O into the same queue and get events for the same completions. This is probably the right model for most applications, but it is something that could be changed later on. Also, add a new utility, camdd(8) that uses the asynchronous pass(4) driver interface. This utility is intended to be a basic data transfer/copy utility, a simple benchmark utility, and an example of how to use the asynchronous pass(4) interface. It can copy data to and from pass(4) devices using any target queue depth, starting offset and blocksize for the input and ouptut devices. It currently only supports SCSI devices, but could be easily extended to support ATA devices. It can also copy data to and from regular files, block devices, tape devices, pipes, stdin, and stdout. It does not support queueing multiple commands to any of those targets, since it uses the standard read(2)/write(2)/writev(2)/readv(2) system calls. The I/O is done by two threads, one for the reader and one for the writer. The reader thread sends completed read requests to the writer thread in strictly sequential order, even if they complete out of order. That could be modified later on for random I/O patterns or slightly out of order I/O. camdd(8) uses kqueue(2)/kevent(2) to get I/O completion events from the pass(4) driver and also to send request notifications internally. For pass(4) devcies, camdd(8) uses a single buffer (CAM_DATA_VADDR) per CAM CCB on the reading side, and a scatter/gather list (CAM_DATA_SG) on the writing side. In addition to testing both interfaces, this makes any potential reblocking of I/O easier. No data is copied between the reader and the writer, but rather the reader's buffers are split into multiple I/O requests or combined into a single I/O request depending on the input and output blocksize. For the file I/O path, camdd(8) also uses a single buffer (read(2), write(2), pread(2) or pwrite(2)) on reads, and a scatter/gather list (readv(2), writev(2), preadv(2), pwritev(2)) on writes. Things that would be nice to do for camdd(8) eventually: 1. Add support for I/O pattern generation. Patterns like all zeros, all ones, LBA-based patterns, random patterns, etc. Right Now you can always use /dev/zero, /dev/random, etc. 2. Add support for a "sink" mode, so we do only reads with no writes. Right now, you can use /dev/null. 3. Add support for automatic queue depth probing, so that we can figure out the right queue depth on the input and output side for maximum throughput. At the moment it defaults to 6. 4. Add support for SATA device passthrough I/O. 5. Add support for random LBAs and/or lengths on the input and output sides. 6. Track average per-I/O latency and busy time. The busy time and latency could also feed in to the automatic queue depth determination. sys/cam/scsi/scsi_pass.h: Define two new ioctls, CAMIOQUEUE and CAMIOGET, that queue and fetch asynchronous CAM CCBs respectively. Although these ioctls do not have a declared argument, they both take a union ccb pointer. If we declare a size here, the ioctl code in sys/kern/sys_generic.c will malloc and free a buffer for either the CCB or the CCB pointer (depending on how it is declared). Since we have to keep a copy of the CCB (which is fairly large) anyway, having the ioctl malloc and free a CCB for each call is wasteful. sys/cam/scsi/scsi_pass.c: Add asynchronous CCB support. Add two new ioctls, CAMIOQUEUE and CAMIOGET. CAMIOQUEUE adds a CCB to the incoming queue. The CCB is executed immediately (and moved to the active queue) if it is an immediate CCB, but otherwise it will be executed in passstart() when a CCB is available from the transport layer. When CCBs are completed (because they are immediate or passdone() if they are queued), they are put on the done queue. If we get the final close on the device before all pending I/O is complete, all active I/O is moved to the abandoned queue and we increment the peripheral reference count so that the peripheral driver instance doesn't go away before all pending I/O is done. The new passcreatezone() function is called on the first call to the CAMIOQUEUE ioctl on a given device to allocate the UMA zones for I/O requests and S/G list buffers. This may be good to move off to a taskqueue at some point. The new passmemsetup() function allocates memory and scatter/gather lists to hold the user's data, and copies in any data that needs to be written. For virtual pointers (CAM_DATA_VADDR), the kernel buffer is malloced from the new pass(4) driver malloc bucket. For virtual scatter/gather lists (CAM_DATA_SG), buffers are allocated from a new per-pass(9) UMA zone in MAXPHYS-sized chunks. Physical pointers are passed in unchanged. We have support for up to 16 scatter/gather segments (for the user and kernel S/G lists) in the default struct pass_io_req, so requests with longer S/G lists require an extra kernel malloc. The new passcopysglist() function copies a user scatter/gather list to a kernel scatter/gather list. The number of elements in each list may be different, but (obviously) the amount of data stored has to be identical. The new passmemdone() function copies data out for the CAM_DATA_VADDR and CAM_DATA_SG cases. The new passiocleanup() function restores data pointers in user CCBs and frees memory. Add new functions to support kqueue(2)/kevent(2): passreadfilt() tells kevent whether or not the done queue is empty. passkqfilter() adds a knote to our list. passreadfiltdetach() removes a knote from our list. Add a new function, passpoll(), for poll(2)/select(2) to use. Add devstat(9) support for the queued CCB path. sys/cam/ata/ata_da.c: Add support for the BIO_VLIST bio type. sys/cam/cam_ccb.h: Add a new enumeration for the xflags field in the CCB header. (This doesn't change the CCB header, just adds an enumeration to use.) sys/cam/cam_xpt.c: Add a new function, xpt_setup_ccb_flags(), that allows specifying CCB flags. sys/cam/cam_xpt.h: Add a prototype for xpt_setup_ccb_flags(). sys/cam/scsi/scsi_da.c: Add support for BIO_VLIST. sys/dev/md/md.c: Add BIO_VLIST support to md(4). sys/geom/geom_disk.c: Add BIO_VLIST support to the GEOM disk class. Re-factor the I/O size limiting code in g_disk_start() a bit. sys/kern/subr_bus_dma.c: Change _bus_dmamap_load_vlist() to take a starting offset and length. Add a new function, _bus_dmamap_load_pages(), that will load a list of physical pages starting at an offset. Update _bus_dmamap_load_bio() to allow loading BIO_VLIST bios. Allow unmapped I/O to start at an offset. sys/kern/subr_uio.c: Add two new functions, physcopyin_vlist() and physcopyout_vlist(). sys/pc98/include/bus.h: Guard kernel-only parts of the pc98 machine/bus.h header with #ifdef _KERNEL. This allows userland programs to include to get the definition of bus_addr_t and bus_size_t. sys/sys/bio.h: Add a new bio flag, BIO_VLIST. sys/sys/uio.h: Add prototypes for physcopyin_vlist() and physcopyout_vlist(). share/man/man4/pass.4: Document the CAMIOQUEUE and CAMIOGET ioctls. usr.sbin/Makefile: Add camdd. usr.sbin/camdd/Makefile: Add a makefile for camdd(8). usr.sbin/camdd/camdd.8: Man page for camdd(8). usr.sbin/camdd/camdd.c: The new camdd(8) utility. Sponsored by: Spectra Logic MFC after: 1 week 291706 by cem: if_ntb: Don't roundup MW size to full BAR size unnecessarily Note that the MW allocation still must be BAR *aligned*. So, this only loosens the constraints on MW allocation slightly. BAR-aligned does not play well with large (GB+) BAR sizes. Going forward, if anyone cares about if_ntb on very large BARs, I suggest they add functionality to allocate a smaller window than the BAR size, and set the BAR range to cover a window much larger than the allocated window. This will require negotiating a window offset and limit for protocol traffic. None of this is implemented in this revision. Sponsored by: EMC / Isilon Storage Division 291705 by cem: if_ntb: Log error *before* zeroing relevant variables Sponsored by: EMC / Isilon Storage Division 291704 by cem: Pull vm_object_scan_all_shadowed out of vm_object_backing_scan These two functions were largely unrelated, they just used the same same loop logic to walk through a backing object's memq. Pull out the all_shadowed test as its own function and eliminate OBSC_TEST_ALL_SHADOWED. Rename vm_object_backing_scan to vm_object_collapse_scan. No functional change. Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D4335 291703 by hselasky: Regenerate usb.conf . MFC after: 1 week 291702 by nwhitehorn: Bump MAXCPU. We already run on hardware with 32 threads and the same hardware is available commercially with up to 96 threads per socket. MFC after: 3 weeks The end of the build log: [...truncated 155023 lines...] --- depend_subdir_accf_data --- --- .depend --- rm -f .depend --- depend_subdir_accf_dns --- --- machine --- --- depend_subdir_accf_data --- CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/accf_data/../../netinet/accf_data.c --- depend_subdir_accf_dns --- machine -> /usr/src/sys/arm64/include --- depend_subdir_accf_http --- --- machine --- --- depend_subdir_accf_dns --- --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/accf_dns/../../netinet/accf_dns.c --- depend_subdir_accf_http --- machine -> /usr/src/sys/arm64/include --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/accf_http/../../netinet/accf_http.c --- depend_subdir_acl_nfs4 --- --- machine --- machine -> /usr/src/sys/arm64/include --- vnode_if_newproto.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p --- vnode_if_typedef.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q --- pccarddevs.h --- awk -f /usr/src/sys/tools/pccarddevs2h.awk /usr/src/sys/dev/pccard/pccarddevs --- modules-depend --- --- vnode_if.h --- --- depend_subdir_acl_posix1e --- --- depend_subdir_acl_nfs4 --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h --- depend_subdir_acl_posix1e --- ===> acl_posix1e (depend) --- usbdevs.h --- awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -h --- modules-depend --- --- machine --- machine -> /usr/src/sys/arm64/include --- vnode_if_newproto.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p --- depend_subdir_acl_nfs4 --- --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/acl_nfs4/../../kern/subr_acl_nfs4.c --- depend_subdir_acl_posix1e --- --- vnode_if_typedef.h --- --- depend_subdir_ae --- --- depend_subdir_acl_posix1e --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q --- depend_subdir_ae --- ===> ae (depend) --- depend_subdir_acl_posix1e --- --- vnode_if.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h --- depend_subdir_ae --- --- machine --- machine -> /usr/src/sys/arm64/include --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- depend_subdir_acl_posix1e --- --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/acl_posix1e/../../kern/subr_acl_posix1e.c --- depend_subdir_ae --- --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- usbdevs_data.h --- awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -d --- modules-depend --- --- miibus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/mii/miibus_if.m -h --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/ae/../../dev/ae/if_ae.c --- depend_subdir_age --- ===> age (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- miibus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/mii/miibus_if.m -h --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/age/../../dev/age/if_age.c --- depend_subdir_aha --- ===> aha (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- opt_cam.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_cam.h opt_cam.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- isa_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/isa/isa_if.m -h --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/aha/../../dev/aha/aha.c /usr/src/sys/modules/aha/../../dev/aha/aha_isa.c --- depend_subdir_ahci --- ===> ahci (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- opt_cam.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_cam.h opt_cam.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c /usr/src/sys/modules/ahci/../../dev/ahci/ahci_pci.c /usr/src/sys/modules/ahci/../../dev/ahci/ahciem.c /usr/src/sys/modules/ahci/../../dev/ahci/ahci_generic.c --- depend_subdir_aic7xxx --- ===> aic7xxx (depend) --- depend_subdir_ahc --- ===> aic7xxx/ahc (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- depend_subdir_ahc_isa --- ===> aic7xxx/ahc/ahc_isa (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- opt_scsi.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_scsi.h opt_scsi.h --- opt_cam.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_cam.h opt_cam.h --- opt_aic7xxx.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_aic7xxx.h opt_aic7xxx.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- isa_if.h --- --- depend_subdir_ahc_pci --- --- depend_subdir_ahc_isa --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/isa/isa_if.m -h --- depend_subdir_ahc_pci --- ===> aic7xxx/ahc/ahc_pci (depend) --- depend_subdir_ahc_isa --- --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I/usr/src/sys/modules/aic7xxx/ahc/ahc_isa/../../../../dev/aic7xxx -I.. -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/aic7xxx/ahc/ahc_isa/../../../../dev/aic7xxx/ahc_isa.c --- depend_subdir_ahc_pci --- --- machine --- machine -> /usr/src/sys/arm64/include --- opt_scsi.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_scsi.h opt_scsi.h --- opt_cam.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_cam.h opt_cam.h --- opt_aic7xxx.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_aic7xxx.h opt_aic7xxx.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- depend_subdir_ahci --- In file included from /usr/src/sys/modules/ahci/../../dev/ahci/ahci_generic.c:47: /usr/src/sys/dev/ofw/ofw_bus.h:36:10: fatal error: 'ofw_bus_if.h' file not found #include "ofw_bus_if.h" ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in /usr/src/sys/modules/ahci 1 error make[4]: stopped in /usr/src/sys/modules/ahci *** [depend_subdir_ahci] Error code 2 make[3]: stopped in /usr/src/sys/modules --- depend_subdir_aic7xxx --- A failure has been detected in another branch of the parallel make make[6]: stopped in /usr/src/sys/modules/aic7xxx/ahc/ahc_pci *** [depend_subdir_ahc_pci] Error code 2 make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc --- depend_subdir_ahc_isa --- A failure has been detected in another branch of the parallel make make[6]: stopped in /usr/src/sys/modules/aic7xxx/ahc/ahc_isa *** [depend_subdir_ahc_isa] Error code 2 make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc 2 errors make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc *** [depend_subdir_ahc] Error code 2 make[4]: stopped in /usr/src/sys/modules/aic7xxx 1 error make[4]: stopped in /usr/src/sys/modules/aic7xxx *** [depend_subdir_aic7xxx] Error code 2 make[3]: stopped in /usr/src/sys/modules 2 errors make[3]: stopped in /usr/src/sys/modules *** [modules-depend] Error code 2 make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC 1 error make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson788315144804630871.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Tue Dec 8 19:34:46 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E8029D59EC for ; Tue, 8 Dec 2015 19:34:46 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE0741B7A for ; Tue, 8 Dec 2015 19:34:45 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: by lfaz4 with SMTP id z4so19582383lfa.0 for ; Tue, 08 Dec 2015 11:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=X0AIALYU5l1p1QpHqctCXEk4UKwK5SrszpaTfb0zDPk=; b=vYtfV90JNQkOcyhesE2S6d2DEn37Ir5SZ6N/Ms/DHcdIBQkfHra6+HG94lEH1ohuBU zYpSCHLIOmTT4nvzsW+QMgoH59L69MiaXRtv1zN2AH7CKJCGwv0h/diDv7ZRPVZtMGzL sXT1bFEH6KTSZwseTuvfClzmzVUJHiGa525lPA16Wvm1Y8RL7RzVD5ywS2gidcmODHad OPcmCl6AbkgVq+o/G5i6jDdH0gj2YoVh2ngrp7hlEY7gjFmHqm9vDmF4c7z2HsrwqLvE 2P/qoXNhefy1+af2nudWPmt2pEisUcFZN5DQJGzJ/3XWF4z+/TNpxWSi7O+Kl+G/M630 ne+A== 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:cc :content-type; bh=X0AIALYU5l1p1QpHqctCXEk4UKwK5SrszpaTfb0zDPk=; b=aeQfL/FExg1q45pEEtOjFyF3YHZAA3AxQA0bbqwzaRJmvy/rGIe2bxXcCnpCt6l//x qiW+nugnmumie7SpuSNgV3JcbQBWJ0PWdgzELJOiX3VJQ7Xz8/TZ10A20Hoolus2ReT2 hWUhWBg9gy3YalJxE4/UtYeFZ4mEfkunkUSxuSIiAMZI8V6SbwX+73rNvG9Skyh51XOZ jxxWtPRD+HJ+MXdgdmB6PjumweMwB0HEBx8DuHO69hMrR2DQZyI1A5fmMUrDMEk5yUbW grzUNZbB/S0koPeQ1/UbNMmzvShcd0/YRiQZFMkZwbMbaEL+HnPzKaK7qvz7rMssDAjT DCEQ== X-Gm-Message-State: ALoCoQkTIkRAr2ULw36kBQcSQDMrX72yF4R4VPjNIiAottXRoyDKU9JddLDZhlErGm2GD2WomGfqft2uLPFmJWJswr/UZ7jK0A== X-Received: by 10.25.42.20 with SMTP id q20mr481358lfq.158.1449603283925; Tue, 08 Dec 2015 11:34:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.76.65 with HTTP; Tue, 8 Dec 2015 11:34:24 -0800 (PST) From: Zbigniew Bodek Date: Tue, 8 Dec 2015 20:34:24 +0100 Message-ID: Subject: Various panics while using HWPMC on ARM64 To: br@freebsd.org, Andrew Turner Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 19:34:46 -0000 Hello, I encountered some problems with FreeBSD on ARM64 while using hwpmc. Some of the errors that I found are listed below: * panic: Unknown kernel exception 0 esr_el1 2000000 * panic: data abort in critical section or under mutex * panic: VFP exception in the kernel * panic: Unknown kernel exception 21 esr_el1 86000006 Something is obviously broken. This can be easily reproduced by invoking for example: $ pmcstat -S CPU_CYCLES -O cpu_cycles.pmc wait ~30 seconds or more and hit ctrl + C Platform: ThunderX CRB (single socket) SVN rev: 291651 Kernel: GENERIC + "device hwpmc" - "some debugging options" (also verified that GENERIC + "device hwpmc" does the same) Logs + patch for GENERIC conf. + kernel binary + objdumped kernel: https://people.freebsd.org/~zbb/arm64/armv8_panic.tar.gz Kind regards From owner-freebsd-arm@freebsd.org Tue Dec 8 19:42:45 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D0D39D5F3E for ; Tue, 8 Dec 2015 19:42:45 +0000 (UTC) (envelope-from ulrich-grey@t-online.de) Received: from mailout12.t-online.de (mailout12.t-online.de [194.25.134.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9ACF12FF for ; Tue, 8 Dec 2015 19:42:44 +0000 (UTC) (envelope-from ulrich-grey@t-online.de) Received: from fwd17.aul.t-online.de (fwd17.aul.t-online.de [172.20.27.64]) by mailout12.t-online.de (Postfix) with SMTP id A43E121CAD2; Tue, 8 Dec 2015 20:35:05 +0100 (CET) Received: from work (ZB8gMsZFohc74vcGS-eWnugmFHxtEESpqKW6T5vZW+fcrBWc2GvL4BmYNOFlVE9QaB@[84.134.154.184]) by fwd17.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1a6O2Q-1tVeng0; Tue, 8 Dec 2015 20:35:02 +0100 Date: Tue, 8 Dec 2015 20:35:01 +0100 From: Ulrich Grey To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Subject: Re: Updating / keeping current strategies? Message-Id: <20151208203501.519ce6dc889894f7a947f989@t-online.de> In-Reply-To: <5666F37C.4060908@denninger.net> References: <5666F37C.4060908@denninger.net> Organization: - X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; armv6-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: ZB8gMsZFohc74vcGS-eWnugmFHxtEESpqKW6T5vZW+fcrBWc2GvL4BmYNOFlVE9QaB X-TOI-MSGID: 69dac60a-c67e-4806-af7e-8ed21e45ce39 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 19:42:45 -0000 I am building images natively on my cubox, using the sript: /usr/src/release/release.sh -c arm/.conf I added some lines to arm/.conf: ##CHROOTBUILD_SKIP="yes" CHROOTDIR="/path/to/chroot" ##SRC_UPDATE_SKIP="yes" ##PORTS_UPDATE_SKIP="yes" #SRCBRANCH="base/head@r285417" MAKE_CONF="/etc/local/make.conf" #SRC_CONF="/etc/local/src.conf ... ... To /etc/local/make.conf (host) I write: #KERNFAST=1 MALLOC_PRODUCTION=yes #NO_CLEAN=1 1) Install chroot environment 2) co ports and src into chroot 3) Run script release.sh -c arm/.conf for the first board (about 14 hours) (host) 3a) Rename image 4) Uncomment NO_CLEAN=1 in /etc/local/make.conf (host) 5) Like 3) for second board (about 1 hour) ... The images are saved to /R --------------------------------- On Tue, 8 Dec 2015 09:13:00 -0600 Karl Denninger wrote: > What are people doing in this regard with devices like the Raspberry Pi2? > > Build times for a "make buildworld" are measured in (many) hours to a > day or more and require a USB-attached disk for temporary storage, as > the ramdisk for /tmp that is typically mounted blows up due to lack of > space and SD cards are slow enough on writes (especially small writes) > as to make the process virtually impossible. But even with a > USB-attached disk the process is ridiculous in terms of consumed > walllclock time. > > Further, "make installworld" sometimes fails inexplicably. > > Kernel builds are a bit more reasonable, only requiring a couple of hours. > > I'm wondering what the best option is to not only build current code on > a regular basis (since -CURRENT is a "work in progress") but also to > deploy and update existing devices. What are people doing that has a > history of working well? > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ From owner-freebsd-arm@freebsd.org Tue Dec 8 19:59:27 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E5739D4C1F for ; Tue, 8 Dec 2015 19:59:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E52EE1FD7; Tue, 8 Dec 2015 19:59:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by igcmv3 with SMTP id mv3so108957463igc.0; Tue, 08 Dec 2015 11:59:26 -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:from:date:message-id :subject:to:cc:content-type; bh=49b5CyrkvdZQPtJpCkrMmstQFrPNPfioNOhe1OdLLxQ=; b=AYZly1babudmBaMvy2cw5Vi9Dou9yJU+aOYwSoSE+v6/c8x2fHGAqGHNxTsFfHlQdn HM1EuOEHPZEjeEA11pGuk8qCOvznjK4fBt7sBN+85GavPQZdiA/nqlQlauO08cLu8afh BWlYO/youBUot1y7oXAHXi/7OgQIAtzNYRxZTOhcoucQJhNEu6976gxJPv8FxWRax7zE 76WbJOgdbn9RRnnOpxPNLwJyaYcUY+n7rLLBPXLfhtWlnyFDSQ9eb3oo8+KR3d5EgN1s ZHehspMctZswok9XbvvYpOal+SBpKZXgWemzU9Ae9ZHS5nk2L2pK/zxSiBuo+y4OvUQ/ Ep5Q== X-Received: by 10.50.6.104 with SMTP id z8mr24492156igz.58.1449604766317; Tue, 08 Dec 2015 11:59:26 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.169.85 with HTTP; Tue, 8 Dec 2015 11:59:06 -0800 (PST) In-Reply-To: References: From: Ed Maste Date: Tue, 8 Dec 2015 14:59:06 -0500 X-Google-Sender-Auth: KAUjWGEFEfyK06neFZowa5Ra12E Message-ID: Subject: Re: Various panics while using HWPMC on ARM64 To: Zbigniew Bodek Cc: Ruslan Bukin , Andrew Turner , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 19:59:27 -0000 On 8 December 2015 at 14:34, Zbigniew Bodek wrote: > Hello, > > I encountered some problems with FreeBSD on ARM64 while using hwpmc. > Some of the errors that I found are listed below: > > * panic: Unknown kernel exception 0 esr_el1 2000000 > * panic: data abort in critical section or under mutex > * panic: VFP exception in the kernel > * panic: Unknown kernel exception 21 esr_el1 86000006 Can you add these notes to PR 204686? I think there are SMP issues in arm64 hwpmc that need to be resolved. From owner-freebsd-arm@freebsd.org Tue Dec 8 20:49:33 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 540DE9D565E for ; Tue, 8 Dec 2015 20:49:33 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3871B1C2A; Tue, 8 Dec 2015 20:49:33 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A427A1D3E; Tue, 8 Dec 2015 20:49:32 +0000 (UTC) Date: Tue, 8 Dec 2015 20:49:30 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: emaste@FreeBSD.org, smh@FreeBSD.org, bdrewery@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1528023525.5.1449607772519.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <358635345.1.1449600877149.JavaMail.jenkins@jenkins-9.freebsd.org> References: <358635345.1.1449600877149.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1854 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 20:49:33 -0000 FreeBSD_HEAD_arm64 - Build #1854 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1854/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1854/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1854/console Change summaries: 292000 by emaste: Remove historical GNUC test The requirement is for a GCC-compatible compiler and not necessarily GCC itself. However, we currently expect any compiler used for building the whole of FreeBSD to be GCC-compatible and many things will break if not; there's no longer a need to have an explicit test for this in csu. Sponsored by: The FreeBSD Foundation 291999 by emaste: Add comment explaining aarch64's BROKEN_OPTIONS In-tree bintuils and GCC do not support aarch64 or other recent architectures. 291998 by smh: Don't use 0 for pointer comparison Use NULL instead of 0 for comparison with panicstr. MFC after: 1 week Sponsored by: Multiplay 291997 by bdrewery: META MODE: Define a STAGE_TARGET_OBJTOP and export it alone with STAGE_OBJTOP and STAGE_HOST_OBJTOP. These will always be overridden in sub-makes when building in-tree, but are exported for the benefit of hooking in external builds, such as ports. Sponsored by: EMC / Isilon Storage Division The end of the build log: [...truncated 155629 lines...] --- depend_subdir_accf_dns --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/accf_dns/../../netinet/accf_dns.c --- depend_subdir_accf_data --- CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/accf_data/../../netinet/accf_data.c --- depend_subdir_accf_http --- --- machine --- machine -> /usr/src/sys/arm64/include --- .depend --- rm -f .depend --- depend_subdir_acl_nfs4 --- --- depend_subdir_accf_http --- CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/accf_http/../../netinet/accf_http.c --- depend_subdir_acl_nfs4 --- ===> acl_nfs4 (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- vnode_if_newproto.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p --- vnode_if_typedef.h --- --- usbdevs.h --- --- modules-depend --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q --- usbdevs.h --- awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -h --- modules-depend --- --- depend_subdir_acl_posix1e --- ===> acl_posix1e (depend) --- depend_subdir_ae --- ===> ae (depend) --- depend_subdir_acl_nfs4 --- --- vnode_if.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h --- depend_subdir_acl_posix1e --- --- machine --- machine -> /usr/src/sys/arm64/include --- vnode_if_newproto.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p --- depend_subdir_ae --- --- machine --- machine -> /usr/src/sys/arm64/include --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- depend_subdir_acl_posix1e --- --- vnode_if_typedef.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q --- depend_subdir_acl_nfs4 --- --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/acl_nfs4/../../kern/subr_acl_nfs4.c --- depend_subdir_ae --- --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- depend_subdir_acl_posix1e --- --- vnode_if.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h --- depend_subdir_ae --- --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- miibus_if.h --- --- depend_subdir_acl_posix1e --- --- .depend --- --- depend_subdir_ae --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/mii/miibus_if.m -h --- depend_subdir_acl_posix1e --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/acl_posix1e/../../kern/subr_acl_posix1e.c --- usbdevs_data.h --- awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -d --- modules-depend --- --- depend_subdir_ae --- --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/ae/../../dev/ae/if_ae.c --- depend_subdir_age --- ===> age (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- depend_subdir_aha --- ===> aha (depend) --- depend_subdir_age --- --- miibus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/mii/miibus_if.m -h --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/age/../../dev/age/if_age.c --- depend_subdir_aha --- --- machine --- machine -> /usr/src/sys/arm64/include --- opt_cam.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_cam.h opt_cam.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- isa_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/isa/isa_if.m -h --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/aha/../../dev/aha/aha.c /usr/src/sys/modules/aha/../../dev/aha/aha_isa.c --- depend_subdir_ahci --- ===> ahci (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- opt_cam.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_cam.h opt_cam.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- depend_subdir_aic7xxx --- ===> aic7xxx (depend) --- depend_subdir_ahci --- --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c /usr/src/sys/modules/ahci/../../dev/ahci/ahci_pci.c /usr/src/sys/modules/ahci/../../dev/ahci/ahciem.c /usr/src/sys/modules/ahci/../../dev/ahci/ahci_generic.c --- depend_subdir_aic7xxx --- --- depend_subdir_ahc --- ===> aic7xxx/ahc (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- depend_subdir_ahc_isa --- ===> aic7xxx/ahc/ahc_isa (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- opt_scsi.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_scsi.h opt_scsi.h --- opt_cam.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_cam.h opt_cam.h --- opt_aic7xxx.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_aic7xxx.h opt_aic7xxx.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- isa_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/isa/isa_if.m -h --- .depend --- rm -f .depend CC='cc -B/usr/local/aarch64-freebsd/bin/' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I/usr/src/sys/modules/aic7xxx/ahc/ahc_isa/../../../../dev/aic7xxx -I.. -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 /usr/src/sys/modules/aic7xxx/ahc/ahc_isa/../../../../dev/aic7xxx/ahc_isa.c --- depend_subdir_ahc_pci --- ===> aic7xxx/ahc/ahc_pci (depend) --- machine --- machine -> /usr/src/sys/arm64/include --- opt_scsi.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_scsi.h opt_scsi.h --- opt_cam.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_cam.h opt_cam.h --- opt_aic7xxx.h --- ln -sf /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_aic7xxx.h opt_aic7xxx.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- depend_subdir_ahci --- In file included from /usr/src/sys/modules/ahci/../../dev/ahci/ahci_generic.c:47: /usr/src/sys/dev/ofw/ofw_bus.h:36:10: fatal error: 'ofw_bus_if.h' file not found #include "ofw_bus_if.h" ^ --- depend_subdir_aic7xxx --- --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- depend_subdir_ahci --- 1 error generated. mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in /usr/src/sys/modules/ahci 1 error make[4]: stopped in /usr/src/sys/modules/ahci *** [depend_subdir_ahci] Error code 2 make[3]: stopped in /usr/src/sys/modules --- depend_subdir_aic7xxx --- --- depend_subdir_ahc_isa --- A failure has been detected in another branch of the parallel make make[6]: stopped in /usr/src/sys/modules/aic7xxx/ahc/ahc_isa *** [depend_subdir_ahc_isa] Error code 2 make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc --- depend_subdir_ahc_pci --- A failure has been detected in another branch of the parallel make make[6]: stopped in /usr/src/sys/modules/aic7xxx/ahc/ahc_pci *** [depend_subdir_ahc_pci] Error code 2 make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc 2 errors make[5]: stopped in /usr/src/sys/modules/aic7xxx/ahc *** [depend_subdir_ahc] Error code 2 make[4]: stopped in /usr/src/sys/modules/aic7xxx 1 error make[4]: stopped in /usr/src/sys/modules/aic7xxx *** [depend_subdir_aic7xxx] Error code 2 make[3]: stopped in /usr/src/sys/modules 2 errors make[3]: stopped in /usr/src/sys/modules *** [modules-depend] Error code 2 make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC 1 error make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson8765335907978253543.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Tue Dec 8 22:15:17 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6BAB9D45ED for ; Tue, 8 Dec 2015 22:15:17 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) 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 881FD1140 for ; Tue, 8 Dec 2015 22:15:17 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.15.2/8.15.2) with ESMTPA id tB8MFEbK030802 for ; Tue, 8 Dec 2015 23:15:15 +0100 (CET) (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, 08 Dec 2015 23:15:14 +0100 (CET) Message-ID: <475b25742d8.1cb61c79@mail.schwarzes.net> In-Reply-To: <5666F37C.4060908@denninger.net> References: <5666F37C.4060908@denninger.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: Updating / keeping current strategies? 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, 08 Dec 2015 23:15:15 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 22:15:18 -0000 On 08.12.15, Karl Denninger wrote: > What are people doing in this regard with devices like the Raspberry Pi2? > > Build times for a "make buildworld" are measured in (many) hours to a > day or more and require a USB-attached disk for temporary storage, as > the ramdisk for /tmp that is typically mounted blows up due to lack of > space and SD cards are slow enough on writes (especially small writes) > as to make the process virtually impossible. But even with a > USB-attached disk the process is ridiculous in terms of consumed > walllclock time. I'm building the world directly at my RPI2 without problems. Did this already with my former RPI and I'm not using an extra USB Disk. Building the toolchain takes ~300, kernel ~50 and world ~800 minutes. I'm using a 1 GB swap partition and tmpfs (not md) for /tmp and /var/tmp, no problem so far. root@pizelot:~ # swapinfo Device 1K-blocks Used Avail Capacity /dev/mmcsd0s2b 1048576 9548 1039028 1% root@pizelot:~ # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mmcsd0s2a 1015324 63940 870160 7% / devfs 1 1 0 100% /dev /dev/mmcsd0s2d 8106716 3897656 3560524 52% /usr /dev/mmcsd0s2e 8106716 163200 7294980 2% /var /dev/mmcsd0s2f 8106716 16 7458164 0% /home tmpfs 1224992 40 1224952 0% /tmp tmpfs 1224956 4 1224952 0% /var/tmp -asc From owner-freebsd-arm@freebsd.org Tue Dec 8 22:54:53 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27C529D3235 for ; Tue, 8 Dec 2015 22:54:53 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1A77618B2; Tue, 8 Dec 2015 22:54:53 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id CC82C1D89; Tue, 8 Dec 2015 22:54:52 +0000 (UTC) Date: Tue, 8 Dec 2015 22:54:50 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: hiren@FreeBSD.org, andrew@FreeBSD.org, bdrewery@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1895771148.7.1449615292061.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1528023525.5.1449607772519.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1528023525.5.1449607772519.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1855 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 22:54:53 -0000 FreeBSD_HEAD_arm64 - Build #1855 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1855/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1855/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1855/console Change summaries: 292003 by hiren: One of the ways to detect loss is to count duplicate acks coming back from the other end till it reaches predetermined threshold which is 3 for us right now. Once that happens, we trigger fast-retransmit to do loss recovery. Main problem with the current implementation is that we don't honor SACK information well to detect whether an incoming ack is a dupack or not. RFC6675 has latest recommendations for that. According to it, dupack is a segment that arrives carrying a SACK block that identifies previously unknown information between snd_una and snd_max even if it carries new data, changes the advertised window, or moves the cumulative acknowledgment point. With the prevalence of Selective ACK (SACK) these days, improper handling can lead to delayed loss recovery. With the fix, new behavior looks like following: 0) th_ack < snd_una --> ignore Old acks are ignored. 1) th_ack == snd_una, !sack_changed --> ignore Acks with SACK enabled but without any new SACK info in them are ignored. 2) th_ack == snd_una, window == old_window --> increment Increment on a good dupack. 3) th_ack == snd_una, window != old_window, sack_changed --> increment When SACK enabled, it's okay to have advertized window changed if the ack has new SACK info. 4) th_ack > snd_una --> reset to 0 Reset to 0 when left edge moves. 5) th_ack > snd_una, sack_changed --> increment Increment if left edge moves but there is new SACK info. Here, sack_changed is the indicator that incoming ack has previously unknown SACK info in it. Note: This fix is not fully compliant to RFC6675. That may require a few changes to current implementation in order to keep per-sackhole dupack counter and change to the way we mark/handle sack holes. PR: 203663 Reviewed by: jtl MFC after: 3 weeks Sponsored by: Limelight Networks Differential Revision: https://reviews.freebsd.org/D4225 292002 by bdrewery: CCACHE_BUILD: Only export CCACHE_PATH= if it was already set with a value. Older ccache don't work with an empty CCACHE_PATH value. They will error with: ccache: FATAL: Could not find compiler "cc" in PATH make: "/mnt/bdrewery/git/onefs/src/share/mk/bsd.compiler.mk" line 134: Unable to determine compiler type for /usr/local/bin/ccache cc. Consider setting COMPILER_TYPE. Sponsored by: EMC / Isilon Storage Division 292001 by andrew: ahci_generic.c needs ofw_bus_if.h, add it to the module. From owner-freebsd-arm@freebsd.org Wed Dec 9 12:06:31 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA8DD9D58F4 for ; Wed, 9 Dec 2015 12:06:31 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 532D61B07 for ; Wed, 9 Dec 2015 12:06:31 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: by lffu14 with SMTP id u14so32719889lff.1 for ; Wed, 09 Dec 2015 04:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hrGS0aHxoDtjtD3dAH3IeKJYNg+ItnWqH5UZaan5Dis=; b=i/hhaYBC90o9R6fVYyLuyoCr072DU9MFO3cwp6FZu0ZWKqtBkP4gnGnMDoZioLvMkq hT1LKMs3FIBVF4opQkjHcJL5WarEJzfqmKMFcy1qqyQA9EEDqjU/jv3G4exKjmhxUPhQ P7E/HJtmDazBx9fexdXw/Er3QpS0UzgQ2A+8ikmoMjlfmVObmqop1aP84Sf568kWcx5D df2jSVmJ834Mu65FBi9NSpAJufGrX2oApVO5ncEmsvsMGrs/blZmZj+I2u/i8yLg5nHS gIlQBNCVjDbfYX6Zn7zivn6nbULNHGo8WZhjiTqWRViZL0J/BW6YQBuF/2A/eWCW0731 hUew== 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=hrGS0aHxoDtjtD3dAH3IeKJYNg+ItnWqH5UZaan5Dis=; b=TD2W93qcp2GwuwLPVLpw3YB8O49owXiLkHz7/ck6KRuS6sokcSluib3NS4Q8wcxqVT AIEt50g6hhQKYoJtgyo6EVnx3SnwJIuvd4kqjX+g9kj4BGEGfgKDyRQ/KHpIAdwuwTDk /CsiuK5sMUNLEGs9ByDXw8z64YZ5/K05Op+0TRWrlTwDF6k73Etltl17VqkvKfmn3oWv +mcFmjWiSYj2QEw03ijf95R68vau8bVhL/DdQSDbwhvLbTfd+SfTcP61PHE07JNJNF8p tbE0TMhybYiq9TxAwTJrcasiE/vucdoUCOT6Ee8mtXaul4OvrFwly1vXZK3+k1R7bmsd VpxQ== X-Gm-Message-State: ALoCoQlxYn3w3VOQ0P7rrhGBDWhWTyZPkw/v18n3N0CPqJg5rni8YsLLATToNHGUlCx7pqM8RsuKDCTx0a/n/Ae0VMjlBUx08g== X-Received: by 10.25.149.139 with SMTP id x133mr1650359lfd.57.1449662788943; Wed, 09 Dec 2015 04:06:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.76.65 with HTTP; Wed, 9 Dec 2015 04:06:09 -0800 (PST) In-Reply-To: References: From: Zbigniew Bodek Date: Wed, 9 Dec 2015 13:06:09 +0100 Message-ID: Subject: Re: Various panics while using HWPMC on ARM64 To: Ed Maste Cc: Ruslan Bukin , Andrew Turner , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 12:06:32 -0000 Hello Ed, Done. I also check what happens when SMP is disabled and the kassert is triggered: root@thunderx_crb4:~ # pmcstat -S CPU_CYCLES -O cpu_cycles.pmc ^Cpanic: [pmc,4256] cpu 0 didn't find a sample to collect KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0xffffff80004e9aac lr = 0xffffff800006d8b4 sp = 0xffffff87cba976e0 fp = 0xffffff87cba97800 db_trace_self_wrapper() at vpanic+0x9c pc = 0xffffff800006d8b4 lr = 0xffffff800027136c sp = 0xffffff87cba97810 fp = 0xffffff87cba97880 vpanic() at kassert_panic+0x160 pc = 0xffffff800027136c lr = 0xffffff80002712cc sp = 0xffffff87cba97890 fp = 0xffffff87cba97950 kassert_panic() at pmc_capture_user_callchain+0x1a4 pc = 0xffffff80002712cc lr = 0xffffff80000e1444 sp = 0xffffff87cba97960 fp = 0xffffff87cba979c0 pmc_capture_user_callchain() at pmc_hook_handler+0x7c0 pc = 0xffffff80000e1444 lr = 0xffffff80000dfb78 sp = 0xffffff87cba979d0 fp = 0xffffff87cba97a50 pmc_hook_handler() at ast+0x14c pc = 0xffffff80000dfb78 lr = 0xffffff80002b976c sp = 0xffffff87cba97a60 fp = 0xffffff87cba97a90 ast() at handle_el0_sync+0x90 pc = 0xffffff80002b976c lr = 0xffffff80004eb224 sp = 0xffffff87cba97aa0 fp = 0xffffff87cba97bb0 handle_el0_sync() at 0x406d60 pc = 0xffffff80004eb224 lr = 0x0000000000406d60 sp = 0xffffff87cba97bc0 fp = 0x0000007ffffff540 KDB: enter: panic [ thread pid 679 tid 100061 ] Stopped at kdb_enter+0x40: db> when invariants options is disabled I only get: root@thunderx_crb4:~ # pmcstat -S CPU_CYCLES -O cpu_cycles.pmc ^Cpmcstat: WARNING: sampling was paused at least 1 time. Please consider tuning the "kern.hwpmc.nsamples" tunable. Best regards zbb 2015-12-08 20:59 GMT+01:00 Ed Maste : > On 8 December 2015 at 14:34, Zbigniew Bodek wrote: >> Hello, >> >> I encountered some problems with FreeBSD on ARM64 while using hwpmc. >> Some of the errors that I found are listed below: >> >> * panic: Unknown kernel exception 0 esr_el1 2000000 >> * panic: data abort in critical section or under mutex >> * panic: VFP exception in the kernel >> * panic: Unknown kernel exception 21 esr_el1 86000006 > > Can you add these notes to PR 204686? I think there are SMP issues in > arm64 hwpmc that need to be resolved. From owner-freebsd-arm@freebsd.org Thu Dec 10 22:08:00 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D3DF9D710F for ; Thu, 10 Dec 2015 22:08:00 +0000 (UTC) (envelope-from sjms@rambler.ru) Received: from mxout2.rambler.ru (mxout2.rambler.ru [81.19.67.204]) by mx1.freebsd.org (Postfix) with ESMTP id BF8D51FDD for ; Thu, 10 Dec 2015 22:07:59 +0000 (UTC) (envelope-from sjms@rambler.ru) Received: from saddam2.rambler.ru (saddam2.rambler.ru [10.32.16.2]) by mxout2.rambler.ru (Postfix) with ESMTP id B92CA9055C1 for ; Fri, 11 Dec 2015 01:00:32 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rambler.ru; s=mail; t=1449784832; bh=iIXF/QkQ7W9o4eju6ovF6/QAj4uxYyQ7qYiTKxmBBUI=; h=From:To:Reply-To:Subject:Date; b=BpdOxsr44wIgBv7xH3ev7W5kcHo+qpilK+4iGE+nWXCsIN9gpm2PkhGf1TmQTDEbf 57LEDGWRFSefpwHl5lg8B0Xbxml7vYCrY34X8Xk4ISvp1xtqBdnvUue2qGgYc9B4JV gQBpuwfVNsr+f/FTcXOfc4bPCCT4Pr4JgpNnbEhY= Received: from localhost.localdomain (localhost [127.0.0.1]) by saddam2.rambler.ru (Postfix) with ESMTP id 922CA124265E for ; Fri, 11 Dec 2015 01:00:32 +0300 (MSK) Received: from [94.140.215.142] by mail.rambler.ru with HTTP; Fri, 11 Dec 2015 01:00:32 +0300 From: =?koi8-r?B?88XSx8XKIP7XxdLUztHL?= To: freebsd-arm@freebsd.org Reply-To: =?koi8-r?B?88XSx8XKIP7XxdLUztHL?= Subject: support Allwinner H3 Date: Fri, 11 Dec 2015 01:00:32 +0300 Message-Id: <1449784832.417138.27650.30415@mail.rambler.ru> MIME-Version: 1.0 X-Mailer: Rambler WebMail, http://mail.rambler.ru/ X-Rambler-User: sjms@rambler.ru/94.140.215.142 X-Mailman-Approved-At: Thu, 10 Dec 2015 22:23:33 +0000 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 22:08:00 -0000 Please help. I do not understand how to create a boot exactly for Allwinner H3 (board Or= angePi PC). There are practices in support of processors Allwinner H3? Thanks! Best regards, Sergey! From owner-freebsd-arm@freebsd.org Thu Dec 10 22:31:16 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 197249D6492 for ; Thu, 10 Dec 2015 22:31:16 +0000 (UTC) (envelope-from m.vale@live.com.au) Received: from COL004-OMC3S17.hotmail.com (col004-omc3s17.hotmail.com [65.55.34.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D91C61EB8 for ; Thu, 10 Dec 2015 22:31:15 +0000 (UTC) (envelope-from m.vale@live.com.au) Received: from COL401-EAS378 ([65.55.34.137]) by COL004-OMC3S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 10 Dec 2015 14:30:08 -0800 X-TMN: [5xV1iDgvKKhUmwRmBHGrTX+5PK1vbzuF] X-Originating-Email: [m.vale@live.com.au] Message-ID: From: =?utf-8?B?bS52YWxlQGxpdmUuY29tLmF1?= To: =?utf-8?B?ZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmc=?= Subject: Wolfson Audio for Raspberry Pi X-Priority: 3 Importance: Normal Date: Thu, 10 Dec 2015 22:29:00 +0000 MIME-Version: 1.0 X-Mailer: Infraware POLARIS Mobile Mailer v2.5 X-OriginalArrivalTime: 10 Dec 2015 22:30:08.0571 (UTC) FILETIME=[5348B8B0:01D1339A] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 22:31:16 -0000 CgoKCgoKICAgIEhpLApKdXN0IHdvbmRlcmluZyBpZiBhbnlvbmUgd2FzIHdpbGxpbmcgdG8gdGFr ZSBhIGxvb2sgYXQgc3VwcG9ydGluZyB0aGUgUmFzcGJlcnJ5IFBpIFdvbGZzb24gQXVkaW8gY2Fy ZD8KUmVnYXJkcywKTWljaGFlbC4KU2VudCBmcm9tIG15IExHIEczIG9uIHRoZSBUZWxzdHJhIE1v YmlsZSBuZXR3b3JrCgoK From owner-freebsd-arm@freebsd.org Fri Dec 11 01:24:12 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A993E9D6EB1 for ; Fri, 11 Dec 2015 01:24:12 +0000 (UTC) (envelope-from serge0x76@gmail.com) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77E2A1C86 for ; Fri, 11 Dec 2015 01:24:12 +0000 (UTC) (envelope-from serge0x76@gmail.com) Received: by qgcc31 with SMTP id c31so175861966qgc.3 for ; Thu, 10 Dec 2015 17:24: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:content-transfer-encoding; bh=NcjQxqW/Se+0BYBqjaFP0NH7kVomtmytBRVrlxyUEPE=; b=V5IhKdCqaGP5IJxBXQYXNhCnTbzy3RcJthWhqDNETYZoQkKOfSC3g0Qou1RY4F2ltW nByGFtrkOcB1W0VZQeLjZHdBNYqe5tFawUI/CKy4fxOetyZGbpgyyQ6B0KW6/rpVNWsV zOKIIYybcTrNzmnZDbbqll01eNqGpc1plu9hT6c19qisc19lji2aFRoId98lnc2gC/U1 TYnDjo3ArzhBKS9semVaXqRiZrVYl/2QzOdsqFCeUt3kEDyIOj8c6sp3Xbvo3Dv/hfvV buQvwVibG1vUwWZqL1A9hRBbpk3bQPHZu1SUjRQFvQl0+XJXgfHEqW1iyIgAQg1jkHcM t6/w== MIME-Version: 1.0 X-Received: by 10.55.40.153 with SMTP id o25mr175872qko.93.1449797051556; Thu, 10 Dec 2015 17:24:11 -0800 (PST) Received: by 10.55.179.71 with HTTP; Thu, 10 Dec 2015 17:24:11 -0800 (PST) In-Reply-To: <1449784832.417138.27650.30415@mail.rambler.ru> References: <1449784832.417138.27650.30415@mail.rambler.ru> Date: Thu, 10 Dec 2015 20:24:11 -0500 Message-ID: Subject: Re: support Allwinner H3 From: Serge Voilokov To: =?UTF-8?B?0KHQtdGA0LPQtdC5INCn0LLQtdGA0YLQvdGP0Lo=?= Cc: 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.20 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 Dec 2015 01:24:12 -0000 Serge, Take a look into this blog: https://www.bidouilliste.com/blog/2015/11/27/Porting-FreeBSD-to-a-new-ARM-B= oard-Part-1/. Maybe you'll find some hint there. On Thu, Dec 10, 2015 at 5:00 PM, =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9 =D0= =A7=D0=B2=D0=B5=D1=80=D1=82=D0=BD=D1=8F=D0=BA wrote: > Please help. > I do not understand how to create a boot exactly for Allwinner H3 (board > OrangePi > PC). > There are practices in support of processors Allwinner H3? > Thanks! > > Best regards, Sergey! > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://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 Dec 11 15:00:41 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A3A99D8234 for ; Fri, 11 Dec 2015 15:00:41 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) 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 8D63D1846 for ; Fri, 11 Dec 2015 15:00:40 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.9/8.14.9) with ESMTP id tBBF0LuB044377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Dec 2015 23:00:21 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.9/8.14.9/Submit) id tBBF0Kar044376; Fri, 11 Dec 2015 23:00:20 +0800 (CST) (envelope-from kevlo) Date: Fri, 11 Dec 2015 23:00:19 +0800 From: Kevin Lo To: =?utf-8?B?0KHQtdGA0LPQtdC5INCn0LLQtdGA0YLQvdGP0Lo=?= Cc: freebsd-arm@freebsd.org Subject: Re: support Allwinner H3 Message-ID: <20151211150019.GA44341@ns.kevlo.org> References: <1449784832.417138.27650.30415@mail.rambler.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1449784832.417138.27650.30415@mail.rambler.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 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 Dec 2015 15:00:41 -0000 On Fri, Dec 11, 2015 at 01:00:32AM +0300, Сергей Чвертняк wrote: > > Please help. > I do not understand how to create a boot exactly for Allwinner H3 (board OrangePi > PC). > There are practices in support of processors Allwinner H3? Thanks to Ganbold who added support for Allwinner A10/A20 SoCs, porting to H3 is straightforward. I have a preliminary patch for this, but I don't want to continue working on it. It seems there's a hardware issue with Orange Pi PC [1]. I had a similar issue with my Orange Pi PC when I used the images from Orange Pi download [2], it turned out that only Lubuntu image worked. [1] http://www.cnx-software.com/2015/10/02/orange-pi-pc-not-booting-you-are-not-alone/ [2] http://www.orangepi.org/downloadresources/ > Thanks! > > Best regards, Sergey! Kevin