From owner-freebsd-arm@freebsd.org Sun Sep 6 00:56: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 38ED59CB1EC for ; Sun, 6 Sep 2015 00:56:34 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE7E21C35 for ; Sun, 6 Sep 2015 00:56:33 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id t860v2VW027263 for freebsd-arm@freebsd.org; Sun, 6 Sep 2015 00:57:02 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.108] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id p7dgu8nk4kb8m9q5rt7a4vw9jn; for freebsd-arm@freebsd.org; Sun, 06 Sep 2015 00:57:02 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: keeping up-to-date on RPi2/FreeBSD11 From: Tim Kientzle In-Reply-To: <20150905234829.GA6572@potato.growveg.org> Date: Sat, 5 Sep 2015 17:56:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1DCEFAC1-E185-4E4B-B407-7C465079B62B@kientzle.com> References: <20150905125316.GB80713@potato.growveg.org> <20150905133519.c60e316b90b3205a5d482c01@ulrich-grey.de> <55EB46D2.1040003@blarg.com> <20150905234829.GA6572@potato.growveg.org> To: freebsd-arm X-Mailer: Apple Mail (2.2104) 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 Sep 2015 00:56:34 -0000 > On Sep 5, 2015, at 4:48 PM, John = wrote: >=20 > On Sat, Sep 05, 2015 at 12:47:30PM -0700, kah42pub wrote: >=20 >> For what it is worth, these steps work for me to update an RPI2 in >> place. A serial cable is definitely required. Most of this was taken >> from the FreeBSD documentation. I've omitted steps that are specific = to >> my configuration. >=20 > [snip - thanks for the info btw] >=20 >> This process recently took me up to 11.0-CURRENT r287441 without a >> hiccup on the RPI2. Hope it helps. If anyone sees anything obvious = that >> I didn't do that I should have for the upgrade process, feel free to >> speak up. >=20 > Will your method work for an image made by crotchet - ie will it boot > the right kernel, does it update what crotchet installed? The original > install was = http://download.raspbsd.org/FreeBSD-armv6-11.0-RPI2-286947.img.gz Yes, it will work. The reason there's not a lot of documentation about upgrading = FreeBSD-arm in-place is simply that it's exactly the same as i386 or = amd64. All the existing documentation applies exactly. There are a few minor bits of trivia: * It takes a while: allow 15 hours on an RPI2, 40 hours on a BeagleBone = Black. * Crochet normally sets the KERNCONF in /etc/sys.mk so you should not = need to set it manually. * If you want to tweak the kernel configuration, it's in the usual = place: /usr/src/sys//conf/ * 1GB RAM is not enough for buildworld, so you'll need to configure swap = space. I normally aim for ram + swap >=3D 1.5GB, so at least 512MB on = an RPI2. * You also need to make sure you have enough disk space: I think I've = successfully done a full buildworld with an 8GB SD card. 16GB is ample. >=20 >> Also, powerd definitely works on RPI2. Having it enabled (allowing >> stepped up CPU speeds under load) decreases the build world time by >> hours - at least for me. Your mileage may vary. >=20 > yep, I have powerd enabled now rather than setting turbo in=20 > /etc/sysctl.conf. I also have powerd_flags=3D"-a hiadaptive" though am > unsure if these flags have any effect on this arch. >=20 > thanks, > --=20 > John=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 Sep 6 03:54:26 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 A78F69C5702 for ; Sun, 6 Sep 2015 03:54:26 +0000 (UTC) (envelope-from kah42pub@blarg.com) Received: from mail.avvanta.com (smtp61.avvanta.com [206.124.128.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A50A2D2 for ; Sun, 6 Sep 2015 03:54:25 +0000 (UTC) (envelope-from kah42pub@blarg.com) Received: from mail.avvanta.com (localhost.drteeth.p.blarg.net [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id E25ABF3937 for ; Sat, 5 Sep 2015 20:53:20 -0700 (PDT) Received: from MBP16GB.local (c-50-135-203-40.hsd1.wa.comcast.net [50.135.203.40]) by mail.avvanta.com (Postfix) with ESMTP id C717AF3935 for ; Sat, 5 Sep 2015 20:53:20 -0700 (PDT) Subject: Re: keeping up-to-date on RPi2/FreeBSD11 To: freebsd-arm@freebsd.org References: <20150905125316.GB80713@potato.growveg.org> <20150905133519.c60e316b90b3205a5d482c01@ulrich-grey.de> <55EB46D2.1040003@blarg.com> <20150905234829.GA6572@potato.growveg.org> <1DCEFAC1-E185-4E4B-B407-7C465079B62B@kientzle.com> From: kah42pub Message-ID: <55EBB8F0.6080300@blarg.com> Date: Sat, 5 Sep 2015 20:54:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1DCEFAC1-E185-4E4B-B407-7C465079B62B@kientzle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.drteeth.p.blarg.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: Sun, 06 Sep 2015 03:54:26 -0000 On 9/5/15 17:56, Tim Kientzle wrote: > >> On Sep 5, 2015, at 4:48 PM, John wrote: >> >> On Sat, Sep 05, 2015 at 12:47:30PM -0700, kah42pub wrote: >> >>> For what it is worth, these steps work for me to update an RPI2 in >>> place. A serial cable is definitely required. Most of this was taken >>> from the FreeBSD documentation. I've omitted steps that are specific to >>> my configuration. >> >> [snip - thanks for the info btw] >> >>> This process recently took me up to 11.0-CURRENT r287441 without a >>> hiccup on the RPI2. Hope it helps. If anyone sees anything obvious that >>> I didn't do that I should have for the upgrade process, feel free to >>> speak up. >> >> Will your method work for an image made by crotchet - ie will it boot >> the right kernel, does it update what crotchet installed? The original >> install was http://download.raspbsd.org/FreeBSD-armv6-11.0-RPI2-286947.img.gz > > Yes, it will work. > > The reason there's not a lot of documentation about upgrading FreeBSD-arm in-place is simply that it's exactly the same as i386 or amd64. All the existing documentation applies exactly. > > There are a few minor bits of trivia: > > * It takes a while: allow 15 hours on an RPI2, 40 hours on a BeagleBone Black. > > * Crochet normally sets the KERNCONF in /etc/sys.mk so you should not need to set it manually. > > * If you want to tweak the kernel configuration, it's in the usual place: /usr/src/sys//conf/ > > * 1GB RAM is not enough for buildworld, so you'll need to configure swap space. I normally aim for ram + swap >= 1.5GB, so at least 512MB on an RPI2. > > * You also need to make sure you have enough disk space: I think I've successfully done a full buildworld with an 8GB SD card. 16GB is ample. > > >> >>> Also, powerd definitely works on RPI2. Having it enabled (allowing >>> stepped up CPU speeds under load) decreases the build world time by >>> hours - at least for me. Your mileage may vary. >> >> yep, I have powerd enabled now rather than setting turbo in >> /etc/sysctl.conf. I also have powerd_flags="-a hiadaptive" though am >> unsure if these flags have any effect on this arch. >> >> thanks, >> -- >> John >> _______________________________________________ >> 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" > > _______________________________________________ > 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" > > My starting image was from a crochet build so that definitely works. On the RPI2, I have 4GB allocated to /usr/src and that is more than enough to build. I have lots of swap swap space allocated (2GB, I think) but that is never touched during the buildworld phase. Again, your mileage may vary. Kris From owner-freebsd-arm@freebsd.org Sun Sep 6 13:48: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 C260B9CC406 for ; Sun, 6 Sep 2015 13:48:12 +0000 (UTC) (envelope-from chane@carrollsweb.com) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1.freebsd.org (Postfix) with ESMTP id B1A72A59 for ; Sun, 6 Sep 2015 13:48:12 +0000 (UTC) (envelope-from chane@carrollsweb.com) Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id D845E14E0F57 for ; Sun, 6 Sep 2015 06:44:34 -0700 (PDT) Date: Sun, 6 Sep 2015 06:48:12 -0700 (MST) From: DrObscure To: freebsd-arm@freebsd.org Message-ID: <1441547292619-6037518.post@n5.nabble.com> In-Reply-To: <1797C633-CD84-4CCA-984A-83C70418FD1A@netgate.com> References: <201508102037.OAA16743@mail.lariat.net> <1797C633-CD84-4CCA-984A-83C70418FD1A@netgate.com> Subject: Re: FreeBSD 10.2 and embedded ARM boards? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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 Sep 2015 13:48:12 -0000 Just down loaded the 9/4/2015 10.2 STABLE binary image, and am having issues getting it to come up properly. near the beginning of the run I get the message: ** Unable to read file uEnv.txt ** then the autoboot sequnce U-Boot (rev 1.2) starts up and we get - DRAM: 480MB Number of U-boot devices: 1 loaderdev='mmc 0' then, mmc fail to send stop cmd disk0: real size != size (repeated several times) can't load kernel Type '?'.. etc.. loader> -------------------------- 0f course the USB keyboard does not function here, so this ends the run.. The image is being loaded using Win32DiskImager in Win8.0.. Any help would be appreciated.. -- View this message in context: http://freebsd.1045724.n5.nabble.com/FreeBSD-10-2-and-embedded-ARM-boards-tp6031761p6037518.html Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@freebsd.org Sun Sep 6 17:59: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 19E389CBFE8 for ; Sun, 6 Sep 2015 17:59:45 +0000 (UTC) (envelope-from mmitchel@gmail.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 CA1F122B for ; Sun, 6 Sep 2015 17:59:44 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: by qgev79 with SMTP id v79so49746290qge.0 for ; Sun, 06 Sep 2015 10:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8B3A6Zp2+hOBWWiOqzpfb3T7BPEEdlnXPMhfXVrIU9w=; b=ZrBw0x8uqFYX4l9CBOzqpvD3EzgCO/o+/gFNiGoBr6sSgI8kLX+nCSVQBNwLDjDcrB La6Hap0aPQz8PK6rrn0L8aRS1h9x1a6eASpHPvGhBiTBWLKIMVfTS/pgP6d/+9vQTxWF /CP2yOoRMg35jSviNryB/gHHnI0ZcaCDOAdHEx65OCKzCPC7e+e2H4O/PGYbynD0ZrRc 4/FtJ2Jd9Pi5trGsSCQU8Wu93RboMKpU9qhghyg332ojf1O2r4I5+1t2NzQWX2gnzAq7 HmjXzHSIGrjchfVmo3fo/OeuvqrFBQpbX/bTeSe01bh1JmOuhesQVgM/KsCExt8tpZW1 IfoA== MIME-Version: 1.0 X-Received: by 10.140.93.53 with SMTP id c50mr21081533qge.59.1441562383355; Sun, 06 Sep 2015 10:59:43 -0700 (PDT) Received: by 10.55.165.131 with HTTP; Sun, 6 Sep 2015 10:59:43 -0700 (PDT) In-Reply-To: <1441547292619-6037518.post@n5.nabble.com> References: <201508102037.OAA16743@mail.lariat.net> <1797C633-CD84-4CCA-984A-83C70418FD1A@netgate.com> <1441547292619-6037518.post@n5.nabble.com> Date: Sun, 6 Sep 2015 10:59:43 -0700 Message-ID: Subject: Re: FreeBSD 10.2 and embedded ARM boards? From: Michael Mitchell To: DrObscure 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: Sun, 06 Sep 2015 17:59:45 -0000 try a different SD card is the first troubleshoot technique. On Sun, Sep 6, 2015 at 6:48 AM, DrObscure wrote: > Just down loaded the 9/4/2015 10.2 STABLE binary image, and am having > issues > getting it to come up properly. > > near the beginning of the run I get the message: > ** Unable to read file uEnv.txt ** > then the autoboot sequnce > U-Boot (rev 1.2) starts up and we get - > DRAM: 480MB > Number of U-boot devices: 1 > loaderdev='mmc 0' > then, > mmc fail to send stop cmd > disk0: real size != size (repeated several times) > can't load kernel > > Type '?'.. etc.. > loader> > -------------------------- > 0f course the USB keyboard does not function here, so this ends the run.. > > The image is being loaded using Win32DiskImager in Win8.0.. > > Any help would be appreciated.. > > > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/FreeBSD-10-2-and-embedded-ARM-boards-tp6031761p6037518.html > Sent from the freebsd-arm mailing list archive at Nabble.com. > _______________________________________________ > 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 Sep 6 21:33: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 836B69C5A29 for ; Sun, 6 Sep 2015 21:33:34 +0000 (UTC) (envelope-from chane@carrollsweb.com) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1.freebsd.org (Postfix) with ESMTP id 688E11FF1 for ; Sun, 6 Sep 2015 21:33:33 +0000 (UTC) (envelope-from chane@carrollsweb.com) Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id 3446A14E59E3 for ; Sun, 6 Sep 2015 14:29:53 -0700 (PDT) Date: Sun, 6 Sep 2015 14:33:33 -0700 (MST) From: DrObscure To: freebsd-arm@freebsd.org Message-ID: <1441575213223-6037591.post@n5.nabble.com> In-Reply-To: References: <201508102037.OAA16743@mail.lariat.net> <1797C633-CD84-4CCA-984A-83C70418FD1A@netgate.com> <1441547292619-6037518.post@n5.nabble.com> Subject: Re: FreeBSD 10.2 and embedded ARM boards? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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 Sep 2015 21:33:34 -0000 Hi.. and thanks for the reminder.. :) I was using the card successfully for Raspian with no complaints, so made the (obviously bad) assumption that the card was Ok.. however, it did fail for FreeBSD.. At your prompt, I grabbed the original SanDisk SD card that came with the RasPI and overwrote it.. and ubldr is happy and the kernel does boot as advertised.... Just a reminder as to how finicky these cards can be, and that just because it works for one OS, is no guarantee of a good card :) -- View this message in context: http://freebsd.1045724.n5.nabble.com/FreeBSD-10-2-and-embedded-ARM-boards-tp6031761p6037591.html Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@freebsd.org Mon Sep 7 06:39:23 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 80DCD9CB9A3 for ; Mon, 7 Sep 2015 06:39:23 +0000 (UTC) (envelope-from mgamsjager@gmail.com) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 522F71F5 for ; Mon, 7 Sep 2015 06:39:23 +0000 (UTC) (envelope-from mgamsjager@gmail.com) Received: by igcrk20 with SMTP id rk20so47996829igc.1 for ; Sun, 06 Sep 2015 23:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Ulvg8+mg6ZpKTnmkKdcwQkbkt41cCFKih6NnbNQZBLM=; b=Uq1GUpROuYhSzYfVucMQEKSSRdvuINtpzEPSj/Zpb8vO3d0N0tjBltRJR7zKSioOV1 gLOpAXL8Bm85NvD2unZYUdtRyuJn+9Fi2Nx3JE/3ceUozBCMbt3nNQLQz+wpRExr8tBF 6UIBHPPjXLbotaFVO9o4+Ul/2AhjhhfWmtjbtGiCWa4ZbSsymFSESZnlpi08GG2rm9D6 4+zr095EB7U8VTm3nQ7Rdnlc54iyrcpLyA5sfsPOAnafpwrXlcf3yEMPt1NAncEFGmq1 fdWNzK7IqIMQGrzNW1IqXj8G4dnx87Dg51FpxA14AUpSOlVmbJx6cSfQ/WH4R2LxF+xN iLFQ== X-Received: by 10.50.127.177 with SMTP id nh17mr17687348igb.40.1441607962706; Sun, 06 Sep 2015 23:39:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.27.161 with HTTP; Sun, 6 Sep 2015 23:38:53 -0700 (PDT) From: Matthias Gamsjager Date: Mon, 7 Sep 2015 08:38:53 +0200 Message-ID: Subject: ARM pkg repo To: "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 Sep 2015 06:39:23 -0000 Hallo, where can I find the status of the official pkgng ARM repo? The only repos I could find are private ones. - Matthias From owner-freebsd-arm@freebsd.org Mon Sep 7 09:05:55 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 A244F9CB05F for ; Mon, 7 Sep 2015 09:05:55 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 6AAAF1A0C for ; Mon, 7 Sep 2015 09:05:55 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZYsMv-000M5X-JY for freebsd-arm@freebsd.org; Mon, 07 Sep 2015 10:05:41 +0100 Date: Mon, 7 Sep 2015 10:05:41 +0100 From: John To: freebsd-arm@freebsd.org Subject: bhyve/arm6/amd64 query Message-ID: <20150907090541.GA54788@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false 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 Sep 2015 09:05:55 -0000 Hello list, Can an arm6 image guest run on a bhyve amd64 host? thanks, -- John From owner-freebsd-arm@freebsd.org Mon Sep 7 12:33:30 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 257009CCB60 for ; Mon, 7 Sep 2015 12:33:30 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 A9CEF1BA8 for ; Mon, 7 Sep 2015 12:33:29 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by lbcjc2 with SMTP id jc2so38516015lbc.0 for ; Mon, 07 Sep 2015 05:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=yTkL/ADFXc0EMDSffq5CLFEjrC5U4ZUAyPbHkZN3wbY=; b=rg7PFEPFThiuUbTh1i2KZbC8NVA5+nNChHTpNxP8opUfUxD1TA/GlewzYumaqHN8uT sDK6xiAyQR/RV9LflXu9/0uQq16/LswqOYkf9/ZSMQCSI6cRv83N/OrhBjfhF6LNJxMZ SxVxItFl8zLUNI0TXWqJt6R5mqY/kAs+ZWFpWfuLithiJ1X3Ir3ZpDYlYvfoh5oFOgK9 zbg/2fShfct2849gPFApXT1B0Hc9b11hpyDvy6MC6vP7JCk/DH3hA5CQxF5fAEHj12Au a7GEDgUHNsxm6O1IAObL5AHNnqXRybREfDH0yJhqRoNZlqyTuZ56z00bG+MRoJd5qVJg XGmA== X-Received: by 10.152.8.233 with SMTP id u9mr17006642laa.8.1441629205972; Mon, 07 Sep 2015 05:33:25 -0700 (PDT) Received: from [192.168.1.193] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by smtp.gmail.com with ESMTPSA id q5sm3065892laj.6.2015.09.07.05.33.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Sep 2015 05:33:25 -0700 (PDT) From: Jukka Ukkonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: bhyve/arm6/amd64 query Message-Id: <59F1B4A5-CD93-46D2-83D3-F0790CA2FA8E@gmail.com> Date: Mon, 7 Sep 2015 15:33:24 +0300 References: <20150907090541.GA54788@potato.growveg.org> In-Reply-To: <20150907090541.GA54788@potato.growveg.org> To: "freebsd-arm@freebsd.org" X-Mailer: iPad Mail (12H321) 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 Sep 2015 12:33:30 -0000 AFAIK no. Bhyve is a plain hardware type of container, not a hardware emulator like qemu, nor a jail type container. You should be looking for qemu or something similar. Bhyve can be used for hosting other operating systems on the same type of HW as the vanilla system. --jau Sent from my iPad > On 07 Sep 2015, at 12:05, John wrote: > > Hello list, > > Can an arm6 image guest run on a bhyve amd64 host? > > thanks, > -- > John > _______________________________________________ > 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 Sep 7 15:05:43 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 6B1B89CC84E for ; Mon, 7 Sep 2015 15:05:43 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 2E76E1228 for ; Mon, 7 Sep 2015 15:05:42 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZYxzH-0000qn-QD for freebsd-arm@freebsd.org; Mon, 07 Sep 2015 16:05:39 +0100 Date: Mon, 7 Sep 2015 16:05:39 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: bhyve/arm6/amd64 query Message-ID: <20150907150539.GA2959@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150907090541.GA54788@potato.growveg.org> <59F1B4A5-CD93-46D2-83D3-F0790CA2FA8E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59F1B4A5-CD93-46D2-83D3-F0790CA2FA8E@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false 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 Sep 2015 15:05:43 -0000 On Mon, Sep 07, 2015 at 03:33:24PM +0300, Jukka Ukkonen wrote: > AFAIK no. Bhyve is a plain hardware type of container, > not a hardware emulator like qemu, nor a jail type > container. > You should be looking for qemu or something similar. > Bhyve can be used for hosting other operating systems > on the same type of HW as the vanilla system. OK, thanks. You've saved me the work of trying then failing terribly :D It doesn't have to be hosted. The reason for me asking is, basically can I take the image and (as an image, not as an OS) can it be updated/recompiled on different, higher spec hardware, then returned to the Pi? Hopefully I'm describing this right. You know on say amd64, an arm6 system can be cross-compiled as an installable system. That system is running. I have updated it (while installed on RPI2 hardware) and installed my configs, it works great. Now I can unplug the microSD, dd it to a .img file, on another system, to archive it. What I'm asking is, can I take that image while it's on the other system, and interact with it to the extent that I can update/upgrade it? *the other system is also freebsd11, but amd64* thanks, -- John From owner-freebsd-arm@freebsd.org Mon Sep 7 15:12:35 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 B38159CCC10 for ; Mon, 7 Sep 2015 15:12:35 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (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 7764818FA for ; Mon, 7 Sep 2015 15:12:35 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: by qgx61 with SMTP id 61so63824357qgx.3 for ; Mon, 07 Sep 2015 08:12:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=PwgriqvJup87Sfw7Ku4KiTvvSU1fMXeQmFHbFm82WnU=; b=XCg4IGhDeUW7ufItUhvsUVbBXC8Q27dSLzIbifMPRPN5LDo0B6YFSAQV9I/yk1LvWj 3shyefuetkEvq489eQ9o64O8q48krBgPtI2YAB8rNE1aby18FYTNZWcTOZyv9utMa/JH fOFPacbyDRgVzHUZqjgIdNHw+igQjrSevTLcUrgeljN53dR6RxyXh2QrhZ96WXF+hWFJ 3cOwFsnmjxEkPiYbwHK0I2nBAE/q5OlTyeZD45pG4W97BxX5eDF8NC94IQ0WX0quxw67 3v5u/ibPV8mGcZKctneemiVJ4fO0otmnXJRNkE0ekFCwk5Uh2NMr5YPJnGFc21cppR0E esxA== X-Gm-Message-State: ALoCoQlD4yx8P0KM/irPicN80281j64U5ufnnEpUEw3dIKXLSx2Y2UwXbUeXi4rzzB/eKJcWf2ZB X-Received: by 10.140.238.85 with SMTP id j82mr29580897qhc.9.1441638748231; Mon, 07 Sep 2015 08:12:28 -0700 (PDT) Received: from [172.26.26.1] ([192.154.157.52]) by smtp.googlemail.com with ESMTPSA id s90sm18853qki.46.2015.09.07.08.12.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Sep 2015 08:12:27 -0700 (PDT) Subject: Re: ARM pkg repo To: freebsd-arm@freebsd.org References: From: Peter Garshtja Message-ID: <55EDA95C.9010900@ambient-md.com> Date: Mon, 7 Sep 2015 11:12:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed 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: Mon, 07 Sep 2015 15:12:35 -0000 hi, At the moment the freebsd foundation is working to create the official arm repository. i don't the ETA. you can build yours on x86 machine, check qemu and poudriere. thx, peter On 9/7/2015 2:38 AM, Matthias Gamsjager wrote: > Hallo, > > where can I find the status of the official pkgng ARM repo? The only > repos I could find are private ones. > > > > - > Matthias > _______________________________________________ > 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 Sep 7 16:04:32 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 8AA459CCDBF for ; Mon, 7 Sep 2015 16:04:32 +0000 (UTC) (envelope-from cleber@bsd.com.br) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 4AF6C1189 for ; Mon, 7 Sep 2015 16:04:31 +0000 (UTC) (envelope-from cleber@bsd.com.br) Received: by qgx61 with SMTP id 61so64657764qgx.3 for ; Mon, 07 Sep 2015 09:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=2lpTg8pg92FlPR8IEjTKDT59g14NhcmEhcprEJnSUwQ=; b=dh/iZjRNAvlma7ksPe0osRmmqyqlsQL44RVPqlTtjnqe6PHikHTNMmgxRijfWD916Z rponlgf6nVVBmGfJAt68EiTNpqJQT8RraimTt+/MFi0Gr9HYA4/QTHkS5wk1Clc0eTUn S+qATqWXcZ6H/QkYB91duEdrvICykdZ3Bbvd0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2lpTg8pg92FlPR8IEjTKDT59g14NhcmEhcprEJnSUwQ=; b=OLpvTu48JqVrGVQHyYgT5P3/SaMEvtcI82JxQ21v115NEm2EkFpt6TttYGcLA+UhD6 MVPSsGXBfyAYWJrV322tyIkq6U8/H/2KYi3zNfok7HAxCyE6k4wVAz/N7MYcDCRGssl5 qZiyB1CaihMLmufZsckLstdx5UzUw+0d2K73uNGhP904Y+CcoZNVFLPKlLx5s6h+SIqX 2X5SSBc6v2PfJZbPingd3IQfqT8jsmE/oNbYAJflh5YdeL8S6VACTRafim3H5A0IcvNp XS/fS9u207mJfWzVyIPL93VmgfkhFZCgn9DHWtLc+2PuoCttkUVLuR8wNb8+D28s458g YzyQ== X-Gm-Message-State: ALoCoQn5BY640ayOAQfVvz5wP7qBgmqkCiwI+SIwSj6pH8J2KfkPFOSEI/xvihGMnY7RJyjFIt4/ MIME-Version: 1.0 X-Received: by 10.140.19.227 with SMTP id 90mr27405948qgh.51.1441641871013; Mon, 07 Sep 2015 09:04:31 -0700 (PDT) Received: by 10.55.89.199 with HTTP; Mon, 7 Sep 2015 09:04:30 -0700 (PDT) In-Reply-To: <20150907150539.GA2959@potato.growveg.org> References: <20150907090541.GA54788@potato.growveg.org> <59F1B4A5-CD93-46D2-83D3-F0790CA2FA8E@gmail.com> <20150907150539.GA2959@potato.growveg.org> Date: Mon, 7 Sep 2015 13:04:30 -0300 Message-ID: Subject: Re: bhyve/arm6/amd64 query From: "Cleber A. Nascimento" To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.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 Sep 2015 16:04:32 -0000 2015-09-07 12:05 GMT-03:00 John : > On Mon, Sep 07, 2015 at 03:33:24PM +0300, Jukka Ukkonen wrote: > > AFAIK no. Bhyve is a plain hardware type of container, > > not a hardware emulator like qemu, nor a jail type > > container. > > You should be looking for qemu or something similar. > > Bhyve can be used for hosting other operating systems > > on the same type of HW as the vanilla system. > > OK, thanks. You've saved me the work of trying then failing terribly :D > > It doesn't have to be hosted. The reason for me asking is, basically can = I > take > the image and (as an image, not as an OS) can it be updated/recompiled on > different, > higher spec hardware, then returned to the Pi? > > Hopefully I'm describing this right. You know on say amd64, an arm6 syste= m > can be > cross-compiled as an installable system. That system is running. I have > updated it > (while installed on RPI2 hardware) and installed my configs, it works > great. > Now I can unplug the microSD, dd it to a .img file, on another system, to > archive it. > What I'm asking is, can I take that image while it's on the other system, > and > interact with it to the extent that I can update/upgrade it? > > *the other system is also freebsd11, but amd64* > > thanks, > -- > John > _______________________________________________ > 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" > Think about Crochet, maybe this tool is you looking for. And about packages I have some success with Poudriere. Regards, --=20 Cleber Alves .=C4=B1l=C4=B1..=C4=B1l=C4=B1. "Observe as estrelas e aprenda com elas." Albert Einstein From owner-freebsd-arm@freebsd.org Mon Sep 7 18:15: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 0221F9CC83F for ; Mon, 7 Sep 2015 18:15:12 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3D571E0D for ; Mon, 7 Sep 2015 18:15:11 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id t87IFY3S034281 for freebsd-arm@freebsd.org; Mon, 7 Sep 2015 18:15:34 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.108] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id u2b65tkywyhhmtc9qqij4p2gbe; for freebsd-arm@freebsd.org; Mon, 07 Sep 2015 18:15:34 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: bhyve/arm6/amd64 query From: Tim Kientzle In-Reply-To: <20150907150539.GA2959@potato.growveg.org> Date: Mon, 7 Sep 2015 11:15:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <023E3382-6F0A-4EDA-9D9A-E0F60AB58FA6@kientzle.com> References: <20150907090541.GA54788@potato.growveg.org> <59F1B4A5-CD93-46D2-83D3-F0790CA2FA8E@gmail.com> <20150907150539.GA2959@potato.growveg.org> To: freebsd-arm X-Mailer: Apple Mail (2.2104) 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 Sep 2015 18:15:12 -0000 > On Sep 7, 2015, at 8:05 AM, John = wrote: >=20 > On Mon, Sep 07, 2015 at 03:33:24PM +0300, Jukka Ukkonen wrote: >> AFAIK no. Bhyve is a plain hardware type of container, >> not a hardware emulator like qemu, nor a jail type >> container. >> You should be looking for qemu or something similar. >> Bhyve can be used for hosting other operating systems >> on the same type of HW as the vanilla system. >=20 > OK, thanks. You've saved me the work of trying then failing terribly = :D >=20 > It doesn't have to be hosted. The reason for me asking is, basically = can I take > the image and (as an image, not as an OS) can it be updated/recompiled = on different, > higher spec hardware, then returned to the Pi? >=20 > Hopefully I'm describing this right. You know on say amd64, an arm6 = system can be > cross-compiled as an installable system. That system is running. I = have updated it > (while installed on RPI2 hardware) and installed my configs, it works = great.=20 > Now I can unplug the microSD, dd it to a .img file, on another system, = to archive it.=20 > What I'm asking is, can I take that image while it's on the other = system, and=20 > interact with it to the extent that I can update/upgrade it? In theory, yes. If you could figure this out there are lots of people = who might be interested in it. The basic idea: cross-compile a new FreeBSD system, mount the arm6 = image and then cross-install onto it to update it. This is very similar = to the process Crochet uses for building a new image, except that = instead of starting with a new blank system image you would instead = mount your existing image and install over it. Roughly speaking, the process should be something like the following = (you'll need to do some research to fill in the many details): $ cd /usr/src $ make TARGET_ARCH=3Darm6 buildworld $ make TARGET_ARCH=3Darm6 KERNCONF=3DRPI2 buildkernel $ # ... mount the img via md loopback $ mergemaster $ make TARGET_ARCH=3Darm6 KERNCONF=3DRPI2 DESTDIR=3D = installkernel $ make TARGET_ARCH=3Darm6 KERNCONF=3DRPI2 DESTDIR=3D installworld $ # ... unmount the image From owner-freebsd-arm@freebsd.org Mon Sep 7 20:04:28 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 60BC59CDFA5 for ; Mon, 7 Sep 2015 20:04:28 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (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 21EC71999 for ; Mon, 7 Sep 2015 20:04:27 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by qgev79 with SMTP id v79so67888410qge.0 for ; Mon, 07 Sep 2015 13:04:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:organization :user-agent:mime-version:content-type; bh=ImRXliV5BmmBP8SdjBcGb+v67nudViv+TdoPAREnbrY=; b=IMxMgVbP/I94TvrBKqVV0HWKNNXnJQqM/9NlSKIFo2RFSagt1jnrbNWlqfeWi3wg2z RliDR+WzLTqlhg6Td1ONMEklkvLRJPmZ2V2ISnMD28cSPjdPKuoqC2s5LBt1uAWfthae x+0dJguJiXcvQh3yD15XStNVZxnBTUOEEbyo+pMct4an8jDIPMPTbmCCq4kEaEuYj2YB bIZj4dDPak7LfB+Y0ia67Z9Or29E2oKGDMSNhBATNCSrf1rtApzNEwsdJusmMvRIUSoy Khog8PhvUfC1hF4ytsM+Y4UXcnGq3d1+ut5bQBkZ9z88cdcz71TaA802lOKJFPKtH3vU ra0g== X-Gm-Message-State: ALoCoQnzgEMDmJvhg7ZAUIwpU3RasBzHnkBe67vFbDRjpY5Jndl5cuolvanZ8QNOQ0n+FnaILc7u3KZgu6NmemDUEC7zuJLVzocO2pYsvUCmauKkZWxrNP/FQ23dg6ol7ezMe63EhqzMDFHDheoRC4duVjzTKelGeKJAEUZKnpPdh/9qrqvzsM4NVh8fEldsz8wr7Wj7FA+v X-Received: by 10.140.98.118 with SMTP id n109mr29320860qge.17.1441655875647; Mon, 07 Sep 2015 12:57:55 -0700 (PDT) Received: from hbsd-dev-laptop.localnet ([63.88.83.104]) by smtp.gmail.com with ESMTPSA id n10sm446006qki.24.2015.09.07.12.57.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Sep 2015 12:57:55 -0700 (PDT) From: Shawn Webb To: "'freebsd-arm@freebsd.org'" Subject: qemu arm64 and networking Date: Mon, 07 Sep 2015 15:57:49 -0400 Message-ID: <3738181.x17CtYilQJ@hbsd-dev-laptop> Organization: HardenedBSD User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT-HBSD; KDE/4.14.3; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6892980.tC4GsSajSD"; micalg="pgp-sha256"; protocol="application/pgp-signature" 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 Sep 2015 20:04:28 -0000 --nextPart6892980.tC4GsSajSD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hey All, Quite a bit of a newbie question, but I'm having troubles getting netwo= rking=20 to work in the qemu arm64 image. I'm following the instructions on the=20= snapshots mailing list: https://lists.freebsd.org/pipermail/freebsd-snapshots/2015-September/00= 0169.html Yet I can't get anything outbound or inbound. 100% packet loss. Has any= one=20 else had this issue? What are some things I can do to debug this and ge= t it=20 working? Everything I've tried doesn't seem to work. Thanks, =2D-=20 Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --nextPart6892980.tC4GsSajSD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV7ew9AAoJEGqEZY9SRW7u4TIP/1yzXgq1eqvUl5DhMy8b+/v1 safTFiTj4XWhT7LOUYrUtFdTNq+0eg5d9rBAMUTqiJOUqgbxEcqHlabBwzFIdK+U javlutrGal054bsSHmnP7fnYEMcxTkxHnlsDIuq62azNX6QU9rBJHrxfalRHH1KJ upb35v7+unvasosFrb1lARAaWvFGA4WVXi6pFQDT5+uQgAUSOyLuTVcnbNJixt5z CrtRzpsFYeW9s3ZKttWRg6W+ZE9ZesgT/QwhMOuK+B8u115ndSH1io7ZDJQoufQ6 uHVU+ZVVYvU4ZB1RWdRasWOzONkDU/kAs0AHM+NGFvnQfrJY9MJ8QAjW2CZin+lq m7oLF+aGMiqVAaVr/+ysWFcs9RX7+pRFRySXTq2IXqVdhqzYIQ+qs4OaI11HEnex UgR9uVf/BjIl0eKHYd/HIa+SEB/HIr+eyjCI8z4zq8ZRY4gdVx3eNa43p7GDwn7g 9d3dcLVFRmt/w4taHGozi9HdVx7KKY8TTfZ3EDNgj3NG95eUsGy3rM/JqzxsuJ4h DTeEz/4STFjtSQ8okRMxCORXCxG/byyWFtXJYJRdR6LYxhT8aTg2Fw8sx1N0mGxP PiIE4ZrBXq97bCE2wYkvwqZwUjVsn3V0tkHjm1gNQ6pcyi3oftCQXQzSOs78UGcu +ukjTRhybTEoBpuy8RRB =h5OB -----END PGP SIGNATURE----- --nextPart6892980.tC4GsSajSD-- From owner-freebsd-arm@freebsd.org Mon Sep 7 22:19:55 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 7A5FB9CC33B for ; Mon, 7 Sep 2015 22:19:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (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 332E019F3 for ; Mon, 7 Sep 2015 22:19:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgev79 with SMTP id v79so69561294qge.0 for ; Mon, 07 Sep 2015 15:19:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JWmzcQYrCgCLBgpuKDN6R/UVBECpo4c9GCbpyJBayC4=; b=iTQkutpxWTzVObd7258aKkLN0mWKlQKFlxwTNIa4V0hy+CWFO7B+NoR+ULCEHKNBfr MfOvYf4uA7RDeQGRtGLmxTgZxryX6QkHz51JAsKzenh6cnji/eEevm/+WRyFtSh2xW1w 4GraipMkHn5AhEvTlSpbCa6vN3vbKoqVcCKzIj8bAqt7TokeD4PGLr7kkU3yoP/nVu8w EdAeqp577SEBV2svy4iZTYRm3JWj3N+skbQV1uohk+R+rWa7Opn3vppU7JE2fSHd8TMZ /E6jkX/rExqqdX1mvFHyJK0XC99ktpqa2RBWPDexqmRMesgeow8NMNL9CGb3Xc4UXzd6 6OLQ== X-Gm-Message-State: ALoCoQneZ5jwva4xryyXK2U460dPZCxVq0D1Ytzvf4EcU01OGxW1GgyZsufQZr7Jsm3dCz2kbO+U MIME-Version: 1.0 X-Received: by 10.140.164.7 with SMTP id k7mr31931758qhk.40.1441664388349; Mon, 07 Sep 2015 15:19:48 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.164 with HTTP; Mon, 7 Sep 2015 15:19:48 -0700 (PDT) X-Originating-IP: [69.53.245.5] In-Reply-To: <023E3382-6F0A-4EDA-9D9A-E0F60AB58FA6@kientzle.com> References: <20150907090541.GA54788@potato.growveg.org> <59F1B4A5-CD93-46D2-83D3-F0790CA2FA8E@gmail.com> <20150907150539.GA2959@potato.growveg.org> <023E3382-6F0A-4EDA-9D9A-E0F60AB58FA6@kientzle.com> Date: Mon, 7 Sep 2015 16:19:48 -0600 X-Google-Sender-Auth: oVnR2LzF0t9khqjzw5SLx90ajj4 Message-ID: Subject: Re: bhyve/arm6/amd64 query From: Warner Losh To: Tim Kientzle Cc: freebsd-arm 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: Mon, 07 Sep 2015 22:19:55 -0000 On Mon, Sep 7, 2015 at 12:15 PM, Tim Kientzle wrote: > > > On Sep 7, 2015, at 8:05 AM, John > wrote: > > > > On Mon, Sep 07, 2015 at 03:33:24PM +0300, Jukka Ukkonen wrote: > >> AFAIK no. Bhyve is a plain hardware type of container, > >> not a hardware emulator like qemu, nor a jail type > >> container. > >> You should be looking for qemu or something similar. > >> Bhyve can be used for hosting other operating systems > >> on the same type of HW as the vanilla system. > > > > OK, thanks. You've saved me the work of trying then failing terribly :D > > > > It doesn't have to be hosted. The reason for me asking is, basically can > I take > > the image and (as an image, not as an OS) can it be updated/recompiled > on different, > > higher spec hardware, then returned to the Pi? > > > > Hopefully I'm describing this right. You know on say amd64, an arm6 > system can be > > cross-compiled as an installable system. That system is running. I have > updated it > > (while installed on RPI2 hardware) and installed my configs, it works > great. > > Now I can unplug the microSD, dd it to a .img file, on another system, > to archive it. > > What I'm asking is, can I take that image while it's on the other > system, and > > interact with it to the extent that I can update/upgrade it? > > In theory, yes. If you could figure this out there are lots of people who > might be interested in it. > > The basic idea: cross-compile a new FreeBSD system, mount the arm6 image > and then cross-install onto it to update it. This is very similar to the > process Crochet uses for building a new image, except that instead of > starting with a new blank system image you would instead mount your > existing image and install over it. > > Roughly speaking, the process should be something like the following > (you'll need to do some research to fill in the many details): > > $ cd /usr/src > $ make TARGET_ARCH=arm6 buildworld > $ make TARGET_ARCH=arm6 KERNCONF=RPI2 buildkernel > $ # ... mount the img via md loopback > $ mergemaster filesystem> > $ make TARGET_ARCH=arm6 KERNCONF=RPI2 DESTDIR= installkernel > $ make TARGET_ARCH=arm6 KERNCONF=RPI2 DESTDIR= installworld > $ # ... unmount the image s/arm6/armv6/g but otherwise that looks good. Warner From owner-freebsd-arm@freebsd.org Tue Sep 8 02:02: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 BA24B9CC6A4 for ; Tue, 8 Sep 2015 02:02:39 +0000 (UTC) (envelope-from mmitchel@gmail.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 773A51E6A for ; Tue, 8 Sep 2015 02:02:39 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: by qgx61 with SMTP id 61so72238642qgx.3 for ; Mon, 07 Sep 2015 19:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cj0resRt6Qgl3AufnHLNQT/Dvc/kiUcc9C/b40GTxds=; b=KLCRCoCnpUbRMChHlmLMx6DUZz9XLbAyucgfPZHKfD8s47PhpizLi1T6IIacX04CMm z/S9d7pFRr7Wwpp6BYcIxFqBhdc+yMrAFQStNp2sdphVK2ffGMnreEibJUT71tA20TRs kh1KagWiq+JxYqZ4tdqmKwK55goGBkucJGq/39mU3ilv8PTur+92usWqyPuccdQEC5wC oMIylYK1pkCcja26OFe7zlaWVA897bh0K3eq4UITsSPnBS+CkQawm5QsUw0YnDIH8Yse 6ZLsytbUNn2u6srLwiT4GM/DvzVFrogdXdxbkaibiH7feimNYyXgUyovSlm/xd/0x6VQ wJGg== MIME-Version: 1.0 X-Received: by 10.140.39.73 with SMTP id u67mr31033014qgu.16.1441677758485; Mon, 07 Sep 2015 19:02:38 -0700 (PDT) Received: by 10.55.165.131 with HTTP; Mon, 7 Sep 2015 19:02:38 -0700 (PDT) In-Reply-To: <59F1B4A5-CD93-46D2-83D3-F0790CA2FA8E@gmail.com> References: <20150907090541.GA54788@potato.growveg.org> <59F1B4A5-CD93-46D2-83D3-F0790CA2FA8E@gmail.com> Date: Mon, 7 Sep 2015 19:02:38 -0700 Message-ID: Subject: Re: bhyve/arm6/amd64 query From: Michael Mitchell To: Jukka Ukkonen 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 Sep 2015 02:02:39 -0000 investigate qemu; it will run arm based images of various type. On Mon, Sep 7, 2015 at 5:33 AM, Jukka Ukkonen wrote: > AFAIK no. Bhyve is a plain hardware type of container, > not a hardware emulator like qemu, nor a jail type > container. > You should be looking for qemu or something similar. > Bhyve can be used for hosting other operating systems > on the same type of HW as the vanilla system. > > --jau > > > Sent from my iPad > > > On 07 Sep 2015, at 12:05, John wrote: > > > > Hello list, > > > > Can an arm6 image guest run on a bhyve amd64 host? > > > > thanks, > > -- > > John > > _______________________________________________ > > 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" > _______________________________________________ > 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 Sep 8 05:14: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 38B859CCE79 for ; Tue, 8 Sep 2015 05:14:02 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: from mail2.openmailbox.org (mail2.openmailbox.org [62.4.1.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE28719C6 for ; Tue, 8 Sep 2015 05:14:01 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: by mail2.openmailbox.org (Postfix, from userid 1004) id 6FA642AC18B0; Tue, 8 Sep 2015 07:13:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1441689233; bh=SSvyPAxyLigHVs4+nkcqGa0xiE4pmkMOJaKoHo6dNCk=; h=Date:From:To:Subject:From; b=hwb6ikTLDbeK2vBgJyilO6aqNWFw/ym214744gROI7xaBWeKFJSHBTrru1TqpmaCj 9r/jWr6+lZQ6WRt65JOEshmO8YvP/hsW3SENwRYDRGXOl44hokw+6z/SW09jbRLAbx YYU/XfM7wG6e1JZbGHuGpGORa6XRb82a9i6AGfOI= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on openmailbox-b2 X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MISSING_MID,NO_RECEIVED,NO_RELAYS autolearn=no autolearn_force=no version=3.4.0 Date: Tue, 08 Sep 2015 05:13:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1441689233; bh=SSvyPAxyLigHVs4+nkcqGa0xiE4pmkMOJaKoHo6dNCk=; h=Date:From:To:Subject:From; b=hwb6ikTLDbeK2vBgJyilO6aqNWFw/ym214744gROI7xaBWeKFJSHBTrru1TqpmaCj 9r/jWr6+lZQ6WRt65JOEshmO8YvP/hsW3SENwRYDRGXOl44hokw+6z/SW09jbRLAbx YYU/XfM7wG6e1JZbGHuGpGORa6XRb82a9i6AGfOI= From: sig6247 To: freebsd-arm@freebsd.org Subject: A10/A20 AHCI device not working on BananaPi M1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20150908051353.6FA642AC18B0@mail2.openmailbox.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 Sep 2015 05:14:02 -0000 Hi, I'm running 11.0-CURRENT r287391 with KERNCONF=A20, the hard disk is connected on the SATA port. It seems it can not read/write the disk reliably. # newfs -U /dev/ada0 /dev/ada0: 476940.0MB (976773168 sectors) block size 32768, fragment size 4096 using 762 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates super-block backups (for fsck_ffs -b #) at: 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, 19233792, ... ... 962962432, 964244672, 965526912, 966809152, 968091392, 969373632, 970655872, 971938112, 973220352, 974502592, 975784832 cg 0: bad magic number # dd if=/dev/zero of=/dev/ada0 bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.062203 secs (8231 bytes/sec) # dd if=/dev/ada0 bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.001043 secs (490911 bytes/sec) 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000040 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 |................| * 00000080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000100 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 |................| * 00000140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000180 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 |................| * 00000200 # dd if=/dev/ada0 bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.001050 secs (487832 bytes/sec) 00000000 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 |................| * 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000180 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 |................| * 00000200 From owner-freebsd-arm@freebsd.org Tue Sep 8 05:23: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 A68D29CD2D9 for ; Tue, 8 Sep 2015 05:23:03 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: from smtp27.openmailbox.org (smtp27.openmailbox.org [62.4.1.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1C41CE7 for ; Tue, 8 Sep 2015 05:23:03 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: by mail2.openmailbox.org (Postfix, from userid 1002) id 34AE77C15FE; Tue, 8 Sep 2015 06:43:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1441687410; bh=SSvyPAxyLigHVs4+nkcqGa0xiE4pmkMOJaKoHo6dNCk=; h=Date:From:To:Subject:From; b=nRH+8PyQHjllUQSCWF6CDflFbzuX6zgk44azSk89WhmNG07LAMFpE0P5hIwNPPSn8 XZPD8FykLxO8Hwqk+s4z5lfdpclnKv41PYQ9eV1z35GQj9tWN641zSXBn1ydEHo59z UMhADj66PZv1+Bu8jRkrCBCTxhCpDESFQRmU4R3M= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on openmailbox-b1 X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MISSING_MID,NO_RECEIVED,NO_RELAYS autolearn=no autolearn_force=no version=3.4.0 Date: Tue, 08 Sep 2015 04:43:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1441687410; bh=SSvyPAxyLigHVs4+nkcqGa0xiE4pmkMOJaKoHo6dNCk=; h=Date:From:To:Subject:From; b=nRH+8PyQHjllUQSCWF6CDflFbzuX6zgk44azSk89WhmNG07LAMFpE0P5hIwNPPSn8 XZPD8FykLxO8Hwqk+s4z5lfdpclnKv41PYQ9eV1z35GQj9tWN641zSXBn1ydEHo59z UMhADj66PZv1+Bu8jRkrCBCTxhCpDESFQRmU4R3M= From: sig6247 To: freebsd-arm@freebsd.org Subject: A10/A20 AHCI device not working on BananaPi M1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20150908044330.34AE77C15FE@mail2.openmailbox.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 Sep 2015 05:23:03 -0000 Hi, I'm running 11.0-CURRENT r287391 with KERNCONF=A20, the hard disk is connected on the SATA port. It seems it can not read/write the disk reliably. # newfs -U /dev/ada0 /dev/ada0: 476940.0MB (976773168 sectors) block size 32768, fragment size 4096 using 762 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates super-block backups (for fsck_ffs -b #) at: 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, 19233792, ... ... 962962432, 964244672, 965526912, 966809152, 968091392, 969373632, 970655872, 971938112, 973220352, 974502592, 975784832 cg 0: bad magic number # dd if=/dev/zero of=/dev/ada0 bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.062203 secs (8231 bytes/sec) # dd if=/dev/ada0 bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.001043 secs (490911 bytes/sec) 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000040 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 |................| * 00000080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000100 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 |................| * 00000140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000180 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 |................| * 00000200 # dd if=/dev/ada0 bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.001050 secs (487832 bytes/sec) 00000000 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 |................| * 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000180 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 |................| * 00000200 From owner-freebsd-arm@freebsd.org Tue Sep 8 13:16:20 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 659659CC542 for ; Tue, 8 Sep 2015 13:16:20 +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 3FB791E80 for ; Tue, 8 Sep 2015 13:16:20 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id ACE2A961; Tue, 8 Sep 2015 09:16:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: bhyve/arm6/amd64 query From: Paul Mather In-Reply-To: <20150907150539.GA2959@potato.growveg.org> Date: Tue, 8 Sep 2015 09:16:12 -0400 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150907090541.GA54788@potato.growveg.org> <59F1B4A5-CD93-46D2-83D3-F0790CA2FA8E@gmail.com> <20150907150539.GA2959@potato.growveg.org> To: John X-Mailer: Apple Mail (2.2104) 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 Sep 2015 13:16:20 -0000 On Sep 7, 2015, at 11:05 AM, John = wrote: > On Mon, Sep 07, 2015 at 03:33:24PM +0300, Jukka Ukkonen wrote: >> AFAIK no. Bhyve is a plain hardware type of container, >> not a hardware emulator like qemu, nor a jail type >> container. >> You should be looking for qemu or something similar. >> Bhyve can be used for hosting other operating systems >> on the same type of HW as the vanilla system. >=20 > OK, thanks. You've saved me the work of trying then failing terribly = :D >=20 > It doesn't have to be hosted. The reason for me asking is, basically = can I take > the image and (as an image, not as an OS) can it be updated/recompiled = on different, > higher spec hardware, then returned to the Pi? >=20 > Hopefully I'm describing this right. You know on say amd64, an arm6 = system can be > cross-compiled as an installable system. That system is running. I = have updated it > (while installed on RPI2 hardware) and installed my configs, it works = great.=20 > Now I can unplug the microSD, dd it to a .img file, on another system, = to archive it.=20 > What I'm asking is, can I take that image while it's on the other = system, and=20 > interact with it to the extent that I can update/upgrade it? >=20 > *the other system is also freebsd11, but amd64* I do something similar to what you describe for my Raspberry Pi and = BeagleBone Black except I don't deal with it as a complete image. I = just work with the file systems on the SD card. I cross build the system on my FreeBSD/amd64 system using this guide: = https://wiki.freebsd.org/FreeBSD/arm/crossbuild. When I'm ready to = update the SD card on the Pi or BBB, I shut them down and then mount the = UFS2 file system on the FreeBSD/amd64 system. I run make installkernel = and installworld to the mounted SD card file system (mounted, e.g., at = /build/sys/bbb) and also run mergemaster (e.g., mergemaster -i -F -m = /build/src/head -A armv6 -D /build/sys/bbb). All this is really just = using the standard build tools, but with some extra option specified due = to the cross-build nature of the process. After unmounting the SD card, I put it back in the Pi or BBB and start = it up again. This method has worked without problems for me for a = while, and I can build a new kernel and world on my FreeBSD/amd64 system = in under 30 minutes, as opposed to the many many hours it takes to do it = natively on the Pi or BBB. Cheers, Paul.= From owner-freebsd-arm@freebsd.org Tue Sep 8 16:23:50 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 483CC9CC5A9 for ; Tue, 8 Sep 2015 16:23:50 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 100561F67 for ; Tue, 8 Sep 2015 16:23:49 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZZLfu-0000FQ-H6 for freebsd-arm@freebsd.org; Tue, 08 Sep 2015 17:23:14 +0100 Date: Tue, 8 Sep 2015 17:23:10 +0100 From: John To: freebsd-arm@freebsd.org Subject: swap questions freebsd11/arm6 Message-ID: <20150908162309.GA929@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John 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 Sep 2015 16:23:50 -0000 Hello list, sorry about all my questions. I'm learning, honest. OK I found that having a swapfile after the fact, makes it not appear in top. It seemed that some of the system saw the swap at /usr/swap0 but other parts didn't use it. So in an effort to get around this, I got another spare usb stick and put swap on it. The stick is 16GB. I now get the folllowing in messages: Sep 8 15:26:34 potato kernel: warning: total configured swap (3906304 pages) exceeds maximum recommended amount (223328 pages). Sep 8 15:26:34 potato kernel: warning: increase kern.maxswzone or reduce amount of swap. Thing is, I'd quite like a huge amount of swap given the following: 1. not too concerned about speed here, as long as it's stable 2. things like svnlite choke on many writes There's not much documentation about kern.maxswzone. I put the following in /boot/loader.conf : kern.maxswzone=3906304 it still complains. Please can anyone give pointers how to fix this? thanks, -- John From owner-freebsd-arm@freebsd.org Tue Sep 8 21:40: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 59792A00D30 for ; Tue, 8 Sep 2015 21:40:12 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 2533F1849 for ; Tue, 8 Sep 2015 21:40:12 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by ykdg206 with SMTP id g206so140344514ykd.1 for ; Tue, 08 Sep 2015 14:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F03pWE0PCagVd15aYlNYN7jktVcZF7JbB/Cz2/jVKVQ=; b=m5AvFceB28rFBFQ6eLb9TtK8LO+jUfePg5h0pnox4BUA4KUnrXTzufCnU7pkNjGXK/ I3+Inv/RoASH9lm0834/sP5fK3QAOMjFWcYUbroY1Uw+A2BAp7QvxWMbZUq25ZZkqmQd lCSpQLoln4AHR1HyY5aV3V7e50zAF/UIftHzpYlmvgdrH9Rlep4Xrk2P3tzdG6li6bXO 1vql0Rjp3Pd/0ck/J+y5/Fo5+uMfX8r5+UzSlEv+1ypS/NCrQ0CP/mHP8dsx2vuqpADl DAA3Otc3ro3YLP3GMlaDCRlNw0VzWrStfj954UJee/7pEA0CEL6cgNfhUIYAFAaGBnhC SjXA== MIME-Version: 1.0 X-Received: by 10.170.220.215 with SMTP id m206mr32684561ykf.57.1441748411077; Tue, 08 Sep 2015 14:40:11 -0700 (PDT) Received: by 10.129.43.70 with HTTP; Tue, 8 Sep 2015 14:40:11 -0700 (PDT) In-Reply-To: <20150908051353.6FA642AC18B0@mail2.openmailbox.org> References: <20150908051353.6FA642AC18B0@mail2.openmailbox.org> Date: Tue, 8 Sep 2015 18:40:11 -0300 Message-ID: Subject: Re: A10/A20 AHCI device not working on BananaPi M1 From: Luiz Otavio O Souza To: sig6247 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 Sep 2015 21:40:12 -0000 On 8 September 2015 at 02:13, sig6247 wrote: > > Hi, > > I'm running 11.0-CURRENT r287391 with KERNCONF=A20, > the hard disk is connected on the SATA port. > It seems it can not read/write the disk reliably. Hi, Yes, this is a know problem, there is a patch floating around that seems to address this issue. I'll try to find the link to this patch. Luiz From owner-freebsd-arm@freebsd.org Tue Sep 8 22:05: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 1DD319CD8A6 for ; Tue, 8 Sep 2015 22:05:00 +0000 (UTC) (envelope-from kah42pub@blarg.com) Received: from mail.avvanta.com (smtp61.avvanta.com [206.124.128.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02A32152B for ; Tue, 8 Sep 2015 22:04:59 +0000 (UTC) (envelope-from kah42pub@blarg.com) Received: from mail.avvanta.com (localhost.pops.p.blarg.net [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id 5B956276CB7 for ; Tue, 8 Sep 2015 15:04:52 -0700 (PDT) Received: from MBP16GB.local (c-50-135-203-40.hsd1.wa.comcast.net [50.135.203.40]) by mail.avvanta.com (Postfix) with ESMTP id 4094E276CB6 for ; Tue, 8 Sep 2015 15:04:52 -0700 (PDT) Subject: Re: swap questions freebsd11/arm6 To: freebsd-arm@freebsd.org References: <20150908162309.GA929@potato.growveg.org> From: kah42pub X-Enigmail-Draft-Status: N1010 Message-ID: <55EF5B84.4080403@blarg.com> Date: Tue, 8 Sep 2015 15:04:52 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150908162309.GA929@potato.growveg.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.pops.p.blarg.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: Tue, 08 Sep 2015 22:05:00 -0000 On 9/8/15 09:23, John wrote: > Hello list, > > sorry about all my questions. I'm learning, honest. > > OK I found that having a swapfile after the fact, makes it not appear in > top. It seemed that some of the system saw the swap at /usr/swap0 but > other parts didn't use it. So in an effort to get around this, I > got another spare usb stick and put swap on it. The stick is 16GB. > > I now get the folllowing in messages: > > Sep 8 15:26:34 potato kernel: warning: total configured swap (3906304 pages) > exceeds maximum recommended amount (223328 pages). > Sep 8 15:26:34 potato kernel: warning: increase kern.maxswzone or reduce > amount of swap. > > Thing is, I'd quite like a huge amount of swap given the following: > > 1. not too concerned about speed here, as long as it's stable > 2. things like svnlite choke on many writes > > There's not much documentation about kern.maxswzone. I put the > following in /boot/loader.conf : > > kern.maxswzone=3906304 > > it still complains. > > Please can anyone give pointers how to fix this? > thanks, > I'm not an expert on this topic so take it with a grain of salt... Looking through my old notes, I have a reference that the maximum swap space for FreeBSD was 8X the available memory. Note that this is available memory which is reported by the kernel during boot and not physical memory. They are likely not the same. This is dmesg output from a RPI2 card I have running as an example: real memory = 989851648 (943 MB) avail memory = 958476288 (914 MB) At the time I made the notation, it didn't appear to be possible to have more than this amount without one, or more, kernel patches so I didn't bother with it (this was probably back in the FreeBSD 8 time frame... maybe... so I don't know if anything has changed since then). I have two default configurations for FreeBSD on armv6. One is without any swap defined where I know it will never be needed (card is dedicated to one task). The second (for more general purposes) is with 4X physical memory defined for more general purpose (multi-core) cards. For this type of question, I'd probably post it to the hackers mailing list. That group may have more experience and/or insight into that tuning parameter and large swap spaces. Hope that helps. Kris From owner-freebsd-arm@freebsd.org Tue Sep 8 23:36:55 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 D9BD8A00A26 for ; Tue, 8 Sep 2015 23:36:55 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yk0-x243.google.com (mail-yk0-x243.google.com [IPv6:2607:f8b0:4002:c07::243]) (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 9C157146B for ; Tue, 8 Sep 2015 23:36:55 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by ykba192 with SMTP id a192so6546432ykb.2 for ; Tue, 08 Sep 2015 16:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7gGAoyvIS9DZllxe+rEEUUEOEy3+Nfd9ecWtNmOIx3w=; b=QAlfi2an2dVhEnznCOQgCk0uB9M9fK00COb2CN4YH8ONH3LPjimxqbD1W+enYfkOpl sRwZqhO6mQLK4J5juGpSIfWT3l5ytTdZBQjIle+BpYUqztCDxI0P3nIjkmlqM8PxcbrX 72KdMT8I8NM8VMnSwtttTD9Fd4cRlYU0dO4Imww3GVFtlQzKd89MPGm913eqQHUI2bST dqF1ROrmFYeNhGVdINUFIxlRpntwSHAksI3bJLhG5pR1nnX24QUMd9B4ijICSIklhs2k RhHyHWUFISqSx8NKMACBz3enaWQ311Yih/K1+d8bT3sd4jLsNBy0+83DDKTIIbfWWT63 MvwA== MIME-Version: 1.0 X-Received: by 10.170.153.3 with SMTP id u3mr33064373ykc.46.1441755414868; Tue, 08 Sep 2015 16:36:54 -0700 (PDT) Received: by 10.129.43.70 with HTTP; Tue, 8 Sep 2015 16:36:54 -0700 (PDT) In-Reply-To: References: <20150908051353.6FA642AC18B0@mail2.openmailbox.org> Date: Tue, 8 Sep 2015 20:36:54 -0300 Message-ID: Subject: Re: A10/A20 AHCI device not working on BananaPi M1 From: Luiz Otavio O Souza To: sig6247 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 Sep 2015 23:36:55 -0000 On 8 September 2015 at 18:40, Luiz Otavio O Souza wrote: > On 8 September 2015 at 02:13, sig6247 wrote: >> >> Hi, >> >> I'm running 11.0-CURRENT r287391 with KERNCONF=A20, >> the hard disk is connected on the SATA port. >> It seems it can not read/write the disk reliably. > > Hi, > > Yes, this is a know problem, there is a patch floating around that > seems to address this issue. > > I'll try to find the link to this patch. Hi, Here is the patch: https://github.com/strejda/qualcomm/commit/28e3187f4ae509081b9d7e6aef11905d9ecc63e0 Please, let us know if this patch works for you. Luiz From owner-freebsd-arm@freebsd.org Wed Sep 9 07:37:18 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 1786F9CD5F3 for ; Wed, 9 Sep 2015 07:37:18 +0000 (UTC) (envelope-from bo@kbct.de) Received: from yserv1.ybit.eu (yserv1.ybit.eu [78.46.83.78]) by mx1.freebsd.org (Postfix) with ESMTP id CA7291127 for ; Wed, 9 Sep 2015 07:37:17 +0000 (UTC) (envelope-from bo@kbct.de) Received: from localhost (yserv1.ybit.eu.local [127.0.0.1]) by yserv1.ybit.eu (Postfix) with ESMTP id 47BC6C81FFE; Wed, 9 Sep 2015 09:28:48 +0200 (CEST) Received: from yserv1.ybit.eu ([127.0.0.1]) by localhost (ybit.eu [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28474-09; Wed, 9 Sep 2015 09:28:18 +0200 (CEST) Received: from bo-mbp.fritz.box (unknown [212.53.178.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kb@kbct.de) by yserv1.ybit.eu (Postfix) with ESMTPSA id 7DDAAC81FEA; Wed, 9 Sep 2015 09:28:18 +0200 (CEST) Subject: Re: A10/A20 AHCI device not working on BananaPi M1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AC357686-503A-4228-AABD-806205805F5D"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5.1 From: =?utf-8?Q?Bj=C3=B6rn_Oelke?= In-Reply-To: Date: Wed, 9 Sep 2015 09:28:17 +0200 Cc: =?utf-8?Q?Bj=C3=B6rn_Oelke?= , "freebsd-arm@freebsd.org" Message-Id: <71658691-8360-4B42-8CAD-65993C207B53@kbct.de> References: <20150908051353.6FA642AC18B0@mail2.openmailbox.org> To: sig6247 X-Mailer: Apple Mail (2.2104) X-Virus-Scanned: Maia Mailguard 1.0.2 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 Sep 2015 07:37:18 -0000 --Apple-Mail=_AC357686-503A-4228-AABD-806205805F5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 09 Sep 2015, at 01:36, Luiz Otavio O Souza = wrote: >=20 > Here is the patch: > = https://github.com/strejda/qualcomm/commit/28e3187f4ae509081b9d7e6aef11905= d9ecc63e0 Some of these changes have made their way into HEAD already, here's an = updated diff without conflicts: http://tmp.kbct.de/ahci-r287292.diff I tested that patch against r287592 just now. -- BO .. http://kbct.de --Apple-Mail=_AC357686-503A-4228-AABD-806205805F5D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXv35EACgkQHqhqMDnJ20HyBQCgrNL2sK5ndUru74epMpA8VTv+ t68An0sdTKZFd04QQFUdokHqcVKLC91u =6629 -----END PGP SIGNATURE----- --Apple-Mail=_AC357686-503A-4228-AABD-806205805F5D-- From owner-freebsd-arm@freebsd.org Wed Sep 9 08:54: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 4ED56A00858 for ; Wed, 9 Sep 2015 08:54:06 +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 404361CDC; Wed, 9 Sep 2015 08:54:06 +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 11C11414; Wed, 9 Sep 2015 08:54:05 +0000 (UTC) Date: Wed, 9 Sep 2015 08:54:00 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: hselasky@FreeBSD.org, kib@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <158743785.71.1441788844914.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1698701114.65.1441779260791.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1698701114.65.1441779260791.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1089 - 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: Wed, 09 Sep 2015 08:54:06 -0000 FreeBSD_HEAD_arm64 - Build #1089 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1089/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1089/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1089/console Change summaries: 287592 by hselasky: Add new USB ID. MFC after: 1 month PR: 202968 287591 by kib: Remove a check which caused spurious SIGSEGV on usermode access to the mapped address without valid pte installed, when parallel wiring of the entry happen. The entry must be copy on write. If entry is COW but was already copied, and parallel wiring set MAP_ENTRY_IN_TRANSITION, vm_fault() would sleep waiting for the MAP_ENTRY_IN_TRANSITION flag to clear. After that, the fault handler is restarted and vm_map_lookup() or vm_map_lookup_locked() trip over the check. Note that this is race, if the address is accessed after the wiring is done, the entry does not fault at all. There is no reason in the current kernel to disallow write access to the COW wired entry if the entry permissions allow it. Initially this was done in r24666, since that kernel did not supported proper copy-on-write for wired text, which was fixed in r199869. The r251901 revision re-introduced the r24666 fix for the current VM. Note that write access must clear MAP_ENTRY_NEEDS_COPY entry flag by performing COW. In reverse, when MAP_ENTRY_NEEDS_COPY is set in vmspace_fork(), the MAP_ENTRY_USER_WIRED flag is cleared. Put the assert stating the invariant, instead of returning the error. Reported and debugging help by: peter Reviewed by: alc Sponsored by: The FreeBSD Foundation MFC after: 1 week From owner-freebsd-arm@freebsd.org Wed Sep 9 09:09:42 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 D8B5E9CC232 for ; Wed, 9 Sep 2015 09:09:42 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: from smtp21.openmailbox.org (smtp21.openmailbox.org [62.4.1.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9ADCD141E for ; Wed, 9 Sep 2015 09:09:41 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: by mail2.openmailbox.org (Postfix, from userid 1002) id 734BC7C14CB; Wed, 9 Sep 2015 11:09:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1441789715; bh=xW4yCebLwSYiof4v+KFkKrrWRuzYQwja3TgOrG1kjM8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=J+5Y+FUbl8X2Mr0rePWNyIwUlYQ00BdQ82qW93wQk5Z33wC0kaQMpcXUG3p6NgWAm jsfbRFhxYoZvSlG6//eCSQL01xIB1Ny9tylqS4TQLOZ+PYeDVzdk470nLC9CfwVUKV ZloJn8IqI2tPc3VRZfy6pqV92EpCHfhXqvcj4/G0= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on openmailbox-b1 X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MISSING_MID,NO_RECEIVED,NO_RELAYS autolearn=no autolearn_force=no version=3.4.0 Date: Wed, 09 Sep 2015 09:09:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1441789705; bh=xW4yCebLwSYiof4v+KFkKrrWRuzYQwja3TgOrG1kjM8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dPOVluEMUEhOBG1FEhWnvuQUsz2GllAl4HN22jgGw+ywpmG3oupdnxcdr3AMBv30S w+EnKX1x5uwAIMsRRxRzooOVIz1H7RvGnUAFd92MhgFsc04Il5FQzJ3rYYvwoeq0Dg aS/ZJ38bdYNfCDYD6uMivFnh3xqy045f/1uBVg80= From: sig6247 To: Luiz Otavio O Souza Cc: freebsd-arm@freebsd.org Subject: Re: A10/A20 AHCI device not working on BananaPi M1 In-Reply-To: (Luiz Otavio O. Souza's message of "Tue, 8 Sep 2015 20:36:54 -0300") References: <20150908051353.6FA642AC18B0@mail2.openmailbox.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20150909090933.734BC7C14CB@mail2.openmailbox.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: Wed, 09 Sep 2015 09:09:42 -0000 On Tue, 8 Sep 2015 20:36:54 -0300, Luiz Otavio O Souza wrote: > Hi, > > Here is the patch: > https://github.com/strejda/qualcomm/commit/28e3187f4ae509081b9d7e6aef11905d9ecc63e0 > > Please, let us know if this patch works for you. > Hi Luiz, Thanks for the link, the patch worked. Now I can install the base system on the hard disk. :D From owner-freebsd-arm@freebsd.org Wed Sep 9 14:04:51 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 8978EA0188F for ; Wed, 9 Sep 2015 14:04:51 +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 78DA31C02; Wed, 9 Sep 2015 14:04:51 +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 2AC5A4FE; Wed, 9 Sep 2015 14:04:49 +0000 (UTC) Date: Wed, 9 Sep 2015 14:04:48 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1571846527.75.1441807488824.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1091 - Failure 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: Wed, 09 Sep 2015 14:04:51 -0000 FreeBSD_HEAD_arm64 - Build #1091 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1091/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1091/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1091/console Change summaries: No changes The end of the build log: Started by an SCM change Building remotely on kyua4.nyi.freebsd.org (jailer) in workspace /jenkins/workspace/FreeBSD_HEAD_arm64 Updating svn://svnmir.freebsd.org/base/head at revision '2015-09-09T11:54:40.490 +0000' ERROR: Failed to update svn://svnmir.freebsd.org/base/head org.tmatesoft.svn.core.SVNException: svn: E210004: Handshake failed: 'Operation timed out' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.skipLeadingGrabage(SVNConnection.java:108) at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.handshake(SVNConnection.java:131) at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.open(SVNConnection.java:80) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1253) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.testConnection(SVNRepositoryImpl.java:96) at org.tmatesoft.svn.core.io.SVNRepository.getRepositoryUUID(SVNRepository.java:283) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.createRepository(SvnRepositoryAccess.java:110) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepository(SvnNgRepositoryAccess.java:210) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:156) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:38) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:158) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2691) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:69) at java.lang.Thread.run(Thread.java:745) ERROR: Subversion update failed java.io.IOException: remote file operation failed: /jenkins/workspace/FreeBSD_HEAD_arm64 at hudson.remoting.Channel@76ecae69:kyua4.nyi.freebsd.org: java.io.IOException at hudson.FilePath.act(FilePath.java:987) at hudson.FilePath.act(FilePath.java:969) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1282) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:381) Caused by: java.io.IOException at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:212) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2691) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:69) at java.lang.Thread.run(Thread.java:745) at ......remote call to kyua4.nyi.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1361) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:753) at hudson.FilePath.act(FilePath.java:980) ... 12 more Caused by: hudson.scm.subversion.UpdaterException: failed to perform svn update at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:212) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2691) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:69) at java.lang.Thread.run(Thread.java:745) Caused by: org.tmatesoft.svn.core.SVNException: svn: E210004: Handshake failed: 'Operation timed out' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.skipLeadingGrabage(SVNConnection.java:108) at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.handshake(SVNConnection.java:131) at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.open(SVNConnection.java:80) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1253) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.testConnection(SVNRepositoryImpl.java:96) at org.tmatesoft.svn.core.io.SVNRepository.getRepositoryUUID(SVNRepository.java:283) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.createRepository(SvnRepositoryAccess.java:110) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepository(SvnNgRepositoryAccess.java:210) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:156) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:38) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:158) ... 14 more [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson2625273649008480910.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 jail: "FreeBSD_HEAD_arm64" not found + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address + true + sudo umount FreeBSD_HEAD_arm64/usr/src umount: FreeBSD_HEAD_arm64/usr/src: statfs: No such file or directory umount: FreeBSD_HEAD_arm64/usr/src: unknown file system + true + sudo umount FreeBSD_HEAD_arm64/dev umount: FreeBSD_HEAD_arm64/dev: statfs: No such file or directory umount: FreeBSD_HEAD_arm64/dev: unknown file system + true + sudo rm -fr FreeBSD_HEAD_arm64 + sudo chflags -R noschg FreeBSD_HEAD_arm64 chflags: FreeBSD_HEAD_arm64: No such file or directory + true + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Wed Sep 9 15:02: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 91714A00690 for ; Wed, 9 Sep 2015 15:02:52 +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 82E67158C; Wed, 9 Sep 2015 15:02:52 +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 EEC8C520; Wed, 9 Sep 2015 15:02:52 +0000 (UTC) Date: Wed, 9 Sep 2015 15:02:51 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1083246544.81.1441810972952.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1571846527.75.1441807488824.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1571846527.75.1441807488824.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1092 - 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: Wed, 09 Sep 2015 15:02:52 -0000 FreeBSD_HEAD_arm64 - Build #1092 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1092/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1092/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1092/console Change summaries: No changes From owner-freebsd-arm@freebsd.org Wed Sep 9 15:20: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 900EAA01135 for ; Wed, 9 Sep 2015 15:20:27 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 589CB1F48 for ; Wed, 9 Sep 2015 15:20:26 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZZhAc-0000Km-Pf for freebsd-arm@freebsd.org; Wed, 09 Sep 2015 16:20:23 +0100 Date: Wed, 9 Sep 2015 16:20:22 +0100 From: John To: freebsd-arm@freebsd.org Subject: static device numbering on arm6/FreeBSD11 Message-ID: <20150909152022.GA1025@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John 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 Sep 2015 15:20:27 -0000 Hello list, On i386/amd64 the kernel line: options ATA_STATIC_ID # Static device numbering means that I can reference a da device in fstab which stays constant through reboots. Is there an equivalent line for the RPI2 kernel? I've looked but can't see it. At the moment, they keep swapping round. thanks, -- John From owner-freebsd-arm@freebsd.org Wed Sep 9 16:36: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 48D47A00B38 for ; Wed, 9 Sep 2015 16:36:11 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 098C41CDE for ; Wed, 9 Sep 2015 16:36:10 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZZiLK-0007Fh-6h for freebsd-arm@freebsd.org; Wed, 09 Sep 2015 17:35:45 +0100 Date: Wed, 9 Sep 2015 17:35:16 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: very odd behaviour from svnlite on RPi2 [FIXED] Message-ID: <20150909163516.GB1025@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150904173804.GA82922@potato.growveg.org> <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> <20150904223214.GA80713@potato.growveg.org> <644A3890-CEF7-4ED4-BB85-616C09EE1E6F@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <644A3890-CEF7-4ED4-BB85-616C09EE1E6F@kientzle.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John 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 Sep 2015 16:36:11 -0000 On Fri, Sep 04, 2015 at 08:40:17PM -0700, Tim Kientzle wrote: > > > On Sep 4, 2015, at 3:32 PM, John wrote: > > > > On Fri, Sep 04, 2015 at 11:33:54PM +0200, Andreas Schwarz wrote: > > > >> I got this svn errors from time to time, independently from the rpi. For > >> getting and updating the ports tree, you can also use the "portsnap" tool > >> (it's part of the base system). > > > > Yeah I thought about doing this instead of svnlite (after I'd started > > svnlite). > > After 10 restarts I got so annoyed I made a while loop. I've never used > > portsnap because I thought it lagged behind svn, but I might use it in > > future, maybe it's suited more to low-power systems. > > Svn should work just fine on "low power systems," but has had problems on > FreeBSD-based RPi and BeagleBone for a long time. > > I suspect the root cause is a bug in SVN when dealing with extremely slow disk: > I think the TCP connection times out while the svn client is doing a long > series of disk operations. > > It certainly should not be happening. > > > I've not seen these errors on the other freebsd boxes in the logs (same > > connection) which is why I thought it might be a bottleneck with the pi. > > In some cases, I've repeated the 'svn cleanup' + 'svn up' cycle for 2-3 days > before it finally completed only to see missing files that svn doesn't seem to > be aware of at all. I've found that partial tree checkouts are more likely > to succeed; you can sometimes work around this by asking SVN to > checkout/update individual subdirectories. > > For FreeBSD source checkouts, I recommend using git which doesn't seem to > suffer from this problem. Similarly, portsnap is more resilient than svn for > ports checkouts. Hi, The workaround for this for me is to take a usb stick, partition it into four parts and made a 4GB slice for src and 7GB for ports, mounted with async and noatime, and it's working a treat. The other two partitions I've set as swap (2GB each) which has fixed the swap issues I described in another thread. Using the same logic, I might install another stick just for /usr/obj and /tmp and /var/tmp. It seems the microSD gets a little too busy if everything is on / -- John From owner-freebsd-arm@freebsd.org Wed Sep 9 17:13:54 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 F00EEA01C04 for ; Wed, 9 Sep 2015 17:13:53 +0000 (UTC) (envelope-from kah42pub@blarg.com) Received: from mail.avvanta.com (smtp61.avvanta.com [206.124.128.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D205F109B for ; Wed, 9 Sep 2015 17:13:53 +0000 (UTC) (envelope-from kah42pub@blarg.com) Received: from mail.avvanta.com (localhost.scooter.p.blarg.net [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id E6061276D66 for ; Wed, 9 Sep 2015 10:12:46 -0700 (PDT) Received: from MBP16GB.local (c-50-135-203-40.hsd1.wa.comcast.net [50.135.203.40]) by mail.avvanta.com (Postfix) with ESMTP id C7BAD276D62 for ; Wed, 9 Sep 2015 10:12:46 -0700 (PDT) Subject: Re: very odd behaviour from svnlite on RPi2 [FIXED] To: freebsd-arm@freebsd.org References: <20150904173804.GA82922@potato.growveg.org> <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> <20150904223214.GA80713@potato.growveg.org> <644A3890-CEF7-4ED4-BB85-616C09EE1E6F@kientzle.com> <20150909163516.GB1025@potato.growveg.org> From: kah42pub X-Enigmail-Draft-Status: N1010 Message-ID: <55F068CF.9030707@blarg.com> Date: Wed, 9 Sep 2015 10:13:51 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150909163516.GB1025@potato.growveg.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.scooter.p.blarg.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: Wed, 09 Sep 2015 17:13:54 -0000 On 9/9/15 09:35, John wrote: > On Fri, Sep 04, 2015 at 08:40:17PM -0700, Tim Kientzle wrote: >> >>> On Sep 4, 2015, at 3:32 PM, John wrote: >>> >>> On Fri, Sep 04, 2015 at 11:33:54PM +0200, Andreas Schwarz wrote: >>> >>>> I got this svn errors from time to time, independently from the rpi. For >>>> getting and updating the ports tree, you can also use the "portsnap" tool >>>> (it's part of the base system). >>> >>> Yeah I thought about doing this instead of svnlite (after I'd started >>> svnlite). >>> After 10 restarts I got so annoyed I made a while loop. I've never used >>> portsnap because I thought it lagged behind svn, but I might use it in >>> future, maybe it's suited more to low-power systems. >> >> Svn should work just fine on "low power systems," but has had problems on >> FreeBSD-based RPi and BeagleBone for a long time. >> >> I suspect the root cause is a bug in SVN when dealing with extremely slow disk: >> I think the TCP connection times out while the svn client is doing a long >> series of disk operations. >> >> It certainly should not be happening. >> >>> I've not seen these errors on the other freebsd boxes in the logs (same >>> connection) which is why I thought it might be a bottleneck with the pi. >> >> In some cases, I've repeated the 'svn cleanup' + 'svn up' cycle for 2-3 days >> before it finally completed only to see missing files that svn doesn't seem to >> be aware of at all. I've found that partial tree checkouts are more likely >> to succeed; you can sometimes work around this by asking SVN to >> checkout/update individual subdirectories. >> >> For FreeBSD source checkouts, I recommend using git which doesn't seem to >> suffer from this problem. Similarly, portsnap is more resilient than svn for >> ports checkouts. > > Hi, > > The workaround for this for me is to take a usb stick, partition it into > four parts and made a 4GB slice for src and 7GB for ports, mounted with > async and noatime, and it's working a treat. The other two partitions I've > set as swap (2GB each) which has fixed the swap issues I described in > another thread. Using the same logic, I might install another stick just for > /usr/obj and /tmp and /var/tmp. It seems the microSD gets a little too > busy if everything is on / > This is the approach I use for my RPIs and RPI2s. The SD cards can't handle the I/O activity of a "real" system so I move various file systems off to a partitioned USB stick. These include: /usr/ports /usr/src /usr/local /home I set noatime on these but haven't been brave enough to set async. Moving these has improved performance and stability on these systems. I have toyed with the idea of moving the following to USB but haven't found a compelling need, yet. Getting the four above off seems to have reduced the stress on the SD card. /tmp /var/tmp /var/log /usr/obj It is possible I'm missing some tuning variable that would make the SD card I/O work better but I couldn't find such a thing and moving the higher use filesystems off to a USB device was definitely a path of least resistance for me. Hope that helps someone. Kris From owner-freebsd-arm@freebsd.org Wed Sep 9 18:01:30 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 5D5BEA014C9 for ; Wed, 9 Sep 2015 18:01:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) (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 22B651ACD for ; Wed, 9 Sep 2015 18:01:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkdw123 with SMTP id w123so8031453qkd.0 for ; Wed, 09 Sep 2015 11:01:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=NEI4ykOPVmHKFuWYzW9ItoYWFJrkXJEIYeMmdzgAjFs=; b=dYKsNRk5CaRwB28asiiIaOpnEXZweoHHwOMwZqoy++DdfrYqQ1gsq9yUSO6uaX+Hec ka4T0/dwvF4r+kfo57cvOt76TKNlDj88PzygLVPZ0GGsF00uZr2LAf1w3wVs3I6nH3Sp EPz+KKR5hxbEYGI0sVYpurtAnsHPIzGQ51p/6R+/vSYWBo9UOrVLqGi1W7pZiQH0QxUF xLpTFrjZLzjdQaG8OinITXR7tbwVxhqjhM/9iH1V+rB05QTHCPWfAQCeY4ALPOUDkaFT UQ892WbpL/yFdvmYaM5eZQgQQ4sUp6B60+sfE/6ocg+MiNRWYGpAWvcDvrbJnRiK1HWZ 2c5A== X-Gm-Message-State: ALoCoQkCoG9gWDN1YuosjtC0CHavcE7Sy0WtMnd6hu6s1jg/+46/cqDpIlbRN1Rn315RrhWv9Yg4 MIME-Version: 1.0 X-Received: by 10.55.204.208 with SMTP id n77mr45495711qkl.46.1441818068278; Wed, 09 Sep 2015 10:01:08 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.164 with HTTP; Wed, 9 Sep 2015 10:01:08 -0700 (PDT) X-Originating-IP: [69.53.245.5] In-Reply-To: <20150909152022.GA1025@potato.growveg.org> References: <20150909152022.GA1025@potato.growveg.org> Date: Wed, 9 Sep 2015 11:01:08 -0600 X-Google-Sender-Auth: D6Lbse2_JUd3oN4Uh7Yq4aiWNU0 Message-ID: Subject: Re: static device numbering on arm6/FreeBSD11 From: Warner Losh To: "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: Wed, 09 Sep 2015 18:01:30 -0000 On Wed, Sep 9, 2015 at 9:20 AM, John wrote: > Hello list, > > On i386/amd64 the kernel line: > > options ATA_STATIC_ID # Static device numbering > > means that I can reference a da device in fstab which stays constant > through reboots. Is there an equivalent line for the RPI2 kernel? > I've looked but can't see it. At the moment, they keep swapping > round. Your best bet is to use ufs or gpt labels. # Device Mountpoint FStype Options Dump Pass# /dev/gpt/dune-swap none swap sw 0 0 /dev/gpt/dune-root / ufs rw 1 1 /dev/gpt/dune-dune /dune ufs rw 2 2 /dev/gpt/dune-tmp /tmp ufs rw 2 2 /dev/gpt/dune-usr /usr ufs rw 2 2 /dev/gpt/dune-var /var ufs rw 2 2 There may be ways to wire them with CAM, but this is what I've been using for a long time. From owner-freebsd-arm@freebsd.org Wed Sep 9 18:20:55 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 8F3D8A01D27 for ; Wed, 9 Sep 2015 18:20:55 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EA9F142B for ; Wed, 9 Sep 2015 18:20:55 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t89IKmg8089720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Sep 2015 11:20:48 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t89IKma2089719 for freebsd-arm@freebsd.org; Wed, 9 Sep 2015 11:20:48 -0700 (PDT) (envelope-from jmg) Date: Wed, 9 Sep 2015 11:20:48 -0700 From: John-Mark Gurney To: freebsd-arm@freebsd.org Subject: Re: static device numbering on arm6/FreeBSD11 Message-ID: <20150909182048.GN33167@funkthat.com> References: <20150909152022.GA1025@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150909152022.GA1025@potato.growveg.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 09 Sep 2015 11:20:48 -0700 (PDT) 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 Sep 2015 18:20:55 -0000 John wrote this message on Wed, Sep 09, 2015 at 16:20 +0100: > Hello list, > > On i386/amd64 the kernel line: > > options ATA_STATIC_ID # Static device numbering > > means that I can reference a da device in fstab which stays constant > through reboots. Is there an equivalent line for the RPI2 kernel? > I've looked but can't see it. At the moment, they keep swapping > round. To wire scsi devices, you can use hints as described in scsi(4).. For example: This assigns CAM bus 0 to the bus 1 instance on ahc1. Peripheral drivers can be wired to a specific bus, target, and lun as so: hint.da.0.at="scbus0" hint.da.0.target="0" hint.da.0.unit="0" I've never tried this w/ USB disks though. Though I will second the usage of gpt labels or glabels, those are more reliable, and will stay them same even when you move disks around, say in a hot swap enclosure... Hope this helps.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Wed Sep 9 18:32: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 B7CA69CD365 for ; Wed, 9 Sep 2015 18:32:03 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 98EED1DA0 for ; Wed, 9 Sep 2015 18:32:03 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t89IW2qP089828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Sep 2015 11:32:02 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t89IW2Um089827; Wed, 9 Sep 2015 11:32:02 -0700 (PDT) (envelope-from jmg) Date: Wed, 9 Sep 2015 11:32:02 -0700 From: John-Mark Gurney To: Tim Kientzle Cc: freebsd-arm Subject: Re: bhyve/arm6/amd64 query Message-ID: <20150909183202.GO33167@funkthat.com> References: <20150907090541.GA54788@potato.growveg.org> <59F1B4A5-CD93-46D2-83D3-F0790CA2FA8E@gmail.com> <20150907150539.GA2959@potato.growveg.org> <023E3382-6F0A-4EDA-9D9A-E0F60AB58FA6@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <023E3382-6F0A-4EDA-9D9A-E0F60AB58FA6@kientzle.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 09 Sep 2015 11:32:02 -0700 (PDT) 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 Sep 2015 18:32:03 -0000 Tim Kientzle wrote this message on Mon, Sep 07, 2015 at 11:15 -0700: > > On Sep 7, 2015, at 8:05 AM, John wrote: > > > > On Mon, Sep 07, 2015 at 03:33:24PM +0300, Jukka Ukkonen wrote: > >> AFAIK no. Bhyve is a plain hardware type of container, > >> not a hardware emulator like qemu, nor a jail type > >> container. > >> You should be looking for qemu or something similar. > >> Bhyve can be used for hosting other operating systems > >> on the same type of HW as the vanilla system. > > > > OK, thanks. You've saved me the work of trying then failing terribly :D > > > > It doesn't have to be hosted. The reason for me asking is, basically can I take > > the image and (as an image, not as an OS) can it be updated/recompiled on different, > > higher spec hardware, then returned to the Pi? > > > > Hopefully I'm describing this right. You know on say amd64, an arm6 system can be > > cross-compiled as an installable system. That system is running. I have updated it > > (while installed on RPI2 hardware) and installed my configs, it works great. > > Now I can unplug the microSD, dd it to a .img file, on another system, to archive it. > > What I'm asking is, can I take that image while it's on the other system, and > > interact with it to the extent that I can update/upgrade it? > > In theory, yes. If you could figure this out there are lots of people who might be interested in it. > > The basic idea: cross-compile a new FreeBSD system, mount the arm6 image and then cross-install onto it to update it. This is very similar to the process Crochet uses for building a new image, except that instead of starting with a new blank system image you would instead mount your existing image and install over it. > > Roughly speaking, the process should be something like the following (you'll need to do some research to fill in the many details): > > $ cd /usr/src > $ make TARGET_ARCH=arm6 buildworld > $ make TARGET_ARCH=arm6 KERNCONF=RPI2 buildkernel > $ # ... mount the img via md loopback > $ mergemaster > $ make TARGET_ARCH=arm6 KERNCONF=RPI2 DESTDIR= installkernel > $ make TARGET_ARCH=arm6 KERNCONF=RPI2 DESTDIR= installworld > $ # ... unmount the image I've done something different a few times, but on i386/amd64 vm's, but should work the same w/ a cross compiled arm6 world too: make buildworld make installworld -DNO_ROOT DESTDIR=/somewhereempty tar -czf worldimage.tar.gz @/somewhereempty/METALOG Then on the target system: chflags -R noschg / tar -xzf worldimage.tar.gz Kernels are easy enough to simply copy over, though similar steps can be don w/ buildkernel/installkernel... A nice thing about using -DNO_ROOT is that you can do all the building/installing as a normal user, so only when you go to extract the tar on the destination host do you need root perms... Hope this helps! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Wed Sep 9 21:55: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 96B16A01189 for ; Wed, 9 Sep 2015 21:55:17 +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 7A7F81202; Wed, 9 Sep 2015 21:55:17 +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 61B685E7; Wed, 9 Sep 2015 21:55:15 +0000 (UTC) Date: Wed, 9 Sep 2015 21:55:13 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1034295225.87.1441835714924.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1350195677.85.1441828542266.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1350195677.85.1441828542266.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1094 - 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: Wed, 09 Sep 2015 21:55:17 -0000 FreeBSD_HEAD_arm64 - Build #1094 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1094/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1094/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1094/console Change summaries: No changes The end of the build log: Started by an SCM change Building remotely on kyua4.nyi.freebsd.org (jailer) in workspace /jenkins/workspace/FreeBSD_HEAD_arm64 Updating svn://svnmir.freebsd.org/base/head at revision '2015-09-09T21:54:17.352 +0000' U sys/kern/vfs_vnops.c U tests/sys/kern/ptrace_test.c At revision 287600 No emails were triggered. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson4655944712461497800.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 jail: "FreeBSD_HEAD_arm64" not found + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address + true + sudo umount FreeBSD_HEAD_arm64/usr/src umount: FreeBSD_HEAD_arm64/usr/src: statfs: No such file or directory umount: FreeBSD_HEAD_arm64/usr/src: unknown file system + true + sudo umount FreeBSD_HEAD_arm64/dev umount: FreeBSD_HEAD_arm64/dev: statfs: No such file or directory umount: FreeBSD_HEAD_arm64/dev: unknown file system + true + sudo rm -fr FreeBSD_HEAD_arm64 + sudo chflags -R noschg FreeBSD_HEAD_arm64 chflags: FreeBSD_HEAD_arm64: No such file or directory + true + sudo rm -fr FreeBSD_HEAD_arm64 ERROR: Build step failed with exception java.lang.IllegalStateException: Invalid object ID 23 iota=24 at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:386) at hudson.remoting.ExportTable.get(ExportTable.java:330) at hudson.remoting.Channel.getExportedObject(Channel.java:605) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:317) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:301) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:260) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:69) at java.lang.Thread.run(Thread.java:745) at ......remote call to kyua4.nyi.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1361) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:753) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:179) at com.sun.proxy.$Proxy49.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:992) at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:137) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:97) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779) at hudson.model.Build$BuildExecution.build(Build.java:205) at hudson.model.Build$BuildExecution.doRun(Build.java:162) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:537) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:381) Caused by: java.lang.Exception: Object was recently deallocated #23 (ref.0) : object=null type=hudson.Launcher$RemoteLaunchCallable$1 interfaces=[hudson.Launcher$RemoteProcess] Created at Wed Sep 09 21:55:11 GMT 2015 at hudson.remoting.ExportTable$Entry.(ExportTable.java:99) at hudson.remoting.ExportTable.export(ExportTable.java:305) at hudson.remoting.Channel.internalExport(Channel.java:601) at hudson.remoting.Channel.export(Channel.java:592) at hudson.remoting.Channel.export(Channel.java:562) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1151) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1114) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:69) at java.lang.Thread.run(Thread.java:745) Released at Wed Sep 09 21:55:12 GMT 2015 at hudson.remoting.ExportTable$Entry.release(ExportTable.java:131) at hudson.remoting.ExportTable.unexportByOid(ExportTable.java:414) at hudson.remoting.Channel.unexport(Channel.java:613) at hudson.remoting.UnexportCommand.execute(UnexportCommand.java:43) at hudson.remoting.Channel$2.handle(Channel.java:484) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60) Caused by: Command hudson.remoting.UnexportCommand@72470415 created at at hudson.remoting.Command.(Command.java:67) at hudson.remoting.Command.(Command.java:50) at hudson.remoting.UnexportCommand.(UnexportCommand.java:33) at hudson.remoting.RemoteInvocationHandler.finalize(RemoteInvocationHandler.java:240) at java.lang.System$2.invokeFinalize(System.java:1270) at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:98) at java.lang.ref.Finalizer.access$100(Finalizer.java:34) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:210) Caused by: java.lang.Exception: Proxy hudson.remoting.RemoteInvocationHandler@17 was created for interface hudson.Launcher$RemoteProcess at hudson.remoting.RemoteInvocationHandler.(RemoteInvocationHandler.java:99) at hudson.remoting.RemoteInvocationHandler.wrap(RemoteInvocationHandler.java:111) at hudson.remoting.Channel.export(Channel.java:593) at hudson.remoting.Channel.export(Channel.java:562) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1151) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1114) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:69) at java.lang.Thread.run(Thread.java:745) at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:379) at hudson.remoting.ExportTable.get(ExportTable.java:330) at hudson.remoting.Channel.getExportedObject(Channel.java:605) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:317) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:301) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:260) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:69) at java.lang.Thread.run(Thread.java:745) Caused by: Released at Wed Sep 09 21:55:12 GMT 2015 at hudson.remoting.ExportTable$Entry.release(ExportTable.java:131) at hudson.remoting.ExportTable.unexportByOid(ExportTable.java:414) at hudson.remoting.Channel.unexport(Channel.java:613) at hudson.remoting.UnexportCommand.execute(UnexportCommand.java:43) at hudson.remoting.Channel$2.handle(Channel.java:484) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60) Caused by: Command hudson.remoting.UnexportCommand@7f772ebd created at at hudson.remoting.Command.(Command.java:67) at hudson.remoting.Command.(Command.java:50) at hudson.remoting.UnexportCommand.(UnexportCommand.java:33) at hudson.remoting.RemoteInvocationHandler.finalize(RemoteInvocationHandler.java:240) at java.lang.System$2.invokeFinalize(System.java:1270) at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:98) at java.lang.ref.Finalizer.access$100(Finalizer.java:34) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:210) Caused by: java.lang.Exception: Proxy hudson.remoting.RemoteInvocationHandler@17 was created for interface hudson.Launcher$RemoteProcess at hudson.remoting.RemoteInvocationHandler.(RemoteInvocationHandler.java:99) at hudson.remoting.RemoteInvocationHandler.wrap(RemoteInvocationHandler.java:111) at hudson.remoting.Channel.export(Channel.java:593) at hudson.remoting.Channel.export(Channel.java:562) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1151) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1114) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:69) at java.lang.Thread.run(Thread.java:745) Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson2216095378238737630.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 jail: "FreeBSD_HEAD_arm64" not found + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address + true + sudo umount FreeBSD_HEAD_arm64/usr/src umount: FreeBSD_HEAD_arm64/usr/src: statfs: No such file or directory umount: FreeBSD_HEAD_arm64/usr/src: unknown file system + true + sudo umount FreeBSD_HEAD_arm64/dev umount: FreeBSD_HEAD_arm64/dev: statfs: No such file or directory umount: FreeBSD_HEAD_arm64/dev: unknown file system + true + sudo rm -fr FreeBSD_HEAD_arm64 + sudo chflags -R noschg FreeBSD_HEAD_arm64 chflags: FreeBSD_HEAD_arm64: No such file or directory + true + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Wed Sep 9 22:55: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 9927AA01092 for ; Wed, 9 Sep 2015 22:55:06 +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 0BF0F105D for ; Wed, 9 Sep 2015 22:55:05 +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 t89Mt2oA014232 for ; Thu, 10 Sep 2015 00:55:03 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Thu, 10 Sep 2015 00:55:02 +0200 (CEST) Message-ID: <46e495e484.66704618@mail.schwarzes.net> In-Reply-To: <46d8b55830c.48a059ec@mail.schwarzes.net> References: <55A7D8CE.4020809@selasky.org> <55B23276.8090703@selasky.org> <55B73113.2020308@selasky.org> <55B8AB76.7030603@selasky.org> <55B8B297.1010008@selasky.org> <20150729154516.GH78154@funkthat.com> <55B8F5EC.2050908@selasky.org> <46ad096c958.1a82a175@mail.schwarzes.net> <55B9C3E2.5040501@selasky.org> <46ae815c7c3.447237c8@mail.schwarzes.net> <46aece00b53.3c1cdc1f@mail.schwarzes.net> <55BB2A5F.9000502@selasky.org> <46baa16c4ce.6efd29ef@mail.schwarzes.net> <55CF31A1.5080205@selasky.org> <46ce372c895.20050775@mail.schwarzes.net> <46d0a4441bb.41f6f91d@mail.schwarzes.net> <55DD5C0A.2050401@selasky.org> <46d8b55830c.48a059ec@mail.schwarzes.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: DWC OTG TX path optimisation for 11-current 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]); Thu, 10 Sep 2015 00:55:03 +0200 (CEST) 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 Sep 2015 22:55:06 -0000 On 01.09.15, Andreas Schwarz wrote: > On 28.08.15, Svatopluk Kraus wrote: > >> My subjective observation is that the slow system response can be >> caused by slow wake up from idle state. I have tried to change >> scheduler from ULE to BSD one with no MII warning and everything is >> okay result. And buildword was about one hour faster. Note that the >> trigger is very sensitive, so it can be just because system timing and >> many other things are different with different scheduler. > > I've tried the 4BSD scheduler too, amazing, faster and surely prevents > to run into the known problem. I've just started a buildworld loop, will > try to reach 10 rounds. I just want to inform you that I've copmpleted my ten rounds of building (with -j4) and cleaning the world in a loop without any problems (and INVARIANTS switched off) at my RPI2 (see script below). It take ~18 hours for a "round". It's not a fix but a real workaround to prevent this annoying interrupt problems with the sd driver. Seems, that the more "stolid" 4BSD scheduler will not drive the system in situations which trigger the problem. root@pizelot:~ # uname -a FreeBSD pizelot.schwarzes.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r287315: Mon Aug 31 12:03:20 CEST 2015 root@pizelot.schwarzes.net:/usr/obj/usr/src/sys/RPI2-B-ASC arm #!/bin/sh cd /usr/src while true do make cleandir make -j4 kernel-toolchain make -j4 buildkernel make -j4 buildworld date >> loop_build.log done -asc From owner-freebsd-arm@freebsd.org Thu Sep 10 00:52: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 4AB99A010E0 for ; Thu, 10 Sep 2015 00:52:10 +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 3C12E1B0D; Thu, 10 Sep 2015 00:52:10 +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 BDA1462E; Thu, 10 Sep 2015 00:52:09 +0000 (UTC) Date: Thu, 10 Sep 2015 00:52:00 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jhb@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <587531976.89.1441846329052.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1034295225.87.1441835714924.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1034295225.87.1441835714924.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1095 - 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: Thu, 10 Sep 2015 00:52:10 -0000 FreeBSD_HEAD_arm64 - Build #1095 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1095/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1095/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1095/console Change summaries: 287602 by jhb: Use _exit() instead of exit() in child processes created during tests. Suggested by: kib 287601 by jhb: Add a test to verify that a traced process sees its original parent via getppid() after a debugger process that is not the parent has attached. Reviewed by: kib (earlier version) Differential Revision: https://reviews.freebsd.org/D3615 From owner-freebsd-arm@freebsd.org Thu Sep 10 08:52: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 B2DB3A0136B for ; Thu, 10 Sep 2015 08:52:02 +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 A383C178D; Thu, 10 Sep 2015 08:52:02 +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 8E9B374C; Thu, 10 Sep 2015 08:52:02 +0000 (UTC) Date: Thu, 10 Sep 2015 08:51:55 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: hselasky@FreeBSD.org, hrs@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1685086160.95.1441875121967.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1097 - Failure 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: Thu, 10 Sep 2015 08:52:02 -0000 FreeBSD_HEAD_arm64 - Build #1097 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1097/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1097/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1097/console Change summaries: 287616 by hselasky: Update USB quirk. MFC after: 1 month PR: 202968 287615 by hrs: Use read to parse a line instead of set. MFC after: 3 days 287614 by hrs: - Add uid check. - Report delay<0 as a warning. MFC after: 3 days 287613 by hrs: Update only static routes when an interface is specified. This fixed a bad side-effect reported in PR 202144. PR: 202144 MFC after: 3 days 287612 by hrs: - Remove #ifdef HAVE_POLL_H. - Use nitems(). MFC after: 3 days 287611 by hrs: - Remove SIOCGDRLST_IN6 and SIOCGPRLST_IN6. These are quite old APIs and there is no consumer now. MFC after: 3 days 287610 by hrs: - Remove SIOCGDRLST_IN6 and SIOCGPRLST_IN6. These are quite old APIs and there is no consumer now. - Simplify first and duplicate LLA check. MFC after: 3 days 287609 by hrs: Do not add IN6_IFF_TENTATIVE when ND6_IFF_NO_DAD. MFC after: 3 days 287608 by hrs: Remove IN6_IFF_NOPFX. This flag was no longer used. MFC after: 3 days 287607 by hrs: - Remove GIF_{SEND,ACCEPT}_REVETHIP. - Simplify EADDRNOTAVAIL and EAFNOSUPPORT conditions. MFC after: 3 days The end of the build log: [...truncated 142038 lines...] --- zlib.o --- --- strvalid.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/libkern/strvalid.c --- timingsafe_bcmp.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/libkern/timingsafe_bcmp.c --- zlib.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/libkern/zlib.c --- bpf.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/bpf.c --- bpf_buffer.o --- --- bpf_filter.o --- --- bpf_buffer.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/bpf_buffer.c --- bpf_filter.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/bpf_filter.c --- bpf_zerocopy.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/bpf_zerocopy.c --- if_clone.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_clone.c --- if_dead.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_dead.c --- if_debug.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_debug.c --- if_ethersubr.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_ethersubr.c --- if_gif.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_gif.c --- if_loop.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_loop.c --- if_llatbl.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_llatbl.c --- if_media.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_media.c --- if_mib.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_mib.c --- if_tun.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_tun.c --- if_vlan.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/if_vlan.c --- pfil.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/pfil.c --- radix.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/radix.c --- radix_mpath.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/radix_mpath.c --- raw_cb.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/raw_cb.c --- raw_usrreq.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/raw_usrreq.c --- route.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/route.c --- rtsock.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/net/rtsock.c --- if_ether.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/if_ether.c --- igmp.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/igmp.c --- in.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/in.c --- in_debug.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/in_debug.c --- in_kdtrace.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/in_kdtrace.c --- in_gif.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/in_gif.c --- ip_id.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/ip_id.c --- in_mcast.o --- --- in_pcb.o --- --- in_mcast.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/in_mcast.c --- in_pcb.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/in_pcb.c --- in_proto.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/in_proto.c --- in_rmx.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/in_rmx.c --- ip_ecn.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/ip_ecn.c --- ip_encap.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/ip_encap.c --- ip_fastfwd.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/ip_fastfwd.c --- ip_icmp.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/ip_icmp.c --- ip_input.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/ip_input.c --- ip_ipsec.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/ip_ipsec.c --- ip_options.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/ip_options.c --- ip_output.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/ip_output.c --- ip_reass.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/ip_reass.c --- raw_ip.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/raw_ip.c --- cc.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/cc/cc.c --- cc_newreno.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/cc/cc_newreno.c --- sctp_asconf.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_asconf.c --- sctp_auth.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_auth.c --- sctp_bsd_addr.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_bsd_addr.c --- sctp_cc_functions.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_cc_functions.c --- sctp_crc32.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_crc32.c --- sctp_indata.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_indata.c --- sctp_input.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_input.c --- sctp_output.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_output.c --- sctp_pcb.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_pcb.c --- sctp_peeloff.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_peeloff.c --- sctp_ss_functions.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_ss_functions.c --- sctp_sysctl.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_sysctl.c --- sctp_timer.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_timer.c --- sctp_usrreq.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctp_usrreq.c --- sctputil.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/sctputil.c --- tcp_hostcache.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_hostcache.c --- tcp_input.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_input.c --- tcp_lro.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_lro.c --- tcp_output.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_output.c --- tcp_offload.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_offload.c --- tcp_reass.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_reass.c --- tcp_sack.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_sack.c --- tcp_subr.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_subr.c --- tcp_syncache.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_syncache.c --- tcp_timer.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_timer.c --- tcp_timewait.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_timewait.c --- tcp_usrreq.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_usrreq.c --- udp_usrreq.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet/udp_usrreq.c --- dest6.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet6/dest6.c --- frag6.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet6/frag6.c --- icmp6.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet6/icmp6.c --- in6.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet6/in6.c --- in6_cksum.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet6/in6_cksum.c --- in6.o --- /usr/src/sys/netinet6/in6.c:284:7: error: use of undeclared identifier 'SIOCGDRLST_IN6' case SIOCGDRLST_IN6: ^ /usr/src/sys/netinet6/in6.c:285:7: error: use of undeclared identifier 'SIOCGPRLST_IN6' case SIOCGPRLST_IN6: ^ --- in6_gif.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet6/in6_gif.c --- in6.o --- 2 errors generated. --- in6_ifattach.o --- --- in6.o --- *** [in6.o] Error code 1 make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC --- in6_ifattach.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mgeneral-regs-only -ffixed-x18 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -std=iso9899:1999 -Werror /usr/src/sys/netinet6/in6_ifattach.c 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/hudson3543401270653203233.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 rm: FreeBSD_HEAD_arm64/libexec/ld-elf32.so.1: Operation not permitted rm: FreeBSD_HEAD_arm64/libexec/ld-elf.so.1: Operation not permitted rm: FreeBSD_HEAD_arm64/libexec: Directory not empty rm: FreeBSD_HEAD_arm64/sbin/init: Operation not permitted rm: FreeBSD_HEAD_arm64/sbin: Directory not empty rm: FreeBSD_HEAD_arm64/lib/libcrypt.so.5: Operation not permitted rm: FreeBSD_HEAD_arm64/lib/libthr.so.3: Operation not permitted rm: FreeBSD_HEAD_arm64/lib/libc.so.7: Operation not permitted rm: FreeBSD_HEAD_arm64/lib: Directory not empty rm: FreeBSD_HEAD_arm64/usr/lib32/libthr.so.3: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/lib32/libcrypt.so.5: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/lib32/librt.so.1: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/lib32/libc.so.7: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/lib32: Directory not empty rm: FreeBSD_HEAD_arm64/usr/lib/librt.so.1: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/lib: Directory not empty rm: FreeBSD_HEAD_arm64/usr/bin/ypchsh: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/yppasswd: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/opieinfo: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/opiepasswd: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/ypchfn: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/passwd: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/crontab: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/su: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/chpass: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/chfn: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/login: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/ypchpass: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/chsh: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin: Directory not empty rm: FreeBSD_HEAD_arm64/usr: Directory not empty rm: FreeBSD_HEAD_arm64: Directory not empty + 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 Thu Sep 10 09:45:15 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 73F8B9C92C4 for ; Thu, 10 Sep 2015 09:45:15 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 3E39413E6 for ; Thu, 10 Sep 2015 09:45:15 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZZyPh-0002oU-FL for freebsd-arm@freebsd.org; Thu, 10 Sep 2015 10:45:06 +0100 Date: Thu, 10 Sep 2015 10:45:05 +0100 From: John To: freebsd-arm@freebsd.org Subject: X on RPI2 - which driver Message-ID: <20150910094505.GA23609@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John 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 Sep 2015 09:45:15 -0000 Hello list, Which xorg drivers work on the rpi2? X -configure just shows vesa however I've not installed dbus/hal yet. thanks, -- John From owner-freebsd-arm@freebsd.org Thu Sep 10 09:48:09 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 154F99C9454 for ; Thu, 10 Sep 2015 09:48:09 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D12C915FF for ; Thu, 10 Sep 2015 09:48:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D07321FE023 for ; Thu, 10 Sep 2015 11:48:06 +0200 (CEST) Subject: Re: X on RPI2 - which driver To: freebsd-arm@freebsd.org References: <20150910094505.GA23609@potato.growveg.org> From: Hans Petter Selasky Message-ID: <55F15232.3060401@selasky.org> Date: Thu, 10 Sep 2015 11:49:38 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150910094505.GA23609@potato.growveg.org> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Thu, 10 Sep 2015 09:48:09 -0000 On 09/10/15 11:45, John wrote: > Hello list, > > Which xorg drivers work on the rpi2? X -configure just shows vesa > however I've not installed dbus/hal yet. > > thanks, > I think you can use: xf86-video-scfb --HPS From owner-freebsd-arm@freebsd.org Thu Sep 10 10:40:47 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 57CD0A011D8 for ; Thu, 10 Sep 2015 10:40:47 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 1F5A21E1C for ; Thu, 10 Sep 2015 10:40:46 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZZzGr-000DFT-Rj for freebsd-arm@freebsd.org; Thu, 10 Sep 2015 11:40:29 +0100 Date: Thu, 10 Sep 2015 11:40:01 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: X on RPI2 - which driver Message-ID: <20150910104001.GB23609@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150910094505.GA23609@potato.growveg.org> <55F15232.3060401@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F15232.3060401@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John 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 Sep 2015 10:40:47 -0000 On Thu, Sep 10, 2015 at 11:49:38AM +0200, Hans Petter Selasky wrote: > On 09/10/15 11:45, John wrote: > > Hello list, > > > > Which xorg drivers work on the rpi2? X -configure just shows vesa > > however I've not installed dbus/hal yet. > > I think you can use: > > xf86-video-scfb Thanks for that, I'll try it when hal and friends finish installing. -- John From owner-freebsd-arm@freebsd.org Thu Sep 10 10:52:48 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 3966EA01804 for ; Thu, 10 Sep 2015 10:52:48 +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 2A6C91547; Thu, 10 Sep 2015 10:52:48 +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 30E727B7; Thu, 10 Sep 2015 10:52:48 +0000 (UTC) Date: Thu, 10 Sep 2015 10:52:44 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: hrs@FreeBSD.org, mav@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <358763725.101.1441882368161.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1685086160.95.1441875121967.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1685086160.95.1441875121967.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1098 - 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: Thu, 10 Sep 2015 10:52:48 -0000 FreeBSD_HEAD_arm64 - Build #1098 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1098/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1098/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1098/console Change summaries: 287618 by mav: Disable CTL_IO_DELAY feature. It is too developer-oriented to be enabled by default. 287617 by hrs: Remove SIOCGDRLST_IN6 and SIOCGPRLST_IN6 forgotten in the previous commit. MFC after: 3 days From owner-freebsd-arm@freebsd.org Thu Sep 10 08:51: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 F22BDA01308 for ; Thu, 10 Sep 2015 08:51:23 +0000 (UTC) (envelope-from zhaoshenglong@huawei.com) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by mx1.freebsd.org (Postfix) with ESMTP id D21511604 for ; Thu, 10 Sep 2015 08:51:20 +0000 (UTC) (envelope-from zhaoshenglong@huawei.com) Received: from 172.24.1.47 (EHLO SZXEML424-HUB.china.huawei.com) ([172.24.1.47]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSC71314; Thu, 10 Sep 2015 16:42:50 +0800 (CST) Received: from HGHY1Z002260041.china.huawei.com (10.177.16.142) by SZXEML424-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP Server id 14.3.235.1; Thu, 10 Sep 2015 16:42:33 +0800 From: Shannon Zhao To: , CC: , , , , , , , , , , , , , , , Subject: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Date: Thu, 10 Sep 2015 16:41:56 +0800 Message-ID: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> X-Mailer: git-send-email 1.9.0.msysgit.0 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.177.16.142] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 10 Sep 2015 11:14:02 +0000 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 Sep 2015 08:51:24 -0000 From: Shannon Zhao These EFI stub parameters are used to internal communication between EFI stub and Linux kernel and EFI stub creates these parameters. But for Xen on ARM when booting with UEFI, Xen will create a minimal DT providing these parameters for Dom0 and Dom0 is not only Linux kernel, but also other OS (such as FreeBSD) which will be used in the future. So here we plan to standardize the names by dropping the prefix "linux," and make them common to other OS. Also this will not break the compatibility since these parameters are used to internal communication between EFI stub and kernel. Signed-off-by: Shannon Zhao --- Look at [1] for the discussion about this in Xen ML. The purpose of this patch is to standardize the names to make Linux ARM kernel work on Xen with UEFI. Also it hopes other OS(e.g. FreeBSD), which will be used as Dom0 on Xen, could support this mechanism as well. [1]http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg02250.html Documentation/arm/uefi.txt | 10 +++++----- drivers/firmware/efi/efi.c | 10 +++++----- drivers/firmware/efi/libstub/fdt.c | 10 +++++----- 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt index d60030a..8c83243 100644 --- a/Documentation/arm/uefi.txt +++ b/Documentation/arm/uefi.txt @@ -45,18 +45,18 @@ following parameters: ________________________________________________________________________________ Name | Size | Description ================================================================================ -linux,uefi-system-table | 64-bit | Physical address of the UEFI System Table. +uefi-system-table | 64-bit | Physical address of the UEFI System Table. -------------------------------------------------------------------------------- -linux,uefi-mmap-start | 64-bit | Physical address of the UEFI memory map, +uefi-mmap-start | 64-bit | Physical address of the UEFI memory map, | | populated by the UEFI GetMemoryMap() call. -------------------------------------------------------------------------------- -linux,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map +uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map | | pointed to in previous entry. -------------------------------------------------------------------------------- -linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI +uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI | | memory map. -------------------------------------------------------------------------------- -linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. +uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. -------------------------------------------------------------------------------- linux,uefi-stub-kern-ver | string | Copy of linux_banner from build. -------------------------------------------------------------------------------- diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index d6144e3..3878715 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -481,11 +481,11 @@ static __initdata struct { int offset; int size; } dt_params[] = { - UEFI_PARAM("System Table", "linux,uefi-system-table", system_table), - UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap), - UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size), - UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size), - UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver) + UEFI_PARAM("System Table", "uefi-system-table", system_table), + UEFI_PARAM("MemMap Address", "uefi-mmap-start", mmap), + UEFI_PARAM("MemMap Size", "uefi-mmap-size", mmap_size), + UEFI_PARAM("MemMap Desc. Size", "uefi-mmap-desc-size", desc_size), + UEFI_PARAM("MemMap Desc. Version", "uefi-mmap-desc-ver", desc_ver) }; struct param_info { diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c index ef5d764..e94589a 100644 --- a/drivers/firmware/efi/libstub/fdt.c +++ b/drivers/firmware/efi/libstub/fdt.c @@ -118,31 +118,31 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt, /* Add FDT entries for EFI runtime services in chosen node. */ node = fdt_subnode_offset(fdt, 0, "chosen"); fdt_val64 = cpu_to_fdt64((u64)(unsigned long)sys_table); - status = fdt_setprop(fdt, node, "linux,uefi-system-table", + status = fdt_setprop(fdt, node, "uefi-system-table", &fdt_val64, sizeof(fdt_val64)); if (status) goto fdt_set_fail; fdt_val64 = cpu_to_fdt64((u64)(unsigned long)memory_map); - status = fdt_setprop(fdt, node, "linux,uefi-mmap-start", + status = fdt_setprop(fdt, node, "uefi-mmap-start", &fdt_val64, sizeof(fdt_val64)); if (status) goto fdt_set_fail; fdt_val32 = cpu_to_fdt32(map_size); - status = fdt_setprop(fdt, node, "linux,uefi-mmap-size", + status = fdt_setprop(fdt, node, "uefi-mmap-size", &fdt_val32, sizeof(fdt_val32)); if (status) goto fdt_set_fail; fdt_val32 = cpu_to_fdt32(desc_size); - status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-size", + status = fdt_setprop(fdt, node, "uefi-mmap-desc-size", &fdt_val32, sizeof(fdt_val32)); if (status) goto fdt_set_fail; fdt_val32 = cpu_to_fdt32(desc_ver); - status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-ver", + status = fdt_setprop(fdt, node, "uefi-mmap-desc-ver", &fdt_val32, sizeof(fdt_val32)); if (status) goto fdt_set_fail; -- 2.0.4 From owner-freebsd-arm@freebsd.org Thu Sep 10 09:59:20 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 5EDF19C99D2 for ; Thu, 10 Sep 2015 09:59:20 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mx1.freebsd.org (Postfix) with ESMTP id 4294D1AB8 for ; Thu, 10 Sep 2015 09:59:20 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7697175; Thu, 10 Sep 2015 02:52:36 -0700 (PDT) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D80283F21A; Thu, 10 Sep 2015 02:52:22 -0700 (PDT) Date: Thu, 10 Sep 2015 10:52:09 +0100 From: Mark Rutland To: Shannon Zhao Cc: "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "stefano.stabellini@eu.citrix.com" , "shannon.zhao@linaro.org" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150910095208.GA29293@leverpostej> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 10 Sep 2015 11:17:35 +0000 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 Sep 2015 09:59:20 -0000 Hi, I'm not necessarily opposed to the renaming, but I think that this is the least important thing to standardize for this to work. On Thu, Sep 10, 2015 at 09:41:56AM +0100, Shannon Zhao wrote: > From: Shannon Zhao > > These EFI stub parameters are used to internal communication between EFI > stub and Linux kernel and EFI stub creates these parameters. But for Xen > on ARM when booting with UEFI, Xen will create a minimal DT providing > these parameters for Dom0 and Dom0 is not only Linux kernel, but also > other OS (such as FreeBSD) which will be used in the future. Currently the Linux EFI stub and kernel have a symbiotic relationship, because they're intimately coupled and we don't have kexec (yet) on EFI platforms to loosen that coupling. If an agent other than the (kernel-specific) stub is going to provide this to the kernel, then we need more specified than just the property names. That at least includes the following: * The state of boot services (we currently have the EFI stub call ExitBootServices(), and I believe this is crucial to the plan for kexec). * The state of the address map (we currently have the EFI stub call SetVirtualAddressMap()). * The virtual address range(s) that SetVirtualAddressMap() may map elements to (this logic is currently in the EFI stub, and this matches the expectations of the kernel that it is tied to). > So here we plan to standardize the names by dropping the prefix > "linux," and make them common to other OS. Also this will not break > the compatibility since these parameters are used to internal > communication between EFI stub and kernel. For the moment this is true, but will not be once we have kexec, so there's a dependency (or anti-dependency) there. > Signed-off-by: Shannon Zhao > --- > Look at [1] for the discussion about this in Xen ML. The purpose of this > patch is to standardize the names to make Linux ARM kernel work on Xen > with UEFI. Also it hopes other OS(e.g. FreeBSD), which will be used as > Dom0 on Xen, could support this mechanism as well. > > [1]http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg02250.html Per this post, it looks like to pass a DTB to the kernel Xen already needs to know it's a Linux kernel... I wasn't aware that there was a common standard for arm(64) kernels other than a PE/COFF EFI application. Does Xen not talk to EFI itself and/or give the kernel a virtual EFI interface? Thanks, Mark. > Documentation/arm/uefi.txt | 10 +++++----- > drivers/firmware/efi/efi.c | 10 +++++----- > drivers/firmware/efi/libstub/fdt.c | 10 +++++----- > 3 files changed, 15 insertions(+), 15 deletions(-) > > diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt > index d60030a..8c83243 100644 > --- a/Documentation/arm/uefi.txt > +++ b/Documentation/arm/uefi.txt > @@ -45,18 +45,18 @@ following parameters: > ________________________________________________________________________________ > Name | Size | Description > ================================================================================ > -linux,uefi-system-table | 64-bit | Physical address of the UEFI System Table. > +uefi-system-table | 64-bit | Physical address of the UEFI System Table. > -------------------------------------------------------------------------------- > -linux,uefi-mmap-start | 64-bit | Physical address of the UEFI memory map, > +uefi-mmap-start | 64-bit | Physical address of the UEFI memory map, > | | populated by the UEFI GetMemoryMap() call. > -------------------------------------------------------------------------------- > -linux,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map > +uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map > | | pointed to in previous entry. > -------------------------------------------------------------------------------- > -linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI > +uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI > | | memory map. > -------------------------------------------------------------------------------- > -linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. > +uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. > -------------------------------------------------------------------------------- > linux,uefi-stub-kern-ver | string | Copy of linux_banner from build. > -------------------------------------------------------------------------------- > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > index d6144e3..3878715 100644 > --- a/drivers/firmware/efi/efi.c > +++ b/drivers/firmware/efi/efi.c > @@ -481,11 +481,11 @@ static __initdata struct { > int offset; > int size; > } dt_params[] = { > - UEFI_PARAM("System Table", "linux,uefi-system-table", system_table), > - UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap), > - UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size), > - UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size), > - UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver) > + UEFI_PARAM("System Table", "uefi-system-table", system_table), > + UEFI_PARAM("MemMap Address", "uefi-mmap-start", mmap), > + UEFI_PARAM("MemMap Size", "uefi-mmap-size", mmap_size), > + UEFI_PARAM("MemMap Desc. Size", "uefi-mmap-desc-size", desc_size), > + UEFI_PARAM("MemMap Desc. Version", "uefi-mmap-desc-ver", desc_ver) > }; > > struct param_info { > diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c > index ef5d764..e94589a 100644 > --- a/drivers/firmware/efi/libstub/fdt.c > +++ b/drivers/firmware/efi/libstub/fdt.c > @@ -118,31 +118,31 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt, > /* Add FDT entries for EFI runtime services in chosen node. */ > node = fdt_subnode_offset(fdt, 0, "chosen"); > fdt_val64 = cpu_to_fdt64((u64)(unsigned long)sys_table); > - status = fdt_setprop(fdt, node, "linux,uefi-system-table", > + status = fdt_setprop(fdt, node, "uefi-system-table", > &fdt_val64, sizeof(fdt_val64)); > if (status) > goto fdt_set_fail; > > fdt_val64 = cpu_to_fdt64((u64)(unsigned long)memory_map); > - status = fdt_setprop(fdt, node, "linux,uefi-mmap-start", > + status = fdt_setprop(fdt, node, "uefi-mmap-start", > &fdt_val64, sizeof(fdt_val64)); > if (status) > goto fdt_set_fail; > > fdt_val32 = cpu_to_fdt32(map_size); > - status = fdt_setprop(fdt, node, "linux,uefi-mmap-size", > + status = fdt_setprop(fdt, node, "uefi-mmap-size", > &fdt_val32, sizeof(fdt_val32)); > if (status) > goto fdt_set_fail; > > fdt_val32 = cpu_to_fdt32(desc_size); > - status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-size", > + status = fdt_setprop(fdt, node, "uefi-mmap-desc-size", > &fdt_val32, sizeof(fdt_val32)); > if (status) > goto fdt_set_fail; > > fdt_val32 = cpu_to_fdt32(desc_ver); > - status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-ver", > + status = fdt_setprop(fdt, node, "uefi-mmap-desc-ver", > &fdt_val32, sizeof(fdt_val32)); > if (status) > goto fdt_set_fail; > -- > 2.0.4 > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > From owner-freebsd-arm@freebsd.org Thu Sep 10 10:21: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 D451CA00724 for ; Thu, 10 Sep 2015 10:21:58 +0000 (UTC) (envelope-from prvs=68895f1e6=Stefano.Stabellini@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 813EA1382 for ; Thu, 10 Sep 2015 10:21:58 +0000 (UTC) (envelope-from prvs=68895f1e6=Stefano.Stabellini@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,504,1437436800"; d="scan'208";a="302651193" Date: Thu, 10 Sep 2015 11:19:51 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mark Rutland CC: Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "stefano.stabellini@eu.citrix.com" , "shannon.zhao@linaro.org" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters In-Reply-To: <20150910095208.GA29293@leverpostej> Message-ID: References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA1 X-Mailman-Approved-At: Thu, 10 Sep 2015 11:19:34 +0000 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 Sep 2015 10:21:59 -0000 On Thu, 10 Sep 2015, Mark Rutland wrote: > Hi, > > I'm not necessarily opposed to the renaming, but I think that this is > the least important thing to standardize for this to work. > > On Thu, Sep 10, 2015 at 09:41:56AM +0100, Shannon Zhao wrote: > > From: Shannon Zhao > > > > These EFI stub parameters are used to internal communication between EFI > > stub and Linux kernel and EFI stub creates these parameters. But for Xen > > on ARM when booting with UEFI, Xen will create a minimal DT providing > > these parameters for Dom0 and Dom0 is not only Linux kernel, but also > > other OS (such as FreeBSD) which will be used in the future. > > Currently the Linux EFI stub and kernel have a symbiotic relationship, > because they're intimately coupled and we don't have kexec (yet) on EFI > platforms to loosen that coupling. > > If an agent other than the (kernel-specific) stub is going to provide > this to the kernel, then we need more specified than just the property > names. > > That at least includes the following: > > * The state of boot services (we currently have the EFI stub call > ExitBootServices(), and I believe this is crucial to the plan for > kexec). > > * The state of the address map (we currently have the EFI stub call > SetVirtualAddressMap()). > > * The virtual address range(s) that SetVirtualAddressMap() may map > elements to (this logic is currently in the EFI stub, and this matches > the expectations of the kernel that it is tied to). > > > So here we plan to standardize the names by dropping the prefix > > "linux," and make them common to other OS. Also this will not break > > the compatibility since these parameters are used to internal > > communication between EFI stub and kernel. > > For the moment this is true, but will not be once we have kexec, so > there's a dependency (or anti-dependency) there. > > > Signed-off-by: Shannon Zhao > > --- > > Look at [1] for the discussion about this in Xen ML. The purpose of this > > patch is to standardize the names to make Linux ARM kernel work on Xen > > with UEFI. Also it hopes other OS(e.g. FreeBSD), which will be used as > > Dom0 on Xen, could support this mechanism as well. > > > > [1]http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg02250.html > > Per this post, it looks like to pass a DTB to the kernel Xen already > needs to know it's a Linux kernel... > > I wasn't aware that there was a common standard for arm(64) kernels > other than a PE/COFF EFI application. > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > interface? Xen talks to EFI itself but the interface provided to dom0 is somewhat different: there are no BootServices (Xen calls ExitBootServices before running the kernel), and the RuntimeServices go via hypercalls (see drivers/xen/efi.c). From owner-freebsd-arm@freebsd.org Thu Sep 10 11:24: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 A0BE1A009ED for ; Thu, 10 Sep 2015 11:24:33 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mx1.freebsd.org (Postfix) with ESMTP id 8494C1610 for ; Thu, 10 Sep 2015 11:24:33 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 11579317; Thu, 10 Sep 2015 04:24:43 -0700 (PDT) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 646963F317; Thu, 10 Sep 2015 04:24:29 -0700 (PDT) Date: Thu, 10 Sep 2015 12:24:19 +0100 From: Mark Rutland To: Stefano Stabellini Cc: Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150910112418.GC29293@leverpostej> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 10 Sep 2015 11:36:48 +0000 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 Sep 2015 11:24:33 -0000 > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > interface? > > Xen talks to EFI itself but the interface provided to dom0 is somewhat > different: there are no BootServices (Xen calls ExitBootServices before > running the kernel), and the RuntimeServices go via hypercalls (see > drivers/xen/efi.c). That's somewhat hideous; a non Xen-aware OS wouild presumably die if trying to use any runtime services the normal way? I'm not keen on describing things that the OS cannot use. Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. create pages of RuntimeServicesCode that are trivial assembly shims doing hypercalls, and plumb these into the virtual EFI memory map and tables? That would keep things sane for any guest, allow for easy addition of EFI features, and you could even enter the usual EFI entry point, simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest to make things sane for itself... Mark. From owner-freebsd-arm@freebsd.org Thu Sep 10 11:32:55 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 A9EFEA00F23 for ; Thu, 10 Sep 2015 11:32:55 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id 74DDC1B0B for ; Thu, 10 Sep 2015 11:32:55 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from bender.Home (bcdc6507.skybroadband.com [188.220.101.7]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 5FB8DD7F66; Thu, 10 Sep 2015 11:32:53 +0000 (UTC) Date: Thu, 10 Sep 2015 12:32:51 +0100 From: Andrew Turner To: Shannon Zhao Cc: , , linux-efi@vger.kernel.org, ian.campbell@citrix.com, linux-doc@vger.kernel.org, ard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org, leif.lindholm@linaro.org, xen-devel@lists.xen.org, julien.grall@citrix.com, freebsd-arm@freebsd.org, matt.fleming@intel.com, christoffer.dall@linaro.org, jbeulich@suse.com, peter.huangpeng@huawei.com, stefano.stabellini@eu.citrix.com, shannon.zhao@linaro.org Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150910123251.7e0810d1@bender.Home> In-Reply-To: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 10 Sep 2015 11:46:14 +0000 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 Sep 2015 11:32:55 -0000 On Thu, 10 Sep 2015 16:41:56 +0800 Shannon Zhao wrote: > From: Shannon Zhao > > These EFI stub parameters are used to internal communication between > EFI stub and Linux kernel and EFI stub creates these parameters. But > for Xen on ARM when booting with UEFI, Xen will create a minimal DT > providing these parameters for Dom0 and Dom0 is not only Linux > kernel, but also other OS (such as FreeBSD) which will be used in the > future. So here we plan to standardize the names by dropping the > prefix "linux," and make them common to other OS. Also this will not > break the compatibility since these parameters are used to internal > communication between EFI stub and kernel. It is unlikely FreeBSD will use this property when booting ad Xen dom0. The kernel expects to be passed a data structure to find boot this information. My preference would be to have the FreeBSD loader load the xen binary, the FreeBSD kernel, and set up these data structs before passing control to Xen, with the information it needs to boot the kernel. My understanding is this is how it is done on x86. I can see a few issues with this where, for example, the device tree or ACPI tables need to be modified, but these should be solvable. Andrew From owner-freebsd-arm@freebsd.org Thu Sep 10 11:40:04 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 5D085A012F8 for ; Thu, 10 Sep 2015 11:40:04 +0000 (UTC) (envelope-from prvs=68895f1e6=Stefano.Stabellini@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 083C51CB8 for ; Thu, 10 Sep 2015 11:40:03 +0000 (UTC) (envelope-from prvs=68895f1e6=Stefano.Stabellini@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,504,1437436800"; d="scan'208";a="299136041" Date: Thu, 10 Sep 2015 12:37:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mark Rutland CC: Stefano Stabellini , Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk , Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters In-Reply-To: <20150910112418.GC29293@leverpostej> Message-ID: References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA2 X-Mailman-Approved-At: Thu, 10 Sep 2015 11:46:29 +0000 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 Sep 2015 11:40:04 -0000 On Thu, 10 Sep 2015, Mark Rutland wrote: > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > > interface? > > > > Xen talks to EFI itself but the interface provided to dom0 is somewhat > > different: there are no BootServices (Xen calls ExitBootServices before > > running the kernel), and the RuntimeServices go via hypercalls (see > > drivers/xen/efi.c). > > That's somewhat hideous; a non Xen-aware OS wouild presumably die if > trying to use any runtime services the normal way? I'm not keen on > describing things that the OS cannot use. I agree that is somewhat hideous, but a non-Xen aware OS traditionally has never been able to even boot as Dom0. On ARM it can, but it still wouldn't be very useful (one couldn't use it to start other guests). > Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. > create pages of RuntimeServicesCode that are trivial assembly shims > doing hypercalls, and plumb these into the virtual EFI memory map and > tables? > > That would keep things sane for any guest, allow for easy addition of > EFI features, and you could even enter the usual EFI entry point, > simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest > to make things sane for itself... That's the way it was done on x86 and now we have common code both in Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this scheme. Switching to a different solution for ARM, would mean diverging with x86, which is not nice, or reimplementing the x86 solution too, which is expensive. BTW I think that the idea you proposed was actually considered at the time and deemed hard to implement, if I recall correctly. In any case this should be separate from the shim ABI discussion. From owner-freebsd-arm@freebsd.org Thu Sep 10 11:49: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 C8CBBA017B1 for ; Thu, 10 Sep 2015 11:49:17 +0000 (UTC) (envelope-from prvs=688ae54f7=julien.grall@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61E261270 for ; Thu, 10 Sep 2015 11:49:17 +0000 (UTC) (envelope-from prvs=688ae54f7=julien.grall@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,504,1437436800"; d="scan'208";a="299137752" Message-ID: <55F16DF5.1080705@citrix.com> Date: Thu, 10 Sep 2015 12:48:05 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Andrew Turner , Shannon Zhao CC: , , , , , , , , , , , , , , , , Roger Pau Monne Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910123251.7e0810d1@bender.Home> In-Reply-To: <20150910123251.7e0810d1@bender.Home> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA2 X-Mailman-Approved-At: Thu, 10 Sep 2015 12:18:59 +0000 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 Sep 2015 11:49:17 -0000 On 10/09/15 12:32, Andrew Turner wrote: > On Thu, 10 Sep 2015 16:41:56 +0800 > Shannon Zhao wrote: > >> From: Shannon Zhao >> >> These EFI stub parameters are used to internal communication between >> EFI stub and Linux kernel and EFI stub creates these parameters. But >> for Xen on ARM when booting with UEFI, Xen will create a minimal DT >> providing these parameters for Dom0 and Dom0 is not only Linux >> kernel, but also other OS (such as FreeBSD) which will be used in the >> future. So here we plan to standardize the names by dropping the >> prefix "linux," and make them common to other OS. Also this will not >> break the compatibility since these parameters are used to internal >> communication between EFI stub and kernel. > > It is unlikely FreeBSD will use this property when booting ad Xen dom0. > The kernel expects to be passed a data structure to find boot this > information. > > My preference would be to have the FreeBSD loader load the xen binary, > the FreeBSD kernel, and set up these data structs before passing > control to Xen, with the information it needs to boot the kernel. My > understanding is this is how it is done on x86. Well, AFAICT, there is no FreeBSD specific code in Xen for x86. We are faking a multiboot module which contains all the informations. I know that the bootloader is at least involved, I don't remember if there is some code in FreeBSD to read this boot module. I've CCed Roger to confirm. > I can see a few issues with this where, for example, the device tree or > ACPI tables need to be modified, but these should be solvable. Xen has to modify the firmware table in order to remove everything that it's used by itself (UART, virtual GIC...). So we would need to modify the FreeBSD data structure to pass the new DT/ACPI. Does the metadata are standardize? I.e is it stable from accross FreeBSD version? Anyway, I'd like to avoid any FreeBSD specific code in Xen, and even any OS specific code in Xen. It's better if we keep a common interface for everyone. Regards, -- Julien Grall From owner-freebsd-arm@freebsd.org Thu Sep 10 12:06: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 B617C9CC597 for ; Thu, 10 Sep 2015 12:06:33 +0000 (UTC) (envelope-from prvs=688746ca2=roger.pau@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4859B1D0F for ; Thu, 10 Sep 2015 12:06:32 +0000 (UTC) (envelope-from prvs=688746ca2=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,504,1437436800"; d="scan'208";a="299141539" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters To: Julien Grall , Andrew Turner , Shannon Zhao References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910123251.7e0810d1@bender.Home> <55F16DF5.1080705@citrix.com> CC: , , , , , , , , , , , , , , , From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= X-Enigmail-Draft-Status: N1110 Message-ID: <55F1721D.1010801@citrix.com> Date: Thu, 10 Sep 2015 14:05:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F16DF5.1080705@citrix.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA2 X-Mailman-Approved-At: Thu, 10 Sep 2015 13:08:18 +0000 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 Sep 2015 12:06:33 -0000 El 10/09/15 a les 13.48, Julien Grall ha escrit: > On 10/09/15 12:32, Andrew Turner wrote: >> On Thu, 10 Sep 2015 16:41:56 +0800 >> Shannon Zhao wrote: >> >>> From: Shannon Zhao >>> >>> These EFI stub parameters are used to internal communication between >>> EFI stub and Linux kernel and EFI stub creates these parameters. But >>> for Xen on ARM when booting with UEFI, Xen will create a minimal DT >>> providing these parameters for Dom0 and Dom0 is not only Linux >>> kernel, but also other OS (such as FreeBSD) which will be used in the >>> future. So here we plan to standardize the names by dropping the >>> prefix "linux," and make them common to other OS. Also this will not >>> break the compatibility since these parameters are used to internal >>> communication between EFI stub and kernel. >> >> It is unlikely FreeBSD will use this property when booting ad Xen dom0. >> The kernel expects to be passed a data structure to find boot this >> information. >> >> My preference would be to have the FreeBSD loader load the xen binary, >> the FreeBSD kernel, and set up these data structs before passing >> control to Xen, with the information it needs to boot the kernel. My >> understanding is this is how it is done on x86. > > Well, AFAICT, there is no FreeBSD specific code in Xen for x86. We are > faking a multiboot module which contains all the informations. > > I know that the bootloader is at least involved, I don't remember if > there is some code in FreeBSD to read this boot module. I've CCed Roger > to confirm. The metadata/modules needed by the FreeBSD Dom0 kernel is generated by the native FreeBSD bootloader (as would be done when booting bare metal). Then this blob is passed as a multiboot module in the same place that Linux puts it's initramfs. Xen simply copies this blob straight into guest memory and sets start_info.mod_start to point to the start memory address of this blob. I've done it this way because I don't see many other options. Xen is tailored for Linux and only allows passing one module to the Dom0 kernel (initramfs). For FreeBSD it would be good to be able to pass at least two modules to the Dom0 kernel, one containing the metadata, and the other one containing the modules themselves. The new PVH work (HVMlite or whatever) will hopefully allow passing more than one module to the Dom0 kernel, and should make the code in the FreeBSD loader simpler. Roger. From owner-freebsd-arm@freebsd.org Thu Sep 10 12:15:28 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 ACE799CCA68 for ; Thu, 10 Sep 2015 12:15:28 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mx1.freebsd.org (Postfix) with ESMTP id 8E10A1040 for ; Thu, 10 Sep 2015 12:15:28 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DE33A75; Thu, 10 Sep 2015 05:15:38 -0700 (PDT) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E3A163F317; Thu, 10 Sep 2015 05:15:24 -0700 (PDT) Date: Thu, 10 Sep 2015 13:15:14 +0100 From: Mark Rutland To: Stefano Stabellini Cc: Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk , "daniel.kiper@oracle.com" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150910121514.GE29293@leverpostej> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 10 Sep 2015 13:08:33 +0000 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 Sep 2015 12:15:28 -0000 On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > > > interface? > > > > > > Xen talks to EFI itself but the interface provided to dom0 is somewhat > > > different: there are no BootServices (Xen calls ExitBootServices before > > > running the kernel), and the RuntimeServices go via hypercalls (see > > > drivers/xen/efi.c). > > > > That's somewhat hideous; a non Xen-aware OS wouild presumably die if > > trying to use any runtime services the normal way? I'm not keen on > > describing things that the OS cannot use. > > I agree that is somewhat hideous, but a non-Xen aware OS traditionally > has never been able to even boot as Dom0. On ARM it can, but it still > wouldn't be very useful (one couldn't use it to start other guests). Sure, but it feels odd to provide the usual information in this manner if it cannot be used. If you require Xen-specific code to make things work, I would imagine this information could be dciscovered in a Xen-specific manner. > > Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. > > create pages of RuntimeServicesCode that are trivial assembly shims > > doing hypercalls, and plumb these into the virtual EFI memory map and > > tables? > > > > That would keep things sane for any guest, allow for easy addition of > > EFI features, and you could even enter the usual EFI entry point, > > simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest > > to make things sane for itself... > > That's the way it was done on x86 and now we have common code both in > Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this > scheme. This code is not currently used on arm. It might live in a location where it may be shared, but that doesn't mean that it's common code yet. > Switching to a different solution for ARM, would mean diverging > with x86, which is not nice, or reimplementing the x86 solution too, > which is expensive. > > BTW I think that the idea you proposed was actually considered at the > time and deemed hard to implement, if I recall correctly. I appreciate that divergence is painful. We already diverge in other respects (e.g. lack of PV page tables) because things that used to be the case on x86 never applied to ARM. It would be interesting to see why that was the case for x86, and whether that applies to ARM. > In any case this should be separate from the shim ABI discussion. I disagree; I think this is very much relevant to the ABI discussion. That's not to say that I insist on a particular approach, but I think that they need to be considered together. Thanks, Mark. From owner-freebsd-arm@freebsd.org Thu Sep 10 12:58: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 4D066A01BE0 for ; Thu, 10 Sep 2015 12:58:29 +0000 (UTC) (envelope-from prvs=688ac6705=Ian.Campbell@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED07D1C40 for ; Thu, 10 Sep 2015 12:58:28 +0000 (UTC) (envelope-from prvs=688ac6705=Ian.Campbell@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,504,1437436800"; d="scan'208";a="299154478" Message-ID: <1441889905.24450.382.camel@citrix.com> Subject: Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters From: Ian Campbell To: Mark Rutland , Stefano Stabellini CC: "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-doc@vger.kernel.org" , "daniel.kiper@oracle.com" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , Shannon Zhao , "peter.huangpeng@huawei.com" , "linux-arm-kernel@lists.infradead.org" , "shannon.zhao@linaro.org" Date: Thu, 10 Sep 2015 13:58:25 +0100 In-Reply-To: <20150910121514.GE29293@leverpostej> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-Mailman-Approved-At: Thu, 10 Sep 2015 13:17:02 +0000 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 Sep 2015 12:58:29 -0000 On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote: > > In any case this should be separate from the shim ABI discussion. > > I disagree; I think this is very much relevant to the ABI discussion. > That's not to say that I insist on a particular approach, but I think > that they need to be considered together. Taking a step back, the reason for using the EFI stub parameters is only (AFAIK) in order to be able to locate the ACPI RDSP (the root table pointer), which as it happens is normally passed via one of the EFI firmware tables. If there was a way to achieve that goal (i.e. another way to find the RSDP) without opening the can of UEFI worms then we could consider that opiton too. a way != the legacy x86 thing of scanning low memory of the signature, of course. Ian. From owner-freebsd-arm@freebsd.org Thu Sep 10 13:08:54 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 6DC9EA0010F for ; Thu, 10 Sep 2015 13:08:54 +0000 (UTC) (envelope-from JBeulich@suse.com) Received: from prv-mh.provo.novell.com (prv-mh.provo.novell.com [137.65.248.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.provo.novell.com", Issuer "DigiCert SHA2 High Assurance Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D67410AD for ; Thu, 10 Sep 2015 13:08:53 +0000 (UTC) (envelope-from JBeulich@suse.com) Received: from INET-PRV-MTA by prv-mh.provo.novell.com with Novell_GroupWise; Thu, 10 Sep 2015 07:08:52 -0600 Message-Id: <55F19D0202000078000A1B54@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.0.1 Date: Thu, 10 Sep 2015 07:08:50 -0600 From: "Jan Beulich" To: "Ian Campbell" Cc: "Mark Rutland" , "julien.grall@citrix.com" , "Stefano Stabellini" , "freebsd-arm@freebsd.org" , "peter.huangpeng@huawei.com" , "Shannon Zhao" , "matt.fleming@intel.com" , "ard.biesheuvel@linaro.org" , "christoffer.dall@linaro.org" , "leif.lindholm@linaro.org" , "shannon.zhao@linaro.org" , "linux-arm-kernel@lists.infradead.org" , "xen-devel@lists.xen.org" , "daniel.kiper@oracle.com" , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <1441889905.24450.382.camel@citrix.com> In-Reply-To: <1441889905.24450.382.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Thu, 10 Sep 2015 13:17:40 +0000 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 Sep 2015 13:08:54 -0000 >>> On 10.09.15 at 14:58, wrote: > On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote: >=20 >> > In any case this should be separate from the shim ABI discussion. >>=20 >> I disagree; I think this is very much relevant to the ABI discussion. >> That's not to say that I insist on a particular approach, but I think >> that they need to be considered together. >=20 > Taking a step back, the reason for using the EFI stub parameters is only > (AFAIK) in order to be able to locate the ACPI RDSP (the root table > pointer), which as it happens is normally passed via one of the EFI > firmware tables. >=20 > If there was a way to achieve that goal (i.e. another way to find the = RSDP) > without opening the can of UEFI worms then we could consider that opiton > too. >=20 > a way !=3D the legacy x86 thing of scanning low memory of the signature, = of > course. But even x86 doesn't do that (other than as a fallback) on EFI. The configuration table is available to Dom0 (via XENPF_firmware_info: XEN_FW_EFI_INFO:XEN_FW_EFI_CONFIG_TABLE). Jan From owner-freebsd-arm@freebsd.org Thu Sep 10 14:47: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 7D95DA012EA for ; Thu, 10 Sep 2015 14:47:33 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 376341006 for ; Thu, 10 Sep 2015 14:47:33 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1Za38C-0002e8-0F for freebsd-arm@freebsd.org; Thu, 10 Sep 2015 15:47:23 +0100 Date: Thu, 10 Sep 2015 15:47:19 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: X on RPI2 - which driver Message-ID: <20150910144719.GC23609@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150910094505.GA23609@potato.growveg.org> <55F15232.3060401@selasky.org> <20150910104001.GB23609@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910104001.GB23609@potato.growveg.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John 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 Sep 2015 14:47:33 -0000 On Thu, Sep 10, 2015 at 11:40:01AM +0100, John wrote: > On Thu, Sep 10, 2015 at 11:49:38AM +0200, Hans Petter Selasky wrote: > > On 09/10/15 11:45, John wrote: > > > Hello list, > > > > > > Which xorg drivers work on the rpi2? X -configure just shows vesa > > > however I've not installed dbus/hal yet. > > > > I think you can use: > > > > xf86-video-scfb > > Thanks for that, I'll try it when hal and friends finish installing. No dice, I get the following from X -configure root@potato:~ # X -configure X.Org X Server 1.14.7 Release Date: 2014-06-05 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 11.0-CURRENT arm Current Operating System: FreeBSD potato.growveg.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r286947: Wed Aug 19 18:04:27 MDT 2015 brd@hive.den.so14k.com:/usr/local/raspbsd /obj/RPI2/obj/arm.armv6/usr/local/raspbsd/src/RPI2/sys/RPI2 arm Build Date: 09 September 2015 09:44:10PM Current version of pixman: 0.32.6 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 10 15:36:17 2015 List of video drivers: scfb fbdev vesa scfb trace: probe start No devices to configure. Configuration failed. (EE) Server terminated with error (2). Closing log file. I'm not sure where to start given it didn't even write a config! thanks, -- John From owner-freebsd-arm@freebsd.org Thu Sep 10 14:52: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 8DB70A015E9 for ; Thu, 10 Sep 2015 14:52:16 +0000 (UTC) (envelope-from hp@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 54755148D for ; Thu, 10 Sep 2015 14:52:16 +0000 (UTC) (envelope-from hp@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0B1D61FE023 for ; Thu, 10 Sep 2015 16:52:14 +0200 (CEST) Subject: Re: X on RPI2 - which driver To: freebsd-arm@freebsd.org References: <20150910094505.GA23609@potato.growveg.org> <55F15232.3060401@selasky.org> <20150910104001.GB23609@potato.growveg.org> <20150910144719.GC23609@potato.growveg.org> From: Hans Petter Selasky Message-ID: <55F19978.6040105@selasky.org> Date: Thu, 10 Sep 2015 16:53:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150910144719.GC23609@potato.growveg.org> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Thu, 10 Sep 2015 14:52:16 -0000 On 09/10/15 16:47, John wrote: > On Thu, Sep 10, 2015 at 11:40:01AM +0100, John wrote: >> On Thu, Sep 10, 2015 at 11:49:38AM +0200, Hans Petter Selasky wrote: >>> On 09/10/15 11:45, John wrote: >>>> Hello list, >>>> >>>> Which xorg drivers work on the rpi2? X -configure just shows vesa >>>> however I've not installed dbus/hal yet. >>> >>> I think you can use: >>> >>> xf86-video-scfb >> >> Thanks for that, I'll try it when hal and friends finish installing. > > No dice, I get the following from X -configure > > root@potato:~ # X -configure > > X.Org X Server 1.14.7 > Release Date: 2014-06-05 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 11.0-CURRENT arm > Current Operating System: FreeBSD potato.growveg.org 11.0-CURRENT FreeBSD 11.0-CURRENT > #0 r286947: Wed Aug 19 18:04:27 MDT 2015 brd@hive.den.so14k.com:/usr/local/raspbsd > /obj/RPI2/obj/arm.armv6/usr/local/raspbsd/src/RPI2/sys/RPI2 arm > > Build Date: 09 September 2015 09:44:10PM > > Current version of pixman: 0.32.6 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 10 15:36:17 2015 > List of video drivers: > scfb > fbdev > vesa > scfb trace: probe start > No devices to configure. Configuration failed. > (EE) Server terminated with error (2). Closing log file. > > I'm not sure where to start given it didn't even write a config! > Hi, You need a manual X.org config. Try searching the web. --HPS From owner-freebsd-arm@freebsd.org Thu Sep 10 15:51: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 16FB0A014CF for ; Thu, 10 Sep 2015 15:51:03 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A71A31589 for ; Thu, 10 Sep 2015 15:51:02 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1441900256; l=3893; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:To:From:Date; bh=DfYZ9/lMZ4QSevaZzaxPQcwdsm0/EUVbgAxpp56m5j0=; b=uEUI1jUIaNlQ0ISC0+rYPvpgBJVxYZ4TOc7lif5wl8UHs72jZ4tEv4VxNilsDRxi2pc MULwqfd5m0mO/iMfwLRdCldH4z2kmh5DDnNjNscNMBnOcfbJjvIUTmWgiCbxed7y+V51l okNHDjvnUBkpBVm6JRTtTlmTnFLlAJaZYwM= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg47usv9Eg== X-RZG-CLASS-ID: mo00 Received: from quad (p54868403.dip0.t-ipconnect.de [84.134.132.3]) by smtp.strato.de (RZmta 37.11 DYNA|AUTH) with ESMTPSA id 6008e6r8AFotouH (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 10 Sep 2015 17:50:55 +0200 (CEST) Date: Thu, 10 Sep 2015 15:50:54 +0000 From: Ulrich Grey To: freebsd-arm@freebsd.org Subject: Re: X on RPI2 - which driver Message-Id: <20150910155054.a200ea1e98ce408d98742d2a@ulrich-grey.de> In-Reply-To: <20150910144719.GC23609@potato.growveg.org> References: <20150910094505.GA23609@potato.growveg.org> <55F15232.3060401@selasky.org> <20150910104001.GB23609@potato.growveg.org> <20150910144719.GC23609@potato.growveg.org> Organization: - X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; armv6-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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 Sep 2015 15:51:03 -0000 On Thu, 10 Sep 2015 15:47:19 +0100 John wrote: > On Thu, Sep 10, 2015 at 11:40:01AM +0100, John wrote: > > On Thu, Sep 10, 2015 at 11:49:38AM +0200, Hans Petter Selasky wrote: > > > On 09/10/15 11:45, John wrote: > > > > Hello list, > > > > > > > > Which xorg drivers work on the rpi2? X -configure just shows vesa > > > > however I've not installed dbus/hal yet. > > > > > > I think you can use: > > > > > > xf86-video-scfb > > > > Thanks for that, I'll try it when hal and friends finish installing. > > No dice, I get the following from X -configure > > root@potato:~ # X > -configure > X.Org X Server > 1.14.7 Release Date: > 2014-06-05 X Protocol Version 11, Revision > 0 Build Operating System: FreeBSD 11.0-CURRENT > arm Current Operating System: FreeBSD potato.growveg.org 11.0-CURRENT FreeBSD > 11.0-CURRENT > #0 r286947: Wed Aug 19 18:04:27 MDT 2015 brd@hive.den.so14k.com:/usr/local/raspbsd > /obj/RPI2/obj/arm.armv6/usr/local/raspbsd/src/RPI2/sys/RPI2 arm > > Build Date: 09 September 2015 > 09:44:10PM > Current version of pixman: > 0.32.6 Before reporting problems, check > http://wiki.x.org to make sure that you have the latest > version. Markers: (--) probed, (**) from config file, (==) default > setting, (++) from command line, (!!) notice, (II) > informational, (WW) warning, (EE) error, (NI) not implemented, (??) > unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 10 15:36:17 > 2015 List of video > drivers: > scfb > fbdev > vesa scfb trace: probe > start No devices to configure. Configuration > failed. (EE) Server terminated with error (2). Closing log file. > > I'm not sure where to start given it didn't even write a config! > > thanks, > -- > John > _______________________________________________ > 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" A working /etc/xorg.conf on ARM: Section "Files" FontPath "/usr/local/share/fonts/75dpi/" FontPath "/usr/local/share/fonts/100dpi/" FontPath "/usr/local/share/fonts/dejavu/" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/share/fonts/misc/" FontPath "/usr/local/share/fonts/TTF/" FontPath "/usr/local/share/fonts/OTF/" FontPath "/usr/local/share/fonts/Type1/" FontPath "/usr/local/share/fonts/Droid/" FontPath "/usr/local/share/fonts/Lohit/" EndSection Section "Module" Load "dbe" Disable "dri" Disable "dri2" Disable "glx" Load "freetype" SubSection "extmod" Option "omit xfree86-dga" EndSubSection EndSection Section "ServerFlags" Option "AIGLX" "false" Option "NoAccel" "True" Option "NoDRI" "True" Option "DRI" "False" Option "DRI2" "False" Option "DontZap" "false" Option "BlankTime" "1" EndSection Section "InputDevice" Identifier "Keyboard1" Driver "kbd" Option "XkbLayout" "de" # ? Option "ZAxisMapping" "4 5" #Rad an Maus Option "XkbVariant" "nodeadkeys" #? Option "XkbModel" "pc105" #? Option "XkbRules" "xorg" # Option "XkbCompat" "" EndSection Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" EndSection Section "Monitor" Identifier "Monitor" Option "DPMS" "true" EndSection Section "Device" Identifier "Generic FB" Driver "scfb" Option "NoAccel" "True" # Option "ShadowFB" "False" # EndSection Section "Screen" Identifier "Screen" Device "Generic FB" Monitor "Monitor" SubSection "Display" Depth 16 EndSubsection EndSection Section "ServerLayout" Identifier "layout" Screen 0 "Screen" 0 0 InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" Option "AutoAddDevices" "false" # Stellt altes Verhalten wieder her!! EndSection From owner-freebsd-arm@freebsd.org Thu Sep 10 15:56: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 9399FA01702 for ; Thu, 10 Sep 2015 15:56:58 +0000 (UTC) (envelope-from carlj@peak.org) Received: from filter01.peakinternet.com (filter01.peakinternet.com [207.55.16.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6DA2C1ACC for ; Thu, 10 Sep 2015 15:56:58 +0000 (UTC) (envelope-from carlj@peak.org) Received: from zmail-mta02.peak.org ([207.55.16.112]) by filter01.peakinternet.com ({e1c81c21-e4c4-4528-aa90-7a27869c545a}) via TCP (outbound) with ESMTPS id 20150910155651383_0000 for ; Thu, 10 Sep 2015 08:56:51 -0700 X-RC-FROM: X-RC-RCPT: Received: from zmail-mta02.peak.org (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTPS id 5745A4D8C7 for ; Thu, 10 Sep 2015 08:56:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTP id 3DB354D81B for ; Thu, 10 Sep 2015 08:56:50 -0700 (PDT) Received: from zmail-mta02.peak.org ([127.0.0.1]) by localhost (zmail-mta02.peak.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EjWHcbxCWcQn for ; Thu, 10 Sep 2015 08:56:50 -0700 (PDT) Received: from mailproxy-lb-05.peak.org (mailproxy-lb-05.peak.org [207.55.17.95]) by zmail-mta02.peak.org (Postfix) with ESMTP id 0D5134D5E7 for ; Thu, 10 Sep 2015 08:56:49 -0700 (PDT) Received: from carlj by elk.localnet with local (Exim 4.80) (envelope-from ) id 1Za4DR-0003cD-3G for freebsd-arm@freebsd.org; Thu, 10 Sep 2015 08:56:49 -0700 From: Carl Johnson To: freebsd-arm@freebsd.org Subject: Re: X on RPI2 - which driver References: <20150910094505.GA23609@potato.growveg.org> <55F15232.3060401@selasky.org> <20150910104001.GB23609@potato.growveg.org> <20150910144719.GC23609@potato.growveg.org> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 10 Sep 2015 08:56:49 -0700 In-Reply-To: <20150910144719.GC23609@potato.growveg.org> (John's message of "Thu, 10 Sep 2015 15:47:19 +0100") Message-ID: <87h9n26zem.fsf@elk.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MAG-OUTBOUND: peakinternet.redcondor.net@207.55.16/22 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 Sep 2015 15:56:58 -0000 John writes: > On Thu, Sep 10, 2015 at 11:40:01AM +0100, John wrote: >> On Thu, Sep 10, 2015 at 11:49:38AM +0200, Hans Petter Selasky wrote: >> > On 09/10/15 11:45, John wrote: >> > > Hello list, >> > > >> > > Which xorg drivers work on the rpi2? X -configure just shows vesa >> > > however I've not installed dbus/hal yet. >> > >> > I think you can use: >> > >> > xf86-video-scfb >> >> Thanks for that, I'll try it when hal and friends finish installing. > > No dice, I get the following from X -configure Look at the 'Setting up Xorg on RPi' link on the 'Raspberry Pi' page on the FreeBSD wiki (https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi). It shows a sample xorg.conf file that works for me. -- Carl Johnson carlj@peak.org From owner-freebsd-arm@freebsd.org Thu Sep 10 16:45:38 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 30397A01CCA for ; Thu, 10 Sep 2015 16:45:38 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 E9A821BDE for ; Thu, 10 Sep 2015 16:45:37 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1Za4yV-00042C-I0 for freebsd-arm@freebsd.org; Thu, 10 Sep 2015 17:45:28 +0100 Date: Thu, 10 Sep 2015 17:45:27 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: X on RPI2 - which driver Message-ID: <20150910164527.GA15049@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150910094505.GA23609@potato.growveg.org> <55F15232.3060401@selasky.org> <20150910104001.GB23609@potato.growveg.org> <20150910144719.GC23609@potato.growveg.org> <87h9n26zem.fsf@elk.localnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h9n26zem.fsf@elk.localnet> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John 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 Sep 2015 16:45:38 -0000 On Thu, Sep 10, 2015 at 08:56:49AM -0700, Carl Johnson wrote: > John writes: > > > No dice, I get the following from X -configure > > Look at the 'Setting up Xorg on RPi' link on the 'Raspberry Pi' page on > the FreeBSD wiki (https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi). > It shows a sample xorg.conf file that works for me. I tried that, unfortunately it didn't work for me and gives the error I posted (sorry I didn't make that clear). -- John From owner-freebsd-arm@freebsd.org Thu Sep 10 16:50: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 08CA7A01EDB for ; Thu, 10 Sep 2015 16:50:27 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 C1B611D6D for ; Thu, 10 Sep 2015 16:50:26 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1Za53I-00042X-GD for freebsd-arm@freebsd.org; Thu, 10 Sep 2015 17:50:24 +0100 Date: Thu, 10 Sep 2015 17:50:24 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: X on RPI2 - which driver Message-ID: <20150910165024.GB15049@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150910094505.GA23609@potato.growveg.org> <55F15232.3060401@selasky.org> <20150910104001.GB23609@potato.growveg.org> <20150910144719.GC23609@potato.growveg.org> <20150910155054.a200ea1e98ce408d98742d2a@ulrich-grey.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910155054.a200ea1e98ce408d98742d2a@ulrich-grey.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John 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 Sep 2015 16:50:27 -0000 On Thu, Sep 10, 2015 at 03:50:54PM +0000, Ulrich Grey wrote: [a working xorg.conf!!!!!] Thank you very much, that worked!!! OK it's slow, I expect that. But it's working, at least it's a starting point. What I know about X you could write on a stamp. Now I just need to tune it a bit. thanks again, -- John From owner-freebsd-arm@freebsd.org Thu Sep 10 13:15: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 05E60A0058F for ; Thu, 10 Sep 2015 13:15:40 +0000 (UTC) (envelope-from JBeulich@suse.com) Received: from prv-mh.provo.novell.com (prv-mh.provo.novell.com [137.65.248.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.provo.novell.com", Issuer "DigiCert SHA2 High Assurance Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9A571448 for ; Thu, 10 Sep 2015 13:15:39 +0000 (UTC) (envelope-from JBeulich@suse.com) Received: from INET-PRV-MTA by prv-mh.provo.novell.com with Novell_GroupWise; Thu, 10 Sep 2015 06:55:27 -0600 Message-Id: <55F199DD02000078000A1B1E@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.0.1 Date: Thu, 10 Sep 2015 06:55:25 -0600 From: "Jan Beulich" To: "Mark Rutland" , "Stefano Stabellini" Cc: "Ian.Campbell@citrix.com" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "peter.huangpeng@huawei.com" , "Shannon Zhao" , "matt.fleming@intel.com" , "ard.biesheuvel@linaro.org" , "christoffer.dall@linaro.org" , "leif.lindholm@linaro.org" , "shannon.zhao@linaro.org" , "linux-arm-kernel@lists.infradead.org" , "xen-devel@lists.xen.org" , , "Konrad Rzeszutek Wilk" , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Thu, 10 Sep 2015 17:19:53 +0000 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 Sep 2015 13:15:40 -0000 >>> On 10.09.15 at 13:37, wrote: > On Thu, 10 Sep 2015, Mark Rutland wrote: >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. >> create pages of RuntimeServicesCode that are trivial assembly shims >> doing hypercalls, and plumb these into the virtual EFI memory map and >> tables? >>=20 >> That would keep things sane for any guest, allow for easy addition of >> EFI features, and you could even enter the usual EFI entry point, >> simulate ExitBootServices(), SetVirtualAddressMap(), and allow the = guest >> to make things sane for itself... >=20 > That's the way it was done on x86 and now we have common code both in > Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this > scheme. Switching to a different solution for ARM, would mean diverging > with x86, which is not nice, or reimplementing the x86 solution too, > which is expensive. >=20 > BTW I think that the idea you proposed was actually considered at the > time and deemed hard to implement, if I recall correctly. Considering that the EFI support is just for Dom0, and Dom0 (at the time) had to be PV anyway, it was the more natural solution to expose the interface via hypercalls, the more that this allows better control over what is and primarily what is not being exposed to Dom0. With the wrapper approach we'd be back to the same problem (discussed elsewhere) of which EFI version to surface: The host one would impose potentially missing extensions, while the most recent hypervisor known one might imply hiding valuable information from Dom0. Plus there are incompatible changes like the altered meaning of EFI_MEMORY_WP in 2.5. Jan From owner-freebsd-arm@freebsd.org Thu Sep 10 13:30: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 BD453A00D8B for ; Thu, 10 Sep 2015 13:30:34 +0000 (UTC) (envelope-from prvs=688ac6705=Ian.Campbell@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBABC1BCD for ; Thu, 10 Sep 2015 13:30:33 +0000 (UTC) (envelope-from prvs=688ac6705=Ian.Campbell@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,504,1437436800"; d="scan'208";a="302696803" Message-ID: <1441891830.24450.384.camel@citrix.com> Subject: Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters From: Ian Campbell To: Jan Beulich CC: Mark Rutland , "julien.grall@citrix.com" , Stefano Stabellini , "freebsd-arm@freebsd.org" , "peter.huangpeng@huawei.com" , Shannon Zhao , "matt.fleming@intel.com" , "ard.biesheuvel@linaro.org" , "christoffer.dall@linaro.org" , "leif.lindholm@linaro.org" , "shannon.zhao@linaro.org" , "linux-arm-kernel@lists.infradead.org" , "xen-devel@lists.xen.org" , "daniel.kiper@oracle.com" , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" Date: Thu, 10 Sep 2015 14:30:30 +0100 In-Reply-To: <55F19D0202000078000A1B54@prv-mh.provo.novell.com> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <1441889905.24450.382.camel@citrix.com> <55F19D0202000078000A1B54@prv-mh.provo.novell.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-Mailman-Approved-At: Thu, 10 Sep 2015 17:20:03 +0000 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 Sep 2015 13:30:34 -0000 On Thu, 2015-09-10 at 07:08 -0600, Jan Beulich wrote: > > > > On 10.09.15 at 14:58, wrote: > > On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote: > > > > > > In any case this should be separate from the shim ABI discussion. > > > > > > I disagree; I think this is very much relevant to the ABI discussion. > > > That's not to say that I insist on a particular approach, but I think > > > that they need to be considered together. > > > > Taking a step back, the reason for using the EFI stub parameters is > > only > > (AFAIK) in order to be able to locate the ACPI RDSP (the root table > > pointer), which as it happens is normally passed via one of the EFI > > firmware tables. > > > > If there was a way to achieve that goal (i.e. another way to find the > > RSDP) > > without opening the can of UEFI worms then we could consider that > > opiton > > too. > > > > a way != the legacy x86 thing of scanning low memory of the signature, > > of > > course. > > But even x86 doesn't do that (other than as a fallback) on EFI. Indeed, I was referring legacy (non-EFI) mode. > The > configuration table is available to Dom0 (via XENPF_firmware_info: > XEN_FW_EFI_INFO:XEN_FW_EFI_CONFIG_TABLE). Under ARM we find out we are running under Xen from the ACPI tables, so there is a chicken and egg situation there. Not insoluble I'm sure, if we want to go down this route. Ian. From owner-freebsd-arm@freebsd.org Thu Sep 10 13:54:26 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 369D19CDA07 for ; Thu, 10 Sep 2015 13:54:26 +0000 (UTC) (envelope-from prvs=68895f1e6=Stefano.Stabellini@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7B6818E9 for ; Thu, 10 Sep 2015 13:54:25 +0000 (UTC) (envelope-from prvs=68895f1e6=Stefano.Stabellini@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,504,1437436800"; d="scan'208";a="302704117" Date: Thu, 10 Sep 2015 14:52:25 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mark Rutland CC: Stefano Stabellini , Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk , "daniel.kiper@oracle.com" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters In-Reply-To: <20150910121514.GE29293@leverpostej> Message-ID: References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA2 X-Mailman-Approved-At: Thu, 10 Sep 2015 17:20:46 +0000 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 Sep 2015 13:54:26 -0000 On Thu, 10 Sep 2015, Mark Rutland wrote: > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > > > > interface? > > > > > > > > Xen talks to EFI itself but the interface provided to dom0 is somewhat > > > > different: there are no BootServices (Xen calls ExitBootServices before > > > > running the kernel), and the RuntimeServices go via hypercalls (see > > > > drivers/xen/efi.c). > > > > > > That's somewhat hideous; a non Xen-aware OS wouild presumably die if > > > trying to use any runtime services the normal way? I'm not keen on > > > describing things that the OS cannot use. > > > > I agree that is somewhat hideous, but a non-Xen aware OS traditionally > > has never been able to even boot as Dom0. On ARM it can, but it still > > wouldn't be very useful (one couldn't use it to start other guests). > > Sure, but it feels odd to provide the usual information in this manner > if it cannot be used. If you require Xen-specific code to make things > work, I would imagine this information could be dciscovered in a > Xen-specific manner. We need ACPI (or Device Tree) to find that Xen is available on the platform, so we cannot use Xen-specific code to get the ACPI tables. > > > Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. > > > create pages of RuntimeServicesCode that are trivial assembly shims > > > doing hypercalls, and plumb these into the virtual EFI memory map and > > > tables? > > > > > > That would keep things sane for any guest, allow for easy addition of > > > EFI features, and you could even enter the usual EFI entry point, > > > simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest > > > to make things sane for itself... > > > > That's the way it was done on x86 and now we have common code both in > > Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this > > scheme. > > This code is not currently used on arm. It might live in a location > where it may be shared, but that doesn't mean that it's common code yet. Yeah, but that was clearly the intention. > > Switching to a different solution for ARM, would mean diverging > > with x86, which is not nice, or reimplementing the x86 solution too, > > which is expensive. > > > > BTW I think that the idea you proposed was actually considered at the > > time and deemed hard to implement, if I recall correctly. > > I appreciate that divergence is painful. We already diverge in other > respects (e.g. lack of PV page tables) because things that used to be > the case on x86 never applied to ARM. > > It would be interesting to see why that was the case for x86, and > whether that applies to ARM. I have been a big advocate of doing things differently, and more cleanly, on ARM, but in this case the code is already non-arch specific. We are not talking about pagetables, which of course cannot be reused as-is even if we wanted to. For once, I think we should follow the x86 way, for convenience and for the reasons brought up by Jan. > > In any case this should be separate from the shim ABI discussion. > > I disagree; I think this is very much relevant to the ABI discussion. > That's not to say that I insist on a particular approach, but I think > that they need to be considered together. Let's suppose Xen didn't expose any RuntimeServices at all, would that make it easier to discuss about the EFI stub parameters? In the grant scheme of things, they are not that important, as Ian wrote what is important is how to pass the RSDP. From owner-freebsd-arm@freebsd.org Thu Sep 10 14:49:54 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 7B64EA013CC for ; Thu, 10 Sep 2015 14:49:54 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9F71092 for ; Thu, 10 Sep 2015 14:49:53 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 58DC775; Thu, 10 Sep 2015 07:50:03 -0700 (PDT) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 45CEB3F318; Thu, 10 Sep 2015 07:49:49 -0700 (PDT) Date: Thu, 10 Sep 2015 15:49:38 +0100 From: Mark Rutland To: Stefano Stabellini Cc: Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk , "daniel.kiper@oracle.com" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150910144938.GI29293@leverpostej> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 10 Sep 2015 17:20:47 +0000 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 Sep 2015 14:49:54 -0000 On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote: > On Thu, 10 Sep 2015, Mark Rutland wrote: > > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > > > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > > > > > interface? > > > > > > > > > > Xen talks to EFI itself but the interface provided to dom0 is somewhat > > > > > different: there are no BootServices (Xen calls ExitBootServices before > > > > > running the kernel), and the RuntimeServices go via hypercalls (see > > > > > drivers/xen/efi.c). > > > > > > > > That's somewhat hideous; a non Xen-aware OS wouild presumably die if > > > > trying to use any runtime services the normal way? I'm not keen on > > > > describing things that the OS cannot use. > > > > > > I agree that is somewhat hideous, but a non-Xen aware OS traditionally > > > has never been able to even boot as Dom0. On ARM it can, but it still > > > wouldn't be very useful (one couldn't use it to start other guests). > > > > Sure, but it feels odd to provide the usual information in this manner > > if it cannot be used. If you require Xen-specific code to make things > > work, I would imagine this information could be dciscovered in a > > Xen-specific manner. > > We need ACPI (or Device Tree) to find that Xen is available on the > platform, so we cannot use Xen-specific code to get the ACPI tables. I don't understand. The proposition already involves passing a custom DT to the OS, implying that Xen knows how to boot that OS, and how to pass it a DTB. Consider: A) In the DT-only case, we go: DT -> Discover Xen -> Xen-specific stuff B) The proposition is that un the ACPI case we go: DT -> EFI tables -> ACPI tables -> Discover Xen -> Xen-specific stuff -> override EFI/ACPI stuff \-----------------------/ (be really cautious here) C) When you could go: DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery D) If you want to be generic: EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff \------------------------------------------/ (virtualize these, provide shims to Dom0, but handle everything in Xen itself) E) Partially-generic option: EFI -> EFI application -> Xen detected by registered GUID -> Xen-specific EFI bootloader stuff -> OS in Xen-specific configuration > > > In any case this should be separate from the shim ABI discussion. > > > > I disagree; I think this is very much relevant to the ABI discussion. > > That's not to say that I insist on a particular approach, but I think > > that they need to be considered together. > > Let's suppose Xen didn't expose any RuntimeServices at all, would that > make it easier to discuss about the EFI stub parameters? It would simply the protocol specific to Xen, certainly. > In the grant scheme of things, they are not that important, as Ian > wrote what is important is how to pass the RSDP. Unfortunately we're still going to have to care about this eventually, even if for something like kexec. So we still need to spec out the state of things if this is going to be truly generic. Thanks, Mark. From owner-freebsd-arm@freebsd.org Thu Sep 10 15:06: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 271F5A01C22 for ; Thu, 10 Sep 2015 15:06:34 +0000 (UTC) (envelope-from JBeulich@suse.com) Received: from prv-mh.provo.novell.com (prv-mh.provo.novell.com [137.65.248.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.provo.novell.com", Issuer "DigiCert SHA2 High Assurance Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA2B61CFB for ; Thu, 10 Sep 2015 15:06:33 +0000 (UTC) (envelope-from JBeulich@suse.com) Received: from INET-PRV-MTA by prv-mh.provo.novell.com with Novell_GroupWise; Thu, 10 Sep 2015 09:06:32 -0600 Message-Id: <55F1B89802000078000A1C9B@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.0.1 Date: Thu, 10 Sep 2015 09:06:32 -0600 From: "Jan Beulich" To: "Mark Rutland" Cc: "Ian.Campbell@citrix.com" , "julien.grall@citrix.com" , "Stefano Stabellini" , "freebsd-arm@freebsd.org" , "peter.huangpeng@huawei.com" , "Shannon Zhao" , "matt.fleming@intel.com" , "ard.biesheuvel@linaro.org" , "christoffer.dall@linaro.org" , "leif.lindholm@linaro.org" , "shannon.zhao@linaro.org" , "linux-arm-kernel@lists.infradead.org" , "xen-devel@lists.xen.org" , "daniel.kiper@oracle.com" , "Konrad Rzeszutek Wilk" , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <55F199DD02000078000A1B1E@prv-mh.provo.novell.com> <20150910145331.GJ29293@leverpostej> In-Reply-To: <20150910145331.GJ29293@leverpostej> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Thu, 10 Sep 2015 17:20:49 +0000 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 Sep 2015 15:06:34 -0000 >>> On 10.09.15 at 16:53, wrote: > On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote: >> >>> On 10.09.15 at 13:37, wrote: >> > On Thu, 10 Sep 2015, Mark Rutland wrote: >> >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. >> >> create pages of RuntimeServicesCode that are trivial assembly shims >> >> doing hypercalls, and plumb these into the virtual EFI memory map = and >> >> tables? >> >>=20 >> >> That would keep things sane for any guest, allow for easy addition = of >> >> EFI features, and you could even enter the usual EFI entry point, >> >> simulate ExitBootServices(), SetVirtualAddressMap(), and allow the = guest >> >> to make things sane for itself... >> >=20 >> > That's the way it was done on x86 and now we have common code both in >> > Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement = this >> > scheme. Switching to a different solution for ARM, would mean = diverging >> > with x86, which is not nice, or reimplementing the x86 solution too, >> > which is expensive. >> >=20 >> > BTW I think that the idea you proposed was actually considered at the >> > time and deemed hard to implement, if I recall correctly. >>=20 >> Considering that the EFI support is just for Dom0, and Dom0 (at >> the time) had to be PV anyway, it was the more natural solution to >> expose the interface via hypercalls, the more that this allows better >> control over what is and primarily what is not being exposed to >> Dom0. With the wrapper approach we'd be back to the same >> problem (discussed elsewhere) of which EFI version to surface: The >> host one would impose potentially missing extensions, while the >> most recent hypervisor known one might imply hiding valuable >> information from Dom0. Plus there are incompatible changes like >> the altered meaning of EFI_MEMORY_WP in 2.5. >=20 > I'm not sure I follow how hypercalls solve any impedance mismatch here; > you're still expecting Dom0 to call up to Xen in order to perform calls, > and all I suggested was a different location for those hypercalls. >=20 > If Xen is happy to make such calls blindly, why does it matter if the > hypercall was in the kernel binary or an external shim? Because there could be new entries in SystemTable->RuntimeServices (expected and blindly but validly called by the kernel). Even worse (because likely harder to deal with) would be new fields in other structures. > Incompatible changes are a spec problem regardless of how this is > handled. Not necessarily - we don't expose the memory map (we'd have to if we were to mimic EFI for Dom0), and hence the mentioned issue doesn't exist in our model. Jan From owner-freebsd-arm@freebsd.org Thu Sep 10 14:13: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 20636A0034F for ; Thu, 10 Sep 2015 14:13:59 +0000 (UTC) (envelope-from leif.lindholm@linaro.org) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 A71941154 for ; Thu, 10 Sep 2015 14:13:58 +0000 (UTC) (envelope-from leif.lindholm@linaro.org) Received: by wicge5 with SMTP id ge5so26942311wic.0 for ; Thu, 10 Sep 2015 07:13:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=in5GC6WTYotm0NuJi4pP6eJXJKyZLdPYfOyBmjDdnBI=; b=NYtm4PsL3eEijii2vVBsx544CmjLuojw/ENahApDVOY6x2fagsABz/5ly3c4RgOov2 gaW2NdC3KwcTYJAAsU3Qoshsy/sevT41/JYQgFW6WBgGm+b1zZ5yLD8trxNG3b5X8E0f HDbTM5xJxug479R16r1lsP/fsGHjtxRc9MC28f45bzYYnTUXHYocte7wLJOdGsIrINqt j9V39UHygeF2eFItzkYjeLHLYkTtmEs0VI179V114mY54Q1laShPqT3fE1x54DWHFsAW soXPrws50qb09Ph3lapCvF8tROaN6YR9O2fDjrug75zlwhtPPRi0BzALGWmopsEF4HPi XjwA== X-Gm-Message-State: ALoCoQnsmQ9/dodCW+fQFPHESCfSXgRxv1GDA0C6w47XzVJsp+kwrF7Zc3QF7sHVCLo9NZNGQQa3 X-Received: by 10.180.87.1 with SMTP id t1mr6611388wiz.33.1441894430534; Thu, 10 Sep 2015 07:13:50 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id mc18sm9527838wic.23.2015.09.10.07.13.48 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 10 Sep 2015 07:13:49 -0700 (PDT) Date: Thu, 10 Sep 2015 15:13:46 +0100 From: Leif Lindholm To: Stefano Stabellini Cc: Mark Rutland , Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk , "daniel.kiper@oracle.com" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150910141346.GV10728@bivouac.eciton.net> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 10 Sep 2015 17:20:47 +0000 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 Sep 2015 14:13:59 -0000 On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote: > > > In any case this should be separate from the shim ABI discussion. > > > > I disagree; I think this is very much relevant to the ABI discussion. > > That's not to say that I insist on a particular approach, but I think > > that they need to be considered together. > > Let's suppose Xen didn't expose any RuntimeServices at all, would that > make it easier to discuss about the EFI stub parameters? Possibly :) > In the grant > scheme of things, they are not that important, as Ian wrote what is > important is how to pass the RSDP. So, we have discussed in the past having the ability to get at configuration tables when UEFI is not available. Say, for example, that we wanted SMBIOS support on a platform with U-Boot firmware. Since all that is needed then is a UEFI System Table with a pointer to a configuration table array, this should be fairly straightforward to implement statically. The other parameters would not be necessary. It would however require minor changes to the arm64 kernel UEFI support. / Leif From owner-freebsd-arm@freebsd.org Thu Sep 10 16:13:01 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 C58FFA01E64 for ; Thu, 10 Sep 2015 16:13:01 +0000 (UTC) (envelope-from prvs=68895f1e6=Stefano.Stabellini@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6813615C2 for ; Thu, 10 Sep 2015 16:13:00 +0000 (UTC) (envelope-from prvs=68895f1e6=Stefano.Stabellini@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,505,1437436800"; d="scan'208";a="302754396" Date: Thu, 10 Sep 2015 17:10:33 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mark Rutland CC: Stefano Stabellini , Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk , "daniel.kiper@oracle.com" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters In-Reply-To: <20150910144938.GI29293@leverpostej> Message-ID: References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA1 X-Mailman-Approved-At: Thu, 10 Sep 2015 17:20:49 +0000 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 Sep 2015 16:13:01 -0000 On Thu, 10 Sep 2015, Mark Rutland wrote: > On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote: > > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > > > > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > > > > > > interface? > > > > > > > > > > > > Xen talks to EFI itself but the interface provided to dom0 is somewhat > > > > > > different: there are no BootServices (Xen calls ExitBootServices before > > > > > > running the kernel), and the RuntimeServices go via hypercalls (see > > > > > > drivers/xen/efi.c). > > > > > > > > > > That's somewhat hideous; a non Xen-aware OS wouild presumably die if > > > > > trying to use any runtime services the normal way? I'm not keen on > > > > > describing things that the OS cannot use. > > > > > > > > I agree that is somewhat hideous, but a non-Xen aware OS traditionally > > > > has never been able to even boot as Dom0. On ARM it can, but it still > > > > wouldn't be very useful (one couldn't use it to start other guests). > > > > > > Sure, but it feels odd to provide the usual information in this manner > > > if it cannot be used. If you require Xen-specific code to make things > > > work, I would imagine this information could be dciscovered in a > > > Xen-specific manner. > > > > We need ACPI (or Device Tree) to find that Xen is available on the > > platform, so we cannot use Xen-specific code to get the ACPI tables. > > I don't understand. The proposition already involves passing a custom DT > to the OS, implying that Xen knows how to boot that OS, and how to pass > it a DTB. > > Consider: > > A) In the DT-only case, we go: > > DT -> Discover Xen -> Xen-specific stuff > > > B) The proposition is that un the ACPI case we go: > > DT -> EFI tables -> ACPI tables -> Discover Xen -> Xen-specific stuff -> override EFI/ACPI stuff > \-----------------------/ > (be really cautious here) Well, yes. To be pedantic "override" here would just be the different delivery method for RuntimeServices. I guess it still counts. > C) When you could go: > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery I take you mean discovering Xen with the usual Xen hypervisor node on device tree. I think that C) is a good option actually. I like it. Not sure why we didn't think about this earlier. Is there anything EFI or ACPI which is needed before Xen support is discovered by arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()? If not, we could just go for this. A lot of complexity would go away. > D) If you want to be generic: > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff > \------------------------------------------/ > (virtualize these, provide shims to Dom0, but handle > everything in Xen itself) I think that this is good in theory but could turn out to be a lot of work in practice. We could probably virtualize the RuntimeServices but the BootServices are troublesome. > > E) Partially-generic option: > EFI -> EFI application -> Xen detected by registered GUID -> Xen-specific EFI bootloader stuff -> OS in Xen-specific configuration > > > > > > In any case this should be separate from the shim ABI discussion. > > > > > > I disagree; I think this is very much relevant to the ABI discussion. > > > That's not to say that I insist on a particular approach, but I think > > > that they need to be considered together. > > > > Let's suppose Xen didn't expose any RuntimeServices at all, would that > > make it easier to discuss about the EFI stub parameters? > > It would simply the protocol specific to Xen, certainly. > > > In the grant scheme of things, they are not that important, as Ian > > wrote what is important is how to pass the RSDP. > > Unfortunately we're still going to have to care about this eventually, > even if for something like kexec. So we still need to spec out the state > of things if this is going to be truly generic. Fair enough. My position is that if we restrict this to RuntimeServices, it might be possible, but I still prefer C). From owner-freebsd-arm@freebsd.org Thu Sep 10 14:53: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 55657A01687 for ; Thu, 10 Sep 2015 14:53:45 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mx1.freebsd.org (Postfix) with ESMTP id 36B681520 for ; Thu, 10 Sep 2015 14:53:44 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8DC8B75; Thu, 10 Sep 2015 07:53:55 -0700 (PDT) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C1363F318; Thu, 10 Sep 2015 07:53:41 -0700 (PDT) Date: Thu, 10 Sep 2015 15:53:31 +0100 From: Mark Rutland To: Jan Beulich Cc: Stefano Stabellini , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "matt.fleming@intel.com" , "Ian.Campbell@citrix.com" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "daniel.kiper@oracle.com" , Konrad Rzeszutek Wilk , "linux-doc@vger.kernel.org" , "peter.huangpeng@huawei.com" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "linux-efi@vger.kernel.org" , "shannon.zhao@linaro.org" , Shannon Zhao , "christoffer.dall@linaro.org" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150910145331.GJ29293@leverpostej> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <55F199DD02000078000A1B1E@prv-mh.provo.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F199DD02000078000A1B1E@prv-mh.provo.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 10 Sep 2015 17:20:48 +0000 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 Sep 2015 14:53:45 -0000 On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote: > >>> On 10.09.15 at 13:37, wrote: > > On Thu, 10 Sep 2015, Mark Rutland wrote: > >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. > >> create pages of RuntimeServicesCode that are trivial assembly shims > >> doing hypercalls, and plumb these into the virtual EFI memory map and > >> tables? > >> > >> That would keep things sane for any guest, allow for easy addition of > >> EFI features, and you could even enter the usual EFI entry point, > >> simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest > >> to make things sane for itself... > > > > That's the way it was done on x86 and now we have common code both in > > Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this > > scheme. Switching to a different solution for ARM, would mean diverging > > with x86, which is not nice, or reimplementing the x86 solution too, > > which is expensive. > > > > BTW I think that the idea you proposed was actually considered at the > > time and deemed hard to implement, if I recall correctly. > > Considering that the EFI support is just for Dom0, and Dom0 (at > the time) had to be PV anyway, it was the more natural solution to > expose the interface via hypercalls, the more that this allows better > control over what is and primarily what is not being exposed to > Dom0. With the wrapper approach we'd be back to the same > problem (discussed elsewhere) of which EFI version to surface: The > host one would impose potentially missing extensions, while the > most recent hypervisor known one might imply hiding valuable > information from Dom0. Plus there are incompatible changes like > the altered meaning of EFI_MEMORY_WP in 2.5. I'm not sure I follow how hypercalls solve any impedance mismatch here; you're still expecting Dom0 to call up to Xen in order to perform calls, and all I suggested was a different location for those hypercalls. If Xen is happy to make such calls blindly, why does it matter if the hypercall was in the kernel binary or an external shim? Incompatible changes are a spec problem regardless of how this is handled. Thanks, Mark. From owner-freebsd-arm@freebsd.org Thu Sep 10 16:23: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 8A5DFA01340 for ; Thu, 10 Sep 2015 16:23:17 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mx1.freebsd.org (Postfix) with ESMTP id 68E681D07 for ; Thu, 10 Sep 2015 16:23:17 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D7D2575; Thu, 10 Sep 2015 09:23:26 -0700 (PDT) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9DB3B3F317; Thu, 10 Sep 2015 09:23:12 -0700 (PDT) Date: Thu, 10 Sep 2015 17:23:02 +0100 From: Mark Rutland To: Stefano Stabellini Cc: Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk , "daniel.kiper@oracle.com" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150910162302.GN29293@leverpostej> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 10 Sep 2015 17:20:51 +0000 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 Sep 2015 16:23:17 -0000 > > C) When you could go: > > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery > > I take you mean discovering Xen with the usual Xen hypervisor node on > device tree. I think that C) is a good option actually. I like it. Not > sure why we didn't think about this earlier. Is there anything EFI or > ACPI which is needed before Xen support is discovered by > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()? Currently lots (including the memory map). With the stuff to support SPCR, the ACPI discovery would be moved before xen_early_init(). > If not, we could just go for this. A lot of complexity would go away. I suspect this would still be fairly complex, but would at least prevent the Xen-specific EFI handling from adversely affecting the native case. > > D) If you want to be generic: > > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff > > \------------------------------------------/ > > (virtualize these, provide shims to Dom0, but handle > > everything in Xen itself) > > I think that this is good in theory but could turn out to be a lot of > work in practice. We could probably virtualize the RuntimeServices but > the BootServices are troublesome. What's troublesome with the boot services? What can't be simulated? > > E) Partially-generic option: > > EFI -> EFI application -> Xen detected by registered GUID -> Xen-specific EFI bootloader stuff -> OS in Xen-specific configuration > > > > > > > > > In any case this should be separate from the shim ABI discussion. > > > > > > > > I disagree; I think this is very much relevant to the ABI discussion. > > > > That's not to say that I insist on a particular approach, but I think > > > > that they need to be considered together. > > > > > > Let's suppose Xen didn't expose any RuntimeServices at all, would that > > > make it easier to discuss about the EFI stub parameters? > > > > It would simply the protocol specific to Xen, certainly. > > > > > In the grant scheme of things, they are not that important, as Ian > > > wrote what is important is how to pass the RSDP. > > > > Unfortunately we're still going to have to care about this eventually, > > even if for something like kexec. So we still need to spec out the state > > of things if this is going to be truly generic. > > Fair enough. My position is that if we restrict this to RuntimeServices, > it might be possible, but I still prefer C). Regardless of what we do we still need a well-defined state here, which brings us back to the initial problem eventually. Thanks, Mark. From owner-freebsd-arm@freebsd.org Fri Sep 11 11:00: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 59893A01BFF for ; Fri, 11 Sep 2015 11:00:10 +0000 (UTC) (envelope-from prvs=689d88a86=Ian.Campbell@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0310C1C84 for ; Fri, 11 Sep 2015 11:00:09 +0000 (UTC) (envelope-from prvs=689d88a86=Ian.Campbell@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,511,1437436800"; d="scan'208";a="302949465" Message-ID: <1441969200.3549.23.camel@citrix.com> Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters From: Ian Campbell To: Stefano Stabellini , Mark Rutland CC: Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk , "daniel.kiper@oracle.com" Date: Fri, 11 Sep 2015 12:00:00 +0100 In-Reply-To: References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-DLP: MIA2 X-Mailman-Approved-At: Fri, 11 Sep 2015 11:22:02 +0000 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 Sep 2015 11:00:10 -0000 On Thu, 2015-09-10 at 17:10 +0100, Stefano Stabellini wrote: > > C) When you could go: > > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI > > discovery > > I take you mean discovering Xen with the usual Xen hypervisor node on > device tree. There may be other options, such as ARM defining an architectural mechanism to do early detection of hypervisors e.g. by defining some bit in some hypervisor controllable register (MPIDR?) to say "a hypervisor is present" and defining an hvc or smc call which can be used to ask which one it is. Ian. From owner-freebsd-arm@freebsd.org Fri Sep 11 12:47: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 C1930A01ACB for ; Fri, 11 Sep 2015 12:47:02 +0000 (UTC) (envelope-from daniel.kiper@oracle.com) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "userp1040.oracle.com", Issuer "VeriSign Class 3 International Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 895A51DCA for ; Fri, 11 Sep 2015 12:47:02 +0000 (UTC) (envelope-from daniel.kiper@oracle.com) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8BCkphw019886 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Sep 2015 12:46:51 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8BCkoWs005102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2015 12:46:50 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t8BCkoQH027033; Fri, 11 Sep 2015 12:46:50 GMT Received: from olila.local.net-space.pl (/10.175.171.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Sep 2015 05:46:50 -0700 Date: Fri, 11 Sep 2015 14:46:43 +0200 From: Daniel Kiper To: Mark Rutland Cc: Stefano Stabellini , Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150911124643.GB4530@olila.local.net-space.pl> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> <20150910162302.GN29293@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910162302.GN29293@leverpostej> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Mailman-Approved-At: Fri, 11 Sep 2015 14:54:36 +0000 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 Sep 2015 12:47:02 -0000 On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > > > C) When you could go: > > > > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery > > > > I take you mean discovering Xen with the usual Xen hypervisor node on > > device tree. I think that C) is a good option actually. I like it. Not > > sure why we didn't think about this earlier. Is there anything EFI or > > ACPI which is needed before Xen support is discovered by > > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()? > > Currently lots (including the memory map). With the stuff to support > SPCR, the ACPI discovery would be moved before xen_early_init(). > > > If not, we could just go for this. A lot of complexity would go away. > > I suspect this would still be fairly complex, but would at least prevent > the Xen-specific EFI handling from adversely affecting the native case. > > > > D) If you want to be generic: > > > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff > > > \------------------------------------------/ > > > (virtualize these, provide shims to Dom0, but handle > > > everything in Xen itself) > > > > I think that this is good in theory but could turn out to be a lot of > > work in practice. We could probably virtualize the RuntimeServices but > > the BootServices are troublesome. > > What's troublesome with the boot services? > > What can't be simulated? How do you want to access bare metal EFI boot services from dom0 if they were shutdown long time ago before loading dom0 image? What do you need from EFI boot services in dom0? Daniel From owner-freebsd-arm@freebsd.org Fri Sep 11 13:16: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 9D304A027A6 for ; Fri, 11 Sep 2015 13:16:17 +0000 (UTC) (envelope-from prvs=689e42d66=Stefano.Stabellini@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 289711F1D for ; Fri, 11 Sep 2015 13:16:16 +0000 (UTC) (envelope-from prvs=689e42d66=Stefano.Stabellini@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,511,1437436800"; d="scan'208";a="299435767" Date: Fri, 11 Sep 2015 14:14:09 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Daniel Kiper CC: Mark Rutland , Stefano Stabellini , Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters In-Reply-To: <20150911124643.GB4530@olila.local.net-space.pl> Message-ID: References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> <20150910162302.GN29293@leverpostej> <20150911124643.GB4530@olila.local.net-space.pl> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA2 X-Mailman-Approved-At: Fri, 11 Sep 2015 15:55:47 +0000 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 Sep 2015 13:16:17 -0000 On Fri, 11 Sep 2015, Daniel Kiper wrote: > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > > > > C) When you could go: > > > > > > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery > > > > > > I take you mean discovering Xen with the usual Xen hypervisor node on > > > device tree. I think that C) is a good option actually. I like it. Not > > > sure why we didn't think about this earlier. Is there anything EFI or > > > ACPI which is needed before Xen support is discovered by > > > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()? > > > > Currently lots (including the memory map). With the stuff to support > > SPCR, the ACPI discovery would be moved before xen_early_init(). > > > > > If not, we could just go for this. A lot of complexity would go away. > > > > I suspect this would still be fairly complex, but would at least prevent > > the Xen-specific EFI handling from adversely affecting the native case. > > > > > > D) If you want to be generic: > > > > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff > > > > \------------------------------------------/ > > > > (virtualize these, provide shims to Dom0, but handle > > > > everything in Xen itself) > > > > > > I think that this is good in theory but could turn out to be a lot of > > > work in practice. We could probably virtualize the RuntimeServices but > > > the BootServices are troublesome. > > > > What's troublesome with the boot services? > > > > What can't be simulated? > > How do you want to access bare metal EFI boot services from dom0 if they > were shutdown long time ago before loading dom0 image? What do you need > from EFI boot services in dom0? That's right. Trying to emulate BootServices after the real ExitBootServices has already been called seems like a very bad plan. I think that whatever interface we come up with, would need to be past ExitBootServices. From owner-freebsd-arm@freebsd.org Fri Sep 11 13:30:23 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 6DF8BA02EBB for ; Fri, 11 Sep 2015 13:30:23 +0000 (UTC) (envelope-from ard.biesheuvel@linaro.org) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) (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 326351497 for ; Fri, 11 Sep 2015 13:30:22 +0000 (UTC) (envelope-from ard.biesheuvel@linaro.org) Received: by iofh134 with SMTP id h134so97850722iof.0 for ; Fri, 11 Sep 2015 06:30:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2vYRXGNrOCjJFk5o5k6beu+e0eToa1hskc8Fj2adrlA=; b=keBhYM6CjokNX1toQXOS8NGrA01ihgdZaLoVQJp0ZrblA86AlfwKFWFVto4kOmYlOc zydv32hLKxlaf9vnVdZ3OPy6JVuPXlCBZn42bKePIRXVS0BRNy6Vqw5wpzfoySTofnDF EuoGzvKoF8j3GqXclTyvKAFIL/UWjmS7G2xHwSWAokdL/3tgRNPTHGvrEHCRcPBN1K6q l9nooF1T6pl6TNW4TecXqN88+/WeZ9pTXP73YRR38zZvDnVfbPnlkMq1hT+TzhAo9Xwn ZSByCPe2PSz6zxUWnavFiMeIO9tDjKZvmMd6soI9ieXaZMACC8HlO8ZbqOwCRrlAyTXe D1Pw== X-Gm-Message-State: ALoCoQmeKrvf6wT4TzTCz1mHGF7OgkU2iNURIdwxmoSxAF1cC2SgYUUFxMMnUws3A1pnVHXLxKt5 MIME-Version: 1.0 X-Received: by 10.107.16.80 with SMTP id y77mr3593796ioi.183.1441978215921; Fri, 11 Sep 2015 06:30:15 -0700 (PDT) Received: by 10.36.138.69 with HTTP; Fri, 11 Sep 2015 06:30:15 -0700 (PDT) In-Reply-To: References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> <20150910162302.GN29293@leverpostej> <20150911124643.GB4530@olila.local.net-space.pl> Date: Fri, 11 Sep 2015 15:30:15 +0200 Message-ID: Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters From: Ard Biesheuvel To: Stefano Stabellini Cc: Daniel Kiper , Mark Rutland , Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 11 Sep 2015 16:04:05 +0000 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 Sep 2015 13:30:23 -0000 On 11 September 2015 at 15:14, Stefano Stabellini wrote: > On Fri, 11 Sep 2015, Daniel Kiper wrote: >> On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: >> > > > C) When you could go: >> > > > >> > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery >> > > >> > > I take you mean discovering Xen with the usual Xen hypervisor node on >> > > device tree. I think that C) is a good option actually. I like it. Not >> > > sure why we didn't think about this earlier. Is there anything EFI or >> > > ACPI which is needed before Xen support is discovered by >> > > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()? >> > >> > Currently lots (including the memory map). With the stuff to support >> > SPCR, the ACPI discovery would be moved before xen_early_init(). >> > >> > > If not, we could just go for this. A lot of complexity would go away. >> > >> > I suspect this would still be fairly complex, but would at least prevent >> > the Xen-specific EFI handling from adversely affecting the native case. >> > >> > > > D) If you want to be generic: >> > > > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff >> > > > \------------------------------------------/ >> > > > (virtualize these, provide shims to Dom0, but handle >> > > > everything in Xen itself) >> > > >> > > I think that this is good in theory but could turn out to be a lot of >> > > work in practice. We could probably virtualize the RuntimeServices but >> > > the BootServices are troublesome. >> > >> > What's troublesome with the boot services? >> > >> > What can't be simulated? >> >> How do you want to access bare metal EFI boot services from dom0 if they >> were shutdown long time ago before loading dom0 image? What do you need >> from EFI boot services in dom0? > > That's right. Trying to emulate BootServices after the real > ExitBootServices has already been called seems like a very bad plan. > > I think that whatever interface we come up with, would need to be past > ExitBootServices. It feels like this discussion is going in circles. When we discussed this six months ago, we already concluded that, since UEFI is the only specified way that the presence of ACPI is advertised on an ARM system, we need to emulate UEFI to some extent. So we need the EFI system table to expose the UEFI configuration table that carries the ACPI root pointer. Since ACPI support also relies on the UEFI memory map (I think?), we need that as well. These two items are exactly what we pass via the UEFI DT properties, so we should indeed promote the current de-facto binding to a proper binding, and renaming the properties makes sense in that context. I agree that this should also include a description of the expected state of the firmware, i.e., that ExitBootServices() has been called, and that the memory map has been populated with virtual address, which have been installed using SetVirtualAddressMap() if they differ from the physical addresses. (The current implementation on the kernel side is perfectly capable of dealing with a 1:1 mapping). Beyond that, there is no point in pretending to be a full UEFI implementation, imo. Boot services are not required, nor are runtime services (only the current EFI init code on arm needs to be modified to deal with a NULL runtime services pointer) -- Ard. From owner-freebsd-arm@freebsd.org Fri Sep 11 17:03: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 CBDB5A01D6D for ; Fri, 11 Sep 2015 17:03:10 +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 BE1291A4A; Fri, 11 Sep 2015 17:03:10 +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 884B4B6B; Fri, 11 Sep 2015 17:03:10 +0000 (UTC) Date: Fri, 11 Sep 2015 17:03:05 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1854222166.119.1441990989547.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <252073543.117.1441987499962.JavaMail.jenkins@jenkins-9.freebsd.org> References: <252073543.117.1441987499962.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1109 - 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: Fri, 11 Sep 2015 17:03:10 -0000 FreeBSD_HEAD_arm64 - Build #1109 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1109/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1109/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1109/console Change summaries: No changes From owner-freebsd-arm@freebsd.org Fri Sep 11 15:45: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 02C6BA01418 for ; Fri, 11 Sep 2015 15:45:53 +0000 (UTC) (envelope-from daniel.kiper@oracle.com) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "aserp1040.oracle.com", Issuer "VeriSign Class 3 International Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0AD8110F for ; Fri, 11 Sep 2015 15:45:52 +0000 (UTC) (envelope-from daniel.kiper@oracle.com) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8BFji3m026766 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Sep 2015 15:45:45 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8BFjiWu021867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2015 15:45:44 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8BFjhbv006076; Fri, 11 Sep 2015 15:45:43 GMT Received: from olila.local.net-space.pl (/10.175.171.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Sep 2015 08:45:42 -0700 Date: Fri, 11 Sep 2015 17:45:34 +0200 From: Daniel Kiper To: Ard Biesheuvel Cc: Stefano Stabellini , Mark Rutland , Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150911154534.GD4530@olila.local.net-space.pl> References: <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> <20150910162302.GN29293@leverpostej> <20150911124643.GB4530@olila.local.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Mailman-Approved-At: Fri, 11 Sep 2015 17:22:04 +0000 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 Sep 2015 15:45:53 -0000 On Fri, Sep 11, 2015 at 03:30:15PM +0200, Ard Biesheuvel wrote: > On 11 September 2015 at 15:14, Stefano Stabellini > wrote: > > On Fri, 11 Sep 2015, Daniel Kiper wrote: > >> On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > >> > > > C) When you could go: > >> > > > > >> > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery > >> > > > >> > > I take you mean discovering Xen with the usual Xen hypervisor node on > >> > > device tree. I think that C) is a good option actually. I like it. Not > >> > > sure why we didn't think about this earlier. Is there anything EFI or > >> > > ACPI which is needed before Xen support is discovered by > >> > > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()? > >> > > >> > Currently lots (including the memory map). With the stuff to support > >> > SPCR, the ACPI discovery would be moved before xen_early_init(). > >> > > >> > > If not, we could just go for this. A lot of complexity would go away. > >> > > >> > I suspect this would still be fairly complex, but would at least prevent > >> > the Xen-specific EFI handling from adversely affecting the native case. > >> > > >> > > > D) If you want to be generic: > >> > > > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff > >> > > > \------------------------------------------/ > >> > > > (virtualize these, provide shims to Dom0, but handle > >> > > > everything in Xen itself) > >> > > > >> > > I think that this is good in theory but could turn out to be a lot of > >> > > work in practice. We could probably virtualize the RuntimeServices but > >> > > the BootServices are troublesome. > >> > > >> > What's troublesome with the boot services? > >> > > >> > What can't be simulated? > >> > >> How do you want to access bare metal EFI boot services from dom0 if they > >> were shutdown long time ago before loading dom0 image? What do you need > >> from EFI boot services in dom0? > > > > That's right. Trying to emulate BootServices after the real > > ExitBootServices has already been called seems like a very bad plan. > > > > I think that whatever interface we come up with, would need to be past > > ExitBootServices. > > It feels like this discussion is going in circles. > > When we discussed this six months ago, we already concluded that, > since UEFI is the only specified way that the presence of ACPI is > advertised on an ARM system, we need to emulate UEFI to some extent. > > So we need the EFI system table to expose the UEFI configuration table > that carries the ACPI root pointer. > > Since ACPI support also relies on the UEFI memory map (I think?), we > need that as well. > > These two items are exactly what we pass via the UEFI DT properties, > so we should indeed promote the current de-facto binding to a proper > binding, and renaming the properties makes sense in that context. > > I agree that this should also include a description of the expected > state of the firmware, i.e., that ExitBootServices() has been called, > and that the memory map has been populated with virtual address, which > have been installed using SetVirtualAddressMap() if they differ from > the physical addresses. (The current implementation on the kernel side > is perfectly capable of dealing with a 1:1 mapping). > > Beyond that, there is no point in pretending to be a full UEFI > implementation, imo. Boot services are not required, nor are runtime > services (only the current EFI init code on arm needs to be modified > to deal with a NULL runtime services pointer) Taking into account above I think that you have most of the code in place. Please take a look at linux/arch/x86/xen/efi.c, linux/drivers/acpi/osl.c and linux/drivers/xen/efi.c (maybe somewhere else). In general you should create ARM version of xen_efi_init() (x86 version you can find in linux/drivers/xen/efi.c; it is very simple thing), maybe add some code in a few places and voila. Daniel From owner-freebsd-arm@freebsd.org Fri Sep 11 16:26: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 858C0A02908 for ; Fri, 11 Sep 2015 16:26:39 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mx1.freebsd.org (Postfix) with ESMTP id 64E1E1D10 for ; Fri, 11 Sep 2015 16:26:38 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A16CF75; Fri, 11 Sep 2015 09:26:44 -0700 (PDT) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A1E3F3F317; Fri, 11 Sep 2015 09:26:29 -0700 (PDT) Date: Fri, 11 Sep 2015 17:25:59 +0100 From: Mark Rutland To: Daniel Kiper Cc: "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , Konrad Rzeszutek Wilk , Stefano Stabellini , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "ard.biesheuvel@linaro.org" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , Shannon Zhao , "julien.grall@citrix.com" , "peter.huangpeng@huawei.com" , "linux-arm-kernel@lists.infradead.org" , "shannon.zhao@linaro.org" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150911162559.GA8726@leverpostej> References: <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> <20150910162302.GN29293@leverpostej> <20150911124643.GB4530@olila.local.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150911124643.GB4530@olila.local.net-space.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 11 Sep 2015 17:44:08 +0000 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 Sep 2015 16:26:39 -0000 On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > > > > C) When you could go: > > > > > > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery > > > > > > I take you mean discovering Xen with the usual Xen hypervisor node on > > > device tree. I think that C) is a good option actually. I like it. Not > > > sure why we didn't think about this earlier. Is there anything EFI or > > > ACPI which is needed before Xen support is discovered by > > > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()? > > > > Currently lots (including the memory map). With the stuff to support > > SPCR, the ACPI discovery would be moved before xen_early_init(). > > > > > If not, we could just go for this. A lot of complexity would go away. > > > > I suspect this would still be fairly complex, but would at least prevent > > the Xen-specific EFI handling from adversely affecting the native case. > > > > > > D) If you want to be generic: > > > > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff > > > > \------------------------------------------/ > > > > (virtualize these, provide shims to Dom0, but handle > > > > everything in Xen itself) > > > > > > I think that this is good in theory but could turn out to be a lot of > > > work in practice. We could probably virtualize the RuntimeServices but > > > the BootServices are troublesome. > > > > What's troublesome with the boot services? > > > > What can't be simulated? > > How do you want to access bare metal EFI boot services from dom0 if they > were shutdown long time ago before loading dom0 image? I don't want to. I asked "What can't be simulated?" because I assumed everything necessary/mandatory could be simulated without needinng access to any real EFI boot services. As far as I can see all that's necessary is to provide a compatible interface. > What do you need from EFI boot services in dom0? The ability to call ExitBootServices() and SetVirtualAddressMap() on a _virtual_ address map for _virtual_ services provided by the hypervisor. A console so that I can log things early on. Mark. From owner-freebsd-arm@freebsd.org Fri Sep 11 16:33:50 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 0C1D3A02CA9 for ; Fri, 11 Sep 2015 16:33:50 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mx1.freebsd.org (Postfix) with ESMTP id DD9EE1157 for ; Fri, 11 Sep 2015 16:33:49 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4DBBF317; Fri, 11 Sep 2015 09:34:01 -0700 (PDT) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B7BB43F317; Fri, 11 Sep 2015 09:33:43 -0700 (PDT) Date: Fri, 11 Sep 2015 17:33:32 +0100 From: Mark Rutland To: Ard Biesheuvel Cc: Stefano Stabellini , Daniel Kiper , Shannon Zhao , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "julien.grall@citrix.com" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , "peter.huangpeng@huawei.com" , "shannon.zhao@linaro.org" , Konrad Rzeszutek Wilk Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150911163332.GB8726@leverpostej> References: <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> <20150910162302.GN29293@leverpostej> <20150911124643.GB4530@olila.local.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Thread-Topic: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Accept-Language: en-GB, en-US Content-Language: en-US acceptlanguage: en-GB, en-US User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 11 Sep 2015 17:44:23 +0000 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 Sep 2015 16:33:50 -0000 > It feels like this discussion is going in circles. > > When we discussed this six months ago, we already concluded that, > since UEFI is the only specified way that the presence of ACPI is > advertised on an ARM system, we need to emulate UEFI to some extent. My understanding from the last time I was present at such a discussion was that the emulation was complete from the kernel's PoV (i.e. no special case handling was required). Evidently I misunderstood. One of the main points of rationale for requiring EFI was that we'd have a well-defined system state as per the EFI (and ACPI) standards. We'd know we had the EFI memory map, services, etc (with the memory map and configuration tables being the most important elements). We didn't want to have to try to reconcile a DT memory map and ACPI, for instance. That is somewhat (though admitedly not entirely) broken if we require a set of rules to be applied beyond what the standards mandate. That is broken if we require a non-standard set of rules to be applied, and limits what we can do in the !Xen case. > So we need the EFI system table to expose the UEFI configuration table > that carries the ACPI root pointer. > > Since ACPI support also relies on the UEFI memory map (I think?), we > need that as well. > > These two items are exactly what we pass via the UEFI DT properties, > so we should indeed promote the current de-facto binding to a proper > binding, and renaming the properties makes sense in that context. I agree that we need to sort these out. > I agree that this should also include a description of the expected > state of the firmware, i.e., that ExitBootServices() has been called, > and that the memory map has been populated with virtual address, which > have been installed using SetVirtualAddressMap() if they differ from > the physical addresses. (The current implementation on the kernel side > is perfectly capable of dealing with a 1:1 mapping). > > Beyond that, there is no point in pretending to be a full UEFI > implementation, imo. Boot services are not required, nor are runtime > services (only the current EFI init code on arm needs to be modified > to deal with a NULL runtime services pointer) I'm not keen on this because it involves applying Xen-specific caveats atop of what the UEFI spec says (e.g. as runtime services might be NULL under Xen). As the spec and Xen evolve, those caveats shift, and that's going to be fragile for all users regardleses of Xen. If Xen needs special-casing, then I'd rather that Xen were detected first and provided us with what it knows is safe for us to use, rather than we tip-toe around until we're sure Xen isn't present and/or doesn't need additional constraints met. Thanks, Mark. From owner-freebsd-arm@freebsd.org Fri Sep 11 16:36:20 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 18EAEA02DD6 for ; Fri, 11 Sep 2015 16:36:20 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mx1.freebsd.org (Postfix) with ESMTP id EDAEC11B1 for ; Fri, 11 Sep 2015 16:36:19 +0000 (UTC) (envelope-from mark.rutland@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 615CE317; Fri, 11 Sep 2015 09:36:31 -0700 (PDT) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6E6183F317; Fri, 11 Sep 2015 09:36:16 -0700 (PDT) Date: Fri, 11 Sep 2015 17:36:05 +0100 From: Mark Rutland To: Jan Beulich Cc: "Ian.Campbell@citrix.com" , "julien.grall@citrix.com" , Stefano Stabellini , "freebsd-arm@freebsd.org" , "peter.huangpeng@huawei.com" , Shannon Zhao , "matt.fleming@intel.com" , "ard.biesheuvel@linaro.org" , "christoffer.dall@linaro.org" , "leif.lindholm@linaro.org" , "shannon.zhao@linaro.org" , "linux-arm-kernel@lists.infradead.org" , "xen-devel@lists.xen.org" , "daniel.kiper@oracle.com" , Konrad Rzeszutek Wilk , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150911163605.GC8726@leverpostej> References: <1441874516-11364-1-git-send-email-zhaoshenglong@huawei.com> <20150910095208.GA29293@leverpostej> <20150910112418.GC29293@leverpostej> <55F199DD02000078000A1B1E@prv-mh.provo.novell.com> <20150910145331.GJ29293@leverpostej> <55F1B89802000078000A1C9B@prv-mh.provo.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F1B89802000078000A1C9B@prv-mh.provo.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 11 Sep 2015 17:44:24 +0000 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 Sep 2015 16:36:20 -0000 > >> Considering that the EFI support is just for Dom0, and Dom0 (at > >> the time) had to be PV anyway, it was the more natural solution to > >> expose the interface via hypercalls, the more that this allows better > >> control over what is and primarily what is not being exposed to > >> Dom0. With the wrapper approach we'd be back to the same > >> problem (discussed elsewhere) of which EFI version to surface: The > >> host one would impose potentially missing extensions, while the > >> most recent hypervisor known one might imply hiding valuable > >> information from Dom0. Plus there are incompatible changes like > >> the altered meaning of EFI_MEMORY_WP in 2.5. > > > > I'm not sure I follow how hypercalls solve any impedance mismatch here; > > you're still expecting Dom0 to call up to Xen in order to perform calls, > > and all I suggested was a different location for those hypercalls. > > > > If Xen is happy to make such calls blindly, why does it matter if the > > hypercall was in the kernel binary or an external shim? > > Because there could be new entries in SystemTable->RuntimeServices > (expected and blindly but validly called by the kernel). Even worse > (because likely harder to deal with) would be new fields in other > structures. Any of these could cause Xen to blow up, while Xen could always provide a known-safe (but potentially sub-optimal) view to the kernel by default. > > Incompatible changes are a spec problem regardless of how this is > > handled. > > Not necessarily - we don't expose the memory map (we'd have to > if we were to mimic EFI for Dom0), and hence the mentioned issue > doesn't exist in our model. We have to expose _some_ memory map, so I don't follow this point. Mark. From owner-freebsd-arm@freebsd.org Sat Sep 12 11:37:21 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 00E89A02232 for ; Sat, 12 Sep 2015 11:37:21 +0000 (UTC) (envelope-from daniel.kiper@oracle.com) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "aserp1040.oracle.com", Issuer "VeriSign Class 3 International Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2A8F196A for ; Sat, 12 Sep 2015 11:37:20 +0000 (UTC) (envelope-from daniel.kiper@oracle.com) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8CBb7rx030737 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Sep 2015 11:37:07 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8CBb32m014624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 12 Sep 2015 11:37:04 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8CBb25B019874; Sat, 12 Sep 2015 11:37:02 GMT Received: from olila.local.net-space.pl (/10.175.241.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Sep 2015 04:37:02 -0700 Date: Sat, 12 Sep 2015 13:36:55 +0200 From: Daniel Kiper To: Mark Rutland Cc: "devicetree@vger.kernel.org" , "linux-efi@vger.kernel.org" , "Ian.Campbell@citrix.com" , Konrad Rzeszutek Wilk , Stefano Stabellini , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "leif.lindholm@linaro.org" , "xen-devel@lists.xen.org" , "ard.biesheuvel@linaro.org" , "freebsd-arm@freebsd.org" , "matt.fleming@intel.com" , "christoffer.dall@linaro.org" , "jbeulich@suse.com" , Shannon Zhao , "julien.grall@citrix.com" , "peter.huangpeng@huawei.com" , "linux-arm-kernel@lists.infradead.org" , "shannon.zhao@linaro.org" Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Message-ID: <20150912113655.GG4530@olila.local.net-space.pl> References: <20150910112418.GC29293@leverpostej> <20150910121514.GE29293@leverpostej> <20150910144938.GI29293@leverpostej> <20150910162302.GN29293@leverpostej> <20150911124643.GB4530@olila.local.net-space.pl> <20150911162559.GA8726@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150911162559.GA8726@leverpostej> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Mailman-Approved-At: Sat, 12 Sep 2015 12:03:12 +0000 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: Sat, 12 Sep 2015 11:37:21 -0000 On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: [...] > > > What's troublesome with the boot services? > > > > > > What can't be simulated? > > > > How do you want to access bare metal EFI boot services from dom0 if they > > were shutdown long time ago before loading dom0 image? > > I don't want to. > > I asked "What can't be simulated?" because I assumed everything > necessary/mandatory could be simulated without needinng access to any > real EFI boot services. > > As far as I can see all that's necessary is to provide a compatible > interface. Could you be more precise what do you need? Please enumerate. UEFI spec has more than 2500 pages and I do not think that we need all stuff in dom0. > > What do you need from EFI boot services in dom0? > > The ability to call ExitBootServices() and SetVirtualAddressMap() on a > _virtual_ address map for _virtual_ services provided by the hypervisor. I am confused. Why do you need that? Please remember, EFI is owned and operated by Xen hypervisor. dom0 does not have direct access to EFI. All stuff required in dom0 is provided via hypercalls. If you need an extra data form EFI in dom0 please extend currently exiting API. Do not emulate whole EFI if you need one or a few things from spec. > A console so that I can log things early on. IIUC, log from dom0. Please use machinery provided by Xen hypervisor. Daniel From owner-freebsd-arm@freebsd.org Sat Sep 12 15:04:44 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 67334A010BF for ; Sat, 12 Sep 2015 15:04:44 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 2ECE118CC for ; Sat, 12 Sep 2015 15:04:43 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZamLx-000PWx-Bq for freebsd-arm@freebsd.org; Sat, 12 Sep 2015 16:04:33 +0100 Date: Sat, 12 Sep 2015 16:04:33 +0100 From: John To: freebsd-arm@freebsd.org Subject: single user mode freebsd11/rpi2 Message-ID: <20150912150433.GA1204@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John 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: Sat, 12 Sep 2015 15:04:44 -0000 Hello list, I need to either make the system single user node by either becoming it (as root, shutdown now) or booting into it (either at the boot prompt or with nextboot) and I can do neither, so obviously I'm going about this the wrong way. "shutdown now" never returns a prompt and "nextboot -o "-s" -k kernel *will* boot the kernel after shutdown -p but I get no prompt. Last two lines of output: warning: no time-of-day clock registered, system time will not be set accurately random: unblocking device. and there it sits. I left it for 15 mins to make sure it wasn't just slow. ctrl-alt-del rebooted the pi but other than that, nothing had any effect. ** also, rebooting didn't fix this. Nextboot, when it boots, attempts to zero nextboot.conf but it couldn't do this. In order to get it to boot again I had to remove the config by taking the sd card out and mounting it on another machine. *** How can I make it single user mode? The reason this needs to be done is I need to move some filesystems around. thanks, -- John From owner-freebsd-arm@freebsd.org Sat Sep 12 15:21: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 59B52A018C2 for ; Sat, 12 Sep 2015 15:21:24 +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 3485D1F4F for ; Sat, 12 Sep 2015 15:21:23 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from macbook.chumby.lan (c-71-62-179-114.hsd1.va.comcast.net [71.62.179.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 9F852D39 for ; Sat, 12 Sep 2015 11:21:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: single user mode freebsd11/rpi2 From: Paul Mather In-Reply-To: <20150912150433.GA1204@potato.growveg.org> Date: Sat, 12 Sep 2015 11:21:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1C74A408-4800-4F36-88A3-DE76DB80037B@gromit.dlib.vt.edu> References: <20150912150433.GA1204@potato.growveg.org> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.2104) 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: Sat, 12 Sep 2015 15:21:24 -0000 On Sep 12, 2015, at 11:04 AM, John = wrote: > Hello list, >=20 > I need to either make the system single user node by either becoming > it (as root, shutdown now) or booting into it (either at the boot = prompt or > with nextboot) and I can do neither, so obviously I'm going about this > the wrong way. "shutdown now" never returns a prompt and=20 > "nextboot -o "-s" -k kernel *will* boot the kernel after shutdown -p > but I get no prompt. Last two lines of output: >=20 > warning: no time-of-day clock registered, system time will not be set = accurately > random: unblocking device. >=20 > and there it sits. I left it for 15 mins to make sure it wasn't just = slow. > ctrl-alt-del rebooted the pi but other than that, nothing had any = effect. >=20 > ** also, rebooting didn't fix this. Nextboot, when it boots, attempts = to zero > nextboot.conf but it couldn't do this. In order to get it to boot = again > I had to remove the config by taking the sd card out and mounting it > on another machine. *** >=20 > How can I make it single user mode? The reason this needs to be done = is > I need to move some filesystems around. Are you using a serial console? When you do "shutdown now" it is = probably dropping into the serial console. IIRC, it's the only type of = console supported on the Raspberry Pi right now, though I may be = mistaken. (I've only ever used a serial console on the Raspberry Pi.) Cheers, Paul. From owner-freebsd-arm@freebsd.org Sat Sep 12 15:49: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 75D5DA0250E for ; Sat, 12 Sep 2015 15:49:39 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 3AFF61C9F for ; Sat, 12 Sep 2015 15:49:39 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1Zan3Y-000DsV-8q for freebsd-arm@freebsd.org; Sat, 12 Sep 2015 16:49:36 +0100 Date: Sat, 12 Sep 2015 16:49:36 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: single user mode freebsd11/rpi2 Message-ID: <20150912154936.GB1204@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150912150433.GA1204@potato.growveg.org> <1C74A408-4800-4F36-88A3-DE76DB80037B@gromit.dlib.vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C74A408-4800-4F36-88A3-DE76DB80037B@gromit.dlib.vt.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John 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: Sat, 12 Sep 2015 15:49:39 -0000 On Sat, Sep 12, 2015 at 11:21:16AM -0400, Paul Mather wrote: > Are you using a serial console? When you do "shutdown now" it is probably > dropping into the serial console. IIRC, it's the only type of console supported > on the Raspberry Pi right now, though I may be mistaken. > > (I've only ever used a serial console on the Raspberry Pi.) It's highly likely that I'm being an idiot here. What I have is a keyboard plugged into the pi via the USB and a monitor connected via the HDMI socket. The image I'm using is from here: http://download.raspbsd.org/FreeBSD-armv6-11.0-RPI2-286947.img.gz (main page is http://raspbsd.org) It says: "Designed to be connected to a display and used with a keyboard/mouse. Currently no GUI is enabled." It has a separate section for console images but none are available. Hmmmm. The other way of doing what I want to do is to remove the sdcard and sticks, mount them on another machine and move the filesystems round that way. -- John From owner-freebsd-arm@freebsd.org Sat Sep 12 16:52:20 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 35E4EA02F4D for ; Sat, 12 Sep 2015 16:52:20 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7C8E1620 for ; Sat, 12 Sep 2015 16:52:19 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1442076734; l=1276; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=bGK6M1VOxdKT92UpsrRZQJPdZeBR9kGxLDsloXugtqQ=; b=fPIFQSnv4vR0DXzgJ8j/eBWWYbbtwLK4ivqP1Fm+P6QQMpNXh34yNh4UEBDrEiAFoaB UhgmLWEhfdoMuN5qvDyF+qtEf0FdtGRcYY4/TLBptN/0+piRtolje3y0h1FrHlvUQByUI bKJWhQc050Mt1nBBkhzhVBpmy6V+udM2iAQ= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg48scv/nqmU X-RZG-CLASS-ID: mo00 Received: from quad (p54869580.dip0.t-ipconnect.de [84.134.149.128]) by smtp.strato.de (RZmta 37.12 DYNA|AUTH) with ESMTPSA id Q07bf3r8CGp3VJN (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 12 Sep 2015 18:51:03 +0200 (CEST) Date: Sat, 12 Sep 2015 16:51:02 +0000 From: Ulrich Grey To: freebsd-arm@freebsd.org Subject: Re: single user mode freebsd11/rpi2 Message-Id: <20150912165102.93f556ca42fa9e2c227a6a92@ulrich-grey.de> In-Reply-To: <20150912154936.GB1204@potato.growveg.org> References: <20150912150433.GA1204@potato.growveg.org> <1C74A408-4800-4F36-88A3-DE76DB80037B@gromit.dlib.vt.edu> <20150912154936.GB1204@potato.growveg.org> Organization: - X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; armv6-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 16:52:20 -0000 On Sat, 12 Sep 2015 16:49:36 +0100 John wrote: > On Sat, Sep 12, 2015 at 11:21:16AM -0400, Paul Mather wrote: > > > Are you using a serial console? When you do "shutdown now" it is probably > > dropping into the serial console. IIRC, it's the only type of console supported > > on the Raspberry Pi right now, though I may be mistaken. > > > > (I've only ever used a serial console on the Raspberry Pi.) > > It's highly likely that I'm being an idiot here. > > What I have is a keyboard plugged into the pi via the USB and a monitor > connected via the HDMI socket. > > The image I'm using is from here: > > http://download.raspbsd.org/FreeBSD-armv6-11.0-RPI2-286947.img.gz > (main page is http://raspbsd.org) > > It says: > > "Designed to be connected to a display and used with a keyboard/mouse. > Currently no GUI is enabled." > > It has a separate section for console images but none are available. > Hmmmm. > > The other way of doing what I want to do is to remove the sdcard and > sticks, mount them on another machine and move the filesystems round > that way. > -- > John I think you need a USB to serial adaptor. See thread: https://lists.freebsd.org/pipermail/freebsd-arm/2015-May/011466.html From owner-freebsd-arm@freebsd.org Sat Sep 12 17:41: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 F38EFA025FE for ; Sat, 12 Sep 2015 17:41:14 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9CD6149E for ; Sat, 12 Sep 2015 17:41:14 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id t8CHfdgw055379 for freebsd-arm@freebsd.org; Sat, 12 Sep 2015 17:41:39 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.108] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id 36rnw7uuz4c4gj4g42d58hssi6; for freebsd-arm@freebsd.org; Sat, 12 Sep 2015 17:41:39 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: single user mode freebsd11/rpi2 From: Tim Kientzle In-Reply-To: <20150912150433.GA1204@potato.growveg.org> Date: Sat, 12 Sep 2015 10:41:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150912150433.GA1204@potato.growveg.org> To: freebsd-arm X-Mailer: Apple Mail (2.2104) 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: Sat, 12 Sep 2015 17:41:15 -0000 > On Sep 12, 2015, at 8:04 AM, John = wrote: >=20 > Hello list, >=20 > I need to either make the system single user node by either becoming > it (as root, shutdown now) or booting into it (either at the boot = prompt or > with nextboot) and I can do neither, so obviously I'm going about this > the wrong way. "shutdown now" never returns a prompt and=20 > "nextboot -o "-s" -k kernel *will* boot the kernel after shutdown -p > but I get no prompt. Last two lines of output: >=20 > warning: no time-of-day clock registered, system time will not be set = accurately > random: unblocking device. >=20 > and there it sits. I left it for 15 mins to make sure it wasn't just = slow. > ctrl-alt-del rebooted the pi but other than that, nothing had any = effect. The default system console is the serial console. You'll need one of these (or something equivalent): http://www.adafruit.com/product/954 Here's a good picture showing how to connect it: = http://tinkersphere.com/raspberry-pi-accessories/317-usb-to-ttl-serial-cab= le-for-raspberry-pi-debugging.html Note: The red wire does not need to be connected: If you do connect = it, it will provide power and the board will boot, which may or may not = be what you want. (In particular, if you have USB accessories plugged = into your RPI2, the red wire here may not provide enough power.) This will also give you access to the U-Boot and ubldr prompts. >=20 > How can I make it single user mode? The reason this needs to be done = is > I need to move some filesystems around. If you have another FreeBSD machine, you can mount the SD card there to = do major surgery like this. Cheers, Tim From owner-freebsd-arm@freebsd.org Sat Sep 12 17:43:55 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 4A1E5A02727 for ; Sat, 12 Sep 2015 17:43:55 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25ECF1809 for ; Sat, 12 Sep 2015 17:43:54 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id t8CHiQ5p055408 for freebsd-arm@freebsd.org; Sat, 12 Sep 2015 17:44:26 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.108] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id 98tm4c9p59nsstbeby24b85e5w; for freebsd-arm@freebsd.org; Sat, 12 Sep 2015 17:44:26 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: single user mode freebsd11/rpi2 From: Tim Kientzle In-Reply-To: Date: Sat, 12 Sep 2015 10:44:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8A2D36BC-0BA7-46C8-B4E8-1655A54A3509@kientzle.com> References: <20150912150433.GA1204@potato.growveg.org> To: freebsd-arm X-Mailer: Apple Mail (2.2104) 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: Sat, 12 Sep 2015 17:43:55 -0000 > On Sep 12, 2015, at 10:41 AM, Tim Kientzle wrote: >=20 >> How can I make it single user mode? The reason this needs to be done = is >> I need to move some filesystems around. >=20 > If you have another FreeBSD machine, you can mount the SD card there = to do major surgery like this. >=20 Actually, you don't even need another machine; you can use your existing = RPI2: * Copy the card. * Boot the RPI2 from the copy * Mount the original via any SD <-> USB adapter * Do your changes As a bonus, the copy will serve as a backup in case you get something = wrong. Cheers, Tim From owner-freebsd-arm@freebsd.org Sat Sep 12 19:57: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 5344EA02CAF for ; Sat, 12 Sep 2015 19:57:02 +0000 (UTC) (envelope-from mmitchel@gmail.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 0C42112CF for ; Sat, 12 Sep 2015 19:57:02 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: by qgev79 with SMTP id v79so87792102qge.0 for ; Sat, 12 Sep 2015 12:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3SEhS+cxZwgV6H9HrP3UHYDEukdx4kza5sbkp9wmVn8=; b=FliASXf6OQAPetuW0u1RD/Oo8VQmoNmuCHwww2Ru5akL1yRm9gkN1doANnK9uIdnmm FqggX8+37JCkorK7qVPxNjlRfNlkiWD2gY9cJXtNsCzBs8IdYAP29iAP18f1mCJAZ7+O pKxSCEEI8M5/YsMxmTXdyZKLtB2sUHAU6uaTF/agPEYKSDf25dNZu2qNJ1A4Y6D3POTg 13cP0pm18th6bv7mccLLHPXP/hSxUpqGyW2KsO801Z81zIg14u64k3AT+D/pEvYY3myl i33XKfwR5GGotzwG4vV0yuW6wKN+ak44PcttXmK5qxhAulY3oAWHBZl+k0ZK2Ea+jn2I 6o1g== MIME-Version: 1.0 X-Received: by 10.140.39.73 with SMTP id u67mr8691046qgu.16.1442087820819; Sat, 12 Sep 2015 12:57:00 -0700 (PDT) Received: by 10.55.165.131 with HTTP; Sat, 12 Sep 2015 12:57:00 -0700 (PDT) In-Reply-To: References: <20150912150433.GA1204@potato.growveg.org> Date: Sat, 12 Sep 2015 12:57:00 -0700 Message-ID: Subject: Re: single user mode freebsd11/rpi2 From: Michael Mitchell To: Tim Kientzle Cc: freebsd-arm 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: Sat, 12 Sep 2015 19:57:02 -0000 the Prolific 2303 drivers -- SUXXOR -- on windows. we had to eliminate all use of cables like this in our software lab at work, they actually Blue Screen of Death at the most in opportune time. http://www.ftdichip.com/Products/Cables/RPi.htm These don't have the problem with driver crashes. On Sat, Sep 12, 2015 at 10:41 AM, Tim Kientzle wrote: > > > On Sep 12, 2015, at 8:04 AM, John > wrote: > > > > Hello list, > > > > I need to either make the system single user node by either becoming > > it (as root, shutdown now) or booting into it (either at the boot prompt > or > > with nextboot) and I can do neither, so obviously I'm going about this > > the wrong way. "shutdown now" never returns a prompt and > > "nextboot -o "-s" -k kernel *will* boot the kernel after shutdown -p > > but I get no prompt. Last two lines of output: > > > > warning: no time-of-day clock registered, system time will not be set > accurately > > random: unblocking device. > > > > and there it sits. I left it for 15 mins to make sure it wasn't just > slow. > > ctrl-alt-del rebooted the pi but other than that, nothing had any effect. > > The default system console is the serial console. > > You'll need one of these (or something equivalent): > > http://www.adafruit.com/product/954 > > Here's a good picture showing how to connect it: > > > http://tinkersphere.com/raspberry-pi-accessories/317-usb-to-ttl-serial-cable-for-raspberry-pi-debugging.html > > Note: The red wire does not need to be connected: If you do connect it, > it will provide power and the board will boot, which may or may not be what > you want. (In particular, if you have USB accessories plugged into your > RPI2, the red wire here may not provide enough power.) > > This will also give you access to the U-Boot and ubldr prompts. > > > > > How can I make it single user mode? The reason this needs to be done is > > I need to move some filesystems around. > > If you have another FreeBSD machine, you can mount the SD card there to do > major surgery like this. > > Cheers, > > Tim > > _______________________________________________ > 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" >