From owner-freebsd-arm@freebsd.org Mon Sep 4 14:16:42 2017 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 356B1E09B17 for ; Mon, 4 Sep 2017 14:16:42 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [95.85.46.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CF96B7534A for ; Mon, 4 Sep 2017 14:16:41 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.4] (mail.kronometrix.com [79.134.105.181]) (authenticated bits=0) by mail.kronometrix.org (8.15.2/8.15.2) with ESMTPSA id v84Dov4f060823 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 4 Sep 2017 13:50:57 GMT (envelope-from sparvu@kronometrix.org) X-Authentication-Warning: mail.kronometrix.org: Host mail.kronometrix.com [79.134.105.181] claimed to be [192.168.1.4] From: Stefan Parvu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Strato Server PI FreeBSD 11.1 Release serial port comunication Message-Id: <6989FBCA-5866-4E71-814B-2D850A353824@kronometrix.org> Date: Mon, 4 Sep 2017 16:50:53 +0300 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 14:16:42 -0000 Hi guys, I have installed FreeBSD 11.1 [1] under Strato Server PI [2], a = Raspberry PI2 board plus goodies. FreeBSD 11.1 STABLE is booting fine. Now my problem is to = connect to an indoor air quality sensor, plugged in to a RS485 connector and Im stuck = in discovering whats=20 the correct serial port for that. I have tried /dev/cuau0 but with no = success.=20 root@k50dev:~ # ls -lrt /dev/cuau0* crw-rw---- 1 uucp dialer 0x2d Sep 4 12:22 /dev/cuau0.lock crw-rw---- 1 uucp dialer 0x2c Sep 4 12:22 /dev/cuau0.init crw-rw---- 1 uucp dialer 0x2b Sep 4 12:22 /dev/cuau0 I know all parameters set on the device level, baudrate, stopbits, = parity since I have tried it under Raspbian and it is working fine there. Im basically using Kronometrix = data recording rs485rec [3] fo that. Any ideas how can I discover the port, and debug it somehow ? thanks, Stefan [1] = http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.1/FreeBSD-11.1-= STABLE-arm-armv6-RPI2-20170822-r322788.img.xz [2] https://www.sferalabs.cc/strato-pi/=20 [3] https://github.com/kronometrix/recording/blob/master/bin/rs485rec=20 From owner-freebsd-arm@freebsd.org Mon Sep 4 14:34:38 2017 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 6D74BE0A84C for ; Mon, 4 Sep 2017 14:34:38 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 E33F675ED5 for ; Mon, 4 Sep 2017 14:34:37 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x242.google.com with SMTP id m199so294810lfe.5 for ; Mon, 04 Sep 2017 07:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=P180DWwThFY/jtqN70h6vc9AGLghkIYGmnx2b9ZvoZM=; b=psYsUIxYSix50sbHk8Mjfvr3nHygHlmmtjryGeY9fGR069/cax5IB2plQ6UtN5fuHZ zChwAABlPAeXMLSZb83aOFQINEJiv6ba2ITkKLRlaxnK521bPCcoM9W53pegBujxTIj4 kgFh20ip8cL2dDN6YlED5gk+JC131gzPEKOE/hpKZnStl1Hv2Q0ORQH2RqHGNcShDm6M LSKl8fdvNatGcl7XH4chaOR2hAHgrBDGpqsaWBCnQXJ//MKjV9404W5+eadB7hwQbyT/ c1ns3A9HUugmXsQs2nc2Mc8sB4Px7nxoREfLLCaDLr4zuOXy6VpmLtaZsbUA/+6X0Zbt XDyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=P180DWwThFY/jtqN70h6vc9AGLghkIYGmnx2b9ZvoZM=; b=VaaZnqd8Af68zsLme+Pgpni4bF631CKithPvYyLXGslOolh6oVW1r3Is/xPqlLBpz+ AvbWCVORgYCQtDq8CHghKOcNEpH9cZ5I7ONXa8gza5wxIuTW0uo6OMCZYEyBsQ7EBbVl sKlu6jMeROI6SdbjHpJkjbNi3aMfm+ldB5BmFGb/xIAXyIhzm7DdOUC0h5P8KAX8afkC y61PBTbs0M/QRLLu5mlymqhTfsfZgfb622z9PHn6HyDdHA4D4b8fcpEr7ET0gPd64Q06 S9Czobn42XNa27lCTQdQqsD/ze94lu0BvrtfrNt0nTNnXoptbpcDSZYRr33dao4t1qMQ Ezcg== X-Gm-Message-State: AHPjjUiXZ0lXNApT0Uvu5vpshvAPP6jku9G19iuiYXVNHsAlVesKkC73 9GYbSqZ7X948dmmB X-Google-Smtp-Source: ADKCNb4VZLpB4DNZkT//u0m7LSruj45valU5prU+BvY+SBr7mz1XlKOeQcICU4YvnWnWdewJN1faUA== X-Received: by 10.25.202.17 with SMTP id a17mr238010lfg.176.1504535675557; Mon, 04 Sep 2017 07:34:35 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id t13sm1279529lfe.32.2017.09.04.07.34.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 07:34:35 -0700 (PDT) Subject: Re: Strato Server PI FreeBSD 11.1 Release serial port comunication To: freebsd-arm@freebsd.org References: <6989FBCA-5866-4E71-814B-2D850A353824@kronometrix.org> From: "Jukka A. Ukkonen" Message-ID: <9bf992d9-9a22-c7a0-5a78-54c779880a6d@gmail.com> Date: Mon, 4 Sep 2017 17:34:34 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6989FBCA-5866-4E71-814B-2D850A353824@kronometrix.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 14:34:38 -0000 On 09/04/17 16:50, Stefan Parvu wrote: > Hi guys, > > I have installed FreeBSD 11.1 [1] under Strato Server PI [2], a Raspberry PI2 board plus > goodies. FreeBSD 11.1 STABLE is booting fine. Now my problem is to connect to an > indoor air quality sensor, plugged in to a RS485 connector and Im stuck in discovering whats > the correct serial port for that. I have tried /dev/cuau0 but with no success. > > root@k50dev:~ # ls -lrt /dev/cuau0* > crw-rw---- 1 uucp dialer 0x2d Sep 4 12:22 /dev/cuau0.lock > crw-rw---- 1 uucp dialer 0x2c Sep 4 12:22 /dev/cuau0.init > crw-rw---- 1 uucp dialer 0x2b Sep 4 12:22 /dev/cuau0 > > I know all parameters set on the device level, baudrate, stopbits, parity since I have tried it under > Raspbian and it is working fine there. Im basically using Kronometrix data recording rs485rec [3] > fo that. > > Any ideas how can I discover the port, and debug it somehow ? > > thanks, > Stefan > > [1] http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.1/FreeBSD-11.1-STABLE-arm-armv6-RPI2-20170822-r322788.img.xz > [2] https://www.sferalabs.cc/strato-pi/ > [3] https://github.com/kronometrix/recording/blob/master/bin/rs485rec > > _______________________________________________ > 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" > What are the other /dev/cua* devices on your system? Quite often various USB connected gizmos I have tried end up under names like /dev/cuaU0 or /dev/cuaU1 etc. --jau From owner-freebsd-arm@freebsd.org Mon Sep 4 14:41:55 2017 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 931F6E0ADB1 for ; Mon, 4 Sep 2017 14:41:55 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [95.85.46.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 391DF7620D for ; Mon, 4 Sep 2017 14:41:54 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.4] (mail.kronometrix.com [79.134.105.181]) (authenticated bits=0) by mail.kronometrix.org (8.15.2/8.15.2) with ESMTPSA id v84Efp8w061030 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Sep 2017 14:41:52 GMT (envelope-from sparvu@kronometrix.org) X-Authentication-Warning: mail.kronometrix.org: Host mail.kronometrix.com [79.134.105.181] claimed to be [192.168.1.4] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Strato Server PI FreeBSD 11.1 Release serial port comunication From: Stefan Parvu In-Reply-To: <9bf992d9-9a22-c7a0-5a78-54c779880a6d@gmail.com> Date: Mon, 4 Sep 2017 17:41:46 +0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1AD403B4-F974-4734-BE0A-40717FA34E9E@kronometrix.org> References: <6989FBCA-5866-4E71-814B-2D850A353824@kronometrix.org> <9bf992d9-9a22-c7a0-5a78-54c779880a6d@gmail.com> To: "Jukka A. Ukkonen" X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 14:41:55 -0000 >=20 > What are the other /dev/cua* devices on your system? > Quite often various USB connected gizmos I have tried > end up under names like /dev/cuaU0 or /dev/cuaU1 etc. Nothing else. I do have just that. I have tried as well to play with a FTDI USB connector (plugs in to the = USB port) and that works fine. So basically I can connect my IAQ sensor on such = USB to=20 Serial RS485 connector and yes, I do get some: /dev/cuaU0 device easily = that case. But my problem is if I want to directly plug the IAQ sensor to the RS485 = board=20 provided by SferaLabs without using such FTDI USB connector. The = SferaLabs is basically another board which connects to the GPIO ports of the RBPI2.=20 I cant make it run nor detect anything. Wonder if there is something = else on the kernel to make it happen Stefan= From owner-freebsd-arm@freebsd.org Mon Sep 4 16:49:57 2017 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 214F2E11448 for ; Mon, 4 Sep 2017 16:49:57 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 054E97DFDF for ; Mon, 4 Sep 2017 16:49:56 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 02f4f5bb-9191-11e7-b49e-71a67e0dab63 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 02f4f5bb-9191-11e7-b49e-71a67e0dab63; Mon, 04 Sep 2017 16:49:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v84Gnr79007920; Mon, 4 Sep 2017 10:49:54 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1504543793.41612.69.camel@freebsd.org> Subject: Re: Strato Server PI FreeBSD 11.1 Release serial port comunication From: Ian Lepore To: Stefan Parvu , freebsd-arm@freebsd.org Date: Mon, 04 Sep 2017 10:49:53 -0600 In-Reply-To: <6989FBCA-5866-4E71-814B-2D850A353824@kronometrix.org> References: <6989FBCA-5866-4E71-814B-2D850A353824@kronometrix.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 16:49:57 -0000 On Mon, 2017-09-04 at 16:50 +0300, Stefan Parvu wrote: > Hi guys, > > I have installed FreeBSD 11.1 [1] under Strato Server PI [2], a > Raspberry PI2 board plus > goodies. FreeBSD 11.1 STABLE is booting fine. Now my problem is to > connect to an > indoor air quality sensor, plugged in to a RS485 connector and Im > stuck in discovering whats  > the correct serial port for that. I have tried /dev/cuau0 but with no > success.  > > root@k50dev:~ # ls -lrt /dev/cuau0* > crw-rw----  1 uucp  dialer  0x2d Sep  4 12:22 /dev/cuau0.lock > crw-rw----  1 uucp  dialer  0x2c Sep  4 12:22 /dev/cuau0.init > crw-rw----  1 uucp  dialer  0x2b Sep  4 12:22 /dev/cuau0 > > I know all parameters set on the device level, baudrate, stopbits, > parity since I have tried it under > Raspbian and it is working fine there. Im basically using Kronometrix > data recording rs485rec [3] > fo that. > > Any ideas how can I discover the port, and debug it somehow ? > > thanks, > Stefan > > [1] http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.1/Free > BSD-11.1-STABLE-arm-armv6-RPI2-20170822-r322788.img.xz > [2] https://www.sferalabs.cc/strato-pi/  > [3] https://github.com/kronometrix/recording/blob/master/bin/rs485rec >   I think /dev/cuau0 is the right device, but maybe the system is using it as a console and has a getty active on the port.  Try editing /etc/ttys and in this line: ttyu0   "/usr/libexec/getty 3wire"      vt100   onifconsole  secure Change "onifconsole" to "off".  That should leave the device free for other software to access. -- Ian From owner-freebsd-arm@freebsd.org Mon Sep 4 16:50:17 2017 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 EFA1DE11483 for ; Mon, 4 Sep 2017 16:50:17 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 89DEC7E03D for ; Mon, 4 Sep 2017 16:50:17 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id v84Go9BM034315 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Sep 2017 18:50:10 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id v84Go7eh036242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Sep 2017 18:50:07 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTPS id v84Go7ZM078726 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Sep 2017 18:50:07 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v84Go6HW078725; Mon, 4 Sep 2017 18:50:06 +0200 (CEST) (envelope-from ticso) Date: Mon, 4 Sep 2017 18:50:06 +0200 From: Bernd Walter To: Stefan Parvu Cc: "Jukka A. Ukkonen" , freebsd-arm@freebsd.org Subject: Re: Strato Server PI FreeBSD 11.1 Release serial port comunication Message-ID: <20170904165005.GB18101@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <6989FBCA-5866-4E71-814B-2D850A353824@kronometrix.org> <9bf992d9-9a22-c7a0-5a78-54c779880a6d@gmail.com> <1AD403B4-F974-4734-BE0A-40717FA34E9E@kronometrix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AD403B4-F974-4734-BE0A-40717FA34E9E@kronometrix.org> X-Operating-System: FreeBSD cicely7.cicely.de 11.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED=-1, RP_MATCHES_RCVD=-0.001 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 16:50:18 -0000 On Mon, Sep 04, 2017 at 05:41:46PM +0300, Stefan Parvu wrote: > > > > What are the other /dev/cua* devices on your system? > > Quite often various USB connected gizmos I have tried > > end up under names like /dev/cuaU0 or /dev/cuaU1 etc. > > Nothing else. I do have just that. > > I have tried as well to play with a FTDI USB connector (plugs in to the USB port) > and that works fine. So basically I can connect my IAQ sensor on such USB to > Serial RS485 connector and yes, I do get some: /dev/cuaU0 device easily that case. > > But my problem is if I want to directly plug the IAQ sensor to the RS485 board > provided by SferaLabs without using such FTDI USB connector. The SferaLabs is basically > another board which connects to the GPIO ports of the RBPI2. > > I cant make it run nor detect anything. Wonder if there is something else on the kernel > to make it happen The schematic (looked at the BASE/UPS) is quite clear. It uses the one and only onboard UART, so cuau0 is correct, but under FreeBSD that uart is already in use as the console. You can use conscontrol to temporarily relocate the console, which should allow you to use the uart. The TXenable line seems to be autogenerated by the PIC microcontroller, so I assume you don't need to care about it. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Sep 4 21:52:34 2017 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 53077E208C2 for ; Mon, 4 Sep 2017 21:52:34 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [95.85.46.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EB7CE63538 for ; Mon, 4 Sep 2017 21:52:33 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.53] (87-92-38-14.bb.dnainternet.fi [87.92.38.14]) (authenticated bits=0) by mail.kronometrix.org (8.15.2/8.15.2) with ESMTPSA id v84LqUD2062328 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 4 Sep 2017 21:52:31 GMT (envelope-from sparvu@kronometrix.org) X-Authentication-Warning: mail.kronometrix.org: Host 87-92-38-14.bb.dnainternet.fi [87.92.38.14] claimed to be [192.168.1.53] From: Stefan Parvu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Strato Server PI FreeBSD 11.1 Release serial port comunication Date: Tue, 5 Sep 2017 00:52:25 +0300 References: <6989FBCA-5866-4E71-814B-2D850A353824@kronometrix.org> <9bf992d9-9a22-c7a0-5a78-54c779880a6d@gmail.com> <1AD403B4-F974-4734-BE0A-40717FA34E9E@kronometrix.org> <20170904165005.GB18101@cicely7.cicely.de> To: freebsd-arm@freebsd.org In-Reply-To: <20170904165005.GB18101@cicely7.cicely.de> Message-Id: <5A298353-8098-4EF4-86EF-4ABCD6DC7724@kronometrix.org> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 21:52:34 -0000 Done. Indeed the device was in fact the default, /dev/cuau0 but the=20 console would not allow me to use it. After changing ttys file = everything started to work. krmx@k50dev:~ % /opt/kronometrix/bin/rs485rec 10 2 1504561878:msd1618_1:27.31:31.89:9.10:443.00:0.10:0.60:0.60 1504561888:msd1618_1:27.31:31.89:9.10:443.00:0.10:0.60:0.60 Thanks Ian, Bernd. Stefan= From owner-freebsd-arm@freebsd.org Tue Sep 5 06:42:00 2017 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 75A31E1D5C5 for ; Tue, 5 Sep 2017 06:42:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 646357E843 for ; Tue, 5 Sep 2017 06:42:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v856g0nj015375 for ; Tue, 5 Sep 2017 06:42:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 222062] unknown file system -> mountroot when booting aarm64 from ZFS Date: Tue, 05 Sep 2017 06:42:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: heinz@project-fifo.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 06:42:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222062 Bug ID: 222062 Summary: unknown file system -> mountroot when booting aarm64 from ZFS Product: Base System Version: 11.1-STABLE Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: heinz@project-fifo.net Installing a zfs root on a ThunderX w/ auto-ZFS disk layout the following error is printed on the first boot Trying to mount root from zfs:zroot/ROOT/default []... Mounting from zfs:zroot/ROOT/default failed with error 2: unknown file syst= em. Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2 on uhub0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3 on uhub1 uhub3: on usbus1 uhub3: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 usbus0 uhub2: 5 ports with 5 removable, self powered ugen1.3: at usbus1 uhub4 on uhub1 uhub4: on usbus1 uhub4: 4 ports with 4 removable, self powered ugen0.3: at usbus0 ukbd0 on uhub2 ukbd0: on usbus0 kbd0 at ukbd0 then mountroot is opend. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Sep 5 20:01:09 2017 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 A5A05E1C64F for ; Tue, 5 Sep 2017 20:01:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 323A07E20A for ; Tue, 5 Sep 2017 20:01:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12278 invoked from network); 5 Sep 2017 19:54:28 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Sep 2017 19:54:28 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 05 Sep 2017 15:54:28 -0400 (EDT) Received: (qmail 8028 invoked from network); 5 Sep 2017 19:54:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Sep 2017 19:54:27 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id EFF64EC94DA; Tue, 5 Sep 2017 12:54:26 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like Message-Id: <5CAB42C9-984A-4BC9-A4CC-4BDD74932084@dsl-only.net> Date: Tue, 5 Sep 2017 12:54:26 -0700 Cc: FreeBSD Toolchain To: freebsd-arm , x11@FreeBSD.org, FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:01:09 -0000 In an experiment with building some arm ports via poudriere cross building on amd64 I got the following. It appears that clang does not handle all the assembler notation and a different assembler might need to be used for x11/pixman . (The x11/pixman usage is indirect from having specified x11/lumina and x11/xscreensaver ). --- pixman-arm-simd-asm.lo --- /bin/sh ../libtool --mode=3Dcompile /nxb-bin/usr/bin/cc = -DHAVE_CONFIG_H -I. -I.. -mcpu=3Dcortex-a7 -O2 -pipe = -mcpu=3Dcortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo = -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo = pixman-arm-simd-asm.S libtool: compile: /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. = -mcpu=3Dcortex-a7 -O2 -pipe -mcpu=3Dcortex-a7 -g -fno-strict-aliasing = -MT pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c = pixman-arm-simd-asm.S -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o :1:1: error: unknown directive . . . --- pixman-arm-simd-asm.lo --- .func fname ^ ./pixman-arm-simd-asm.h:599:5: note: while in macro instantiation pixman_asm_function fname ^ /tmp/pixman-arm-simd-asm-b59328.s:910:1: note: while in macro = instantiation generate_composite_function pixman_composite_src_8888_8888_asm_armv6, = 32, 0, 32, FLAG_DST_WRITEONLY | FLAG_COND_EXEC | = FLAG_SPILL_LINE_VARS_WIDE | FLAG_PROCESS_PRESERVES_SCRATCH, 4, = blit_init, nop_macro, nop_macro, blit_process_head, nop_macro, = blit_inner_loop ^ ./pixman-arm-simd-asm.h:614:6: error: expected absolute expression .if prefetch_distance =3D=3D 0 ^ /tmp/pixman-arm-simd-asm-b59328.s:910:1: note: while in macro = instantiation generate_composite_function pixman_composite_src_8888_8888_asm_armv6, = 32, 0, 32, FLAG_DST_WRITEONLY | FLAG_COND_EXEC | = FLAG_SPILL_LINE_VARS_WIDE | FLAG_PROCESS_PRESERVES_SCRATCH, 4, = blit_init, nop_macro, nop_macro, blit_process_head, nop_macro, = blit_inner_loop ^ ./pixman-arm-simd-asm.h:620:6: error: expected absolute expression .if src_bpp =3D=3D 32 ^ . . . (I've omitted much later material continuing to reject notation.) (A variant build without the -mcpu=3Dcortex-a7 usage got the same.) The context for the above is from a poudriere/qemu-user-static/native_xtools based cross build from amd64: poudriere jail -c -j zrFBSDx64CjailArmV7 -a arm.armv6 -x -m null -M = /usr/obj/DESTDIRs/clang-armv7-installworld-poud -S /usr/src -v = 12.0-CURRENT poudriere bulk -j zrFBSDx64CjailArmV7 -w -f /root/armv7-origins.txt The -x use was enabled for -m null via: /usr/local/share/poudriere/jail.sh having a "build_native_xtools" added: null) JAILFS=3Dnone FCT=3Dbuild_native_xtools ;; # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r323147M amd64 = amd64 1200043 1200043 /usr/obj/DESTDIRs/clang-armv7-installworld-poud is from an arm/armv6 build of the same sources using -mcpu=3Dcortex-a7 , installed via installworld distrib-dirs distribution DB_FROM_SRC=3D1 DESTDIR=3D. . . : # more ~/src.configs/src.conf.armv7-clang-bootstrap.amd64-host=20 TO_TYPE=3Darmv6 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv6(/v7) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. The source variations are almost all for powerpc family explorations: # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/Makefile M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/boot1.chrp/Makefile M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 449165 Last Changed Rev: 449165 # svnlite status /usr/ports/ | sort M /usr/ports/Mk/bsd.port.mk M /usr/ports/base/gcc/Makefile M /usr/ports/base/gcc/distinfo M /usr/ports/base/gcc/pkg-plist M /usr/ports/devel/libunwind/Makefile M /usr/ports/sysutils/cdrdao/Makefile # more /usr/local/etc/poudriere.d/make.conf WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D7 # # =46rom a local /usr/ports/Mk/bsd.port.mk extension: ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D # .if ${.CURDIR:M*/devel/llvm*} #WITH_DEBUG=3D .elif ${.CURDIR:M*/www/webkit-qt5*} #WITH_DEBUG=3D .else WITH_DEBUG=3D .endif MALLOC_PRODUCTION=3D # more /usr/local/etc/poudriere.d/zrFBSDx64CjailArmV7-make.conf = = =20 CFLAGS+=3D -mcpu=3Dcortex-a7 CXXFLAGS+=3D -mcpu=3Dcortex-a7 CPPFLAGS+=3D -mcpu=3Dcortex-a7 As for that "ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG" I have in /usr/ports/Mk/bsd.port.mk : STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif I've also had trouble in some contexts with where bad.port.mk uses ${UNAME} (empty string results) and so have forced the expected content to match the context that this is in: # Get the architecture .if !defined(ARCH) -ARCH!=3D ${UNAME} -p +ARCH!=3D echo amd64 .endif _EXPORTED_VARS+=3D ARCH =20 # Get the operating system type .if !defined(OPSYS) -OPSYS!=3D ${UNAME} -s +OPSYS!=3D echo FreeBSD .endif _EXPORTED_VARS+=3D OPSYS =20 .if !defined(_OSRELEASE) -_OSRELEASE!=3D ${UNAME} -r +_OSRELEASE!=3D echo 12.0-CURRENT .endif _EXPORTED_VARS+=3D _OSRELEASE =20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Sep 5 20:13:15 2017 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 344D1E1CF11; Tue, 5 Sep 2017 20:13:15 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1C0C80DEC; Tue, 5 Sep 2017 20:13:14 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 8CFB41DF04; Tue, 5 Sep 2017 20:13:11 +0000 (UTC) From: Jan Beich To: Mark Millard Cc: freebsd-arm , x11@FreeBSD.org, FreeBSD Ports , FreeBSD Toolchain Subject: Re: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like References: <5CAB42C9-984A-4BC9-A4CC-4BDD74932084__24380.8804465973$1504641758$gmane$org@dsl-only.net> Date: Tue, 05 Sep 2017 22:13:05 +0200 In-Reply-To: <5CAB42C9-984A-4BC9-A4CC-4BDD74932084__24380.8804465973$1504641758$gmane$org@dsl-only.net> (Mark Millard's message of "Tue, 5 Sep 2017 12:54:26 -0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:13:15 -0000 Mark Millard writes: > In an experiment with building some arm ports via poudriere > cross building on amd64 I got the following. It appears that > clang does not handle all the assembler notation and a > different assembler might need to be used for x11/pixman . > (The x11/pixman usage is indirect from having specified > x11/lumina and x11/xscreensaver ). > > --- pixman-arm-simd-asm.lo --- > /bin/sh ../libtool --mode=compile /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O2 -pipe -mcpu=cortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo pixman-arm-simd-asm.S > libtool: compile: /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O2 -pipe -mcpu=cortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c pixman-arm-simd-asm.S -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o > :1:1: error: unknown directive > . . . > --- pixman-arm-simd-asm.lo --- > .func fname > ^ Does it still happen after https://svnweb.freebsd.org/changeset/ports/449285 ? From owner-freebsd-arm@freebsd.org Tue Sep 5 20:33:10 2017 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 6137CE1DDD7 for ; Tue, 5 Sep 2017 20:33:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 7B402180E for ; Tue, 5 Sep 2017 20:33:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21233 invoked from network); 5 Sep 2017 20:33:07 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Sep 2017 20:33:07 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 05 Sep 2017 16:33:07 -0400 (EDT) Received: (qmail 1764 invoked from network); 5 Sep 2017 20:33:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Sep 2017 20:33:07 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 818F8EC807E; Tue, 5 Sep 2017 13:33:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like From: Mark Millard In-Reply-To: Date: Tue, 5 Sep 2017 13:33:05 -0700 Cc: freebsd-arm , x11@FreeBSD.org, FreeBSD Ports , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <8A60350E-0D95-4D47-A7E8-6AF1A7727A93@dsl-only.net> References: <5CAB42C9-984A-4BC9-A4CC-4BDD74932084__24380.8804465973$1504641758$gmane$org@dsl-only.net> To: Jan Beich X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:33:10 -0000 On 2017-Sep-5, at 1:13 PM, Jan Beich wrote: > Mark Millard writes: >=20 >> In an experiment with building some arm ports via poudriere >> cross building on amd64 I got the following. It appears that >> clang does not handle all the assembler notation and a >> different assembler might need to be used for x11/pixman . >> (The x11/pixman usage is indirect from having specified >> x11/lumina and x11/xscreensaver ). >>=20 >> --- pixman-arm-simd-asm.lo --- >> /bin/sh ../libtool --mode=3Dcompile /nxb-bin/usr/bin/cc = -DHAVE_CONFIG_H -I. -I.. -mcpu=3Dcortex-a7 -O2 -pipe = -mcpu=3Dcortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo = -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo = pixman-arm-simd-asm.S >> libtool: compile: /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. = -mcpu=3Dcortex-a7 -O2 -pipe -mcpu=3Dcortex-a7 -g -fno-strict-aliasing = -MT pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c = pixman-arm-simd-asm.S -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o >> :1:1: error: unknown directive >> . . . >> --- pixman-arm-simd-asm.lo --- >> .func fname >> ^ >=20 > Does it still happen after = https://svnweb.freebsd.org/changeset/ports/449285 ? I'll let you know. But it will be a while for the results: I just started another build experiment with: poudriere bulk -j zrFBSDx64CjailArmV7 -w -c -f ~/armv7-origins.txt This is based on /usr/ports having -r449313 . (I updated based on your question.) It will likely take 2-4 hours to get that far in the 338 packages it is attempting to build. (I'm more experimenting with building than using the results currently. Previously my port builds were all native and via portmaster .) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Sep 5 20:49:59 2017 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 36E8AE1E97C for ; Tue, 5 Sep 2017 20:49:59 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010: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 7CEE564725 for ; Tue, 5 Sep 2017 20:49:58 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id m199so13503556lfe.3 for ; Tue, 05 Sep 2017 13:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=tqUOalbGWrjZL5Ww7kIDx1o43gAznPX6VNsfG7pi194=; b=seJLAJwpgWPxRrDaOxU1XKc00UgxrW2GBUtR9xUkpdR30DUhuhjKf6JxyZrXmQqK4W H0RoW3R4Gs4PmpM4BNQBn1MJDhv+Z0MpyRBwzKtn4ENCwCztwc0N+CmVhtgUs2MVFJ++ H6dU2Q0KvGxPyTDY1dlo9JrW8jzcgLmxxx5+tP7g8GK1LBfBOsQA/uBtiDOZUfraFVcU ojHo/5Vn4VD2/vVd4ZHfaV2yAcUtNkDPm/iTIYN1c4BFHPmKsuDQa1mAZa1YDg3aIk72 a8V9a9iq5D4IuTvnKMS0/lCHvGiZ4Vv0VzNp+b5C8/oGMF4kBCSY09MrUQ6WrmuvSTx/ O8RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=tqUOalbGWrjZL5Ww7kIDx1o43gAznPX6VNsfG7pi194=; b=AZAX3ZrYeqckF2OWbVUqBT9hBMZVIhgoPKudi7VPJfnWfrcPE64c3zYOaRq2/TATWU t743f01CC7pP5aaAZW4JG+EE4PoO7J2z/0/Hgyrv5gllrUGVlgzhqB8Zy9pmz49cz32M Bz9opadjrSkacSpSPNLtwa78Opjgju8gpjd9F9ViHbcF802KdPLvxUvdRWE6oePVEdz7 hGddDIC7XtDd/7r+pfstvaNTa6aApAlvvqsJZ+JnwLQPU7JLuFLxu8Mm4fpd5Mun5cFZ kkJ1aZNSLHuWVfdJPCBSh2RYKrfYYjyGRp4RY1iVvuGRhZ3N1pn3++2sAKBdXHrXk3UG cDjg== X-Gm-Message-State: AHPjjUh0Ju7NA8gG2SMArP8RIqmFx1A9b70xV5fnBa/lxS2uIj94cziE O/1m6HOcin2nY49EVQFYbVew3p2CgUsT X-Google-Smtp-Source: ADKCNb46oBUIui5Z4p+fczOa9HZHef/zQ3ZRP8kxaGUBSKK4dmAbrDpB9qJuZmugdsNaQhUK1rkmoK5jaB8YHKyVkbA= X-Received: by 10.46.71.68 with SMTP id u65mr132424lja.22.1504644596198; Tue, 05 Sep 2017 13:49:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Tue, 5 Sep 2017 13:49:55 -0700 (PDT) From: Russell Haley Date: Tue, 5 Sep 2017 13:49:55 -0700 Message-ID: Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? To: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:49:59 -0000 This got sent only to Chris by accident so I am forwarding it to the mailing list. Comment below... Russ ---------- Forwarded message ---------- From: Russell Haley Date: Mon, Sep 4, 2017 at 10:59 PM Subject: Re: Beaglebone Black + FreeBSD + USB WiFi =3D WAP? To: Chris Gordon On Mon, Sep 4, 2017 at 10:50 PM, Russell Haley wrote= : > On Sat, Aug 26, 2017 at 11:48 PM, Russell Haley wr= ote: >> On Sat, Aug 26, 2017 at 11:35 PM, Russell Haley w= rote: >>> On Thu, Aug 24, 2017 at 11:26 PM, Russell Haley = wrote: >>>> On Tue, Aug 22, 2017 at 5:51 PM, Chris Gordon w= rote: >>>>> Ilya, >>>>> >>>>> Thanks for the follow up. >>>>> >>>>>> On Aug 22, 2017, at 3:11 PM, Ilya Bakulin wrote: >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> have you found the issue already? >>>>> >>>>> I have not. See below for some theories... >>>>> >>>>>> If not: what does `top -Sa` show when you're running your speed test= ? >>>>>> Specifically what does "CPU:" line look like, and what are the top p= rocesses in the list? >>>>> >>>>> The system stays at >90% idle through the entire test (upload and dow= nload). I see 2-4% WCPU for interrupts and 1-2% for USB. >>>>> >>>>>> I've had an issue with FreeBSD acting as WAP (although using Atheros= -based NIC) some years ago, >>>>>> the problem back then was that the machine CPU was just too slow to = process the traffic. >>>>> >>>>> I had initially thought that maybe the little CPU in the BeagleBone w= asn=E2=80=99t up to the WPA encryption or the interrupt rate + usb where ju= st too much for it. Sometimes changing channels helps for a little bit. S= ince I=E2=80=99ve been tinkering with this little project, I=E2=80=99ve bee= n paying a bit more attention to my overall WiFi performance and I=E2=80=99= m beginning to think there are just too many WiFi signals nearby and conges= tion is just killing my overall WiFi performance. >>>>> >>>>> Any other ideas? >>>> >>>> Hi, I'm just trying to reproduce your setup with my BBB and an ASUS >>>> wi-fi stick. The chipset is Ralink RT3052. I just got the dongle >>>> working so I'll see if I can set it up as an access point this >>>> weekend. I can't make any promises on play time though. :) >>> >>> >>> >>> Hi! >>> >>> So I'm only partially successful repeating your test so far, but I can >>> cause a kernel panic! The following are my observations: >>> >>> Running BBB through ftdi cable. >>> Asus WiFi Adapter, RT3071 chipset >>> https://wikidevi.com/files/Ralink/RT307x%20product%20brief.pdf >>> >>> root@bbb:~ # uname -a >>> FreeBSD bbb.highfell.local 12.0-CURRENT FreeBSD 12.0-CURRENT #7 >>> r321601M: Thu Aug 17 22:13:21 PDT 2017 >>> russellh@prescott.highfell.local:/usr/home/russellh/FreeBSD/rh-armv6/ob= j/arm.armv6/usr/home/russellh/FreeBSD/rh-armv6/src/sys/BEAGLEBONE-MMCCAM >>> arm >>> >>> root@bbb:~ # cat /boot/loader.conf >>> if_run0_load=3D"YES" >>> wlan_mac_load=3D"YES" >>> >>> root@bbb:~ # cat /etc/rc.conf >>> hostname=3D"bbb.highfell.local" >>> ifconfig_cpsw0=3D"inet 192.168.2.101 netmask 255.255.255.0" >>> defaultrouter=3D"192.168.2.1" >>> hostapd_enable=3D"YES" >>> wlans_run0=3D"wlan0" >>> create_args_wlan0=3D"wlanmode hostap" >>> ifconfig_wlan0=3D"up" >>> #gateway_enable=3D"YES" >>> cloned_interfaces=3D"bridge0" >>> ifconfig_bridge0=3D"addm cpsw0 addm wlan0 up" >>> >>> sshd_enable=3D"YES" >>> sendmail_enable=3D"NONE" >>> sendmail_submit_enable=3D"NO" >>> sendmail_outbound_enable=3D"NO" >>> sendmail_msp_queue_enable=3D"NO" >>> growfs_enable=3D"YES" >>> >>> >>> >>> root@bbb:~ # cat /etc/hostapd.conf >>> interface=3Dwlan0 >>> debug=3D1 >>> ctrl_interface=3D/var/run/hostapd >>> ctrl_interface_group=3Dwheel >>> ssid=3Dfreebsd >>> wpa=3D2 >>> wpa_passphrase=3Dtesting >>> wpa_key_mgmt=3DWPA-PSK >>> wpa_pairwise=3DCCMP >>> >>> root@bbb:~ # cat /etc/resolv.conf >>> # Generated by resolvconf >>> nameserver 192.168.2.1 >>> >>> >>> 1) Before the kernel loads, loader give the following errors: >>> >>> can't find 'if_run' >>> can't find 'wlan_mac' >>> >>> 2) It seems the run0 usb wi-fi interface only comes up after the >>> bridge0 is already enabled. dmesg does NOT capture the output from the >>> failed attempt to add the non-existent wlan0 interface. However, I >>> grabbed it from the boot output in the serial console: >>> >>> #From dmesg: >>> >>> ugen1.2: at usbus1 >>> random: unblocking device. >>> bridge0: Ethernet address: 02:94:dd:d7:a3:00 >>> cpsw0: link state changed to DOWN >>> cpsw0: promiscuous mode enabled >>> bridge0: link state changed to DOWN >>> cpsw0: link state changed to UP >>> bridge0: link state changed to UP >>> run0 on uhub1 >>> run0: <1.0> on usbus1 >>> run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address >>> 60:a4:4c:ec:c9:a5 >>> ieee80211_load_module: load the wlan_amrr module by hand for now. >>> wlan0: Ethernet address: 60:a4:4c:ec:c9:a5 >>> run0: firmware RT3071 ver. 0.33 loaded >>> >>> #From console grab: >>> >>> eeding entropy: . >>> ifconfig: SIOCIFCREATE2: Invalid argument >>> bridge0: Ethernet address: 02:94:dd:d7:a3:00 >>> Created clone interfaces: bridge0. >>> cpsw0: link state changed to DOWN >>> cpsw0: promiscuous mode enabled >>> bridge0: link state changed to DOWN >>> ifconfig: BRDGADD wlan0: No such file or directory >>> cpsw0: link state changed to UP >>> bridge0: link state changed to UP >>> Starting Network: lo0 cpsw0 bridge0. >>> lo0: flags=3D8049 metric 0 mtu 16384 >>> options=3D600003 >>> inet6 ::1 prefixlen 128 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >>> inet 127.0.0.1 netmask 0xff000000 >>> groups: lo >>> nd6 options=3D21 >>> cpsw0: flags=3D8943 >>> metric 0 mtu 1500 >>> options=3D8000b >>> ether a0:f6:fd:8a:c5:be >>> hwaddr a0:f6:fd:8a:c5:be >>> inet 192.168.2.101 netmask 0xffffff00 broadcast 192.168.2.255 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> nd6 options=3D29 >>> bridge0: flags=3D8843 metric 0 = mtu 1500 >>> ether 02:94:dd:d7:a3:00 >>> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >>> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >>> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >>> member: cpsw0 flags=3D143 >>> ifmaxaddr 0 port 1 priority 128 path cost 55 >>> groups: bridge >>> nd6 options=3D9 >>> Starting devd. >>> run0 on uhub1 >>> run0: <1.0> on usbus1 >>> run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address >>> 60:a4:4c:ec:c9:a5 >>> ieee80211_load_module: load the wlan_amrr module by hand for now. >>> wlan0: Ethernet address: 60:a4:4c:ec:c9:a5 >>> Created wlan(4) interfaces: wlan0. >>> run0: firmware RT3071 ver. 0.33 loaded >>> Starting Network: wlan0. >>> wlan0: flags=3D8843 metric 0 mt= u 1500 >>> ether 60:a4:4c:ec:c9:a5 >>> hwaddr 60:a4:4c:ec:c9:a5 >>> groups: wlan >>> ssid "" channel 11 (2462 MHz 11g) >>> regdomain FCC country US authmode OPEN privacy OFF txpower 30 >>> scanvalid 60 protmode CTS wme dtimperiod 1 -dfs bintval 0 >>> media: IEEE 802.11 Wireless Ethernet autoselect >>> (autoselect ) >>> status: no carrier >>> nd6 options=3D29 >>> add host 127.0.0.1: gateway lo0 fib 0: route already in table >>> add net default: gateway 192.168.2.1 >>> add host ::1: gateway lo0 fib 0: route already in table >>> >>> >>> *Something else to note about this setup output is that wlan0 did NOT >>> get the ssid or the security setup from /etc/hostapd.conf >>> >>> After boot I manually add the wlan0 to the bridge and then set the ssid >>> >>> root@bbb:~ # ifconfig bridge0 addm wlan0 >>> root@bbb:~ # ifconfig wlan0 ssid freebsd >>> >>> I brought the interface down and back up again which made the AP is >>> available to the clients. I open the ipod and get the system to >>> associate with the ap and enter the following information >>> >>> static IP >>> >>> address: 192.168.2.102 >>> subnet: 255.255.255.0 >>> router: 192.168.2.1 >>> dns : 192.168.1 >>> >>> After numerous wrong attempts at configuring the client, I managed to >>> get exactly ONE request through. The freebsd.org page came up. I then >>> tried to search for the ookla page and my bbb kernel paniced! (yay!) >>> https://pastebin.com/zB9AnWTv >>> >>> The next time I booted the entire board hung right after the usb wifi >>> adapter loaded (chop of hung board output, full output here >>> https://pastebin.com/M09C5NEP): >>> >>> cpsw0: link state changed to UP >>> bridge0: link state changed to UP >>> Starting Network: lo0 cpsw0 bridge0. >>> lo0: flags=3D8049 metric 0 mtu 16384 >>> options=3D600003 >>> inet6 ::1 prefixlen 128 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >>> inet 127.0.0.1 netmask 0xff000000 >>> groups: lo >>> nd6 options=3D21 >>> cpsw0: flags=3D8943 >>> metric 0 mtu 1500 >>> options=3D8000b >>> ether a0:f6:fd:8a:c5:be >>> hwaddr a0:f6:fd:8a:c5:be >>> inet 192.168.2.101 netmask 0xffffff00 broadcast 192.168.2.255 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> nd6 options=3D29 >>> bridge0: flags=3D8843 metric 0 = mtu 1500 >>> ether 02:94:dd:d7:a3:00 >>> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >>> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >>> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >>> member: cpsw0 flags=3D143 >>> ifmaxaddr 0 port 1 priority 128 path cost 55 >>> groups: bridge >>> nd6 options=3D9 >>> Starting devd. >>> run0 on uhub1 >>> run0: <1.0> on usbus1 >>> >>> U-Boot SPL 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19) >>> bad magic >>> >>> Sometimes it boots, sometimes it hangs (I'd say 3 to 1). The lights on >>> the cpsw0 interface still blink but the serial console is dead. I'm >>> trying to *avoid* triggering that so I don't know the sequence that's >>> causing it. However, I can cause the kernel to panic on the BBB >>> relatively quickly from a handful of page requests on the ipod. No >>> more than three full page requests so far. It seems there is a bad >>> memory copy happening in bridge_broadcast() at bridge_broadcast+0x1c4? >>> >>> https://www.freebsd.org/cgi/man.cgi?apropos=3D0&sektion=3D9&query=3Dm_d= up >>> >>> Anyway, that's all the time I have for this weekend. I'm going to take >>> the chance that someone wants to see this and put it in bugzilla. >>> >>> Cheers, >>> >>> Russ >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221845 >> >> Cheers, >> Russ > > Hi, > > I've been digging into the code for if_bridge.c, which is found under > sys/net. bridge_broadcast only has one call to m_dup on line 2553. Hi, I've been digging into the code for if_bridge.c, which is found under sys/net. bridge_broadcast only has one call to m_dup on line 2553. mc =3D m_dup(m, M_NOWAIT); if (mc =3D=3D NULL) { if_inc_counter(sc->sc_ifp, IFCOUNTER_OERRORS, 1); continue; } This is just a guess: I'm wondering if the M_NOWAIT is causing the panic because... er... "someone has a sleep lock they shouldn't"? I don't really know what I'm talking about though (a little bit of knowledge...) I guess I'd have to try and correlate to some sort of lock begin held in the adapter specific code? Cheers, Russ From owner-freebsd-arm@freebsd.org Tue Sep 5 21:38:46 2017 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 C6198E2073A for ; Tue, 5 Sep 2017 21:38:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 D590E7004A for ; Tue, 5 Sep 2017 21:38:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3759 invoked from network); 5 Sep 2017 21:38:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Sep 2017 21:38:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 05 Sep 2017 17:38:43 -0400 (EDT) Received: (qmail 1499 invoked from network); 5 Sep 2017 21:38:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Sep 2017 21:38:43 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 9A5C0EC807E; Tue, 5 Sep 2017 14:38:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like From: Mark Millard In-Reply-To: <8A60350E-0D95-4D47-A7E8-6AF1A7727A93@dsl-only.net> Date: Tue, 5 Sep 2017 14:38:41 -0700 Cc: freebsd-arm , FreeBSD Toolchain , x11@FreeBSD.org, FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: <3354A557-4707-40C1-916F-6E0C066A7A80@dsl-only.net> References: <5CAB42C9-984A-4BC9-A4CC-4BDD74932084__24380.8804465973$1504641758$gmane$org@dsl-only.net> <8A60350E-0D95-4D47-A7E8-6AF1A7727A93@dsl-only.net> To: Jan Beich X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 21:38:47 -0000 On 2017-Sep-5, at 1:33 PM, Mark Millard wrote: > On 2017-Sep-5, at 1:13 PM, Jan Beich wrote: >=20 >> Mark Millard writes: >>=20 >>> In an experiment with building some arm ports via poudriere >>> cross building on amd64 I got the following. It appears that >>> clang does not handle all the assembler notation and a >>> different assembler might need to be used for x11/pixman . >>> (The x11/pixman usage is indirect from having specified >>> x11/lumina and x11/xscreensaver ). >>>=20 >>> --- pixman-arm-simd-asm.lo --- >>> /bin/sh ../libtool --mode=3Dcompile /nxb-bin/usr/bin/cc = -DHAVE_CONFIG_H -I. -I.. -mcpu=3Dcortex-a7 -O2 -pipe = -mcpu=3Dcortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo = -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo = pixman-arm-simd-asm.S >>> libtool: compile: /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. = -mcpu=3Dcortex-a7 -O2 -pipe -mcpu=3Dcortex-a7 -g -fno-strict-aliasing = -MT pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c = pixman-arm-simd-asm.S -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o >>> :1:1: error: unknown directive >>> . . . >>> --- pixman-arm-simd-asm.lo --- >>> .func fname >>> ^ >>=20 >> Does it still happen after = https://svnweb.freebsd.org/changeset/ports/449285 ? >=20 > . . . > This is based on /usr/ports having -r449313 . (I updated based on > your question.) > . . . The rebuild of the ports rebuilt x11/pixman earlier in the sequence than I had guessed so it took less time to get to that point: [00:51:26] [03] [00:00:00] Building x11/pixman | pixman-0.34.0 . . . [00:54:15] [03] [00:02:49] Finished x11/pixman | pixman-0.34.0: Success So -r449285 has avoided using clang's internal assembler. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Sep 5 23:38:37 2017 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 A6953E02421 for ; Tue, 5 Sep 2017 23:38:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 4D96F6998F for ; Tue, 5 Sep 2017 23:38:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13290 invoked from network); 5 Sep 2017 23:43:54 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Sep 2017 23:43:54 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 05 Sep 2017 19:38:34 -0400 (EDT) Received: (qmail 799 invoked from network); 5 Sep 2017 23:38:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Sep 2017 23:38:34 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 896F3EC807E; Tue, 5 Sep 2017 16:38:33 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: x11-toolkits/qt5-gui vs. arm.armv6 build via poudriere cross build: fails (undefined references) and odd mix of "clang++" vs. "/nxb-bin/usr/bin/c++" Message-Id: <4142F136-53C5-40CF-8B0A-BE68BC9EBFC6@dsl-only.net> Date: Tue, 5 Sep 2017 16:38:32 -0700 Cc: FreeBSD Toolchain To: freebsd-arm , x11@FreeBSD.org, FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 23:38:37 -0000 This is a bit odd so I give it in stages. The context is based on: poudriere jail -c -j zrFBSDx64CjailArmV7 -a arm.armv6 -x -m null -M = /usr/obj/DESTDIRs/clang-armv7-installworld-poud -S /usr/src -v = 12.0-CURRENT poudriere bulk -j zrFBSDx64CjailArmV7 -w -f /root/armv7-origins.txt (More details given later.) First there is some unexpected use of (for example) clang++ instead of /nxb-bin/usr/bin/c++ . Then later I show some undefined references that make the build fail. For the clang++ vs. /nxb-bin/usr/bin/c++ there was (for example): --CONFIGURE_ENV-- = QMAKESPEC=3D"/usr/local/lib/qt5/mkspecs/freebsd-$(ccver=3D"$(/nxb-bin/usr/= bin/c++ --version)"; case "$ccver" in *clang*) echo clang ;; *) echo g++ = ;; esac)" MAKE=3D"make" QT_SELECT=3Dqt5 PKG_CONFIG=3Dpkgconf = XDG_DATA_HOME=3D/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work = XDG_CONFIG_HOME=3D/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work = HOME=3D/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work TMPDIR=3D"/tmp" = SHELL=3D/bin/sh CONFIG_SHELL=3D/bin/sh --End CONFIGURE_ENV-- Note the expected use of /nxb-bin/usr/bin/c++ . There is also the later: ---Begin make.nxb.conf--- CC=3D/nxb-bin/usr/bin/cc CPP=3D/nxb-bin/usr/bin/cpp CXX=3D/nxb-bin/usr/bin/c++ AS=3D/nxb-bin/usr/bin/as NM=3D/nxb-bin/usr/bin/nm LD=3D/nxb-bin/usr/bin/ld OBJCOPY=3D/nxb-bin/usr/bin/objcopy SIZE=3D/nxb-bin/usr/bin/size STRIPBIN=3D/nxb-bin/usr/bin/strip SED=3D/nxb-bin/usr/bin/sed READELF=3D/nxb-bin/usr/bin/readelf RANLIB=3D/nxb-bin/usr/bin/ranlib YACC=3D/nxb-bin/usr/bin/yacc MAKE=3D/nxb-bin/usr/bin/make STRINGS=3D/nxb-bin/usr/bin/strings AWK=3D/nxb-bin/usr/bin/awk FLEX=3D/nxb-bin/usr/bin/flex ---End make.nxb.conf--- Yet for some reason x11-toolkits/qt5-gui reports using clang++ commands in config activity instead. For example: Running configuration tests... Determining architecture... () clang++ -c -pipe -g -Wall -W -fPIC -I. -I/usr/local/include = -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o arch.o arch.cpp clang++ -o arch arch.o -L/usr/local/lib Found architecture in binary CFG_ARCH=3D"arm" CFG_CPUFEATURES=3D"" System architecture: 'arm' Host architecture: 'arm' clang++ -c -fvisibility=3Dhidden fvisibility.c clang++: warning: treating 'c' input as 'c++' when in C++ mode, this = behavior is deprecated [-Wdeprecated] Symbol visibility control enabled. clang++ -o libtest.so -shared -Wl,-Bsymbolic-functions -fPIC = bsymbolic_functions.c clang++: warning: treating 'c' input as 'c++' when in C++ mode, this = behavior is deprecated [-Wdeprecated] bsymbolic_functions.c:2:2: error: "Symbolic function binding on this = architecture may be broken, disabling it (see QTBUG-36129)." #error "Symbolic function binding on this architecture may be broken, = disabling it (see QTBUG-36129)." ^ 1 error generated. Symbolic function binding disabled. (I omit a lot more such "clang++" lines in the config stages of output. I did not see any /nxb-bin/usr/bin/c++ in that area.) Still it later reports: Configure summary Build type: /usr/local/lib/qt5/mkspecs/freebsd-clang (arm, CPU = features: none detected) qmake vars .......... QMAKE_CC =3D /nxb-bin/usr/bin/cc QMAKE_CXX =3D = /nxb-bin/usr/bin/c++ . . . It later uses the /nxb-bin/usr/bin/c* commands in the actual build. As for the build failure itself. . . --- ../../lib/libQt5Gui.so.5.7.1 --- rm -f libQt5Gui.so.5.7.1 libQt5Gui.so libQt5Gui.so.5 libQt5Gui.so.5.7 /nxb-bin/usr/bin/c++ -Wl,--as-needed -Wl,--no-undefined = -Wl,--version-script,QtGui.version -Wl,--enable-new-dtags -pthread = -Wl,-rpath,/usr/local/lib/qt5 -shared -Wl,-soname,libQt5Gui.so.5 -o = libQt5Gui.so.5.7.1 .obj/qaccessible.o . . . fails with: .obj/qimage.o: In function `_ZL10qt_memfillIjEvPT_S0_i': = /wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/s= rc/gui/../../include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/pain= ting/qdrawhelper_p.h:803: undefined reference to `qt_memfill32(unsigned = int*, unsigned int, int)' = /wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/s= rc/gui/../../include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/pain= ting/qdrawhelper_p.h:803: undefined reference to `qt_memfill32(unsigned = int*, unsigned int, int)' .obj/qimage_conversions.o:(.data+0x524): undefined reference to = `convert_RGB888_to_RGB32_neon(QImageData*, QImageData const*, = QFlags)' .obj/qimage_conversions.o:(.data+0x528): undefined reference to = `convert_RGB888_to_RGB32_neon(QImageData*, QImageData const*, = QFlags)' .obj/qimage_conversions.o:(.data+0x52c): undefined reference to = `convert_RGB888_to_RGB32_neon(QImageData*, QImageData const*, = QFlags)' .obj/qcompositionfunctions.o: In function `_ZL10qt_memfillIjEvPT_S0_i': = /wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/s= rc/gui/../../include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/pain= ting/qdrawhelper_p.h:803: undefined reference to `qt_memfill32(unsigned = int*, unsigned int, int)' . . . (I've omitted a lot more such notices of undefined references.) The context for all the above is from a poudriere/qemu-user-static/native_xtools based cross build from amd64: poudriere jail -c -j zrFBSDx64CjailArmV7 -a arm.armv6 -x -m null -M = /usr/obj/DESTDIRs/clang-armv7-installworld-poud -S /usr/src -v = 12.0-CURRENT poudriere bulk -j zrFBSDx64CjailArmV7 -w -f /root/armv7-origins.txt The -x use was enabled for -m null via: /usr/local/share/poudriere/jail.sh having a "build_native_xtools" added: null) JAILFS=3Dnone FCT=3Dbuild_native_xtools ;; # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r323147M amd64 = amd64 1200043 1200043 /usr/obj/DESTDIRs/clang-armv7-installworld-poud is from an arm/armv6 build of the same sources using -mcpu=3Dcortex-a7 , installed via installworld distrib-dirs distribution DB_FROM_SRC=3D1 DESTDIR=3D. . . : # more ~/src.configs/src.conf.armv7-clang-bootstrap.amd64-host=20 TO_TYPE=3Darmv6 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv6(/v7) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. The source variations are almost all for powerpc family explorations: # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/Makefile M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/boot1.chrp/Makefile M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 449313 Last Changed Rev: 449313 # svnlite status /usr/ports/ | sort M /usr/ports/Mk/bsd.port.mk M /usr/ports/base/gcc/Makefile M /usr/ports/base/gcc/distinfo M /usr/ports/base/gcc/pkg-plist M /usr/ports/devel/libunwind/Makefile M /usr/ports/sysutils/cdrdao/Makefile # more /usr/local/etc/poudriere.d/make.conf WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D7 # # =46rom a local /usr/ports/Mk/bsd.port.mk extension: ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D # .if ${.CURDIR:M*/devel/llvm*} #WITH_DEBUG=3D .elif ${.CURDIR:M*/www/webkit-qt5*} #WITH_DEBUG=3D .else WITH_DEBUG=3D .endif MALLOC_PRODUCTION=3D # more /usr/local/etc/poudriere.d/zrFBSDx64CjailArmV7-make.conf = =20 CFLAGS+=3D -mcpu=3Dcortex-a7 CXXFLAGS+=3D -mcpu=3Dcortex-a7 CPPFLAGS+=3D -mcpu=3Dcortex-a7 As for that "ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG" I have in /usr/ports/Mk/bsd.port.mk : STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif I've also had trouble in some contexts where bad.port.mk uses ${UNAME} (empty string results) and so have forced the expected content to match the context that this is in a couple of the places: # Get the operating system type .if !defined(OPSYS) -OPSYS!=3D ${UNAME} -s +OPSYS!=3D echo FreeBSD .endif _EXPORTED_VARS+=3D OPSYS .if !defined(_OSRELEASE) -_OSRELEASE!=3D ${UNAME} -r +_OSRELEASE!=3D echo 12.0-CURRENT .endif _EXPORTED_VARS+=3D _OSRELEASE =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Sep 6 09:40:40 2017 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 DB3D4E1D82C for ; Wed, 6 Sep 2017 09:40:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 E11A46A670 for ; Wed, 6 Sep 2017 09:40:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24838 invoked from network); 6 Sep 2017 09:40:37 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Sep 2017 09:40:37 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 06 Sep 2017 05:40:37 -0400 (EDT) Received: (qmail 14827 invoked from network); 6 Sep 2017 09:40:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Sep 2017 09:40:37 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id DF7E1EC926D; Wed, 6 Sep 2017 02:40:36 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Could someone see about possibly applying the patch(s) from bugzilla 216816 so arm qt5 builds can work? (includes patching bsd.qt.mk) Date: Wed, 6 Sep 2017 02:40:36 -0700 References: Cc: mmel@freebsd.org, mikael.urankar@gmail.com, tcberner@freebsd.org, mi@ALDAN.algebra.com To: FreeBSD Toolchain , freebsd-arm , x11@FreeBSD.org, FreeBSD Ports Message-Id: <4886EB2D-3F85-4DC9-954A-99B874334ADB@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:40:41 -0000 The patches mentioned below have been in bugzilla 216816 since 2017-Feb-05 but no one has applied them. The author of the patches reports below having a poudriere build log showing a successful build for x11-toolkits/qt5-gui . (My older bugzilla report 206348 was about qt5-gui specifically.) Could someone see about applying some variation of the patches so arm builds of such things are no longer blocked? FYI: Part of the context here is use of -mcpu=3Dcortex-a7 and the like. > From: bugzilla-noreply@freebsd.org > Subject: [Bug 216816] [PATCH] devel/qt5: In arch.test, use CXXFLAGS = from make environment > Date: September 6, 2017 at 1:31:47 AM PDT > To: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216816 >=20 > --- Comment #8 from Michal Meloun --- > This patch affects many (if not all) of qt5 ports, so you must rebuild = all of > them.=20 > In any case, I can build qt5-gui without problem: > = http://build.humusoft.cz/data/head12armv7-default/2017-03-11_19h10m04s/log= s/qt5-gui-5.7.1.log >=20 > --=20 > You are receiving this mail because: > You are on the CC list for the bug. Note: Bugzilla 206348 and 217278 are also reports of the problem(s), noted as duplicates of the bugzilla that has the patches at this point. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Sep 6 15:03:11 2017 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 24660E06DD9 for ; Wed, 6 Sep 2017 15:03:11 +0000 (UTC) (envelope-from helen.carter@protechnologyaccounts.net) Received: from mail-qt0-x246.google.com (mail-qt0-x246.google.com [IPv6:2607:f8b0:400d:c0d::246]) (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 8E67A7119A for ; Wed, 6 Sep 2017 15:03:10 +0000 (UTC) (envelope-from helen.carter@protechnologyaccounts.net) Received: by mail-qt0-x246.google.com with SMTP id m35so2851349qte.15 for ; Wed, 06 Sep 2017 08:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protechnologyaccounts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:message-id:date:subject:from:to; bh=a1xciZftuXfiHAXwHwmQzuHFf5VwgTsi9FlUadM1mqA=; b=NWO2hyMFRDAX9UaeMUSZ18EoIlYS+MmBhG3PLi6t2rOZzAOXfedCcMW1VSdDten6Gj 1WEsYSF1ivsINcPy2NQvZ6XO9hZLRuBEW/IQf9+T83vXg2Cguzpc/fjpDnJreoNtwYIA o6ar8MdOz0BRSe5qw75YuVT972W/OJfqZNNcVD9A/ccEPtTtrtKsLLhNsbHi0I0L/5Lq VfkLZTU8aQFutOoP+2BDCQZyJ0XbeeDnHPEHJbjOdf/Qt66xC3Ce/PLqRefHUEUuwYWn OE7yETHdceWMibm7iBOrGPfrxPGJEUjoyKZeDr7bWXSAk4LRRlHc7b7bcZf0Emst7adt 9aPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:message-id:date:subject:from:to; bh=a1xciZftuXfiHAXwHwmQzuHFf5VwgTsi9FlUadM1mqA=; b=VAtKY0grniNbcKRfMTEguH8G7x37obpuGER3A7nzscotdkCNFc23moaD1iCIEwIgfP bXs4/Qxe2kc7h5PXMSPxh2MNv+WE13B9Md5QOnJmd82/BABFqipnBdXFcczwm7ZQesrr mZTcUB42wK85m1fO6w12T2lwyEpGJydId3V/A5aIpK0w0UNM2p6mKfvR/St0lBPt5RIQ DozYEK/xHZWS+ovnPAdhI06Raf7paMGyzMKOTeVgE5RWnsGLDx/Nw4QQkM0gNXUWYdIc kyioyn5BAQfNHXloZXEStK2sVy0Nuspu79ORYXhecyS4nsmBSMYYNDO2hV+DmhfuCnl5 RSeA== X-Gm-Message-State: AHPjjUjhDw+TVCBUpMv1obeNM8Wse8FNFqcVeqSwhVJ/XbEBFgdlRZIx odqu/3Y9LIUd4W1ZpcsxufWjAGbi1J01 X-Google-Smtp-Source: ADKCNb7tfNbI2Gom8ToyLWTmQNmsd00b0XNaAK8JFXxv2QiYQCRxz0CM3WKxGkjTGIP6Coy1WkivKFk3FQ== MIME-Version: 1.0 X-Received: by 10.55.159.86 with SMTP id i83mr1621605qke.41.1504710189493; Wed, 06 Sep 2017 08:03:09 -0700 (PDT) Message-ID: <001a114d89ea55b890055886a4dd@google.com> Date: Wed, 06 Sep 2017 15:03:09 +0000 Subject: Decision Makers List From: helen.carter@protechnologyaccounts.net To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 15:03:11 -0000 PGRpdiBkaXI9Imx0ciI+PHAgY2xhc3M9ImdtYWlsLU1zb05vU3BhY2luZyI+PHNwYW4gIA0Kc3R5 bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Y29sb3I6cmdi KDMxLDc4LDEyMSk7YmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tncm91bmQtcG9zaXRpb246 aW5pdGlhbDtiYWNrZ3JvdW5kLXNpemU6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFs O2JhY2tncm91bmQtb3JpZ2luOmluaXRpYWw7YmFja2dyb3VuZC1jbGlwOmluaXRpYWwiPkhlbGxv LDwvc3Bhbj48c3BhbiAgDQpzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6QXJpYWws c2Fucy1zZXJpZjtjb2xvcjpyZ2IoMzEsNzgsMTIxKSI+PGJyPg0KPGJyPg0KPHNwYW4gIA0Kc3R5 bGU9ImJhY2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWw7 YmFja2dyb3VuZC1zaXplOmluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbDtiYWNrZ3Jv dW5kLW9yaWdpbjppbml0aWFsO2JhY2tncm91bmQtY2xpcDppbml0aWFsIj5Xb3VsZCAgDQp5b3Ug YmUgaW50ZXJlc3RlZCBpbiB0aGUgYmVsb3cgU29mdHdhcmUNClVzZXJzIGNvbnRhY3QgaW5mb3Jt YXRpb24gZm9yIHlvdXIgbWFya2V0aW5nIHB1cnBvc2U/PC9zcGFuPjxicj4NCjxicj4NCjxicj4N CjxiPjxzcGFuICANCnN0eWxlPSJiYWNrZ3JvdW5kLWltYWdlOmluaXRpYWw7YmFja2dyb3VuZC1w b3NpdGlvbjppbml0aWFsO2JhY2tncm91bmQtc2l6ZTppbml0aWFsO2JhY2tncm91bmQtcmVwZWF0 OmluaXRpYWw7YmFja2dyb3VuZC1vcmlnaW46aW5pdGlhbDtiYWNrZ3JvdW5kLWNsaXA6aW5pdGlh bCI+RVJQLSAgDQpKRA0KRWR3YXJkcywgSW5mb3IgQmFhbiwgU0FQLCBFeGFjdCBTb2Z0d2FyZSwg TmV0U3VpdGUsIFBlb3BsZVNvZnQsICANCmV0Yy48L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gIA0K c3R5bGU9ImJhY2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRp YWw7YmFja2dyb3VuZC1zaXplOmluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbDtiYWNr Z3JvdW5kLW9yaWdpbjppbml0aWFsO2JhY2tncm91bmQtY2xpcDppbml0aWFsIj5DUk0tICANClNh bGVzRm9yY2UsIE1TIER5bmFtaWNzLCBOZXRTdWl0ZSwgU2llYmVsLA0KVGVyYWRhdGEsIEVwaWNv ciwgSW5mb3IsIENEQyBTb2Z0d2FyZSwgZXRjLjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiAgDQpz dHlsZT0iYmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlh bDtiYWNrZ3JvdW5kLXNpemU6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsO2JhY2tn cm91bmQtb3JpZ2luOmluaXRpYWw7YmFja2dyb3VuZC1jbGlwOmluaXRpYWwiPkVuZ2luZWVyaW5n ICANClNvZnR3YXJlLSBBdXRvZGVzaywgU2llbWVucyBQTE0sDQpBZG9iZSwgQXV0b0NBRCwgTUFZ QSwgUmV2aXR0LCBTb2xpZHdvcmtzLCBQVEMsIE1BRENBRCwgZXRjLjwvc3Bhbj48YnI+DQo8YnI+ DQo8c3BhbiAgDQpzdHlsZT0iYmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tncm91bmQtcG9z aXRpb246aW5pdGlhbDtiYWNrZ3JvdW5kLXNpemU6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDpp bml0aWFsO2JhY2tncm91bmQtb3JpZ2luOmluaXRpYWw7YmFja2dyb3VuZC1jbGlwOmluaXRpYWwi PkNsb3VkICANCkNvbXB1dGluZy0gQW1hem9uLCBSYWNrU3BhY2UsIEdvb2dsZSBBUFBTLA0KSHlw ZXItViwgTmV0QXBwLCBldGMuPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuICANCnN0eWxlPSJiYWNr Z3JvdW5kLWltYWdlOmluaXRpYWw7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsO2JhY2tncm91 bmQtc2l6ZTppbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWw7YmFja2dyb3VuZC1vcmln aW46aW5pdGlhbDtiYWNrZ3JvdW5kLWNsaXA6aW5pdGlhbCI+U3RvcmFnZSAgDQphcHBsaWNhdGlv biAtIE5ldEFwcCwgRU1DLCBDaXRyaXgsIEhQLA0KQnJvY2FkZSwgREVMTCwgZXRjLjwvc3Bhbj48 YnI+DQo8YnI+DQo8c3BhbiAgDQpzdHlsZT0iYmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tn cm91bmQtcG9zaXRpb246aW5pdGlhbDtiYWNrZ3JvdW5kLXNpemU6aW5pdGlhbDtiYWNrZ3JvdW5k LXJlcGVhdDppbml0aWFsO2JhY2tncm91bmQtb3JpZ2luOmluaXRpYWw7YmFja2dyb3VuZC1jbGlw OmluaXRpYWwiPlNlY3VyaXR5ICANClNvZnR3YXJlLSBTeW1hbnRlYywgTWNBZmVlLCBJQk0sDQpS aXZlcmJlZCwgVGFiYmVyZywgQ29tbXZhdWx0LCBKdW5pcGVyIE5ldHdvcmtzLCBGNSwgZXRjLjwv c3Bhbj48YnI+DQo8YnI+DQo8c3BhbiAgDQpzdHlsZT0iYmFja2dyb3VuZC1pbWFnZTppbml0aWFs O2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbDtiYWNrZ3JvdW5kLXNpemU6aW5pdGlhbDtiYWNr Z3JvdW5kLXJlcGVhdDppbml0aWFsO2JhY2tncm91bmQtb3JpZ2luOmluaXRpYWw7YmFja2dyb3Vu ZC1jbGlwOmluaXRpYWwiPk5ldHdvcmtpbmctICANCkJyb2NhZGUsIFN5bWFudGVjLCBBdmF5YSwg Q2lzY28sDQpTaG9yZVRlbCwgZXRjLjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiAgDQpzdHlsZT0i YmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbDtiYWNr Z3JvdW5kLXNpemU6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsO2JhY2tncm91bmQt b3JpZ2luOmluaXRpYWw7YmFja2dyb3VuZC1jbGlwOmluaXRpYWwiPk1lZGljYWwgIA0KU29mdHdh cmUtIE5leHRHZW4sIEFsbFNjcmlwdHMsIEVNUiwNCk1jS2Vzc29uLCBQcmFjdGljZSBGdXNpb24s IGVDbGluaWNhbCBXb3JrcywgZXRjLjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiAgDQpzdHlsZT0i YmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbDtiYWNr Z3JvdW5kLXNpemU6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsO2JhY2tncm91bmQt b3JpZ2luOmluaXRpYWw7YmFja2dyb3VuZC1jbGlwOmluaXRpYWwiPkFjY291bnRpbmcgIA0KU29m dHdhcmUtIFNhZ2UsIFBlYWNoVHJlZSwNClRpbWJlcmxpbmUsIE1TIER5bmFtaWNzLCBOZXRTdWl0 ZSwgRGVsdGVrLCBMYXdzb24sIFF1aWNrQm9va3MsICANCmV0Yy48L3NwYW4+PGJyPg0KPGJyPg0K PHNwYW4gIA0Kc3R5bGU9ImJhY2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXBvc2l0 aW9uOmluaXRpYWw7YmFja2dyb3VuZC1zaXplOmluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5p dGlhbDtiYWNrZ3JvdW5kLW9yaWdpbjppbml0aWFsO2JhY2tncm91bmQtY2xpcDppbml0aWFsIj5C dXNpbmVzcyAgDQpJbnRlbGxpZ2VuY2UtIFNBUCBCdXNpbmVzcyBPYmplY3RzLA0KTWljcm9zdHJh dGVyZ3ksIFRpYmNvLCBNaWNyb3NvZnQgQkksIFFsaWtUZWNoLCBJbmZvcm1hdGlvbiBCdWlsZGVy cywgIA0KZXRjLjwvc3Bhbj48YnI+DQo8L2I+PGJyPg0KPGJyPg0KPHNwYW4gIA0Kc3R5bGU9ImJh Y2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWw7YmFja2dy b3VuZC1zaXplOmluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbDtiYWNrZ3JvdW5kLW9y aWdpbjppbml0aWFsO2JhY2tncm91bmQtY2xpcDppbml0aWFsIj5XZSAgDQpwcm92aWRlIGRhdGEg YWNyb3NzIHRoZSBnbG9iZSAtIE5vcnRoDQpBbWVyaWNhLCBFTUVBLCBBc2lhIFBhY2lmaWMgYW5k IExBVEFNLjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiAgDQpzdHlsZT0iYmFja2dyb3VuZC1pbWFn ZTppbml0aWFsO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbDtiYWNrZ3JvdW5kLXNpemU6aW5p dGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsO2JhY2tncm91bmQtb3JpZ2luOmluaXRpYWw7 YmFja2dyb3VuZC1jbGlwOmluaXRpYWwiPldlICANCnByb3ZpZGUgdGhlIGRlY2lzaW9uIE1ha2Vy cyBjb250YWN0cyBsaWtlDQpDSU8sIENUTywgQ0lTTywgSVQgVlAsIElUIERpcmVjdG9yLCBJVCBt YW5hZ2VyLCBJVCBoZWFkLCBldGMuPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuICANCnN0eWxlPSJi YWNrZ3JvdW5kLWltYWdlOmluaXRpYWw7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsO2JhY2tn cm91bmQtc2l6ZTppbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWw7YmFja2dyb3VuZC1v cmlnaW46aW5pdGlhbDtiYWNrZ3JvdW5kLWNsaXA6aW5pdGlhbCI+UGxlYXNlICANCnJldmlldyBh bmQgbGV0IG1lIGtub3cgaWYgeW91IGFyZSBsb29raW5nDQpmb3IgYW55IHR5cGUgb2YgbGlzdCBh bmQgd2UgY2FuIHNlcnZpY2UgeW91Ljwvc3Bhbj48YnI+DQo8YnI+DQo8c3Bhbj48L3NwYW4+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9ImdtYWlsLU1zb05vU3BhY2luZyI+PHNwYW4gIA0Kc3R5bGU9 ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Y29sb3I6cmdiKDMx LDc4LDEyMSkiPkF3YWl0ICANCnlvdXIgcmVzcG9uc2UhPGJyPg0KPGI+SGVsZW48YnI+DQpEYXRh IFNwZWNpYWxpc3Q8L2I+PHNwYW4+PC9zcGFuPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPSJnbWFp bC1Nc29Ob1NwYWNpbmciPjxzcGFuICANCnN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWls eTpBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOnJnYigzMSw3OCwxMjEpIj7CoDwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPSJnbWFpbC1Nc29Ob1NwYWNpbmciPjxzcGFuICANCnN0eWxlPSJmb250LXNpemU6 MTBwdDtmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOnJnYigxOTEsMTkxLDE5MSki PlRvICANCm9wdCBvdXQgcGxlYXNlDQpyZXBseSB3aXRoICZxdW90O3JlbW92ZSZxdW90OyBpbiB0 aGUgc3ViamVjdCAgDQpsaW5lPHNwYW4+PC9zcGFuPjwvc3Bhbj48L3A+PC9kaXY+DQo8cD4mbmJz cDs8L3A+PGEgc3R5bGU9J2Rpc3BsYXk6IGJsb2NrOyBtYXJnaW46IDMycHggMCA0MHB4IDA7IHBh ZGRpbmc6ICANCjEwcHg7IGZvbnQtc2l6ZTogMWVtOyB0ZXh0LWFsaWduOiBjZW50ZXI7IGJvcmRl cjogMDsgYm9yZGVyLXRvcDogMXB4IHNvbGlkICANCmdyYXk7ICcgaHJlZj0naHR0cHM6Ly9nb28u Z2wvMmtzZFJ2Jz5wb3dlcmVkIGJ5IEdTTS4gRnJlZSBtYWlsIG1lcmdlIGFuZCAgDQplbWFpbCBt YXJrZXRpbmcgc29mdHdhcmUgZm9yIEdtYWlsLjwvYT4NCg== From owner-freebsd-arm@freebsd.org Wed Sep 6 17:32:01 2017 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 10565E0DB90 for ; Wed, 6 Sep 2017 17:32:01 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 7756171614 for ; Wed, 6 Sep 2017 17:32:00 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id 80so14506029lfy.4 for ; Wed, 06 Sep 2017 10:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MAXs8Wqx9iVI8ko8XWtEv4+Q0uwtLwVzGVlOjrGMiDI=; b=E4jZjD+Ee1q1Hr2H0X9InT2OLtb5SviQ/mqWXnde2RbPKEb2jvaTEnDRhc/YlowNeZ 9Pefil7pbEP00i4MnI0FSJN11pIkTHUwEvEs1egJwjzHvKabZhAMbT2Djz8Ju96grDOJ MuOsnDPC/A60U3OZwKai9lNncAU+kM7M7gUi1N4XAMSrlmAgqwgCpLwgavy8tZpbCjFT GM0pYOe3mT57dTGGwQyPvlPslh4CtrwkkwkIjJjvHJAMsYBXlAdS7Tzl3ggZimqu0889 bIbCa0I8f6qmtji3wLZqkrYoao1eRF77+yvf+6uFn7H2JCmBqZW9u/9I1CurRopgfesJ 1PSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MAXs8Wqx9iVI8ko8XWtEv4+Q0uwtLwVzGVlOjrGMiDI=; b=tc3LytfEC+/7EJcQuNHyFKBp/3Nj5YQJDL7UsyzR3iSGV9scLnjqG/OwGJwjjSldip uwIdPPKbagzECXpBKuYHgvxGEi1mhXsNOZ257kW6Dvj4jx/mjZbm440pX32Aeozgc9vK 7AZGYHjOHYGJ6OvKNI7iwwWfIA8ABj0hE+VdUoRwg8lyYvggvdBjv1iggN8V9SbXUgN6 iZyRbpklvsGOUEP9h9YkOSE6/ILbRq9o6nWbXEBonIjX1WZsiFMlk0HdEXv0TgnuvTv3 fl+PVuVbWP22xi3pmflXPLTbKkshu4ianL6h7n6kPCDi4AoW/UfbLlYN0T/DwAxwv3HI pcSA== X-Gm-Message-State: AHPjjUi8ZlonMdTXXkJMOxJuE/OcUYqrJbn3b1c6riN5Dce/2WZ6KqnA hWWFK5LzWZgHz4xbcenhK6G2zPmQWfeAd4I= X-Google-Smtp-Source: ADKCNb4k99u/nBwVUX5Q6USL2KEDRErPNSL3Ba9C9s+hXT10v8YnjDciMLR4Ea0BIqj4NTOEudGRN8hBpu0UiBQTtxI= X-Received: by 10.46.71.75 with SMTP id u72mr1328380lja.42.1504719117980; Wed, 06 Sep 2017 10:31:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Wed, 6 Sep 2017 10:31:56 -0700 (PDT) In-Reply-To: <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> From: Russell Haley Date: Wed, 6 Sep 2017 10:31:56 -0700 Message-ID: Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? To: Chris Gordon Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:32:01 -0000 On Wed, Sep 6, 2017 at 3:44 AM, Chris Gordon wrote: > No problem -- I figured as much. Incidentally, I=E2=80=99m using a urtwn= NIC and I have not seen any panics. > > Chris > > >> On Sep 5, 2017, at 10:17 AM, Russell Haley wrote: >> >> Hi Chris, >> >> Sorry, I was working late and this was supposed to go to the arm mailing= list, not just you. >> >> Cheers, >> Russ (Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221845. Note, I am going to add Chris' original message to the bug...) Hi Chris, I have some questions that may seem rather basic, but I need to get a baseline understanding. Have you monitored your system on a serial console or direct console (i.e. via hdmi/keyboard)? Is the system still responding to other commands after you run the speed test? My thought is that the really really low bandwidth belies a kernel panic on the main terminal that you are not seeing. Regardless of your answer, both your low bandwidth and my kernel panic indicate serious issues between the bridge interface and the device drivers on bbb. The offending bridge_broadcast function in my kernel panic uses m_dup with the NO_WAIT flag. My current working theory is that something in the usb or other intermediate bus is holding a sleep lock or a mutex that it shouldn't. If your wi-fi card is faster than the one I am using, perhaps it avoids the kernel panic, but would ultimately lead to really low bandwidth. (Again, all theory from a dilettante, not a kernel developer). If you would like to do some further testing, you could perhaps help me answer these things: - Can you find a command line way of measuring throughput and latency separately that can be run on a host and on the bbb? I'm sure there are lots of ways to do so. I will leave it up to you to decide and will adopt the same tests so we can compare results. - Can you run the bbb as a standard device (not an access point) and test the performance of the wlan0 interface using the method of measurement pointed above? I will do the same at some point with my wi-fi dongle. While the above won't provide too much detailed clarity, it will at least allow us to perhaps remove the bridge driver from the suspect list. Some tests I would like to do: - Get DTrace involved as a debugging tool. I have rudimentary DTrace skills but will need to consult my books on how to measure throughput and latency. There are some examples early in the DTrace book of logging system calls made by a process and I will review that again when time permits. - Run the system through the kernel debugger. I think this is going to be difficult though as pausing the kernel in the middle of TCP traffic might invalidate any results I get. I know how difficult it can be to debug threaded applications, I can't see a kernel being any easier. ;) Cheers, Russ >> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network. >> Original Message >> From: Russell Haley >> Sent: Monday, September 4, 2017 10:50 PM >> To: Chris Gordon >> Subject: Re: Beaglebone Black + FreeBSD + USB WiFi =3D WAP? >> >> On Sat, Aug 26, 2017 at 11:48 PM, Russell Haley w= rote: >>> On Sat, Aug 26, 2017 at 11:35 PM, Russell Haley = wrote: >>>> On Thu, Aug 24, 2017 at 11:26 PM, Russell Haley = wrote: >>>>> On Tue, Aug 22, 2017 at 5:51 PM, Chris Gordon = wrote: >>>>>> Ilya, >>>>>> >>>>>> Thanks for the follow up. >>>>>> >>>>>>> On Aug 22, 2017, at 3:11 PM, Ilya Bakulin wrote: >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> have you found the issue already? >>>>>> >>>>>> I have not. See below for some theories... >>>>>> >>>>>>> If not: what does `top -Sa` show when you're running your speed tes= t? >>>>>>> Specifically what does "CPU:" line look like, and what are the top = processes in the list? >>>>>> >>>>>> The system stays at >90% idle through the entire test (upload and do= wnload). I see 2-4% WCPU for interrupts and 1-2% for USB. >>>>>> >>>>>>> I've had an issue with FreeBSD acting as WAP (although using Athero= s-based NIC) some years ago, >>>>>>> the problem back then was that the machine CPU was just too slow to= process the traffic. >>>>>> >>>>>> I had initially thought that maybe the little CPU in the BeagleBone = wasn=E2=80=99t up to the WPA encryption or the interrupt rate + usb where j= ust too much for it. Sometimes changing channels helps for a little bit. Si= nce I=E2=80=99ve been tinkering with this little project, I=E2=80=99ve been= paying a bit more attention to my overall WiFi performance and I=E2=80=99m= beginning to think there are just too many WiFi signals nearby and congest= ion is just killing my overall WiFi performance. >>>>>> >>>>>> Any other ideas? >>>>> >>>>> Hi, I'm just trying to reproduce your setup with my BBB and an ASUS >>>>> wi-fi stick. The chipset is Ralink RT3052. I just got the dongle >>>>> working so I'll see if I can set it up as an access point this >>>>> weekend. I can't make any promises on play time though. :) >>>> >>>> >>>> >>>> Hi! >>>> >>>> So I'm only partially successful repeating your test so far, but I can >>>> cause a kernel panic! The following are my observations: >>>> >>>> Running BBB through ftdi cable. >>>> Asus WiFi Adapter, RT3071 chipset >>>> https://wikidevi.com/files/Ralink/RT307x%20product%20brief.pdf >>>> >>>> root@bbb:~ # uname -a >>>> FreeBSD bbb.highfell.local 12.0-CURRENT FreeBSD 12.0-CURRENT #7 >>>> r321601M: Thu Aug 17 22:13:21 PDT 2017 >>>> russellh@prescott.highfell.local:/usr/home/russellh/FreeBSD/rh-armv6/o= bj/arm.armv6/usr/home/russellh/FreeBSD/rh-armv6/src/sys/BEAGLEBONE-MMCCAM >>>> arm >>>> >>>> root@bbb:~ # cat /boot/loader.conf >>>> if_run0_load=3D"YES" >>>> wlan_mac_load=3D"YES" >>>> >>>> root@bbb:~ # cat /etc/rc.conf >>>> hostname=3D"bbb.highfell.local" >>>> ifconfig_cpsw0=3D"inet 192.168.2.101 netmask 255.255.255.0" >>>> defaultrouter=3D"192.168.2.1" >>>> hostapd_enable=3D"YES" >>>> wlans_run0=3D"wlan0" >>>> create_args_wlan0=3D"wlanmode hostap" >>>> ifconfig_wlan0=3D"up" >>>> #gateway_enable=3D"YES" >>>> cloned_interfaces=3D"bridge0" >>>> ifconfig_bridge0=3D"addm cpsw0 addm wlan0 up" >>>> >>>> sshd_enable=3D"YES" >>>> sendmail_enable=3D"NONE" >>>> sendmail_submit_enable=3D"NO" >>>> sendmail_outbound_enable=3D"NO" >>>> sendmail_msp_queue_enable=3D"NO" >>>> growfs_enable=3D"YES" >>>> >>>> >>>> >>>> root@bbb:~ # cat /etc/hostapd.conf >>>> interface=3Dwlan0 >>>> debug=3D1 >>>> ctrl_interface=3D/var/run/hostapd >>>> ctrl_interface_group=3Dwheel >>>> ssid=3Dfreebsd >>>> wpa=3D2 >>>> wpa_passphrase=3Dtesting >>>> wpa_key_mgmt=3DWPA-PSK >>>> wpa_pairwise=3DCCMP >>>> >>>> root@bbb:~ # cat /etc/resolv.conf >>>> # Generated by resolvconf >>>> nameserver 192.168.2.1 >>>> >>>> >>>> 1) Before the kernel loads, loader give the following errors: >>>> >>>> can't find 'if_run' >>>> can't find 'wlan_mac' >>>> >>>> 2) It seems the run0 usb wi-fi interface only comes up after the >>>> bridge0 is already enabled. dmesg does NOT capture the output from the >>>> failed attempt to add the non-existent wlan0 interface. However, I >>>> grabbed it from the boot output in the serial console: >>>> >>>> #From dmesg: >>>> >>>> ugen1.2: at usbus1 >>>> random: unblocking device. >>>> bridge0: Ethernet address: 02:94:dd:d7:a3:00 >>>> cpsw0: link state changed to DOWN >>>> cpsw0: promiscuous mode enabled >>>> bridge0: link state changed to DOWN >>>> cpsw0: link state changed to UP >>>> bridge0: link state changed to UP >>>> run0 on uhub1 >>>> run0: <1.0> on usbus1 >>>> run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address >>>> 60:a4:4c:ec:c9:a5 >>>> ieee80211_load_module: load the wlan_amrr module by hand for now. >>>> wlan0: Ethernet address: 60:a4:4c:ec:c9:a5 >>>> run0: firmware RT3071 ver. 0.33 loaded >>>> >>>> #From console grab: >>>> >>>> eeding entropy: . >>>> ifconfig: SIOCIFCREATE2: Invalid argument >>>> bridge0: Ethernet address: 02:94:dd:d7:a3:00 >>>> Created clone interfaces: bridge0. >>>> cpsw0: link state changed to DOWN >>>> cpsw0: promiscuous mode enabled >>>> bridge0: link state changed to DOWN >>>> ifconfig: BRDGADD wlan0: No such file or directory >>>> cpsw0: link state changed to UP >>>> bridge0: link state changed to UP >>>> Starting Network: lo0 cpsw0 bridge0. >>>> lo0: flags=3D8049 metric 0 mtu 16384 >>>> options=3D600003 >>>> inet6 ::1 prefixlen 128 >>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >>>> inet 127.0.0.1 netmask 0xff000000 >>>> groups: lo >>>> nd6 options=3D21 >>>> cpsw0: flags=3D8943 >>>> metric 0 mtu 1500 >>>> options=3D8000b >>>> ether a0:f6:fd:8a:c5:be >>>> hwaddr a0:f6:fd:8a:c5:be >>>> inet 192.168.2.101 netmask 0xffffff00 broadcast 192.168.2.255 >>>> media: Ethernet autoselect (100baseTX ) >>>> status: active >>>> nd6 options=3D29 >>>> bridge0: flags=3D8843 metric 0= mtu 1500 >>>> ether 02:94:dd:d7:a3:00 >>>> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >>>> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >>>> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >>>> member: cpsw0 flags=3D143 >>>> ifmaxaddr 0 port 1 priority 128 path cost 55 >>>> groups: bridge >>>> nd6 options=3D9 >>>> Starting devd. >>>> run0 on uhub1 >>>> run0: <1.0> on usbus1 >>>> run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address >>>> 60:a4:4c:ec:c9:a5 >>>> ieee80211_load_module: load the wlan_amrr module by hand for now. >>>> wlan0: Ethernet address: 60:a4:4c:ec:c9:a5 >>>> Created wlan(4) interfaces: wlan0. >>>> run0: firmware RT3071 ver. 0.33 loaded >>>> Starting Network: wlan0. >>>> wlan0: flags=3D8843 metric 0 m= tu 1500 >>>> ether 60:a4:4c:ec:c9:a5 >>>> hwaddr 60:a4:4c:ec:c9:a5 >>>> groups: wlan >>>> ssid "" channel 11 (2462 MHz 11g) >>>> regdomain FCC country US authmode OPEN privacy OFF txpower 30 >>>> scanvalid 60 protmode CTS wme dtimperiod 1 -dfs bintval 0 >>>> media: IEEE 802.11 Wireless Ethernet autoselect >>>> (autoselect ) >>>> status: no carrier >>>> nd6 options=3D29 >>>> add host 127.0.0.1: gateway lo0 fib 0: route already in table >>>> add net default: gateway 192.168.2.1 >>>> add host ::1: gateway lo0 fib 0: route already in table >>>> >>>> >>>> *Something else to note about this setup output is that wlan0 did NOT >>>> get the ssid or the security setup from /etc/hostapd.conf >>>> >>>> After boot I manually add the wlan0 to the bridge and then set the ssi= d >>>> >>>> root@bbb:~ # ifconfig bridge0 addm wlan0 >>>> root@bbb:~ # ifconfig wlan0 ssid freebsd >>>> >>>> I brought the interface down and back up again which made the AP is >>>> available to the clients. I open the ipod and get the system to >>>> associate with the ap and enter the following information >>>> >>>> static IP >>>> >>>> address: 192.168.2.102 >>>> subnet: 255.255.255.0 >>>> router: 192.168.2.1 >>>> dns : 192.168.1 >>>> >>>> After numerous wrong attempts at configuring the client, I managed to >>>> get exactly ONE request through. The freebsd.org page came up. I then >>>> tried to search for the ookla page and my bbb kernel paniced! (yay!) >>>> https://pastebin.com/zB9AnWTv >>>> >>>> The next time I booted the entire board hung right after the usb wifi >>>> adapter loaded (chop of hung board output, full output here >>>> https://pastebin.com/M09C5NEP): >>>> >>>> cpsw0: link state changed to UP >>>> bridge0: link state changed to UP >>>> Starting Network: lo0 cpsw0 bridge0. >>>> lo0: flags=3D8049 metric 0 mtu 16384 >>>> options=3D600003 >>>> inet6 ::1 prefixlen 128 >>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >>>> inet 127.0.0.1 netmask 0xff000000 >>>> groups: lo >>>> nd6 options=3D21 >>>> cpsw0: flags=3D8943 >>>> metric 0 mtu 1500 >>>> options=3D8000b >>>> ether a0:f6:fd:8a:c5:be >>>> hwaddr a0:f6:fd:8a:c5:be >>>> inet 192.168.2.101 netmask 0xffffff00 broadcast 192.168.2.255 >>>> media: Ethernet autoselect (100baseTX ) >>>> status: active >>>> nd6 options=3D29 >>>> bridge0: flags=3D8843 metric 0= mtu 1500 >>>> ether 02:94:dd:d7:a3:00 >>>> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >>>> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >>>> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >>>> member: cpsw0 flags=3D143 >>>> ifmaxaddr 0 port 1 priority 128 path cost 55 >>>> groups: bridge >>>> nd6 options=3D9 >>>> Starting devd. >>>> run0 on uhub1 >>>> run0: <1.0> on usbus1 >>>> >>>> U-Boot SPL 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19) >>>> bad magic >>>> >>>> Sometimes it boots, sometimes it hangs (I'd say 3 to 1). The lights on >>>> the cpsw0 interface still blink but the serial console is dead. I'm >>>> trying to *avoid* triggering that so I don't know the sequence that's >>>> causing it. However, I can cause the kernel to panic on the BBB >>>> relatively quickly from a handful of page requests on the ipod. No >>>> more than three full page requests so far. It seems there is a bad >>>> memory copy happening in bridge_broadcast() at bridge_broadcast+0x1c4? >>>> >>>> https://www.freebsd.org/cgi/man.cgi?apropos=3D0&sektion=3D9&query=3Dm_= dup >>>> >>>> Anyway, that's all the time I have for this weekend. I'm going to take >>>> the chance that someone wants to see this and put it in bugzilla. >>>> >>>> Cheers, >>>> >>>> Russ >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221845 >>> >>> Cheers, >>> Russ >> >> Hi, >> >> I've been digging into the code for if_bridge.c, which is found under >> sys/net. bridge_broadcast only has one call to m_dup on line 2553. > From owner-freebsd-arm@freebsd.org Wed Sep 6 18:25:39 2017 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 B0055E0FF4D for ; Wed, 6 Sep 2017 18:25:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 923E58134D for ; Wed, 6 Sep 2017 18:25:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v86IPdiJ028510 for ; Wed, 6 Sep 2017 18:25:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 222107] ifconfig down / up panics the kernel Date: Wed, 06 Sep 2017 18:25:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: heinz@project-fifo.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 18:25:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222107 Bug ID: 222107 Summary: ifconfig down / up panics the kernel Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: heinz@project-fifo.net when running ifconfig down em0 following by ifconfig up em0 the kernel pani= cs: root@thunderx:~ # ifconfig em0 up link state changed to down Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex em0 (iflib ctx lock) r =3D 0 (0xfffffd00041f2d40) loc= ked @ /usr/src/sys/net/iflib.c:3636 stack backtrace: #0 0xffff00000036d390 at witness_debugger+0x64 #1 0xffff00000036e6a0 at witness_warn+0x3fc #2 0xffff0000005fcb3c at data_abort+0xe0 #3 0xffff0000005fc968 at do_el1h_sync+0xfc #4 0xffff0000005e5874 at handle_el1h_sync+0x74 #5 0xffff00000040e9e0 at _iflib_fl_refill+0x370 #6 0xffff00000040e9e0 at _iflib_fl_refill+0x370 #7 0xffff00000040a770 at iflib_init_locked+0x3e0 #8 0xffff00000040f51c at iflib_if_ioctl+0x724 #9 0xffff0000003f6830 at ifioctl+0x1260 #10 0xffff000000372d28 at kern_ioctl+0x358 #11 0xffff000000372980 at sys_ioctl+0x158 #12 0xffff0000005fd548 at do_el0_sync+0x898 #13 0xffff0000005e59f4 at handle_el0_sync+0x74 x0: fffffd000434ce00 x1: fffffd0004155200 x2: 1 x3: 0 x4: 0 x5: 0 x6: 0 x7: ffff0006237765dc x8: 10 x9: ffff0000005e2524 x10: 100000000 x11: ffff000000a949d8 x12: 1 x13: fffffd00041f2d40 x14: ffff000040687e80 x15: ffff00000085a078 x16: 6caa9fec x17: 3bb1bdac x18: ffff0006237765a0 x19: deadc0dedeadc0de x20: fffffd0004155200 x21: fffffd000434ce00 x22: 0 x23: 1 x24: 0 x25: fffffd00bff92000 x26: 0 x27: ffff0000419ea000 x28: 0 x29: ffff000623776610 sp: ffff0006237765a0 lr: ffff00000040e9e4 elr: ffff0000005e2584 spsr: 80000345 far: deadc0dedeadc10e esr: 96000004 panic: data abort in critical section or under mutex cpuid =3D 29 time =3D 1504643295 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff0000005e3ab8 lr =3D 0xffff000000087228 sp =3D 0xffff000623775fc0 fp =3D 0xffff0006237761d0 db_trace_self_wrapper() at vpanic+0x184 pc =3D 0xffff000000087228 lr =3D 0xffff00000030fd84 sp =3D 0xffff0006237761e0 fp =3D 0xffff000623776260 vpanic() at panic+0x44 pc =3D 0xffff00000030fd84 lr =3D 0xffff00000030fe0c sp =3D 0xffff000623776270 fp =3D 0xffff0006237762f0 panic() at data_abort+0x250 pc =3D 0xffff00000030fe0c lr =3D 0xffff0000005fccac sp =3D 0xffff000623776300 fp =3D 0xffff0006237763b0 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff0000005fccac lr =3D 0xffff0000005fc968 sp =3D 0xffff0006237763c0 fp =3D 0xffff0006237763f0 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000005fc968 lr =3D 0xffff0000005e5874 sp =3D 0xffff000623776400 fp =3D 0xffff000623776510 handle_el1h_sync() at _iflib_fl_refill+0x370 pc =3D 0xffff0000005e5874 lr =3D 0xffff00000040e9e0 sp =3D 0xffff000623776520 fp =3D 0xffff000623776610 _iflib_fl_refill() at _iflib_fl_refill+0x370 pc =3D 0xffff00000040e9e0 lr =3D 0xffff00000040e9e0 sp =3D 0xffff000623776620 fp =3D 0xffff0006237766e0 _iflib_fl_refill() at iflib_init_locked+0x3e0 pc =3D 0xffff00000040e9e0 lr =3D 0xffff00000040a770 sp =3D 0xffff0006237766f0 fp =3D 0xffff000623776750 iflib_init_locked() at iflib_if_ioctl+0x724 pc =3D 0xffff00000040a770 lr =3D 0xffff00000040f51c sp =3D 0xffff000623776760 fp =3D 0xffff0006237767b0 iflib_if_ioctl() at ifioctl+0x1260 pc =3D 0xffff00000040f51c lr =3D 0xffff0000003f6830 sp =3D 0xffff0006237767c0 fp =3D 0xffff000623776860 ifioctl() at kern_ioctl+0x358 pc =3D 0xffff0000003f6830 lr =3D 0xffff000000372d28 sp =3D 0xffff000623776870 fp =3D 0xffff0006237768c0 kern_ioctl() at sys_ioctl+0x158 pc =3D 0xffff000000372d28 lr =3D 0xffff000000372980 sp =3D 0xffff0006237768d0 fp =3D 0xffff0006237769a0 sys_ioctl() at do_el0_sync+0x898 pc =3D 0xffff000000372980 lr =3D 0xffff0000005fd548 sp =3D 0xffff0006237769b0 fp =3D 0xffff000623776a70 do_el0_sync() at handle_el0_sync+0x74 pc =3D 0xffff0000005fd548 lr =3D 0xffff0000005e59f4 sp =3D 0xffff000623776a80 fp =3D 0xffff000623776b90 handle_el0_sync() at 0x21ea8 pc =3D 0xffff0000005e59f4 lr =3D 0x0000000000021ea8 sp =3D 0xffff000623776ba0 fp =3D 0x0000ffffffffe320 KDB: enter: panic [ thread pid 845 tid 100347 ] Stopped at bounce_bus_dmamap_sync+0x60: ldr x19, [x19, #48] --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Sep 6 18:34:34 2017 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 A02A8E105F0 for ; Wed, 6 Sep 2017 18:34:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 8F122833EB for ; Wed, 6 Sep 2017 18:34:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v86IYYrV048863 for ; Wed, 6 Sep 2017 18:34:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 222108] adding bridge interface causes kernel panic Date: Wed, 06 Sep 2017 18:34:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: heinz@project-fifo.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 18:34:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222108 Bug ID: 222108 Summary: adding bridge interface causes kernel panic Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: heinz@project-fifo.net Adding a bridge interface as part of the rc.conf causes a kernel panic on startup: bridge0: Ethernet address: 02:a1:f3:11:3d:00 Created clon: bridge0. Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex em0 (iflib ctx lock) r =3D 0 (0xfffffd00041f2d40) loc= ked @ /usr/src/sys/net/iflib.c:3873 stack backtrace: #0 0xffff00000036d390 at witness_debugger+0x64 #1 0xffff00000036e6a0 at witness_warn+0x3fc #2 0xffff0000005fcb3c at data_abort+0xe0 #3 0xffff0000005fc968 at do_el1h_sync+0xfc #4 0xffff0000005e5874 at handle_el1h_sync+0x74 #5 0xffff00000040e9e0 at _iflib_fl_refill+0x370 #6 0xffff00000040e9e0 at _iflib_fl_refill+0x370 #7 0xffff00000040a770 at iflib_init_locked+0x3e0 #8 0xffff00000040f490 at iflib_if_ioctl+0x698 #9 0xffff0000464abcdc at bridge_set_ifcap+0x78 #10 0xffff0000464abc08 at bridge_mutecaps+0xcc #11 0xffff0000464a840c at bridge_ioctl_add+0x40c #12 0xffff0000464a9ca0 at bridge_ioctl+0x174 #13 0xffff0000003f64e4 at ifioctl+0xf14 #14 0xffff000000372d28 at kern_ioctl+0x358 #15 0xffff000000372980 at sys_ioctl+0x158 #16 0xffff0000005fd548 at do_el0_sync+0x898 #17 0xffff0000005e59f4 at handle_el0_sync+0x74 x0: fffffd000434ce00 x1: fffffd0004155200 x2: 1 x3: 0 x4: 0 x5: 0 x6: 0 x7: ffff00062365942c x8: 10 x9: ffff0000005e2524 x10: 100000000 x11: ffff000000a949d8 x12: 1 x13: fffffd00041f2d40 x14: ffff000040687e80 x15: ffff00000085a078 x16: dc318819 x17: 9f8f3c75 x18: ffff0006236593f0 x19: deadc0dedeadc0de x20: fffffd0004155200 x21: fffffd000434ce00 x22: 0 x23: 1 x24: 0 x25: fffffd001b319800 x26: 0 x27: ffff0000419ea000 x28: 0 x29: ffff000623659460 sp: ffff0006236593f0 lr: ffff00000040e9e4 elr: ffff0000005e2584 spsr: 80000345 far: deadc0dedeadc10e esr: 96000004 panic: data abort in critical section or under mutex cpuid =3D 1 time =3D 1504643393 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff0000005e3ab8 lr =3D 0xffff000000087228 sp =3D 0xffff000623658e10 fp =3D 0xffff000623659020 db_trace_self_wrapper() at vpanic+0x184 pc =3D 0xffff000000087228 lr =3D 0xffff00000030fd84 sp =3D 0xffff000623659030 fp =3D 0xffff0006236590b0 vpanic() at panic+0x44 pc =3D 0xffff00000030fd84 lr =3D 0xffff00000030fe0c sp =3D 0xffff0006236590c0 fp =3D 0xffff000623659140 panic() at data_abort+0x250 pc =3D 0xffff00000030fe0c lr =3D 0xffff0000005fccac sp =3D 0xffff000623659150 fp =3D 0xffff000623659200 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff0000005fccac lr =3D 0xffff0000005fc968 sp =3D 0xffff000623659210 fp =3D 0xffff000623659240 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000005fc968 lr =3D 0xffff0000005e5874 sp =3D 0xffff000623659250 fp =3D 0xffff000623659360 handle_el1h_sync() at _iflib_fl_refill+0x370 pc =3D 0xffff0000005e5874 lr =3D 0xffff00000040e9e0 sp =3D 0xffff000623659370 fp =3D 0xffff000623659460 _iflib_fl_refill() at _iflib_fl_refill+0x370 pc =3D 0xffff00000040e9e0 lr =3D 0xffff00000040e9e0 sp =3D 0xffff000623659470 fp =3D 0xffff000623659530 _iflib_fl_refill() at iflib_init_locked+0x3e0 pc =3D 0xffff00000040e9e0 lr =3D 0xffff00000040a770 sp =3D 0xffff000623659540 fp =3D 0xffff0006236595a0 iflib_init_locked() at iflib_if_ioctl+0x698 pc =3D 0xffff00000040a770 lr =3D 0xffff00000040f490 sp =3D 0xffff0006236595b0 fp =3D 0xffff000623659600 iflib_if_ioctl() at bridge_set_ifcap+0x78 pc =3D 0xffff00000040f490 lr =3D 0xffff0000464abcdc sp =3D 0xffff000623659610 fp =3D 0xffff000623659660 bridge_set_ifcap() at bridge_mutecaps+0xcc pc =3D 0xffff0000464abcdc lr =3D 0xffff0000464abc08 sp =3D 0xffff000623659670 fp =3D 0xffff0006236596b0 bridge_mutecaps() at bridge_ioctl_add+0x40c pc =3D 0xffff0000464abc08 lr =3D 0xffff0000464a840c sp =3D 0xffff0006236596c0 fp =3D 0xffff000623659700 bridge_ioctl_add() at bridge_ioctl+0x174 pc =3D 0xffff0000464a840c lr =3D 0xffff0000464a9ca0 sp =3D 0xffff000623659710 fp =3D 0xffff0006236597b0 bridge_ioctl() at ifioctl+0xf14 pc =3D 0xffff0000464a9ca0 lr =3D 0xffff0000003f64e4 sp =3D 0xffff0006236597c0 fp =3D 0xffff000623659860 ifioctl() at kern_ioctl+0x358 pc =3D 0xffff0000003f64e4 lr =3D 0xffff000000372d28 sp =3D 0xffff000623659870 fp =3D 0xffff0006236598c0 kern_ioctl() at sys_ioctl+0x158 pc =3D 0xffff000000372d28 lr =3D 0xffff000000372980 sp =3D 0xffff0006236598d0 fp =3D 0xffff0006236599a0 sys_ioctl() at do_el0_sync+0x898 pc =3D 0xffff000000372980 lr =3D 0xffff0000005fd548 sp =3D 0xffff0006236599b0 fp =3D 0xffff000623659a70 do_el0_sync() at handle_el0_sync+0x74 pc =3D 0xffff0000005fd548 lr =3D 0xffff0000005e59f4 sp =3D 0xffff000623659a80 fp =3D 0xffff000623659b90 handle_el0_sync() at 0x38e60 pc =3D 0xffff0000005e59f4 lr =3D 0x0000000000038e60 sp =3D 0xffff000623659ba0 fp =3D 0x0000ffffffffe470 KDB: enter: panic --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Sep 6 22:38:53 2017 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 C88BFE1B29F for ; Wed, 6 Sep 2017 22:38:53 +0000 (UTC) (envelope-from freebsd@theory14.net) Received: from bacon.theory14.net (bacon.theory14.net [45.55.200.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4D0BF73AD1 for ; Wed, 6 Sep 2017 22:38:53 +0000 (UTC) (envelope-from freebsd@theory14.net) Received: from remote.theory14.net (remote.theory14.net [173.79.116.36]) by bacon.theory14.net (Postfix) with ESMTPSA id BCDDC125ECA; Wed, 6 Sep 2017 18:30:25 -0400 (EDT) Received: from anubis.int.theory14.net (anubis.int.theory14.net [192.168.10.50]) by remote.theory14.net (Postfix) with ESMTPS id 7E98A68EF; Wed, 6 Sep 2017 18:30:25 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? From: Chris Gordon In-Reply-To: Date: Wed, 6 Sep 2017 18:30:25 -0400 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> To: Russell Haley X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 22:38:54 -0000 Russ, > Have you monitored your system on a serial console or direct console > (i.e. via hdmi/keyboard)? Is the system still responding to other > commands after you run the speed test? My thought is that the really > really low bandwidth belies a kernel panic on the main terminal that > you are not seeing. I have a serial console connected the entire time along with ssh = sessions (via wired NIC) into the BBB. There is no panic other other = messages on the console. The devices remains responsive to user = input/actions via ssh. In a previous reply to my initial inquiry, Ilya = Bakulin asked about output from "top -Sa=E2=80=9D thinking the CPU was = overwhelmed. The system stays at >90% idle through the entire test = (upload and download). I see 2-4% WCPU for interrupts and 1-2% for USB. > If you would like to do some further testing, you could perhaps help > me answer these things: It won=E2=80=99t be until next week when I can look at any of these. = I=E2=80=99m one of the organizers at vBSDcon and will be at the Dev = Summit and conference through the weekend. If anyone is interested, = I=E2=80=99m happy to bring my BBB there for debugging/testing on site. > - Can you find a command line way of measuring throughput and latency > separately that can be run on a host and on the bbb? I'm sure there > are lots of ways to do so. I will leave it up to you to decide and > will adopt the same tests so we can compare results. I just have to find another device -- I have everything wired here other = than i-devices. I used nuttcp for testing the wired connection, so I = would plan to use that for the Wifi. > - Can you run the bbb as a standard device (not an access point) and > test the performance of the wlan0 interface using the method of > measurement pointed above? I will do the same at some point with my > wi-fi dongle. Yes, that should be easy to do, but will be next week before I have a = chance. > Some tests I would like to do: > - Get DTrace involved as a debugging tool. I have rudimentary DTrace > skills but will need to consult my books on how to measure throughput > and latency. There are some examples early in the DTrace book of > logging system calls made by a process and I will review that again > when time permits. > - Run the system through the kernel debugger. I think this is going to > be difficult though as pausing the kernel in the middle of TCP traffic > might invalidate any results I get. I know how difficult it can be to > debug threaded applications, I can't see a kernel being any easier. ;) I was thinking along the same lines and hampered only by lack of time = and specific knowledge of what to start poking (of course, this is a = great wqy to learn!). Thanks for your help. I=E2=80=99ll get some info as soon as I can. = Anything important I=E2=80=99ll add to the bug report. Thanks, Chris From owner-freebsd-arm@freebsd.org Thu Sep 7 00:13:24 2017 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 1600AE1F0A0 for ; Thu, 7 Sep 2017 00:13:24 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64178680F1 for ; Thu, 7 Sep 2017 00:13:23 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id 80so16292402lfy.4 for ; Wed, 06 Sep 2017 17:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QxZhqScDn0Yq6CyAN35QI1X50pP3JqWgqdF2UyTwLRI=; b=hkZCMz+lf31scPUGCPp248KWs6Cr+h/XlWdZ20x4fiYOIwHvCRom1ttWMHbRttWmZT TXzt0vkmEfyyKVDWlMrDG5HhUOHozt24SVyjeLOLQmnIqDtmpPWiRHaID5ruhSJXYiI8 wa6ECt02m00XKvxTrwg64HByfhCB3/r0SDZ2PB8gsXeagc6C6uGTKeTYXN91Ca2rLPgA 2wualqjoKB8HuriM/BefHnxQ0+zp/VqtYkoBoZF9eKNmX6nkGjmz3KLT42MtoSNChGdv QpbhmX8WZYyM7Y2u+qJzXe0nFV4W7cz4P2uwGVKpeBUYB4P5uTn/V5XL2JwoLneMTwuq mEww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QxZhqScDn0Yq6CyAN35QI1X50pP3JqWgqdF2UyTwLRI=; b=rBQ+xkHXgRWRJI+bbWCezN6xS9Y8pxkg6yiUqxEFFYkKEH9iPBCsiuaI5+qiYp81/i hu5jZY1RouhAl/K8XkIVRi4QEKaG5Mz5xtdzGNjLzEhKO9zzZf/Zj38nTJ2hs8eQvBKq Ez3J0KP1V6KWw+31e3uby1P78vykFl1DsGWgdlaKE79hp3Gnbgm1UE9e0ay9ZBgtq5mC xxY1M4WmztnMBYTdWONA62UJhebvoJMeyjcrvLai2GvISp8QatXzYfwbF+LJa+DES54J 00wPPYzJfM/uE49THsiTQ+M+pQNStTcJnYFLmyC0p/HoniP9T2Kswoph+1JutgLipxhY jh0Q== X-Gm-Message-State: AHPjjUgTrXgHdUVEZuqm5UhVA8dtV0ChcXoxTmJ0QRVFF25YXejJKe9e j2Xo277n1mXmq8diq1f6OllgSxs2dA== X-Google-Smtp-Source: AOwi7QCWk/nD0ycITxiAEjDvQF64QOP11OVCDi0UoNHWXrKKvAV0uYchuku1JsbgZmo8snFGvIUGKQCYj4hOwLZ/fsc= X-Received: by 10.25.202.77 with SMTP id h13mr307703lfj.54.1504743200238; Wed, 06 Sep 2017 17:13:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Wed, 6 Sep 2017 17:13:19 -0700 (PDT) In-Reply-To: References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> From: Russell Haley Date: Wed, 6 Sep 2017 17:13:19 -0700 Message-ID: Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? To: Chris Gordon Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 00:13:24 -0000 On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon wrote: > Russ, > >> Have you monitored your system on a serial console or direct console >> (i.e. via hdmi/keyboard)? Is the system still responding to other >> commands after you run the speed test? My thought is that the really >> really low bandwidth belies a kernel panic on the main terminal that >> you are not seeing. > > I have a serial console connected the entire time along with ssh sessions= (via wired NIC) into the BBB. There is no panic other other messages on t= he console. The devices remains responsive to user input/actions via ssh. = In a previous reply to my initial inquiry, Ilya Bakulin asked about output = from "top -Sa=E2=80=9D thinking the CPU was overwhelmed. The system stays = at >90% idle through the entire test (upload and download). I see 2-4% WCP= U for interrupts and 1-2% for USB. Good, thanks for clarifying. >> If you would like to do some further testing, you could perhaps help >> me answer these things: > > It won=E2=80=99t be until next week when I can look at any of these. I= =E2=80=99m one of the organizers at vBSDcon and will be at the Dev Summit a= nd conference through the weekend. If anyone is interested, I=E2=80=99m ha= ppy to bring my BBB there for debugging/testing on site. Argh! I was just in Maryland and we flew home from Dulles!!! I made the client push the date forward to last week so I could be home for Labour Day. Have fun! (sob, sob, sob). ;) >> - Can you find a command line way of measuring throughput and latency >> separately that can be run on a host and on the bbb? I'm sure there >> are lots of ways to do so. I will leave it up to you to decide and >> will adopt the same tests so we can compare results. > > I just have to find another device -- I have everything wired here other = than i-devices. I used nuttcp for testing the wired connection, so I would= plan to use that for the Wifi. nuttcp. Got it, I'll start playing with it. >> - Can you run the bbb as a standard device (not an access point) and >> test the performance of the wlan0 interface using the method of >> measurement pointed above? I will do the same at some point with my >> wi-fi dongle. > > Yes, that should be easy to do, but will be next week before I have a cha= nce. > >> Some tests I would like to do: >> - Get DTrace involved as a debugging tool. I have rudimentary DTrace >> skills but will need to consult my books on how to measure throughput >> and latency. There are some examples early in the DTrace book of >> logging system calls made by a process and I will review that again >> when time permits. >> - Run the system through the kernel debugger. I think this is going to >> be difficult though as pausing the kernel in the middle of TCP traffic >> might invalidate any results I get. I know how difficult it can be to >> debug threaded applications, I can't see a kernel being any easier. ;) > > I was thinking along the same lines and hampered only by lack of time and= specific knowledge of what to start poking (of course, this is a great wqy= to learn!). My random thought of the day is that the "down/receive" from eth0 to wlan0 is working somewhat correctly, but the "up/send" from wlan0 to eth0 is causing issues. This is coming from your throughput notes, and the fact I got a whole page downloaded, but received a panic when I was trying to request another page. My thought is to start looking at the send commands for wlan0 and USB. > Thanks for your help. I=E2=80=99ll get some info as soon as I can. Anyt= hing important I=E2=80=99ll add to the bug report. Thanks for having a fun problem to play with! Good luck with the conference and don't worry about time, I have 3 other things that I started this week alone. Anyone want to test a prototype Lua database? lolz. Russ From owner-freebsd-arm@freebsd.org Thu Sep 7 07:03:55 2017 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 9B148E0C437 for ; Thu, 7 Sep 2017 07:03:55 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A56CF82109 for ; Thu, 7 Sep 2017 07:03:54 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id 80so17608024lfy.4 for ; Thu, 07 Sep 2017 00:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Phg/5+vY3exfPzyp0+EAf9KfqnlvgyoCpV0wKEjvhW4=; b=rqUsQYAnH55yzs42kDyGncl70VRnJ8sX9/TVswOF4ZlYawAPa+IfHWM+oV1l2/zWZL ehnw3sY08s86rB4s8/ETke6V5ScXDkSCnFc6AC9I+YKyPNlgmFNYYwE8dtVcA3Nw8eEw DeaucBmtAJ6uI0qAI8Z/MXL9dzCnRZUT6e4SGK2oy0B35w+LAwO03vTxx9HLECqa+yvm vr1LnC/jQftVjrENrrNH7QXlljtJES3x0q9gUrqwWGOHdabQD7fsbwoMVj+vzN3FjCac DxN0KSicbzd0HNChzvkcDcpypK+gi/2cASRZedBUvm/2Pxk21GW4Gvm+odAs+DoUabfp Nbiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Phg/5+vY3exfPzyp0+EAf9KfqnlvgyoCpV0wKEjvhW4=; b=XNPoRFiboIUIzR1u3DanrZSBfX/NKe2/DeZTKCMSqDWhdsL29Ni6f0Y8IRJUVxwxi/ Ek66mlgCNBYJ+Q82D9PYIe2d4wPa1uh8hODNSEZ/w/Umccj7V5jvgKuXDnMIT85abbiu snMA3E72Y/zEvKJBC3U3pzPBDKiPO3sgUNa+0hqtMrTgPG1voepzL/y0eyYAmUKBZZbc FutwHFzF5WZU+oQvcdPlTrZ1r3BzqmVUa+Tiuj3zxXPLuEK0lbWmQregsLYL7cv4di5O dzvan1gbbVe1KTL8kG6/OYCAJ29jquUoeB5cePdDKMWsJwms8dg8O3eg6KaCVGsBryyw TYJg== X-Gm-Message-State: AHPjjUjOdyV2MYmzfXmiZH6a9jv+kWAO3QXkDWY1XaNpFNNRDERZpy6V RiSCLuyk5MDnHbiIKhzgIroBj4HOblfQ X-Google-Smtp-Source: AOwi7QBTyJoQqBPQxJAg5j6CTsAiruhicdk++Cwqj+lQaPUyc+wQ5U/4FTPkzsFyBD1EUnjkjA33S05CzKGK9PWt37E= X-Received: by 10.25.234.220 with SMTP id y89mr621721lfi.188.1504767832521; Thu, 07 Sep 2017 00:03:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Thu, 7 Sep 2017 00:03:51 -0700 (PDT) In-Reply-To: References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> From: Russell Haley Date: Thu, 7 Sep 2017 00:03:51 -0700 Message-ID: Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? To: Chris Gordon Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 07:03:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221845#c3 I've been following the code through and wound up at sys/arm/ti/cpsw/if_cpsw.c. cpsw_intr_rx [which] is defined on line 1554. The function uses a macro called CPSW_RX_LOCK which is defined on line 349. The macro contains an assert on a transmit lock (tx.lock). I theorise the statement on line 350 is causing my exception? I also wonder if the lock being held between lines 1561 and 1570 is causing the delay in the bridge interface that is causing the original posters' slow throughput. Is it necessary to hold the lock until after the cpsw_write_4 on line 1569 or could it be performed outside the lock? zzz, Russ On Wed, Sep 6, 2017 at 5:13 PM, Russell Haley wrote: > On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon wrote= : >> Russ, >> >>> Have you monitored your system on a serial console or direct console >>> (i.e. via hdmi/keyboard)? Is the system still responding to other >>> commands after you run the speed test? My thought is that the really >>> really low bandwidth belies a kernel panic on the main terminal that >>> you are not seeing. >> >> I have a serial console connected the entire time along with ssh session= s (via wired NIC) into the BBB. There is no panic other other messages on = the console. The devices remains responsive to user input/actions via ssh.= In a previous reply to my initial inquiry, Ilya Bakulin asked about output= from "top -Sa=E2=80=9D thinking the CPU was overwhelmed. The system stays= at >90% idle through the entire test (upload and download). I see 2-4% WC= PU for interrupts and 1-2% for USB. > > Good, thanks for clarifying. > >>> If you would like to do some further testing, you could perhaps help >>> me answer these things: >> >> It won=E2=80=99t be until next week when I can look at any of these. I= =E2=80=99m one of the organizers at vBSDcon and will be at the Dev Summit a= nd conference through the weekend. If anyone is interested, I=E2=80=99m ha= ppy to bring my BBB there for debugging/testing on site. > > Argh! I was just in Maryland and we flew home from Dulles!!! I made > the client push the date forward to last week so I could be home for > Labour Day. > > Have fun! (sob, sob, sob). ;) > >>> - Can you find a command line way of measuring throughput and latency >>> separately that can be run on a host and on the bbb? I'm sure there >>> are lots of ways to do so. I will leave it up to you to decide and >>> will adopt the same tests so we can compare results. >> >> I just have to find another device -- I have everything wired here other= than i-devices. I used nuttcp for testing the wired connection, so I woul= d plan to use that for the Wifi. > > nuttcp. Got it, I'll start playing with it. > >>> - Can you run the bbb as a standard device (not an access point) and >>> test the performance of the wlan0 interface using the method of >>> measurement pointed above? I will do the same at some point with my >>> wi-fi dongle. >> >> Yes, that should be easy to do, but will be next week before I have a ch= ance. >> >>> Some tests I would like to do: >>> - Get DTrace involved as a debugging tool. I have rudimentary DTrace >>> skills but will need to consult my books on how to measure throughput >>> and latency. There are some examples early in the DTrace book of >>> logging system calls made by a process and I will review that again >>> when time permits. >>> - Run the system through the kernel debugger. I think this is going to >>> be difficult though as pausing the kernel in the middle of TCP traffic >>> might invalidate any results I get. I know how difficult it can be to >>> debug threaded applications, I can't see a kernel being any easier. ;) >> >> I was thinking along the same lines and hampered only by lack of time an= d specific knowledge of what to start poking (of course, this is a great wq= y to learn!). > > My random thought of the day is that the "down/receive" from eth0 to > wlan0 is working somewhat correctly, but the "up/send" from wlan0 to > eth0 is causing issues. This is coming from your throughput notes, and > the fact I got a whole page downloaded, but received a panic when I > was trying to request another page. My thought is to start looking at > the send commands for wlan0 and USB. > >> Thanks for your help. I=E2=80=99ll get some info as soon as I can. Any= thing important I=E2=80=99ll add to the bug report. > > Thanks for having a fun problem to play with! Good luck with the > conference and don't worry about time, I have 3 other things that I > started this week alone. Anyone want to test a prototype Lua database? > lolz. > > Russ From owner-freebsd-arm@freebsd.org Fri Sep 8 03:21:11 2017 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 D21BAE230F9 for ; Fri, 8 Sep 2017 03:21:11 +0000 (UTC) (envelope-from costumer.ppl@sup.co.uk) Received: from web14.glarotech.ch (web14.glarotech.ch [62.12.149.242]) (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 7B525E64 for ; Fri, 8 Sep 2017 03:21:11 +0000 (UTC) (envelope-from costumer.ppl@sup.co.uk) Received: from merlasco by web14.glarotech.ch with local (Exim 4.89) (envelope-from ) id 1dq9qv-0004Px-N3 for freebsd-arm@freebsd.org; Fri, 08 Sep 2017 05:21:09 +0200 To: freebsd-arm@freebsd.org Subject: verify your account ! From: PayPal Message-Id: Date: Fri, 08 Sep 2017 05:21:09 +0200 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web14.glarotech.ch X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [1197 1197] / [47 12] X-AntiAbuse: Sender Address Domain - sup.co.uk X-Get-Message-Sender-Via: web14.glarotech.ch: authenticated_id: merlasco/only user confirmed/virtual account not confirmed X-Authenticated-Sender: web14.glarotech.ch: merlasco MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 03:21:12 -0000 From owner-freebsd-arm@freebsd.org Fri Sep 8 11:22:03 2017 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 53F65E1214F for ; Fri, 8 Sep 2017 11:22:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 F23E6663EF for ; Fri, 8 Sep 2017 11:22:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v88BM2mt033528 for ; Fri, 8 Sep 2017 11:22:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 222139] iovctl can not create virutal function on thunderx platform Date: Fri, 08 Sep 2017 11:22:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: heinz@project-fifo.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 11:22:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222139 Bug ID: 222139 Summary: iovctl can not create virutal function on thunderx platform Product: Base System Version: 11.1-STABLE Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: heinz@project-fifo.net On FreeBSD 11.1 the SoC 80G network interface can not be used (this seems t= o be resolved on 12) Kernel / Basesystem: FreeBSD thunderx 11.1-STABLE FreeBSD 11.1-STABLE #0 r323168: Wed Sep 6 00:46:23 UTC 2017=20=20=20=20 root@releng2.nyi.freebsd.org:/usr/obj/arm64.aarch64/usr/src/sys/GENERIC ar= m64 /etc/iovctl.conf: PF { device : "vnicpf0"; num_vfs : 1; } running iovctl -C -f /etc/iovctl.conf (no output but prited to the console): vnicpf0: Failed to add VF 0 re-running it erros with: iovctl: Failed to configure SR-IOV: Device busy --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Sep 8 15:18:35 2017 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 97337E1D65F for ; Fri, 8 Sep 2017 15:18:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68D93833E8 for ; Fri, 8 Sep 2017 15:18:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id v19so2390833ite.0 for ; Fri, 08 Sep 2017 08:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=5pAUfT1nUEu8fPNODKu415H5WehzigOj6KichZPZLV8=; b=ftYPz8JSpqan9pXIJeGPywBEtb7rwyXJEM1hQysEMLOyrFzduMGhHymwKdIgINgYhD sQrdv2UoNuh8JL3PwIAMy5GNj+UpLsihzmapjMbWbN+lIcp1u6O1PgNZadsNtghUunxf PguaUrHY7gWmismSrbpuavshQ6qUDs13owX5iZIW6OA+EEmQlJPAbDm4F6+x/vo8h2es ouTsUNlcoeXTz18UnbCgwiN4Pq8BZN+YZt44wZEzIJ5aG6jnLiVVzUKNflOPiwwjxhDa 9vkABP6aH3o4voLhMwY59pCItw4mRHypfYjOcLpOIUgQ1nYlToFtZkXdzeaW1ogbsK3L 7WxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=5pAUfT1nUEu8fPNODKu415H5WehzigOj6KichZPZLV8=; b=nEKfIlzdc8RrD0CRxFpJhuF3sITTwE6WXMmEHMk3wpUwW5aO5ReSlza4URWYT7Ti3c /8vtjg7lpIVtzTVxchlp8evPY2AQTKS9TtMNhSjeITGFhOW9e4Dr9lv/0IJaVE8nmYpj /n3u4me/QG7mco54e9SPEfj6tU9uMk0THBDfk65IbFG74GFduCoLC+4OkMCsyKzU/n+B ATSFdZruN5EwCsoppxlJNnMozVJMDZkT8bqkjxYuZQog/2LTkP9YpodtDNgM/9kPV3UD JP096yIxBO9hGeksC4rREwBG50DnhEV2WNFgkxhgYsTqKIBesPIOcb5Vq+qDOzoADjXf WRwA== X-Gm-Message-State: AHPjjUj2T2s+Jqgxh3phCBpIkqXy/TzuRkx4CFCwhFtTUhTEE7PdZF1R 0JRYya+gSRWpRZpp0RBrHoG/XCr2kcnS9sc= X-Google-Smtp-Source: AOwi7QC+qAfWscolJiF3joL4fjP70+3y7PpD88kf8kiDEPN5A29NHtmU89FdHACgty4dGp9YqLf+7jI3CR4ZpefB5Gg= X-Received: by 10.36.150.198 with SMTP id z189mr1365376itd.63.1504883914182; Fri, 08 Sep 2017 08:18:34 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Fri, 8 Sep 2017 08:18:33 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d5ae:f1f3:42c8:b0f7] From: Warner Losh Date: Fri, 8 Sep 2017 09:18:33 -0600 X-Google-Sender-Auth: 3AOZQCzQWdhbyfo7TTAS_FSzjsE Message-ID: Subject: Heads up To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 15:18:35 -0000 Greetings, During the transition from soft to hard float, I made the default behavior of the system as follows: 1. If the binary is hard float use the default ld.so paths 2. if there was no /usr/libsoft directory, use the default ld.so paths 3. otherwise use the soft ld.so paths. which was fine as a transition in a -current environment which has rough edges, but is now causing problems for people trying to execute FreeBSD 10 binaries on FreeBSD 11. I'd like to propose that we eliminate step 2 above so we detect this cross-threading by default. Furthermore, the above algorithm is used, even on armv4/v5 binaries where we can't possibly have hard floating point. I'd further propose that we eliminate the above algorithm altogether for those systems, or more generally when we're compiling for soft floating point. Please see https://reviews.freebsd.org/D12274 to comment on the code. I believe this won't change anybody's FreeBSD experience, unless they have an ld.so compiled for hard float, but every single other binary on the system is somehow soft float. The only time I'm aware of when this happens is when one is jumping the chasm from soft to hard float in an installworld situation, which we can cope with LD_SOFT_ env settings for those that want to jump from 10->current (which I posit may not exist). Comments? Warner From owner-freebsd-arm@freebsd.org Fri Sep 8 23:11:06 2017 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 62A80E10A32 for ; Fri, 8 Sep 2017 23:11:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36AE46E908 for ; Fri, 8 Sep 2017 23:11:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id c195so6157246itb.1 for ; Fri, 08 Sep 2017 16:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=7k5+lM0EWkcVO6XayDoIT6rV7wDuUVv5IWvnBJ35WwI=; b=AIVjYBO6GvRJhQA2hAynfA7NX+XMVq4tkhoBS4mp1bvVwE/iU8R9LMen5lptOQPJZY BuHEDpQgICud7ycxSn32/+5LuVFxxTJJFIgR7NX4QteOZnNm0PQrjJUtw5J2DUANfpzM DQbjYKvzIMwB/oFN8xK30bTqA6YkoUMSe0M4fPu8qmmixJLb5ZisoCk+kG7ARGnnHQsM TTfKsB0Cbi7TsHfROAB4LoGN4DWQfqzPQWE9MAf3DIrRpAS4eKbJDhcSGJ9OeSoxhxEb gPxqhHnxP+5CFa1q+pPbmQtuhPjbvAImP4qc8TsBqgD5lrY59Snf10R50hACBlQ/XOpY GYGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=7k5+lM0EWkcVO6XayDoIT6rV7wDuUVv5IWvnBJ35WwI=; b=JdMad9HLyQ0Lj4zd9D5iHOOEo4sTzulonM2SfEGpZnI9uDveiqoy2brdHc+CpcdTMw m53Zrom5LpCZw1RR9Ga0YBGrCWh/wwyuooytfDhAMn+LEVCKzuZnEEHjirIsgmz7P/16 16H5F0GHFZEG0TlZJDSmPzjY6f3a+KyDECQMt2kYy693RLmTLqMilPDF46WHV6oXO+83 Cn3HgzBIEWk27reCjtxKopSxEzuMetw6xPLlaS+2DGTPKuYwTlRu+mxujUSEhQYNIkDj SaFUultLV9xX+89q/kUKJGzFQPqewwmp4ymhs3xyo6bfN++uugJ4qpic4W/24IhoXEjb 6yXg== X-Gm-Message-State: AHPjjUifrus2nnpb2B4ifFb8P875sRFtfAYpa5qxneqklYVGsGwi4dM7 JNjAAYqTyhS9d5RFeBUmRFoSWPbhlkCq5NA= X-Google-Smtp-Source: ADKCNb6pABPKF3d1sQputfEM4fnwXz/12mxyKefcsOY4b8dJj+7WXw/h1sYKzcoS/J84KRz6piEeQgLOtt+80VNKJfU= X-Received: by 10.36.179.79 with SMTP id z15mr3446935iti.26.1504912265386; Fri, 08 Sep 2017 16:11:05 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Fri, 8 Sep 2017 16:11:04 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d5ae:f1f3:42c8:b0f7] From: Warner Losh Date: Fri, 8 Sep 2017 17:11:04 -0600 X-Google-Sender-Auth: j9ICoGeFYhLdcpnpNEjHMPD4sRE Message-ID: Subject: FCP-100: armv7 plan To: "freebsd-arm@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 23:11:06 -0000 Greetings, This will serve as 'Last Call' for any objections to the plan to create an armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. Please see https://github.com/freebsd/fcp/blob/master/fcp-0100.md for all the details. This has been discussed in the mailing lists, on IRC, etc and I believe that I've captured the consensus from those discussions. I'm interested in any last minute comments, but as far as I can tell I have consensus on this issue. Absent any comments to the contrary, I'll proceed to having core@ vote that this document represents consensus. Now is the time to speak up if I've gotten anything wrong. Once the core vote is done, I plan on committing the code reviews I have open on this: https://reviews.freebsd.org/D12027 and https://reviews.freebsd.org/D12010 (again, I welcome any commits / criticisms in phabricator on the specific issues in this code) Thanks for any comments... Warner From owner-freebsd-arm@freebsd.org Sat Sep 9 01:53:02 2017 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 8F9CEE19E33; Sat, 9 Sep 2017 01:53:02 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15F087418D; Sat, 9 Sep 2017 01:53:02 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id l196so8837603lfl.1; Fri, 08 Sep 2017 18:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xm7EaiP6G6i8yysmfJEpfljslx4YGUEb6TlhxBlOpCs=; b=iKMY9X4NfKrP5qkz+r1rUrz7zl4HgVdKn/7jb6tCM+RpIRe/A2uATWkE37QMr7XlI2 4wg8gBMkMXD0EbzMPJLiEX0S13PDJtgfxy2zY7ugPKj3RD5kGk3ANdJ8RCA6Mz/dbAYf SjS/zzMSM3w2f2RHCV0DrvBivfuIoZeh7ll2m6zdHqnvq9phRZ+sMQnPl9YkR0KvJqm1 ytTHiBJhq0SDNyGhz8uKLY3rt0NDUlZu12rpLvBlx1KreENOlYlTAls6mJ9H7EpJ+B+o ZwHlw3RrwTtsevSiwZkOnoTa4bGvCgs7aQ1HcFiQsCD3M+OEfacCKw1gAVK9OKtPp8uy AYbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xm7EaiP6G6i8yysmfJEpfljslx4YGUEb6TlhxBlOpCs=; b=Zl6oWWvravhAGWHuMBLLZxC/N6Q5qzaCb/wX53fyZel7EIBFtSrASuzmZljfOVoxqv uLD2MWhLvmVjavbZnK03mh1s+YcjGAItB6GqWl021VmmwD6yhQLbE5tI1JYWLZAGLmTO PiD3W9ZuoTKLCeRcXoYN6c4ONkbJsTjQHvkgWb5qe/C3ApLWcvqZshG817b/J8IkNonU j8A5oaRq+RcNqH4vmlVttxTMWgHPttQqonQ5tmWmmpToI7Q56hjBLPC+LoabSOKyKj8v FhEqaJdyiw2p4+UWzwaBwcN0lHUV/qFEiW1i8JjneSBdRjVeC1JJURW/qEJQY1iYbIvy Bggw== X-Gm-Message-State: AHPjjUhXZyMugM5UgchsT98+ukgZjzN7I3AcNyRJzVIZY/e/qlif2ECW irLDBZ+9r9cgpGAZ6DTSz0xjK+9F1vvqrGs= X-Google-Smtp-Source: ADKCNb5fIYWcRzt0+PWw/3L6s2Qe3VRg/qXpEtyoJ7x65BQyOn8gwAx0vxitkdAXhUdvpahP1t/iRDam0xfMihULhW4= X-Received: by 10.46.34.67 with SMTP id i64mr1719191lji.71.1504921980079; Fri, 08 Sep 2017 18:53:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Fri, 8 Sep 2017 18:52:59 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Fri, 8 Sep 2017 18:52:59 -0700 Message-ID: Subject: Re: FCP-100: armv7 plan To: Warner Losh Cc: "freebsd-arm@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 01:53:02 -0000 On Fri, Sep 8, 2017 at 4:11 PM, Warner Losh wrote: > Greetings, > > This will serve as 'Last Call' for any objections to the plan to create an > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > > Please see https://github.com/freebsd/fcp/blob/master/fcp-0100.md for all > the details. This has been discussed in the mailing lists, on IRC, etc and > I believe that I've captured the consensus from those discussions. > > I'm interested in any last minute comments, but as far as I can tell I have > consensus on this issue. Absent any comments to the contrary, I'll proceed > to having core@ vote that this document represents consensus. Now is the > time to speak up if I've gotten anything wrong. > > Once the core vote is done, I plan on committing the code reviews I have > open on this: > https://reviews.freebsd.org/D12027 > and > https://reviews.freebsd.org/D12010 > (again, I welcome any commits / criticisms in phabricator on the specific > issues in this code) > > Thanks for any comments... > > Warner > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Hi Warner, Thanks for your work on this. General thoughts in and around this subject. 1) I like how you split the commit into generic build system changes vs BSP changes. It was helpful in aiding visibility in the code changes. 2) Are these statements true? - We will not be differentiating hard/soft float. It is assumed armv6/7 are hard float (no letter suffixes) - armv4/5 has no changes - armv6 is split into armv6, armv7 - armv8 is aarch64 - We will not be supporting aarch64 32 bit extensions for running armv6/7 binaries - There is no way to run aarch64 on armv7 3) Can I ask if there will be other armv[0-9+] architectures created or do you think everything new will transition to 64 bit? If so, will we (FreeBSD) be able to differentiate those architectures in the future (aarch64v2)? I guess what I'm asking is "in your expert opinion, have we taken enough steps to ensure clean code/names/you-get-my-point for future changes?" What else could we do? It seems that there is a lot of changes in arm compared to other architectures. The rapid development of different things by the Arm group and other vendors seems to cause a lot of churn. Do you think our naming conventions do enough to take this into consideration? Modern hardware manufacturing seem much different then what I am reading about in Unix history. Have our naming patterns kept up? 4) Also, if my supposition about arm 32/64 compatibility is correct, do we have plans in place for future boards may have 32/64 bit compatibility like the RPi3? Or, is it just two different builds and downloads? (which I'm cool with, but would like to know) Cheers, Russ From owner-freebsd-arm@freebsd.org Sat Sep 9 03:34:57 2017 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 2066AE21BB2 for ; Sat, 9 Sep 2017 03:34:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 D34357C62A for ; Sat, 9 Sep 2017 03:34:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19793 invoked from network); 9 Sep 2017 03:40:17 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Sep 2017 03:40:17 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Fri, 08 Sep 2017 23:34:55 -0400 (EDT) Received: (qmail 14498 invoked from network); 9 Sep 2017 03:34:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2017 03:34:54 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 3789BEC7888; Fri, 8 Sep 2017 20:34:54 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r 323246 /usr/src/sys/arm64/arm64/pmap.c:. . . error: no previous prototype for function 'pmap_invalidate_page' (also pmap_invalidate_range and pmap_invalidate_all) Message-Id: Date: Fri, 8 Sep 2017 20:34:53 -0700 Cc: FreeBSD Toolchain To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 03:34:57 -0000 This was from an amd64 -> arm64.aarch64 cross build context and was an attempt to build a debug kernel. # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r323246M amd64 = amd64 1200043 1200043 # svnlite info /usr/src/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 323246 Last Changed Rev: 323246 --- pmap.o --- /usr/src/sys/arm64/arm64/pmap.c:903:1: error: no previous prototype for = function 'pmap_invalidate_page' [-Werror,-Wmissing-prototypes] pmap_invalidate_page(pmap_t pmap, vm_offset_t va) ^ /usr/src/sys/arm64/arm64/pmap.c:917:1: error: no previous prototype for = function 'pmap_invalidate_range' [-Werror,-Wmissing-prototypes] pmap_invalidate_range(pmap_t pmap, vm_offset_t sva, vm_offset_t eva) ^ /usr/src/sys/arm64/arm64/pmap.c:934:1: error: no previous prototype for = function 'pmap_invalidate_all' [-Werror,-Wmissing-prototypes] pmap_invalidate_all(pmap_t pmap) ^ . . . 3 errors generated. *** [pmap.o] Error code 1 make[2]: stopped in = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG .ERROR_TARGET=3D'pmap.o' = .ERROR_META_FILE=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/= GENERIC-DBG/pmap.o.meta' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose curdirOk=3Dyes' _ERROR_CMD=3D'cc -mcpu=3Dcortex-a53 -target aarch64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp = -B/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/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 = -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only = -ffixed-x18 -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__=3D__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 -Wno-error-shift-negative-value = -Wno-error-address-of-packed-member -std=3Diso9899:1999 -Werror = /usr/src/sys/arm64/arm64/pmap.c; ctfconvert -L VERSION -g pmap.o;' = .CURDIR=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-D= BG' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-D= BG' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' MAKEOBJDIRPREFIX=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr/s= bin:/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr/bin:/= usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/bin:/usr/obj/c= ortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/sbin:/usr/obj/cortexA53dbg= _clang/arm64.aarch64/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.cortexA53dbg-clang-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null Makefile = /usr/src/sys/conf/kern.pre.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/kern.post.mk = /usr/src/sys/conf/kern.mk' .PATH=3D'. = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG' 1 error # grep -r pmap_invalidate_page /usr/src/sys/arm64/ | more /usr/src/sys/arm64/arm64/pmap.c:pmap_invalidate_page(pmap_t pmap, = vm_offset_t va) /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(kernel_pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(kernel_pmap, kernel_vm_end); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, pv->pv_va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, sva); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, pv->pv_va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, pv->pv_va); I will note that WERROR=3D was not in use: # more ~/src.configs/src.conf.cortexA53dbg-clang-bootstrap.amd64-host=20 TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} # KERNCONF=3DGENERIC-DBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD_BOOTSTRAP=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D #MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # #CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. I will note that there are other architectures with the likes of: /usr/src/sys/i386/include/pmap.h:void pmap_invalidate_page(pmap_t, = vm_offset_t); /usr/src/sys/mips/mips/pmap.c:static void pmap_invalidate_page(pmap_t = pmap, vm_offset_t va); /usr/src/sys/amd64/include/pmap.h:void pmap_invalidate_page(pmap_t, = vm_offset_t); =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Sep 9 05:10:26 2017 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 C40E2E031CA for ; Sat, 9 Sep 2017 05:10:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EF987F8D7 for ; Sat, 9 Sep 2017 05:10:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id i14so9354067ioe.2 for ; Fri, 08 Sep 2017 22:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XQZzCgIdGYWaBoa53PuqGKoN/rbGJcnYOYnyxTLmfAk=; b=tqlpEGEtZMeq3uyZBc+5guN8AyTpynfTNDzAHQ7cvsaY9fW19asOYH1ZmBpufsYXJo yHJWU9H44MNGsk/33E3UbYRdMBa0dJY9ZVqt2xMy534WA8acvkrKhv7QQpt536QgQeg0 8CRAl6thCC2tPYSQ/5Mjhwpyi+HMSyYmbmsbTtjvT9cRED0YVwTC8lRjhNOvPUSA5k6h Ob+XS+Nd+8H+O2TNrcl34end+5nFoTmthC04EkPv9V9CO2N6h5QV+6piVjdVhqqGBsRU Jk1uVOcLRCpD4SCvmU0xzAqtyMkmBdEs29IWBewmlqMIMLIOajRJrASNSItOVS+FpFow GrUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XQZzCgIdGYWaBoa53PuqGKoN/rbGJcnYOYnyxTLmfAk=; b=C243yTZJzt9nNwwePXb7p4yszQ0Y3eWqOHtZC8TiKpphgsL/RoJTHRWbp0xOT0KvYe RVwKCA7w1Xt3AVq85SH7M4LynNv3AdUjvC4DFvSm1hxiDo30+k2T2oOisUppBseHpFbD n8aZ4rkDw3ia5kOu++UrguhwHxDEdE2IA3TG+kUTkp4pt7yOg6PmU/TXx4okxqMAmKnP gQcjCZbBqyNCPQq/WZAETt1wXzygCPjGX+el2UlxhMxAH5P7MHe4Diqvq5z4rQt0xnqL z0nLFw+xTbLobk8dM417GePafzmKvCgs8mZxwmOPyDOp4q/EBmejsw0bbqRuYv4LQyXs bEMA== X-Gm-Message-State: AHPjjUhCcu1PrIySE0qwpaN2axF5fe56GVsVkRPSy3HJqqP6RQLTbVza oiaOYyuvco5lx8N/Ki10fCa357Je1XUf X-Google-Smtp-Source: AOwi7QBsL9THXylGfAKBUMm/IStLJMfynR5zDROaMRTOZSWPeaJM4aYXOjSCdbNZNinE8tgylFg42q6NQ8+U8aFKtrU= X-Received: by 10.107.185.7 with SMTP id j7mr4475431iof.221.1504933825673; Fri, 08 Sep 2017 22:10:25 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Fri, 8 Sep 2017 22:10:25 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d5ae:f1f3:42c8:b0f7] In-Reply-To: References: From: Warner Losh Date: Fri, 8 Sep 2017 23:10:25 -0600 X-Google-Sender-Auth: 7qz0nEKSezR6f3L6Dvt341iKQns Message-ID: Subject: Re: FCP-100: armv7 plan To: Russell Haley Cc: "freebsd-arm@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 05:10:26 -0000 On Fri, Sep 8, 2017 at 7:52 PM, Russell Haley wrote: > On Fri, Sep 8, 2017 at 4:11 PM, Warner Losh wrote: > > Greetings, > > > > This will serve as 'Last Call' for any objections to the plan to create > an > > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > > > > Please see https://github.com/freebsd/fcp/blob/master/fcp-0100.md for > all > > the details. This has been discussed in the mailing lists, on IRC, etc > and > > I believe that I've captured the consensus from those discussions. > > > > I'm interested in any last minute comments, but as far as I can tell I > have > > consensus on this issue. Absent any comments to the contrary, I'll > proceed > > to having core@ vote that this document represents consensus. Now is the > > time to speak up if I've gotten anything wrong. > > > > Once the core vote is done, I plan on committing the code reviews I have > > open on this: > > https://reviews.freebsd.org/D12027 > > and > > https://reviews.freebsd.org/D12010 > > (again, I welcome any commits / criticisms in phabricator on the specific > > issues in this code) > > > > Thanks for any comments... > > > > Warner > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > Hi Warner, > > Thanks for your work on this. General thoughts in and around this subject. > > 1) I like how you split the commit into generic build system changes > vs BSP changes. It was helpful in aiding visibility in the code > changes. > Thanks. > 2) Are these statements true? > > - We will not be differentiating hard/soft float. It is assumed > armv6/7 are hard float (no letter suffixes) > Yes. We switched to only hard float on armv6 prior to the switch. While one can still build a softfloat system, it's not really supported (we don't test it, we don't build packages for it, etc). That support exists in the tree for the transition libraries only and may be removed in the future. > - armv4/5 has no changes > Correct. > - armv6 is split into armv6, armv7 > Yes. > - armv8 is aarch64 > armv8 has no (current) meaning to FreeBSD. > - We will not be supporting aarch64 32 bit extensions for running > armv6/7 binaries > That's an orthogonal problem that a aarch64 kernel will solve, but is unrelated to the build system. > - There is no way to run aarch64 on armv7 > Nope. > 3) Can I ask if there will be other armv[0-9+] architectures created > or do you think everything new will transition to 64 bit? If so, will > we (FreeBSD) be able to differentiate those architectures in the > future (aarch64v2)? I guess what I'm asking is "in your expert > opinion, have we taken enough steps to ensure clean > code/names/you-get-my-point for future changes?" What else could we > do? It seems that there is a lot of changes in arm compared to other > architectures. The rapid development of different things by the Arm > group and other vendors seems to cause a lot of churn. Do you think > our naming conventions do enough to take this into consideration? > Modern hardware manufacturing seem much different then what I am > reading about in Unix history. Have our naming patterns kept up? > Those are all good questions. While it's hard to say for sure they won't be any new armvX architectures that implement 32-bit ABIs, there's been a strongly telegraphed signal that all new ARM innovation will be in the 64-bit area. They've also claimed that new revisions of aarch64 will be more orderly and less chaotic than things have been in the 32-bit arm world. It's unclear still if that will actually be the case, but given we have little basis for guessing the proper names in the future, it's hard to future-proof here. > 4) Also, if my supposition about arm 32/64 compatibility is correct, > do we have plans in place for future boards may have 32/64 bit > compatibility like the RPi3? Or, is it just two different builds and > downloads? (which I'm cool with, but would like to know) > The notion is that for those AARCH64 SoCs that have the ability to run 32-bit, we'll have two builds. One will be aarch64 based and the other armv7 based. We'll likely roll that into armv7 GENERIC so we can get away from having so many distributions (move to more of a base image + flavoring step), but that work isn't complete enough to talk much about. Work to make RPI3 work with a 32-bit kernel appears to be reaching completion. There should be something there soon (if it hasn't already been announced...) Warner From owner-freebsd-arm@freebsd.org Sat Sep 9 05:33:15 2017 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 9EAFFE03F10; Sat, 9 Sep 2017 05:33:15 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 20C5B804BD; Sat, 9 Sep 2017 05:33:15 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id c80so9284818lfh.0; Fri, 08 Sep 2017 22:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O52EakqqlfaNiSF+vZjqH75XWe65SN/guKL9B4aQLcQ=; b=sh9KDt4DRoErk55ozpMRmkpHwMzM/WHT07kqTh1XJxY6vCLJLPLnZLOXMvJk3JtbDu WBd4RkAJD/Vc/kgzvMlmA6cj3gIhcDK2GyLshtLWnf3B2ZmyZS/aWf5BvtqssAitfvgs kFVumtCnllmVIiWb5n4VWJiy5lm1kLjG/bvlGljQO5+WCoCF1b7ifj7nZzXcdXVbL8iY ZyyRnNNAOJcEqEY4fPIeDp6PhFOG7huSv4wHnBZz95lUtFCLwTevu+MOjFf+z9RY1Jwq yhRPG1jI1ASE09074vTKmBterMjo0QMBMJi7B3/VpHgqYuE7QMr/3MyMVzoyDrWB9KHt uA8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O52EakqqlfaNiSF+vZjqH75XWe65SN/guKL9B4aQLcQ=; b=O4ak+qYQs9iBTMDwqCZKt4XwYuyEQyfMRD4mXTWlEGDDtQE4yILU29GxUJvydZ0b0U TARUJWYFTKLu66OZcwIDumoQwrrGPzbnjpuVGX22nBH4r87MhZC8XZc1l3UxGhE/0hna yxT0LY9XEy9kuWNGwQRPAa8Sbp0qVrSsH3C94gtuaalCbqJPxNW3LaDW+aZwRDpdl0SA VEbL4K7oiZK7RoyfwniEx2HB9j6tJWkBz967nn7763lQ9rXbrBPKNrR+TnC2rUffk12E syJI9vjaLMKm36Cl+vDQprvKVaPg6kFPn5uCeE4h/eX2poSgYF74S/vdwyreeLTh15rA Ch5g== X-Gm-Message-State: AHPjjUiON2SHooOl5ljRvhXi4+j4nq/lsOBcm2frSUVa6vH1JTj+TRNA cZPevHT3KchVZ3FuAJ4+DPvyPc/0qmrmsYk= X-Google-Smtp-Source: AOwi7QDBRiSeEQvY+u7q4NB+E7HjJZt5TIlm61LpjikDVLFghZOMAAHHSSVq1aW50p31QDWTTEy07qZpGJC0TUqaKZ8= X-Received: by 10.25.87.79 with SMTP id l76mr2215114lfb.117.1504935192763; Fri, 08 Sep 2017 22:33:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Fri, 8 Sep 2017 22:33:12 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Fri, 8 Sep 2017 22:33:12 -0700 Message-ID: Subject: Re: FCP-100: armv7 plan To: Warner Losh Cc: "freebsd-arm@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 05:33:15 -0000 On Fri, Sep 8, 2017 at 10:10 PM, Warner Losh wrote: > > On Fri, Sep 8, 2017 at 7:52 PM, Russell Haley wrote: >> >> On Fri, Sep 8, 2017 at 4:11 PM, Warner Losh wrote: >> > Greetings, >> > >> > This will serve as 'Last Call' for any objections to the plan to create >> > an >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. >> > >> > Please see https://github.com/freebsd/fcp/blob/master/fcp-0100.md for >> > all >> > the details. This has been discussed in the mailing lists, on IRC, etc >> > and >> > I believe that I've captured the consensus from those discussions. >> > >> > I'm interested in any last minute comments, but as far as I can tell I >> > have >> > consensus on this issue. Absent any comments to the contrary, I'll >> > proceed >> > to having core@ vote that this document represents consensus. Now is the >> > time to speak up if I've gotten anything wrong. >> > >> > Once the core vote is done, I plan on committing the code reviews I have >> > open on this: >> > https://reviews.freebsd.org/D12027 >> > and >> > https://reviews.freebsd.org/D12010 >> > (again, I welcome any commits / criticisms in phabricator on the >> > specific >> > issues in this code) >> > >> > Thanks for any comments... >> > >> > Warner >> > _______________________________________________ >> > freebsd-arm@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> >> Hi Warner, >> >> Thanks for your work on this. General thoughts in and around this subject. >> >> 1) I like how you split the commit into generic build system changes >> vs BSP changes. It was helpful in aiding visibility in the code >> changes. > > > Thanks. > >> >> 2) Are these statements true? >> >> - We will not be differentiating hard/soft float. It is assumed >> armv6/7 are hard float (no letter suffixes) > > > Yes. We switched to only hard float on armv6 prior to the switch. While one > can still build a softfloat system, it's not really supported (we don't test > it, we don't build packages for it, etc). That support exists in the tree > for the transition libraries only and may be removed in the future. > >> >> - armv4/5 has no changes > > > Correct. > >> >> - armv6 is split into armv6, armv7 > > > Yes. > >> >> - armv8 is aarch64 > > > armv8 has no (current) meaning to FreeBSD. > >> >> - We will not be supporting aarch64 32 bit extensions for running >> armv6/7 binaries > > > That's an orthogonal problem that a aarch64 kernel will solve, but is > unrelated to the build system. > >> >> - There is no way to run aarch64 on armv7 > > > Nope. > >> >> 3) Can I ask if there will be other armv[0-9+] architectures created >> or do you think everything new will transition to 64 bit? If so, will >> we (FreeBSD) be able to differentiate those architectures in the >> future (aarch64v2)? I guess what I'm asking is "in your expert >> opinion, have we taken enough steps to ensure clean >> code/names/you-get-my-point for future changes?" What else could we >> do? It seems that there is a lot of changes in arm compared to other >> architectures. The rapid development of different things by the Arm >> group and other vendors seems to cause a lot of churn. Do you think >> our naming conventions do enough to take this into consideration? >> Modern hardware manufacturing seem much different then what I am >> reading about in Unix history. Have our naming patterns kept up? > > > Those are all good questions. While it's hard to say for sure they won't be > any new armvX architectures that implement 32-bit ABIs, there's been a > strongly telegraphed signal that all new ARM innovation will be in the > 64-bit area. They've also claimed that new revisions of aarch64 will be more > orderly and less chaotic than things have been in the 32-bit arm world. It's > unclear still if that will actually be the case, but given we have little > basis for guessing the proper names in the future, it's hard to future-proof > here. > >> >> 4) Also, if my supposition about arm 32/64 compatibility is correct, >> do we have plans in place for future boards may have 32/64 bit >> compatibility like the RPi3? Or, is it just two different builds and >> downloads? (which I'm cool with, but would like to know) > > > The notion is that for those AARCH64 SoCs that have the ability to run > 32-bit, we'll have two builds. One will be aarch64 based and the other armv7 > based. We'll likely roll that into armv7 GENERIC so we can get away from > having so many distributions (move to more of a base image + flavoring > step), but that work isn't complete enough to talk much about. > > Work to make RPI3 work with a 32-bit kernel appears to be reaching > completion. There should be something there soon (if it hasn't already been > announced...) > > Warner > > https://www.netgate.com/products/sg-3100.html ? ;) Russ From owner-freebsd-arm@freebsd.org Sat Sep 9 19:06:04 2017 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 12D88E02F13; Sat, 9 Sep 2017 19:06:04 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E84B574110; Sat, 9 Sep 2017 19:06:03 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 467C08B24; Sat, 9 Sep 2017 19:06:03 +0000 (UTC) From: Jan Beich To: Warner Losh Cc: freebsd-arm@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: FCP-100: armv7 plan References: Date: Sat, 09 Sep 2017 21:05:57 +0200 In-Reply-To: (Warner Losh's message of "Fri, 8 Sep 2017 17:11:04 -0600") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 19:06:04 -0000 Warner Losh writes: > Greetings, > > This will serve as 'Last Call' for any objections to the plan to create an > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. [...] Some ports want NEON support but FCP-0100 is vague about FreeBSD-specific differences between armv6 and armv7. Clang appears to enable NEON for all *-gnueabi* targets but I have no clue about GCC. Apparently, Android and Debian don't assume NEON on armv7. related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 From owner-freebsd-arm@freebsd.org Sat Sep 9 19:14:38 2017 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 97740E03730 for ; Sat, 9 Sep 2017 19:14:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8D5746FF for ; Sat, 9 Sep 2017 19:14:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id o200so9635575itg.0 for ; Sat, 09 Sep 2017 12:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=e33g3XNtCEg4FWZf6sC7BLlQC1u2IX17wsYyu/4FFLA=; b=o2FCRr0qRqH3IKfbdBrGa42RYF7HPCkkQ/RrdIq9k6n2CHa6gzYRF9pTK9U2U7ukVP nv/SDY9QOIO7+QNhEYoeHAphs9Q4H6HHFmBdHMvapzcrXmQOe07mWvTTsAMlOvSQ+PV7 v/BTCW0FMxk3ylHi3GFRGBLNprpwG/A0pEbB5P6HhowJh6lO/pU/rq7UfKpVSGsYQFLh 58L053Ga+KW8W1XCSv6DrsNgYUvhylK/9fNfJzptl+7W0mfnPO/n0HM9FtGGD5MDRPEB k/+nRhUgZQAtKFZ/TSYQkTBItAuyTK1ZDlzr+FCCWlHineVpB8xvSw4tfnzGOgS7p2tn PgSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=e33g3XNtCEg4FWZf6sC7BLlQC1u2IX17wsYyu/4FFLA=; b=CuPbznUpxkVlfSf3gYInGaT4S/XOBQ7oWQ6sIQGMlwyHJORgM+uAlGd/1F9Q7vtPph SDH59JukUeRSXFzd61+9IpQtGgnv8UtTRfxrFkDGbk8Ci6m8K0m6VaDGVShjKnOieIxm V/XCaZbpC7SeeTwcLG95sb2hSoo3KFPfvJPaE9wVvS9cXrg/DIwMwo4/ee8ooZlPin9h 239NZTEB9HRU1bRC7jjw4nV1n7uUjW8GykYdAA3jkDQgNkftl4rWYSbHgCscrGMBoqNl b4/zekgbGM/Wxv4aztkWVSSLuyQT9Hs1xaFakkrkMxNzUHiQqherBjgrMOvyt1ecTAfT o0PQ== X-Gm-Message-State: AHPjjUhvKzybV8Qr0JbMAdmQfExHkF20eiG9D5GRCMWncpCAR6Sk0sjH WdrFMG8G5VvAxI7MmKHYiF4E6/ItDXaR X-Google-Smtp-Source: ADKCNb6VUAvLjylT8s5N6cMdXB99HZNHrCRyBRrbYNu3CXqwfMvel1ob1k1eGgjhNFGDshJfmTbUAkVOwIlbH+sz0N8= X-Received: by 10.36.179.79 with SMTP id z15mr6751027iti.26.1504984477612; Sat, 09 Sep 2017 12:14:37 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Sat, 9 Sep 2017 12:14:36 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d5ae:f1f3:42c8:b0f7] In-Reply-To: References: From: Warner Losh Date: Sat, 9 Sep 2017 13:14:36 -0600 X-Google-Sender-Auth: KJHYwfDDv7VqBMFbUwbmtcC92VA Message-ID: Subject: Re: FCP-100: armv7 plan To: Jan Beich Cc: "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 19:14:38 -0000 On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > Warner Losh writes: > > > Greetings, > > > > This will serve as 'Last Call' for any objections to the plan to create > an > > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > [...] > > Some ports want NEON support but FCP-0100 is vague about FreeBSD-specific > differences between armv6 and armv7. Clang appears to enable NEON for all > *-gnueabi* targets but I have no clue about GCC. Apparently, Android and > Debian don't assume NEON on armv7. > > related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 > Yes. We are vague about it on purpose. Just like we're vague about MMX, MMX2, etc on x86 because different processors can/want use different things. The goal, if it doesn't work already, is for NEON to work if used, but not be required, just like all the other optional features of a CPU. Warner From owner-freebsd-arm@freebsd.org Sat Sep 9 19:25:06 2017 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 BDF16E0412F; Sat, 9 Sep 2017 19:25:06 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DD3874E11; Sat, 9 Sep 2017 19:25:06 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id DCDDB90BE; Sat, 9 Sep 2017 19:25:05 +0000 (UTC) From: Jan Beich To: Warner Losh Cc: Jan Beich , "freebsd-arm\@freebsd.org" , "freebsd-toolchain\@FreeBSD.org" Subject: Re: FCP-100: armv7 plan References: Date: Sat, 09 Sep 2017 21:25:01 +0200 In-Reply-To: (Warner Losh's message of "Sat, 9 Sep 2017 13:14:36 -0600") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 19:25:06 -0000 Warner Losh writes: > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > >> Warner Losh writes: >> >> > Greetings, >> > >> > This will serve as 'Last Call' for any objections to the plan to create >> an >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. >> [...] >> >> Some ports want NEON support but FCP-0100 is vague about FreeBSD-specific >> differences between armv6 and armv7. Clang appears to enable NEON for all >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android and >> Debian don't assume NEON on armv7. >> >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 >> > > Yes. We are vague about it on purpose. Just like we're vague about MMX, > MMX2, etc on x86 because different processors can/want use different > things. Do you mean similar to how FreeBSD i386 is vague about not supporting real i386, only i486 or later? > The goal, if it doesn't work already, is for NEON to work if used, > but not be required, just like all the other optional features of a CPU. FreeBSD doesn't support detecting NEON at runtime unlike Linux. Do you mean at compile time? If so then the following probably needs to change $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - 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 4A950E04D55 for ; Sat, 9 Sep 2017 19:37:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 0B07475657 for ; Sat, 9 Sep 2017 19:37:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id b142so11368860ioe.1 for ; Sat, 09 Sep 2017 12:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hNgamjOla/fUYYmfjkSsuJufKvKKpBKx38Yz73F+9QM=; b=n8+vNeQNjo6eqqsDr03vDmUX3hTi1DCu64MRoalSJtskVP0OC1/u49ikZnKnABEh3m hnzQS6CG1jQvkVZq/MoLsW6QQfKYu9sUzjEkvn787/myC3Ogb/zp0Bxv9Dni6j2uT09r A3+GAI4ji+cdSKLS4GxCyofhuGiORWnoB4v8vhJUiOMNbvCjovd3RmJ41kWIA9wQpbiz eUIE78xKM7R5t+QeCAQv9GS9r37LbG1o2PlnaouB9FX47K9AWMW/KRcKDHL88VPsnjva jNfBEMzEzkPJk25ftQXcRQFws9rbBr4OkPKUsGTgzd8ME6KLFJ8iLxrMQcF1lD6bELDZ JaoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hNgamjOla/fUYYmfjkSsuJufKvKKpBKx38Yz73F+9QM=; b=V1gdA5gD4w/U7qLufU/jQjvFT0wkaicoFqA7qDQ9DkoNJE2qmVzEItjsi/RlmCGHLZ k/1aWhvhgBRb8XfPPc6ZXVeHPrz359m8AWMkb8KuHzCFmGOiAhcXDAq6K7ZWXj3DNi/T J0RcSjBwuQ9uCIumtZV9FcIymRl/WuIx8ZkYl9BIrk8calei/C8wycihU+W6UCRn61oT eT6dKy6rX8x6cfU9OgZu+f4UCv7ION2fgykdg/Zx/lJFT0/25nVDeGVhJhT5YI4ASFMZ 5QRwaafMRCubHGrKR1dlZCoAdZDAoL+wkbsPRUHS/uAQMxBgNbcMyHJPlgwvnS532j5J K7Uw== X-Gm-Message-State: AHPjjUjkqUFF5DSYStOW+dreFQzx1aIwTsQ49W9nNoM7dAgoE5Pl2cLb cb+cH2cywAIdhtK7j87YoQ4yEWTQpyK9 X-Google-Smtp-Source: ADKCNb4AJesL/DbFzhMF7oAJUl8UoISnGkWzT3UV/cNiZ+IGD4YgmZoRc0dOIrd7zqx3+Lpf4spgH0pm6dvSdBs3mvE= X-Received: by 10.107.133.92 with SMTP id h89mr2169841iod.208.1504985862229; Sat, 09 Sep 2017 12:37:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Sat, 9 Sep 2017 12:37:41 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d5ae:f1f3:42c8:b0f7] In-Reply-To: References: From: Warner Losh Date: Sat, 9 Sep 2017 13:37:41 -0600 X-Google-Sender-Auth: S-uaDnKzj6IxnJFRcCFJxdspke0 Message-ID: Subject: Re: FCP-100: armv7 plan To: Jan Beich Cc: Jan Beich , "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 19:37:43 -0000 On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich wrote: > Warner Losh writes: > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > > > >> Warner Losh writes: > >> > >> > Greetings, > >> > > >> > This will serve as 'Last Call' for any objections to the plan to > create > >> an > >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > >> [...] > >> > >> Some ports want NEON support but FCP-0100 is vague about > FreeBSD-specific > >> differences between armv6 and armv7. Clang appears to enable NEON for > all > >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android and > >> Debian don't assume NEON on armv7. > >> > >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 > >> > > > > Yes. We are vague about it on purpose. Just like we're vague about MMX, > > MMX2, etc on x86 because different processors can/want use different > > things. > > Do you mean similar to how FreeBSD i386 is vague about not supporting > real i386, only i486 or later? I mean we don't enumerate the list of all the processor supported things. We default to compiling for a fairly middle of the road processor, but you can strip that back all the way to i486, or hyper optimize for the latest core-2 duo. However, armv6 vs armv7 can affect the ABI in subtle ways that's it's best to avoid by declaring the two different. One may be able to run armv6 binaries on an armv7 CPUs still, but we're not specifically guaranteeing it. > The goal, if it doesn't work already, is for NEON to work if used, > > but not be required, just like all the other optional features of a CPU. > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. No, I don't mean that at all. I mean we don't care if it is enabled or not. It doesn't affect the ABI. The kernel knows about the extensions and saves the context when it's in use, just like the x86 kernel saves MMX, etc context when it's in use. Do you > mean at compile time? If so then the following probably needs to change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - fgrep -i neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > Right. that's based on the default target. gcc/clang can enable or disable it (and a dozen other things) depending on what options you give. We don't care. We'll run all binaries. It's up to the system integrator to mix/match the options so they get optimal performance for their platform. Just like on x86. If you compile for MMX and run it on 486 w/o run-time detection, you'll get a reserved instruction fault. Same philosophy here. We don't dictate policy for the binaries, just like on x86. However, most of them have run-time detection to be nicer to the users than a core dump, and most do the best thing for that CPU if they really care about performance, but those applications that don't can just do whatever and be fine. Warner From owner-freebsd-arm@freebsd.org Sat Sep 9 20:10:54 2017 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 300ADE072F4; Sat, 9 Sep 2017 20:10:54 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 F051877688; Sat, 9 Sep 2017 20:10:53 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pf0-x241.google.com with SMTP id f84so3102678pfj.3; Sat, 09 Sep 2017 13:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=rrb3oyTOx+EhSQqV0092UgjHyYHAWg7/IOAGpJ35YJA=; b=kJuFb0/alBgBIH0x7a3n2iN6zUA94e1mNOUIpyUEp4DGZBE8OuLRMlauWFZQkbvQTl +2aHeuTFoc1Q+AcFzHeIsYN4RlR9WTlpJnmwHqym385efv+rN6NnjenDEMLVafOfT5yd 0Ulp7pK9gVTd6Xf9mBEBupvhHZHO5dvtJqxPlyCcXv4tQMI7mvcKRofGPnsz6bY86nUH cKWMaDQwzs1Twt8Cq12RTf5Tj2y2l0HDmNz9k5ep+V++K9i/MwdAWxmaPRJRGaAx54OH fuMi+7s7aYO98o4SJ3ztjHT56tzS4JXWscnb7NF3EWEkXm5geCXexGTxPM/nhy1nPqLK VZ+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=rrb3oyTOx+EhSQqV0092UgjHyYHAWg7/IOAGpJ35YJA=; b=MYY3koLeAKSgfdMl8Gh84SWeiRyi/0QLhDBhMtJBafnuHG22URplpzbKRCcq24HBfa v2gJ9GsxRE47Njx1nyHqvDRVUEIsI2nRkO88rgz+JXs8cQ0UjaNwZvsTgyqWrTZtyB5d mdnDIAzasXc22qqtgA/41IragqSePkI6NqlqAlxKcygJmumHLBDoDGY/Ee8uYPMBLjtY jFDtXT/CpdsX9KLjE+OgkFMV/neVY9NB3o3dnNpITIU2HDtB2KIJssa1W8/34mcwhSGA l0jliauJFz91qYUYl2soEuy4o7fTYkJGrDkMH7wXwZx3OK+OzJgX/l7KV6QBI/UnHAuG BcPg== X-Gm-Message-State: AHPjjUi+FTdduOqQRnnlImGMHf2afqT/lETQw23kctiCcJGn0bkdxnmP Qa9LDw4OlWqI9gPgqoIeBA== X-Google-Smtp-Source: ADKCNb5HiTdrMqzmCwvKIX62fsVmjxwPg3+cgp82MJlO+Mcuq3VYr1K7ZB3qdAvWRExQZ+GoUUXzDg== X-Received: by 10.84.210.45 with SMTP id z42mr7951078plh.132.1504987853521; Sat, 09 Sep 2017 13:10:53 -0700 (PDT) Received: from [127.0.0.1] ([204.174.94.196]) by smtp.gmail.com with ESMTPSA id q12sm8096058pgs.47.2017.09.09.13.10.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Sep 2017 13:10:52 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170909201051.6545490.68027.31617@gmail.com> Date: Sat, 09 Sep 2017 13:10:51 -0700 Subject: Re: FCP-100: armv7 plan From: Russell Haley In-Reply-To: References: To: Warner Losh , Jan Beich Cc: freebsd-arm@freebsd.org, "freebsd-toolchain@FreeBSD.org" , Jan Beich X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 20:10:54 -0000 Warner,=A0 So you are saying NEON support is a compile time option that has no relevan= ce to the Application Binary Interface, which is what the FCP-0100 was abou= t? Thanks for clarification, Russ Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the=A0Virgin=A0Mobil= e=A0network. =A0 Original Message =A0 From: Warner Losh Sent: Saturday, September 9, 2017 12:37 PM To: Jan Beich Cc: freebsd-arm@freebsd.org; freebsd-toolchain@FreeBSD.org; Jan Beich Subject: Re: FCP-100: armv7 plan On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich wrote: > Warner Losh writes: > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > > > >> Warner Losh writes: > >> > >> > Greetings, > >> > > >> > This will serve as 'Last Call' for any objections to the plan to > create > >> an > >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > >> [...] > >> > >> Some ports want NEON support but FCP-0100 is vague about > FreeBSD-specific > >> differences between armv6 and armv7. Clang appears to enable NEON for > all > >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android a= nd > >> Debian don't assume NEON on armv7. > >> > >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221898 > >> > > > > Yes. We are vague about it on purpose. Just like we're vague about MMX, > > MMX2, etc on x86 because different processors can/want use different > > things. > > Do you mean similar to how FreeBSD i386 is vague about not supporting > real i386, only i486 or later? I mean we don't enumerate the list of all the processor supported things. We default to compiling for a fairly middle of the road processor, but you can strip that back all the way to i486, or hyper optimize for the latest core-2 duo. However, armv6 vs armv7 can affect the ABI in subtle ways that's it's best to avoid by declaring the two different. One may be able to run armv6 binaries on an armv7 CPUs still, but we're not specifically guaranteeing it. > The goal, if it doesn't work already, is for NEON to work if used, > > but not be required, just like all the other optional features of a CPU. > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. No, I don't mean that at all. I mean we don't care if it is enabled or not. It doesn't affect the ABI. The kernel knows about the extensions and saves the context when it's in use, just like the x86 kernel saves MMX, etc context when it's in use. Do you > mean at compile time? If so then the following probably needs to change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - fgrep -i neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > Right. that's based on the default target. gcc/clang can enable or disable it (and a dozen other things) depending on what options you give. We don't care. We'll run all binaries. It's up to the system integrator to mix/match the options so they get optimal performance for their platform. Just like on x86. If you compile for MMX and run it on 486 w/o run-time detection, you'll get a reserved instruction fault. Same philosophy here. We don't dictate policy for the binaries, just like on x86. However, most of them have run-time detection to be nicer to the users than a core dump, and most do the best thing for that CPU if they really care about performance, but those applications that don't can just do whatever and be fine. Warner _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Sep 9 20:34:13 2017 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 B03F8E0890D for ; Sat, 9 Sep 2017 20:34:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 91DF87C997 for ; Sat, 9 Sep 2017 20:34:13 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 44f804e6-959e-11e7-950d-03a3531dacf2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 44f804e6-959e-11e7-950d-03a3531dacf2; Sat, 09 Sep 2017 20:34:25 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v89KYArr004518; Sat, 9 Sep 2017 14:34:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1504989250.32063.66.camel@freebsd.org> Subject: Re: FCP-100: armv7 plan From: Ian Lepore To: Jan Beich , Warner Losh Cc: "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" , Jan Beich Date: Sat, 09 Sep 2017 14:34:10 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 20:34:13 -0000 On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > Warner Losh writes: > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich > > wrote: > > > > > > > > Warner Losh writes: > > > > > > > > > > > Greetings, > > > > > > > > This will serve as 'Last Call' for any objections to the plan > > > > to create > > > an > > > > > > > > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > > > [...] > > > > > > Some ports want NEON support but FCP-0100 is vague about FreeBSD- > > > specific > > > differences between armv6 and armv7. Clang appears to enable NEON > > > for all > > > *-gnueabi* targets but I have no clue about GCC. Apparently, > > > Android and > > > Debian don't assume NEON on armv7. > > > > > > related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 > > > > > Yes. We are vague about it on purpose. Just like we're vague about > > MMX, > > MMX2, etc on x86 because different processors can/want use > > different > > things. > Do you mean similar to how FreeBSD i386 is vague about not supporting > real i386, only i486 or later? > > > > > The goal, if it doesn't work already, is for NEON to work if used, > > but not be required, just like all the other optional features of a > > CPU. > FreeBSD doesn't support detecting NEON at runtime unlike Linux. We should fix that.  In fact, we should probably fix it in exactly the way linux does it (does it today, I think it's their 3rd scheme so far), using getauxval() and elf AT_HWCAP. Adding the AT_HWCAP stuff would be relatively easy.  I'm not as sure what to do about getauxval().  To be maximally linux-compatible (which would be good for ports) we'd put getauxval() in libc and make it work just like the linux one.  That's a bit at odds with the support we have now, which is procstat_getauxv() in libprocstat.  It's not very compatible with how linux getauxval() works, so using just that might lead to a lot of patches in ports. -- Ian > Do you > mean at compile time? If so then the following probably needs to > change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - |& fgrep -i neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > _______________________________________________ From owner-freebsd-arm@freebsd.org Sat Sep 9 21:30:32 2017 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 B44C1E0B414 for ; Sat, 9 Sep 2017 21:30:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 76DA87E350 for ; Sat, 9 Sep 2017 21:30:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id v19so7520652ite.0 for ; Sat, 09 Sep 2017 14:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bYn8uCIw8A2pSEpIETK8KvSe+49m3Zmlu+EGfxWv2FM=; b=IxFjiS6p5F3vZ4EbdqyDGEotPR11/aZWx7ZQbLR7Rur/UzqxzmpaeMUQ55BUoDbVwZ 35CzbP9JRvOnQT98r+8eiWAgApVPeHA6cHcxz24u1eqSDrXNsqkfJuijM0tqKPCr26wG gn6bg4RclEFpC527l5xXi/DzxBYQ+ymQlkMktJPJBsN3XpdwgxHOWQVktuOvTATmznnz XIdt8jMkYEwIFqyP8DVRjJir6MRfU4ToM9HEsEUHJ4l8qZCzGtPek+Gy+cONpSLU2rgC OU7swR2lHm1btXroEYIuZT5nTxhjscc9hEgfgcINuFdn0VwurJdEXHKMWB9XBWYpcDqb q6ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bYn8uCIw8A2pSEpIETK8KvSe+49m3Zmlu+EGfxWv2FM=; b=lxkGzvNa0AIvxqtyTSPnEMp7fqVt7AGg1yyN7arXFoj9PNdlhNSgU84l5iM58EJnLD Q8CcO1+Pmx/l5beL90pxEVC9WN530Db5avB/9mFqfAMG9oJuKvKlJhKt4oqVIKGs3MfK 3TL0Zcv+HUdvpBBWPDd4KvcMiQ/P50Rq+62+2o7gnRHlcvKjv+iH5w+ng2wKKdeO5RYP It9MA1P+0ptiBwJZ2cfsk7OKA7HA0sj9J9teyG8G/o4C38exzyl1xRNEdTknAExXtDUB j7jUJORQKbHKqIkpuDX6bSUFFjC/iDzBikpQzpgXpoKNf/NG6cJuTW/rsfONdPtC9xvj hK5Q== X-Gm-Message-State: AHPjjUi8c85u3CbIm3h/8sOkrt5daBbp6mKnd3TyDDM/k59FIGzmieJ9 afrPIX/sDK3+4N16CVraJyj5RVOXAbEW X-Google-Smtp-Source: AOwi7QBjyc8n06qjygRXant/iIXDSqkDtnQgQH8/h08nN23D+0XY0l709Rcv374YEBeiKG5LizIQztwmt3okYiA7GFs= X-Received: by 10.36.34.75 with SMTP id o72mr6383586ito.15.1504992630854; Sat, 09 Sep 2017 14:30:30 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Sat, 9 Sep 2017 14:30:30 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d5ae:f1f3:42c8:b0f7] In-Reply-To: <1504989250.32063.66.camel@freebsd.org> References: <1504989250.32063.66.camel@freebsd.org> From: Warner Losh Date: Sat, 9 Sep 2017 15:30:30 -0600 X-Google-Sender-Auth: Mj0y30Ff8y1Ck3Y7q6B2OR-FhWI Message-ID: Subject: Re: FCP-100: armv7 plan To: Ian Lepore Cc: Jan Beich , "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" , Jan Beich Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 21:30:32 -0000 On Sat, Sep 9, 2017 at 2:34 PM, Ian Lepore wrote: > On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > > Warner Losh writes: > > > > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich > > > wrote: > > > > > > > > > > > Warner Losh writes: > > > > > > > > > > > > > > Greetings, > > > > > > > > > > This will serve as 'Last Call' for any objections to the plan > > > > > to create > > > > an > > > > > > > > > > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > > > > [...] > > > > > > > > Some ports want NEON support but FCP-0100 is vague about FreeBSD- > > > > specific > > > > differences between armv6 and armv7. Clang appears to enable NEON > > > > for all > > > > *-gnueabi* targets but I have no clue about GCC. Apparently, > > > > Android and > > > > Debian don't assume NEON on armv7. > > > > > > > > related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 > > > > > > > Yes. We are vague about it on purpose. Just like we're vague about > > > MMX, > > > MMX2, etc on x86 because different processors can/want use > > > different > > > things. > > Do you mean similar to how FreeBSD i386 is vague about not supporting > > real i386, only i486 or later? > > > > > > > > The goal, if it doesn't work already, is for NEON to work if used, > > > but not be required, just like all the other optional features of a > > > CPU. > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. > > We should fix that. In fact, we should probably fix it in exactly the > way linux does it (does it today, I think it's their 3rd scheme so > far), using getauxval() and elf AT_HWCAP. > Ah, yes. We should do that. We need that for other reasons as well. It shouldn't be too hard, though I don't know where we get the AT_HWCAP from to start with. > Adding the AT_HWCAP stuff would be relatively easy. I'm not as sure > what to do about getauxval(). To be maximally linux-compatible (which > would be good for ports) we'd put getauxval() in libc and make it work > just like the linux one. That's a bit at odds with the support we have > now, which is procstat_getauxv() in libprocstat. It's not very > compatible with how linux getauxval() works, so using just that might > lead to a lot of patches in ports. Totally agreed, even if it means breaking compatibility with the past. And as important as these issues are, they are orthogonal to armv7 :) Warner -- Ian > > > Do you > > mean at compile time? If so then the following probably needs to > > change > > > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - > |& fgrep -i neon > > #define __ARM_NEON 1 > > #define __ARM_NEON_FP 0x4 > > #define __ARM_NEON__ 1 > > _______________________________________________ > > From owner-freebsd-arm@freebsd.org Sat Sep 9 21:46:12 2017 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 CDAB3E0C457; Sat, 9 Sep 2017 21:46:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 60C027EC7D; Sat, 9 Sep 2017 21:46:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v89Lk6YT093622 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Sep 2017 00:46:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v89Lk6YT093622 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v89Lk6Dp093621; Sun, 10 Sep 2017 00:46:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Sep 2017 00:46:06 +0300 From: Konstantin Belousov To: Ian Lepore Cc: Jan Beich , Warner Losh , "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" , Jan Beich Subject: Re: FCP-100: armv7 plan Message-ID: <20170909214606.GW1700@kib.kiev.ua> References: <1504989250.32063.66.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1504989250.32063.66.camel@freebsd.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 21:46:12 -0000 On Sat, Sep 09, 2017 at 02:34:10PM -0600, Ian Lepore wrote: > Adding the AT_HWCAP stuff would be relatively easy. šI'm not as sure > what to do about getauxval(). šTo be maximally linux-compatible (which > would be good for ports) we'd put getauxval() in libc and make it work > just like the linux one. šThat's a bit at odds with the support we have > now, which isšprocstat_getauxv() in libprocstat. šIt's not very > compatible with how linux getauxval() works, so using just that might > lead to a lot of patches in ports. libprocstat is for accessing other processes information and address space. Our libc already has _elf_aux_info, but it is not exported. If you have a clear description of the desired API, I can add it (I do not want to read glibc code). From owner-freebsd-arm@freebsd.org Sat Sep 9 22:08:07 2017 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 5F7EFE0D89B; Sat, 9 Sep 2017 22:08:07 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 2B41A7FA3F; Sat, 9 Sep 2017 22:08:07 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pg0-x241.google.com with SMTP id d8so2898845pgt.3; Sat, 09 Sep 2017 15:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=EKV8fCc5VyDKWhoWJb6JDGSZORvNKr3idKWPzt7bF4Y=; b=K1OfHGbvLOu5GOz64Dp8UUKMtC+76FP3iVXumZMW9HGFIX21FEnyXiyIRfXa6DRN3I tS5JA1KwC++69W51nl80BaBJxjV0uAHbbIg7fgFmMrq4u+nRTpXVW13TVxvAJnX4tjXM 0LzmyUzSTG731L2D0L2gmsMtQXaz/yr46uacFeyy0MLf+nEZfTBBi0NdJoYgTsD1ZEGk m/fmrASfRk0CZWrokvYb/zuTjwiaA2GYfg1K9GKnfIzOslcuV904dGQaeXe/v+MjUrgp 2tin/1hYOzZv6vuEzhIbqnmuCyPad6t/su2MQcfI6p4j7ObenXlo68E5E7NZlV54bpzI IXSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=EKV8fCc5VyDKWhoWJb6JDGSZORvNKr3idKWPzt7bF4Y=; b=kF3eNbz/x3q/9dqdO9Aw2N5fnZbnBIc9MzruYAumpVBVFrvo318lRUlX+kfQ0Kj3uD QxUlWfAa8iktVmXQinIooGXcTmuEJE3JmyWup+uAvEe9ju3UbEQIB361g+pMlmvHZouo HBHWsXz11MCVZmK0PZ0leViZqESj+77J4UypKc1YpeXyeUKDJeIc0nNodvg6pqbABLYm m8d8Z5E8F3fLtUqvJwB8NBn/AmyTSFvdlv75mOTM76RSiQJWqXissE1MZl35Twen1/JT oQERZ8p7NYLwaf0YPlZApHc/EFpy41Lc29/ozASZ88COAi/94f1RroK96aFUD7Ovj4Aq gMPw== X-Gm-Message-State: AHPjjUgq7j07kIA25DtEfWvfnlo9iGeCibhgX5EpqSnRcKWzgx0rEzE1 ZRPzhU8aZljybA== X-Google-Smtp-Source: ADKCNb7CxJ+/kxHi8uZcIODordHDZpVdwQ9Zg0zaazdHl39iq3Rv77DmyliuVwb+fFdSzoRvZRTBUg== X-Received: by 10.99.37.66 with SMTP id l63mr7390467pgl.348.1504994886468; Sat, 09 Sep 2017 15:08:06 -0700 (PDT) Received: from [127.0.0.1] ([204.174.94.196]) by smtp.gmail.com with ESMTPSA id r11sm9944328pfg.180.2017.09.09.15.08.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Sep 2017 15:08:04 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170909220804.6545490.97876.31623@gmail.com> Date: Sat, 09 Sep 2017 15:08:04 -0700 Subject: Getauxval - was Re: FCP-100: armv7 plan From: Russell Haley In-Reply-To: <20170909214606.GW1700@kib.kiev.ua> References: <1504989250.32063.66.camel@freebsd.org> <20170909214606.GW1700@kib.kiev.ua> To: Konstantin Belousov , Ian Lepore Cc: freebsd-arm@freebsd.org, "freebsd-toolchain@FreeBSD.org" , Jan Beich , Jan Beich X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 22:08:07 -0000 Apologies for the top post.=C2=A0 Man pages indicate =E2=80=8Egetauxval is a non standard glibc function. Is = this an issue? Is there a more posix way I could compare against? I was pre= viously wondering to myself if the Linux api is now more standard than the = posix api? Looking forward to all opinions and comments.=C2=A0 Rus Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the=C2=A0Virgin=C2=A0Mobile=C2=A0network. =C2=A0 Original Message =C2=A0 From: Konstantin Belousov Sent: Saturday, September 9, 2017 2:46 PM To: Ian Lepore Cc: freebsd-arm@freebsd.org; freebsd-toolchain@FreeBSD.org; Jan Beich; Jan = Beich Subject: Re: FCP-100: armv7 plan On Sat, Sep 09, 2017 at 02:34:10PM -0600, Ian Lepore wrote: > Adding the AT_HWCAP stuff would be relatively easy. =C2=A0I'm not as sure > what to do about getauxval(). =C2=A0To be maximally linux-compatible (whi= ch > would be good for ports) we'd put getauxval() in libc and make it work > just like the linux one. =C2=A0That's a bit at odds with the support we h= ave > now, which is=C2=A0procstat_getauxv() in libprocstat. =C2=A0It's not very > compatible with how linux getauxval() works, so using just that might > lead to a lot of patches in ports. libprocstat is for accessing other processes information and address space. Our libc already has _elf_aux_info, but it is not exported. If you have a clear description of the desired API, I can add it (I do not want to read glibc code). _______________________________________________ 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 Sat Sep 9 22:36:59 2017 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 D2281E0EEE0; Sat, 9 Sep 2017 22:36:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACF4780708; Sat, 9 Sep 2017 22:36:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (unknown [50.235.236.73]) by mail.baldwin.cx (Postfix) with ESMTPSA id BEA7610A7B9; Sat, 9 Sep 2017 18:36:51 -0400 (EDT) Subject: Re: FCP-100: armv7 plan To: Jan Beich , Warner Losh References: Cc: "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" , Jan Beich From: John Baldwin Message-ID: Date: Sat, 9 Sep 2017 18:36:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Sat, 09 Sep 2017 18:36:51 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 22:36:59 -0000 On 9/9/17 3:25 PM, Jan Beich wrote: > Warner Losh writes: > >> On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: >> >>> Warner Losh writes: >> The goal, if it doesn't work already, is for NEON to work if used, >> but not be required, just like all the other optional features of a CPU. > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. Do you > mean at compile time? If so then the following probably needs to change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 Re: runtime, I have patches in review to add AT_HWCAP for native FreeBSD/arm binaries. Right now it doesn't support a NEON hwcap but it should be easy to add the flag using the same check to enable it that Linux does. -- John Baldwin From owner-freebsd-arm@freebsd.org Sat Sep 9 23:35:15 2017 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 89214E11B63 for ; Sat, 9 Sep 2017 23:35:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 35C7981FE9 for ; Sat, 9 Sep 2017 23:35:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12085 invoked from network); 9 Sep 2017 23:35:13 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Sep 2017 23:35:13 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sat, 09 Sep 2017 19:35:13 -0400 (EDT) Received: (qmail 23670 invoked from network); 9 Sep 2017 23:35:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2017 23:35:12 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 3AA97EC94E5; Sat, 9 Sep 2017 16:35:12 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Missing in action during arm64/aarch64 builds: no pine64_plus.dtb to be found from buildkernel, installkernel, or u-boot-pine64 Message-Id: Date: Sat, 9 Sep 2017 16:35:11 -0700 To: FreeBSD Toolchain , freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 23:35:15 -0000 The context here is head -r323246 amd64 -> arm64/aarch64 cross build activity. =46rom installkernel : # find /usr/obj/DESTDIRs/clang-cortexA53-installkernel/ -name "*.dtb" = -print #=20 =46rom buildkernel : # find /usr/obj/cortexA53_clang/arm64.aarch64/ -name "*.dtb" -print #=20 =46rom installing u-boot-pine64 : # ls -lTd /usr/local/share/u-boot/u-boot-pine64/* -rw-r--r-- 1 root wheel 125 Sep 6 00:49:44 2017 = /usr/local/share/u-boot/u-boot-pine64/README -rw-r--r-- 1 root wheel 505940 Sep 6 00:49:43 2017 = /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin As stands the file must be manually produced. crochet goes to the trouble to have logic to build and install pine64_plus.dtb (based on arm64/pine64_plus.dts ). Is pine64_plus.dtb required for the likes of Pine64+ 2GB's? If yes: should it be automatically built and installed someplace for arm64/aarch64 builds (even if more manual steps are required to have the final placement on the Pine64 media)? =3D=3D=3D Mark Millard markmi at dsl-only.net