From owner-freebsd-arm@freebsd.org Sun Jun 11 14:23:36 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 230A2D881EE for ; Sun, 11 Jun 2017 14:23:36 +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 119C16729E for ; Sun, 11 Jun 2017 14:23:36 +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 v5BENZZj014052 for ; Sun, 11 Jun 2017 14:23:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 219927] awg0 stops working after a long output under ssh Date: Sun, 11 Jun 2017 14:23:36 +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: hlh@restart.be 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: Sun, 11 Jun 2017 14:23:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219927 Bug ID: 219927 Summary: awg0 stops working after a long output under ssh Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: hlh@restart.be Environment: pine64+ 2GB FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318945M: = Sat Jun 10 11:47:44 CEST 2017=20=20=20=20 root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 If I connect from a wireless computer (FreeBSD 11.1-PRERELEASE #0 r318860) = and run a command with a big output (eg `find /`) the awg0 stops working quickly (under 20 seconds of output). If I do the same with telnet from the same computer, the output is much lon= ger but awg0 stops working. If I do the same from a wired computer then I must run `find /` 2 or 3 times before awg0 stops working. I can rsync through ssh 12GB without problem in both directions (from and to the pine64 and the wireless computer). I have a `tcpdump -w ssh.data port 22`. (8.3 MB) I can connect with a serial console to the pine64 after awg0 stop working. ifconfig awg0 down ifconfig awg0 up don't restore the connectivity. I must reboot to restore connectvity. Henri --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Jun 11 15:54:21 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 B5266D89A46 for ; Sun, 11 Jun 2017 15:54:21 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AA8F6E025 for ; Sun, 11 Jun 2017 15:54:21 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-yw0-x22a.google.com with SMTP id 63so30550713ywr.0 for ; Sun, 11 Jun 2017 08:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5ZYdS7wiaRXiRFHiaKzJPVFW10fmC9xlBnsif4kwsho=; b=Ekaeokx7YXuXuO0gmmU6tA1qMNFGjKZgWm8R7KYg4n+tWxDpz10OO7vXfGdAJOVOul C3VfWPKsDF3oRLMsYR4HpuFi58PLLlXlBs2I12Zz0MR/JzNf72BaDZtM0iZVHXokeTdE W5mHU/HV0L3VX/clvIxyODQhui81uWy6q8YWT4sCuJRz5NpzciT5CFbHkUmtmBjA19rm Kv1CdGVv+kin2uaDPVm2xopSa/Q3dEy4yvdm1U7c6CHUNXwna2bd5BCbgK1Ic0tDSRic 9eEgHaJFm7kfE2cZVbZFeq/cx+bKttq9qsj3LThC/GTW5GYlQkP0KlYnMpel4uG6fkvE U+GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5ZYdS7wiaRXiRFHiaKzJPVFW10fmC9xlBnsif4kwsho=; b=rCiXfiekDLqM4MbqckGuHYBokEzlKmfy47mYBCZxCFf55NzgbfAEAuh06UhzDbJP5u Sdxp47OANY75S4vFLV8aaN4gkRFUvaLx6D3TppgdKSOMVNyTY5poebxV55ZqE4wRLRol BmoPG7wVeYYKUdJAvPWt8B43u+Rg0wkgPeASYwL+1md3T5PXDNUwDGrfrO1gcTT9c/Fh kuDNBCMizvkIWrDM0id7bkFy0Bs8Ow5iFuDLiabnXu/z4HARuHRaDnu6HSiuCUz891A8 hVb3mxAkY5Vzi6mo521ZQcuaxrNarsHL+77EegB0gjjkRmrEzCWUT6ED1tzI6eysuyTI D0dA== X-Gm-Message-State: AODbwcB+21EejeTWAhOy96Q7bl20nyf2tuk5fIdC4YJk1eSyvO6G1rDl rd9hYE3wuvC67FMPKABSXP/yKpoMWkIf X-Received: by 10.13.212.69 with SMTP id w66mr20852367ywd.164.1497196460339; Sun, 11 Jun 2017 08:54:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Vijlbrief Date: Sun, 11 Jun 2017 15:54:09 +0000 Message-ID: Subject: Re: [Bug 219927] awg0 stops working after a long output under ssh To: freebsd-arm@freebsd.org, hlh@restart.be 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: Sun, 11 Jun 2017 15:54:21 -0000 Op zo 11 jun. 2017 om 16:23 schreef : > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219927 > > Bug ID: 219927 > Summary: awg0 stops working after a long output under ssh > Product: Base System > Version: CURRENT > Hardware: arm64 > OS: Any > Status: New > Severity: Affects Only Me > Priority: --- > Component: arm > Assignee: freebsd-arm@FreeBSD.org > Reporter: hlh@restart.be > > Environment: pine64+ 2GB > FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318945M: > Sat > Jun 10 11:47:44 CEST 2017 > root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 > > If I connect from a wireless computer (FreeBSD 11.1-PRERELEASE #0 r318860) > and > run a command with a big output (eg `find /`) the awg0 stops working > quickly > (under 20 seconds of output). > > If I do the same with telnet from the same computer, the output is much > longer > but awg0 stops working. > > If I do the same from a wired computer then I must run `find /` 2 or 3 > times > before awg0 stops working. > > I can rsync through ssh 12GB without problem in both directions (from and > to > the pine64 and the wireless computer). > > I have a `tcpdump -w ssh.data port 22`. (8.3 MB) > > I can connect with a serial console to the pine64 after awg0 stop working. > ifconfig awg0 down > ifconfig awg0 up > don't restore the connectivity. I must reboot to restore connectvity. > That's a coincidence, today I'm investigating the same issue. You could try increasing TX_MAX_SEGS in sys/arm/allwinner/if_awg.c line 95. I'm currently testing TX_MAX_SEGS set to 40 and no lock up yet.... From owner-freebsd-arm@freebsd.org Sun Jun 11 16:01:52 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 A60F0D89BB7 for ; Sun, 11 Jun 2017 16:01:52 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EF156E229 for ; Sun, 11 Jun 2017 16:01:52 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=tvijlbrief@gmail.com DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3wm1452cMpzsNF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1497196901; bh=NLEeV2IJ/k64hK7HMNGZs1Zq4eeJiKUv91GAmCcN+p8=; h=Subject:To:References:From:Date:In-Reply-To; z=Subject:=20Re:=20[Bug=20219927]=20awg0=20stops=20working=20after= 20a=20long=20output=20under=20ssh|To:=20Tom=20Vijlbrief=20,=20freebsd-arm@freebsd.org|References:=20=0D=0A=20|From:=20Henri=20H ennebert=20|Date:=20Sun,=2011=20Jun=202017=2018:01 :39=20+0200|In-Reply-To:=20; b=JQkAMJECA8IydYKLkcGbK75KVMqrFmix/yfOvq9C0EpFdNivbCylmpnbl4W7PQbe6 E5IvqVwGarS3WR6Y8CoMtTZkOePAaeaOmW1bZX21lExAVdefGsQOKsfceh7vmBLqVq JbWiS8b0/XGCcUn7MtalusdhVhlpGgWkoRT8HxShDy7VsZAdRpjG9u+/4iRdrJuJ17 IOrsnkVuKQWERgZwyqOP0JbE9hKXyB9/UfEEHYTpUkmcAk/8Rj+xVTA5GfcXl9TdoY dWmUDMivHvkT6SCas0F9prTMQCwDyykYrY1jUQakYMIuUSAV4L5dDjkdojkbwMBjwM YwXC+6eN88Qng== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3wm1452cMpzsNF; Sun, 11 Jun 2017 18:01:40 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v5BG1dr4020962 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 11 Jun 2017 18:01:40 +0200 (CEST) (envelope-from hlh@restart.be) Subject: Re: [Bug 219927] awg0 stops working after a long output under ssh To: Tom Vijlbrief , freebsd-arm@freebsd.org References: From: Henri Hennebert Message-ID: Date: Sun, 11 Jun 2017 18:01:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic 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: Sun, 11 Jun 2017 16:01:52 -0000 On 06/11/2017 17:54, Tom Vijlbrief wrote: > > Op zo 11 jun. 2017 om 16:23 schreef >: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219927 > > Bug ID: 219927 > Summary: awg0 stops working after a long output under ssh > Product: Base System > Version: CURRENT > Hardware: arm64 > OS: Any > Status: New > Severity: Affects Only Me > Priority: --- > Component: arm > Assignee: freebsd-arm@FreeBSD.org > Reporter: hlh@restart.be > > Environment: pine64+ 2GB > FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 > r318945M: Sat > Jun 10 11:47:44 CEST 2017 > root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 > > If I connect from a wireless computer (FreeBSD 11.1-PRERELEASE #0 > r318860) and > run a command with a big output (eg `find /`) the awg0 stops working > quickly > (under 20 seconds of output). > > If I do the same with telnet from the same computer, the output is > much longer > but awg0 stops working. > > If I do the same from a wired computer then I must run `find /` 2 or > 3 times > before awg0 stops working. > > I can rsync through ssh 12GB without problem in both directions > (from and to > the pine64 and the wireless computer). > > I have a `tcpdump -w ssh.data port 22`. (8.3 MB) > > I can connect with a serial console to the pine64 after awg0 stop > working. > ifconfig awg0 down > ifconfig awg0 up > don't restore the connectivity. I must reboot to restore connectvity. > > > That's a coincidence, today I'm investigating the same issue. > > You could try increasing TX_MAX_SEGS in sys/arm/allwinner/if_awg.c line 95. > > I'm currently testing TX_MAX_SEGS set to 40 and no lock up yet.... Thanks for this hint! I am compiling a new kernel with this change. I'm compiling on the pine64 so it will take some time. Henri From owner-freebsd-arm@freebsd.org Sun Jun 11 19:28: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 0B20ED8D4B5 for ; Sun, 11 Jun 2017 19:28:55 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C7A7574267 for ; Sun, 11 Jun 2017 19:28:54 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1dK8XV-0006AP-MJ for freebsd-arm@freebsd.org; Sun, 11 Jun 2017 21:28:46 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Deorbiting armv4 and armv5 support References: Date: Sun, 11 Jun 2017 21:28:45 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.5 X-Spam-Status: No, score=0.5 required=5.0 tests=ALL_TRUSTED, BAYES_60 autolearn=disabled version=3.4.0 X-Scan-Signature: a8ecdd0179e5342c74548fafd5461917 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: Sun, 11 Jun 2017 19:28:55 -0000 On Thu, 08 Jun 2017 22:22:51 +0200, Warner Losh wrote: > Greetings, > > The pmap in armv4/5 has been broken for years at this point. It basically > works, but has issues with unaligned buffers. Since these have remained > unfixed for a long time, and most of the main ARM developers have given > up > trying to fix it, I think it would be best to retire the support rather > than waste people's time that seem to be working only to discover after a > lot of effort that it's busted. > > Since the consensus at the FreeBSD developer's summit appeared to be > 'let's > let it go'. It would remove the TARGET_ARCH arm and armeb. armv6 would > remain unaffected (though see a parallel thread). > > Warner What branches are you talking about? Regards, Ronald. From owner-freebsd-arm@freebsd.org Mon Jun 12 04:41:45 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 A025ABF3A88 for ; Mon, 12 Jun 2017 04:41:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C24E81A0F for ; Mon, 12 Jun 2017 04:41:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id k93so50663926ioi.2 for ; Sun, 11 Jun 2017 21:41:45 -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=LXEZGjhgSmudnsBZwLcWEPXV7LSvwWu9VPMnoVGY8eg=; b=hc2Ey7Fcf6ThJy8sHggKoogsRf24WtlbJrFWyoixdf3AIHNm6pzfOiZz/IkViXY8LL cKqScueZANDHpGMCy9vmzIYjT0u4Rgh16OvpGKnU+Qj1M7n5gTyLQuyi5nVKsgxM3f7K /KtipxaWhu/LqdogoNWJ8KAtXk/bMrcXqh4M21MEzm1wqAqKZM2jK27/pwsQiJBn4TrL 3uJhJgUIo85tvQBNSrROHC/bJT5DUhqQfBYnWn6jl0BukAsiYWX0EumCpO4BdLVfU5xx 79hMuTDQP1l8sJvI58S7Pe6rkyZvefkCk6o9AHmbpx1Oo2J552wIO+hRo++fIYc9OklY WHZg== 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=LXEZGjhgSmudnsBZwLcWEPXV7LSvwWu9VPMnoVGY8eg=; b=s1DJdEnRYS+n2sehH02rjIjXviE+HkvT2ZOZfCjdLDJFxvZVBRlC0rIohmq/brLNmw cOqZh8HKSeAvAfHK0iydDF/ovKkgs5zGOAcuQbJMU732npzTZwGmMxfXFkAdSEr0JDkY 7OpbQQBxzBUFc9GHF67VlmIG9IBHkf7vg8/8V+5qd50fcSoq2MAnj1dtGDyDoA2XsTrO aB1JaL+8jfCqtKL6G0d7yWd4UvDhwLKnZvp/ykbfZzi+Wh7heHNXws7hkimAtQPmooFJ l6jTH8KHPxGiM6z5UmtnLBZNpG/PxfjloWHbRHVV95FlUX+s8Tn/AkHKpz8Qmpjutcw/ B5Cg== X-Gm-Message-State: AODbwcB3QWmJZzNG44chvnc92fCZlUvxijMAxKL2gQaPIB71kcCTabMK IxLh6I9SwGbWTadzYysG4qESeeN8ryLh X-Received: by 10.107.197.68 with SMTP id v65mr16914064iof.218.1497242504633; Sun, 11 Jun 2017 21:41:44 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Sun, 11 Jun 2017 21:41:43 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: References: From: Warner Losh Date: Sun, 11 Jun 2017 22:41:43 -0600 X-Google-Sender-Auth: jBRn9CsrhcAA3llQmHE7syIoS-M Message-ID: Subject: Re: Deorbiting armv4 and armv5 support To: Ronald Klop Cc: "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: Mon, 12 Jun 2017 04:41:45 -0000 On Sun, Jun 11, 2017 at 3:28 PM, Ronald Klop wrote: > On Thu, 08 Jun 2017 22:22:51 +0200, Warner Losh wrote: > > Greetings, >> >> The pmap in armv4/5 has been broken for years at this point. It basically >> works, but has issues with unaligned buffers. Since these have remained >> unfixed for a long time, and most of the main ARM developers have given up >> trying to fix it, I think it would be best to retire the support rather >> than waste people's time that seem to be working only to discover after a >> lot of effort that it's busted. >> >> Since the consensus at the FreeBSD developer's summit appeared to be >> 'let's >> let it go'. It would remove the TARGET_ARCH arm and armeb. armv6 would >> remain unaffected (though see a parallel thread). >> >> Warner >> > > What branches are you talking about? > I'm thinking only the -current branch. However, I'm thinking now that I'll write up something more formal (the FCP process) and start maybe a 3 month timeout. There's two leads on a fix, I'll be looking at one of them in the next few days. If one of these fixes is good, I'll merge it. The second one is a long shot, though... So, my current plan is that if it remains unfixed by, say Sept 1, 2017, I'll deorbit. I may adjust that date depending on the timing of the 12 branch, since I want to get this resolved before the branch... Warner From owner-freebsd-arm@freebsd.org Mon Jun 12 07:59:28 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 53C79BF64A8 for ; Mon, 12 Jun 2017 07:59:28 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B356117A3 for ; Mon, 12 Jun 2017 07:59:27 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=tvijlbrief@gmail.com DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3wmQK75GrczsGg DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1497254363; bh=paJRZpSPZywknhtAwYSQ/v0aVBhO76JeeIrU0MxSWgA=; h=Subject:To:References:From:Date:In-Reply-To; z=Subject:=20Re:=20[Bug=20219927]=20awg0=20stops=20working=20after= 20a=20long=20output=20under=20ssh|To:=20Tom=20Vijlbrief=20,=20freebsd-arm@freebsd.org|References:=20=0D=0A=20|From:=20Henri=20H ennebert=20|Date:=20Mon,=2012=20Jun=202017=2009:59 :21=20+0200|In-Reply-To:=20; b=bxzP3we8S6e2k7EM8keh4NpKh60YjixE5yi7fThHHOdELayZa/8SF+PUITb7TwR32 fLc3GPAJY+rI4Oq2/2nMFrQeko1q4Og/HnLz7Q9W2Rr1T76whndrRnwibYVD/68cBw xNxWaSY6KBGXtqyTJUgyBCaHL2j3s73IM04FVxWTI6Z2LLueQ6Zz2FkJHs0w0cNeXw EQOal7ecL0FQD0KNxenvJ9iT9J5dBjmwWwPAlNozKsEAlZ+wdd/A0mdCHD0kMqdPWk n6Rh8lci0s1eXvCqYVK7G1Odr5b/Mkqrq07b/EaoZBHfVL/ooLvUZN+qSdMchEAIi7 NEiMZoOIfkwxQ== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3wmQK75GrczsGg; Mon, 12 Jun 2017 09:59:23 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v5C7xL1C030648 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Jun 2017 09:59:22 +0200 (CEST) (envelope-from hlh@restart.be) Subject: Re: [Bug 219927] awg0 stops working after a long output under ssh To: Tom Vijlbrief , freebsd-arm@freebsd.org References: From: Henri Hennebert Message-ID: <158994e0-9f53-e64a-2b81-b554894571c6@restart.be> Date: Mon, 12 Jun 2017 09:59:21 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic 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, 12 Jun 2017 07:59:28 -0000 On 06/11/2017 17:54, Tom Vijlbrief wrote: > > Op zo 11 jun. 2017 om 16:23 schreef >: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219927 > > Bug ID: 219927 > Summary: awg0 stops working after a long output under ssh > Product: Base System > Version: CURRENT > Hardware: arm64 > OS: Any > Status: New > Severity: Affects Only Me > Priority: --- > Component: arm > Assignee: freebsd-arm@FreeBSD.org > Reporter: hlh@restart.be > > Environment: pine64+ 2GB > FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 > r318945M: Sat > Jun 10 11:47:44 CEST 2017 > root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 > > If I connect from a wireless computer (FreeBSD 11.1-PRERELEASE #0 > r318860) and > run a command with a big output (eg `find /`) the awg0 stops working > quickly > (under 20 seconds of output). > > If I do the same with telnet from the same computer, the output is > much longer > but awg0 stops working. > > If I do the same from a wired computer then I must run `find /` 2 or > 3 times > before awg0 stops working. > > I can rsync through ssh 12GB without problem in both directions > (from and to > the pine64 and the wireless computer). > > I have a `tcpdump -w ssh.data port 22`. (8.3 MB) > > I can connect with a serial console to the pine64 after awg0 stop > working. > ifconfig awg0 down > ifconfig awg0 up > don't restore the connectivity. I must reboot to restore connectvity. > > > That's a coincidence, today I'm investigating the same issue. > > You could try increasing TX_MAX_SEGS in sys/arm/allwinner/if_awg.c line 95. > > I'm currently testing TX_MAX_SEGS set to 40 and no lock up yet.... Bingo. Your solution solved the problem. Thanks a lot. From owner-freebsd-arm@freebsd.org Mon Jun 12 08:48: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 37E62BF6FCD for ; Mon, 12 Jun 2017 08:48:07 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 E05DA2B0F for ; Mon, 12 Jun 2017 08:48:06 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-yw0-x235.google.com with SMTP id e142so25708329ywa.1 for ; Mon, 12 Jun 2017 01:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=x5y1LZJzyWOndKqtbVi2TAENMZ/unrmGmRniYDzQbR4=; b=YbTh6YxWGQ9w4Xm3OfhT0RiLr1tJKDc3j2J7x8M3bwawHPjSXg3mZ2Hq09Gi5HT8Vy Yh5hN+/MgCBZRNarlHBKEk1EQyaifhuD20BhLAdeCr4WhRCU9d1WQngFlVvY5tHcu746 wGxq5iEZOSbsbdBHVF0M0pjIfkIPIM+bt1EgSoY+wzTJg/ZbzBm6Rf1A8Ua4R1bNsmPh yZDhgTsCSjXxZ7tsdPYiNEX2Nvv+R2MWy5wzjgwmfx8O+dmRkeEc6pskDqUmmmHb1Ya4 Q2M2H0FljYmPDbKiBOCl9/7rscyqHdCtUAViRiJW8T96nKBrSJ1lsQtVkdjAXiI6UdES L7dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=x5y1LZJzyWOndKqtbVi2TAENMZ/unrmGmRniYDzQbR4=; b=GEYMkH2TfFgzzt09atuSQSE3q6V1TRQLW8PJBfDbyfx0spc9oXPdPULIMSphoEWIoS yt8qxQdgXSBgH0PfupFL3LdnF2SXFCW6+ClekfSaF1xjzkSL/grdwHxaJDFDVjn/Or2l 1Exkl42fqLY4QjZ/qZIXzOAigQuz5WYvElliwU8f7ngqlZl98AOp3Zism+03Q93InCTb vgQNfa0310klM/hru5FJBRCHZKASILOg8KXC2EEdEZZQBRZJAMTmjFFDQd8CTE/0SHJa 2Iye9RYn/FDdp+WCGwj65Jtt/LIIfP45vu3g6zugRPhuFyRCKRIzTqKY9+w/1pMPAiTk Nmew== X-Gm-Message-State: AODbwcB/OvnCCaUnwroUCTaRpIA6DEazLM8g7Fv/1RrwFUlIB/jBIDQd VDwPBj+b8RxXM7xgdvZvRNN8JBPfJg== X-Received: by 10.129.76.14 with SMTP id z14mr23509837ywa.20.1497257286097; Mon, 12 Jun 2017 01:48:06 -0700 (PDT) MIME-Version: 1.0 References: <158994e0-9f53-e64a-2b81-b554894571c6@restart.be> In-Reply-To: <158994e0-9f53-e64a-2b81-b554894571c6@restart.be> From: Tom Vijlbrief Date: Mon, 12 Jun 2017 08:47:55 +0000 Message-ID: Subject: Re: [Bug 219927] awg0 stops working after a long output under ssh To: Henri Hennebert , freebsd-arm 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: Mon, 12 Jun 2017 08:48:07 -0000 Op ma 12 jun. 2017 09:59 schreef Henri Hennebert : > On 06/11/2017 17:54, Tom Vijlbrief wrote: > > > > Op zo 11 jun. 2017 om 16:23 schreef > >: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219927 > > > > Bug ID: 219927 > > Summary: awg0 stops working after a long output under ssh > > Product: Base System > > Version: CURRENT > > Hardware: arm64 > > OS: Any > > Status: New > > Severity: Affects Only Me > > Priority: --- > > Component: arm > > Assignee: freebsd-arm@FreeBSD.org > > Reporter: hlh@restart.be > > > > Environment: pine64+ 2GB > > FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 > > r318945M: Sat > > Jun 10 11:47:44 CEST 2017 > > root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 > > > > If I connect from a wireless computer (FreeBSD 11.1-PRERELEASE #0 > > r318860) and > > run a command with a big output (eg `find /`) the awg0 stops working > > quickly > > (under 20 seconds of output). > > > > If I do the same with telnet from the same computer, the output is > > much longer > > but awg0 stops working. > > > > If I do the same from a wired computer then I must run `find /` 2 or > > 3 times > > before awg0 stops working. > > > > I can rsync through ssh 12GB without problem in both directions > > (from and to > > the pine64 and the wireless computer). > > > > I have a `tcpdump -w ssh.data port 22`. (8.3 MB) > > > > I can connect with a serial console to the pine64 after awg0 stop > > working. > > ifconfig awg0 down > > ifconfig awg0 up > > don't restore the connectivity. I must reboot to restore connectvity. > > > > > > That's a coincidence, today I'm investigating the same issue. > > > > You could try increasing TX_MAX_SEGS in sys/arm/allwinner/if_awg.c line > 95. > > > > I'm currently testing TX_MAX_SEGS set to 40 and no lock up yet.... > > Bingo. Your solution solved the problem. > > Thanks a lot. > Good to hear! Increasing from 10 to 20 is probably sufficient. It is not clear to me what the adverse effects are of a too high value. The root cause is that the driver tries to call m_collapse with this limit and this will fail. The tcp stack will resent the package and the m_collapse will fail again and again and ... From owner-freebsd-arm@freebsd.org Mon Jun 12 13:31:27 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 65997BFCB43 for ; Mon, 12 Jun 2017 13:31:27 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 209B66FB19 for ; Mon, 12 Jun 2017 13:31:27 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-yw0-x22f.google.com with SMTP id e142so27490215ywa.1 for ; Mon, 12 Jun 2017 06:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=v6zg0dmKGNf6Ha6ASpCCYw9WCQccg8aVBkxC7M844Ao=; b=PvUkmOLFPGWW+ziKfpmJgJjE4QFgjK/kdOSR7C76oI6+UHziHVKhIEyFJsY7bWOQ8t G5W4zlS1rviOMCESXgpcKNv7ouHGN7DLwFKe4ckam2yj0ZbYyoY3/woFS+C/whutfo4q rYBPNESAz0SfaGnluF9Brt4YMPhYa9vJ/+ExyF6WLoOwarGxMHzaZR0qgIQWBFPjAgUD ZY7v7RALHUmQbv9mkPDgL0zjzgpo7Zw9Xkk+9au3eLPsAHO93rQv3cYz0H1y/N1H9W/v 3LsiquOVaDTwqiRPb+KU/7TS8rzeMh1zoJRc2yLn12mzfJ0gr4IRSQ/0m0sxbtdnQB0k xq+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=v6zg0dmKGNf6Ha6ASpCCYw9WCQccg8aVBkxC7M844Ao=; b=IK4z0VGP2nb1HTMPUDkAMh8PEWKtsiLoHltwjvKxZqGuGtuAGUSIR3ia9wnuh5Mliu ZOrngQ7JI4BMvxaU/rYecmrH6X7gw3pS1LlkPYDZh/RVThytlprkgilTIedimiYVXSuO QhFCqhg7ylauTztbd9UouYdM8L058Tor6iToiZVNvL/GPDyAulEwaLIvobGnecACeLj3 xQVxuqEFOKCLSPPJG1yIxsCGpWz9f2fyq0JW7ZFGlZfRnhq22A23gMlQrKgqVC6qCyAG uXV0zM2A8NKdJ1pfStZKq7Rk+KS2TB9c5YAmz1tQVf592oNc7NPCa4v213gZkVTbzKog ragA== X-Gm-Message-State: AODbwcAkYGV5s9JlxHzNAhEvagAumJLAaaidHU9rAgqOpmTvVgrnbWFt i55oxQ/FXtoXg0j6nLIp66h3Mlpw1g== X-Received: by 10.129.76.14 with SMTP id z14mr24355294ywa.20.1497274286276; Mon, 12 Jun 2017 06:31:26 -0700 (PDT) MIME-Version: 1.0 References: <158994e0-9f53-e64a-2b81-b554894571c6@restart.be> In-Reply-To: From: Tom Vijlbrief Date: Mon, 12 Jun 2017 13:31:15 +0000 Message-ID: Subject: Re: [Bug 219927] awg0 stops working after a long output under ssh To: Henri Hennebert , freebsd-arm 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: Mon, 12 Jun 2017 13:31:27 -0000 Tested with TX_MAG_SEGS at 20 and that is also stable for me, so I added a patch to the original bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219927 The only downside I can see is a modest increase in kernel stack usage: Index: sys/arm/allwinner/if_awg.c =================================================================== --- sys/arm/allwinner/if_awg.c (revision 319826) +++ sys/arm/allwinner/if_awg.c (working copy) @@ -92,7 +92,7 @@ #define TX_SKIP(n, o) (((n) + (o)) & (TX_DESC_COUNT - 1)) #define RX_NEXT(n) (((n) + 1) & (RX_DESC_COUNT - 1)) -#define TX_MAX_SEGS 10 +#define TX_MAX_SEGS 20 #define SOFT_RST_RETRY 1000 #define MII_BUSY_RETRY 1000 @@ -419,14 +419,18 @@ sc->tx.buf_map[index].map, m, segs, &nsegs, BUS_DMA_NOWAIT); if (error == EFBIG) { m = m_collapse(m, M_NOWAIT, TX_MAX_SEGS); - if (m == NULL) + if (m == NULL) { + device_printf(sc->miibus, "awg_setup_txbuf: m_collapse failed\n"); return (0); + } *mp = m; error = bus_dmamap_load_mbuf_sg(sc->tx.buf_tag, sc->tx.buf_map[index].map, m, segs, &nsegs, BUS_DMA_NOWAIT); } - if (error != 0) + if (error != 0) { + device_printf(sc->miibus, "awg_setup_txbuf: bus_dmamap_load_mbuf_sg failed\n"); return (0); + } bus_dmamap_sync(sc->tx.buf_tag, sc->tx.buf_map[index].map, BUS_DMASYNC_PREWRITE); Op ma 12 jun. 2017 om 10:47 schreef Tom Vijlbrief : > > > Op ma 12 jun. 2017 09:59 schreef Henri Hennebert : > >> On 06/11/2017 17:54, Tom Vijlbrief wrote: >> > >> > Op zo 11 jun. 2017 om 16:23 schreef > > >: >> > >> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219927 >> > >> > Bug ID: 219927 >> > Summary: awg0 stops working after a long output under >> ssh >> > Product: Base System >> > Version: CURRENT >> > Hardware: arm64 >> > OS: Any >> > Status: New >> > Severity: Affects Only Me >> > Priority: --- >> > Component: arm >> > Assignee: freebsd-arm@FreeBSD.org >> > Reporter: hlh@restart.be >> > >> > Environment: pine64+ 2GB >> > FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 >> > r318945M: Sat >> > Jun 10 11:47:44 CEST 2017 >> > root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 >> > >> > If I connect from a wireless computer (FreeBSD 11.1-PRERELEASE #0 >> > r318860) and >> > run a command with a big output (eg `find /`) the awg0 stops working >> > quickly >> > (under 20 seconds of output). >> > >> > If I do the same with telnet from the same computer, the output is >> > much longer >> > but awg0 stops working. >> > >> > If I do the same from a wired computer then I must run `find /` 2 or >> > 3 times >> > before awg0 stops working. >> > >> > I can rsync through ssh 12GB without problem in both directions >> > (from and to >> > the pine64 and the wireless computer). >> > >> > I have a `tcpdump -w ssh.data port 22`. (8.3 MB) >> > >> > I can connect with a serial console to the pine64 after awg0 stop >> > working. >> > ifconfig awg0 down >> > ifconfig awg0 up >> > don't restore the connectivity. I must reboot to restore >> connectvity. >> > >> > >> > That's a coincidence, today I'm investigating the same issue. >> > >> > You could try increasing TX_MAX_SEGS in sys/arm/allwinner/if_awg.c >> line 95. >> > >> > I'm currently testing TX_MAX_SEGS set to 40 and no lock up yet.... >> >> Bingo. Your solution solved the problem. >> >> Thanks a lot. >> > > Good to hear! > > Increasing from 10 to 20 is probably sufficient. It is not clear to me > what the adverse effects are of a too high value. > > The root cause is that the driver tries to call m_collapse with this limit > and this will fail. The tcp stack will resent the package and the > m_collapse will fail again and again and ... > > From owner-freebsd-arm@freebsd.org Mon Jun 12 13:59: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 364A4BFD21E for ; Mon, 12 Jun 2017 13:59:38 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 04E227062C for ; Mon, 12 Jun 2017 13:59:37 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [10.0.0.69] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 946A84EBA9; Mon, 12 Jun 2017 13:59:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Creating armv7 MACHINE_ARCH From: Andrew Turner In-Reply-To: Date: Mon, 12 Jun 2017 14:59:00 +0100 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh 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, 12 Jun 2017 13:59:38 -0000 > On 8 Jun 2017, at 21:27, Warner Losh wrote: >=20 > While the kernel doesn't really need an armv7 support, there will be a > better match to other systems if we create a armv7 MACHINE_ARCH. This = will > be in addition to the armv6 MACHINE_ARCH we have today. This will = allow us > to create a package set optimized for armv7 as well as armv6. While it = is > true the RPI 1 is the only system that needs armv6 binaries, it's = quite > popular and the Raspberry Pi folks keep creating new variants with the = same > chip. It would also let us get the package stuff spun up and working = before > we mess with armv6. >=20 > This would also separate the fate of armv6 and armv7 support at a = later > time, but the weak consensus I've heard appears to be that the time = isn't > yet right to discuss retiring armv6 support... >=20 > Warner I like this. My understanding is adding armv7 would also fix many of the = currently broken ports that assume they are being built for armv7 as = many Linux distros target ARMv7+. It should also be noted the GENERIC kernel is likely to only ever target = ARMv7+ even without an armv7 TARGET_ARCH. Andrew From owner-freebsd-arm@freebsd.org Mon Jun 12 15:22: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 89EE8BFE98A for ; Mon, 12 Jun 2017 15:22:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5384C7306A for ; Mon, 12 Jun 2017 15:22:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id y77so56706370ioe.3 for ; Mon, 12 Jun 2017 08:22:15 -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=l5F8dNCR7lzrBqDKdW4Iv3rPkXNRPVeHChoxjeJOiwI=; b=bCcLYLVIZigSKxmSfy82Io8J3b/4GcQjof2CKpjNoOWiEHMRuvEM+T1wdYVHNiF5tU 6wk4xDXs45tSwyjwrN9i7Vx6VnbtXmwS8YlZJeDwDvni9EYsgmmMJMAd8YdvkPcn2oYW LDmk8PnGZpOc9u/jPeWX6MgAYcm3roSxSWsZiaxbOOGxB5Pjt3v562NzVP63uMK0QeV9 dwTgoxRZGf5gWSG2lionvgV3QM+3Dwp/43YQcgZT5vPh2NvaECP0CpIZEqP7WryTrqNr lG4hbqfTai/6Ubv6rGsnBW0a8+2nXep4TeNaUz/lHz0om8343/9YijXsxvEW0fGtet12 1Fbg== 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=l5F8dNCR7lzrBqDKdW4Iv3rPkXNRPVeHChoxjeJOiwI=; b=aPGuSkdixjTjcIRch7d0KCU5wBD5trCUszjLVUA/MKi5h85TWCd23P5t19F72IN9zs iGkX6TWiiDHqKj7tyQsXVGfyA52wxgChHPHnrkxaWzAc5C0JWwK+LVTPun0KznVjsmdA her2fpodS9r3H9+GDaBlDtWKPVmFe9QmzR4/04y4uP1Wh6oIEPd3WbpYy2/Hvh+aowYi Un56es+5LeXAwWP8yDGb/wIBXl0UzGte7izv/37S7xv6XfEtWTNlNUEAHYxo4hQdoFYu fu2Up1RcqSoYdeugUDUUFbrYotLHurKMgwjJtvBLBpEIdEMYCoVi2vjSuvbuI174Ahd6 yzSQ== X-Gm-Message-State: AODbwcAjI1xFLbGg9Id5GJpYHYu+/BazEfAjadP+B4eqooaQMtDeRo8Q bfGt6u5atQCBaA/KSbYXoQE3O6zAJOIb X-Received: by 10.107.197.68 with SMTP id v65mr19052720iof.218.1497280934523; Mon, 12 Jun 2017 08:22:14 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Mon, 12 Jun 2017 08:22:13 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: References: From: Warner Losh Date: Mon, 12 Jun 2017 09:22:13 -0600 X-Google-Sender-Auth: e5CDLTT085aHtFWAksdXUdTNVQg Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Andrew Turner Cc: "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: Mon, 12 Jun 2017 15:22:15 -0000 On Mon, Jun 12, 2017 at 7:59 AM, Andrew Turner wrote: > > > On 8 Jun 2017, at 21:27, Warner Losh wrote: > > > > While the kernel doesn't really need an armv7 support, there will be a > > better match to other systems if we create a armv7 MACHINE_ARCH. This > will > > be in addition to the armv6 MACHINE_ARCH we have today. This will allow > us > > to create a package set optimized for armv7 as well as armv6. While it is > > true the RPI 1 is the only system that needs armv6 binaries, it's quite > > popular and the Raspberry Pi folks keep creating new variants with the > same > > chip. It would also let us get the package stuff spun up and working > before > > we mess with armv6. > > > > This would also separate the fate of armv6 and armv7 support at a later > > time, but the weak consensus I've heard appears to be that the time isn't > > yet right to discuss retiring armv6 support... > > > > Warner > > I like this. My understanding is adding armv7 would also fix many of the > currently broken ports that assume they are being built for armv7 as many > Linux distros target ARMv7+. > > It should also be noted the GENERIC kernel is likely to only ever target > ARMv7+ even without an armv7 TARGET_ARCH. > We already compile all the non-RPI kernels de-facto how we'd do an armv7 TARGET_ARCH. Is there a rough consensus that we want to do this? Are there any objections? Should I ask RE? Do I need to do an FCP to write down the decision with core blessing our understanding of the consensus? Warner From owner-freebsd-arm@freebsd.org Mon Jun 12 15:28: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 E72F6BFEA64 for ; Mon, 12 Jun 2017 15:28:10 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 B709673307 for ; Mon, 12 Jun 2017 15:28:10 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pf0-x234.google.com with SMTP id 83so52713325pfr.0 for ; Mon, 12 Jun 2017 08:28:10 -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; bh=eWoDSCooy8D88YNSncNmJO5xtmRTeXwuuG7eM52H8uI=; b=WUOvsWCQElbiKB/Fcp4MCiePBWVAxH+wJB7jQmJjDZR+/Oiaxdf6XUo2fXW69XLTyB AMljOUbyCguInnBWGgFAIAkoY/myb1yRHAmIVia1ep0fE3oXIR1p3/xzwKtX1jtxbhhu FWJmE4AnCDNDok0N3fRukJ551Aoy4WGY5IYs1nTNNJ6X53b7Vq31EQwi65q2VoRiVZF6 I+cEle/uQB03QJ8oQJnKJatepd+gu3i6u8QU7T3ANUPpCBT0Sc5D5WAR5Ts+WJzBDuD4 g8Byiqh9Z0XZLOg8vFGfUHOxVv7JUsV3ADE3XjNxkEgXBn7fP+jBVKuRciqs/2FrjuPE fW6g== 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; bh=eWoDSCooy8D88YNSncNmJO5xtmRTeXwuuG7eM52H8uI=; b=mD5Erc8DV/9pWEkawbXK8xh0Ja9JF3dq5OzIG1Kx3Oiu6Kp3A7eq/4eFmgTawu/Ojh qj0MzVFHEMBk6g7irlR90DQxtcPQ5cRM1tHdsUiuWg3KsNJyY9BFHjtjvFMEr7MAbW1Y 4AUOuKQ0G/bLbtVN/2AhJ26NljZQNij4UY57qpgT87QriMKxY1cgYJoN/6P9lVesYAQw VVgQzrWpTpjKXJ1yD6Lnv/cyBARSsTk5cxWSz3NGL98pD7xMi9y3+/b63AMLqSK00pSK aKRkeAYhRE6QQ4LDAgWKjuD0CqbxxGtrDfmO8AncTQJOqIO0e1cERMe7nxMZK3CY0223 DUfw== X-Gm-Message-State: AODbwcCjqXELFEeIs84SdLDYEas8taZKQl+gjN6FA9C4f1kS2Eo4xBCg LXDpuaRkkWow47LA+hc= X-Received: by 10.84.217.141 with SMTP id p13mr57282796pli.271.1497281290346; Mon, 12 Jun 2017 08:28:10 -0700 (PDT) Received: from [127.0.0.1] ([184.151.231.58]) by smtp.gmail.com with ESMTPSA id r75sm22866722pfl.49.2017.06.12.08.28.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jun 2017 08:28:09 -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: <20170612152808.6094931.74364.27128@gmail.com> Date: Mon, 12 Jun 2017 08:28:08 -0700 Subject: Re: Creating armv7 MACHINE_ARCH From: Russell Haley In-Reply-To: References: To: Warner Losh , freebsd-arm@freebsd.org 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, 12 Jun 2017 15:28:11 -0000 Sorry for the top post.=C2=A0 Hasn't Ian Lapore been saying this since pre R10?=E2=80=8E I seems to remem= ber people doing backflips to get around this=E2=80=8E heading up to that r= elease and it was considered to much effort. Can I ask what has changed? Russ 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: Warner Losh Sent: Thursday, June 8, 2017 1:27 PM To: freebsd-arm@freebsd.org Subject: Creating armv7 MACHINE_ARCH While the kernel doesn't really need an armv7 support, there will be a better match to other systems if we create a armv7 MACHINE_ARCH. This will be in addition to the armv6 MACHINE_ARCH we have today. This will allow us to create a package set optimized for armv7 as well as armv6. While it is true the RPI 1 is the only system that needs armv6 binaries, it's quite popular and the Raspberry Pi folks keep creating new variants with the same chip. It would also let us get the package stuff spun up and working before we mess with armv6. This would also separate the fate of armv6 and armv7 support at a later time, but the weak consensus I've heard appears to be that the time isn't yet right to discuss retiring armv6 support... 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 Mon Jun 12 15:39: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 318AABFED13 for ; Mon, 12 Jun 2017 15:39:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 EA2A9738DF for ; Mon, 12 Jun 2017 15:39:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id m47so6315131iti.1 for ; Mon, 12 Jun 2017 08:39:05 -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=B2DZnrTc3rTp5y+qJpy5tAizI7e+r69hqySwlIRRtDE=; b=qOk3tcl10IafQWTJh04RxwI7nvpZRS/sWXaqBLnbr/vPgkrCYhqj62aS21q4bWupWt Fv+g5gzGwGoVP6hCCfPwoqsKS5yyAcimg36lU8kOvtVQzkrEpLa26NorcqfFML0Yxtpo VUytLkYF/FMQn0BGAk/ECSF8z6WGlnTQfGxM9OjwbXi+0QFlP/rjJFYw92XNUjLYebb3 tsu+v++SqkXXuXyt0vgnln7goKDACpuKANWW2EMIk1ukCmzZK7adt9LGwln6tYV2Awlo vAcla8aGki2fziPrbFmvqBkqOllt+kDuNSoTpqY6JL58GvuN/4tpOioY9NJ/qgeBT3d2 beuQ== 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=B2DZnrTc3rTp5y+qJpy5tAizI7e+r69hqySwlIRRtDE=; b=Y29bdi7oeATFys5y4SU6ulTIG5JpzeenLHDo3M85SykI5cO2Qh2z7aVrNZmWWgrtBv xLLxXko9ivcRxgGBNPRYmK8EL4hgHEu4VHFLyhieHHp14ba7kSMBaw4ZfUTehiAG6gfq 2aWKExipdDmrqaH6AYVlCQDKc6PALSa07xn449U94wOb/ZNN7h5BE2soqLeChyw9C+LF wAfcVTWBZuReCjTKFFCBBBPFL6L1YFEQA5X2CVVB5t3ie2BGhLvQBsQGe7pK/NEGThk9 9UQhBGjqUChbfXgjBiWlQjcWZvKP05wPlZy3YcFzDwnrjj1QzrfaVPrV33Sig5yigVCM wtNA== X-Gm-Message-State: AODbwcDqu7lUdZiz3S/HBxlHIDI0iS3XJXzhWFZWy32Oosu7NHv7VFxO 4/2FGfRYehIdsuzmpFG26oRYM1y6JCAL X-Received: by 10.36.105.13 with SMTP id e13mr12273453itc.64.1497281945194; Mon, 12 Jun 2017 08:39:05 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Mon, 12 Jun 2017 08:39:04 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: <20170612152808.6094931.74364.27128@gmail.com> References: <20170612152808.6094931.74364.27128@gmail.com> From: Warner Losh Date: Mon, 12 Jun 2017 09:39:04 -0600 X-Google-Sender-Auth: nCYofijZFmwyG1wdwoNpC2P1IDg Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Russell Haley Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.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: Mon, 12 Jun 2017 15:39:06 -0000 Clearly, we woke up one day and realized Ian was right? And he's only been saying it since pre R11 since that was the first release that supported it. There was no armv6 support in 10. Ask a snarky question, get a snarky answer... What's changed is that the port has gone from being mainly used by people that had an rpi that supported a bunch of other platforms (including Ian's iMX6) to a port that's used primarily by armv7 machines (including the rpi2) that also happens to support the rpi (which is the only !armv7 platform). When Ian started saying it, rpi was one of the better supported platforms as well. Now with all the Allwinner support, improved iMX6 support, and the rpi2 being armv7, we are now in a situation where most users and most of the good support is on that platform. What's also changed is Andrew's work on having a GENERIC kernel. We'd have a GENERIC one for ARMv6 too: It's the RPI config :). Plus, we aren't quite doing what Ian wanted. He wanted a full rename. The proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to rename or remove armv6. Sadly, that will still be there since the RPI foundation keeps finding new ways to repackage the rpi into new boards that are just too cheap to ignore. Warner On Mon, Jun 12, 2017 at 9:28 AM, Russell Haley wrote= : > Sorry for the top post. > > Hasn't Ian Lapore been saying this since pre R10?=E2=80=8E I seems to rem= ember > people doing backflips to get around this=E2=80=8E heading up to that rel= ease and > it was considered to much effort. Can I ask what has changed? > > Russ > > Sent from my BlackBerry 10 smartphone on the Virgin Mobile network. > Original Message > From: Warner Losh > Sent: Thursday, June 8, 2017 1:27 PM > To: freebsd-arm@freebsd.org > Subject: Creating armv7 MACHINE_ARCH > > While the kernel doesn't really need an armv7 support, there will be a > better match to other systems if we create a armv7 MACHINE_ARCH. This wil= l > be in addition to the armv6 MACHINE_ARCH we have today. This will allow u= s > to create a package set optimized for armv7 as well as armv6. While it is > true the RPI 1 is the only system that needs armv6 binaries, it's quite > popular and the Raspberry Pi folks keep creating new variants with the sa= me > chip. It would also let us get the package stuff spun up and working befo= re > we mess with armv6. > > This would also separate the fate of armv6 and armv7 support at a later > time, but the weak consensus I've heard appears to be that the time isn't > yet right to discuss retiring armv6 support... > > 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 Mon Jun 12 15:40: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 65AF9BFED65 for ; Mon, 12 Jun 2017 15:40:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B2257395B for ; Mon, 12 Jun 2017 15:40:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id i7so56943082ioe.1 for ; Mon, 12 Jun 2017 08:40:02 -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=7Hmv1BNDxoY+fDKJCix89c5SUXGgAIwBBa663UNgDlE=; b=yfgUQux/3H9mkoNS/NqrWY5aIUin282rvorWj1xOuHCzH/Obl32Px7BH96Tu53Pt3z 2wE9eTdePTA8maj8RJhBQ5w/bWoyiZHMAepPlFiY3FltTgmxhseVTc+xuUS27eYddosn TS/BCHSRpj5uYjSQ1uDfem/Twmpe/nTrEAc0YZE9dIIUN56xpJKoYqITzDk+OCfxqxqY SXM31LlNT0U0kCt7uIc6cPj5UIJek6wW4VZCiw3iX868JxgN7sNJp4nyfZ98+KGdi3we 42rpCPuJgtOwGBU8XaCiXH26URCsaSKAJ1U+SfWJBCRjM/eoGEBwbuyF0Vkh0N+dpXkA V09A== 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=7Hmv1BNDxoY+fDKJCix89c5SUXGgAIwBBa663UNgDlE=; b=JTzvJ88PIwiNpd7uagD/m59S0ZjQR1FyIa08nvA9xgZ8THEIBgmPjyHVS9cHvCePOu APYvOrzAiUCWQR1bPKBf9Jkws7c44fLDfZp6PQqcbkQiCS8ykfO55XHVGMyWICkba/D9 NMGJSOaGepY/Vz4Px19KdlS72h8oOo5F0sWAEsEb8dICQaRZCmuMLs7qxW6n9cu5r4Ve 7jx+li2y2q2RB8AZhOZaQDldYzPcc1jB3V3EH+KNLXjniKwT03BdhjNY20kuon39z4eY mfK0mGgmgzPnscEl1MOyt63yli1y5iDPrsTmaI1I2+U8n3RY94y5qqLJt/kowRBY0Wxl IjqQ== X-Gm-Message-State: AODbwcCLTU6vOL6B12w1iI8AzutoEI8TE65GQPiWxkJGrY+F5mcggr7l kYAy+hw/W2nub0PihNs2Imsb/N+/GhMK X-Received: by 10.107.16.217 with SMTP id 86mr56756018ioq.134.1497282001275; Mon, 12 Jun 2017 08:40:01 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Mon, 12 Jun 2017 08:40:00 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> From: Warner Losh Date: Mon, 12 Jun 2017 09:40:00 -0600 X-Google-Sender-Auth: 1q9QArHBLTH6Gq88AAWX8xcVdpI Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Russell Haley Cc: "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: Mon, 12 Jun 2017 15:40:02 -0000 On Mon, Jun 12, 2017 at 9:39 AM, Warner Losh wrote: > Clearly, we woke up one day and realized Ian was right? And he's only been > saying it since pre R11 since that was the first release that supported it. > There was no armv6 support in 10. Ask a snarky question, get a snarky > answer... > I take that last bit back. The support in 11 is for hard float. 10.x did have some support. Warner From owner-freebsd-arm@freebsd.org Mon Jun 12 15:46: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 B8DA5BFEEE5 for ; Mon, 12 Jun 2017 15:46:17 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 8724073CCD for ; Mon, 12 Jun 2017 15:46:17 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pf0-x22b.google.com with SMTP id 15so25304426pfc.1 for ; Mon, 12 Jun 2017 08:46:17 -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=+Gh9NVh5OI82CBpZ2sooypsbBt5DNu8VTnd7mbx327w=; b=NdLPkJURVt/4GACDSi9f362q399/7nNl06e427XYAD0vEqp9mQKSjqXnmm+wY2uI9e LA/U2A9MYVCXvI3WV1cLFYEZtioZa3k+8LpEtdVvTg+ozqrXRDvMuffDVkAhB5FMk6Cl dlsWmMONqKF1FUUWGVZA6gp0BK5emkbvXqSM32+wTihJ6G5kJuxrXlAv1QZEjNuixMSD 7NlVtBq+mI4hiZkn9doC1SsdWI4ujM4hNy8R89A0BysQtDo5vHgQPxGLYaZMAkO6hbXK eKlINTPPIs9HdcwKRn1dUBA2UDQ1HlwSMjyDinZqhWtcxhA3z/KTKt8YGnepp3w9SX+O EMow== 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=+Gh9NVh5OI82CBpZ2sooypsbBt5DNu8VTnd7mbx327w=; b=ciIeDjYxjbh3jiarPJUYqoYscuQCYAI4lNDL4CpxeUaWR9QtaCYxOlI9WRhuzFs8TK MVNgDhFg8KzLCfw6PNipEJvvYkWeB5yCgCg2d0j5rfDhcaAJGDfGhED0rN1t7eAHPFoY QZ45UFfXxE+i4dVqRJob6RY5UYLgqeGU+kBTH3cA4l0xBvSGfyBpQFZZaNDUq308lfeX w9ewH6PydtHP7tcpkH+RqUjSY7OBnl5mW1Cw+eGHyeSNhUaonJg5X8KmrMwRnH+IrA5y ofNsgfSq35OsxMANkRL9lcIygU+7gL5L023rgM0nijkylFDGG4zPR8P5hq30XSfIaVPP WPJA== X-Gm-Message-State: AKS2vOz/tYsGUgGEGTrH3mqdwLk4DJaV/xjNk9Dv6OKHEWMRY1jivpmm jvxIOrRQ+fOvRA== X-Received: by 10.84.143.100 with SMTP id 91mr1694053ply.186.1497282377160; Mon, 12 Jun 2017 08:46:17 -0700 (PDT) Received: from [127.0.0.1] ([184.151.231.58]) by smtp.gmail.com with ESMTPSA id o24sm28183384pgc.11.2017.06.12.08.46.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jun 2017 08:46:15 -0700 (PDT) X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170612154614.6094931.61931.27132@gmail.com> Date: Mon, 12 Jun 2017 08:46:14 -0700 Subject: Re: Creating armv7 MACHINE_ARCH From: Russell Haley In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> To: Warner Losh Cc: freebsd-arm@freebsd.org MIME-Version: 1.0 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: Mon, 12 Jun 2017 15:46:17 -0000 From owner-freebsd-arm@freebsd.org Mon Jun 12 15:47:48 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 D0623BFEF39 for ; Mon, 12 Jun 2017 15:47:48 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 9E46673D43 for ; Mon, 12 Jun 2017 15:47:48 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id l89so52896158pfi.2 for ; Mon, 12 Jun 2017 08:47:48 -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=2dLsrBVMPUTA13dPsAvkYWXvXJ45XKfANFnP1NQLdJs=; b=tPLasUkciKtUjojgynU44VZ17DIwTkvHR5w+AqtD5vn1FgTS4svZHm7gouRHr0idzH wvtAwqnXI2BlyWeboMWCvN6t5VFQqTsZtx5mrCRLm7BhKTrGscrrXlGBsGvWAzM7jjt2 1W0NdS84o21I8NNwCaLy38/zKQ4+C+aAswTQ9ovkkJ/aYVonGXdnrtTE97DnR+bfFj1J 7Lc3JTY6L45F0yGIjxdhMHSas2S8bDMTPnCiiIIgys0/qUk8uxZPxrkedgTGZ5GYItGp FKjQAerRKYoajmQmxeuZzcq5yFhLwrJKx7Cjjjt4a50w4b22TqT8KfwifgYhFuzTBwz1 ILMA== 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=2dLsrBVMPUTA13dPsAvkYWXvXJ45XKfANFnP1NQLdJs=; b=o1/MuAaoO8DN3CCeyCqzlvfdV5aRlX0i8zYVS21oBI2r+Ty5oGNKHeARAl87VGyA02 0Oz2Mrxeno9isxmRiBrJksl/447KNA+LIHlTIKPydsKvI2N+iHj8W1NqqhwE4k/z7YoY httI0KatSexqy4rUfj8RXqb78LEMX1PglPEQTu1Cxk11Gz+MFKq/93ZpDBmTdoME6lo9 kNr4tonB+JzzESMUC3ey8AfGHpak0Lt0KgHedWJwxdKf2evdUPgG0cWiVcM/Dc16W23u +rSCJvwQ3wpYJU/xxBPHn7UEEgp8hrX2Qsnm9a7wwcL8vPc8Z/UzM5QjvK5ReMKn1kZO lPBQ== X-Gm-Message-State: AODbwcAS7SShDXkpS3S5R107yHfrleDBxEQTpvbjZXrPm8NbEjzfrFV9 YPovlLCFur4Ao0hQaOg= X-Received: by 10.98.200.206 with SMTP id i75mr30298668pfk.163.1497282468192; Mon, 12 Jun 2017 08:47:48 -0700 (PDT) Received: from [127.0.0.1] ([184.151.231.58]) by smtp.gmail.com with ESMTPSA id o24sm28190106pgc.11.2017.06.12.08.47.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jun 2017 08:47:46 -0700 (PDT) X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170612154745.6094931.30709.27134@gmail.com> Date: Mon, 12 Jun 2017 08:47:45 -0700 Subject: Re: Creating armv7 MACHINE_ARCH From: Russell Haley In-Reply-To: <20170612154614.6094931.61931.27132@gmail.com> References: <20170612152808.6094931.74364.27128@gmail.com> <20170612154614.6094931.61931.27132@gmail.com> To: Warner Losh Cc: freebsd-arm@freebsd.org MIME-Version: 1.0 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: Mon, 12 Jun 2017 15:47:48 -0000 From owner-freebsd-arm@freebsd.org Mon Jun 12 15:48:48 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 CB0DEBFEF8C for ; Mon, 12 Jun 2017 15:48:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 8E81B73DB5 for ; Mon, 12 Jun 2017 15:48:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id y77so57075043ioe.3 for ; Mon, 12 Jun 2017 08:48:48 -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=PO8c2GpUnkcIMZf+dhkLvfSIDR0HjPiBPLcZJ0esWC0=; b=EtluRSml+OGeSxR0D+XrZIOfQXW+rSL7OxJePilPkXG8ySw9QYPX6FZntpu+AOzk3b X9PDGTcEJCj452ApzaOX/I3XyZ84l0YyWiFDOaP5pbWYc4omf5q8CItXDsif4tSpJX85 nkYFJ0IsvQh3Z277R8g7zROqhVV/IcLs0B9Q2y86WG3u9ULWZudukEN4zYx2Xuf0GHog Ru1LPp+4PdGhiMPsDF5uK4hqinifX7ZwErwD6HoJlBsbTNOT2koCDGw2O8SG/Q8UT9oa ut3hHWl8BC8lncyZA6jg6vyaEvYg6HVwg0tZNN1qv6yfOr6tKCTCdByEXptgSFozrtcT mrnQ== 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=PO8c2GpUnkcIMZf+dhkLvfSIDR0HjPiBPLcZJ0esWC0=; b=KKOMzjgtOIUnJUxPJAzWZDgnXV1dr200i8n8N1SKOSui39uorqplKSPaYii4Gd1MaX 4FtLnsEGGaf1C+n6GaZto/y/bW6Wfs0GzK28cc9xtM/PcHOMb+3aHwxpm6My/BqFapLR QdMBPv2xjvlJ0ptOiA9GD0TnpMOiVuoG1uBE9Yl4wguGQ/bogITGyObS6dIIeaaR8iGO 2rFx4lfvw9yetkVE8SORa3osQ9VUgFQS+JFr8rjnmGsvF4q+43dLyeMm39e4neAwOdsC JnhmjoY0l0CEJ/b6eg3RKz/orZDlraJR1tHJrPgOCboeY9YNFhHmghJopt19UCAl3QgA 2gMA== X-Gm-Message-State: AKS2vOza+xoB03SATp/hZQRm3n+1jdX6TfiD/ddGYcp5Rf9msxAT8Nvc 43ISglvhp3rbS+im0fBVAVJNekXgxg8s X-Received: by 10.107.170.213 with SMTP id g82mr35005758ioj.148.1497282527787; Mon, 12 Jun 2017 08:48:47 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Mon, 12 Jun 2017 08:48:47 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: <20170612154745.6094931.30709.27134@gmail.com> References: <20170612152808.6094931.74364.27128@gmail.com> <20170612154614.6094931.61931.27132@gmail.com> <20170612154745.6094931.30709.27134@gmail.com> From: Warner Losh Date: Mon, 12 Jun 2017 09:48:47 -0600 X-Google-Sender-Auth: mBqIJ4bRc8Q6Td_8ZZzYmo8NBQk Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Russell Haley Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.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: Mon, 12 Jun 2017 15:48:48 -0000 Me too: offence &=3D ~(TAKEN | INTENDED); :) On Mon, Jun 12, 2017 at 9:47 AM, Russell Haley wrote= : > Ha ha I should have used a bitwise or in that. > > Sent from my BlackBerry 10 smartphone on the Virgin Mobile network. > *From: *Russell Haley > *Sent: *Monday, June 12, 2017 8:46 AM > *To: *Warner Losh > *Cc: *freebsd-arm@freebsd.org > *Subject: *Re: Creating armv7 MACHINE_ARCH > > No offense meant, no offense take: glad for a passionate answer! > > Russ > > Sent from my BlackBerry 10 smartphone on the Virgin Mobile network. > *From: *Warner Losh > *Sent: *Monday, June 12, 2017 8:39 AM > *To: *Russell Haley > *Cc: *freebsd-arm@freebsd.org > *Subject: *Re: Creating armv7 MACHINE_ARCH > > Clearly, we woke up one day and realized Ian was right? And he's only bee= n > saying it since pre R11 since that was the first release that supported i= t. > There was no armv6 support in 10. Ask a snarky question, get a snarky > answer... > > What's changed is that the port has gone from being mainly used by people > that had an rpi that supported a bunch of other platforms (including Ian'= s > iMX6) to a port that's used primarily by armv7 machines (including the > rpi2) that also happens to support the rpi (which is the only !armv7 > platform). When Ian started saying it, rpi was one of the better supporte= d > platforms as well. Now with all the Allwinner support, improved iMX6 > support, and the rpi2 being armv7, we are now in a situation where most > users and most of the good support is on that platform. What's also chang= ed > is Andrew's work on having a GENERIC kernel. We'd have a GENERIC one for > ARMv6 too: It's the RPI config :). > > Plus, we aren't quite doing what Ian wanted. He wanted a full rename. The > proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to rename = or > remove armv6. Sadly, that will still be there since the RPI foundation > keeps finding new ways to repackage the rpi into new boards that are just > too cheap to ignore. > > Warner > > On Mon, Jun 12, 2017 at 9:28 AM, Russell Haley > wrote: > >> Sorry for the top post. >> >> Hasn't Ian Lapore been saying this since pre R10?=E2=80=8E I seems to re= member >> people doing backflips to get around this=E2=80=8E heading up to that re= lease and >> it was considered to much effort. Can I ask what has changed? >> >> Russ >> >> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network. >> Original Message >> From: Warner Losh >> Sent: Thursday, June 8, 2017 1:27 PM >> To: freebsd-arm@freebsd.org >> Subject: Creating armv7 MACHINE_ARCH >> >> While the kernel doesn't really need an armv7 support, there will be a >> better match to other systems if we create a armv7 MACHINE_ARCH. This wi= ll >> be in addition to the armv6 MACHINE_ARCH we have today. This will allow = us >> to create a package set optimized for armv7 as well as armv6. While it i= s >> true the RPI 1 is the only system that needs armv6 binaries, it's quite >> popular and the Raspberry Pi folks keep creating new variants with the >> same >> chip. It would also let us get the package stuff spun up and working >> before >> we mess with armv6. >> >> This would also separate the fate of armv6 and armv7 support at a later >> time, but the weak consensus I've heard appears to be that the time isn'= t >> yet right to discuss retiring armv6 support... >> >> 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 Mon Jun 12 17:43: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 40C3CC091F9 for ; Mon, 12 Jun 2017 17:43:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-174.reflexion.net [208.70.211.174]) (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 E700477CCD for ; Mon, 12 Jun 2017 17:43:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31551 invoked from network); 12 Jun 2017 17:36:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 Jun 2017 17:36:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 12 Jun 2017 13:36:42 -0400 (EDT) Received: (qmail 18969 invoked from network); 12 Jun 2017 17:36:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Jun 2017 17:36:42 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6993BEC9296; Mon, 12 Jun 2017 10:36:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Creating armv7 MACHINE_ARCH From: Mark Millard In-Reply-To: Date: Mon, 12 Jun 2017 10:36:40 -0700 Cc: Russell Haley , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170612152808.6094931.74364.27128@gmail.com> To: Warner Losh 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, 12 Jun 2017 17:43:24 -0000 On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: > . . . >=20 > Plus, we aren't quite doing what Ian wanted. He wanted a full rename. = The > proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to = rename or > remove armv6. Sadly, that will still be there since the RPI foundation > keeps finding new ways to repackage the rpi into new boards that are = just > too cheap to ignore. On 2017-Jun-12, at 6:59 AM, Andrew Turner wrote: > I like this. My understanding is adding armv7 would also fix many of = the currently broken ports that assume they are being built for armv7 as = many Linux distros target ARMv7+. >=20 > It should also be noted the GENERIC kernel is likely to only ever = target ARMv7+ even without an armv7 TARGET_ARCH. Hopefully the choices related to TARGET and TARGET_ARCH for armv7 end up identifying the context to port builds so that many would just automatically do the right thing. As for GENERIC: powerpc has. . . TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc and GENERIC TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 and GENERIC64 So there is precedent for more than one GENERIC* for a family, with which one being appropriate being based on TARGET_ARCH. For powerpc TARGET=3Dpowerpc implicitly uses TARGET_ARCH=3Dpowerpc when TARGET_ARCH is not specified (if I remember right). Which should be the default for armv6 vs. armv7 might go the other direction (TARGET_ARCH=3Darmv7 by default). Side note: A caution about talking about "rpi2" as an example. . . Raspberry Pi 2 Model B V1.2 is Cortex-A53 based (so arm64/aarch64). (A BCM2837, not a BCM2836.) This dates about to something like 2014 based on the pictures showing the (c) notice on the boards. V1.1 and before were armv7 (BCM2836) based. Unless a kernel and world are made that can also configure/handle a Cortex-A53 in a armv7-like manor there will be two different GENERIC builds in order to span the "rpi2" family, based on just V1.2+ vs. V1.1 and before. (A single, modern distribution of the official Raspbian software for the rpi2 does support all the V1.x boards if I understand right.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Jun 12 19:16:50 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 0C582C0A8B5 for ; Mon, 12 Jun 2017 19:16:50 +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 7D2EB7A6A2 for ; Mon, 12 Jun 2017 19:16:49 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id m77so31837258lfe.0 for ; Mon, 12 Jun 2017 12:16:49 -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=Y/ie2/YgrADF52hSHf0nsdoNfnqQGM6PFeAVG130urM=; b=NgeBbLFk3zdQD81r6GIzs+z+nrc7s+kBlfYoNqQvLL/NxrKYczF07KpZFYE43pq78d UKHome1tzaYSjIFIsY+dmRCtR+XbbB/B8agW2Rx/hSQXRv0AmK+tx5jLJOs9bfU9IRPB mbjESyfqmio3CSohuFKcR+HjIpMyAMipM64iRA6HvT2vcY55p5ufYfuXHTRc3FqU2fNA Lyk12BsZQiT+hYDepQMWge2YHpoiUhTpQDaKbEvgGLAXshmqaUz7+a6bQ6D4HshxLIBt qQmjEo1iLy3wOlDNGaeqUtZ0sn+XzKp7r+LMQJq/RQalDHOMLFRBQLZOf/CUCQmtfSPK 0wyg== 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=Y/ie2/YgrADF52hSHf0nsdoNfnqQGM6PFeAVG130urM=; b=OHOkFEYkxztIGIbVCj3DKzNjGwo4ryZ/qlrSI4yqQQEY3O5V4Fq+tZEl+lVuCyjLsh xOHQ5W1RxbPfHgP9ekVNNQoq4njP6IiSJ5kI/ZDH0cWuQSq9FqK8aT3TUTiIf9W9uWYJ JiBg9oVuppNHOsLBGhiytPkxPlXMIoIftQbFTN9/GfdfU91a/wu4atQeQ971d7+6SIFJ u7izbCy+tlR5VZhNoL0GxV79oAt8hDNlGiJ3SY+jN7Noi4l9JfM7Q96mL1zpD2RozuyG lTPLxMQMKSs5mrolazH5GFzrUQribSgR1wXBl1zMEvL+IYSR3Hbv6HTE2xPsgSgnhTkE 0ztA== X-Gm-Message-State: AODbwcBbFC/LLvgdHRjRW6Vncx+FZU5I5xH1amFXC35QXYTymSzGUI4l jgGKeeq16egjQ/vX/kYqsZLeeNv3lc+d X-Received: by 10.46.83.23 with SMTP id h23mr8472952ljb.70.1497295007710; Mon, 12 Jun 2017 12:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.82.196 with HTTP; Mon, 12 Jun 2017 12:16:46 -0700 (PDT) In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> From: Russell Haley Date: Mon, 12 Jun 2017 12:16:46 -0700 Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Mark Millard Cc: Warner Losh , "freebsd-arm@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: Mon, 12 Jun 2017 19:16:50 -0000 On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard wrote: > > On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: > >> . . . >> >> Plus, we aren't quite doing what Ian wanted. He wanted a full rename. The >> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to rename or >> remove armv6. Sadly, that will still be there since the RPI foundation >> keeps finding new ways to repackage the rpi into new boards that are just >> too cheap to ignore. > > On 2017-Jun-12, at 6:59 AM, Andrew Turner wrote: > >> I like this. My understanding is adding armv7 would also fix many of the currently broken ports that assume they are being built for armv7 as many Linux distros target ARMv7+. >> >> It should also be noted the GENERIC kernel is likely to only ever target ARMv7+ even without an armv7 TARGET_ARCH. > > > Hopefully the choices related to TARGET and TARGET_ARCH > for armv7 end up identifying the context to port builds > so that many would just automatically do the right thing. > > > As for GENERIC: > > powerpc has. . . > > TARGET=powerpc TARGET_ARCH=powerpc and GENERIC > TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 > > So there is precedent for more than one GENERIC* > for a family, with which one being appropriate > being based on TARGET_ARCH. > > For powerpc TARGET=powerpc implicitly uses > TARGET_ARCH=powerpc when TARGET_ARCH is not > specified (if I remember right). Which should > be the default for armv6 vs. armv7 might go > the other direction (TARGET_ARCH=armv7 by > default). > > > Side note: > > A caution about talking about "rpi2" as > an example. . . > > Raspberry Pi 2 Model B V1.2 is Cortex-A53 based > (so arm64/aarch64). (A BCM2837, not a BCM2836.) > This dates about to something like 2014 based > on the pictures showing the (c) notice on the > boards. > > V1.1 and before were armv7 (BCM2836) based. > > Unless a kernel and world are made that can > also configure/handle a Cortex-A53 in a > armv7-like manor there will be two different > GENERIC builds in order to span the "rpi2" > family, based on just V1.2+ vs. V1.1 and > before. > > (A single, modern distribution of the official > Raspbian software for the rpi2 does support > all the V1.x boards if I understand right.) I am confused. I don't see any documentation about Raspbian supporting 64 bit? >From Arm at https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php: "The Cortex-A53 supports the full ARMv8-A architecture. It not only runs 64-bit applications also seamlessly and efficiently runs legacy ARM 32-bit applications." I assume that means it handles armv7-A without issue? (In fact, many on this board know it does) >From the outside it looks like "we" are causing headaches by tracking architecture (32/64) instead of instruction set (armv7 vs armv8)? Just some spitballing: When it comes to ARM would it be advantageous to do: TARGET=arm TARGET_ARCH=armv8 #defaults to ARCH=32 or the real setting that I didn't pull from my derriere. or TARGET=arm TARGET_ARCH=armv8 ARCH=64 OR conversly add an "instruction" variable? In my very novice view, we're not really talking about architectures, we are talking about the different instruction sets and the concepts are still being blurred together. https://en.wikipedia.org/wiki/ARM_architecture#Architectural_licence Russ From owner-freebsd-arm@freebsd.org Mon Jun 12 20:07:18 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 62866C31E49 for ; Mon, 12 Jun 2017 20:07:18 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 E2EE87CA39 for ; Mon, 12 Jun 2017 20:07:17 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x244.google.com with SMTP id v20so10359932lfa.2 for ; Mon, 12 Jun 2017 13:07:17 -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=pXmDSsTqxqS3NN9noVaQo4Nfk0VrD5xY5jzBd+GcQag=; b=GoC3drJwl11kfSbbyOeG9lMcgkI0KqTI6yWBvkXB29noTSypVoHnKAPgfufvCL9aFN XVcRj9MG70CF8ptQrl/cSGthnY3FeNPyLvFE0HQWD5HUSHLKTLDtI05MeyLzFbK/gP9D MvgAavy1jMa1uFD+w+mDSTcLsgp3x26fkC6icndSmAaRZrbzSlQzicTp3ES2mrHarVYC vMIlec1DQioeTraMbyoET8geXU+a6Oxs7fzan5DTzGPP12FT3FNXVt7MPtXaa0H5U6ff 7cDcgiKiMN4Vf7afDnACeTLKfNcAfrS5mcNwLFDl92otdcgAYajzZ3VOZxwhSXUueWxc fC0Q== 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=pXmDSsTqxqS3NN9noVaQo4Nfk0VrD5xY5jzBd+GcQag=; b=EDOfL8SBvVaUu9B38qGSfv1B11sCDy1zzRwi0vKTxG5QWTLJS1XaLN0cangmaWAnvc hzF3j31owc2gE/IUHBKdbTNJ25FwOlaLDTOO440RV+iivEP6iih9UhaDWxwwPUWKXmy8 P/Mn5Nrbsx43FrGv5t5BeUpC44kvpt2DiaTrTGp6/p+//OMrKLrShiYnQRVUusmE5W50 Ghuisu/VWFz/yyo+/Er+Dzs+quvOxiv9keqryGJlm+gmLed4rQKfxkryMDbiv7I7KHWt OCpcbRlgMqBNRBE5pEijD1kWNMMGhEk+cwnOsvUJl2wVt6EiREzlFVQsARnZHPbtqWji dG2A== X-Gm-Message-State: AODbwcBt6GLjNeDq5OSxxVHN9KjoC0wsXhneqDTrKNFadnAJ/2bU0ubb 9N3aTYXJPNhXUloD4W5N8JJ8bP1FXA== X-Received: by 10.25.149.4 with SMTP id x4mr7624543lfd.136.1497298036060; Mon, 12 Jun 2017 13:07:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.82.196 with HTTP; Mon, 12 Jun 2017 13:07:15 -0700 (PDT) In-Reply-To: <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> From: Russell Haley Date: Mon, 12 Jun 2017 13:07:15 -0700 Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Mark Millard Cc: Warner Losh , "freebsd-arm@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: Mon, 12 Jun 2017 20:07:18 -0000 On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard wrote: > On 2017-Jun-12, at 12:16 PM, Russell Haley wrote: > >> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard wrote: >>> >>> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: >>> >>>> . . . >>>> >>>> Plus, we aren't quite doing what Ian wanted. He wanted a full rename. The >>>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to rename or >>>> remove armv6. Sadly, that will still be there since the RPI foundation >>>> keeps finding new ways to repackage the rpi into new boards that are just >>>> too cheap to ignore. >>> >>> On 2017-Jun-12, at 6:59 AM, Andrew Turner wrote: >>> >>>> I like this. My understanding is adding armv7 would also fix many of the currently broken ports that assume they are being built for armv7 as many Linux distros target ARMv7+. >>>> >>>> It should also be noted the GENERIC kernel is likely to only ever target ARMv7+ even without an armv7 TARGET_ARCH. >>> >>> >>> Hopefully the choices related to TARGET and TARGET_ARCH >>> for armv7 end up identifying the context to port builds >>> so that many would just automatically do the right thing. >>> >>> >>> As for GENERIC: >>> >>> powerpc has. . . >>> >>> TARGET=powerpc TARGET_ARCH=powerpc and GENERIC >>> TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 >>> >>> So there is precedent for more than one GENERIC* >>> for a family, with which one being appropriate >>> being based on TARGET_ARCH. >>> >>> For powerpc TARGET=powerpc implicitly uses >>> TARGET_ARCH=powerpc when TARGET_ARCH is not >>> specified (if I remember right). Which should >>> be the default for armv6 vs. armv7 might go >>> the other direction (TARGET_ARCH=armv7 by >>> default). >>> >>> >>> Side note: >>> >>> A caution about talking about "rpi2" as >>> an example. . . >>> >>> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based >>> (so arm64/aarch64). (A BCM2837, not a BCM2836.) >>> This dates about to something like 2014 based >>> on the pictures showing the (c) notice on the >>> boards. >>> >>> V1.1 and before were armv7 (BCM2836) based. >>> >>> Unless a kernel and world are made that can >>> also configure/handle a Cortex-A53 in a >>> armv7-like manor there will be two different >>> GENERIC builds in order to span the "rpi2" >>> family, based on just V1.2+ vs. V1.1 and >>> before. >>> >>> (A single, modern distribution of the official >>> Raspbian software for the rpi2 does support >>> all the V1.x boards if I understand right.) >> >> I am confused. I don't see any documentation about Raspbian supporting 64 bit? > > 64-bit Cortex-A53's can be configure to operate in a > 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 > and for RPI3. > > Raspian does not (yet?) support a 64-bit mode (AArch64). > > The Cortex-A53 can support either. As I understand it > is possible for an OS to allow a user processes to be > one or the other, different processes using the different > modes. That does not mean that all operating systems > bother to. > > If I remember right the official Ubuntu for an ODroid-C2 > allows both AArch64 and AArch32 user programs (and > so processes, with shared library types tracking). > >> From Arm at https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php: >> "The Cortex-A53 supports the full ARMv8-A architecture. It not only >> runs 64-bit applications also seamlessly and efficiently runs legacy >> ARM 32-bit applications." >> >> I assume that means it handles armv7-A without issue? (In fact, many >> on this board know it does) > > I've not gone through the details but targeting AArch32 > probably means targeting a subset of armv7. Or may be > to support both requires targeting a common subset of both. > (My guess is that AArch32 is the definition of a common > subset for 32-bit, at least for user processes.) > > Raspian targets just AArch32 on armv7 and Cortex-A53 > (user space). (If I've got the definition of AArch32 > right: otherwise a common subset.) > > FreeBSD targets armv7 and AArch64 separately (via > separate GENERIC kernels). I'm not aware of FreeBSD > targeting AArch32 at all on cores capable of AArch64. > FreeBSD possibly does not restrict itself to AArch32 > (user processes) on armv7 if AArch32 is really a > subset. I thought all 64 bit Arm instructions are defined in armv8? Russ From owner-freebsd-arm@freebsd.org Mon Jun 12 20:07:19 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 9EE9CC31E4F for ; Mon, 12 Jun 2017 20:07:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-175.reflexion.net [208.70.211.175]) (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 6306C7CA45 for ; Mon, 12 Jun 2017 20:07:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28367 invoked from network); 12 Jun 2017 20:00:37 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Jun 2017 20:00:37 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 12 Jun 2017 16:00:37 -0400 (EDT) Received: (qmail 23217 invoked from network); 12 Jun 2017 20:00:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Jun 2017 20:00:37 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 97457EC851C; Mon, 12 Jun 2017 13:00:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Creating armv7 MACHINE_ARCH From: Mark Millard In-Reply-To: Date: Mon, 12 Jun 2017 13:00:36 -0700 Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> References: <20170612152808.6094931.74364.27128@gmail.com> To: Russell Haley 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, 12 Jun 2017 20:07:19 -0000 On 2017-Jun-12, at 12:16 PM, Russell Haley wrote: > On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard = wrote: >>=20 >> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: >>=20 >>> . . . >>>=20 >>> Plus, we aren't quite doing what Ian wanted. He wanted a full = rename. The >>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to = rename or >>> remove armv6. Sadly, that will still be there since the RPI = foundation >>> keeps finding new ways to repackage the rpi into new boards that are = just >>> too cheap to ignore. >>=20 >> On 2017-Jun-12, at 6:59 AM, Andrew Turner = wrote: >>=20 >>> I like this. My understanding is adding armv7 would also fix many of = the currently broken ports that assume they are being built for armv7 as = many Linux distros target ARMv7+. >>>=20 >>> It should also be noted the GENERIC kernel is likely to only ever = target ARMv7+ even without an armv7 TARGET_ARCH. >>=20 >>=20 >> Hopefully the choices related to TARGET and TARGET_ARCH >> for armv7 end up identifying the context to port builds >> so that many would just automatically do the right thing. >>=20 >>=20 >> As for GENERIC: >>=20 >> powerpc has. . . >>=20 >> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc and GENERIC >> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 and GENERIC64 >>=20 >> So there is precedent for more than one GENERIC* >> for a family, with which one being appropriate >> being based on TARGET_ARCH. >>=20 >> For powerpc TARGET=3Dpowerpc implicitly uses >> TARGET_ARCH=3Dpowerpc when TARGET_ARCH is not >> specified (if I remember right). Which should >> be the default for armv6 vs. armv7 might go >> the other direction (TARGET_ARCH=3Darmv7 by >> default). >>=20 >>=20 >> Side note: >>=20 >> A caution about talking about "rpi2" as >> an example. . . >>=20 >> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based >> (so arm64/aarch64). (A BCM2837, not a BCM2836.) >> This dates about to something like 2014 based >> on the pictures showing the (c) notice on the >> boards. >>=20 >> V1.1 and before were armv7 (BCM2836) based. >>=20 >> Unless a kernel and world are made that can >> also configure/handle a Cortex-A53 in a >> armv7-like manor there will be two different >> GENERIC builds in order to span the "rpi2" >> family, based on just V1.2+ vs. V1.1 and >> before. >>=20 >> (A single, modern distribution of the official >> Raspbian software for the rpi2 does support >> all the V1.x boards if I understand right.) >=20 > I am confused. I don't see any documentation about Raspbian supporting = 64 bit? 64-bit Cortex-A53's can be configure to operate in a 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 and for RPI3. Raspian does not (yet?) support a 64-bit mode (AArch64). The Cortex-A53 can support either. As I understand it is possible for an OS to allow a user processes to be one or the other, different processes using the different modes. That does not mean that all operating systems bother to. If I remember right the official Ubuntu for an ODroid-C2 allows both AArch64 and AArch32 user programs (and so processes, with shared library types tracking). > =46rom Arm at = https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php:= > "The Cortex-A53 supports the full ARMv8-A architecture. It not only > runs 64-bit applications also seamlessly and efficiently runs legacy > ARM 32-bit applications." >=20 > I assume that means it handles armv7-A without issue? (In fact, many > on this board know it does) I've not gone through the details but targeting AArch32 probably means targeting a subset of armv7. Or may be to support both requires targeting a common subset of both. (My guess is that AArch32 is the definition of a common subset for 32-bit, at least for user processes.) Raspian targets just AArch32 on armv7 and Cortex-A53 (user space). (If I've got the definition of AArch32 right: otherwise a common subset.) FreeBSD targets armv7 and AArch64 separately (via=20 separate GENERIC kernels). I'm not aware of FreeBSD targeting AArch32 at all on cores capable of AArch64. FreeBSD possibly does not restrict itself to AArch32 (user processes) on armv7 if AArch32 is really a subset. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Jun 12 20:35: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 1CF4EC77955 for ; Mon, 12 Jun 2017 20:35:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-175.reflexion.net [208.70.211.175]) (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 D129B7DFFC for ; Mon, 12 Jun 2017 20:35:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16222 invoked from network); 12 Jun 2017 20:35:11 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Jun 2017 20:35:11 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 12 Jun 2017 16:35:11 -0400 (EDT) Received: (qmail 11882 invoked from network); 12 Jun 2017 20:35:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Jun 2017 20:35:10 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 296EFEC851C; Mon, 12 Jun 2017 13:35:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Creating armv7 MACHINE_ARCH From: Mark Millard In-Reply-To: <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> Date: Mon, 12 Jun 2017 13:35:09 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> To: Russell Haley 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, 12 Jun 2017 20:35:13 -0000 On 2017-Jun-12, at 1:00 PM, Mark Millard wrote: > On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard = wrote: >> On 2017-Jun-12, at 12:16 PM, Russell Haley = wrote: >>=20 >>> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard wrote: >>>>=20 >>>> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: >>>>=20 >>>>> . . . >>>>>=20 >>>>> Plus, we aren't quite doing what Ian wanted. He wanted a full = rename. The >>>>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to = rename or >>>>> remove armv6. Sadly, that will still be there since the RPI = foundation >>>>> keeps finding new ways to repackage the rpi into new boards that = are just >>>>> too cheap to ignore. >>>>=20 >>>> On 2017-Jun-12, at 6:59 AM, Andrew Turner = wrote: >>>>=20 >>>>> I like this. My understanding is adding armv7 would also fix many = of the currently broken ports that assume they are being built for armv7 = as many Linux distros target ARMv7+. >>>>>=20 >>>>> It should also be noted the GENERIC kernel is likely to only ever = target ARMv7+ even without an armv7 TARGET_ARCH. >>>>=20 >>>>=20 >>>> Hopefully the choices related to TARGET and TARGET_ARCH >>>> for armv7 end up identifying the context to port builds >>>> so that many would just automatically do the right thing. >>>>=20 >>>>=20 >>>> As for GENERIC: >>>>=20 >>>> powerpc has. . . >>>>=20 >>>> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc and GENERIC >>>> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 and GENERIC64 >>>>=20 >>>> So there is precedent for more than one GENERIC* >>>> for a family, with which one being appropriate >>>> being based on TARGET_ARCH. >>>>=20 >>>> For powerpc TARGET=3Dpowerpc implicitly uses >>>> TARGET_ARCH=3Dpowerpc when TARGET_ARCH is not >>>> specified (if I remember right). Which should >>>> be the default for armv6 vs. armv7 might go >>>> the other direction (TARGET_ARCH=3Darmv7 by >>>> default). >>>>=20 >>>>=20 >>>> Side note: >>>>=20 >>>> A caution about talking about "rpi2" as >>>> an example. . . >>>>=20 >>>> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based >>>> (so arm64/aarch64). (A BCM2837, not a BCM2836.) >>>> This dates about to something like 2014 based >>>> on the pictures showing the (c) notice on the >>>> boards. >>>>=20 >>>> V1.1 and before were armv7 (BCM2836) based. >>>>=20 >>>> Unless a kernel and world are made that can >>>> also configure/handle a Cortex-A53 in a >>>> armv7-like manor there will be two different >>>> GENERIC builds in order to span the "rpi2" >>>> family, based on just V1.2+ vs. V1.1 and >>>> before. >>>>=20 >>>> (A single, modern distribution of the official >>>> Raspbian software for the rpi2 does support >>>> all the V1.x boards if I understand right.) >>>=20 >>> I am confused. I don't see any documentation about Raspbian = supporting 64 bit? >>=20 >> 64-bit Cortex-A53's can be configure to operate in a >> 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 >> and for RPI3. >>=20 >> Raspian does not (yet?) support a 64-bit mode (AArch64). >>=20 >> The Cortex-A53 can support either. As I understand it >> is possible for an OS to allow a user processes to be >> one or the other, different processes using the different >> modes. That does not mean that all operating systems >> bother to. >>=20 >> If I remember right the official Ubuntu for an ODroid-C2 >> allows both AArch64 and AArch32 user programs (and >> so processes, with shared library types tracking). >>=20 >>> =46rom Arm at = https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php:= >>> "The Cortex-A53 supports the full ARMv8-A architecture. It not only >>> runs 64-bit applications also seamlessly and efficiently runs legacy >>> ARM 32-bit applications." >>>=20 >>> I assume that means it handles armv7-A without issue? (In fact, many >>> on this board know it does) >>=20 >> I've not gone through the details but targeting AArch32 >> probably means targeting a subset of armv7. Or may be >> to support both requires targeting a common subset of both. >> (My guess is that AArch32 is the definition of a common >> subset for 32-bit, at least for user processes.) >>=20 >> Raspian targets just AArch32 on armv7 and Cortex-A53 >> (user space). (If I've got the definition of AArch32 >> right: otherwise a common subset.) >>=20 >> FreeBSD targets armv7 and AArch64 separately (via >> separate GENERIC kernels). I'm not aware of FreeBSD >> targeting AArch32 at all on cores capable of AArch64. >> FreeBSD possibly does not restrict itself to AArch32 >> (user processes) on armv7 if AArch32 is really a >> subset. >=20 > I thought all 64 bit Arm instructions are defined in armv8? (I assume you are not trying to indicate armv8.1, armv8.2 and such. Cortex-A53 is older than those and so does not have the newer things involved.) That Cortex-A53 allows armv8 64-bit arm code is not in dispute. But the operating system in involved in setting up what will actually work based on how it configures things and operates. Much of this is the kernel. Cortex-A53 also supports AArch32, i.e., 32 bit instructions. So that the 64-bit instructions all being there does not of itself prevent using a 32-bit mode instead. (The kernel likely has to deal with more specifics of processor variations than user code does not. My notes are really about the user process model, not the all the kernel details.) Raspian deals with armv7's that have no 64-bit support and with Cortex-A53's that do. It presents a user-process model that is 32-bit only, even on Cortex-A53's that allow for 64-bit (but do not required user programs to be AArch64 code). Ubuntu for ODroid-C2 does not deal with armv7's but does allow both 64-bit (AArch64) and 32-bit (AArch32) user processes as I remember, on its Cortex-A53's. FreeBSD armv7 does not support Cortext-A53 or anything that allows 64-bit (that allows AArch64). This is a kernel level issue. FreeBSD aarch64 does not support having AArch32 user processes. Nor does its kernel support processors that do not support aarch64 (so it does not support armv7). These are simply examples of different choices about what combinations of the technical possibilities to put effort into supporting in the kernels (and possibly elsewhere). None of the alternatives is automatic. None are independent of software choices that must be made by each operating system. (I'm not one of the people working on the kernels. If they tell you that I'm wrong abut something: Believe them.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Jun 12 21:00: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 8F1DFC78145 for ; Mon, 12 Jun 2017 21:00:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 5C49A7EFFC for ; Mon, 12 Jun 2017 21:00:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id t87so42452142ioe.0 for ; Mon, 12 Jun 2017 14:00:46 -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=CkENAdhaKtd7LUeP3D7kYo80tdSooQgb+KQVWAW8VnQ=; b=gBWvqF/SRACI6ioMsMYeacRfyPfUqmLikKRg4Mfwpd6gExJ47M777SnsXvgWgKBoEa 66nJfwqfeAHQ1unmOOEtxOvSZ+lhc3vELkb+0qkRSMZq/YGjYiJ+wZMY3CNg6mq4xI7T pJNjwA49vDhPWlt1wEmRHxBPsL/vXTNfpcxsjUsSapSODZE6mSGUGwyvvbtaLeBB+xaK M4SvmStnqzk1fajFctSk8f8vyrD79nMXhAhAiFGiaQLLASEoN1Ets9c4AtVRKXgnRJis ml+UAjXF9PsDGT8TmslduT2f4pnb0lRafZN/pphw60lbnOXvMsiODnEPez0VXPNHE41h aYhg== 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=CkENAdhaKtd7LUeP3D7kYo80tdSooQgb+KQVWAW8VnQ=; b=qE8bAVeUTTgivBhuv7qWyN9NQxkHRFXBPeUfjViw76wuFVZ4egQdXdSpHXmkvtKmcM iH8nBWB+6AFB8OO5Ciltr30fhAqrFREaks0voZLPE5rppSti7WmYpL5VMYHoL6YDrBXm kI1aKBLBjk95TxFML7At1XPVKSNqNjxbIQOSx8KD+KQX2RmOUYSAOr8pI4eiMNLTvJMN lLVEdhpt6xlGjLWIix9A5BT92pruVepruoXWy+Fv4wDAajmDhJ0WThf8hxEPI1hI8aPj 8ODL2k/gnmbz9xgfgSraPphPRGMSTqL9vtAGXIB1xOuLAoGqZJmbq52Nyx4odyuzNMjS b0kg== X-Gm-Message-State: AODbwcD0yEG1uWkypWyhpbbk8JDs4pO98lG6Yt+V4y1lyx/EGVv6Rg4r oVi0I485HMowkomZButT+Is0xK9Vo0We X-Received: by 10.107.197.68 with SMTP id v65mr20525907iof.218.1497301244412; Mon, 12 Jun 2017 14:00:44 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Mon, 12 Jun 2017 14:00:43 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> From: Warner Losh Date: Mon, 12 Jun 2017 15:00:43 -0600 X-Google-Sender-Auth: eJA6B5wT3l8UrzR90AwizvD_oNg Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Mark Millard Cc: Russell Haley , "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: Mon, 12 Jun 2017 21:00:46 -0000 On Mon, Jun 12, 2017 at 11:36 AM, Mark Millard wrote: > > On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: > > > . . . > > > > Plus, we aren't quite doing what Ian wanted. He wanted a full rename. The > > proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to rename > or > > remove armv6. Sadly, that will still be there since the RPI foundation > > keeps finding new ways to repackage the rpi into new boards that are just > > too cheap to ignore. > > On 2017-Jun-12, at 6:59 AM, Andrew Turner wrote: > > > I like this. My understanding is adding armv7 would also fix many of the > currently broken ports that assume they are being built for armv7 as many > Linux distros target ARMv7+. > > > > It should also be noted the GENERIC kernel is likely to only ever target > ARMv7+ even without an armv7 TARGET_ARCH. > > > Hopefully the choices related to TARGET and TARGET_ARCH > for armv7 end up identifying the context to port builds > so that many would just automatically do the right thing. > Yes. That's a prereq for having a new TARGET_ARCH support: relevant kernels must identify themselves correctly so that ports build correctly. > As for GENERIC: > > powerpc has. . . > > TARGET=powerpc TARGET_ARCH=powerpc and GENERIC > TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 > > So there is precedent for more than one GENERIC* > for a family, with which one being appropriate > being based on TARGET_ARCH. > > For powerpc TARGET=powerpc implicitly uses > TARGET_ARCH=powerpc when TARGET_ARCH is not > specified (if I remember right). Which should > be the default for armv6 vs. armv7 might go > the other direction (TARGET_ARCH=armv7 by > default). > > > Side note: > > A caution about talking about "rpi2" as > an example. . . > > Raspberry Pi 2 Model B V1.2 is Cortex-A53 based > (so arm64/aarch64). (A BCM2837, not a BCM2836.) > This dates about to something like 2014 based > on the pictures showing the (c) notice on the > boards. > > V1.1 and before were armv7 (BCM2836) based. > > Unless a kernel and world are made that can > also configure/handle a Cortex-A53 in a > armv7-like manor there will be two different > GENERIC builds in order to span the "rpi2" > family, based on just V1.2+ vs. V1.1 and > before. > > (A single, modern distribution of the official > Raspbian software for the rpi2 does support > all the V1.x boards if I understand right.) Yea, that's crazy on their part. I don't know if we support the 64-bit CPU in 32-bit mode at all. But that's an orthogonal issue to this discussion. Warner From owner-freebsd-arm@freebsd.org Mon Jun 12 21:07: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 C8CDFC785F2 for ; Mon, 12 Jun 2017 21:07:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 8A1087F6BE for ; Mon, 12 Jun 2017 21:07:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id m47so27053858iti.0 for ; Mon, 12 Jun 2017 14:07:46 -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=+qtZmbh60SM8vpdkGKMy5IpCFdBSXLAvybRaCkCnWtI=; b=EVy5ses4+hgTqMJX3PONF/jVwmRWedKsgGpt1BYjXbjNGau3e4KrBxXtCKbCg7dTgG Ib6ilGmlZPAfTxonwmFZko8EQcawqOFJgdv47aLxmat/c2GJr8gpw7E4IjumvkW2U56d nWjfecxGmb/CyxKQNMRU0DssB3AanyHjt37V92mdHxtt1rXGIJzXx5fJWCXTwjecLH5m 2czqXXrMY5wIZTIFsOoj5C5U8T+Q2JloGpTuAKhO+RgDRI6CprcUP/kxX8vNEHcf2INc 4cND+n5mI4ABnUfVX968ckKl8JKgNJpJMSKZV/vWC7gaB/H/boj1MWSG6y+ZfLuo+Tz9 I/hw== 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=+qtZmbh60SM8vpdkGKMy5IpCFdBSXLAvybRaCkCnWtI=; b=HQCbFP42NH1raooO0Iesml7oq6zTLmtI+KDqmaWx2FUs6Tm8AZWhM50hRei4QQ4OGs D4DU16NIdVXiT117t07CPjCEVpVo1Z/7SJ0pGKw+TxDu/wI1EII0ktGql+puMheYnnJA +ot3YOZzpmLxn3acDxOZShWFpqC0sshlVDBLZMC6+BergYVEm2/gU9nWwyWY5kLfFiJs uGHAysgxK/j4FJcBsSMIaIjF9GVZwu/eG0Nb3s/D7cEjRXDxveXup7aa1VEhm/cnxmkw k2m8FXQtg2HYvSYxfZR9p2TM9m1FPtYA1+PK7gWlLZhPY29S9YnpA7QKm7D0Ze/HuGbY p6Wg== X-Gm-Message-State: AODbwcAb9L2aT61TqWpUM3stJ9vVrwe0Oo3L57m+jwhViR8hYZWQpVpD DJw402JlM6C3yQIMUlJooC5DWH1ohMZE X-Received: by 10.36.83.145 with SMTP id n139mr14078921itb.0.1497301665813; Mon, 12 Jun 2017 14:07:45 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Mon, 12 Jun 2017 14:07:45 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> From: Warner Losh Date: Mon, 12 Jun 2017 15:07:45 -0600 X-Google-Sender-Auth: 58F9S5mxVfW6rPqb4DZ8mcPykps Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Mark Millard Cc: Russell Haley , "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: Mon, 12 Jun 2017 21:07:46 -0000 On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard wrote: > > On 2017-Jun-12, at 1:00 PM, Mark Millard wrote: > > > On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard > wrote: > >> On 2017-Jun-12, at 12:16 PM, Russell Haley > wrote: > >> > >>> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard > wrote: > >>>> > >>>> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: > >>>> > >>>>> . . . > >>>>> > >>>>> Plus, we aren't quite doing what Ian wanted. He wanted a full > rename. The > >>>>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to > rename or > >>>>> remove armv6. Sadly, that will still be there since the RPI > foundation > >>>>> keeps finding new ways to repackage the rpi into new boards that are > just > >>>>> too cheap to ignore. > >>>> > >>>> On 2017-Jun-12, at 6:59 AM, Andrew Turner > wrote: > >>>> > >>>>> I like this. My understanding is adding armv7 would also fix many of > the currently broken ports that assume they are being built for armv7 as > many Linux distros target ARMv7+. > >>>>> > >>>>> It should also be noted the GENERIC kernel is likely to only ever > target ARMv7+ even without an armv7 TARGET_ARCH. > >>>> > >>>> > >>>> Hopefully the choices related to TARGET and TARGET_ARCH > >>>> for armv7 end up identifying the context to port builds > >>>> so that many would just automatically do the right thing. > >>>> > >>>> > >>>> As for GENERIC: > >>>> > >>>> powerpc has. . . > >>>> > >>>> TARGET=powerpc TARGET_ARCH=powerpc and GENERIC > >>>> TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 > >>>> > >>>> So there is precedent for more than one GENERIC* > >>>> for a family, with which one being appropriate > >>>> being based on TARGET_ARCH. > >>>> > >>>> For powerpc TARGET=powerpc implicitly uses > >>>> TARGET_ARCH=powerpc when TARGET_ARCH is not > >>>> specified (if I remember right). Which should > >>>> be the default for armv6 vs. armv7 might go > >>>> the other direction (TARGET_ARCH=armv7 by > >>>> default). > >>>> > >>>> > >>>> Side note: > >>>> > >>>> A caution about talking about "rpi2" as > >>>> an example. . . > >>>> > >>>> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based > >>>> (so arm64/aarch64). (A BCM2837, not a BCM2836.) > >>>> This dates about to something like 2014 based > >>>> on the pictures showing the (c) notice on the > >>>> boards. > >>>> > >>>> V1.1 and before were armv7 (BCM2836) based. > >>>> > >>>> Unless a kernel and world are made that can > >>>> also configure/handle a Cortex-A53 in a > >>>> armv7-like manor there will be two different > >>>> GENERIC builds in order to span the "rpi2" > >>>> family, based on just V1.2+ vs. V1.1 and > >>>> before. > >>>> > >>>> (A single, modern distribution of the official > >>>> Raspbian software for the rpi2 does support > >>>> all the V1.x boards if I understand right.) > >>> > >>> I am confused. I don't see any documentation about Raspbian supporting > 64 bit? > >> > >> 64-bit Cortex-A53's can be configure to operate in a > >> 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 > >> and for RPI3. > >> > >> Raspian does not (yet?) support a 64-bit mode (AArch64). > >> > >> The Cortex-A53 can support either. As I understand it > >> is possible for an OS to allow a user processes to be > >> one or the other, different processes using the different > >> modes. That does not mean that all operating systems > >> bother to. > >> > >> If I remember right the official Ubuntu for an ODroid-C2 > >> allows both AArch64 and AArch32 user programs (and > >> so processes, with shared library types tracking). > >> > >>> From Arm at https://www.arm.com/products/processors/cortex-a/cortex- > a53-processor.php: > >>> "The Cortex-A53 supports the full ARMv8-A architecture. It not only > >>> runs 64-bit applications also seamlessly and efficiently runs legacy > >>> ARM 32-bit applications." > >>> > >>> I assume that means it handles armv7-A without issue? (In fact, many > >>> on this board know it does) > >> > >> I've not gone through the details but targeting AArch32 > >> probably means targeting a subset of armv7. Or may be > >> to support both requires targeting a common subset of both. > >> (My guess is that AArch32 is the definition of a common > >> subset for 32-bit, at least for user processes.) > >> > >> Raspian targets just AArch32 on armv7 and Cortex-A53 > >> (user space). (If I've got the definition of AArch32 > >> right: otherwise a common subset.) > >> > >> FreeBSD targets armv7 and AArch64 separately (via > >> separate GENERIC kernels). I'm not aware of FreeBSD > >> targeting AArch32 at all on cores capable of AArch64. > >> FreeBSD possibly does not restrict itself to AArch32 > >> (user processes) on armv7 if AArch32 is really a > >> subset. > > > > I thought all 64 bit Arm instructions are defined in armv8? > > (I assume you are not trying to indicate armv8.1, armv8.2 > and such. Cortex-A53 is older than those and so does not > have the newer things involved.) > > That Cortex-A53 allows armv8 64-bit arm code is not in > dispute. But the operating system in involved in setting > up what will actually work based on how it configures > things and operates. Much of this is the kernel. > Correct. > Cortex-A53 also supports AArch32, i.e., 32 bit instructions. > So that the 64-bit instructions all being there does not > of itself prevent using a 32-bit mode instead. > > (The kernel likely has to deal with more specifics of > processor variations than user code does not. My notes > are really about the user process model, not the all > the kernel details.) > > Raspian deals with armv7's that have no 64-bit support > and with Cortex-A53's that do. It presents a user-process > model that is 32-bit only, even on Cortex-A53's that allow > for 64-bit (but do not required user programs to be AArch64 > code). > > Ubuntu for ODroid-C2 does not deal with armv7's but does > allow both 64-bit (AArch64) and 32-bit (AArch32) user > processes as I remember, on its Cortex-A53's. > > FreeBSD armv7 does not support Cortext-A53 or anything > that allows 64-bit (that allows AArch64). This is a kernel > level issue. > Not a hugely difficult issue to fix, but one nobody had fixed... > FreeBSD aarch64 does not support having AArch32 user > processes. Nor does its kernel support processors that > do not support aarch64 (so it does not support armv7). > Executing a 32-bit /bin/cat on aarch64 level support exists outside the tree, according to the hallway track at BSDcan, so it will only be a matter of time before compat32 exists there I think. There's a further complication is that the aarch32 unit of aarch64 processors is optional. Not all of them have it, so that can be a problem... IIRC, the early aarch64 targets didn't have this feature... > These are simply examples of different choices about > what combinations of the technical possibilities to > put effort into supporting in the kernels (and > possibly elsewhere). None of the alternatives is > automatic. None are independent of software choices > that must be made by each operating system. > Yes. They all require somebody to be interested in doing the work. Warner From owner-freebsd-arm@freebsd.org Mon Jun 12 23:10: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 27F3CD861BA for ; Mon, 12 Jun 2017 23:10:06 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8471A83867 for ; Mon, 12 Jun 2017 23:10:05 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id p189so59239322lfe.2 for ; Mon, 12 Jun 2017 16:10:05 -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=GryNigS81pQC9DneEUpBiIDE4u8Z8xVSiawX2UQFAN8=; b=Z7mqkhAUcgMBeROjzAmuZzJ6V3s7mYTMF6C94xIOHYvHpuWheTXucZzNoZJBbg9PSa mKyetB3iqvs+vAN7b6GNGg4ZXmh1bQ1n7ErHnzilYSnHibSmM/eLpu367EAZJkWTpM/Y YgHf2jmKr/i13UPz2XEZf8crZsVyddkAgSZo3oTHc5RVHknxURRFggqPRnUx7AjjM5G6 6ubp35eja2FzeuBpqcKsUQpa3mGvZOwdVDB2y7zRcKvF2zWY6Z5z1fsj3MFe4MKYqLmY 2ucsgNUfV0mnE2TiDKdXOGbPLQn/MEYTl+4oUSxuhmhcdIPjFyXMD0wVKsxLBq6RyJPo l8ng== 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=GryNigS81pQC9DneEUpBiIDE4u8Z8xVSiawX2UQFAN8=; b=Q+/ejNf5SzlgNZGBQVrcoHKxHzhXLfqjXW4Z4UaPdaYfiTfn0hoiZzabuz1J2FdhCq i3zYBmQachzyGw7SMnonJDA8PNrARSq5GlriX1s59Xf1xhfGiD+i5KmjAXhzyZnPmp3d Xyjbuc6KK9HTOC8gHmH9iFBnn6YxTKw37KddkXON4VY5BjImKYGM+goazzRby0B0aeke +ZKddoVjeBE5OD0rAqYUxf27GnskPqHe1dsIWa1ShSwiy6buq2MugkCttoAc9oBWK5RK lr3PLN0o8R4LsyfpdHH+bbKeIHMvdJLj7wmubpj7WCS1unqUARgvuQAvVGHYUSuR9EUM g+Ww== X-Gm-Message-State: AKS2vOxjEkJ4iI34kn5INFzfxG33vdSbOXXiVW7zUlGCAc0DgancZ0cu W52p7dWnkYh2GMp718NCO2+oRtB11g== X-Received: by 10.46.69.133 with SMTP id s127mr3606044lja.13.1497309003604; Mon, 12 Jun 2017 16:10:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.82.196 with HTTP; Mon, 12 Jun 2017 16:10:02 -0700 (PDT) In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> From: Russell Haley Date: Mon, 12 Jun 2017 16:10:02 -0700 Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Warner Losh Cc: Mark Millard , "freebsd-arm@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: Mon, 12 Jun 2017 23:10:06 -0000 Okay, feel free to ignore me, I'm not going to get the time drill into the source code for my own questions so I don't expect anyone else too. However, I'll ask anyway. I'm too confused to try and inline these questions. Lets see if I understand: - armv7 does not support 64 bit instructions (according to Wikipedia? I claim no expertise.) - FreeBSD has an armv6 "architecture" that is supports armv6 and armv7 on Pre-Cortex-A-53 processors that is not supported on A-53 through the emulated AArch32. - Cortex A-53 can support armv8 (AArch64) and armv7 (AArch32) instructions - The current proposal is to split the armv6 and armv7 into their own "architectures" FreeBSD has an Arm 64 bit kernel build. I don't see what the TARGET_ARCH settings in the wiki and know little about it, but will conjecture that it doesn't have a TARGET_ARCH=armv8 (please correct me if I'm wrong). What I was trying to ask was: is the kernel development moving in a direction that clearly indicates the differences in the instructions vs the architectures (or have I grossly simplified the problem)? Will it be possible to target a Cortex-A53 and build for 32 or 64 bit support? Or is this just to fix RPi? In terms of Raspbian, I had assumed they were just supporting Aarch32 across both processor models. Many of the drivers would be the same source if they share components so I would think it would be "simple". I didn't see anything in my brief look at it today to indicate otherwise. Thanks for letting me ask questions! Russ On Mon, Jun 12, 2017 at 2:07 PM, Warner Losh wrote: > > > On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard wrote: >> >> >> On 2017-Jun-12, at 1:00 PM, Mark Millard wrote: >> >> > On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard >> > wrote: >> >> On 2017-Jun-12, at 12:16 PM, Russell Haley >> >> wrote: >> >> >> >>> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard > >>> dsl-only.net> wrote: >> >>>> >> >>>> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: >> >>>> >> >>>>> . . . >> >>>>> >> >>>>> Plus, we aren't quite doing what Ian wanted. He wanted a full >> >>>>> rename. The >> >>>>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to >> >>>>> rename or >> >>>>> remove armv6. Sadly, that will still be there since the RPI >> >>>>> foundation >> >>>>> keeps finding new ways to repackage the rpi into new boards that are >> >>>>> just >> >>>>> too cheap to ignore. >> >>>> >> >>>> On 2017-Jun-12, at 6:59 AM, Andrew Turner >> >>>> wrote: >> >>>> >> >>>>> I like this. My understanding is adding armv7 would also fix many of >> >>>>> the currently broken ports that assume they are being built for armv7 as >> >>>>> many Linux distros target ARMv7+. >> >>>>> >> >>>>> It should also be noted the GENERIC kernel is likely to only ever >> >>>>> target ARMv7+ even without an armv7 TARGET_ARCH. >> >>>> >> >>>> >> >>>> Hopefully the choices related to TARGET and TARGET_ARCH >> >>>> for armv7 end up identifying the context to port builds >> >>>> so that many would just automatically do the right thing. >> >>>> >> >>>> >> >>>> As for GENERIC: >> >>>> >> >>>> powerpc has. . . >> >>>> >> >>>> TARGET=powerpc TARGET_ARCH=powerpc and GENERIC >> >>>> TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 >> >>>> >> >>>> So there is precedent for more than one GENERIC* >> >>>> for a family, with which one being appropriate >> >>>> being based on TARGET_ARCH. >> >>>> >> >>>> For powerpc TARGET=powerpc implicitly uses >> >>>> TARGET_ARCH=powerpc when TARGET_ARCH is not >> >>>> specified (if I remember right). Which should >> >>>> be the default for armv6 vs. armv7 might go >> >>>> the other direction (TARGET_ARCH=armv7 by >> >>>> default). >> >>>> >> >>>> >> >>>> Side note: >> >>>> >> >>>> A caution about talking about "rpi2" as >> >>>> an example. . . >> >>>> >> >>>> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based >> >>>> (so arm64/aarch64). (A BCM2837, not a BCM2836.) >> >>>> This dates about to something like 2014 based >> >>>> on the pictures showing the (c) notice on the >> >>>> boards. >> >>>> >> >>>> V1.1 and before were armv7 (BCM2836) based. >> >>>> >> >>>> Unless a kernel and world are made that can >> >>>> also configure/handle a Cortex-A53 in a >> >>>> armv7-like manor there will be two different >> >>>> GENERIC builds in order to span the "rpi2" >> >>>> family, based on just V1.2+ vs. V1.1 and >> >>>> before. >> >>>> >> >>>> (A single, modern distribution of the official >> >>>> Raspbian software for the rpi2 does support >> >>>> all the V1.x boards if I understand right.) >> >>> >> >>> I am confused. I don't see any documentation about Raspbian supporting >> >>> 64 bit? >> >> >> >> 64-bit Cortex-A53's can be configure to operate in a >> >> 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 >> >> and for RPI3. >> >> >> >> Raspian does not (yet?) support a 64-bit mode (AArch64). >> >> >> >> The Cortex-A53 can support either. As I understand it >> >> is possible for an OS to allow a user processes to be >> >> one or the other, different processes using the different >> >> modes. That does not mean that all operating systems >> >> bother to. >> >> >> >> If I remember right the official Ubuntu for an ODroid-C2 >> >> allows both AArch64 and AArch32 user programs (and >> >> so processes, with shared library types tracking). >> >> >> >>> From Arm at >> >>> https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php: >> >>> "The Cortex-A53 supports the full ARMv8-A architecture. It not only >> >>> runs 64-bit applications also seamlessly and efficiently runs legacy >> >>> ARM 32-bit applications." >> >>> >> >>> I assume that means it handles armv7-A without issue? (In fact, many >> >>> on this board know it does) >> >> >> >> I've not gone through the details but targeting AArch32 >> >> probably means targeting a subset of armv7. Or may be >> >> to support both requires targeting a common subset of both. >> >> (My guess is that AArch32 is the definition of a common >> >> subset for 32-bit, at least for user processes.) >> >> >> >> Raspian targets just AArch32 on armv7 and Cortex-A53 >> >> (user space). (If I've got the definition of AArch32 >> >> right: otherwise a common subset.) >> >> >> >> FreeBSD targets armv7 and AArch64 separately (via >> >> separate GENERIC kernels). I'm not aware of FreeBSD >> >> targeting AArch32 at all on cores capable of AArch64. >> >> FreeBSD possibly does not restrict itself to AArch32 >> >> (user processes) on armv7 if AArch32 is really a >> >> subset. >> > >> > I thought all 64 bit Arm instructions are defined in armv8? >> >> (I assume you are not trying to indicate armv8.1, armv8.2 >> and such. Cortex-A53 is older than those and so does not >> have the newer things involved.) >> >> That Cortex-A53 allows armv8 64-bit arm code is not in >> dispute. But the operating system in involved in setting >> up what will actually work based on how it configures >> things and operates. Much of this is the kernel. > > > Correct. > >> >> Cortex-A53 also supports AArch32, i.e., 32 bit instructions. >> So that the 64-bit instructions all being there does not >> of itself prevent using a 32-bit mode instead. >> >> (The kernel likely has to deal with more specifics of >> processor variations than user code does not. My notes >> are really about the user process model, not the all >> the kernel details.) >> >> Raspian deals with armv7's that have no 64-bit support >> and with Cortex-A53's that do. It presents a user-process >> model that is 32-bit only, even on Cortex-A53's that allow >> for 64-bit (but do not required user programs to be AArch64 >> code). >> >> Ubuntu for ODroid-C2 does not deal with armv7's but does >> allow both 64-bit (AArch64) and 32-bit (AArch32) user >> processes as I remember, on its Cortex-A53's. >> >> FreeBSD armv7 does not support Cortext-A53 or anything >> that allows 64-bit (that allows AArch64). This is a kernel >> level issue. > > > Not a hugely difficult issue to fix, but one nobody had fixed... > >> >> FreeBSD aarch64 does not support having AArch32 user >> processes. Nor does its kernel support processors that >> do not support aarch64 (so it does not support armv7). > > > Executing a 32-bit /bin/cat on aarch64 level support exists outside the > tree, according to the hallway track at BSDcan, so it will only be a matter > of time before compat32 exists there I think. > > There's a further complication is that the aarch32 unit of aarch64 > processors is optional. Not all of them have it, so that can be a problem... > IIRC, the early aarch64 targets didn't have this feature... > >> >> These are simply examples of different choices about >> what combinations of the technical possibilities to >> put effort into supporting in the kernels (and >> possibly elsewhere). None of the alternatives is >> automatic. None are independent of software choices >> that must be made by each operating system. > > > Yes. They all require somebody to be interested in doing the work. > > Warner > > > From owner-freebsd-arm@freebsd.org Mon Jun 12 23:11: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 7F54AD8630F for ; Mon, 12 Jun 2017 23:11:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F92183958 for ; Mon, 12 Jun 2017 23:11:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id m47so31529042iti.1 for ; Mon, 12 Jun 2017 16:11:12 -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=nI+De/+O+/oLBk7BCt50Gq+S92A6ZKS9TAll1W2dX/s=; b=nEAxehriIPyo6Ebw/pD/i3ok9EcuL4f3JkBmAJeHvruvLuL5fF354NAGnO1cco2UI/ XrgnkUZrGfqdA0sQwseWVeSUKnOS/fuSxsAgIZKTeTxi/KBEw+i/e17KWo3KiM/7vOvP U1lufbMHtEncQgBGlOVXkduIZwZchBC5DNNpDcVXoBXiucsXZYebNhLuv6AzxU/e3GWq GPS1ZQv2CBYkTK5gOOyPhUBMUb9GPO+X5kzSXNskoDp2evWkIe5oOWJqoNcqG5ycSKOO gRdZrjWHn4ekezWCwul4ObwdONij4tcrevQAtIDDGhMp5KF75YXY4ckKDdsG2ZnNK33X TptA== 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=nI+De/+O+/oLBk7BCt50Gq+S92A6ZKS9TAll1W2dX/s=; b=e/PHlgXcTvI23MqiaCbIXGgd2Ix6tcHIZ6c9rNKApdQrBWJQ3KPMacKCYysvi9XKDa Op7IG3kwrqLqZFHKuXs+n72nURGgcTrWuA0xlmWKjezB6bAdK9kkWPt4lBVpSK+fqlbp YyPAlLMw/WGsrcWCb10tCweOh8iXCtbHXGhvZgTLH52fg3FqVsJJ1UzHcRcD8FQl06dO Dl61WvbU6kMkgT35LNFI7kaq2+9tykYrIaR2Ex1N6XR/DprNt+ic9DwfMfpmGkRMU9bm byrhR53eC4e9i7SJ+GdyXpSGWUSkqg0fHeFzxhlCVHXESMqbMii9pTCXwsEQyM6vBbiR ReaA== X-Gm-Message-State: AODbwcAg3IOM5qi6OCmPxHoc8XpjJd4i8sBi5LcUwMUV2av+aeJZ03Mg BsRgurlFqy2vPu36c7YyJ4AdWrXc5ESl X-Received: by 10.36.181.4 with SMTP id v4mr14882551ite.103.1497309071567; Mon, 12 Jun 2017 16:11:11 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Mon, 12 Jun 2017 16:11:10 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> From: Warner Losh Date: Mon, 12 Jun 2017 17:11:10 -0600 X-Google-Sender-Auth: ikG6yn0gaGVxPGjZSgqqkEMkd1g Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Russell Haley Cc: Mark Millard , "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: Mon, 12 Jun 2017 23:11:12 -0000 On Mon, Jun 12, 2017 at 5:10 PM, Russell Haley wrote: > Okay, feel free to ignore me, I'm not going to get the time drill into > the source code for my own questions so I don't expect anyone else > too. However, I'll ask anyway. I'm too confused to try and inline > these questions. Lets see if I understand: > > - armv7 does not support 64 bit instructions (according to Wikipedia? > I claim no expertise.) > - FreeBSD has an armv6 "architecture" that is supports armv6 and armv7 > on Pre-Cortex-A-53 processors that is not supported on A-53 through > the emulated AArch32. > - Cortex A-53 can support armv8 (AArch64) and armv7 (AArch32) instructions > - The current proposal is to split the armv6 and armv7 into their own > "architectures" > > FreeBSD has an Arm 64 bit kernel build. I don't see what the > TARGET_ARCH settings in the wiki and know little about it, but will > conjecture that it doesn't have a TARGET_ARCH=armv8 (please correct me > if I'm wrong). > > What I was trying to ask was: is the kernel development moving in a > direction that clearly indicates the differences in the instructions > vs the architectures (or have I grossly simplified the problem)? Will > it be possible to target a Cortex-A53 and build for 32 or 64 bit > support? Or is this just to fix RPi? > > In terms of Raspbian, I had assumed they were just supporting Aarch32 > across both processor models. Many of the drivers would be the same > source if they share components so I would think it would be "simple". > I didn't see anything in my brief look at it today to indicate > otherwise. > > Thanks for letting me ask questions! > > Russ > > On Mon, Jun 12, 2017 at 2:07 PM, Warner Losh wrote: > > > > > > On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard > wrote: > >> > >> > >> On 2017-Jun-12, at 1:00 PM, Mark Millard > wrote: > >> > >> > On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard > > >> > wrote: > >> >> On 2017-Jun-12, at 12:16 PM, Russell Haley > >> >> wrote: > >> >> > >> >>> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard >> >>> dsl-only.net> wrote: > >> >>>> > >> >>>> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: > >> >>>> > >> >>>>> . . . > >> >>>>> > >> >>>>> Plus, we aren't quite doing what Ian wanted. He wanted a full > >> >>>>> rename. The > >> >>>>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to > >> >>>>> rename or > >> >>>>> remove armv6. Sadly, that will still be there since the RPI > >> >>>>> foundation > >> >>>>> keeps finding new ways to repackage the rpi into new boards that > are > >> >>>>> just > >> >>>>> too cheap to ignore. > >> >>>> > >> >>>> On 2017-Jun-12, at 6:59 AM, Andrew Turner > > >> >>>> wrote: > >> >>>> > >> >>>>> I like this. My understanding is adding armv7 would also fix many > of > >> >>>>> the currently broken ports that assume they are being built for > armv7 as > >> >>>>> many Linux distros target ARMv7+. > >> >>>>> > >> >>>>> It should also be noted the GENERIC kernel is likely to only ever > >> >>>>> target ARMv7+ even without an armv7 TARGET_ARCH. > >> >>>> > >> >>>> > >> >>>> Hopefully the choices related to TARGET and TARGET_ARCH > >> >>>> for armv7 end up identifying the context to port builds > >> >>>> so that many would just automatically do the right thing. > >> >>>> > >> >>>> > >> >>>> As for GENERIC: > >> >>>> > >> >>>> powerpc has. . . > >> >>>> > >> >>>> TARGET=powerpc TARGET_ARCH=powerpc and GENERIC > >> >>>> TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 > >> >>>> > >> >>>> So there is precedent for more than one GENERIC* > >> >>>> for a family, with which one being appropriate > >> >>>> being based on TARGET_ARCH. > >> >>>> > >> >>>> For powerpc TARGET=powerpc implicitly uses > >> >>>> TARGET_ARCH=powerpc when TARGET_ARCH is not > >> >>>> specified (if I remember right). Which should > >> >>>> be the default for armv6 vs. armv7 might go > >> >>>> the other direction (TARGET_ARCH=armv7 by > >> >>>> default). > >> >>>> > >> >>>> > >> >>>> Side note: > >> >>>> > >> >>>> A caution about talking about "rpi2" as > >> >>>> an example. . . > >> >>>> > >> >>>> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based > >> >>>> (so arm64/aarch64). (A BCM2837, not a BCM2836.) > >> >>>> This dates about to something like 2014 based > >> >>>> on the pictures showing the (c) notice on the > >> >>>> boards. > >> >>>> > >> >>>> V1.1 and before were armv7 (BCM2836) based. > >> >>>> > >> >>>> Unless a kernel and world are made that can > >> >>>> also configure/handle a Cortex-A53 in a > >> >>>> armv7-like manor there will be two different > >> >>>> GENERIC builds in order to span the "rpi2" > >> >>>> family, based on just V1.2+ vs. V1.1 and > >> >>>> before. > >> >>>> > >> >>>> (A single, modern distribution of the official > >> >>>> Raspbian software for the rpi2 does support > >> >>>> all the V1.x boards if I understand right.) > >> >>> > >> >>> I am confused. I don't see any documentation about Raspbian > supporting > >> >>> 64 bit? > >> >> > >> >> 64-bit Cortex-A53's can be configure to operate in a > >> >> 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 > >> >> and for RPI3. > >> >> > >> >> Raspian does not (yet?) support a 64-bit mode (AArch64). > >> >> > >> >> The Cortex-A53 can support either. As I understand it > >> >> is possible for an OS to allow a user processes to be > >> >> one or the other, different processes using the different > >> >> modes. That does not mean that all operating systems > >> >> bother to. > >> >> > >> >> If I remember right the official Ubuntu for an ODroid-C2 > >> >> allows both AArch64 and AArch32 user programs (and > >> >> so processes, with shared library types tracking). > >> >> > >> >>> From Arm at > >> >>> https://www.arm.com/products/processors/cortex-a/cortex- > a53-processor.php: > >> >>> "The Cortex-A53 supports the full ARMv8-A architecture. It not only > >> >>> runs 64-bit applications also seamlessly and efficiently runs legacy > >> >>> ARM 32-bit applications." > >> >>> > >> >>> I assume that means it handles armv7-A without issue? (In fact, many > >> >>> on this board know it does) > >> >> > >> >> I've not gone through the details but targeting AArch32 > >> >> probably means targeting a subset of armv7. Or may be > >> >> to support both requires targeting a common subset of both. > >> >> (My guess is that AArch32 is the definition of a common > >> >> subset for 32-bit, at least for user processes.) > >> >> > >> >> Raspian targets just AArch32 on armv7 and Cortex-A53 > >> >> (user space). (If I've got the definition of AArch32 > >> >> right: otherwise a common subset.) > >> >> > >> >> FreeBSD targets armv7 and AArch64 separately (via > >> >> separate GENERIC kernels). I'm not aware of FreeBSD > >> >> targeting AArch32 at all on cores capable of AArch64. > >> >> FreeBSD possibly does not restrict itself to AArch32 > >> >> (user processes) on armv7 if AArch32 is really a > >> >> subset. > >> > > >> > I thought all 64 bit Arm instructions are defined in armv8? > >> > >> (I assume you are not trying to indicate armv8.1, armv8.2 > >> and such. Cortex-A53 is older than those and so does not > >> have the newer things involved.) > >> > >> That Cortex-A53 allows armv8 64-bit arm code is not in > >> dispute. But the operating system in involved in setting > >> up what will actually work based on how it configures > >> things and operates. Much of this is the kernel. > > > > > > Correct. > > > >> > >> Cortex-A53 also supports AArch32, i.e., 32 bit instructions. > >> So that the 64-bit instructions all being there does not > >> of itself prevent using a 32-bit mode instead. > >> > >> (The kernel likely has to deal with more specifics of > >> processor variations than user code does not. My notes > >> are really about the user process model, not the all > >> the kernel details.) > >> > >> Raspian deals with armv7's that have no 64-bit support > >> and with Cortex-A53's that do. It presents a user-process > >> model that is 32-bit only, even on Cortex-A53's that allow > >> for 64-bit (but do not required user programs to be AArch64 > >> code). > >> > >> Ubuntu for ODroid-C2 does not deal with armv7's but does > >> allow both 64-bit (AArch64) and 32-bit (AArch32) user > >> processes as I remember, on its Cortex-A53's. > >> > >> FreeBSD armv7 does not support Cortext-A53 or anything > >> that allows 64-bit (that allows AArch64). This is a kernel > >> level issue. > > > > > > Not a hugely difficult issue to fix, but one nobody had fixed... > > > >> > >> FreeBSD aarch64 does not support having AArch32 user > >> processes. Nor does its kernel support processors that > >> do not support aarch64 (so it does not support armv7). > > > > > > Executing a 32-bit /bin/cat on aarch64 level support exists outside the > > tree, according to the hallway track at BSDcan, so it will only be a > matter > > of time before compat32 exists there I think. > > > > There's a further complication is that the aarch32 unit of aarch64 > > processors is optional. Not all of them have it, so that can be a > problem... > > IIRC, the early aarch64 targets didn't have this feature... > > > >> > >> These are simply examples of different choices about > >> what combinations of the technical possibilities to > >> put effort into supporting in the kernels (and > >> possibly elsewhere). None of the alternatives is > >> automatic. None are independent of software choices > >> that must be made by each operating system. > > > > > > Yes. They all require somebody to be interested in doing the work. > > > > Warner > > > > > > > From owner-freebsd-arm@freebsd.org Mon Jun 12 23:20: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 89CD1D864A4 for ; Mon, 12 Jun 2017 23:20:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49A5183DAB for ; Mon, 12 Jun 2017 23:20:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id m47so31616829iti.1 for ; Mon, 12 Jun 2017 16:20:15 -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=cWmh4Znv6aHcEXMIg29l8Pwh342wA5Erp3O0Bedk73A=; b=0GEezUDbyauy/Sv64Wh5mA44itrYtkHiHmDnxL6LGUvCjkAyFUMHAQJRhl1eE721bn Q/cNElDISENOjez+Vh5mS3emIgs+rNh4Vd/M81wVpBB7sIc5rIIZx1mYw/eJd0ihyHLu Ky7MdydaMW6JI4byxuxpeGXfh80aab0rrF/ku6WZVeiaSj0Nq3pq9iBiIPA6Pq4/CpF9 QG5gauw0KRBGc/ZtR+5vc8alxXjddGRGNmzZ8K+qS2lmRgxOJNJOthuxSG1Ld6aTji5W rcRJjEm4UyO+7sLG6AChx+EmXjpIcUxjZd78ZM3T0VF4q2AF4DulEWuouYe1nI7E2w7j GjUQ== 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=cWmh4Znv6aHcEXMIg29l8Pwh342wA5Erp3O0Bedk73A=; b=PAKZIQDZNKfVG/ZawEdrSM12cI2sot/AdA+RcvHmjc7Gas9Rgozm0B+OtMf6iWTTKM yEZfnwB0cMEmexfZiU+/yx++jl+JadALcbsDYMy8ZDuEPg89IF04vtjxXT03bweOuIhL sMehQjzI86ic1CgEU2bLE2IwJKijGIbGgcxpPcZF4yEe4UOriw8CjTi08NSGabNuK2LQ mm6+vqNKE7srgmdH2JPTD52/XPVwnIbg4cR9mCk34BG24aLixCd6JKJpxJCNSm5jYsH3 IvWlqszYRpPzEB8G/C1EcnnPxihpWHB0xxWcZXoNqYN6oc7F0dKQcdLgiZjhYpFyaFvq zb3g== X-Gm-Message-State: AODbwcBN0ugBzT8kz7Cto+sqq4VuQ9MaAaa7oGirzG0SNNckl1JP8Paz pl4YivZLaX2vYqi8EfD50S8ThNob9iqQ X-Received: by 10.36.105.13 with SMTP id e13mr14150545itc.64.1497309614550; Mon, 12 Jun 2017 16:20:14 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Mon, 12 Jun 2017 16:20:13 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> From: Warner Losh Date: Mon, 12 Jun 2017 17:20:13 -0600 X-Google-Sender-Auth: Oi-EQfQtXvXTZARbxcxctlbY-bA Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Russell Haley Cc: Mark Millard , "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: Mon, 12 Jun 2017 23:20:15 -0000 On Mon, Jun 12, 2017 at 5:10 PM, Russell Haley wrote: > Okay, feel free to ignore me, I'm not going to get the time drill into > the source code for my own questions so I don't expect anyone else > too. However, I'll ask anyway. I'm too confused to try and inline > these questions. Lets see if I understand: > > - armv7 does not support 64 bit instructions (according to Wikipedia? > I claim no expertise.) > - FreeBSD has an armv6 "architecture" that is supports armv6 and armv7 > on Pre-Cortex-A-53 processors that is not supported on A-53 through > the emulated AArch32. > There may be a tiny number of kernel or bootloader issues precluding that support, but yes. I've been told of people claiming to run a newer rpi2 (v1.2 or newer) in 32-bit mode, but I've not been able to confirm the people who are making the claims. It should be possible to do this, since we know Linux does it, so it's only a matter of someone showing up with patches and/or instructions on how to do this. > - Cortex A-53 can support armv8 (AArch64) and armv7 (AArch32) instructions > Yes, as well as many others that have similar situations. > - The current proposal is to split the armv6 and armv7 into their own > "architectures" > Kinda, yes. This is to build two different sub-architectures where we currently do just one. > FreeBSD has an Arm 64 bit kernel build. I don't see what the > TARGET_ARCH settings in the wiki and know little about it, but will > conjecture that it doesn't have a TARGET_ARCH=armv8 (please correct me > if I'm wrong). > It's callled aarch64, per industry norms. Arm doesn't want people calling it arm64 or armv8 when referencing the architecture, so nobody that's running in this space sets their architecture name to anything bug aarch64. > What I was trying to ask was: is the kernel development moving in a > direction that clearly indicates the differences in the instructions > vs the architectures (or have I grossly simplified the problem)? Will > it be possible to target a Cortex-A53 and build for 32 or 64 bit > support? Or is this just to fix RPi? > It already has that difference in an MI way. The MD code to do that hasn't caught up yet (to run 32-bit binaries on a 64-bit kernel). It's just that the rpi is the first device people have wanted to boot either in 32-bit mode or in 64-bit mode, so that's exposing that our code is a bit green in that area. > In terms of Raspbian, I had assumed they were just supporting Aarch32 > across both processor models. Many of the drivers would be the same > source if they share components so I would think it would be "simple". > I didn't see anything in my brief look at it today to indicate > otherwise. > We already share considerable code between the armv7 and aarch64 kernels to support raspberry pi devices since they are substantially similar between them. > Thanks for letting me ask questions! > > Russ > > On Mon, Jun 12, 2017 at 2:07 PM, Warner Losh wrote: > > > > > > On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard > wrote: > >> > >> > >> On 2017-Jun-12, at 1:00 PM, Mark Millard > wrote: > >> > >> > On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard > > >> > wrote: > >> >> On 2017-Jun-12, at 12:16 PM, Russell Haley > >> >> wrote: > >> >> > >> >>> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard >> >>> dsl-only.net> wrote: > >> >>>> > >> >>>> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: > >> >>>> > >> >>>>> . . . > >> >>>>> > >> >>>>> Plus, we aren't quite doing what Ian wanted. He wanted a full > >> >>>>> rename. The > >> >>>>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to > >> >>>>> rename or > >> >>>>> remove armv6. Sadly, that will still be there since the RPI > >> >>>>> foundation > >> >>>>> keeps finding new ways to repackage the rpi into new boards that > are > >> >>>>> just > >> >>>>> too cheap to ignore. > >> >>>> > >> >>>> On 2017-Jun-12, at 6:59 AM, Andrew Turner > > >> >>>> wrote: > >> >>>> > >> >>>>> I like this. My understanding is adding armv7 would also fix many > of > >> >>>>> the currently broken ports that assume they are being built for > armv7 as > >> >>>>> many Linux distros target ARMv7+. > >> >>>>> > >> >>>>> It should also be noted the GENERIC kernel is likely to only ever > >> >>>>> target ARMv7+ even without an armv7 TARGET_ARCH. > >> >>>> > >> >>>> > >> >>>> Hopefully the choices related to TARGET and TARGET_ARCH > >> >>>> for armv7 end up identifying the context to port builds > >> >>>> so that many would just automatically do the right thing. > >> >>>> > >> >>>> > >> >>>> As for GENERIC: > >> >>>> > >> >>>> powerpc has. . . > >> >>>> > >> >>>> TARGET=powerpc TARGET_ARCH=powerpc and GENERIC > >> >>>> TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 > >> >>>> > >> >>>> So there is precedent for more than one GENERIC* > >> >>>> for a family, with which one being appropriate > >> >>>> being based on TARGET_ARCH. > >> >>>> > >> >>>> For powerpc TARGET=powerpc implicitly uses > >> >>>> TARGET_ARCH=powerpc when TARGET_ARCH is not > >> >>>> specified (if I remember right). Which should > >> >>>> be the default for armv6 vs. armv7 might go > >> >>>> the other direction (TARGET_ARCH=armv7 by > >> >>>> default). > >> >>>> > >> >>>> > >> >>>> Side note: > >> >>>> > >> >>>> A caution about talking about "rpi2" as > >> >>>> an example. . . > >> >>>> > >> >>>> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based > >> >>>> (so arm64/aarch64). (A BCM2837, not a BCM2836.) > >> >>>> This dates about to something like 2014 based > >> >>>> on the pictures showing the (c) notice on the > >> >>>> boards. > >> >>>> > >> >>>> V1.1 and before were armv7 (BCM2836) based. > >> >>>> > >> >>>> Unless a kernel and world are made that can > >> >>>> also configure/handle a Cortex-A53 in a > >> >>>> armv7-like manor there will be two different > >> >>>> GENERIC builds in order to span the "rpi2" > >> >>>> family, based on just V1.2+ vs. V1.1 and > >> >>>> before. > >> >>>> > >> >>>> (A single, modern distribution of the official > >> >>>> Raspbian software for the rpi2 does support > >> >>>> all the V1.x boards if I understand right.) > >> >>> > >> >>> I am confused. I don't see any documentation about Raspbian > supporting > >> >>> 64 bit? > >> >> > >> >> 64-bit Cortex-A53's can be configure to operate in a > >> >> 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 > >> >> and for RPI3. > >> >> > >> >> Raspian does not (yet?) support a 64-bit mode (AArch64). > >> >> > >> >> The Cortex-A53 can support either. As I understand it > >> >> is possible for an OS to allow a user processes to be > >> >> one or the other, different processes using the different > >> >> modes. That does not mean that all operating systems > >> >> bother to. > >> >> > >> >> If I remember right the official Ubuntu for an ODroid-C2 > >> >> allows both AArch64 and AArch32 user programs (and > >> >> so processes, with shared library types tracking). > >> >> > >> >>> From Arm at > >> >>> https://www.arm.com/products/processors/cortex-a/cortex- > a53-processor.php: > >> >>> "The Cortex-A53 supports the full ARMv8-A architecture. It not only > >> >>> runs 64-bit applications also seamlessly and efficiently runs legacy > >> >>> ARM 32-bit applications." > >> >>> > >> >>> I assume that means it handles armv7-A without issue? (In fact, many > >> >>> on this board know it does) > >> >> > >> >> I've not gone through the details but targeting AArch32 > >> >> probably means targeting a subset of armv7. Or may be > >> >> to support both requires targeting a common subset of both. > >> >> (My guess is that AArch32 is the definition of a common > >> >> subset for 32-bit, at least for user processes.) > >> >> > >> >> Raspian targets just AArch32 on armv7 and Cortex-A53 > >> >> (user space). (If I've got the definition of AArch32 > >> >> right: otherwise a common subset.) > >> >> > >> >> FreeBSD targets armv7 and AArch64 separately (via > >> >> separate GENERIC kernels). I'm not aware of FreeBSD > >> >> targeting AArch32 at all on cores capable of AArch64. > >> >> FreeBSD possibly does not restrict itself to AArch32 > >> >> (user processes) on armv7 if AArch32 is really a > >> >> subset. > >> > > >> > I thought all 64 bit Arm instructions are defined in armv8? > >> > >> (I assume you are not trying to indicate armv8.1, armv8.2 > >> and such. Cortex-A53 is older than those and so does not > >> have the newer things involved.) > >> > >> That Cortex-A53 allows armv8 64-bit arm code is not in > >> dispute. But the operating system in involved in setting > >> up what will actually work based on how it configures > >> things and operates. Much of this is the kernel. > > > > > > Correct. > > > >> > >> Cortex-A53 also supports AArch32, i.e., 32 bit instructions. > >> So that the 64-bit instructions all being there does not > >> of itself prevent using a 32-bit mode instead. > >> > >> (The kernel likely has to deal with more specifics of > >> processor variations than user code does not. My notes > >> are really about the user process model, not the all > >> the kernel details.) > >> > >> Raspian deals with armv7's that have no 64-bit support > >> and with Cortex-A53's that do. It presents a user-process > >> model that is 32-bit only, even on Cortex-A53's that allow > >> for 64-bit (but do not required user programs to be AArch64 > >> code). > >> > >> Ubuntu for ODroid-C2 does not deal with armv7's but does > >> allow both 64-bit (AArch64) and 32-bit (AArch32) user > >> processes as I remember, on its Cortex-A53's. > >> > >> FreeBSD armv7 does not support Cortext-A53 or anything > >> that allows 64-bit (that allows AArch64). This is a kernel > >> level issue. > > > > > > Not a hugely difficult issue to fix, but one nobody had fixed... > > > >> > >> FreeBSD aarch64 does not support having AArch32 user > >> processes. Nor does its kernel support processors that > >> do not support aarch64 (so it does not support armv7). > > > > > > Executing a 32-bit /bin/cat on aarch64 level support exists outside the > > tree, according to the hallway track at BSDcan, so it will only be a > matter > > of time before compat32 exists there I think. > > > > There's a further complication is that the aarch32 unit of aarch64 > > processors is optional. Not all of them have it, so that can be a > problem... > > IIRC, the early aarch64 targets didn't have this feature... > > > >> > >> These are simply examples of different choices about > >> what combinations of the technical possibilities to > >> put effort into supporting in the kernels (and > >> possibly elsewhere). None of the alternatives is > >> automatic. None are independent of software choices > >> that must be made by each operating system. > > > > > > Yes. They all require somebody to be interested in doing the work. > > > > Warner > > > > > > > From owner-freebsd-arm@freebsd.org Mon Jun 12 23:53:45 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 EF3CED86CBF for ; Mon, 12 Jun 2017 23:53:45 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A2F784F44 for ; Mon, 12 Jun 2017 23:53:45 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id p189so59569831lfe.2 for ; Mon, 12 Jun 2017 16:53:45 -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=aNZOOuPwFl/yH+/nlJfphwGjMCRGzlHn+si7BGTPD44=; b=OJYp3UrxQw//luLlkK28B1l6Zo9XZiR5NLCsDKam7pucoXgsYQU34KRv4jalmGw/yg b8j+6YR+5GC4d6rSnG7US6tpRjoegUbZXoEuXzDT5FyluUG6MNvKcFjwNRzo81KE62Pk jdIPFrgrUN6stK6mjM9BZX60UJbpuD/uviYLD7bFa8aLs4oCO6hbaxd5ehjqN1pQeWNT zRIgdKAt4jnxXp/F0e9jTaBqhZOZPl0bbC6HUB7i/Sm96mtX0t4yIpYjo+/61nNc5Fj9 iCLx3/6RSGPqJuKcYfxoALbK3R+At0u1d/Gg3HhadwfcKg/ajgvOwTrNXNNxParLj2vH Djsw== 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=aNZOOuPwFl/yH+/nlJfphwGjMCRGzlHn+si7BGTPD44=; b=PTKWgSwawS+GLXrXLhIHqUbBIzKVx8kUsAwLwwuRzjaU7Qa8S7bx5NfIFWqK/kCIV4 uVVMOmC1wiyE35XCp9vgBy3DMdwdtsZBaTr4A/IBzMf5wV6rVyrmAzK9dpR85TqU5LTS 8U8L2/aqUlmkVtkiQesY33DUqz5hIGoDWkMsvyMiqDo8xdiAOqIHMXW0ywjhYVS9yGqr QoEZy+d0RNoKokCWhD8FXwBLW7zbORFNVUp2PTwk76zECLUdWBpIXzoNsRyeTuT/pgmA iA0+HI5A1kfbMXNmyfJXfOc00iVoBWFKG/FiHr3av7wX4F+RM25PtUCQV7Ha4KSRGoV4 h/3A== X-Gm-Message-State: AODbwcCjhLN5pGc9hUwI2OZ9HR1wR10K9ESWqR4KaEvwqV8NMqguT86p cCm2qVs1SAU+q3zKfVG2y+bAdneapw== X-Received: by 10.46.13.2 with SMTP id 2mr18394514ljn.93.1497311623217; Mon, 12 Jun 2017 16:53:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.82.196 with HTTP; Mon, 12 Jun 2017 16:53:42 -0700 (PDT) In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> From: Russell Haley Date: Mon, 12 Jun 2017 16:53:42 -0700 Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Warner Losh Cc: Mark Millard , "freebsd-arm@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: Mon, 12 Jun 2017 23:53:46 -0000 On Mon, Jun 12, 2017 at 4:20 PM, Warner Losh wrote: > > > On Mon, Jun 12, 2017 at 5:10 PM, Russell Haley wrote: >> >> Okay, feel free to ignore me, I'm not going to get the time drill into >> the source code for my own questions so I don't expect anyone else >> too. However, I'll ask anyway. I'm too confused to try and inline >> these questions. Lets see if I understand: >> >> - armv7 does not support 64 bit instructions (according to Wikipedia? >> I claim no expertise.) >> - FreeBSD has an armv6 "architecture" that is supports armv6 and armv7 >> on Pre-Cortex-A-53 processors that is not supported on A-53 through >> the emulated AArch32. > > > There may be a tiny number of kernel or bootloader issues precluding that > support, but yes. I've been told of people claiming to run a newer rpi2 > (v1.2 or newer) in 32-bit mode, but I've not been able to confirm the people > who are making the claims. It should be possible to do this, since we know > Linux does it, so it's only a matter of someone showing up with patches > and/or instructions on how to do this. > >> >> - Cortex A-53 can support armv8 (AArch64) and armv7 (AArch32) instructions > > > Yes, as well as many others that have similar situations. > >> >> - The current proposal is to split the armv6 and armv7 into their own >> "architectures" > > > Kinda, yes. This is to build two different sub-architectures where we > currently do just one. > >> >> FreeBSD has an Arm 64 bit kernel build. I don't see what the >> TARGET_ARCH settings in the wiki and know little about it, but will >> conjecture that it doesn't have a TARGET_ARCH=armv8 (please correct me >> if I'm wrong). > > > It's callled aarch64, per industry norms. Arm doesn't want people calling it > arm64 or armv8 when referencing the architecture, so nobody that's running > in this space sets their architecture name to anything bug aarch64. So supported arm architectures would use a TARGET_ARCH of: armv5, armv6, armv7 and then AArch64? Would there be an AArch32 for 32 bit armv8? Just asking out loud: would it be better to call armv7 Aarch32? Russ >> >> What I was trying to ask was: is the kernel development moving in a >> direction that clearly indicates the differences in the instructions >> vs the architectures (or have I grossly simplified the problem)? Will >> it be possible to target a Cortex-A53 and build for 32 or 64 bit >> support? Or is this just to fix RPi? > > > It already has that difference in an MI way. The MD code to do that hasn't > caught up yet (to run 32-bit binaries on a 64-bit kernel). It's just that > the rpi is the first device people have wanted to boot either in 32-bit mode > or in 64-bit mode, so that's exposing that our code is a bit green in that > area. > >> >> In terms of Raspbian, I had assumed they were just supporting Aarch32 >> across both processor models. Many of the drivers would be the same >> source if they share components so I would think it would be "simple". >> I didn't see anything in my brief look at it today to indicate >> otherwise. > > > We already share considerable code between the armv7 and aarch64 kernels to > support raspberry pi devices since they are substantially similar between > them. > >> >> Thanks for letting me ask questions! >> >> Russ >> >> On Mon, Jun 12, 2017 at 2:07 PM, Warner Losh wrote: >> > >> > >> > On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard >> > wrote: >> >> >> >> >> >> On 2017-Jun-12, at 1:00 PM, Mark Millard >> >> wrote: >> >> >> >> > On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard > >> > dsl-only.net> >> >> > wrote: >> >> >> On 2017-Jun-12, at 12:16 PM, Russell Haley >> >> >> wrote: >> >> >> >> >> >>> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard > >> >>> dsl-only.net> wrote: >> >> >>>> >> >> >>>> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: >> >> >>>> >> >> >>>>> . . . >> >> >>>>> >> >> >>>>> Plus, we aren't quite doing what Ian wanted. He wanted a full >> >> >>>>> rename. The >> >> >>>>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to >> >> >>>>> rename or >> >> >>>>> remove armv6. Sadly, that will still be there since the RPI >> >> >>>>> foundation >> >> >>>>> keeps finding new ways to repackage the rpi into new boards that >> >> >>>>> are >> >> >>>>> just >> >> >>>>> too cheap to ignore. >> >> >>>> >> >> >>>> On 2017-Jun-12, at 6:59 AM, Andrew Turner > >> >>>> fubar.geek.nz> >> >> >>>> wrote: >> >> >>>> >> >> >>>>> I like this. My understanding is adding armv7 would also fix many >> >> >>>>> of >> >> >>>>> the currently broken ports that assume they are being built for >> >> >>>>> armv7 as >> >> >>>>> many Linux distros target ARMv7+. >> >> >>>>> >> >> >>>>> It should also be noted the GENERIC kernel is likely to only ever >> >> >>>>> target ARMv7+ even without an armv7 TARGET_ARCH. >> >> >>>> >> >> >>>> >> >> >>>> Hopefully the choices related to TARGET and TARGET_ARCH >> >> >>>> for armv7 end up identifying the context to port builds >> >> >>>> so that many would just automatically do the right thing. >> >> >>>> >> >> >>>> >> >> >>>> As for GENERIC: >> >> >>>> >> >> >>>> powerpc has. . . >> >> >>>> >> >> >>>> TARGET=powerpc TARGET_ARCH=powerpc and GENERIC >> >> >>>> TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 >> >> >>>> >> >> >>>> So there is precedent for more than one GENERIC* >> >> >>>> for a family, with which one being appropriate >> >> >>>> being based on TARGET_ARCH. >> >> >>>> >> >> >>>> For powerpc TARGET=powerpc implicitly uses >> >> >>>> TARGET_ARCH=powerpc when TARGET_ARCH is not >> >> >>>> specified (if I remember right). Which should >> >> >>>> be the default for armv6 vs. armv7 might go >> >> >>>> the other direction (TARGET_ARCH=armv7 by >> >> >>>> default). >> >> >>>> >> >> >>>> >> >> >>>> Side note: >> >> >>>> >> >> >>>> A caution about talking about "rpi2" as >> >> >>>> an example. . . >> >> >>>> >> >> >>>> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based >> >> >>>> (so arm64/aarch64). (A BCM2837, not a BCM2836.) >> >> >>>> This dates about to something like 2014 based >> >> >>>> on the pictures showing the (c) notice on the >> >> >>>> boards. >> >> >>>> >> >> >>>> V1.1 and before were armv7 (BCM2836) based. >> >> >>>> >> >> >>>> Unless a kernel and world are made that can >> >> >>>> also configure/handle a Cortex-A53 in a >> >> >>>> armv7-like manor there will be two different >> >> >>>> GENERIC builds in order to span the "rpi2" >> >> >>>> family, based on just V1.2+ vs. V1.1 and >> >> >>>> before. >> >> >>>> >> >> >>>> (A single, modern distribution of the official >> >> >>>> Raspbian software for the rpi2 does support >> >> >>>> all the V1.x boards if I understand right.) >> >> >>> >> >> >>> I am confused. I don't see any documentation about Raspbian >> >> >>> supporting >> >> >>> 64 bit? >> >> >> >> >> >> 64-bit Cortex-A53's can be configure to operate in a >> >> >> 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 >> >> >> and for RPI3. >> >> >> >> >> >> Raspian does not (yet?) support a 64-bit mode (AArch64). >> >> >> >> >> >> The Cortex-A53 can support either. As I understand it >> >> >> is possible for an OS to allow a user processes to be >> >> >> one or the other, different processes using the different >> >> >> modes. That does not mean that all operating systems >> >> >> bother to. >> >> >> >> >> >> If I remember right the official Ubuntu for an ODroid-C2 >> >> >> allows both AArch64 and AArch32 user programs (and >> >> >> so processes, with shared library types tracking). >> >> >> >> >> >>> From Arm at >> >> >>> >> >> >>> https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php: >> >> >>> "The Cortex-A53 supports the full ARMv8-A architecture. It not only >> >> >>> runs 64-bit applications also seamlessly and efficiently runs >> >> >>> legacy >> >> >>> ARM 32-bit applications." >> >> >>> >> >> >>> I assume that means it handles armv7-A without issue? (In fact, >> >> >>> many >> >> >>> on this board know it does) >> >> >> >> >> >> I've not gone through the details but targeting AArch32 >> >> >> probably means targeting a subset of armv7. Or may be >> >> >> to support both requires targeting a common subset of both. >> >> >> (My guess is that AArch32 is the definition of a common >> >> >> subset for 32-bit, at least for user processes.) >> >> >> >> >> >> Raspian targets just AArch32 on armv7 and Cortex-A53 >> >> >> (user space). (If I've got the definition of AArch32 >> >> >> right: otherwise a common subset.) >> >> >> >> >> >> FreeBSD targets armv7 and AArch64 separately (via >> >> >> separate GENERIC kernels). I'm not aware of FreeBSD >> >> >> targeting AArch32 at all on cores capable of AArch64. >> >> >> FreeBSD possibly does not restrict itself to AArch32 >> >> >> (user processes) on armv7 if AArch32 is really a >> >> >> subset. >> >> > >> >> > I thought all 64 bit Arm instructions are defined in armv8? >> >> >> >> (I assume you are not trying to indicate armv8.1, armv8.2 >> >> and such. Cortex-A53 is older than those and so does not >> >> have the newer things involved.) >> >> >> >> That Cortex-A53 allows armv8 64-bit arm code is not in >> >> dispute. But the operating system in involved in setting >> >> up what will actually work based on how it configures >> >> things and operates. Much of this is the kernel. >> > >> > >> > Correct. >> > >> >> >> >> Cortex-A53 also supports AArch32, i.e., 32 bit instructions. >> >> So that the 64-bit instructions all being there does not >> >> of itself prevent using a 32-bit mode instead. >> >> >> >> (The kernel likely has to deal with more specifics of >> >> processor variations than user code does not. My notes >> >> are really about the user process model, not the all >> >> the kernel details.) >> >> >> >> Raspian deals with armv7's that have no 64-bit support >> >> and with Cortex-A53's that do. It presents a user-process >> >> model that is 32-bit only, even on Cortex-A53's that allow >> >> for 64-bit (but do not required user programs to be AArch64 >> >> code). >> >> >> >> Ubuntu for ODroid-C2 does not deal with armv7's but does >> >> allow both 64-bit (AArch64) and 32-bit (AArch32) user >> >> processes as I remember, on its Cortex-A53's. >> >> >> >> FreeBSD armv7 does not support Cortext-A53 or anything >> >> that allows 64-bit (that allows AArch64). This is a kernel >> >> level issue. >> > >> > >> > Not a hugely difficult issue to fix, but one nobody had fixed... >> > >> >> >> >> FreeBSD aarch64 does not support having AArch32 user >> >> processes. Nor does its kernel support processors that >> >> do not support aarch64 (so it does not support armv7). >> > >> > >> > Executing a 32-bit /bin/cat on aarch64 level support exists outside the >> > tree, according to the hallway track at BSDcan, so it will only be a >> > matter >> > of time before compat32 exists there I think. >> > >> > There's a further complication is that the aarch32 unit of aarch64 >> > processors is optional. Not all of them have it, so that can be a >> > problem... >> > IIRC, the early aarch64 targets didn't have this feature... >> > >> >> >> >> These are simply examples of different choices about >> >> what combinations of the technical possibilities to >> >> put effort into supporting in the kernels (and >> >> possibly elsewhere). None of the alternatives is >> >> automatic. None are independent of software choices >> >> that must be made by each operating system. >> > >> > >> > Yes. They all require somebody to be interested in doing the work. >> > >> > Warner >> > >> > >> > > > From owner-freebsd-arm@freebsd.org Tue Jun 13 00:49:51 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 BAB03D87E34 for ; Tue, 13 Jun 2017 00:49:51 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80A921E3D for ; Tue, 13 Jun 2017 00:49:51 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v5D0nmr4053894; Mon, 12 Jun 2017 17:49:48 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v5D0nmeZ053893; Mon, 12 Jun 2017 17:49:48 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201706130049.v5D0nmeZ053893@pdx.rh.CN85.dnsmgr.net> Subject: Re: Creating armv7 MACHINE_ARCH In-Reply-To: <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> To: Mark Millard Date: Mon, 12 Jun 2017 17:49:48 -0700 (PDT) CC: Russell Haley , "freebsd-arm@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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, 13 Jun 2017 00:49:51 -0000 > On 2017-Jun-12, at 12:16 PM, Russell Haley wrote: > > > On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard wrote: > >> > >> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: > >> > >>> . . . > >>> > >>> Plus, we aren't quite doing what Ian wanted. He wanted a full rename. The > >>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to rename or > >>> remove armv6. Sadly, that will still be there since the RPI foundation > >>> keeps finding new ways to repackage the rpi into new boards that are just > >>> too cheap to ignore. > >> > >> On 2017-Jun-12, at 6:59 AM, Andrew Turner wrote: > >> > >>> I like this. My understanding is adding armv7 would also fix many of the currently broken ports that assume they are being built for armv7 as many Linux distros target ARMv7+. > >>> > >>> It should also be noted the GENERIC kernel is likely to only ever target ARMv7+ even without an armv7 TARGET_ARCH. > >> > >> > >> Hopefully the choices related to TARGET and TARGET_ARCH > >> for armv7 end up identifying the context to port builds > >> so that many would just automatically do the right thing. > >> > >> > >> As for GENERIC: > >> > >> powerpc has. . . > >> > >> TARGET=powerpc TARGET_ARCH=powerpc and GENERIC > >> TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 > >> > >> So there is precedent for more than one GENERIC* > >> for a family, with which one being appropriate > >> being based on TARGET_ARCH. > >> > >> For powerpc TARGET=powerpc implicitly uses > >> TARGET_ARCH=powerpc when TARGET_ARCH is not > >> specified (if I remember right). Which should > >> be the default for armv6 vs. armv7 might go > >> the other direction (TARGET_ARCH=armv7 by > >> default). > >> > >> > >> Side note: > >> > >> A caution about talking about "rpi2" as > >> an example. . . > >> > >> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based > >> (so arm64/aarch64). (A BCM2837, not a BCM2836.) > >> This dates about to something like 2014 based > >> on the pictures showing the (c) notice on the > >> boards. > >> > >> V1.1 and before were armv7 (BCM2836) based. > >> > >> Unless a kernel and world are made that can > >> also configure/handle a Cortex-A53 in a > >> armv7-like manor there will be two different > >> GENERIC builds in order to span the "rpi2" > >> family, based on just V1.2+ vs. V1.1 and > >> before. > >> > >> (A single, modern distribution of the official > >> Raspbian software for the rpi2 does support > >> all the V1.x boards if I understand right.) > > > > I am confused. I don't see any documentation about Raspbian supporting 64 bit? > > 64-bit Cortex-A53's can be configure to operate in a > 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 > and for RPI3. > > Raspian does not (yet?) support a 64-bit mode (AArch64). > > The Cortex-A53 can support either. As I understand it > is possible for an OS to allow a user processes to be > one or the other, different processes using the different > modes. That does not mean that all operating systems > bother to. > > If I remember right the official Ubuntu for an ODroid-C2 > allows both AArch64 and AArch32 user programs (and > so processes, with shared library types tracking). It would be very nice if we had an AArch32 that could run on the RPI3. For me it does not make a huge amount of sense to run 64 bit pointers on a machine that can never physcially have more than 2G of memory. I do understand, and am greatful, that basically this was done to bring up the AArch64 platform, but can we go the extra mile and have both? > > > From Arm at https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php: > > "The Cortex-A53 supports the full ARMv8-A architecture. It not only > > runs 64-bit applications also seamlessly and efficiently runs legacy > > ARM 32-bit applications." > > > > I assume that means it handles armv7-A without issue? (In fact, many > > on this board know it does) > > I've not gone through the details but targeting AArch32 > probably means targeting a subset of armv7. Or may be > to support both requires targeting a common subset of both. > (My guess is that AArch32 is the definition of a common > subset for 32-bit, at least for user processes.) > > Raspian targets just AArch32 on armv7 and Cortex-A53 > (user space). (If I've got the definition of AArch32 > right: otherwise a common subset.) > > FreeBSD targets armv7 and AArch64 separately (via > separate GENERIC kernels). I'm not aware of FreeBSD > targeting AArch32 at all on cores capable of AArch64. > FreeBSD possibly does not restrict itself to AArch32 > (user processes) on armv7 if AArch32 is really a > subset. Isnt this just a wonefully confusing world! > Mark Millard > markmi at dsl-only.net -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Tue Jun 13 01:04: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 9A1C7D88287 for ; Tue, 13 Jun 2017 01:04:07 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 38BFC26C6 for ; Tue, 13 Jun 2017 01:04:06 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 0abc58b2-4fd4-11e7-b96e-2378c10e3beb 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.eu.mailhop.org (Halon) with ESMTPSA id 0abc58b2-4fd4-11e7-b96e-2378c10e3beb; Tue, 13 Jun 2017 01:03:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v5D12oME002268; Mon, 12 Jun 2017 19:02:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1497315770.81013.4.camel@freebsd.org> Subject: Re: Creating armv7 MACHINE_ARCH From: Ian Lepore To: Warner Losh , Russell Haley Cc: "freebsd-arm@freebsd.org" Date: Mon, 12 Jun 2017 19:02:50 -0600 In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> 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: Tue, 13 Jun 2017 01:04:07 -0000 On Mon, 2017-06-12 at 09:39 -0600, Warner Losh wrote: > Clearly, we woke up one day and realized Ian was right? And he's only been > saying it since pre R11 since that was the first release that supported it. > There was no armv6 support in 10. Ask a snarky question, get a snarky > answer... > > What's changed is that the port has gone from being mainly used by people > that had an rpi that supported a bunch of other platforms (including Ian's > iMX6) to a port that's used primarily by armv7 machines (including the > rpi2) that also happens to support the rpi (which is the only !armv7 > platform). When Ian started saying it, rpi was one of the better supported > platforms as well. Now with all the Allwinner support, improved iMX6 > support, and the rpi2 being armv7, we are now in a situation where most > users and most of the good support is on that platform. What's also changed > is Andrew's work on having a GENERIC kernel. We'd have a GENERIC one for > ARMv6 too: It's the RPI config :). > > Plus, we aren't quite doing what Ian wanted. He wanted a full rename. The > proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to rename or > remove armv6. Sadly, that will still be there since the RPI foundation > keeps finding new ways to repackage the rpi into new boards that are just > too cheap to ignore. > > Warner > For the record... 1. Of course there was armv6 support in freebsd 10. 2. I never proposed eliminating armv6/rpi support, I was always about adding armv7 as its own arch.   I did once propose renaming armv6hf to armv6 without bothering to do the magic softfp compatibility thing you did, maybe that's what you're remembering (basically using tier-2 status freedom to break ABI in the middle of a released branch). Of course I support the new proposol to create an armv7 arch. :) -- Ian From owner-freebsd-arm@freebsd.org Tue Jun 13 02:08:28 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 0FED6D89FF9 for ; Tue, 13 Jun 2017 02:08:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-176.reflexion.net [208.70.211.176]) (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 C60CD649AB for ; Tue, 13 Jun 2017 02:08:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6429 invoked from network); 13 Jun 2017 02:05:44 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 13 Jun 2017 02:05:44 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 12 Jun 2017 22:01:46 -0400 (EDT) Received: (qmail 30166 invoked from network); 13 Jun 2017 02:01:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jun 2017 02:01:46 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6B3EAEC8816; Mon, 12 Jun 2017 19:01:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Creating armv7 MACHINE_ARCH From: Mark Millard In-Reply-To: Date: Mon, 12 Jun 2017 19:01:44 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> To: Russell Haley 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, 13 Jun 2017 02:08:28 -0000 On 2017-Jun-12, at 4:10 PM, Russell Haley = wrote: > Okay, feel free to ignore me, I'm not going to get the time drill into > the source code for my own questions so I don't expect anyone else > too. However, I'll ask anyway. I'm too confused to try and inline > these questions. Lets see if I understand: >=20 > - armv7 does not support 64 bit instructions (according to Wikipedia? > I claim no expertise.) It does not support AArch64 instructions but does support AArch32 instructions (or is a good approximation). AArch32 was actually created later to be armv7-a like. > - FreeBSD has an armv6 "architecture" that is supports armv6 and armv7 > on Pre-Cortex-A-53 processors that is not supported on A-53 through > the emulated AArch32. There are actually architectures (by ARM's definitions). . . ARMv6, ARMv6T2, ARMv6Z, ARMv6K, ARMV6-M ARMv7-M, ARMv7E-M, ARMv7-R, ARMv7-A ARMv8-A, ARMv8.1-A ARMv8.2-Am ARMV8.3-A, ARMv8-R, ARMv8-M I'm going to largely ignore much of that variation in structure. ARM has continued to produce/make new variations for both 32-bit and 64-bit in overlapping time frames. So the "Pre-Cortex-A53" presumes to much about relative timing. Technically the old RPI2s (V1.1 and before) have Cortex-A7's and the new V1.2's have Cortex-A53's. RPI3 is also Cortex-A53 based. Cortex-A7 includes an implementation of armv7-A architecture (but is not the only one). Cortex-A53 includes an implementation of armv8-A architecture=20 (but is not the only one). (Both include other things as well. And the System On A Chip has even more stuff than the Cortex-A's in question.) Cortex-A's are specific CPUs/cores that are also examples of the specific architecture(s) they implement. If a kernel supports armv7-a it can support a variety of CPUs that all implement armv7-a architecture. It may not support things in the CPUs that are beyond that architecture. If a kernel supports armv8-a it can support a variety of CPUs that all implement armv8-a architecture. It may not support things in the CPUs that are beyond that architecture. Note there are also issues of support of the System On a Chip involved as well. More than ARM is involved overall. > - Cortex A-53 can support armv8 (AArch64) and armv7 (AArch32) = instructions As I remember armv8-a specifies: A) Optional support: AArch64 (Cortex-A32 is ARMv8-A archtecture but only 32-bit) (ARMv8-R architecture is always only 32-bit as I understand) (ARMv8-M architecture is always only 32-bit as I understand) B) Optional support: AArch32 (Cortex-A35/53/57/72/73 are ARMv8-A and have both) (Cortex-A55/75 are ARMV8.2-A architecture and have both) (But variants can be produced that omit AArch32.) C) Various things specific to armv8-a might go beyond what AArch64 and AArch32 specify. Note: AArch32 has 2 instruction sets (A32/ARM and T32/Thumb), like armv7-a does. AArch64 has A64. (I'm not giving thumb version numbers here but there are versioned vintages.) So 1 architecture (armv8-a) has at least 3 instruction sets when both AArch64 and AArch32 are implemented. AArch64 state: A64 AArch32 state: A32 and T32 There can be context switching between these states as I understand. (I'll not get into the NEON distinctions and such so the above is simplified.) armv8-a does not necessarily uniquely identify the interrupt controller or its software interface, as an example of variation that is not an instruction set issue: register interfaces to other hardware. ARM provides GIC-400 and GIC-500 and others. But the controller does not have to come from ARM. While Cortex-A53 has a default/reference interrupt controller(s), it is possible to build variations that use other ones as I understand. Similar points go for Cortex-A7. The other parts of a System On a Chip are for non-arm aspects and may have some mixed degree on commonality independently of ARM. But the kernel may deal with such specifics as well. > - The current proposal is to split the armv6 and armv7 into their own > "architectures" ARM defines these as distinct architectures. That is not a FreeBSD specific terminology. But much of the armv6 is common with armv7. armv7 architecture has more than armv6 architecture does: it is an update. Having armv7 implemented separately in FreeBSD means more completely/correctly identifying what is there compared to pretending it is an armv6. > FreeBSD has an Arm 64 bit kernel build. I don't see what the > TARGET_ARCH settings in the wiki and know little about it, but will > conjecture that it doesn't have a TARGET_ARCH=3Darmv8 (please correct = me > if I'm wrong). FreeBSD has TARGET=3Darm64 TARGET_ARCH=3Daarch64 . That combination is for armv8-A with AArch64 currently. Cortex-A32 is not supported because it lacks AArch64. FreeBSD's TARGET=3Darm64 TARGET_ARCH=3Daarch64 may grow to span armv8.1 or such as well for all I know. Cortex-A53 is one example of an armv8 implementation that the kernel supports (presuming certain interrupt controllers and such). There are others. > What I was trying to ask was: is the kernel development moving in a > direction that clearly indicates the differences in the instructions > vs the architectures (or have I grossly simplified the problem)? Will > it be possible to target a Cortex-A53 and build for 32 or 64 bit > support? Or is this just to fix RPi? Instruction sets are part of an architecture but not all of it. They are not independent of architecture. Talking of an overall architecture includes covering the instruction set(s). One architecture can have multiple instruction sets as part of it. TARGET=3Darm64 TARGET_ARCH=3Daarch64 may get a "lib32" (compat32) implementation someday if someone is motivated to do the work. That would enable AArch32 user processes. What exists now and will in the future is mostly tied to choices of volunteers that say "I'm going to provide " and then manage to complete whatever it was. (Clearly a "we are going to" is also an option.) A similar points would go for TARGET_ARCH=3Darmv7 supporting something like Cortex-A53 in AArch32 mode (Raspian like). So at this point no one knows if or when as far as I know. armv6 and armv7 architectures are strongly overlapping for what is in armv6. The GENERIC kernel for what is currently a TARGET_ARCH=3Darmv6 build actually builds for armv7 and will not work on armv6. One has to use a different kernel configuration than GENERIC for armv6 (such as the one for the older RPI vintage that was armv6 based). Identifying an armv7-a build as a armv6 build has odd consequences for software that tries to figure out what can be depended on. > In terms of Raspbian, I had assumed they were just supporting Aarch32 > across both processor models. Many of the drivers would be the same > source if they share components so I would think it would be "simple". > I didn't see anything in my brief look at it today to indicate > otherwise. For Cortex-A53: Raspian supports just AArch32 state, not AArch64 state for rpi2 V1.2 and RPI3. (I do not know if early boot is temporarily AArch64 or not.) For Cortex-A7: Cortex-A7 predates AArch32 and is armv7-a directly but AArch32 was designed to appear to be be nearly the same as armv7-a. So Raspian is supporting armv7-a directly for rpi2 V1.1 and V1.0. =3D=3D=3D Mark Millard markmi at dsl-only.net On Mon, Jun 12, 2017 at 2:07 PM, Warner Losh wrote: >=20 >=20 > On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard = wrote: >>=20 >>=20 >> On 2017-Jun-12, at 1:00 PM, Mark Millard = wrote: >>=20 >>> On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard >>> wrote: >>>> On 2017-Jun-12, at 12:16 PM, Russell Haley >>>> wrote: >>>>=20 >>>>> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard >>>> dsl-only.net> wrote: >>>>>>=20 >>>>>> On 2017-Jun-12, at 8:39 AM, Warner Losh = wrote: >>>>>>=20 >>>>>>> . . . >>>>>>>=20 >>>>>>> Plus, we aren't quite doing what Ian wanted. He wanted a full >>>>>>> rename. The >>>>>>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not = to >>>>>>> rename or >>>>>>> remove armv6. Sadly, that will still be there since the RPI >>>>>>> foundation >>>>>>> keeps finding new ways to repackage the rpi into new boards that = are >>>>>>> just >>>>>>> too cheap to ignore. >>>>>>=20 >>>>>> On 2017-Jun-12, at 6:59 AM, Andrew Turner >>>>>> wrote: >>>>>>=20 >>>>>>> I like this. My understanding is adding armv7 would also fix = many of >>>>>>> the currently broken ports that assume they are being built for = armv7 as >>>>>>> many Linux distros target ARMv7+. >>>>>>>=20 >>>>>>> It should also be noted the GENERIC kernel is likely to only = ever >>>>>>> target ARMv7+ even without an armv7 TARGET_ARCH. >>>>>>=20 >>>>>>=20 >>>>>> Hopefully the choices related to TARGET and TARGET_ARCH >>>>>> for armv7 end up identifying the context to port builds >>>>>> so that many would just automatically do the right thing. >>>>>>=20 >>>>>>=20 >>>>>> As for GENERIC: >>>>>>=20 >>>>>> powerpc has. . . >>>>>>=20 >>>>>> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc and GENERIC >>>>>> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 and GENERIC64 >>>>>>=20 >>>>>> So there is precedent for more than one GENERIC* >>>>>> for a family, with which one being appropriate >>>>>> being based on TARGET_ARCH. >>>>>>=20 >>>>>> For powerpc TARGET=3Dpowerpc implicitly uses >>>>>> TARGET_ARCH=3Dpowerpc when TARGET_ARCH is not >>>>>> specified (if I remember right). Which should >>>>>> be the default for armv6 vs. armv7 might go >>>>>> the other direction (TARGET_ARCH=3Darmv7 by >>>>>> default). >>>>>>=20 >>>>>>=20 >>>>>> Side note: >>>>>>=20 >>>>>> A caution about talking about "rpi2" as >>>>>> an example. . . >>>>>>=20 >>>>>> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based >>>>>> (so arm64/aarch64). (A BCM2837, not a BCM2836.) >>>>>> This dates about to something like 2014 based >>>>>> on the pictures showing the (c) notice on the >>>>>> boards. >>>>>>=20 >>>>>> V1.1 and before were armv7 (BCM2836) based. >>>>>>=20 >>>>>> Unless a kernel and world are made that can >>>>>> also configure/handle a Cortex-A53 in a >>>>>> armv7-like manor there will be two different >>>>>> GENERIC builds in order to span the "rpi2" >>>>>> family, based on just V1.2+ vs. V1.1 and >>>>>> before. >>>>>>=20 >>>>>> (A single, modern distribution of the official >>>>>> Raspbian software for the rpi2 does support >>>>>> all the V1.x boards if I understand right.) >>>>>=20 >>>>> I am confused. I don't see any documentation about Raspbian = supporting >>>>> 64 bit? >>>>=20 >>>> 64-bit Cortex-A53's can be configure to operate in a >>>> 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 >>>> and for RPI3. >>>>=20 >>>> Raspian does not (yet?) support a 64-bit mode (AArch64). >>>>=20 >>>> The Cortex-A53 can support either. As I understand it >>>> is possible for an OS to allow a user processes to be >>>> one or the other, different processes using the different >>>> modes. That does not mean that all operating systems >>>> bother to. >>>>=20 >>>> If I remember right the official Ubuntu for an ODroid-C2 >>>> allows both AArch64 and AArch32 user programs (and >>>> so processes, with shared library types tracking). >>>>=20 >>>>> =46rom Arm at >>>>> = https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php:= >>>>> "The Cortex-A53 supports the full ARMv8-A architecture. It not = only >>>>> runs 64-bit applications also seamlessly and efficiently runs = legacy >>>>> ARM 32-bit applications." >>>>>=20 >>>>> I assume that means it handles armv7-A without issue? (In fact, = many >>>>> on this board know it does) >>>>=20 >>>> I've not gone through the details but targeting AArch32 >>>> probably means targeting a subset of armv7. Or may be >>>> to support both requires targeting a common subset of both. >>>> (My guess is that AArch32 is the definition of a common >>>> subset for 32-bit, at least for user processes.) >>>>=20 >>>> Raspian targets just AArch32 on armv7 and Cortex-A53 >>>> (user space). (If I've got the definition of AArch32 >>>> right: otherwise a common subset.) >>>>=20 >>>> FreeBSD targets armv7 and AArch64 separately (via >>>> separate GENERIC kernels). I'm not aware of FreeBSD >>>> targeting AArch32 at all on cores capable of AArch64. >>>> FreeBSD possibly does not restrict itself to AArch32 >>>> (user processes) on armv7 if AArch32 is really a >>>> subset. >>>=20 >>> I thought all 64 bit Arm instructions are defined in armv8? >>=20 >> (I assume you are not trying to indicate armv8.1, armv8.2 >> and such. Cortex-A53 is older than those and so does not >> have the newer things involved.) >>=20 >> That Cortex-A53 allows armv8 64-bit arm code is not in >> dispute. But the operating system in involved in setting >> up what will actually work based on how it configures >> things and operates. Much of this is the kernel. >=20 >=20 > Correct. >=20 >>=20 >> Cortex-A53 also supports AArch32, i.e., 32 bit instructions. >> So that the 64-bit instructions all being there does not >> of itself prevent using a 32-bit mode instead. >>=20 >> (The kernel likely has to deal with more specifics of >> processor variations than user code does not. My notes >> are really about the user process model, not the all >> the kernel details.) >>=20 >> Raspian deals with armv7's that have no 64-bit support >> and with Cortex-A53's that do. It presents a user-process >> model that is 32-bit only, even on Cortex-A53's that allow >> for 64-bit (but do not required user programs to be AArch64 >> code). >>=20 >> Ubuntu for ODroid-C2 does not deal with armv7's but does >> allow both 64-bit (AArch64) and 32-bit (AArch32) user >> processes as I remember, on its Cortex-A53's. >>=20 >> FreeBSD armv7 does not support Cortext-A53 or anything >> that allows 64-bit (that allows AArch64). This is a kernel >> level issue. >=20 >=20 > Not a hugely difficult issue to fix, but one nobody had fixed... >=20 >>=20 >> FreeBSD aarch64 does not support having AArch32 user >> processes. Nor does its kernel support processors that >> do not support aarch64 (so it does not support armv7). >=20 >=20 > Executing a 32-bit /bin/cat on aarch64 level support exists outside = the > tree, according to the hallway track at BSDcan, so it will only be a = matter > of time before compat32 exists there I think. >=20 > There's a further complication is that the aarch32 unit of aarch64 > processors is optional. Not all of them have it, so that can be a = problem... > IIRC, the early aarch64 targets didn't have this feature... >=20 >>=20 >> These are simply examples of different choices about >> what combinations of the technical possibilities to >> put effort into supporting in the kernels (and >> possibly elsewhere). None of the alternatives is >> automatic. None are independent of software choices >> that must be made by each operating system. >=20 >=20 > Yes. They all require somebody to be interested in doing the work. >=20 > Warner >=20 >=20 >=20 From owner-freebsd-arm@freebsd.org Tue Jun 13 05:37: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 AD061D8E8FB for ; Tue, 13 Jun 2017 05:37:09 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E7DF6E430 for ; Tue, 13 Jun 2017 05:37:09 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id p189so62138669lfe.2 for ; Mon, 12 Jun 2017 22:37:09 -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=DzYlx/raTPkdCPbC3UPpiyzolvBC0r6asWEQwJqCxSQ=; b=J0NKh9FxfV7LUeImWYanKSnwxK9l1eal2/wrasM4DRH0gaUe24SQJfWwy5ynP8ZBBS v5xLagBxSUnednTN1FakHpYljOWh5tWObGaPxtFPcN8/rvq7Y4sDm81Vfurt/aAwCN6F 9bKy3NvgqDyJRzuqCPv/FN+QQfTRTTQxerIEBAnB8wQpEMwB7m6RIbacqQHEkGOaToC4 396FpEZD6scYA0B4bWPQon7bNDmUhbHSkxBarkY4kNFPiOgHC3kQzU1c1UzQ6ipxSUwq u9veAuDuteBUsWEyfskvm7IT0MDZGXkz9Y3Pj9uuChibHxICvqDwMoIg5dyeigViNGsM vApg== 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=DzYlx/raTPkdCPbC3UPpiyzolvBC0r6asWEQwJqCxSQ=; b=NxDmI42kDgLm0Ukjn84ai59q3JcLjQ3ElYxT7DBHReQXPHvjUH0b8BA+AMi11EtYkv XwO4zcS9tUPAxm/ZfMqIaQRCmGWG343FxlTiTpdHKFVDkZdD7tujbV67KkRN5DW2T/Is gbBRdyLKWvgN4Ns9H/kQ1QJYdnWmUVPRx3BKG7klqnqTPh049ot8IjMUll5K1we3dkqT T+ExUi56zgE5XZwpgd+EqOmx8lwmVl1OZOr5tCuFt7OML7wrAbpnoL2abz6x97U/MO7H WIreL5BxMa8eEAFsbYJB0rXzSLHilEJWbBYZIGeKT1KFdwvoWtUFI77b3ohVJeYVrAcV 5cew== X-Gm-Message-State: AODbwcAqGyOAW6xZoNGH5QIMNgmlepJA6nP3n7r5jnW9IluFZ1LitYVD T4ULVLha+Hzw2nP8QHYzjA338/NvJw== X-Received: by 10.46.13.2 with SMTP id 2mr18719485ljn.93.1497332226735; Mon, 12 Jun 2017 22:37:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.82.196 with HTTP; Mon, 12 Jun 2017 22:37:05 -0700 (PDT) In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> From: Russell Haley Date: Mon, 12 Jun 2017 22:37:05 -0700 Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Mark Millard Cc: "freebsd-arm@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: Tue, 13 Jun 2017 05:37:09 -0000 Thanks Mark! I'll chew on that for a couple of days. :D Russ On Mon, Jun 12, 2017 at 7:01 PM, Mark Millard wrote: > > On 2017-Jun-12, at 4:10 PM, Russell Haley wrote: > >> Okay, feel free to ignore me, I'm not going to get the time drill into >> the source code for my own questions so I don't expect anyone else >> too. However, I'll ask anyway. I'm too confused to try and inline >> these questions. Lets see if I understand: >> >> - armv7 does not support 64 bit instructions (according to Wikipedia? >> I claim no expertise.) > > It does not support AArch64 instructions but does support AArch32 > instructions (or is a good approximation). > > AArch32 was actually created later to be armv7-a like. > >> - FreeBSD has an armv6 "architecture" that is supports armv6 and armv7 >> on Pre-Cortex-A-53 processors that is not supported on A-53 through >> the emulated AArch32. > > There are actually architectures (by ARM's > definitions). . . > > ARMv6, ARMv6T2, ARMv6Z, ARMv6K, ARMV6-M > ARMv7-M, ARMv7E-M, ARMv7-R, ARMv7-A > ARMv8-A, ARMv8.1-A ARMv8.2-Am ARMV8.3-A, ARMv8-R, ARMv8-M > > I'm going to largely ignore much of > that variation in structure. > > ARM has continued to produce/make new variations for both > 32-bit and 64-bit in overlapping time frames. So the > "Pre-Cortex-A53" presumes to much about relative timing. > > Technically the old RPI2s (V1.1 and before) have > Cortex-A7's and the new V1.2's have Cortex-A53's. > RPI3 is also Cortex-A53 based. > > Cortex-A7 includes an implementation of armv7-A architecture > (but is not the only one). > Cortex-A53 includes an implementation of armv8-A architecture > (but is not the only one). > (Both include other things as well. And the System On A Chip has even > more stuff than the Cortex-A's in question.) > > Cortex-A's are specific CPUs/cores that are also > examples of the specific architecture(s) they implement. > > If a kernel supports armv7-a it can support a variety of > CPUs that all implement armv7-a architecture. It may not > support things in the CPUs that are beyond that > architecture. > > If a kernel supports armv8-a it can support a variety of > CPUs that all implement armv8-a architecture. It may not > support things in the CPUs that are beyond that > architecture. > > Note there are also issues of support of the System On > a Chip involved as well. More than ARM is involved > overall. > > > >> - Cortex A-53 can support armv8 (AArch64) and armv7 (AArch32) instructions > > As I remember armv8-a specifies: > > A) Optional support: AArch64 > (Cortex-A32 is ARMv8-A archtecture but only 32-bit) > (ARMv8-R architecture is always only 32-bit as I understand) > (ARMv8-M architecture is always only 32-bit as I understand) > B) Optional support: AArch32 > (Cortex-A35/53/57/72/73 are ARMv8-A and have both) > (Cortex-A55/75 are ARMV8.2-A architecture and have both) > (But variants can be produced that omit AArch32.) > C) Various things specific to armv8-a > might go beyond what AArch64 and > AArch32 specify. > > Note: AArch32 has 2 instruction sets > (A32/ARM and T32/Thumb), like armv7-a > does. AArch64 has A64. (I'm not giving > thumb version numbers here but there > are versioned vintages.) > > So 1 architecture (armv8-a) has at least > 3 instruction sets when both AArch64 > and AArch32 are implemented. > > AArch64 state: A64 > > AArch32 state: A32 and T32 > > There can be context switching between > these states as I understand. > > (I'll not get into the NEON distinctions > and such so the above is simplified.) > > armv8-a does not necessarily uniquely identify > the interrupt controller or its software > interface, as an example of variation that is > not an instruction set issue: register > interfaces to other hardware. ARM provides > GIC-400 and GIC-500 and others. But the > controller does not have to come from ARM. > > While Cortex-A53 has a default/reference > interrupt controller(s), it is possible to > build variations that use other ones as > I understand. > > Similar points go for Cortex-A7. > > The other parts of a System On a Chip are for non-arm > aspects and may have some mixed degree on commonality > independently of ARM. But the kernel may deal with > such specifics as well. > >> - The current proposal is to split the armv6 and armv7 into their own >> "architectures" > > ARM defines these as distinct architectures. > That is not a FreeBSD specific terminology. > But much of the armv6 is common with armv7. > > armv7 architecture has more than armv6 architecture does: > it is an update. Having armv7 implemented separately > in FreeBSD means more completely/correctly identifying > what is there compared to pretending it is an armv6. > >> FreeBSD has an Arm 64 bit kernel build. I don't see what the >> TARGET_ARCH settings in the wiki and know little about it, but will >> conjecture that it doesn't have a TARGET_ARCH=armv8 (please correct me >> if I'm wrong). > > FreeBSD has TARGET=arm64 TARGET_ARCH=aarch64 . That combination > is for armv8-A with AArch64 currently. Cortex-A32 is not > supported because it lacks AArch64. > > FreeBSD's TARGET=arm64 TARGET_ARCH=aarch64 may grow to span > armv8.1 or such as well for all I know. Cortex-A53 is one > example of an armv8 implementation that the kernel supports > (presuming certain interrupt controllers and such). There are > others. > >> What I was trying to ask was: is the kernel development moving in a >> direction that clearly indicates the differences in the instructions >> vs the architectures (or have I grossly simplified the problem)? Will >> it be possible to target a Cortex-A53 and build for 32 or 64 bit >> support? Or is this just to fix RPi? > > Instruction sets are part of an architecture but not all of it. > They are not independent of architecture. Talking of an overall > architecture includes covering the instruction set(s). One > architecture can have multiple instruction sets as part of it. > > TARGET=arm64 TARGET_ARCH=aarch64 may get a "lib32" (compat32) > implementation someday if someone is motivated to do the > work. That would enable AArch32 user processes. > > What exists now and will in the future is mostly tied to > choices of volunteers that say "I'm going to provide > " and then manage to complete whatever it was. > (Clearly a "we are going to" is also an option.) > > A similar points would go for TARGET_ARCH=armv7 supporting > something like Cortex-A53 in AArch32 mode (Raspian like). > > So at this point no one knows if or when as far as I know. > > armv6 and armv7 architectures are strongly overlapping for what > is in armv6. The GENERIC kernel for what is currently a > TARGET_ARCH=armv6 build actually builds for armv7 and will not > work on armv6. One has to use a different kernel configuration > than GENERIC for armv6 (such as the one for the older RPI vintage > that was armv6 based). > > Identifying an armv7-a build as a armv6 build has odd > consequences for software that tries to figure out what > can be depended on. > >> In terms of Raspbian, I had assumed they were just supporting Aarch32 >> across both processor models. Many of the drivers would be the same >> source if they share components so I would think it would be "simple". >> I didn't see anything in my brief look at it today to indicate >> otherwise. > > For Cortex-A53: Raspian supports just AArch32 state, > not AArch64 state for rpi2 V1.2 and RPI3. (I do not > know if early boot is temporarily AArch64 or not.) > > For Cortex-A7: Cortex-A7 predates AArch32 and is armv7-a > directly but AArch32 was designed to appear to be be > nearly the same as armv7-a. So Raspian is supporting > armv7-a directly for rpi2 V1.1 and V1.0. > > === > Mark Millard > markmi at dsl-only.net > > On Mon, Jun 12, 2017 at 2:07 PM, Warner Losh wrote: >> >> >> On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard wrote: >>> >>> >>> On 2017-Jun-12, at 1:00 PM, Mark Millard wrote: >>> >>>> On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard >>>> wrote: >>>>> On 2017-Jun-12, at 12:16 PM, Russell Haley >>>>> wrote: >>>>> >>>>>> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard >>>>> dsl-only.net> wrote: >>>>>>> >>>>>>> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: >>>>>>> >>>>>>>> . . . >>>>>>>> >>>>>>>> Plus, we aren't quite doing what Ian wanted. He wanted a full >>>>>>>> rename. The >>>>>>>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to >>>>>>>> rename or >>>>>>>> remove armv6. Sadly, that will still be there since the RPI >>>>>>>> foundation >>>>>>>> keeps finding new ways to repackage the rpi into new boards that are >>>>>>>> just >>>>>>>> too cheap to ignore. >>>>>>> >>>>>>> On 2017-Jun-12, at 6:59 AM, Andrew Turner >>>>>>> wrote: >>>>>>> >>>>>>>> I like this. My understanding is adding armv7 would also fix many of >>>>>>>> the currently broken ports that assume they are being built for armv7 as >>>>>>>> many Linux distros target ARMv7+. >>>>>>>> >>>>>>>> It should also be noted the GENERIC kernel is likely to only ever >>>>>>>> target ARMv7+ even without an armv7 TARGET_ARCH. >>>>>>> >>>>>>> >>>>>>> Hopefully the choices related to TARGET and TARGET_ARCH >>>>>>> for armv7 end up identifying the context to port builds >>>>>>> so that many would just automatically do the right thing. >>>>>>> >>>>>>> >>>>>>> As for GENERIC: >>>>>>> >>>>>>> powerpc has. . . >>>>>>> >>>>>>> TARGET=powerpc TARGET_ARCH=powerpc and GENERIC >>>>>>> TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 >>>>>>> >>>>>>> So there is precedent for more than one GENERIC* >>>>>>> for a family, with which one being appropriate >>>>>>> being based on TARGET_ARCH. >>>>>>> >>>>>>> For powerpc TARGET=powerpc implicitly uses >>>>>>> TARGET_ARCH=powerpc when TARGET_ARCH is not >>>>>>> specified (if I remember right). Which should >>>>>>> be the default for armv6 vs. armv7 might go >>>>>>> the other direction (TARGET_ARCH=armv7 by >>>>>>> default). >>>>>>> >>>>>>> >>>>>>> Side note: >>>>>>> >>>>>>> A caution about talking about "rpi2" as >>>>>>> an example. . . >>>>>>> >>>>>>> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based >>>>>>> (so arm64/aarch64). (A BCM2837, not a BCM2836.) >>>>>>> This dates about to something like 2014 based >>>>>>> on the pictures showing the (c) notice on the >>>>>>> boards. >>>>>>> >>>>>>> V1.1 and before were armv7 (BCM2836) based. >>>>>>> >>>>>>> Unless a kernel and world are made that can >>>>>>> also configure/handle a Cortex-A53 in a >>>>>>> armv7-like manor there will be two different >>>>>>> GENERIC builds in order to span the "rpi2" >>>>>>> family, based on just V1.2+ vs. V1.1 and >>>>>>> before. >>>>>>> >>>>>>> (A single, modern distribution of the official >>>>>>> Raspbian software for the rpi2 does support >>>>>>> all the V1.x boards if I understand right.) >>>>>> >>>>>> I am confused. I don't see any documentation about Raspbian supporting >>>>>> 64 bit? >>>>> >>>>> 64-bit Cortex-A53's can be configure to operate in a >>>>> 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 >>>>> and for RPI3. >>>>> >>>>> Raspian does not (yet?) support a 64-bit mode (AArch64). >>>>> >>>>> The Cortex-A53 can support either. As I understand it >>>>> is possible for an OS to allow a user processes to be >>>>> one or the other, different processes using the different >>>>> modes. That does not mean that all operating systems >>>>> bother to. >>>>> >>>>> If I remember right the official Ubuntu for an ODroid-C2 >>>>> allows both AArch64 and AArch32 user programs (and >>>>> so processes, with shared library types tracking). >>>>> >>>>>> From Arm at >>>>>> https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php: >>>>>> "The Cortex-A53 supports the full ARMv8-A architecture. It not only >>>>>> runs 64-bit applications also seamlessly and efficiently runs legacy >>>>>> ARM 32-bit applications." >>>>>> >>>>>> I assume that means it handles armv7-A without issue? (In fact, many >>>>>> on this board know it does) >>>>> >>>>> I've not gone through the details but targeting AArch32 >>>>> probably means targeting a subset of armv7. Or may be >>>>> to support both requires targeting a common subset of both. >>>>> (My guess is that AArch32 is the definition of a common >>>>> subset for 32-bit, at least for user processes.) >>>>> >>>>> Raspian targets just AArch32 on armv7 and Cortex-A53 >>>>> (user space). (If I've got the definition of AArch32 >>>>> right: otherwise a common subset.) >>>>> >>>>> FreeBSD targets armv7 and AArch64 separately (via >>>>> separate GENERIC kernels). I'm not aware of FreeBSD >>>>> targeting AArch32 at all on cores capable of AArch64. >>>>> FreeBSD possibly does not restrict itself to AArch32 >>>>> (user processes) on armv7 if AArch32 is really a >>>>> subset. >>>> >>>> I thought all 64 bit Arm instructions are defined in armv8? >>> >>> (I assume you are not trying to indicate armv8.1, armv8.2 >>> and such. Cortex-A53 is older than those and so does not >>> have the newer things involved.) >>> >>> That Cortex-A53 allows armv8 64-bit arm code is not in >>> dispute. But the operating system in involved in setting >>> up what will actually work based on how it configures >>> things and operates. Much of this is the kernel. >> >> >> Correct. >> >>> >>> Cortex-A53 also supports AArch32, i.e., 32 bit instructions. >>> So that the 64-bit instructions all being there does not >>> of itself prevent using a 32-bit mode instead. >>> >>> (The kernel likely has to deal with more specifics of >>> processor variations than user code does not. My notes >>> are really about the user process model, not the all >>> the kernel details.) >>> >>> Raspian deals with armv7's that have no 64-bit support >>> and with Cortex-A53's that do. It presents a user-process >>> model that is 32-bit only, even on Cortex-A53's that allow >>> for 64-bit (but do not required user programs to be AArch64 >>> code). >>> >>> Ubuntu for ODroid-C2 does not deal with armv7's but does >>> allow both 64-bit (AArch64) and 32-bit (AArch32) user >>> processes as I remember, on its Cortex-A53's. >>> >>> FreeBSD armv7 does not support Cortext-A53 or anything >>> that allows 64-bit (that allows AArch64). This is a kernel >>> level issue. >> >> >> Not a hugely difficult issue to fix, but one nobody had fixed... >> >>> >>> FreeBSD aarch64 does not support having AArch32 user >>> processes. Nor does its kernel support processors that >>> do not support aarch64 (so it does not support armv7). >> >> >> Executing a 32-bit /bin/cat on aarch64 level support exists outside the >> tree, according to the hallway track at BSDcan, so it will only be a matter >> of time before compat32 exists there I think. >> >> There's a further complication is that the aarch32 unit of aarch64 >> processors is optional. Not all of them have it, so that can be a problem... >> IIRC, the early aarch64 targets didn't have this feature... >> >>> >>> These are simply examples of different choices about >>> what combinations of the technical possibilities to >>> put effort into supporting in the kernels (and >>> possibly elsewhere). None of the alternatives is >>> automatic. None are independent of software choices >>> that must be made by each operating system. >> >> >> Yes. They all require somebody to be interested in doing the work. >> >> Warner >> >> >> > From owner-freebsd-arm@freebsd.org Tue Jun 13 08:28: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 C3840B95C46 for ; Tue, 13 Jun 2017 08:28:11 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5730D72C17 for ; Tue, 13 Jun 2017 08:28:11 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wr0-x243.google.com with SMTP id v104so27479732wrb.0 for ; Tue, 13 Jun 2017 01:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :cc:to; bh=i0Mtywchox1jaB5dTH9m1Dep0LXJY35VlDBJpIZBsx8=; b=M5BnLCfZtjLaXpJjSPsdWcsIFoHOnSkBtpFtDH/mchdSBFfkcSQ0yfeIf1ykrMgbZx mJts5j1kfq9E23MVU7g6XnqL7G2UN4ysIT122GY4BQbaS05AIRclp+vr8A4ihfGW3uw5 bBvFnOHlWNnKRfwVGLZ7P7sC9A2sMZyZdX4l2uuV8jMN8NiHFwemdRUpXFK/BX2dLTST l0OIgQfpKYKGgG2S+cDp5VwjuRHYXq0exv2zApBTEACHBCMsf3x5bp7ZykBQZIV/PuL8 uDgZ8rfA7ui9aMRTgEOCcJxm7Bz42v+UltkssnMftZLKhaHuT/EqAlnd7i/5w3UDfyE7 d69Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:cc:to; bh=i0Mtywchox1jaB5dTH9m1Dep0LXJY35VlDBJpIZBsx8=; b=BeGXvZ/CQhk5IM/1DFctTVSz0ClNNZHpHUHXLEvkNlaQsPdapKsO5cXGoYM5OeY51j 5Z9QblUAWtwTxMG7C9aGOkOUrDRJoV5otNu33UvE3SC3F29VZ1TdwziGv0Uj66AMkJvu pRWcsaF7LSUlaWQ8fA7ySoZdrIwIO4ctmwosGkJLX+M9F/fLe25Uwf9A0wgh0eyMHvzB iZNokyaTAPODcKjhBjgvETCOXoEiXLVsYjKXi+ZFMXGmoBzpMLSi8nDtQA3VfanwW+fW tIy0ZkxwWRN50ksg4aH4eF5dEbbkzXzM35JaK3ryzp2lRCmf6Y50+3styc/gC+jTJPql JPEA== X-Gm-Message-State: AKS2vOyXovzPvkbBi7e2i420lVNaYfcdwDDsaDRTzLQVvkqFunC21FA7 XYrIVAaFMRfr1g== X-Received: by 10.28.95.135 with SMTP id t129mr1765628wmb.61.1497342489135; Tue, 13 Jun 2017 01:28:09 -0700 (PDT) Received: from [10.235.112.254] ([80.12.27.254]) by smtp.gmail.com with ESMTPSA id 194sm23733wmx.27.2017.06.13.01.28.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 01:28:07 -0700 (PDT) From: Sylvain Garrigues Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Tue, 13 Jun 2017 10:28:06 +0200 Subject: Re: Creating armv7 MACHINE_ARCH Message-Id: Cc: Warner Losh , Mark Millard , "freebsd-arm@freebsd.org" To: Russell Haley X-Mailer: iPhone Mail (14F89) 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, 13 Jun 2017 08:28:11 -0000 Hi, > Le 13 juin 2017 =C3=A0 01:10, Russell Haley a =C3=A9= crit : >=20 > In terms of Raspbian, I had assumed they were just supporting Aarch32 > across both processor models. Many of the drivers would be the same > source if they share components so I would think it would be "simple". > I didn't see anything in my brief look at it today to indicate > otherwise. As far as I understand, the VCHIQ driver, needed for audio and accelerated v= ideo on RPI, is not trivial to port to arm64 as it communicates with the RPI= firmware which only expects and returns 32-bit pointers as of today (althou= gh they managed to hack around this kernel-wise for aarch64). Last I heard, gonzo has some WIP 64-bit VCIQ driver, not tested it yet.=20 I only have an RPI 2 v1.1, and as far as I understand, I shouldn't upgrade t= o RPI 2 v1.2 nor RPI 3 since our freebsd armv6 port does not support the cor= tex-a53 processor (I didn't know about that, just learnt it in this thread),= and the arm64 port does not support accelerated video (with VCHIQ) which I r= equire.=20 Also, I cannot use another arm board because there are no Mali GPU drivers f= or FreeBSD (neither for Vivante btw). Pretty sad to have to stick with my beloved v1.1 RPI2 if I don't want to che= at on FreeBSD :-) Sylvain From owner-freebsd-arm@freebsd.org Tue Jun 13 08:47:28 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 AD964BEE30E for ; Tue, 13 Jun 2017 08:47:28 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 3C275734D1 for ; Tue, 13 Jun 2017 08:47:28 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wr0-x229.google.com with SMTP id v104so127848208wrb.0 for ; Tue, 13 Jun 2017 01:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=RGH10pbDB86HVtBPbilvS5JwNX+ZIIFi5bHAWSKVLEw=; b=e7vzFhI36y5502pk91YnJ45obIXaQ0nTd3jmp9Duxe7Gkwjp+W5ceVMtWmUOPU77as dSh9fq83KQiyrFraSht3USK4JAmJ+xxRwofJgeXzIFmS2pIlliCZxv/jeAd6ehWo3ciQ wK8fQ/NHoNWnh2yYXQw0f91YM5+FaW3PEKKohZhSMp7pQ3NqHI2c1F8HiOEM8cW93iW1 YVuGwHMPmO1T4k+xjTulSH3GI7aW8nviL8b249UZ6stP3PPc7Ocnlwl/op/rYjLbyS94 VyJPpBHI5a1oAgKCTDYwiLApAMy/g/wbj8xGFhfMbfXx20J5sfsiu5Vd9MVAOGJNYDa5 AOmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=RGH10pbDB86HVtBPbilvS5JwNX+ZIIFi5bHAWSKVLEw=; b=kB243ScPPURDsLV7KzBRNfsJFaTOJriYSb3JvxUZ/RMpynMEYdECBYAJTKAwC9NQXW 1jkAbvGbmYMwhXRRLpcWi0wmdwP2Qe+a7DhLivUhL+XTc0vy6MMu6qf57USElV2ebLTF bHo54sY9xJLuEfchAMhV0smrITyym5wvyIx/a67OwGeDK/cpELfc13WaRh0JP0NS7+rj MLJULylNL8zG/lL8IsxiPEqfoHmiiOa4hm+RHJix03AMRzhI2+bYXAffPmmsTK/GkAME eZIkz2GH4hahY9k2mBjf80W7j6MwedlpAYGrvqDmk9RZj/i1yvUrwrCT3HAtCcPLI0td FoeQ== X-Gm-Message-State: AKS2vOwiudMFgSghDEHo7EsfJogd0vQ34dC1VTlnoKhoLEJioeAXIwU4 It9gdl3lvxUpJMJ4I4g= X-Received: by 10.28.71.76 with SMTP id u73mr10284057wma.105.1497343644054; Tue, 13 Jun 2017 01:47:24 -0700 (PDT) Received: from [172.21.11.105] (static-css-csd-147253.business.bouyguestelecom.com. [176.162.147.253]) by smtp.gmail.com with ESMTPSA id v5sm1840458wrd.22.2017.06.13.01.47.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 01:47:23 -0700 (PDT) From: Sylvain Garrigues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Tue, 13 Jun 2017 10:47:22 +0200 Subject: ARM foundation relationship - MALI drivers Message-Id: <34866AEA-01E1-4B68-B541-75B67ED6B3FC@gmail.com> To: freebsd-arm@freebsd.org X-Mailer: iPhone Mail (14F89) 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, 13 Jun 2017 08:47:28 -0000 Hello, Do we have contacts at the ARM foundation which could help us get MALI binar= y drivers for FreeBSD? Or sponsor this project (provided right NDAs are sign= ed)? It's sad that the only ARM board which we have GPU driver for is the Raspber= ry Pi and its Broadcom GPU. There are so many other boards with a MALI GPU.=20= I am stating the obvious but I think it is an adoption obstacle for our othe= rwise great ARM(64) port of our great OS.=20 Sylvain= From owner-freebsd-arm@freebsd.org Tue Jun 13 14:52: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 D3EA9BF69E7 for ; Tue, 13 Jun 2017 14:52:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id AC60E7EB60 for ; Tue, 13 Jun 2017 14:52:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-81.pn.at.cox.net [68.1.57.81]) by colo1.denninger.net (Postfix) with ESMTP id AFBA8274D1 for ; Tue, 13 Jun 2017 10:45:48 -0400 (EDT) Received: from [192.168.10.20] (D10.Denninger.Net [192.168.10.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id E56983595 for ; Tue, 13 Jun 2017 09:45:46 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Continuing problem with RPI USB-based network adapters Message-ID: Date: Tue, 13 Jun 2017 09:45:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030009000401070608000309" 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: Tue, 13 Jun 2017 14:52:10 -0000 This is a cryptographically signed message in MIME format. --------------ms030009000401070608000309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A good long while back I tried to run down an apparent problem with ue-based network drivers that seemed to be linked to having more than one interface instance attached to a physical interface -- such as using "ue0" for the "base" link and "ue0.2" for VLAN 2 on the same physical wir= e. The symptoms would be that the interface would "flap" every 10 or 20 minutes; it would go down an up without apparent cause. I can now quite-reliably report that it's not linked to VLANs; it also appears to show up *ANY* time there are multiple instances of an Ethernet interface up on the "ue" driver, irrespective of whether it's multiple instances on one interface (e.g. the VLAN example) OR multiple instances on multiple physical interfaces (e.g. ue0, ue1 on a plugged-in USB ethernet instance, etc.) I have _*41 days*_ of uptime at present on a single-instance device with ZERO flaps. But on a device with three instances, one with two physical interfaces in which one has a VLAN and base, the other just a base interface, it happens every few minutes. If I "down" the VLAN interface /it still happens./ Jun 13 09:04:53 IPGw kernel: ue0.3: link state changed to UP Jun 13 09:25:46 IPGw kernel: ue0: link state changed to DOWN Jun 13 09:25:46 IPGw kernel: ue0.3: link state changed to DOWN Jun 13 09:25:46 IPGw kernel: ue0: link state changed to UP Jun 13 09:25:46 IPGw kernel: ue0.3: link state changed to UP Jun 13 09:37:50 IPGw kernel: ue0: link state changed to DOWN Jun 13 09:37:50 IPGw kernel: ue0.3: link state changed to DOWN Jun 13 09:37:50 IPGw kernel: ue0: link state changed to UP Jun 13 09:37:50 IPGw kernel: ue0.3: link state changed to UP If there are logging entries that I can enable to try to find the cause of this it would be great -- this particular device is a RPI3 running -HEAD, but the issue traces back to at least 11.0 on the RPI2, where I saw it repeatedly close to a year ago, and there has apparently been no resolution. This looks PR-worthy but without some sort of trace on the REASON for the flap it's not so useful, thus the question as to whether I can dig up a logging option that will inform as to *why* the interface was marked down. It is NOT the switch port that the unit is plugged into OR the physical RPI3 hardware; I have swapped both the RPI3 board and switch port but the problem still exists and the other unit with one interface in service and NO flaps over 41 days of uptime is plugged into the same physical network switch. Thanks in advance. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030009000401070608000309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA2MTMxNDQ1MThaME8GCSqGSIb3DQEJBDFCBED/u1LS wEvydNeL5pwlWMU9nRDcGKOeR5kEmnH1PZCPd3Klh1Ozl7S6a0qIG7Rz4zwXq+jUEKutSO8F 50sIxxZLMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAVR0wa0KrG78E 6RSR6zQzgnsK8/iYjyCRE/40PdUHWiBpNTyKLr6WapwfijqYp8/vDKxzYBlPk5jKxx0pz2w3 95WrxNbJ2gW+74S3i8DFEoSZujyZYZ326dv/egC3GMijdf+sSEydGXFSSR0gvhYcwLTITUkz kIxe3rZEftuutODp1jof4HNTjiwwbQ/AcYh8pheV7UizTCD62kh2Yk04hxFAQ2nM1CP84BXF HCQ9M8Z9HWgoV+ofzDvuCeMnTQKVD+p6LBaPucjr1VbX9sBA3XUU11sEMy3jVgvnpTGaVRWN HSzGlUmRn2Z1D4I6CJZiA+6qmG7mVtKyBqFCMR7gI2ODs9GLPOR6AbZiFNsjlNs7YMSY52Yl lEaybxeCHz7Bc9hUkgjZMfDgYI/S4dzMdJMPEh25tO1c7x8Du1gCIGHv0iH9ieL42TxaaKiL kyiYHoFZMvdLOga9NpsWZIjWgeFqb5Vfw5VW4ZqdZFSuYVWR+dt/gvzZacAmBQ65DVvIH9Ml S0WaF0RAeNk81t4fy6AWkeUMl1CMLgXrD2RW9KvrOqjkpe9W48y/CRja9Smf2dro5MWRV+z8 nNvkbNwVyd6jL2BXo8sbzgEquGHPHxiXKsacYiv3as6banH9qBKu7KqewMmCeGKFIHDDpgvW 4dhMKuaHmXMgXsRS6zUcO8cAAAAAAAA= --------------ms030009000401070608000309-- From owner-freebsd-arm@freebsd.org Tue Jun 13 15:43:49 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 EB0ACBF7CCE for ; Tue, 13 Jun 2017 15:43:49 +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 CF022808D1 for ; Tue, 13 Jun 2017 15:43:49 +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 v5DFhnGS044395 for ; Tue, 13 Jun 2017 15:43:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 219956] FreeBSD 11.1-BETA1 panics on boot on SoftIron Overdrive 1000 Date: Tue, 13 Jun 2017 15:43:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org 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, 13 Jun 2017 15:43:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219956 Bug ID: 219956 Summary: FreeBSD 11.1-BETA1 panics on boot on SoftIron Overdrive 1000 Product: Base System Version: 11.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: emaste@freebsd.org Booting FreeBSD 11.1-BETA1 #0 r319728: Fri Jun 9 20:09:25 UTC 2017 memstick image results in: pcib2: at device 2.3 on pci0 pci2: on pcib2 mskc0: port 0x1000-0x10ff mem 0x40000000-0x40003fff at device 0.0 on pci2 msk0: on mskc0 msk0: Using defaults for TSO: 65518/35/2048 msk0: Ethernet address: e0:ff:f7:00:20:52 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow mskc0: couldn't set up interrupt handler Fatal data abort: x0: 0 x1: 0 x2: ffff0000008aa040 x3: ffff0000005d35eb x4: 5ae x5: 0 x6: ffff000000874300 x7: 40 x8: 0 x9: ffff000000756748 x10: ffff0000008aa040 x11: 0 x12: 1 x13: ffffffff x14: 0 x15: 6 x16: fffffffa x17: 0 x18: ffff000000010370 x19: 0 x20: ffff000000a56b90 x21: ffff000000a56ba8 x22: ffff000000708000 x23: ffff0000008aa040 x24: 0 x25: ffff0000007023e0 x26: 0 x27: 0 x28: 1 x29: ffff0000000103f0 x30: ffff0000000103f0 sp: ffff000000010370 lr: ffff00000028dd38 elr: ffff00000028df24 spsr: 800001c5 far: 3b8 esr: 96000004 [ thread pid 0 tid 100000 ] Stopped at __rw_wlock_hard+0x284: ldr w8, [x8, #952] db> bt Tracing pid 0 tid 100000 td 0xffff0000008aa040 db_trace_self() at db_stack_trace+0xec pc =3D 0xffff00000053c848 lr =3D 0xffff00000005c2d8 sp =3D 0xffff00000000fd10 fp =3D 0xffff00000000fd40 db_stack_trace() at db_command+0x23c pc =3D 0xffff00000005c2d8 lr =3D 0xffff00000005bf58 sp =3D 0xffff00000000fd50 fp =3D 0xffff00000000fe30 db_command() at db_command_loop+0x60 pc =3D 0xffff00000005bf58 lr =3D 0xffff00000005bd00 sp =3D 0xffff00000000fe40 fp =3D 0xffff00000000fe60 db_command_loop() at db_trap+0xf4 pc =3D 0xffff00000005bd00 lr =3D 0xffff00000005ec44 sp =3D 0xffff00000000fe70 fp =3D 0xffff000000010090 db_trap() at kdb_trap+0x190 pc =3D 0xffff00000005ec44 lr =3D 0xffff0000002d102c sp =3D 0xffff0000000100a0 fp =3D 0xffff000000010100 kdb_trap() at data_abort+0x198 pc =3D 0xffff0000002d102c lr =3D 0xffff000000554a9c sp =3D 0xffff000000010110 fp =3D 0xffff0000000101c0 data_abort() at handle_el1h_sync+0x74 pc =3D 0xffff000000554a9c lr =3D 0xffff00000053e874 sp =3D 0xffff0000000101d0 fp =3D 0xffff0000000102e0 handle_el1h_sync() at __rw_wlock_hard+0x94 pc =3D 0xffff00000053e874 lr =3D 0xffff00000028dd34 sp =3D 0xffff0000000102f0 fp =3D 0xffff0000000103f0 __rw_wlock_hard() at _rw_wlock_cookie+0x88 pc =3D 0xffff00000028dd34 lr =3D 0xffff00000028dbf8 sp =3D 0xffff000000010400 fp =3D 0xffff000000010420 _rw_wlock_cookie() at in_pcbpurgeif0+0x34 pc =3D 0xffff00000028dbf8 lr =3D 0xffff0000003a8f88 sp =3D 0xffff000000010430 fp =3D 0xffff000000010470 in_pcbpurgeif0() at in_ifdetach+0x1c pc =3D 0xffff0000003a8f88 lr =3D 0xffff00000039fcd4 sp =3D 0xffff000000010480 fp =3D 0xffff000000010490 in_ifdetach() at if_detach+0x5f4 pc =3D 0xffff00000039fcd4 lr =3D 0xffff0000003708f4 sp =3D 0xffff0000000104a0 fp =3D 0xffff000000010520 if_detach() at msk_detach+0xa8 pc =3D 0xffff0000003708f4 lr =3D 0xffff0000001041c4 sp =3D 0xffff000000010530 fp =3D 0xffff000000010570 msk_detach() at device_detach+0x88 pc =3D 0xffff0000001041c4 lr =3D 0xffff0000002c1d20 sp =3D 0xffff000000010580 fp =3D 0xffff000000010590 device_detach() at device_delete_child+0x18 pc =3D 0xffff0000002c1d20 lr =3D 0xffff0000002c1af8 sp =3D 0xffff0000000105a0 fp =3D 0xffff0000000105b0 device_delete_child() at mskc_detach+0x50 pc =3D 0xffff0000002c1af8 lr =3D 0xffff0000000fc0bc sp =3D 0xffff0000000105c0 fp =3D 0xffff0000000105e0 mskc_detach() at mskc_attach+0x7b8 pc =3D 0xffff0000000fc0bc lr =3D 0xffff0000000fbce8 sp =3D 0xffff0000000105f0 fp =3D 0xffff000000010680 mskc_attach() at device_attach+0x3d8 pc =3D 0xffff0000000fbce8 lr =3D 0xffff0000002c32d0 sp =3D 0xffff000000010690 fp =3D 0xffff0000000106e0 device_attach() at bus_generic_attach+0x50 pc =3D 0xffff0000002c32d0 lr =3D 0xffff0000002c44cc sp =3D 0xffff0000000106f0 fp =3D 0xffff000000010710 bus_generic_attach() at pci_attach+0xe0 pc =3D 0xffff0000002c44cc lr =3D 0xffff000000119914 sp =3D 0xffff000000010720 fp =3D 0xffff000000010750 pci_attach() at device_attach+0x3d8 pc =3D 0xffff000000119914 lr =3D 0xffff0000002c32d0 sp =3D 0xffff000000010760 fp =3D 0xffff0000000107b0 device_attach() at bus_generic_attach+0x50 pc =3D 0xffff0000002c32d0 lr =3D 0xffff0000002c44cc sp =3D 0xffff0000000107c0 fp =3D 0xffff0000000107e0 bus_generic_attach() at device_attach+0x3d8 pc =3D 0xffff0000002c44cc lr =3D 0xffff0000002c32d0 sp =3D 0xffff0000000107f0 fp =3D 0xffff000000010840 device_attach() at bus_generic_attach+0x50 pc =3D 0xffff0000002c32d0 lr =3D 0xffff0000002c44cc sp =3D 0xffff000000010850 fp =3D 0xffff000000010870 bus_generic_attach() at pci_attach+0xe0 pc =3D 0xffff0000002c44cc lr =3D 0xffff000000119914 sp =3D 0xffff000000010880 fp =3D 0xffff0000000108b0 pci_attach() at device_attach+0x3d8 pc =3D 0xffff000000119914 lr =3D 0xffff0000002c32d0 sp =3D 0xffff0000000108c0 fp =3D 0xffff000000010910 device_attach() at bus_generic_attach+0x50 pc =3D 0xffff0000002c32d0 lr =3D 0xffff0000002c44cc sp =3D 0xffff000000010920 fp =3D 0xffff000000010940 bus_generic_attach() at pci_host_generic_attach+0x76c pc =3D 0xffff0000002c44cc lr =3D 0xffff00000055cb8c sp =3D 0xffff000000010950 fp =3D 0xffff0000000109d0 pci_host_generic_attach() at device_attach+0x3d8 pc =3D 0xffff00000055cb8c lr =3D 0xffff0000002c32d0 sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a30 device_attach() at bus_generic_new_pass+0x120 pc =3D 0xffff0000002c32d0 lr =3D 0xffff0000002c4b94 sp =3D 0xffff000000010a40 fp =3D 0xffff000000010a70 bus_generic_new_pass() at bus_generic_new_pass+0xe4 pc =3D 0xffff0000002c4b94 lr =3D 0xffff0000002c4b58 sp =3D 0xffff000000010a80 fp =3D 0xffff000000010ab0 bus_generic_new_pass() at bus_generic_new_pass+0xe4 pc =3D 0xffff0000002c4b58 lr =3D 0xffff0000002c4b58 sp =3D 0xffff000000010ac0 fp =3D 0xffff000000010af0 bus_generic_new_pass() at bus_generic_new_pass+0xe4 pc =3D 0xffff0000002c4b58 lr =3D 0xffff0000002c4b58 sp =3D 0xffff000000010b00 fp =3D 0xffff000000010b30 bus_generic_new_pass() at bus_set_pass+0x8c pc =3D 0xffff0000002c4b58 lr =3D 0xffff0000002c0e04 sp =3D 0xffff000000010b40 fp =3D 0xffff000000010b70 bus_set_pass() at mi_startup+0xc8 pc =3D 0xffff0000002c0e04 lr =3D 0xffff000000231930 sp =3D 0xffff000000010b80 fp =3D 0xffff000000010bc0 mi_startup() at virtdone+0x54 pc =3D 0xffff000000231930 lr =3D 0xffff000000001084 sp =3D 0xffff000000010bd0 fp =3D 0x0000000000000000 db>=20 It is possible to work around by disabling MSI: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds...=20 Type '?' for a list of commands, 'help' for more detailed help. OK set hw.msk.msi_disable=3D1 OK boot ?[37m?[44mBooting...?[m Using DTB provided by EFI at 0x801fe00000. ... Welcome to FreeBSD! Please choose the appropriate terminal type for your system. Common console types are: ansi Standard ANSI terminal vt100 VT100 or compatible terminal xterm xterm terminal emulator (or compatible) cons25w cons25w terminal Console type [vt100]: --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Jun 13 19:00:58 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 6032EBFC4F5 for ; Tue, 13 Jun 2017 19:00:58 +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 4DBA43C13 for ; Tue, 13 Jun 2017 19:00:58 +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 v5DJ0w8i005023 for ; Tue, 13 Jun 2017 19:00:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 219956] FreeBSD 11.1-BETA1 panics on boot on SoftIron Overdrive 1000 (after mskc0: couldn't set up interrupt handler) Date: Tue, 13 Jun 2017 19:00:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 13 Jun 2017 19:00:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219956 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Jun 14 15:27:25 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 98915B947FD for ; Wed, 14 Jun 2017 15:27:25 +0000 (UTC) (envelope-from neerajpal09@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 1FA8268437 for ; Wed, 14 Jun 2017 15:27:25 +0000 (UTC) (envelope-from neerajpal09@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id v20so3967222lfa.1 for ; Wed, 14 Jun 2017 08:27:25 -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; bh=8vWWXovumSaLH/4T5/S+eKqbnImOlQd36ZrREqD9VWE=; b=ge0W9HtKDPvx/5aF5jkolSNldTr1Ayc4AvlXFYMbMvs4Z7oTPDdKU0JAaYhmVo+Kkd An4TnEPnC0NW9ltzzRkPdK8zmwOHdKk0n5FtUoJ5pQm0doDWsnhuiZTp55HgSONks77I M0PDaYsCECLETUalx9g2cxlyjCDKYjznllQCkbZ7DrV86YFqDspT1SZ3ck2D9QM4rtya l0eLb2uS6yM7aqzt44YjcGmjrzrqJ4RVxyhD7rM5yZmx0r9PZtmyXEYZkpKlGX0d9WqQ vsfCCpIX4Maci4eqxqXbOLp/kHlLfevuZN/VXO3MAnHWm2xs8B41GHXukAc4wtHFYjR8 pcLQ== 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; bh=8vWWXovumSaLH/4T5/S+eKqbnImOlQd36ZrREqD9VWE=; b=AN4B3lyPdO7QOR/BP8rVRv3s0OqTWVP/LfEUZ9E6qHmATBgAcLaQQ7YNYTiVHsU4Ku c3ufXapHRINEGVq1f/F9VgEFZQrxXyMxyPfEiFGBMHulDHFVbWApnMnfvnTfJhOCdXri RgWq1JQWeE4cfluxgjl0JBp4AuPNLIcPgEZ7MTbFt+PF1qWw4Iy2wltNM0gG0rC1IkzO cxKUhj4TO18yQDcj38KtuIw0WiHnS6pzWVJTztJ0vwpZfz2OFGFifRKXpl0pAvaCWRzb yoGsY+DKggUkWAXlP2lRPzfAUY843r/hnNRbp9la8pipCf+W28v+fOWO0qBQ4LwGY44x lu6Q== X-Gm-Message-State: AKS2vOzJCPOtQZZzB4Y/iysgojR/tGPj11qe25QTxlFCP1P8TQdxL+qh mQ0oxJmU5mgkdJQ/mRzYUDAvq1J2yQwx X-Received: by 10.46.33.164 with SMTP id h36mr216164lji.86.1497454043102; Wed, 14 Jun 2017 08:27:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.70 with HTTP; Wed, 14 Jun 2017 08:27:22 -0700 (PDT) From: Neeraj Pal Date: Wed, 14 Jun 2017 20:57:22 +0530 Message-ID: Subject: Support for Raspberry Pi 3 wifi broadcom driver in FreeBSD To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.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, 14 Jun 2017 15:27:25 -0000 Hello all, I want to know about wireless driver support for *Raspberry Pi 3*. Is there any support for Raspberry Pi 3 wireless Broadcom (*brcmfmac*) driver? Because i feels difficulty to set-up wireless in Raspberry Pi 3 (installed *FreeBSD*). *Details :[root@rpi3 /usr/home/raspberry]# *uname -a *FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318898M: Thu May 25 15:07:15 MDT 2017 raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarch6= 4/usr/src/sys/GENERIC arm64* --=20 Thank you, Neeraj Pal =E3=83=84 =EF=A3=AB +91-8130344470 The information contents contained in this electronic communication (including the contents of the enclosure(s) or attachment(s) if any) is intended exclusively and solely for the individual(s) or entity to which it is addressed and may contain information that is private, confidential, legally privileged material and exempted from disclosure. Any review, re transmission, dissemination, printing, copying or other use of, or taking any action in reliance on the contents of this information by person(s) or entities other than the intended recipient is strictly prohibited and may be unlawful. If you have received this communication in error, please notify by responding to this email or telephone and immediately and permanently delete all copies of this message and any attachments from your systems. This footnote confirms that this email message has been scanned for the presence of malicious code, vandals & computer viruses. The recipient should check this email and any attachments for the presence of viruses. Please consider the environment before printing this email. From owner-freebsd-arm@freebsd.org Wed Jun 14 15:33:48 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 D8A8AB949BB for ; Wed, 14 Jun 2017 15:33:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id ADF8268948 for ; Wed, 14 Jun 2017 15:33:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-81.pn.at.cox.net [68.1.57.81]) by colo1.denninger.net (Postfix) with ESMTP id 4F6A32734C for ; Wed, 14 Jun 2017 11:33:13 -0400 (EDT) Received: from [192.168.10.20] (D10.Denninger.Net [192.168.10.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 63B613823 for ; Wed, 14 Jun 2017 10:33:11 -0500 (CDT) Subject: Re: Support for Raspberry Pi 3 wifi broadcom driver in FreeBSD To: freebsd-arm@freebsd.org References: From: Karl Denninger Message-ID: <45135cbf-75c7-7a25-4578-9f7c62205e7b@denninger.net> Date: Wed, 14 Jun 2017 10:32:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080604040502080305020406" 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, 14 Jun 2017 15:33:48 -0000 This is a cryptographically signed message in MIME format. --------------ms080604040502080305020406 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/14/2017 10:27, Neeraj Pal wrote: > Hello all, > > I want to know about wireless driver support for *Raspberry Pi 3*. > > Is there any support for Raspberry Pi 3 wireless Broadcom (*brcmfmac*)= > driver? > Because i feels difficulty to set-up wireless in Raspberry Pi 3 (instal= led > *FreeBSD*). > > > > *Details :[root@rpi3 /usr/home/raspberry]# *uname -a > *FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318898M: Thu May 25= > 15:07:15 MDT 2017 > raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aa= rch64/usr/src/sys/GENERIC > arm64* Nope; you need to use a plug-in WiFi adapter on one of the USB ports (which do work.) The issue is, as I understand it, that the internal WiFi is on the SDIO bus and there is no SDIO driver; it thus can't attach. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080604040502080305020406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA2MTQxNTMyNDBaME8GCSqGSIb3DQEJBDFCBECPtZj7 LEnhnWTQhx9FKApYlg5MHGB5KpPlhxFNmiqo8X9lWJAn3JIq+aeNccbSKoJdRxayy47Ddp6k b4y1ZmtOMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAVG9yBDwPW4Bm xu5ogLiX5VjHhnaSNoBHfcHd9/55oIG6CKMg6Tyj93vSIfx9HcDF26Abn5hIi6lGo9vJvcqu XyjKzjMeu5Du/hkOZpB58DDQAqNB6tAYmk2GnSw0BWQlbGnCornqyqe2jTj83awbBvg5JgHq IOxI9WN1X5N7DZ2fLpGDCrQ/hKGtyU+FoSyaURpzYXUwVD5Nq1kfXxD6R3IqMJmtB4302kor Ev5j0R4GEK2v69ohirGVpKCQCIMb7kfBdP8jNwIERwTcFftMHqyOhfljVJVDuiqZZNbCdjew ts8pGjaowmgnBQ4OCWsudl3VQpCX79fhAIkpfMwgihSTeFbcn8TzkQ+y+7Lj/FWGcXxAcLWt ckTlAeCaA5MS1jLR2AWrohxiFQ3oPPc4RYgD4gqW+oTw9dbieWyKhBh0iti1Dyc+h/XsWNK+ VB/5AkIuKAz2ckHxIF0arBpIYlRXMMF+LxpD3cFs4yiANrAO0ufPOCG/p0d7y/Iv6I2yP3Xw fBIR9ywRHwU8rbmhu6OAvvzBMNh3jtnnsL/7EXJAk4XRpemw3Ug8pcaDjEeTRf5Co0CQQKWM sbL+q27xfJewtkKtQ75DiPb7KWNHBrm3Cngea5E/t35mbJ+MT44GRAwJC7bmVTSnMa/nxMMv a6DX8H3lf1FRt4JV4dnMJwkAAAAAAAA= --------------ms080604040502080305020406-- From owner-freebsd-arm@freebsd.org Wed Jun 14 16:17:16 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 6B142BEE1F4 for ; Wed, 14 Jun 2017 16:17:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A0B66EF37; Wed, 14 Jun 2017 16:17:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 30B92260858; Wed, 14 Jun 2017 18:17:14 +0200 (CEST) Subject: Re: Continuing problem with RPI USB-based network adapters To: Karl Denninger , "freebsd-arm@freebsd.org" , Benno Rice , Oleksandr Tymoshenko References: From: Hans Petter Selasky Message-ID: <0fab102c-6152-967e-5b70-99cbd897e757@selasky.org> Date: Wed, 14 Jun 2017 18:15:10 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US 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: Wed, 14 Jun 2017 16:17:16 -0000 On 06/13/17 16:45, Karl Denninger wrote: > A good long while back I tried to run down an apparent problem with > ue-based network drivers that seemed to be linked to having more than > one interface instance attached to a physical interface -- such as using > "ue0" for the "base" link and "ue0.2" for VLAN 2 on the same physical wire. > > The symptoms would be that the interface would "flap" every 10 or 20 > minutes; it would go down an up without apparent cause. > > I can now quite-reliably report that it's not linked to VLANs; it also > appears to show up *ANY* time there are multiple instances of an > Ethernet interface up on the "ue" driver, irrespective of whether it's > multiple instances on one interface (e.g. the VLAN example) OR multiple > instances on multiple physical interfaces (e.g. ue0, ue1 on a plugged-in > USB ethernet instance, etc.) > > I have _*41 days*_ of uptime at present on a single-instance device with > ZERO flaps. But on a device with three instances, one with two physical > interfaces in which one has a VLAN and base, the other just a base > interface, it happens every few minutes. If I "down" the VLAN interface > /it still happens./ > > Jun 13 09:04:53 IPGw kernel: ue0.3: link state changed to UP > Jun 13 09:25:46 IPGw kernel: ue0: link state changed to DOWN > Jun 13 09:25:46 IPGw kernel: ue0.3: link state changed to DOWN > Jun 13 09:25:46 IPGw kernel: ue0: link state changed to UP > Jun 13 09:25:46 IPGw kernel: ue0.3: link state changed to UP > Jun 13 09:37:50 IPGw kernel: ue0: link state changed to DOWN > Jun 13 09:37:50 IPGw kernel: ue0.3: link state changed to DOWN > Jun 13 09:37:50 IPGw kernel: ue0: link state changed to UP > Jun 13 09:37:50 IPGw kernel: ue0.3: link state changed to UP > > If there are logging entries that I can enable to try to find the cause > of this it would be great -- this particular device is a RPI3 running > -HEAD, but the issue traces back to at least 11.0 on the RPI2, where I > saw it repeatedly close to a year ago, and there has apparently been no > resolution. > > This looks PR-worthy but without some sort of trace on the REASON for > the flap it's not so useful, thus the question as to whether I can dig > up a logging option that will inform as to *why* the interface was > marked down. It is NOT the switch port that the unit is plugged into OR > the physical RPI3 hardware; I have swapped both the RPI3 board and > switch port but the problem still exists and the other unit with one > interface in service and NO flaps over 41 days of uptime is plugged into > the same physical network switch. Hi Karl, The link state changed events come from the PHY on the devices you have shown. This is handled by the so-called MII bus code in FreeBSD. sys/dev/mii/smscphy.c > static void > smscphy_status(struct mii_softc *sc) > { > struct mii_data *mii; > uint32_t bmcr, bmsr, status; > > mii = sc->mii_pdata; > mii->mii_media_status = IFM_AVALID; > mii->mii_media_active = IFM_ETHER; > > bmsr = PHY_READ(sc, MII_BMSR) | PHY_READ(sc, MII_BMSR); > if ((bmsr & BMSR_LINK) != 0) > mii->mii_media_status |= IFM_ACTIVE; I see the code is reading the MII_BMSR status register multiple times. Maybe this is to cover up some kind of bug. I suggest as a first step, change the two places where MII_BMSR is read to read it 4 times instead of two. Does it make any difference. Also I would suggest that you can add some prints to inspect the individual values of each MII_BMSR read, to see what is going on. CC'ed Benno and Oleksandr in case they have any suggestion. --HPS From owner-freebsd-arm@freebsd.org Thu Jun 15 05:22: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 3A54DC0A1DD for ; Thu, 15 Jun 2017 05:22:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 00A3B6478C for ; Thu, 15 Jun 2017 05:22:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id m47so4407833iti.0 for ; Wed, 14 Jun 2017 22:22:05 -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=c7SDsGfQ3MIXNYe3UPGjsyzJexFpuKUdrfpzJEIjwNU=; b=JS7TgMgYHcQgKrqkmMeOVx/wBWEDO9h5vDvcMbx+k1pwiaJbmBbI0vHUk+FQDbgKbT 41608TO+rQUzfy1damuol4kuKB/2ZoHyb3r+ZPtB9XXcnUqf7k1MbTnaWbYzoEcyneC2 i8hgDT0jTEq9/8At8OE8TyLjXMsGvfVUqSb9O3jdzx3vPtEgFGxq9V/mz3/T8SFph+Tu Dtv4VIfFh1aB24VONWaBZ4W6VoRTqtMjjyD/1Z/r5OxaPGVG0XQ5u5YjZYWAj8QZN4Oo HtNOWW5pAVCQGZaL1eyWtczFCUmyeUYWNYnDzgAxAI3SSPkuCrJZd1iq+G6tWJQOECPE FmbQ== 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=c7SDsGfQ3MIXNYe3UPGjsyzJexFpuKUdrfpzJEIjwNU=; b=MsM7Ji85ohwhFhr1S1LAlLQVBmUlYnUbQbuPHBGMLKShfkIeH1rfsEt+e/8DszwV+A 0oK2aXcVpTnvj+Al9thVZ+eFaeGZZBgBasCCbxW+H2hCxs+4AJtTw5EYxEui6ooQocHj +vkw0Ry1Jf7q4ZC4aRWfk8aTxSKQH2zlksVlOi9jYFk3lsRekeH99UTHyJrEXeIM6k6F F9WXp950z7e1aLrmjJTVNd+gTHBqqVmkyc2IRNbJdiWxOmedgmFCCJDYp1hgbQ6OeXQp eD5PzEjR+qOJU74NUC4XJFe3CKHrfbr5ZyPUn1PRSEtcORgiHHr7HO7NDX/A/oeBZgh0 o8gA== X-Gm-Message-State: AKS2vOxVZd7vWceqcN9zPGilPcVdgXFOJnXRtFX3KOoBpLp41hCgNnJn kbECfat/uQFe0mM9Ej5gMBYkm8z8X6kC X-Received: by 10.36.20.211 with SMTP id 202mr3516272itg.103.1497504125193; Wed, 14 Jun 2017 22:22:05 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Wed, 14 Jun 2017 22:22:04 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:402:51b7:c887:1fa6] From: Warner Losh Date: Wed, 14 Jun 2017 23:22:04 -0600 X-Google-Sender-Auth: GtH560ygrWJOP3yMCD4MDBlPriE Message-ID: Subject: Next up on creating armv7 MACHINE_ARCH: pre FCP stage To: "freebsd-arm@freebsd.org" , FreeBSD Release Engineering Team 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: Thu, 15 Jun 2017 05:22:06 -0000 On Thu, Jun 8, 2017 at 2:27 PM, Warner Losh wrote: > While the kernel doesn't really need an armv7 support, there will be a > better match to other systems if we create a armv7 MACHINE_ARCH. This will > be in addition to the armv6 MACHINE_ARCH we have today. This will allow us > to create a package set optimized for armv7 as well as armv6. While it is > true the RPI 1 is the only system that needs armv6 binaries, it's quite > popular and the Raspberry Pi folks keep creating new variants with the same > chip. It would also let us get the package stuff spun up and working before > we mess with armv6. > > This would also separate the fate of armv6 and armv7 support at a later > time, but the weak consensus I've heard appears to be that the time isn't > yet right to discuss retiring armv6 support... > I've created a new FCP for this. You can comment on it at https://github.com/freebsd/fcp/pull/6 but the FCP number may change since the allocation isn't official. I've created this on the belief that everybody here is either agnostic or fully supports this path. The FCP tries to enumerate the work and impact, but currently needs your help to flesh things out. I've done a first pass, but it's lame still. This is one of the first FCPs, so I'm going to use it a little as test case for the larger thing. There will be bumps. Feels may get bruised, but if so accept my apologies and help me do better in the future. I cc'd the re@ as a heads up that this may be coming down the pike and that discussions so far have been super hand-wavey on the RE@ side of things. I'd like to know what the actual impact will be so we can document it. At this stage, it's still in the draft stage and nothing is certain. This is my call for feedback, but call it 'pre-feedback' if I read FCP-0 wrong and am doing it wrong :) My gut tells me that to make my doc better, do it on the pull request. To raise serious issues that need to be discussed, reply to this message. To talk about the many flavors of Rpi, about unified releases, 32-bit ports to A-53, or any other odd tangents, please do that in arm@, but I'd humbly request a new subject. Comments? Warner From owner-freebsd-arm@freebsd.org Thu Jun 15 06:20: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 3EFE9C31219 for ; Thu, 15 Jun 2017 06:20:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 E9A6265D33 for ; Thu, 15 Jun 2017 06:20:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9922 invoked from network); 15 Jun 2017 06:20:57 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Jun 2017 06:20:57 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 15 Jun 2017 02:20:57 -0400 (EDT) Received: (qmail 27385 invoked from network); 15 Jun 2017 06:20:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Jun 2017 06:20:56 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3B215EC8F04; Wed, 14 Jun 2017 23:20:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage From: Mark Millard In-Reply-To: Date: Wed, 14 Jun 2017 23:20:51 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh 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: Thu, 15 Jun 2017 06:20:59 -0000 On 2017-Jun-14, at 10:22 PM, Warner Losh wrote: > On Thu, Jun 8, 2017 at 2:27 PM, Warner Losh wrote: >=20 >> While the kernel doesn't really need an armv7 support, there will be = a >> better match to other systems if we create a armv7 MACHINE_ARCH. This = will >> be in addition to the armv6 MACHINE_ARCH we have today. This will = allow us >> to create a package set optimized for armv7 as well as armv6. While = it is >> true the RPI 1 is the only system that needs armv6 binaries, it's = quite >> popular and the Raspberry Pi folks keep creating new variants with = the same >> chip. It would also let us get the package stuff spun up and working = before >> we mess with armv6. >>=20 >> This would also separate the fate of armv6 and armv7 support at a = later >> time, but the weak consensus I've heard appears to be that the time = isn't >> yet right to discuss retiring armv6 support... >>=20 >=20 > I've created a new FCP for this. You can comment on it at > https://github.com/freebsd/fcp/pull/6 but the FCP number may change = since > the allocation isn't official. I've created this on the belief that > everybody here is either agnostic or fully supports this path. The FCP > tries to enumerate the work and impact, but currently needs your help = to > flesh things out. I've done a first pass, but it's lame still. >=20 > This is one of the first FCPs, so I'm going to use it a little as test = case > for the larger thing. There will be bumps. Feels may get bruised, but = if > so accept my apologies and help me do better in the future. >=20 > I cc'd the re@ as a heads up that this may be coming down the pike and = that > discussions so far have been super hand-wavey on the RE@ side of = things. > I'd like to know what the actual impact will be so we can document it. = At > this stage, it's still in the draft stage and nothing is certain. This = is > my call for feedback, but call it 'pre-feedback' if I read FCP-0 wrong = and > am doing it wrong :) My gut tells me that to make my doc better, do it = on > the pull request. To raise serious issues that need to be discussed, = reply > to this message. >=20 > To talk about the many flavors of Rpi, about unified releases, 32-bit = ports > to A-53, or any other odd tangents, please do that in arm@, but I'd = humbly > request a new subject. >=20 > Comments? I booted Ubuntu Mate on a BPI-M3 and tried: $ uname -p armv7l $ uname -ap Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 = 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux I was actually thinking that a "hf" might show up in how they name things if it was a hard float based build. But looking I see in /lib/ : . . . drwxr-xr-x 3 root root 16384 Nov 4 2016 arm-linux-gnueabihf . . . lrwxrwxrwx 1 root root 30 Oct 14 2016 ld-linux-armhf.so.3 -> = arm-linux-gnueabihf/ld-2.23.so lrwxrwxrwx 1 root root 24 Apr 21 2016 ld-linux.so.3 -> = /lib/ld-linux-armhf.so.3 . . . and in /lib/arm-linux-gnueabihf/ : lrwxrwxrwx 1 root root 10 Oct 14 2016 = /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so so it appears armv7l was used for naming a hard float build in uname -p. Of course this does not check how uniform the various linux distributions are about such naming. Still it may mean that for linux-matching "armv7" might not be the right name for uname -p output. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jun 15 09:08:14 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 40380C796CD for ; Thu, 15 Jun 2017 09:08:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 5A3A76E6A0 for ; Thu, 15 Jun 2017 09:08:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 951 invoked from network); 15 Jun 2017 09:09:36 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Jun 2017 09:09:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 15 Jun 2017 05:08:11 -0400 (EDT) Received: (qmail 15842 invoked from network); 15 Jun 2017 09:08:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Jun 2017 09:08:11 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 02518EC8F04; Thu, 15 Jun 2017 02:08:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage From: Mark Millard In-Reply-To: Date: Thu, 15 Jun 2017 02:08:10 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> References: To: Warner Losh 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: Thu, 15 Jun 2017 09:08:14 -0000 On 2017-Jun-14, at 11:20 PM, Mark Millard = wrote: > On 2017-Jun-14, at 10:22 PM, Warner Losh wrote: >=20 >> . . . >> Comments? >=20 > I booted Ubuntu Mate on a BPI-M3 and tried: >=20 > $ uname -p > armv7l >=20 > $ uname -ap > Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 = 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux >=20 > I was actually thinking that a "hf" might > show up in how they name things if it was > a hard float based build. But looking I > see in /lib/ : >=20 > . . . > drwxr-xr-x 3 root root 16384 Nov 4 2016 arm-linux-gnueabihf > . . . > lrwxrwxrwx 1 root root 30 Oct 14 2016 ld-linux-armhf.so.3 -> = arm-linux-gnueabihf/ld-2.23.so > lrwxrwxrwx 1 root root 24 Apr 21 2016 ld-linux.so.3 -> = /lib/ld-linux-armhf.so.3 > . . . >=20 > and in /lib/arm-linux-gnueabihf/ : >=20 > lrwxrwxrwx 1 root root 10 Oct 14 2016 = /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so >=20 > so it appears armv7l was used for naming a > hard float build in uname -p. >=20 > Of course this does not check how uniform the > various linux distributions are about such > naming. >=20 > Still it may mean that for linux-matching "armv7" > might not be the right name for uname -p output. I tried another linux on the BPI-M3: gentoo . # uname -p ARMv7 Processor rev 5 (v7l) (Wow. Not what I expected.) # uname -pa Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 = UTC 2016 armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux # uname -m armv7l # uname -i sun8i # ls -l /lib/ld-* -rwxr-xr-x 1 root root 134192 Mar 26 2016 /lib/ld-2.21.so lrwxrwxrwx 1 root root 10 Mar 26 2016 /lib/ld-linux-armhf.so.3 -> = ld-2.21.so So again armv7l seems to be the base name used for a hardfloat little-endian context --although it appears that "uname -m" gives text more likely to be used in testing for how to configure to match the live context. "uname -p" seems far less standardized for its results. The same for "uname -i". =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jun 15 11:21: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 F040CD87D65 for ; Thu, 15 Jun 2017 11:21:01 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 CC27D71C0F for ; Thu, 15 Jun 2017 11:21:01 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-it0-x230.google.com with SMTP id l6so9203975iti.1 for ; Thu, 15 Jun 2017 04:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=PE+sxrAR5h5Q7i6dEpPuJRp/ogz2QuXIpWgqICu7uN0=; b=u1m00zowZzl6qfgA4cdBtt641BjIRCh4NXYDyZfGArj/NzZI5eH54kD66nZfl8IpQZ gaj7DzczgdFCm+AJ/dFKJHnQ8yurAm2CugwSvLP/PiWCMAW14xrGCQWgTfuxY8e6O+JW TvDaSAMlBfgjdJTTxake+55vWNT+xgayPq0M6O0TY07DK2oZsCKHvBjaHh8o6aVQPONF gyN38zHBqiumoEWl32/ooVR1cxfGK/EIZO440/pMTmKvX1yQBtZLUtmhWCk8A9yT34O1 WRR1Bc/h8OJ5gc1PQ+sRysmCgRhqfGscWaidogxWBdCKdsiJxXOGlWd9OkvVbmujUT0q YgfQ== 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:cc; bh=PE+sxrAR5h5Q7i6dEpPuJRp/ogz2QuXIpWgqICu7uN0=; b=SO7P9nsw3k/ymf8Q+V4fiuu9RiXIjklMDmo7BNMUocrV5lRe568WpO5SRjXux+otYm jaYN5q7ozh4veDVb1x8Jul954rWqaXQKkLtUXBFwvIXyZ3hME1xHanI+YB6DBfxawwAk ebD0u1j8EwhgA8HEsHGcDvSSbU4BmxWn/7V6VOb1l6MeDldZHO5kbHsIzUIfCGoy3tvN BUfnyc6TPsTjZxgHCBJ+ahHWCHlAc11T1nJToPNBQ/1sepx7KCkQBgbYwnOTLyWpmDEP WDHPKoPaYJ+HwzGP26qlvIp4Fsf7VKM250j3fH2N0kUtQNE/BtG8MqHcF+89vn1Lblj6 urSg== X-Gm-Message-State: AKS2vOwYJ9WduJFFcFOn8mpZao9TpfQZwTtxfQcm9Jm6UPES7mTFwVsm S0ejdASl4HaIu6l9rPg6M8y26r7k5PAN9jXCLA== X-Received: by 10.36.39.13 with SMTP id g13mr3080526ita.87.1497525660861; Thu, 15 Jun 2017 04:21:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.142 with HTTP; Thu, 15 Jun 2017 04:21:00 -0700 (PDT) From: Marcin Wojtas Date: Thu, 15 Jun 2017 13:21:00 +0200 Message-ID: Subject: HEADS UP: Marvell Armada 38x support in the tree To: freebsd-arm@freebsd.org Cc: Fabien Thomas , Rafal Jaworowski , Jim Thompson , Julien LUSIAK , Luiz Otavio O Souza 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: Thu, 15 Jun 2017 11:21:02 -0000 Hello all, Semihalf is happy to officially announce that starting from SVN revision r319914 FreeBSD is ready to run on Marvell Armada 38x system-on-a-chip family! With an easy availability of the development boards, such as SolidRun A388-Clearfog, this SoC family has a large ecosystem of various Marvell and third-party software stacks and wide open-source support (e.g. Linux, U-Boot, OpenWRT). From now on the FreeBSD project is full-fledged part of it. Because this port was originally supposed to be a base for a set of the UTM devices, also there was an effort to introduce a rich, production quality port. In the time of past months all features have made their way to FreeBSD-HEAD: * Single/dual-core ARM Cortex-A9 and platform initialization, incorporated into common Marvell code (sys/arm/mv), which was fixed/improved in many places * Optimised network controller support (sys/dev/neta) * Cascade interrupt controllers support (MPIC to GICv2) * SATA 3.0 * USB 3.0 * SDHCI 3.0 * USB 2.0 * RTC * Multiple ports PCIe support * Performance counters and fixes for ARMv7 HWMPC * I2C * GPIO * Marvell 88E6176 switch support (sys/dev/etherswitchcfg/e6000sw) This was a joined effort of Semihalf and Stormshield (main development sponsor), in particular: Fabien Thomas Arnaud Ysmal Zbigniew Bodek Michal Stanek Jan Dabros Bartosz Szczepanek Konrad Adamczyk Dominik Ermel Wojciech Macek Marcin Wojtas Also great thanks to Netgate for sponsoring and supporting great part of the upstream effort and providing the SDHCI support for the platform (by Luiz Otavio O Souza). Best regards, Marcin From owner-freebsd-arm@freebsd.org Thu Jun 15 12:09: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 E5D00D894FB for ; Thu, 15 Jun 2017 12:09:02 +0000 (UTC) (envelope-from fabien.thomas@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.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 9989D73343 for ; Thu, 15 Jun 2017 12:09:01 +0000 (UTC) (envelope-from fabien.thomas@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 42246376150A; Thu, 15 Jun 2017 13:53:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 325E83761507; Thu, 15 Jun 2017 13:53:39 +0200 (CEST) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eY5V24mmvqfh; Thu, 15 Jun 2017 13:53:39 +0200 (CEST) Received: from deadbeef.netasq.com (support1.stormshield.eu [91.212.116.2]) by work.stormshield.eu (Postfix) with ESMTPSA id 0A58237614FB; Thu, 15 Jun 2017 13:53:39 +0200 (CEST) From: Fabien Thomas Message-Id: <001F966D-74BE-47FD-9091-BABE282FB567@stormshield.eu> Content-Type: multipart/signed; boundary="Apple-Mail=_673883E0-FECE-4CAC-BC1E-952B1321ECF3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: HEADS UP: Marvell Armada 38x support in the tree Date: Thu, 15 Jun 2017 14:02:49 +0200 In-Reply-To: Cc: freebsd-arm@freebsd.org, Rafal Jaworowski , Jim Thompson , Julien LUSIAK , Luiz Otavio O Souza To: Marcin Wojtas References: 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: Thu, 15 Jun 2017 12:09:03 -0000 --Apple-Mail=_673883E0-FECE-4CAC-BC1E-952B1321ECF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Marcin for managing this project up to completion! > Le 15 juin 2017 =C3=A0 13:21, Marcin Wojtas a =C3=A9cr= it : >=20 > Hello all, >=20 > Semihalf is happy to officially announce that starting from SVN > revision r319914 FreeBSD is ready to run on Marvell Armada 38x > system-on-a-chip family! >=20 > With an easy availability of the development boards, such as SolidRun > A388-Clearfog, this SoC family has a large ecosystem of various > Marvell and third-party software stacks and wide open-source support > (e.g. Linux, U-Boot, OpenWRT). =46rom now on the FreeBSD project is > full-fledged part of it. Because this port was originally supposed to > be a base for a set of the UTM devices, also there was an effort to > introduce a rich, production quality port. >=20 > In the time of past months all features have made their way to = FreeBSD-HEAD: > * Single/dual-core ARM Cortex-A9 and platform initialization, > incorporated into common Marvell code (sys/arm/mv), which > was fixed/improved in many places > * Optimised network controller support (sys/dev/neta) > * Cascade interrupt controllers support (MPIC to GICv2) > * SATA 3.0 > * USB 3.0 > * SDHCI 3.0 > * USB 2.0 > * RTC > * Multiple ports PCIe support > * Performance counters and fixes for ARMv7 HWMPC > * I2C > * GPIO > * Marvell 88E6176 switch support (sys/dev/etherswitchcfg/e6000sw) >=20 > This was a joined effort of Semihalf and Stormshield (main development > sponsor), in particular: > Fabien Thomas > Arnaud Ysmal > Zbigniew Bodek > Michal Stanek > Jan Dabros > Bartosz Szczepanek > Konrad Adamczyk > Dominik Ermel > Wojciech Macek > Marcin Wojtas >=20 > Also great thanks to Netgate for sponsoring and supporting great part = of the > upstream effort and providing the SDHCI support for the platform > (by Luiz Otavio O Souza). >=20 > Best regards, > Marcin --Apple-Mail=_673883E0-FECE-4CAC-BC1E-952B1321ECF3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2TCCBEsw ggMzoAMCAQICBQCFKMv8MA0GCSqGSIb3DQEBCwUAMEkxCzAJBgNVBAYTAkZSMRQwEgYDVQQKDAtT VE9STVNISUVMRDEkMCIGA1UEAwwbU3Rvcm1zaGllbGQgVXNlcnMgQXV0aG9yaXR5MB4XDTE3MDIw MjE1MzgxNVoXDTE4MDIwMjE1MzgxNVowaDELMAkGA1UEBhMCRlIxFDASBgNVBAoMC1NUT1JNU0hJ RUxEMRYwFAYDVQQDDA1GYWJpZW4gVEhPTUFTMSswKQYJKoZIhvcNAQkBFhxmYWJpZW4udGhvbWFz QHN0b3Jtc2hpZWxkLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvcG3lOqK7r8E MrwBRgrqPcilxb4ZAhxJlKCvKcljh2Qd927kANC9KuUV5ei7+uIKDU8z4L+9Af+nf6/5EIAEfgCS 7wHWtTsdG3LNkH1OlQ8q7hn5ubBV33BNoEGxuqDtuA9o7rCAFLYnLbwJ17y/QMt+BeM+Q5MyNHTJ RTXmQtAoCxVOdyf/UKlWpblsKayzLG0pv26BwzTqnW7iw+KKzq+mOYhY0POdxJq9F4KMk6G7oTnb OY4DKylyw5eKkymjLF+JCm+A3rBRN/Mx/tM1LMMP/CLsKI8a825DgVmooymlVt7kO1E/u4BGJCHk 3hh4jmy4vJDrXIe4GV/IxXn6IQIDAQABo4IBGTCCARUwHQYDVR0OBBYEFGT3Onq/f9SVOYLDkEzL 17yV7OW7MB8GA1UdIwQYMBaAFKFthGyigIUFfHx1dYA0wRNbl9eBMAkGA1UdEwQCMAAwDgYDVR0P AQH/BAQDAgPoMBEGCWCGSAGG+EIBAQQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUH AwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cHM6Ly9wa2kubmV0YXNxLmNvbS9hdXRoL2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3QuY3JsMBEGA1UdIAQKMAgwBgYEVR0gADAnBgNVHREEIDAegRxmYWJp ZW4udGhvbWFzQHN0b3Jtc2hpZWxkLmV1MA0GCSqGSIb3DQEBCwUAA4IBAQAw/OyYHMucp1faAPkO fltcWDW3pW/VPFQ25j+u2Lll5B/U6JMh4+0i8XNNMvx7F4qNxBnja3CsibQGDICL0Guf+iZJUv8p txf5u3d9UiMmJrA7E4Ki+H3IPQuwe6HiuPkw86uEISW8iRgacPNsFbCe7I+l3WxzOHuw4/6feTJQ vRYsJeLQpHzMTrdSrkX5Uly2LqUyp6Ws47psiAgP2SP0z2bovgpK8qCFUWOu/Wk8Jt69Fb/AkNyv TO9aGY2mrSQvRsKW1r2u9lBT3PUIKWdrY5f1iNRbRoxE0w11UoE8T1S8tYaFh7DNhbQ05gIedWjS OCdPvbA/4If7WJt7UKzuMIIEhjCCAm6gAwIBAgIFANvM8O0wDQYJKoZIhvcNAQELBQAwSDELMAkG A1UEBhMCRlIxFDASBgNVBAoMC1NUT1JNU0hJRUxEMSMwIQYDVQQDDBpTdG9ybXNoaWVsZCBSb290 IEF1dGhvcml0eTAeFw0xNDA5MDQxNTA3MTBaFw0yNDA5MDExNTA3MTBaMEkxCzAJBgNVBAYTAkZS MRQwEgYDVQQKDAtTVE9STVNISUVMRDEkMCIGA1UEAwwbU3Rvcm1zaGllbGQgVXNlcnMgQXV0aG9y aXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwocFoAv+lVii+44FiN3gNrFb0XTs Lh3F7EQAF1VnZTAtMoIO7uORO/BoQJ6XZfEGyLu8f0NszquirbbKcAxCI5KDC02Z4Cy5Ro2CWT37 kqAuoZfUe70XeX/BYbt79MUP+78ymM+AvN+iBgq5N9YJqzztB9H8ZMsQjH4aE087nt6F1tSLJkMA qzjzrtmPNkADQ4W4n1i4yFiXrZ4+fGESkfNigbNxZW6sbadJovfiLMDLwgkUqE/jkQe9wpelEbe0 JuwXA/qp5CfbsJVAveHSJU9oV+Mm2P8P7LANexMONfH4MkQlkF84I2YGf11HMNlj/XSIIAOz4PnP 8XkTiR9c7wIDAQABo3YwdDAdBgNVHQ4EFgQUoW2EbKKAhQV8fHV1gDTBE1uX14EwHwYDVR0jBBgw FoAUuEKp+mdE8H/TYYzspcdQrrS97KMwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw EQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBCwUAA4ICAQBOgvc5LdienT5tii280UuqwSGG TRYtF+fYN3pENknOFFrKvgdy/Oo+cZ0EkZyDPwyldfkNlB21P6rIeHLaNn8E1elfmidO1bv2yRNa wDeACOFdusrX+1aAXAY1WSavKRzjKfxtnkB+xdcas5pevA6SpLuumlGpZHAvSDPNpuwFt2AMrw6G BAHIb+Ksi/KoVSy6eiza7vGToTBC4WS1peLpcP0hQzIXAUuiOMAuonI+9TCxkq6+tbzJLTHcEPgh hUOc+SW2sTOtVYMymsvPoJcPsU26Z4raw34ZMx7Nn3cDjrq977TZzbK3QVomD7HidpOFRg+6L+ZC E0GXJJmchf1fiK//2oCUBlbsIQ2Ql4Fzr643vhS2Ke7UPaYEry25bodQPssH8h5xSOJ+rWcvUg9z CA4FkeCsBSzNUJrdzUG99rZKvVZtI1HEFxX251iiwPZK8N5vDZgqoS+T86XznoGDnNECVnzEGpsX lsVzC5OriorEv//lan6QmuSced7fvQ5qDdfqG+Izqaz2l+rXwQa+XY2odsszxoxxAedlYFl8SBfZ QjNs+0MPsxW9jyHTXkoyJDRBYP9aKygAGuYEFwEMpzdiexPmi39ly4R3EtL/vcqIrDxMPfk2+Rdb kIfoM2A+SVFGHGFp3J1/ID/JOl/heZkP/NSKDS/yHo8SYMvy6DGCAqIwggKeAgEBMFIwSTELMAkG A1UEBhMCRlIxFDASBgNVBAoMC1NUT1JNU0hJRUxEMSQwIgYDVQQDDBtTdG9ybXNoaWVsZCBVc2Vy cyBBdXRob3JpdHkCBQCFKMv8MAkGBSsOAwIaBQCgggElMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDYxNTEyMDI0OVowIwYJKoZIhvcNAQkEMRYEFB0nLFEDAitK cw3XldFbMcXO4LRGMGEGCSsGAQQBgjcQBDFUMFIwSTELMAkGA1UEBhMCRlIxFDASBgNVBAoMC1NU T1JNU0hJRUxEMSQwIgYDVQQDDBtTdG9ybXNoaWVsZCBVc2VycyBBdXRob3JpdHkCBQCFKMv8MGMG CyqGSIb3DQEJEAILMVSgUjBJMQswCQYDVQQGEwJGUjEUMBIGA1UECgwLU1RPUk1TSElFTEQxJDAi BgNVBAMMG1N0b3Jtc2hpZWxkIFVzZXJzIEF1dGhvcml0eQIFAIUoy/wwDQYJKoZIhvcNAQEBBQAE ggEAQwTRjWYKXIGnjuxkEAUOTLDLo0lb433jsOl3/4B5AH8lnGDaSgtdxD7tpWk8shNVN8Wm/M2v OoB3h1lFlVJDzkKHEW3gwRInUvDcpuMFQK0zvqO8alQTyKZGUMfA9jZb2S+VbFK81p4TvrR0oMXI +M0UEN0hhigQ4NFgPKbRCIHV+liX2hWWDco7RPDenNrytZ+YO4muRysvHhKVYBJqHXdBS6Qxh9vq yojX0f0EsYfyiwjnYLA06HM3OWaZt7daZpTh9ZLhlkw8YkysuUO3EsAk4ULBi+RkAxRel5d0Gl7x svqlM0YC49ksdwQhD3v9PRKf4DP9Ll78/Ss4e8D68AAAAAAAAA== --Apple-Mail=_673883E0-FECE-4CAC-BC1E-952B1321ECF3-- From owner-freebsd-arm@freebsd.org Thu Jun 15 12:18: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 2F38BD8976C for ; Thu, 15 Jun 2017 12:18:17 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B321973739 for ; Thu, 15 Jun 2017 12:18:16 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 4711aa78; Thu, 15 Jun 2017 14:18:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=ax36vkx1AOm4rFBJmwyHdjgyjbE=; b=MqrATooXIyo5GSmnf898LjdhODuQ dtsjmcLRK8Bl9+bYPgL6+WW4JCLMZ0c/JPjHG0X5uHO2f689b+R4ouzVI72Qz4j1 Shel2CznPkgcRRu6aQNohz6fD5lV2Ebgk9NxDhl2jfcP46/Y2RhkdhdIDqrwy2Ju YIUTdGPdwXuM5WQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=q2pWOoZtPW+oHdoyF+P4C57qwnTgGHxwkgx2mZthMT93LInMWp9ONdTx rE5RbEVkeVnFFobKkbaaxijSbCThBcNXF8H8dTtQIyFlBsfdmfN2gLdFyLc6EgNN YxWmCHfjtiTS5ixNWP23Dysv4O28j9r9wcHD4qD3e4DL3TDM92U= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id d38be47a TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 15 Jun 2017 14:18:08 +0200 (CEST) Date: Thu, 15 Jun 2017 14:18:07 +0200 From: Emmanuel Vadot To: Marcin Wojtas Cc: freebsd-arm@freebsd.org, Luiz Otavio O Souza , Julien LUSIAK , Fabien Thomas Subject: Re: HEADS UP: Marvell Armada 38x support in the tree Message-Id: <20170615141807.6ad67d689bc9b7c4bc744ea2@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 15 Jun 2017 12:18:17 -0000 On Thu, 15 Jun 2017 13:21:00 +0200 Marcin Wojtas wrote: > Hello all, > > Semihalf is happy to officially announce that starting from SVN > revision r319914 FreeBSD is ready to run on Marvell Armada 38x > system-on-a-chip family! > > With an easy availability of the development boards, such as SolidRun > A388-Clearfog, this SoC family has a large ecosystem of various > Marvell and third-party software stacks and wide open-source support > (e.g. Linux, U-Boot, OpenWRT). From now on the FreeBSD project is > full-fledged part of it. Because this port was originally supposed to > be a base for a set of the UTM devices, also there was an effort to > introduce a rich, production quality port. > > In the time of past months all features have made their way to FreeBSD-HEAD: > * Single/dual-core ARM Cortex-A9 and platform initialization, > incorporated into common Marvell code (sys/arm/mv), which > was fixed/improved in many places > * Optimised network controller support (sys/dev/neta) > * Cascade interrupt controllers support (MPIC to GICv2) > * SATA 3.0 > * USB 3.0 > * SDHCI 3.0 > * USB 2.0 > * RTC > * Multiple ports PCIe support > * Performance counters and fixes for ARMv7 HWMPC > * I2C > * GPIO > * Marvell 88E6176 switch support (sys/dev/etherswitchcfg/e6000sw) > > This was a joined effort of Semihalf and Stormshield (main development > sponsor), in particular: > Fabien Thomas > Arnaud Ysmal > Zbigniew Bodek > Michal Stanek > Jan Dabros > Bartosz Szczepanek > Konrad Adamczyk > Dominik Ermel > Wojciech Macek > Marcin Wojtas > > Also great thanks to Netgate for sponsoring and supporting great part of the > upstream effort and providing the SDHCI support for the platform > (by Luiz Otavio O Souza). > > Best regards, > Marcin Hello, First thank you for working on it. What's the status with the DTS ? Do we still need the ones in sys/boot/fdt or can we use the ones in sys/gnu/dts ? I'm gonna clean the sys/boot/fdt soon after importing latest dts from linux (I'm waiting for 4.12 to be out). -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Jun 15 12:51: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 B8E5ED8A00E for ; Thu, 15 Jun 2017 12:51:11 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EAAB748D6 for ; Thu, 15 Jun 2017 12:51:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id bb2c9466; Thu, 15 Jun 2017 14:51:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=Q4A5NC/fNThmIjdtupVI4E/uQxI=; b=Ol0jHyNThb9hgY5SGBdayWWMJ8n/ RDRbXYND2i+Qdne1QWVEwS8MImCcxjVc4h1MpBvMgE9VfhdhE5i0PgoJ0xzpJfXU /fnp8Lxn2rdche9WMe8BqMx5qel6r9UWMJBaauVBOKC3hFuRuLWKoKimBrlC7bYe dzosTfUctpYkT9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=LHCZKR8kTLn0yoc1Ybupj76nKSv2AI5ok4o9mJOCaQfVAUW9D9lJetnd vh1UfaKd3kMAJsg93bi27nWRGbeiFBaDrU9W6mmWQ3JtU+cUswyJYetLiJGAJwOz yu0WKVv5/1SxKbNRusTi8lClS08fzHo4An3QpI7HWgXxNYlGCwI= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id f8bb9981 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 15 Jun 2017 14:51:07 +0200 (CEST) Date: Thu, 15 Jun 2017 14:51:07 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Warner Losh , "freebsd-arm@freebsd.org" Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage Message-Id: <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> In-Reply-To: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> References: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 15 Jun 2017 12:51:11 -0000 On Thu, 15 Jun 2017 02:08:10 -0700 Mark Millard wrote: > On 2017-Jun-14, at 11:20 PM, Mark Millard wrote: > > > On 2017-Jun-14, at 10:22 PM, Warner Losh wrote: > > > >> . . . > >> Comments? > > > > I booted Ubuntu Mate on a BPI-M3 and tried: > > > > $ uname -p > > armv7l > > > > $ uname -ap > > Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux > > > > I was actually thinking that a "hf" might > > show up in how they name things if it was > > a hard float based build. But looking I > > see in /lib/ : > > > > . . . > > drwxr-xr-x 3 root root 16384 Nov 4 2016 arm-linux-gnueabihf > > . . . > > lrwxrwxrwx 1 root root 30 Oct 14 2016 ld-linux-armhf.so.3 -> arm-linux-gnueabihf/ld-2.23.so > > lrwxrwxrwx 1 root root 24 Apr 21 2016 ld-linux.so.3 -> /lib/ld-linux-armhf.so.3 > > . . . > > > > and in /lib/arm-linux-gnueabihf/ : > > > > lrwxrwxrwx 1 root root 10 Oct 14 2016 /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so > > > > so it appears armv7l was used for naming a > > hard float build in uname -p. > > > > Of course this does not check how uniform the > > various linux distributions are about such > > naming. > > > > Still it may mean that for linux-matching "armv7" > > might not be the right name for uname -p output. > > I tried another linux on the BPI-M3: gentoo . > > # uname -p > ARMv7 Processor rev 5 (v7l) > > (Wow. Not what I expected.) > > # uname -pa > Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 UTC 2016 armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux > > # uname -m > armv7l > > # uname -i > sun8i > > # ls -l /lib/ld-* > -rwxr-xr-x 1 root root 134192 Mar 26 2016 /lib/ld-2.21.so > lrwxrwxrwx 1 root root 10 Mar 26 2016 /lib/ld-linux-armhf.so.3 -> ld-2.21.so > > So again armv7l seems to be the base name used for > a hardfloat little-endian context --although it > appears that "uname -m" gives text more likely to > be used in testing for how to configure to match > the live context. "uname -p" seems far less > standardized for its results. The same for > "uname -i". > > === > Mark Millard > markmi at dsl-only.net On both your linux you are using linux-sunxi which is a fork of the Allwinner kernel "maintained" by the sunxi community (and it is old). To have the proper values of uname one should test running linux vanilla kernel. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Jun 15 14:04:22 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 614F1D8B1DA for ; Thu, 15 Jun 2017 14:04:22 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 35B6B766BF for ; Thu, 15 Jun 2017 14:04:22 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-it0-x233.google.com with SMTP id m62so18858200itc.0 for ; Thu, 15 Jun 2017 07:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c3csNzmhjfhbc0qwb/K0Zc7d9oUINXZNCf4/7mcs8I0=; b=0BHEWzeAaNc50EX6fuZYn4cv6lzfLRBfR05DMe2rGRlKa/5Cvy/fUCakMYAf3zrdrz Uv1/0RFo+KglpWza/PQ9S0GVUFj1chxKXvPC7hEfnBLCl25o2fJfMnzZF0on/ZbM0g9q 2PWAlWYxzcfTybto7S3HYh1jXatNZ7WgUHRBicNvjBtxoEt7vWiPg/h6c0ZNaZt3eH9X qLPUqH4eXyAFsa+l8ubg5zLKdRIpMkVOLL3fDaK1tH9+a4FIK6vu80YT3h7kUipjJ03Z ZbMYI2bM6xVdPtO43eG9cDZD+3rgI7ilYWgM+XZ/8fnczEQpxrYi43FMrnHlyVr5PRd9 iKHQ== 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=c3csNzmhjfhbc0qwb/K0Zc7d9oUINXZNCf4/7mcs8I0=; b=i2dPl5tI1SNu26wrcu4BSVDJuH/T2LCzJUEU+bjuSg284RSKGMeKuqnBbuLSmXq8Zm XrlC3hQOt01vYPCkpOSjGGz9xrlf9jSMg67+ED+aq4RMUKO0rNzrqOlr3UK63e+DFFea i2M+dpVbfzbkPq3ZET2dIvum5mg/RxGOe/+d+jVpyp2eer7BqZSbT4MWigV9uEet9pqq o+rXKD9lha5EnyczwvQXbxATfZvk8J7WVUOPMN51SCcCWEowymKOoSkrUMqBavGvWwFr kUVOonzG6+xZdYw0GsPn6seLnGdms4w8gCe5JJBC6sEiHZXttfkq1JKqUgakvpeC25uA KaFA== X-Gm-Message-State: AKS2vOzc4Xx3LqsBGDwbtC9opFea3QaIDfh2XakDI3VQNH6ycEmpgIeE cS6UudJCPsY3U+IvQjaqRgehxzSb8dJT X-Received: by 10.36.219.197 with SMTP id c188mr5378592itg.17.1497535461048; Thu, 15 Jun 2017 07:04:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.142 with HTTP; Thu, 15 Jun 2017 07:04:20 -0700 (PDT) In-Reply-To: <20170615141807.6ad67d689bc9b7c4bc744ea2@bidouilliste.com> References: <20170615141807.6ad67d689bc9b7c4bc744ea2@bidouilliste.com> From: Marcin Wojtas Date: Thu, 15 Jun 2017 16:04:20 +0200 Message-ID: Subject: Re: HEADS UP: Marvell Armada 38x support in the tree To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org, Luiz Otavio O Souza , Julien LUSIAK , Fabien Thomas 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: Thu, 15 Jun 2017 14:04:22 -0000 Hi Emmanuel, > > First thank you for working on it. > > What's the status with the DTS ? Do we still need the ones in > sys/boot/fdt or can we use the ones in sys/gnu/dts ? > We cannot use 1:1 linux device trees (ours are based on v4.10, there was almost no work done after that), although we are very close to it. There are differences in PCIe ranges and also /soc - /soc/interregs simple-bus nodes ranges. Both would require big workarounds in generic code. On the other hand board dts files are basically the same in both OSs. Marcin > I'm gonna clean the sys/boot/fdt soon after importing latest dts from > linux (I'm waiting for 4.12 to be out). From owner-freebsd-arm@freebsd.org Thu Jun 15 15:40:52 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 CB9B3D8CA24 for ; Thu, 15 Jun 2017 15:40:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 8FA8C793E7 for ; Thu, 15 Jun 2017 15:40:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13741 invoked from network); 15 Jun 2017 15:40:50 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Jun 2017 15:40:50 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 15 Jun 2017 11:40:50 -0400 (EDT) Received: (qmail 27322 invoked from network); 15 Jun 2017 15:40:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Jun 2017 15:40:50 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7C404EC8A8B; Thu, 15 Jun 2017 08:40:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage From: Mark Millard In-Reply-To: <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> Date: Thu, 15 Jun 2017 08:40:48 -0700 Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> To: Emmanuel Vadot 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: Thu, 15 Jun 2017 15:40:52 -0000 On 2017-Jun-15, at 5:51 AM, Emmanuel Vadot = wrote: > On Thu, 15 Jun 2017 02:08:10 -0700 > Mark Millard wrote: >=20 >> On 2017-Jun-14, at 11:20 PM, Mark Millard = wrote: >>=20 >>> On 2017-Jun-14, at 10:22 PM, Warner Losh wrote: >>>=20 >>>> . . . >>>> Comments? >>>=20 >>> I booted Ubuntu Mate on a BPI-M3 and tried: >>>=20 >>> $ uname -p >>> armv7l >>>=20 >>> $ uname -ap >>> Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 = 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux >>>=20 >>> I was actually thinking that a "hf" might >>> show up in how they name things if it was >>> a hard float based build. But looking I >>> see in /lib/ : >>>=20 >>> . . . >>> drwxr-xr-x 3 root root 16384 Nov 4 2016 arm-linux-gnueabihf >>> . . . >>> lrwxrwxrwx 1 root root 30 Oct 14 2016 ld-linux-armhf.so.3 -> = arm-linux-gnueabihf/ld-2.23.so >>> lrwxrwxrwx 1 root root 24 Apr 21 2016 ld-linux.so.3 -> = /lib/ld-linux-armhf.so.3 >>> . . . >>>=20 >>> and in /lib/arm-linux-gnueabihf/ : >>>=20 >>> lrwxrwxrwx 1 root root 10 Oct 14 2016 = /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so >>>=20 >>> so it appears armv7l was used for naming a >>> hard float build in uname -p. >>>=20 >>> Of course this does not check how uniform the >>> various linux distributions are about such >>> naming. >>>=20 >>> Still it may mean that for linux-matching "armv7" >>> might not be the right name for uname -p output. >>=20 >> I tried another linux on the BPI-M3: gentoo . >>=20 >> # uname -p >> ARMv7 Processor rev 5 (v7l) >>=20 >> (Wow. Not what I expected.) >>=20 >> # uname -pa >> Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 = UTC 2016 armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux >>=20 >> # uname -m >> armv7l >>=20 >> # uname -i >> sun8i >>=20 >> # ls -l /lib/ld-* >> -rwxr-xr-x 1 root root 134192 Mar 26 2016 /lib/ld-2.21.so >> lrwxrwxrwx 1 root root 10 Mar 26 2016 /lib/ld-linux-armhf.so.3 = -> ld-2.21.so >>=20 >> So again armv7l seems to be the base name used for >> a hardfloat little-endian context --although it >> appears that "uname -m" gives text more likely to >> be used in testing for how to configure to match >> the live context. "uname -p" seems far less >> standardized for its results. The same for >> "uname -i". >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > On both your linux you are using linux-sunxi which is a fork of the > Allwinner kernel "maintained" by the sunxi community (and it is old). > To have the proper values of uname one should test running linux > vanilla kernel. They both reported (extracted from the earlier text that I sent): 3.4.39-BPI-M3-Kernel 3.4.39-BPI-M3-Kernel It is the same kernel version from the same group for the same hardware context as far as what each reported. While they may have varied the kernel for some reason without changing the version identification that is not want I would expect. I expected it was the Ubuntu vs. Gentoo code that makes the difference, not the kernel. I'm not aware of a modern vanilla kernel for the BPI-M3. =46rom what I can tell for little armv7 boards like this having older kernels is a common case and is something ports code would normally deal with upstream. It is not just sunxi as I understand. I may do more experiments and report those too. My notes are just information for Warner and others to consider. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jun 15 16:58:36 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 A0A18D8DDEB for ; Thu, 15 Jun 2017 16:58:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 652337BBE7 for ; Thu, 15 Jun 2017 16:58:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 664 invoked from network); 15 Jun 2017 16:58:34 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Jun 2017 16:58:34 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 15 Jun 2017 12:58:34 -0400 (EDT) Received: (qmail 6140 invoked from network); 15 Jun 2017 16:58:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Jun 2017 16:58:33 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 30D3DEC8B7B; Thu, 15 Jun 2017 09:58:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage From: Mark Millard In-Reply-To: Date: Thu, 15 Jun 2017 09:58:32 -0700 Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0F64C8AC-576B-4E6E-BAB4-44FE819F9B44@dsl-only.net> References: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> To: Emmanuel Vadot 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: Thu, 15 Jun 2017 16:58:36 -0000 On 2017-Jun-15, at 8:40 AM, Mark Millard wrote: > On 2017-Jun-15, at 5:51 AM, Emmanuel Vadot = wrote: >=20 >> On Thu, 15 Jun 2017 02:08:10 -0700 >> Mark Millard wrote: >>=20 >>> On 2017-Jun-14, at 11:20 PM, Mark Millard = wrote: >>>=20 >>>> On 2017-Jun-14, at 10:22 PM, Warner Losh wrote: >>>>=20 >>>>> . . . >>>>> Comments? >>>>=20 >>>> I booted Ubuntu Mate on a BPI-M3 and tried: >>>>=20 >>>> $ uname -p >>>> armv7l >>>>=20 >>>> $ uname -ap >>>> Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 = 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux >>>>=20 >>>> I was actually thinking that a "hf" might >>>> show up in how they name things if it was >>>> a hard float based build. But looking I >>>> see in /lib/ : >>>>=20 >>>> . . . >>>> drwxr-xr-x 3 root root 16384 Nov 4 2016 arm-linux-gnueabihf >>>> . . . >>>> lrwxrwxrwx 1 root root 30 Oct 14 2016 ld-linux-armhf.so.3 -> = arm-linux-gnueabihf/ld-2.23.so >>>> lrwxrwxrwx 1 root root 24 Apr 21 2016 ld-linux.so.3 -> = /lib/ld-linux-armhf.so.3 >>>> . . . >>>>=20 >>>> and in /lib/arm-linux-gnueabihf/ : >>>>=20 >>>> lrwxrwxrwx 1 root root 10 Oct 14 2016 = /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so >>>>=20 >>>> so it appears armv7l was used for naming a >>>> hard float build in uname -p. >>>>=20 >>>> Of course this does not check how uniform the >>>> various linux distributions are about such >>>> naming. >>>>=20 >>>> Still it may mean that for linux-matching "armv7" >>>> might not be the right name for uname -p output. >>>=20 >>> I tried another linux on the BPI-M3: gentoo . >>>=20 >>> # uname -p >>> ARMv7 Processor rev 5 (v7l) >>>=20 >>> (Wow. Not what I expected.) >>>=20 >>> # uname -pa >>> Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 = 13:47:01 UTC 2016 armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux >>>=20 >>> # uname -m >>> armv7l >>>=20 >>> # uname -i >>> sun8i >>>=20 >>> # ls -l /lib/ld-* >>> -rwxr-xr-x 1 root root 134192 Mar 26 2016 /lib/ld-2.21.so >>> lrwxrwxrwx 1 root root 10 Mar 26 2016 /lib/ld-linux-armhf.so.3 = -> ld-2.21.so >>>=20 >>> So again armv7l seems to be the base name used for >>> a hardfloat little-endian context --although it >>> appears that "uname -m" gives text more likely to >>> be used in testing for how to configure to match >>> the live context. "uname -p" seems far less >>> standardized for its results. The same for >>> "uname -i". >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>=20 >> On both your linux you are using linux-sunxi which is a fork of the >> Allwinner kernel "maintained" by the sunxi community (and it is old). >> To have the proper values of uname one should test running linux >> vanilla kernel. >=20 > They both reported (extracted from the earlier text > that I sent): >=20 > 3.4.39-BPI-M3-Kernel > 3.4.39-BPI-M3-Kernel >=20 > It is the same kernel version from the same group > for the same hardware context as far as what each > reported. >=20 > While they may have varied the kernel for some > reason without changing the version identification > that is not want I would expect. >=20 > I expected it was the Ubuntu vs. Gentoo code that > makes the difference, not the kernel. >=20 > I'm not aware of a modern vanilla kernel for the > BPI-M3. >=20 > =46rom what I can tell for little armv7 boards like > this having older kernels is a common case and > is something ports code would normally deal with > upstream. It is not just sunxi as I understand. >=20 > I may do more experiments and report those too. > My notes are just information for Warner and others > to consider. An FYI: I tried the following on both kernel7.img files (this was via macOS): $ strings /Volumes/BPI-BOOT/kernel7.img | grep -i sun8i | more $ strings /Volumes/BPI-BOOT/kernel7.img | grep -i armv7 | more Both came up empty. The strings reported by uname -p -m -i do not seem to be directly from the kernels. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jun 15 18:51: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 6D8E4B941A7 for ; Thu, 15 Jun 2017 18:51:12 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CE747FF65 for ; Thu, 15 Jun 2017 18:51:11 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1497552668; l=1337; s=domk; d=obsigna.com; h=To:Date:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type: From; bh=F/iEaD8jEDmunFG4XKSpRcnPCPmglbX4+njHeSQORAw=; b=n1t6O9ZDIi+bD4dTK9wDp2EK2YvSCyzsXdtFAHE/4wmdm5u2CabVNUpALiZBJkmirj P7Y8bIfhsfGPP4i8eo9nyT4hs7uCY0JdY1jh8MSwMNSajcdIxl06+MM6MizBrQECBs9T dD7FXtVxRvBzQuiDw9sbQ37SZZAyuhvHIdNHo= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGhIk99HlWww= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b1a3.virtua.com.br [187.2.177.163]) by smtp.strato.de (RZmta 40.9 DYNA|AUTH) with ESMTPSA id j0797at5FIp8CPD (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 15 Jun 2017 20:51:08 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 3539976F0B46 for ; Thu, 15 Jun 2017 15:51:05 -0300 (BRT) From: "Dr. Rolf Jansen" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Problems with pkg, svnlite and svn on both 12.0 BBB snapshots of June 2017 Message-Id: Date: Thu, 15 Jun 2017 15:51:04 -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: Thu, 15 Jun 2017 18:51:12 -0000 I subsequently deployed the June snapshots of FreeBSD 12.0 on my = Beaglebone Black, and in both cases I experience problems with pkg, = svnlite and with svn from the ports. # pkg -v --> Shared object "libarchive.so.6" not found, required by "pkg" I can get pkg working, after I do: # ln -s /usr/lib/libarchive.so.7 /usr/lib/libarchive.so.6 Any flavor of subversion is completely unusable now, I see various = errors in different situations: One of either: svn: E175003: Attempt to fetch capability 'depth' resulted in 'no' or: svn: E000022: Error converting entry in directory = '/root/install/my_tiny_project' to UTF-8 svn: E000022: Valid UTF-8 data (hex: 18 10) followed by invalid UTF-8 sequence (hex: e5 20 18 30) The working directories are not damaged, because I observe normal svn = operation on the very same ones, when I open those with svn on a 12.0 = snapshot from May 2017. Anyway, before I submit a burg report, I would like to ask whether I am = the only one, experiencing those problems, or if others see these as = well. May this be related to a broken SD card? Please can someone confirm that pkg and svnlite are working (or even = not) on the out-of-the-box snapshot = FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170612-r319859. Many thanks and best regards Rolf From owner-freebsd-arm@freebsd.org Thu Jun 15 20:16: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 06726B95CC7 for ; Thu, 15 Jun 2017 20:16:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 9E0A582BCF for ; Thu, 15 Jun 2017 20:16:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8664 invoked from network); 15 Jun 2017 20:20:00 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Jun 2017 20:20:00 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 15 Jun 2017 16:16:00 -0400 (EDT) Received: (qmail 21527 invoked from network); 15 Jun 2017 20:16:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Jun 2017 20:16:00 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6EEBEEC7B35; Thu, 15 Jun 2017 13:15:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage From: Mark Millard In-Reply-To: <0F64C8AC-576B-4E6E-BAB4-44FE819F9B44@dsl-only.net> Date: Thu, 15 Jun 2017 13:15:58 -0700 Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9F0F91FB-B4D4-4CD9-AA96-036A0DBB7E56@dsl-only.net> References: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> <0F64C8AC-576B-4E6E-BAB4-44FE819F9B44@dsl-only.net> To: Emmanuel Vadot 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: Thu, 15 Jun 2017 20:16:03 -0000 On 2017-Jun-15, at 9:58 AM, Mark Millard wrote: > On 2017-Jun-15, at 8:40 AM, Mark Millard = wrote: >=20 >=20 >> On 2017-Jun-15, at 5:51 AM, Emmanuel Vadot = wrote: >>=20 >>> On Thu, 15 Jun 2017 02:08:10 -0700 >>> Mark Millard wrote: >>>=20 >>>> On 2017-Jun-14, at 11:20 PM, Mark Millard = wrote: >>>>=20 >>>>> On 2017-Jun-14, at 10:22 PM, Warner Losh = wrote: >>>>>=20 >>>>>> . . . >>>>>> Comments? >>>>>=20 >>>>> I booted Ubuntu Mate on a BPI-M3 and tried: >>>>>=20 >>>>> $ uname -p >>>>> armv7l >>>>>=20 >>>>> $ uname -ap >>>>> Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 = 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux >>>>>=20 >>>>> I was actually thinking that a "hf" might >>>>> show up in how they name things if it was >>>>> a hard float based build. But looking I >>>>> see in /lib/ : >>>>>=20 >>>>> . . . >>>>> drwxr-xr-x 3 root root 16384 Nov 4 2016 arm-linux-gnueabihf >>>>> . . . >>>>> lrwxrwxrwx 1 root root 30 Oct 14 2016 ld-linux-armhf.so.3 -> = arm-linux-gnueabihf/ld-2.23.so >>>>> lrwxrwxrwx 1 root root 24 Apr 21 2016 ld-linux.so.3 -> = /lib/ld-linux-armhf.so.3 >>>>> . . . >>>>>=20 >>>>> and in /lib/arm-linux-gnueabihf/ : >>>>>=20 >>>>> lrwxrwxrwx 1 root root 10 Oct 14 2016 = /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so >>>>>=20 >>>>> so it appears armv7l was used for naming a >>>>> hard float build in uname -p. >>>>>=20 >>>>> Of course this does not check how uniform the >>>>> various linux distributions are about such >>>>> naming. >>>>>=20 >>>>> Still it may mean that for linux-matching "armv7" >>>>> might not be the right name for uname -p output. >>>>=20 >>>> I tried another linux on the BPI-M3: gentoo . >>>>=20 >>>> # uname -p >>>> ARMv7 Processor rev 5 (v7l) >>>>=20 >>>> (Wow. Not what I expected.) >>>>=20 >>>> # uname -pa >>>> Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 = 13:47:01 UTC 2016 armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux >>>>=20 >>>> # uname -m >>>> armv7l >>>>=20 >>>> # uname -i >>>> sun8i >>>>=20 >>>> # ls -l /lib/ld-* >>>> -rwxr-xr-x 1 root root 134192 Mar 26 2016 /lib/ld-2.21.so >>>> lrwxrwxrwx 1 root root 10 Mar 26 2016 /lib/ld-linux-armhf.so.3 = -> ld-2.21.so >>>>=20 >>>> So again armv7l seems to be the base name used for >>>> a hardfloat little-endian context --although it >>>> appears that "uname -m" gives text more likely to >>>> be used in testing for how to configure to match >>>> the live context. "uname -p" seems far less >>>> standardized for its results. The same for >>>> "uname -i". >>>>=20 >>>> =3D=3D=3D >>>> Mark Millard >>>> markmi at dsl-only.net >>>=20 >>> On both your linux you are using linux-sunxi which is a fork of the >>> Allwinner kernel "maintained" by the sunxi community (and it is = old). >>> To have the proper values of uname one should test running linux >>> vanilla kernel. >>=20 >> They both reported (extracted from the earlier text >> that I sent): >>=20 >> 3.4.39-BPI-M3-Kernel >> 3.4.39-BPI-M3-Kernel >>=20 >> It is the same kernel version from the same group >> for the same hardware context as far as what each >> reported. >>=20 >> While they may have varied the kernel for some >> reason without changing the version identification >> that is not want I would expect. >>=20 >> I expected it was the Ubuntu vs. Gentoo code that >> makes the difference, not the kernel. >>=20 >> I'm not aware of a modern vanilla kernel for the >> BPI-M3. >>=20 >> =46rom what I can tell for little armv7 boards like >> this having older kernels is a common case and >> is something ports code would normally deal with >> upstream. It is not just sunxi as I understand. >>=20 >> I may do more experiments and report those too. >> My notes are just information for Warner and others >> to consider. >=20 > An FYI: >=20 > I tried the following on both kernel7.img files > (this was via macOS): >=20 > $ strings /Volumes/BPI-BOOT/kernel7.img | grep -i sun8i | more >=20 > $ strings /Volumes/BPI-BOOT/kernel7.img | grep -i armv7 | more >=20 > Both came up empty. The strings reported by uname -p -m -i > do not seem to be directly from the kernels. Summary: for Ubunutu unless HAVE_SYSINFO and SI_ARCHITECTURE and SI_PLATFORM are defined, it uses struct utsname's machine member for all 3 of -m -p -i . This matches what Ubuntu Mate reported (all 3 matching). (I've not looked at Gentoo source yet.) Supporting details. . . The following is uname.c source from: Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main coreutils = 8.25-2ubuntu2 (dsc) [2,071 B] Get:2 http://ports.ubuntu.com/ubuntu-ports xenial/main coreutils = 8.25-2ubuntu2 (tar) [5,725 kB] Get:3 http://ports.ubuntu.com/ubuntu-ports xenial/main coreutils = 8.25-2ubuntu2 (diff) [28.0 kB] Ubuntu's source for uname.c has: if (toprint & (PRINT_KERNEL_NAME | PRINT_NODENAME | PRINT_KERNEL_RELEASE | PRINT_KERNEL_VERSION | PRINT_MACHINE)) { struct utsname name; struct utsname name; . . . if (uname (&name) =3D=3D -1) error (EXIT_FAILURE, errno, _("cannot get system name")); = if (toprint & PRINT_MACHINE) print_element (name.machine); . . . and later has: if (toprint & PRINT_PROCESSOR) { char *element =3D unknown; #if HAVE_SYSINFO && defined SI_ARCHITECTURE . . . #else { struct utsname u; uname(&u); element =3D u.machine; . . . } #endif #ifdef UNAME_PROCESSOR if (element =3D=3D unknown) { . . . So it appears that -m and -p are explicitly returning the same text (No SI_ARCHITECTURE). Similarly for even later: if (toprint & PRINT_HARDWARE_PLATFORM) { char *element =3D unknown; #if HAVE_SYSINFO && defined SI_PLATFORM . . . #else { struct utsname u; uname(&u); element =3D u.machine; if(strlen(element)=3D=3D4 && element[0]=3D=3D'i' && = element[2]=3D=3D'8' && element[3 ]=3D=3D'6') element[1]=3D'3'; } #endif #ifdef UNAME_HARDWARE_PLATFORM if (element =3D=3D unknown) { . . . So it appears that -m and -p and -i are explicitly returning the same text (No SI_ARCHITECTURE nor SI_PLATFORM). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jun 15 20:58:23 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 D196FBEEB2D for ; Thu, 15 Jun 2017 20:58:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 948AE84289 for ; Thu, 15 Jun 2017 20:58:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21063 invoked from network); 15 Jun 2017 20:58:21 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Jun 2017 20:58:21 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 15 Jun 2017 16:58:21 -0400 (EDT) Received: (qmail 32027 invoked from network); 15 Jun 2017 20:58:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Jun 2017 20:58:21 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EA569EC9281; Thu, 15 Jun 2017 13:58:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage From: Mark Millard In-Reply-To: <9F0F91FB-B4D4-4CD9-AA96-036A0DBB7E56@dsl-only.net> Date: Thu, 15 Jun 2017 13:58:20 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <07E0EC6D-5CC4-4359-A5CE-2FCDF82B01D7@dsl-only.net> References: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> <0F64C8AC-576B-4E6E-BAB4-44FE819F9B44@dsl-only.net> <9F0F91FB-B4D4-4CD9-AA96-036A0DBB7E56@dsl-only.net> To: Emmanuel Vadot 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: Thu, 15 Jun 2017 20:58:23 -0000 [After looking into the details my preliminary guess seems to be correct: the only dependable uname output among -m -p -i is for -m for linux. The uname.c code used varies from distribution to distribution. Below adds relevant gentoo uname.c source (a patch source) and gnu source. Previously I showed the relevant (and distinct) Ubuntu source.] On 2017-Jun-15, at 1:15 PM, Mark Millard wrote: > On 2017-Jun-15, at 9:58 AM, Mark Millard = wrote: >=20 >> On 2017-Jun-15, at 8:40 AM, Mark Millard = wrote: >>=20 >>=20 >>> On 2017-Jun-15, at 5:51 AM, Emmanuel Vadot wrote: >>>=20 >>>> On Thu, 15 Jun 2017 02:08:10 -0700 >>>> Mark Millard wrote: >>>>=20 >>>>> On 2017-Jun-14, at 11:20 PM, Mark Millard = wrote: >>>>>=20 >>>>>> On 2017-Jun-14, at 10:22 PM, Warner Losh = wrote: >>>>>>=20 >>>>>>> . . . >>>>>>> Comments? >>>>>>=20 >>>>>> I booted Ubuntu Mate on a BPI-M3 and tried: >>>>>>=20 >>>>>> $ uname -p >>>>>> armv7l >>>>>>=20 >>>>>> $ uname -ap >>>>>> Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May = 3 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux >>>>>>=20 >>>>>> I was actually thinking that a "hf" might >>>>>> show up in how they name things if it was >>>>>> a hard float based build. But looking I >>>>>> see in /lib/ : >>>>>>=20 >>>>>> . . . >>>>>> drwxr-xr-x 3 root root 16384 Nov 4 2016 arm-linux-gnueabihf >>>>>> . . . >>>>>> lrwxrwxrwx 1 root root 30 Oct 14 2016 ld-linux-armhf.so.3 = -> arm-linux-gnueabihf/ld-2.23.so >>>>>> lrwxrwxrwx 1 root root 24 Apr 21 2016 ld-linux.so.3 -> = /lib/ld-linux-armhf.so.3 >>>>>> . . . >>>>>>=20 >>>>>> and in /lib/arm-linux-gnueabihf/ : >>>>>>=20 >>>>>> lrwxrwxrwx 1 root root 10 Oct 14 2016 = /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so >>>>>>=20 >>>>>> so it appears armv7l was used for naming a >>>>>> hard float build in uname -p. >>>>>>=20 >>>>>> Of course this does not check how uniform the >>>>>> various linux distributions are about such >>>>>> naming. >>>>>>=20 >>>>>> Still it may mean that for linux-matching "armv7" >>>>>> might not be the right name for uname -p output. >>>>>=20 >>>>> I tried another linux on the BPI-M3: gentoo . >>>>>=20 >>>>> # uname -p >>>>> ARMv7 Processor rev 5 (v7l) >>>>>=20 >>>>> (Wow. Not what I expected.) >>>>>=20 >>>>> # uname -pa >>>>> Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 = 13:47:01 UTC 2016 armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux >>>>>=20 >>>>> # uname -m >>>>> armv7l >>>>>=20 >>>>> # uname -i >>>>> sun8i >>>>>=20 >>>>> # ls -l /lib/ld-* >>>>> -rwxr-xr-x 1 root root 134192 Mar 26 2016 /lib/ld-2.21.so >>>>> lrwxrwxrwx 1 root root 10 Mar 26 2016 = /lib/ld-linux-armhf.so.3 -> ld-2.21.so >>>>>=20 >>>>> So again armv7l seems to be the base name used for >>>>> a hardfloat little-endian context --although it >>>>> appears that "uname -m" gives text more likely to >>>>> be used in testing for how to configure to match >>>>> the live context. "uname -p" seems far less >>>>> standardized for its results. The same for >>>>> "uname -i". >>>>>=20 >>>>> =3D=3D=3D >>>>> Mark Millard >>>>> markmi at dsl-only.net >>>>=20 >>>> On both your linux you are using linux-sunxi which is a fork of the >>>> Allwinner kernel "maintained" by the sunxi community (and it is = old). >>>> To have the proper values of uname one should test running linux >>>> vanilla kernel. >>>=20 >>> They both reported (extracted from the earlier text >>> that I sent): >>>=20 >>> 3.4.39-BPI-M3-Kernel >>> 3.4.39-BPI-M3-Kernel >>>=20 >>> It is the same kernel version from the same group >>> for the same hardware context as far as what each >>> reported. >>>=20 >>> While they may have varied the kernel for some >>> reason without changing the version identification >>> that is not want I would expect. >>>=20 >>> I expected it was the Ubuntu vs. Gentoo code that >>> makes the difference, not the kernel. >>>=20 >>> I'm not aware of a modern vanilla kernel for the >>> BPI-M3. >>>=20 >>> =46rom what I can tell for little armv7 boards like >>> this having older kernels is a common case and >>> is something ports code would normally deal with >>> upstream. It is not just sunxi as I understand. >>>=20 >>> I may do more experiments and report those too. >>> My notes are just information for Warner and others >>> to consider. >>=20 >> An FYI: >>=20 >> I tried the following on both kernel7.img files >> (this was via macOS): >>=20 >> $ strings /Volumes/BPI-BOOT/kernel7.img | grep -i sun8i | more >>=20 >> $ strings /Volumes/BPI-BOOT/kernel7.img | grep -i armv7 | more >>=20 >> Both came up empty. The strings reported by uname -p -m -i >> do not seem to be directly from the kernels. >=20 > Summary: for Ubunutu unless HAVE_SYSINFO > and SI_ARCHITECTURE and SI_PLATFORM are > defined, it uses struct utsname's machine > member for all 3 of -m -p -i . This matches > what Ubuntu Mate reported (all 3 matching). >=20 > (I've not looked at Gentoo source yet.) >=20 > Supporting details. . . >=20 > The following is uname.c source from: >=20 > Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main coreutils = 8.25-2ubuntu2 (dsc) [2,071 B] > Get:2 http://ports.ubuntu.com/ubuntu-ports xenial/main coreutils = 8.25-2ubuntu2 (tar) [5,725 kB] > Get:3 http://ports.ubuntu.com/ubuntu-ports xenial/main coreutils = 8.25-2ubuntu2 (diff) [28.0 kB] >=20 > Ubuntu's source for uname.c has: >=20 > if (toprint > & (PRINT_KERNEL_NAME | PRINT_NODENAME | PRINT_KERNEL_RELEASE > | PRINT_KERNEL_VERSION | PRINT_MACHINE)) > { > struct utsname name; struct utsname name; > . . . > if (uname (&name) =3D=3D -1) > error (EXIT_FAILURE, errno, _("cannot get system name")); = if (toprint & PRINT_MACHINE) > print_element (name.machine); > . . . >=20 > and later has: >=20 > if (toprint & PRINT_PROCESSOR) > { > char *element =3D unknown; > #if HAVE_SYSINFO && defined SI_ARCHITECTURE > . . . > #else > { > struct utsname u; > uname(&u); > element =3D u.machine; > . . . > } > #endif > #ifdef UNAME_PROCESSOR > if (element =3D=3D unknown) > { > . . . >=20 > So it appears that -m and -p are > explicitly returning the same text > (No SI_ARCHITECTURE). >=20 > Similarly for even later: >=20 > if (toprint & PRINT_HARDWARE_PLATFORM) > { > char *element =3D unknown; > #if HAVE_SYSINFO && defined SI_PLATFORM > . . . > #else > { > struct utsname u; > uname(&u); > element =3D u.machine; > if(strlen(element)=3D=3D4 && element[0]=3D=3D'i' && = element[2]=3D=3D'8' && element[3 > ]=3D=3D'6') > element[1]=3D'3'; > } > #endif > #ifdef UNAME_HARDWARE_PLATFORM > if (element =3D=3D unknown) > { > . . . >=20 >=20 > So it appears that -m and -p and -i > are explicitly returning the same text > (No SI_ARCHITECTURE nor SI_PLATFORM). Turns out that has a patch instead of independent source. . . Gentoo patches the gnu uname.c source to be different, including: (from = https://dev.gentoo.org/~polynomial-c/dist/coreutils-8.26-patches-1.1.tar.x= z and its 003_all_coreutils-gentoo-uname.patch ) @@ -250,10 +369,14 @@ main (int argc, char **argv) if (toprint & PRINT_PROCESSOR) { char const *element =3D unknown; -#if HAVE_SYSINFO && defined SI_ARCHITECTURE +#if (HAVE_SYSINFO && defined SI_ARCHITECTURE) || defined (USE_PROCINFO) { static char processor[257]; +#if defined (USE_PROCINFO) + if (0 <=3D __linux_procinfo (PROCINFO_PROCESSOR, processor, = sizeof processor)) +#else if (0 <=3D sysinfo (SI_ARCHITECTURE, processor, sizeof = processor)) +#endif element =3D processor; } #endif @@ -306,9 +429,13 @@ main (int argc, char **argv) if (element =3D=3D unknown) { static char hardware_platform[257]; +#if defined (USE_PROCINFO) + if (0 <=3D __linux_procinfo (PROCINFO_HARDWARE_PLATFORM, = hardware_platform, sizeof hardware_platform)) +#else size_t s =3D sizeof hardware_platform; static int mib[] =3D { CTL_HW, UNAME_HARDWARE_PLATFORM }; if (sysctl (mib, 2, hardware_platform, &s, 0, 0) >=3D 0) +#endif element =3D hardware_platform; } #endif The ubuntu source uname.c source I reported earlier does not match what is seen via the gnu history at: = http://git.savannah.gnu.org/gitweb/?p=3Dcoreutils.git;a=3Dhistory;f=3Dsrc/= uname.c;h=3D6378ab7342e5b46e686d719573af99475cc9d69f;hb=3D3df84f0492a97e07= fe4de62bd2ed34e4dd3045ef I'm using version 8.27 of coreutils source below. . . if (toprint & PRINT_PROCESSOR) { char const *element =3D unknown; #if HAVE_SYSINFO && defined SI_ARCHITECTURE { static char processor[257]; if (0 <=3D sysinfo (SI_ARCHITECTURE, processor, sizeof = processor)) element =3D processor; } #endif #ifdef UNAME_PROCESSOR if (element =3D=3D unknown) { static char processor[257]; size_t s =3D sizeof processor; static int mib[] =3D { CTL_HW, UNAME_PROCESSOR }; if (sysctl (mib, 2, processor, &s, 0, 0) >=3D 0) element =3D processor; # ifdef __APPLE__ . . . # endif } #endif if (! (toprint =3D=3D UINT_MAX && element =3D=3D unknown)) print_element (element); } if (toprint & PRINT_HARDWARE_PLATFORM) { char const *element =3D unknown; #if HAVE_SYSINFO && defined SI_PLATFORM { static char hardware_platform[257]; if (0 <=3D sysinfo (SI_PLATFORM, hardware_platform, sizeof hardware_platform)) element =3D hardware_platform; } #endif #ifdef UNAME_HARDWARE_PLATFORM if (element =3D=3D unknown) { static char hardware_platform[257]; size_t s =3D sizeof hardware_platform; static int mib[] =3D { CTL_HW, UNAME_HARDWARE_PLATFORM }; if (sysctl (mib, 2, hardware_platform, &s, 0, 0) >=3D 0) element =3D hardware_platform; } #endif if (! (toprint =3D=3D UINT_MAX && element =3D=3D unknown)) print_element (element); } =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jun 15 22:35: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 C06BABF09EE for ; Thu, 15 Jun 2017 22:35:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 217F83480 for ; Thu, 15 Jun 2017 22:35:03 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 9b9bd8d5; Fri, 16 Jun 2017 00:35:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; s=mail; bh=Msy1L+ 9soeV2BaIh2xQCY/SJnA4=; b=AjTAidfzo7TLt3Ax5QOjwuOat4pJjlm/yH1iII /MGKycFFzmjV/+t25hQuidheRF+9fxvarZV75o4NUrfjFcbwJtI6af/eZxK/p+xl mcM1Lxw6EOzwlQ+8zn218a0B+30jVA0CiT2idKr3FlJuLqde8/1Ful34gT75FKiZ NRbdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; q=dns; s=mail; b= hpnMJ9AVM4+6CD8fExxZ/on9ejOc/uZaTIhR2Pc9VvEa84OJNFWc/nVEGpRj/+YN 2wOrzAXBhmcYKhqjD8Je5V565/p+PdtXSHh0Pxx90e1cqJrzTVC4+kE91PfVe6lr IgCsBq58FIDte7hMm7WrqbaMW7bowPYTSNsCgoWx0RM= Received: from webmail.megadrive.org (www1.blih.net [212.83.177.180]) by mail.blih.net (OpenSMTPD) with ESMTP id 56c99883; Fri, 16 Jun 2017 00:35:00 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 16 Jun 2017 00:35:00 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Warner Losh , freebsd-arm@freebsd.org Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage Organization: Bidouilliste In-Reply-To: References: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> Message-ID: <290f9213ac2b227442c68cb0e3f7fdd5@megadrive.org> X-Sender: manu@bidouilliste.com User-Agent: Roundcube Webmail/1.1.1 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, 15 Jun 2017 22:35:04 -0000 On 2017-06-15 17:40, Mark Millard wrote: > On 2017-Jun-15, at 5:51 AM, Emmanuel Vadot > wrote: > >> On Thu, 15 Jun 2017 02:08:10 -0700 >> Mark Millard wrote: >> >>> On 2017-Jun-14, at 11:20 PM, Mark Millard >>> wrote: >>> >>>> On 2017-Jun-14, at 10:22 PM, Warner Losh wrote: >>>> >>>>> . . . >>>>> Comments? >>>> >>>> I booted Ubuntu Mate on a BPI-M3 and tried: >>>> >>>> $ uname -p >>>> armv7l >>>> >>>> $ uname -ap >>>> Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 >>>> 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux >>>> >>>> I was actually thinking that a "hf" might >>>> show up in how they name things if it was >>>> a hard float based build. But looking I >>>> see in /lib/ : >>>> >>>> . . . >>>> drwxr-xr-x 3 root root 16384 Nov 4 2016 arm-linux-gnueabihf >>>> . . . >>>> lrwxrwxrwx 1 root root 30 Oct 14 2016 ld-linux-armhf.so.3 -> >>>> arm-linux-gnueabihf/ld-2.23.so >>>> lrwxrwxrwx 1 root root 24 Apr 21 2016 ld-linux.so.3 -> >>>> /lib/ld-linux-armhf.so.3 >>>> . . . >>>> >>>> and in /lib/arm-linux-gnueabihf/ : >>>> >>>> lrwxrwxrwx 1 root root 10 Oct 14 2016 >>>> /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so >>>> >>>> so it appears armv7l was used for naming a >>>> hard float build in uname -p. >>>> >>>> Of course this does not check how uniform the >>>> various linux distributions are about such >>>> naming. >>>> >>>> Still it may mean that for linux-matching "armv7" >>>> might not be the right name for uname -p output. >>> >>> I tried another linux on the BPI-M3: gentoo . >>> >>> # uname -p >>> ARMv7 Processor rev 5 (v7l) >>> >>> (Wow. Not what I expected.) >>> >>> # uname -pa >>> Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 >>> UTC 2016 armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux >>> >>> # uname -m >>> armv7l >>> >>> # uname -i >>> sun8i >>> >>> # ls -l /lib/ld-* >>> -rwxr-xr-x 1 root root 134192 Mar 26 2016 /lib/ld-2.21.so >>> lrwxrwxrwx 1 root root 10 Mar 26 2016 /lib/ld-linux-armhf.so.3 >>> -> ld-2.21.so >>> >>> So again armv7l seems to be the base name used for >>> a hardfloat little-endian context --although it >>> appears that "uname -m" gives text more likely to >>> be used in testing for how to configure to match >>> the live context. "uname -p" seems far less >>> standardized for its results. The same for >>> "uname -i". >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >> >> On both your linux you are using linux-sunxi which is a fork of the >> Allwinner kernel "maintained" by the sunxi community (and it is old). >> To have the proper values of uname one should test running linux >> vanilla kernel. > > They both reported (extracted from the earlier text > that I sent): > > 3.4.39-BPI-M3-Kernel > 3.4.39-BPI-M3-Kernel > > It is the same kernel version from the same group > for the same hardware context as far as what each > reported. > > While they may have varied the kernel for some > reason without changing the version identification > that is not want I would expect. > > I expected it was the Ubuntu vs. Gentoo code that > makes the difference, not the kernel. > > I'm not aware of a modern vanilla kernel for the > BPI-M3. Linux 4.11 have a correct support of A83T (and it will be better in 4.12) > From what I can tell for little armv7 boards like > this having older kernels is a common case and > is something ports code would normally deal with > upstream. It is not just sunxi as I understand. It depends, I think that Beaglebone based boards are using a more up to date kernel. And in the Allwinner world the C.H.I.P. is using mostly a vanilla kernel > I may do more experiments and report those too. > My notes are just information for Warner and others > to consider. I'm one of the "others" hence my reply :) > === > Mark Millard > markmi at dsl-only.net -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Jun 16 03:26:45 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 5DC69BF52FD for ; Fri, 16 Jun 2017 03:26:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 0486E6E241 for ; Fri, 16 Jun 2017 03:26:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17005 invoked from network); 16 Jun 2017 03:26:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Jun 2017 03:26:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 15 Jun 2017 23:26:43 -0400 (EDT) Received: (qmail 9836 invoked from network); 16 Jun 2017 03:26:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Jun 2017 03:26:42 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3ACB7EC8F7A; Thu, 15 Jun 2017 20:26:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage From: Mark Millard In-Reply-To: <290f9213ac2b227442c68cb0e3f7fdd5@megadrive.org> Date: Thu, 15 Jun 2017 20:26:41 -0700 Cc: Warner Losh , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <319FAD30-F285-4AE3-B56E-2245F4608CB1@dsl-only.net> References: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> <290f9213ac2b227442c68cb0e3f7fdd5@megadrive.org> To: Emmanuel Vadot 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: Fri, 16 Jun 2017 03:26:45 -0000 On 2017-Jun-15, at 3:35 PM, Emmanuel Vadot = wrote: > On 2017-06-15 17:40, Mark Millard wrote: > . . . >> They both reported (extracted from the earlier text >> that I sent): >> 3.4.39-BPI-M3-Kernel >> 3.4.39-BPI-M3-Kernel >> It is the same kernel version from the same group >> for the same hardware context as far as what each >> reported. >> While they may have varied the kernel for some >> reason without changing the version identification >> that is not want I would expect. >> I expected it was the Ubuntu vs. Gentoo code that >> makes the difference, not the kernel. >> I'm not aware of a modern vanilla kernel for the >> BPI-M3. >=20 > Linux 4.11 have a correct support of A83T (and it will be better in = 4.12) >=20 >> =46rom what I can tell for little armv7 boards like >> this having older kernels is a common case and >> is something ports code would normally deal with >> upstream. It is not just sunxi as I understand. >=20 > It depends, I think that Beaglebone based boards are using a more up = to date kernel. > And in the Allwinner world the C.H.I.P. is using mostly a vanilla = kernel >=20 >> I may do more experiments and report those too. >> My notes are just information for Warner and others >> to consider. >=20 > I'm one of the "others" hence my reply :) Good to know. I'll note here (in shorter form than the message sequence as I was investigating that showed the evidence): I looked at: A) gnu's coreutils and its uname.c B) Ubunutu's coreutils and its uname.c [an (A) variant but not via a .patch file] C) Gentoo's coreutils and its uname.c [a patch applied to (A)] All 3 have different handling of -p and -i in uname (even for the same kernel) via having different source code that does different things to generate the output. While all 3 do the same thing for -m it appears that various Linux distributions tend to tailor what -p and -i do, making the output vary. It does not look like depending on uname -p or uname -i output across different Linux distributions would a good idea (not very portable). Thus if FreeBSD really wants to have a uname output that agrees with a variety of Linux distributions it would appear that targeting uname -m for that would be the best of the 3. And the output text for -m for the armv7 hardfloat context would be: armv7l I've not done an inspection of how uname is used in a variety of ports or on Linux itself for upstream software, so the above is a rather one sided view of it. Of course FreeBSD could also decide to not target uname -m compatibility either. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Jun 16 04:04: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 6F347BF5BAF for ; Fri, 16 Jun 2017 04:04:39 +0000 (UTC) (envelope-from neerajpal09@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 D84096EFD6 for ; Fri, 16 Jun 2017 04:04:38 +0000 (UTC) (envelope-from neerajpal09@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id o83so18844460lff.3 for ; Thu, 15 Jun 2017 21:04:38 -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; bh=R1OzgUsRj3XsX2W9cyF+XdS+K0omDiuQfRq8slpmCP8=; b=iyUjJBXO8flZXf7BwpAbx7VBXGCi85gKcjl1Y7G5yalFN6EYn/tNCZJUtAPvzQoWJM hzOTNRor4HW0iXXpgZeAEclJzQR9BT31n6L06EmZmDjxl+o36DQwQaPY6t5DjUEoFHQ7 6ql7MddRQ5myTx1IKJmB37tM15qtta5L3AhifEhCeMLYHGM6EK3XcBZuLt0JtIAgb5Mm rap4Eb3SlKAPdYDgj9qNWJMPBypDJHUKMaeSDE3qMVDD3ajZR2Sp+1QixT5JArLh7RPV WMRAVymVuZTn7YHOqEoL5K0y3imtyllP0IbFoba5g7Nf7T1CHs5aODkAVH4Ij0F4h0eu LpnA== 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; bh=R1OzgUsRj3XsX2W9cyF+XdS+K0omDiuQfRq8slpmCP8=; b=QHaH3MAzVfk6uCPG5P0ZOkJvXmFm1jRnb8n7c4yFB0an/ktqAKpAXOVKZa1UsYRKqL JFsQJBU4AOY/5V/lzV3nUV6s5eR9uGbUE25EHXiD7jyQ3nRD7KQiGe8UiQpvupVlyzIX B/BYdyGEcOoCVOnswzK6RhY/MNvyhsDcDX0fKjIBeOBauw36IJ5ZNbq37b3f/kWXvWo2 shhJBCe0FGjlXkrKpNKpTiF6bZlwdjz8zTO6IzpgJa7sMSdLmb8d41EaaAdTA7Dog/1N OCGdUVRsQiyXvhjdZeYMwRCb8MYat0y7eaop2w4cIl60okKrJnZ47GcK3vlA9faDqKxX 12Rw== X-Gm-Message-State: AKS2vOwGT6arHVu3AZ73iF1ZzOz9AjEKIjUS4YNKj5eGSPhbI0rwhCvY CrQNxqSf0tmeaheHG70NTqpyT40K2Q== X-Received: by 10.25.229.215 with SMTP id i84mr2750652lfk.146.1497585875605; Thu, 15 Jun 2017 21:04:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.70 with HTTP; Thu, 15 Jun 2017 21:04:34 -0700 (PDT) Received: by 10.25.22.70 with HTTP; Thu, 15 Jun 2017 21:04:34 -0700 (PDT) From: Neeraj Pal Date: Fri, 16 Jun 2017 09:34:34 +0530 Message-ID: Subject: Support for Raspberry Pi 3 wifi broadcom driver in FreeBSD 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, 16 Jun 2017 04:04:39 -0000 Hello all, I want to know about wireless driver support for *Raspberry Pi 3*. Is there any support for Raspberry Pi 3 wireless Broadcom (*brcmfmac*) driver? Because i feels difficulty to set-up wireless in Raspberry Pi 3 (installed *FreeBSD*). *Details :[root@rpi3 /usr/home/raspberry]# *uname -a *FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318898M: Thu May 25 15:07:15 MDT 2017 raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarch64/usr/src/sys/GENERIC arm64* From owner-freebsd-arm@freebsd.org Fri Jun 16 10:06:05 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 41BF4BFC8F0 for ; Fri, 16 Jun 2017 10:06:05 +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 3030A792B5 for ; Fri, 16 Jun 2017 10:06:05 +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 v5GA65aq058175 for ; Fri, 16 Jun 2017 10:06:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 220041] Raspberry Pi Zero 0 W does not boot (halts at U-Boot prompt) Date: Fri, 16 Jun 2017 10:06:05 +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 Many People X-Bugzilla-Who: bcr@FreeBSD.org 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, 16 Jun 2017 10:06:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220041 Bug ID: 220041 Summary: Raspberry Pi Zero 0 W does not boot (halts at U-Boot prompt) Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: bcr@FreeBSD.org The Raspberry Pi 0 W does not boot with the latest ARMv6 RPI-B SD-card imag= e. The same image works successfully on the Raspberry Pi 0 (Camera and no came= ra edition) and boots to a login prompt. The W version does not seem to go bey= ond the U-Boot prompt, as reported here: https://www.raspberrypi.org/forums/viewtopic.php?t=3D179244&p=3D1143307 On the RPI0 without WiFi/Bluetooth, the next kernel message after the U-Boot prompt is "starting USB", so maybe there is something wrong or different in= the RPI0-W? Unfortunately, I can't enter anything at the U-Boot prompt, so it is difficult to enter any diagnostic messages. I can test images/patches and report back my findings. I can also bring the device to BSDCam or other conferences for hands-on tests. Thanks! --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Jun 16 10:41:28 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 0B9BDBFCF8C for ; Fri, 16 Jun 2017 10:41:28 +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 EE59A7A351 for ; Fri, 16 Jun 2017 10:41:27 +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 v5GAfRxD055645 for ; Fri, 16 Jun 2017 10:41:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 220042] [lor] on RPI-0 on halt: vfs_mount.c:1271 with vfs_subr.c:2764 and msdosfs_vfsops.c:972 Date: Fri, 16 Jun 2017 10:41:27 +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: bcr@FreeBSD.org 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, 16 Jun 2017 10:41:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220042 Bug ID: 220042 Summary: [lor] on RPI-0 on halt: vfs_mount.c:1271 with vfs_subr.c:2764 and msdosfs_vfsops.c:972 Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: bcr@FreeBSD.org I'm running the following image on an SD-card on my Raspberry pi 0: FreeBSD-12.0-CURRENT-arm-armv6-RPI-B-20170602-r319481.img . When I issue a "halt -p", I get the attached lock order reversal each time. I checked the = LOR page [1] (is that still being maintained?), but that specific LOR is not li= sted yet.=20 I can test images/patches upon request to see if the problem goes away. Thanks in advance! Benedict [1] http://sources.zabbadoz.net/freebsd/lor.html --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Jun 16 14:30: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 9C559C0A270 for ; Fri, 16 Jun 2017 14:30:04 +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 8AC9681DAF for ; Fri, 16 Jun 2017 14:30:04 +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 v5GEU4SH004502 for ; Fri, 16 Jun 2017 14:30:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 220048] SoftIron OverDrive 1000 reports "no time-of-day clock registered" (but has the correct time) Date: Fri, 16 Jun 2017 14:30:04 +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: emaste@freebsd.org 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, 16 Jun 2017 14:30:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220048 Bug ID: 220048 Summary: SoftIron OverDrive 1000 reports "no time-of-day clock registered" (but has the correct time) Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: emaste@freebsd.org >From dmesg, WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ada0p2 [rw]... uhub0: 4 ports with 4 removable, self powered warning: no time-of-day clock registered, system time will not be set accurately msk0: link state changed to DOWN However, I tried the following steps: 1) ran ntpdate to set the correct time 2) powered down 3) unplugged the network cable 4) booted and noticed that the real time is still correct. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Jun 16 14:40:19 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 D9A04C0A862 for ; Fri, 16 Jun 2017 14:40:19 +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 C7D94824E6 for ; Fri, 16 Jun 2017 14:40:19 +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 v5GEeJcV029113 for ; Fri, 16 Jun 2017 14:40:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 220048] SoftIron OverDrive 1000 reports "no time-of-day clock registered" Date: Fri, 16 Jun 2017 14:40:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 16 Jun 2017 14:40:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220048 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|New |Closed --- Comment #3 from Ed Maste --- *** This bug has been marked as a duplicate of bug 212185 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Jun 16 16:38: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 B9BA1C77DD3 for ; Fri, 16 Jun 2017 16:38:35 +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 A7990243C for ; Fri, 16 Jun 2017 16:38:35 +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 v5GGcZbj084165 for ; Fri, 16 Jun 2017 16:38:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 220050] armv6 kernel fails to build in clang500-import branch: smc instruction requires TrustZone Date: Fri, 16 Jun 2017 16:38:35 +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: emaste@freebsd.org 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, 16 Jun 2017 16:38:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220050 Bug ID: 220050 Summary: armv6 kernel fails to build in clang500-import branch: smc instruction requires TrustZone Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: emaste@freebsd.org /usr/home/emaste/src/freebsd-wip/sys/dev/psci/psci_arm.S:45:2: error: instruction requires: TrustZone smc #0 ^ *** Error code 1 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Jun 16 18:18:30 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 DF083D862CE for ; Fri, 16 Jun 2017 18:18:30 +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 C2FF16642C for ; Fri, 16 Jun 2017 18:18:30 +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 v5GIIUSD088966 for ; Fri, 16 Jun 2017 18:18:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 220055] armv6 kernel fails to link with LLD: incompatible section flags for .bss Date: Fri, 16 Jun 2017 18:18:30 +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: emaste@freebsd.org 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, 16 Jun 2017 18:18:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220055 Bug ID: 220055 Summary: armv6 kernel fails to link with LLD: incompatible section flags for .bss Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: emaste@freebsd.org linking kernel.full ld: error: incompatible section flags for .bss >>> locore.o:(.init_pagetable): 0x0 >>> output section .bss: 0x3 *** Error code 1 LLD reproduction tarball at https://people.freebsd.org/~emaste/lld/lld_armv6_kernel_section_flags.tar.xz --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 17 15:44:48 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 58267BFCC2D for ; Sat, 17 Jun 2017 15:44:48 +0000 (UTC) (envelope-from carlj@peak.org) Received: from filter05.peak.org (filter05.peak.org [69.59.194.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25B6C70A6A for ; Sat, 17 Jun 2017 15:44:46 +0000 (UTC) (envelope-from carlj@peak.org) Received: from zmail-mta02.peak.org ([207.55.16.112]) by filter05.peak.org ({27dbf508-291b-4a6b-93f5-d568f05dc56a}) via TCP (outbound) with ESMTPS id 20170617154127214_0000 for ; Sat, 17 Jun 2017 08:41:27 -0700 X-RC-FROM: X-RC-RCPT: Received: from zmail-mta02.peak.org (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTPS id 6C3E04C606 for ; Sat, 17 Jun 2017 08:41:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTP id 536754C80B for ; Sat, 17 Jun 2017 08:41:21 -0700 (PDT) Received: from zmail-mta02.peak.org ([127.0.0.1]) by localhost (zmail-mta02.peak.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eAF0Ppf3Hj6d for ; Sat, 17 Jun 2017 08:41:21 -0700 (PDT) Received: from mailproxy-lb-06.peak.org (mailproxy-lb-06.peak.org [207.55.17.96]) by zmail-mta02.peak.org (Postfix) with ESMTP id 1BD984C828 for ; Sat, 17 Jun 2017 08:41:21 -0700 (PDT) Received: from carlj by elm.localnet with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dMFqh-000J1G-Mw for freebsd-arm@freebsd.org; Sat, 17 Jun 2017 08:41:19 -0700 From: Carl Johnson To: freebsd-arm@freebsd.org Subject: Re: Problems with pkg, svnlite and svn on both 12.0 BBB snapshots of June 2017 References: X-Clacks-Overhead: GNU Terry Pratchett Date: Sat, 17 Jun 2017 08:41:19 -0700 In-Reply-To: (Rolf Jansen's message of "Thu, 15 Jun 2017 15:51:04 -0300") Message-ID: <86wp8avcyo.fsf@elm.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-MAG-OUTBOUND: peakinternet.redcondor.net@207.55.16/22 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, 17 Jun 2017 15:44:48 -0000 "Dr. Rolf Jansen" writes: > I subsequently deployed the June snapshots of FreeBSD 12.0 on my > Beaglebone Black, and in both cases I experience problems with pkg, > svnlite and with svn from the ports. > > # pkg -v > --> Shared object "libarchive.so.6" not found, required by "pkg" > > I can get pkg working, after I do: > # ln -s /usr/lib/libarchive.so.7 /usr/lib/libarchive.so.6 > > Any flavor of subversion is completely unusable now, I see various errors in different situations: > > One of either: > svn: E175003: Attempt to fetch capability 'depth' resulted in 'no' > > or: > svn: E000022: Error converting entry in directory '/root/install/my_tiny_project' to UTF-8 > svn: E000022: Valid UTF-8 data > (hex: 18 10) > followed by invalid UTF-8 sequence > (hex: e5 20 18 30) > > The working directories are not damaged, because I observe normal svn > operation on the very same ones, when I open those with svn on a 12.0 > snapshot from May 2017. > > Anyway, before I submit a burg report, I would like to ask whether I > am the only one, experiencing those problems, or if others see these > as well. May this be related to a broken SD card? > > Please can someone confirm that pkg and svnlite are working (or even > not) on the out-of-the-box snapshot > FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170612-r319859. I don't know if you are aware, but 12.0-CURRENT switched to 64-bit inodes in late May, so some of the shared library numbers were incremented. I also had the same problem with pkg, but found that pkg-static would still work. I fixed that by building pkg from ports. I just checked the FreeBSD package repository for 12.0 armv6 and it still shows a May 28 date, so it still hasn't been updated. I don't know about svn, but I would expect svnlite in the base system to work if it is just the 64 bit inodes. -- Carl Johnson carlj@peak.org From owner-freebsd-arm@freebsd.org Sat Jun 17 21:24: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 62D05C09BAC for ; Sat, 17 Jun 2017 21:24:26 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7E8E7857C for ; Sat, 17 Jun 2017 21:24:25 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1497734662; l=18440; s=domk; d=obsigna.com; h=In-Reply-To:To:References:Date:Subject:Mime-Version:Content-Type: From; bh=Thh+HzVPswMygZchkRcEkFoVgnmLfQ8m6x4ND3L04+g=; b=iGp/fZZyvvQ+dAqHZuUdrxmTMvfh1Lrg/KooWOgIKnftbJGXnrgSMKfn271f44pMgb s62eu73uFXZl40ltyhPICXs5NpZtUSF4EPQpWCUtVwiqxLLjK9f+RMJX13IFLUdiBlmi rmtyE+qXtTyTAmv5IUlCpBkvXb3pwDKYXVraI= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGhIk99HlWww= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b1a3.virtua.com.br [187.2.177.163]) by smtp.strato.de (RZmta 40.9 DYNA|AUTH) with ESMTPSA id v05d49t5HLOLWlj (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sat, 17 Jun 2017 23:24:21 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 59BF576F0B46 for ; Sat, 17 Jun 2017 18:24:18 -0300 (BRT) From: "Dr. Rolf Jansen" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Problems with pkg, svnlite and svn on both 12.0 BBB snapshots of June 2017 Date: Sat, 17 Jun 2017 18:24:18 -0300 References: <86wp8avcyo.fsf@elm.localnet> To: freebsd-arm@freebsd.org In-Reply-To: <86wp8avcyo.fsf@elm.localnet> Message-Id: <4C562875-5B3E-45E2-9667-E6A0768BF84D@obsigna.com> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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, 17 Jun 2017 21:24:26 -0000 > Am 17.06.2017 um 12:41 schrieb Carl Johnson >: >=20 > "Dr. Rolf Jansen" > writes: >=20 >> I subsequently deployed the June snapshots of FreeBSD 12.0 on my >> Beaglebone Black, and in both cases I experience problems with pkg, >> svnlite and with svn from the ports. >>=20 >> # pkg -v >> --> Shared object "libarchive.so.6" not found, required by "pkg" >>=20 >> I can get pkg working, after I do: >> # ln -s /usr/lib/libarchive.so.7 /usr/lib/libarchive.so.6 >>=20 >> Any flavor of subversion is completely unusable now, I see various = errors in different situations: >>=20 >> One of either: >> svn: E175003: Attempt to fetch capability 'depth' resulted in 'no' >>=20 >> or: >> svn: E000022: Error converting entry in directory = '/root/install/my_tiny_project' to UTF-8 >> svn: E000022: Valid UTF-8 data >> (hex: 18 10) >> followed by invalid UTF-8 sequence >> (hex: e5 20 18 30) >>=20 >> The working directories are not damaged, because I observe normal svn >> operation on the very same ones, when I open those with svn on a 12.0 >> snapshot from May 2017. >>=20 >> Anyway, before I submit a burg report, I would like to ask whether I >> am the only one, experiencing those problems, or if others see these >> as well. May this be related to a broken SD card? >>=20 >> Please can someone confirm that pkg and svnlite are working (or even >> not) on the out-of-the-box snapshot >> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170612-r319859. >=20 > I don't know if you are aware, but 12.0-CURRENT switched to 64-bit > inodes in late May, so some of the shared library numbers were > incremented. I also had the same problem with pkg, but found that > pkg-static would still work. I fixed that by building pkg from ports. = I > just checked the FreeBSD package repository for 12.0 armv6 and it = still > shows a May 28 date, so it still hasn't been updated. I don't know > about svn, but I would expect svnlite in the base system to work if it > is just the 64 bit inodes. Thank you very much for the information, which is news to me. As a matter of fact, pkg-static does work without symlinking = libarchive.so.7 to *.6, while svnlite does not. I built subversion 1.9.5 from the ports, however, I used the = dependencies from package repository -- because building software on the = BBB simply takes too long for being viable in the long run. For the time = being, I will build step by step the dependencies from the ports, and by = this I will see which one is the show stopper in the moment. Many thanks again and best regards Rolf= From owner-freebsd-arm@freebsd.org Sat Jun 17 21:31:27 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 C0E38C09C82 for ; Sat, 17 Jun 2017 21:31:27 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C6BE786B0 for ; Sat, 17 Jun 2017 21:31:26 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1497735085; l=3062; s=domk; d=obsigna.com; h=In-Reply-To:To:References:Date:Subject:Mime-Version: Content-Transfer-Encoding:Content-Type:From; bh=brEzclEJY+4WqVTweDNIjDSFPdRSpKC5HncDIueIVnM=; b=M/gux5TaGxj3hlPUs8yRHPDYe8LEbPJl0xXCn+ujPMrdIrKlvDKTyN8eFQIGtT2m8l D1F7OPhGpvJMnfp9VPtHWyuvzkzefIDf1bseIMxUaVf+gxnyfjMqYpN/wD1V2Ki+zvqE exD+5RuwV65LIzX3dXV+v4M/MQy6R5TWhqwyU= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGhIk99HlWww= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b1a3.virtua.com.br [187.2.177.163]) by smtp.strato.de (RZmta 40.9 DYNA|AUTH) with ESMTPSA id q0a2bft5HLVOUbp (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sat, 17 Jun 2017 23:31:24 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 171C676F0B46 for ; Sat, 17 Jun 2017 18:31:22 -0300 (BRT) From: "Dr. Rolf Jansen" 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: Problems with pkg, svnlite and svn on both 12.0 BBB snapshots of June 2017 Date: Sat, 17 Jun 2017 18:31:21 -0300 References: <86wp8avcyo.fsf@elm.localnet> <4C562875-5B3E-45E2-9667-E6A0768BF84D@obsigna.com> To: freebsd-arm@freebsd.org In-Reply-To: <4C562875-5B3E-45E2-9667-E6A0768BF84D@obsigna.com> Message-Id: <4B8D6F4C-3445-4CF0-B958-ED6523E52510@obsigna.com> 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, 17 Jun 2017 21:31:27 -0000 > Am 17.06.2017 um 18:24 schrieb Dr. Rolf Jansen : >=20 >> Am 17.06.2017 um 12:41 schrieb Carl Johnson >: >>=20 >> "Dr. Rolf Jansen" > writes: >>=20 >>> I subsequently deployed the June snapshots of FreeBSD 12.0 on my >>> Beaglebone Black, and in both cases I experience problems with pkg, >>> svnlite and with svn from the ports. >>>=20 >>> # pkg -v >>> --> Shared object "libarchive.so.6" not found, required by "pkg" >>>=20 >>> I can get pkg working, after I do: >>> # ln -s /usr/lib/libarchive.so.7 /usr/lib/libarchive.so.6 >>>=20 >>> Any flavor of subversion is completely unusable now, I see various = errors in different situations: >>>=20 >>> One of either: >>> svn: E175003: Attempt to fetch capability 'depth' resulted in 'no' >>>=20 >>> or: >>> svn: E000022: Error converting entry in directory = '/root/install/my_tiny_project' to UTF-8 >>> svn: E000022: Valid UTF-8 data >>> (hex: 18 10) >>> followed by invalid UTF-8 sequence >>> (hex: e5 20 18 30) >>>=20 >>> The working directories are not damaged, because I observe normal = svn >>> operation on the very same ones, when I open those with svn on a = 12.0 >>> snapshot from May 2017. >>>=20 >>> Anyway, before I submit a burg report, I would like to ask whether I >>> am the only one, experiencing those problems, or if others see these >>> as well. May this be related to a broken SD card? >>>=20 >>> Please can someone confirm that pkg and svnlite are working (or even >>> not) on the out-of-the-box snapshot >>> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170612-r319859. >>=20 >> I don't know if you are aware, but 12.0-CURRENT switched to 64-bit >> inodes in late May, so some of the shared library numbers were >> incremented. I also had the same problem with pkg, but found that >> pkg-static would still work. I fixed that by building pkg from ports. = I >> just checked the FreeBSD package repository for 12.0 armv6 and it = still >> shows a May 28 date, so it still hasn't been updated. I don't know >> about svn, but I would expect svnlite in the base system to work if = it >> is just the 64 bit inodes. >=20 > Thank you very much for the information, which is news to me. >=20 > As a matter of fact, pkg-static does work without symlinking = libarchive.so.7 to *.6, while svnlite does not. >=20 > I built subversion 1.9.5 from the ports, however, I used the = dependencies from package repository -- because building software on the = BBB simply takes too long for being viable in the long run. For the time = being, I will build step by step the dependencies from the ports, and by = this I will see which one is the show stopper in the moment. I had a quick success. Reinstallation of devel/apr1 from the ports = resolved the problem with subversion. So, I guess, everything will automatically come back to normal in the = course of future updates cycles of the packages repository. Best regards Rolf