From owner-freebsd-arm@freebsd.org Sun May 7 22:05: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 79F2AD63D2A for ; Sun, 7 May 2017 22:05:26 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 E7A8E1D99 for ; Sun, 7 May 2017 22:05:25 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-qt0-x229.google.com with SMTP id n4so37410160qte.2 for ; Sun, 07 May 2017 15:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=N84ZmMtSOB0cittV7JlhC31WL25mgIv2TqijlvAAxCs=; b=1zZIYxh5CO0c4qZcQjALHoAT/3OESfTvS4SBtRmwPs63P4IkQzVYUvmPDBOLhUfe/Z jWCDusG0Wu0EkZT3WG9RAkmxf6lcVpdMMbyW3AfX3JWnZ53c0EGcH8s/CM6xQfdDy+LW 0nbwQOWvP3KKCoqEfjcEPnpf/c8ZjBfIi4RvGPnLPGyB12K44JWi9DZDfbKokFBM+qBX 3Lr6p3/WYPNKSfcgTQ/AwPfo50qxEsozithhLdN2vnCmuAW+CHWk96vwPlvg/A+Nx14J dbO25IBIFogfFskVU0bPzt7M1sdmNWo2UipLoN71Jne9SP7om3JJHtNX1cBBo4kdzNlP QCmw== 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=N84ZmMtSOB0cittV7JlhC31WL25mgIv2TqijlvAAxCs=; b=IkkT5c0sQtuNOVQziRFqFu7rdJ3qpMlTH3JYndJuu6hjgOYHz+7iw7lhG1f5nAOKRd C6z4iJBcK+xU+sBN1SBehFT+f1esNObkqUTnlpVDMRFNtddId+jmaelrmVjrArQENhOx 2qjow49Yvi0xW8oUaqgdXEHcxd3F+eGrsOxVJKQ8iRhDIWZKRIbKLhbF74qjhgMP6dao DsFAitiYq9cHpvLXFTul/T7Ub1NTZpdaNxWCiZVJiivDlQuQh3oo9JN84Lyx6Zfw9C1W Y1GGWKkvxEug1eoLL6heGebuakhobIbKuuFkMm2E6nJg6w8ZuUVEoztminFUfBPNa2Hl 54jA== X-Gm-Message-State: AN3rC/74PpEpKWF4hc7ryVpgGNu1bmA9AVSBb+dHH0E9Xz6UbqQ7Ryen 3qtRDvFrBmN1mkCbQ6fk+4S9XNz//VeP X-Received: by 10.237.62.200 with SMTP id o8mr20224840qtf.152.1494194724896; Sun, 07 May 2017 15:05:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.102 with HTTP; Sun, 7 May 2017 15:05:24 -0700 (PDT) X-Originating-IP: [203.99.129.1] From: Jonathan Chen Date: Mon, 8 May 2017 10:05:24 +1200 Message-ID: Subject: STABLE-11 on RPI3 To: 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: Sun, 07 May 2017 22:05:26 -0000 Hi all, I'm exploring the possibility of installing STABLE-11 on an RPI3. I've managed to build a kernel & world successfully. However, in trying to build a bootable SD card, I can't seem to find a rpi3 dtb from the buildkernel. Does this not get built by the FreeBSD build system? Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Sun May 7 22:17: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 08498D620A8 for ; Sun, 7 May 2017 22:17:19 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id ADFBB146E for ; Sun, 7 May 2017 22:17:18 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id B13663B8E for ; Sun, 7 May 2017 17:17:12 -0500 (CDT) Subject: Re: STABLE-11 on RPI3 To: freebsd-arm@freebsd.org References: From: Karl Denninger Message-ID: <1543577c-5c1f-5967-1aeb-6665bbd3cd93@denninger.net> Date: Sun, 7 May 2017 17:17:08 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010901030108000606010309" 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, 07 May 2017 22:17:19 -0000 This is a cryptographically signed message in MIME format. --------------ms010901030108000606010309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/7/2017 17:05, Jonathan Chen wrote: > Hi all, > > I'm exploring the possibility of installing STABLE-11 on an RPI3. I've > managed to build a kernel & world successfully. However, in trying to > build a bootable SD card, I can't seem to find a rpi3 dtb from the > buildkernel. Does this not get built by the FreeBSD build system? > > Cheers. I do not believe you can; -HEAD will build and run however using Crochet. There are some things that are not supported however (sound / WiFi /Bluetooth to name three) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010901030108000606010309 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDcyMjE3MDhaME8GCSqGSIb3DQEJBDFCBECZKcRz pfewtamK4GIOUuLVJpDy9v9KNHyEQdoY3DVXkPikdl6jtH+BLfuIYGdUwWuUXMRAVerb8vBY v+WFBq4oMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIApT27spHgOzvH /jnoQyauaelPChXUcAvZ748Q9kAp3Yed+jCKCxR/3FignllEW5m59j+eDgncs4F0Wz8IZyRH N9hkKrAOES+E+Jj9PT7mTdds7W/riOlozsBcP777uViNqJbEULyNwkHwhKT/gHTJzNG+H9fW r3SppXw3YrViyaTKr11SzeIbpo4KmDvVFkTRtGPeA1KuA2IWmJ/4TLYkf47WfQWRUBnknLWx G0QU0mgxPDQufwSb67R46kFsPttHRn+CuGBDnZmbjUcTjMQmjiNYkTx+nIk0vfvAuF5dOcI9 znMQYfFxRe3bHi0DBkRmnJndgUiK4P9Oedppx0tWWrFqplFuWkV1jt0s4WT76b4qF/qa5Vk/ gNatqZI0FkK1sDDW/f3VmVo534LDFT9jYfxGoHHaeySovgTEq4cFpR41nl15MQE7jx6A8bMG NZRhC9jrZkQsjOh83QVNndyv2DeFAkMYpDcaKKq71gbWImbq2k6gmwbAPbr0Vg/gVs4itAWA TmnpJ3vSHRVPkwKdejuv8AJ1Ba1qCua0p6IeEB6kmDdXfbbLG4YGWwEpSIHKTCG+IS9noqsE KBS8L4ZXhNbU02P5915PmOJM4S8GjKS4NH1dlq3rxut4KRrzGF5Q/3zxzsy5G4jJGMPQYQlS 6LiWh/HKAZGTSBuAQv/TZoYAAAAAAAA= --------------ms010901030108000606010309-- From owner-freebsd-arm@freebsd.org Mon May 8 03:33: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 3025FD62E3D; Mon, 8 May 2017 03:33:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 027BC1EEA; Mon, 8 May 2017 03:33:45 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v483XXkf061799 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 May 2017 20:33:36 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v483XXch061798; Sun, 7 May 2017 20:33:33 -0700 (PDT) (envelope-from fbsd) Date: Sun, 7 May 2017 20:33:31 -0700 From: bob prohaska To: bob prohaska Cc: ports@freebsd.org, freebsd-arm@freebsd.org Subject: www/firefox, Error: garbage following instruction...was: Re: RPI2, www/firefox, error: "NEON support not enabled" Message-ID: <20170508033331.GA61772@www.zefox.net> References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> <20170505182838.GB51255@www.zefox.net> <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> <20170505230106.GA52464@www.zefox.net> <20170506050140.GA54543@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170506050140.GA54543@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 08 May 2017 03:33:50 -0000 On Fri, May 05, 2017 at 10:01:40PM -0700, bob prohaska wrote: > It appears that using > make CFLAGS='-mcpu=cortex-a7' > is sufficient to get past the NEON not enabled error. > The next problem appears to be /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armSP_FFT_CToC_FC32_Radix4_ls_unsafe_s.S:335: Error: garbage following instruction -- `vmov Q7.F32,Q0.F32' cc: error: assembler command failed with exit code 1 (use -v to see invocation) gmake[6]: *** [/usr/ports/www/firefox/work/firefox-53.0.2/config/rules.mk:990: armSP_FFT_CToC_FC32_Radix4_ls_unsafe_s.o] Error 1 gmake[5]: *** [/usr/ports/www/firefox/work/firefox-53.0.2/config/recurse.mk:71: media/openmax_dl/dl/target] Error 2 Is this worth a bug report, or is firefox too far over the horizon for freebsd-arm? Thanks for reading, and any guidance. bob prohaska From owner-freebsd-arm@freebsd.org Mon May 8 08:56:57 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7CB3D62C71; Mon, 8 May 2017 08:56:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E9DD964; Mon, 8 May 2017 08:56:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [192.168.3.3] (unknown [77.95.97.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 102E53BF7C; Mon, 8 May 2017 10:56:48 +0200 (CEST) From: Dimitry Andric Message-Id: <80D06D70-8534-456C-A66F-CDD4CE0D5811@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_0B9AC110-E2F7-45F7-BBBB-4F2206E327DB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: www/firefox, Error: garbage following instruction...was: Re: RPI2, www/firefox, error: "NEON support not enabled" Date: Mon, 8 May 2017 10:56:40 +0200 In-Reply-To: <20170508033331.GA61772@www.zefox.net> Cc: ports@freebsd.org, freebsd-arm@freebsd.org To: bob prohaska References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> <20170505182838.GB51255@www.zefox.net> <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> <20170505230106.GA52464@www.zefox.net> <20170506050140.GA54543@www.zefox.net> <20170508033331.GA61772@www.zefox.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 08:56:58 -0000 --Apple-Mail=_0B9AC110-E2F7-45F7-BBBB-4F2206E327DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 May 2017, at 05:33, bob prohaska wrote: >=20 > On Fri, May 05, 2017 at 10:01:40PM -0700, bob prohaska wrote: >> It appears that using >> make CFLAGS=3D'-mcpu=3Dcortex-a7' >> is sufficient to get past the NEON not enabled error. >>=20 >=20 > The next problem appears to be >=20 >=20 > = /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armS= P_FFT_CToC_FC32_Radix4_ls_unsafe_s.S:335: Error: garbage following = instruction -- `vmov Q7.F32,Q0.F32' > cc: error: assembler command failed with exit code 1 (use -v to see = invocation) > gmake[6]: *** = [/usr/ports/www/firefox/work/firefox-53.0.2/config/rules.mk:990: = armSP_FFT_CToC_FC32_Radix4_ls_unsafe_s.o] Error 1 > gmake[5]: *** = [/usr/ports/www/firefox/work/firefox-53.0.2/config/recurse.mk:71: = media/openmax_dl/dl/target] Error 2 >=20 > Is this worth a bug report, or is firefox too far over the horizon > for freebsd-arm? >=20 > Thanks for reading, and any guidance. This is actually an error message from the GNU assembler, which is invoked by the compiler driver. Can you figure out whether it is the base version (/usr/bin/as) or the ports version (/usr/local/bin/as)? E.g. manually run that command line with -v, so see which assembler it runs. Also, I wonder why they don't use the integrated assembler in clang, but that is an aspect of the firefox port I'm not familiar with. -Dimitry --Apple-Mail=_0B9AC110-E2F7-45F7-BBBB-4F2206E327DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlkQMswACgkQsF6jCi4glqMMyACeK999kqChBdvsdVM53L+pbka2 olwAoPgZwivXYLk/+SrJg7QQLYUu5xqY =PkdU -----END PGP SIGNATURE----- --Apple-Mail=_0B9AC110-E2F7-45F7-BBBB-4F2206E327DB-- From owner-freebsd-arm@freebsd.org Mon May 8 11:08: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 E7C5DD62265 for ; Mon, 8 May 2017 11:08:45 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 3E93A1453 for ; Mon, 8 May 2017 11:08:45 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id m123so60675428wma.0 for ; Mon, 08 May 2017 04:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xl+mUVtOrga9RdejPmT56eMmh1R3lr5NGUkHm0nI9k8=; b=B09ur4+b8D3PgvJvXkg+Q3p9hSJeRoA9DeY7WEpmolEWLwuzO4TBfMHUhMB6EEU2+Y ltnHHs5i7UeMU/3FPdFDG6Vh0OngVT7gDaae8gYUeDenw56ml/sNd6WVnfxlUeWtojoU NYANgiAw83zg5mTd/vdbZ4tF7yHA+3JFYqei223i9Wj0aO+hCs4kYAFMedvwBMxasWWB BjLBpR30bsrX8Go0W1Gklr22dbLaI419peVrHcVRWXZEyCJFSi9kzZEDSHMUAGqEIkxi b8AMHP77pExwUg677qc3P6NJusLSRalqurUatgV9cADTYLIhEnj2UpESXdLZgtsR4EWi O5Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xl+mUVtOrga9RdejPmT56eMmh1R3lr5NGUkHm0nI9k8=; b=jtR+a+MAbEhDgzwXDxvSnKrYfK5HxJLN8s8bHRBLuMzoRvr09YOROhxoMsWtnZuNLo LjXKxck0LprUHzmm/BFVRct3zbdQb7w5uAboK9sQoflDHsOmurNL9ZmZV5DHtJPgu0ti UA1RGo3lR99f1njwvXRaZqEm3Q/LDR61G4DKsWYR3qg3NMZ50ELiEdIjRpLuNToGHMk7 oJXa9YZc/VgfFOLm9FCm1awIAj+KzVJM45xjbfBFFVFh73wNsnDm3p2y+cYSZsLGeP4G tDRN3yxUtEW4RGTSnIrQ782NfbAxPc+eLWyNNERY2QqKC66khy/b/SzRfPMaRmsDalVj g5+w== X-Gm-Message-State: AODbwcCeEajdpxSoK6MOuSLnGhZEByPvA8A/V5x+qIdupD3EtKkWVK6s 7cTmMIio4j4uNy0HeyY= X-Received: by 10.28.167.197 with SMTP id q188mr12059513wme.79.1494241722496; Mon, 08 May 2017 04:08:42 -0700 (PDT) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id x17sm9844790wrd.63.2017.05.08.04.08.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 May 2017 04:08:42 -0700 (PDT) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: www/firefox, Error: garbage following instruction...was: Re: RPI2, www/firefox, error: "NEON support not enabled" To: freebsd-arm@freebsd.org References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> <20170505182838.GB51255@www.zefox.net> <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> <20170505230106.GA52464@www.zefox.net> <20170506050140.GA54543@www.zefox.net> <20170508033331.GA61772@www.zefox.net> <80D06D70-8534-456C-A66F-CDD4CE0D5811@FreeBSD.org> Message-ID: <7306a091-1350-d6cb-b329-c56f2d80c0bf@freebsd.org> Date: Mon, 8 May 2017 13:08:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <80D06D70-8534-456C-A66F-CDD4CE0D5811@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 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: Mon, 08 May 2017 11:08:46 -0000 On 08.05.2017 10:56, Dimitry Andric wrote: > On 8 May 2017, at 05:33, bob prohaska wrote: >> >> On Fri, May 05, 2017 at 10:01:40PM -0700, bob prohaska wrote: >>> It appears that using >>> make CFLAGS='-mcpu=cortex-a7' >>> is sufficient to get past the NEON not enabled error. >>> >> >> The next problem appears to be >> >> >> /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armSP_FFT_CToC_FC32_Radix4_ls_unsafe_s.S:335: Error: garbage following instruction -- `vmov Q7.F32,Q0.F32' >> cc: error: assembler command failed with exit code 1 (use -v to see invocation) >> gmake[6]: *** [/usr/ports/www/firefox/work/firefox-53.0.2/config/rules.mk:990: armSP_FFT_CToC_FC32_Radix4_ls_unsafe_s.o] Error 1 >> gmake[5]: *** [/usr/ports/www/firefox/work/firefox-53.0.2/config/recurse.mk:71: media/openmax_dl/dl/target] Error 2 >> >> Is this worth a bug report, or is firefox too far over the horizon >> for freebsd-arm? >> >> Thanks for reading, and any guidance. > > This is actually an error message from the GNU assembler, which is > invoked by the compiler driver. Can you figure out whether it is the > base version (/usr/bin/as) or the ports version (/usr/local/bin/as)? > E.g. manually run that command line with -v, so see which assembler it > runs. > > Also, I wonder why they don't use the integrated assembler in clang, but > that is an aspect of the firefox port I'm not familiar with. > > -Dimitry > It's from base (buggy, outdated) GNU assembler, gas from ports can compile affected file without problem. The integrated clang assembler cannot be used because Mozilla extensive uses macros in assembly code, and macros are not supported by clang. Moreover, many pieces of assembly files still uses pre-UAL syntax. Unfortunately, replacing base as (by the one from port) is not sufficient - the Mozilla build system doesn't pass external CFLAGS to assembly files (.S), so build fails again later. Michal From owner-freebsd-arm@freebsd.org Mon May 8 16:15: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 04ECED63EF5; Mon, 8 May 2017 16:15:14 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A5BB0378; Mon, 8 May 2017 16:15:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v48GFBLw065011 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 May 2017 09:15:12 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v48GFBRc065010; Mon, 8 May 2017 09:15:11 -0700 (PDT) (envelope-from fbsd) Date: Mon, 8 May 2017 09:15:11 -0700 From: bob prohaska To: mmel@freebsd.org Cc: freebsd-arm@freebsd.org, ports@freebsd.org Subject: Re: www/firefox, Error: garbage following instruction...was: Re: RPI2, www/firefox, error: "NEON support not enabled" Message-ID: <20170508161511.GA64826@www.zefox.net> References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> <20170505182838.GB51255@www.zefox.net> <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> <20170505230106.GA52464@www.zefox.net> <20170506050140.GA54543@www.zefox.net> <20170508033331.GA61772@www.zefox.net> <80D06D70-8534-456C-A66F-CDD4CE0D5811@FreeBSD.org> <7306a091-1350-d6cb-b329-c56f2d80c0bf@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7306a091-1350-d6cb-b329-c56f2d80c0bf@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 08 May 2017 16:15:14 -0000 On Mon, May 08, 2017 at 01:08:46PM +0200, Michal Meloun wrote: > > On 08.05.2017 10:56, Dimitry Andric wrote: > > On 8 May 2017, at 05:33, bob prohaska wrote: > >> > >> Is this worth a bug report, or is firefox too far over the horizon > >> for freebsd-arm? > >> > > > > Also, I wonder why they don't use the integrated assembler in clang, but > > that is an aspect of the firefox port I'm not familiar with. > > > > The integrated clang assembler cannot be used because Mozilla extensive > uses macros in assembly code, and macros are not supported by clang. > Moreover, many pieces of assembly files still uses pre-UAL syntax. > > Unfortunately, replacing base as (by the one from port) is not > sufficient - the Mozilla build system doesn't pass external CFLAGS to > assembly files (.S), so build fails again later. > I gather this is a familiar and relatively intractable problem 8-( Would a bug report be useful? bob prohaska From owner-freebsd-arm@freebsd.org Tue May 9 03:56: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 51F00D6552D; Tue, 9 May 2017 03:56:18 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C36461982; Tue, 9 May 2017 03:56:17 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id F0DEA73C4; Tue, 9 May 2017 03:55:30 +0000 (UTC) From: Jan Beich To: Michal Meloun Cc: freebsd-arm@freebsd.org, ports@freebsd.org Subject: Re: www/firefox, Error: garbage following instruction...was: Re: RPI2, www/firefox, error: "NEON support not enabled" References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> <20170505182838.GB51255@www.zefox.net> <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> <20170505230106.GA52464@www.zefox.net> <20170506050140.GA54543@www.zefox.net> <20170508033331.GA61772@www.zefox.net> <80D06D70-8534-456C-A66F-CDD4CE0D5811@FreeBSD.org> <7306a091-1350-d6cb-b329-c56f2d80c0bf@freebsd.org> Date: Tue, 09 May 2017 05:55:17 +0200 In-Reply-To: <7306a091-1350-d6cb-b329-c56f2d80c0bf@freebsd.org> (Michal Meloun's message of "Mon, 8 May 2017 13:08:46 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 03:56:18 -0000 Michal Meloun writes: > On 08.05.2017 10:56, Dimitry Andric wrote: > >> On 8 May 2017, at 05:33, bob prohaska wrote: >>> >>> On Fri, May 05, 2017 at 10:01:40PM -0700, bob prohaska wrote: >>>> It appears that using >>>> make CFLAGS='-mcpu=cortex-a7' >>>> is sufficient to get past the NEON not enabled error. >>>> >>> >>> The next problem appears to be >>> >>> >>> > /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armSP_FFT_CToC_FC32_Radix4_ls_unsafe_s.S:335: > Error: garbage following instruction -- `vmov Q7.F32,Q0.F32' >>> cc: error: assembler command failed with exit code 1 (use -v to see > invocation) >>> gmake[6]: *** > [/usr/ports/www/firefox/work/firefox-53.0.2/config/rules.mk:990: > armSP_FFT_CToC_FC32_Radix4_ls_unsafe_s.o] Error 1 >>> gmake[5]: *** > [/usr/ports/www/firefox/work/firefox-53.0.2/config/recurse.mk:71: > media/openmax_dl/dl/target] Error 2 >>> >>> Is this worth a bug report, or is firefox too far over the horizon >>> for freebsd-arm? >>> >>> Thanks for reading, and any guidance. >> >> This is actually an error message from the GNU assembler, which is >> invoked by the compiler driver. Can you figure out whether it is the >> base version (/usr/bin/as) or the ports version (/usr/local/bin/as)? >> E.g. manually run that command line with -v, so see which assembler it >> runs. >> >> Also, I wonder why they don't use the integrated assembler in clang, but >> that is an aspect of the firefox port I'm not familiar with. >> >> -Dimitry >> > It's from base (buggy, outdated) GNU assembler, gas from ports can > compile affected file without problem. > > The integrated clang assembler cannot be used because Mozilla extensive > uses macros in assembly code, and macros are not supported by clang. Upstream commit suggests otherwise. https://android.googlesource.com/platform/external/chromium_org/third_party/openmax_dl/+/5d8507771824%5E%21/ > Moreover, many pieces of assembly files still uses pre-UAL syntax. > > Unfortunately, replacing base as (by the one from port) is not > sufficient - the Mozilla build system doesn't pass external CFLAGS to > assembly files (.S), so build fails again later. Do you mean ASFLAGS are unused, so the following wouldn't help? Index: Mk/bsd.gecko.mk =================================================================== --- Mk/bsd.gecko.mk (revision 440464) +++ Mk/bsd.gecko.mk (working copy) @@ -475,6 +475,10 @@ USE_BINUTILS= # intel-gcm.s CFLAGS+= -B${LOCALBASE}/bin LDFLAGS+= -B${LOCALBASE}/bin . endif +.elif ${ARCH:Marm*} +USE_BINUTILS= # media/openmax_dl/ +MOZ_EXPORT+= ASFLAGS="${ASFLAGS}" +ASFLAGS+= -B${LOCALBASE}/bin .elif ${ARCH:Mpowerpc*} USES:= compiler:gcc-c++11-lib ${USES:Ncompiler*c++11*} . if ${ARCH} == "powerpc64" From owner-freebsd-arm@freebsd.org Tue May 9 10:08:00 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FE2DD630F2; Tue, 9 May 2017 10:08:00 +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 112C51A35; Tue, 9 May 2017 10:08:00 +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=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3wMZn13ybkzrRP DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1494324469; bh=7iHqLB7Ld1TW1e7MdhBNoVLL/ehau2c/JdY2wfvXif0=; h=To:Cc:From:Subject:Date; z=To:=20freebsd-arm=20|Cc:=20freebsd-curre nt=20|From:=20Henri=20Hennebert=20|Subject:=20DTB=20provided=20by=20loader.efi=20from=2 0head=20-r317181=20on=20pine64=20smashed=20by=0D=0A=20zfs.ko=20?|D ate:=20Tue,=209=20May=202017=2012:07:47=20+0200; b=crdHhuTOWMROkwMB6BNKJQexzjoYmbgMkQc4Jd/9j2nNYdIS6BJaYAYUsa+fdI8q0 ETf6ZWehFxQvnKye1bZB0QOsADl/qEuxJicSQkB2XS1tN4lHErTI0JUGMTkDnrcf3u gUr1vh+P12jIuSb8KtbT4jfApclKnu4l68qGZZcOIPHpw7pUuzH66/eAhoukwStNto HErTx8bu7PWDJFO2PLV0D6vmiAbByiR1x/T4azv0mGpt8XaG1HEEXy1mZAcb75ratw F2Ij42NzKVH5ZKgsF1dABURZxZaEhbuu+LCnUAnVZiPd9dPcyeWUl1Wuq5Kcqv+yxO PCY2xb4p2NQBA== 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 3wMZn13ybkzrRP; Tue, 9 May 2017 12:07:49 +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 v49A7lsV081594 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 May 2017 12:07:48 +0200 (CEST) (envelope-from hlh@restart.be) To: freebsd-arm Cc: freebsd-current From: Henri Hennebert Subject: DTB provided by loader.efi from head -r317181 on pine64 smashed by zfs.ko ? Message-ID: <818a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.be> Date: Tue, 9 May 2017 12:07:47 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 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: Tue, 09 May 2017 10:08:00 -0000 Hello, I build current -r317181 with crochet for my PINE64. the kernel can boot with loader.conf.local: geom_mirror_load="YES" If I add to loader.conf.local: zfs_load="YES" or if I strike the space bar during loader.efi and I load zfs manually: OK load zfs ... OK boot the kernel don't boot and the console stay with the last line: Using DTB provided by EFI at 0x49000000. Moreover the opensolaris.ko is not loader. Maybe DTB is smashed by zfs.ko Any idea ? Henri PS with r312006M from RaspBSD all is OK and I can user zfs as root filesystem. From owner-freebsd-arm@freebsd.org Tue May 9 13:47:00 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 945CDD65E64 for ; Tue, 9 May 2017 13:47:00 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 44962D3F for ; Tue, 9 May 2017 13:47:00 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x22b.google.com with SMTP id n4so905337qte.2 for ; Tue, 09 May 2017 06:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PYXk7WEOCTRqOEDqbEVRLNKGIhLyO2ciVWlp4OTEDyo=; b=WQxis5mvhd7MCP+zS/WFgDclQ03WCJLJc0lmsLZFWYjm1L+fva8R5hPrGn1BBU24Bq tnf6+NWy3qggsaSAwUlPCtYkB6Vg9IhJit83XlQPyOek9qGKEFs7bvDv/nw+vQ86Cks1 hnbCrsNMbFbRFId4Fg4MKa0IPkl3XTtwcScmou4kNoMH/U4NPjZ6URjgkhi1WWKf9517 oR+ezU6zTovmyVIyBHnFLf1Hgz/vdrFqLJeI9AJUyu6PB0uRFKqYxnMZuDhXihF2LgPb y2G1hx6Fuwb2sFN6d/jqZjGBX/Y0Acvx0nF3kRiWaZ9jVpgCTTvwXWuwDgIKX4ez+NnF vy+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PYXk7WEOCTRqOEDqbEVRLNKGIhLyO2ciVWlp4OTEDyo=; b=tJEo+XWF5GQl4tG/5bRLR71ElH6AyN7HaTpXCgk+nDZM/9a/W4+aWo9Eltj7+F/HiG reEX7eW1hWwb+DUFcBLwOeoLJO/dZgB4ZxtKhVINXnSMpDfb+OS+TZaVGcha3rZdUtfF 2dT3k8mBoTchvKCGVz6AwX6WcAIajXVYhafjbBQEyCvemkw31+vaMOKk2DaRGy8gqWRs OsqxZOav/DKWEQ0LdX+4HYm8YQxzD1G2RldYVhPSpJ5qCkjSShHONOoOT6XrGRHRSOBd i2l8VdlP0zlKEpa7nZ9YAl/mcQk2OQOI/usd5v8CtlT7pJ8C58GCuZz7Es7aZRLn6Vfb sfUw== X-Gm-Message-State: AODbwcD9RRYApg1pi39epyslv/ZMkw7w7EwR+CuZheRKDlNcQ0R+CaJg JsZ2zsXtjZuhF11y X-Received: by 10.237.53.149 with SMTP id c21mr121465qte.191.1494337619315; Tue, 09 May 2017 06:46:59 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id x27sm9212956qtb.54.2017.05.09.06.46.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 09 May 2017 06:46:58 -0700 (PDT) Date: Tue, 9 May 2017 09:46:57 -0400 From: Shawn Webb To: Henri Hennebert Cc: freebsd-arm , freebsd-current Subject: Re: DTB provided by loader.efi from head -r317181 on pine64 smashed by zfs.ko ? Message-ID: <20170509134657.t3t7dynx3tksfiyg@mutt-hbsd> References: <818a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.be> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qomsnlnsclutcbcm" Content-Disposition: inline In-Reply-To: <818a6074-7d4b-a87e-d89e-ce1f4a30ff3c@restart.be> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170306 (1.8.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, 09 May 2017 13:47:00 -0000 --qomsnlnsclutcbcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 09, 2017 at 12:07:47PM +0200, Henri Hennebert wrote: > Hello, >=20 > I build current -r317181 with crochet for my PINE64. >=20 > the kernel can boot with loader.conf.local: >=20 > geom_mirror_load=3D"YES" >=20 > If I add to loader.conf.local: >=20 > zfs_load=3D"YES" >=20 > or if I strike the space bar during loader.efi and I load zfs manually: >=20 > OK load zfs > ... > OK boot >=20 > the kernel don't boot and the console stay with the last line: >=20 > Using DTB provided by EFI at 0x49000000. >=20 > Moreover the opensolaris.ko is not loader. >=20 > Maybe DTB is smashed by zfs.ko >=20 > Any idea ? I see the same symptom with root-on-ZFS with my SoftIron OverDrive 1000. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --qomsnlnsclutcbcm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlkRyE8ACgkQaoRlj1JF bu6xZRAAyTmnEVPiL7mmjbRmRPRaDXqLHj9yh8xEys9VQELqbBDuGhxwpBSQyJMN 7b4iiF9iDXn5wR6yMfgdD8SKpLUYyJL/I0OYdVoNWKce+npMZHDfi31asrUfz/ay IUAE7mKjpe6S1iFPFhEFLdRixLxT1kbDrIis2qDEz07gbdW/PK37cHYyf2PLkybN IaS6HwmsLDoqnqvS3q53lpKB8226gViFy07JfuxHpmU38qfsw+qtC50xYHiCR0Yg 8/fnPyEvRFm9UDEYIaLzAhr+x+g86heVDMaE4FAA7KFLGGq023cBi6+dQ2URv89H pCemPaVjYkXFug1dwtbb1ZDn5cFNzSyHX/n6w1Roqh941ExSqNEgjDoU03fRoP5C 2JKnuDVnpBGKaVnAcy3n0EOnzBRZcFmHRaEvBFuadtfbu7CUxHT7NYoDSaQ5z1Bl 2Rhr13ebImPX8y6e6yJV/axAWwxnJl8auCgMpGoCCxHvq29KAqhf7sbsxNZQ763b RPpGf1+LJ1DPh6VqEHaGlMOmEbzBqBGwX4rQYxaf01XbEZHBWp4Hmwb/zUQo7E86 +piq/P203B4O20wVJqGa/IGqoeBFdeVdtUMYUZcvC5s+VW0FTyvxe01afOCqG+go auLQKKpndOcNcWrGaPvk+e7CAeuFA3CU41/WLuq7VxZMIzbKfuM= =FuDO -----END PGP SIGNATURE----- --qomsnlnsclutcbcm-- From owner-freebsd-arm@freebsd.org Wed May 10 15:07: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 1A6C1D66B19 for ; Wed, 10 May 2017 15:07:35 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from perdizione.investici.org (perdizione.investici.org [IPv6:2001:41d0:2:33d0::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.autistici.org", Issuer "Autistici/Inventati Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DCB511003 for ; Wed, 10 May 2017 15:07:34 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from [94.23.50.208] (perdizione [94.23.50.208]) (Authenticated sender: aggaz@paranoici.org) by localhost (Postfix) with ESMTPSA id 26E8D12000E; Wed, 10 May 2017 15:07:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paranoici.org; s=stigmate; t=1494428842; bh=HJa9GKZEpW8hS3WwwlhmwlZQgEP4YX2Z91rFslDaP3w=; h=From:To:Subject:Date; b=X1XkrLQszQiaEPchYS3ZJu/0FyaUVDhVcGXyjmGBRopZ4ZFhw3n1iapwsGDaQqS4z OXlKoKj2FuBCz8y7OzNIDjwxWlzdvxiNec9Eo89oBPR0pzXWwLKfrMQP57ruz/mQlp yqOYrSzTrcIzQwQFVe7mT8R5d4R616YDqpT1qVho= From: aggaz To: freebsd-arm@freebsd.org Subject: Re: FreeBSD 12-CURRENT on OrangePi One Message-ID: <0d94c2c1-6b1f-3da1-9de9-f25c84573029@paranoici.org> Date: Wed, 10 May 2017 17:07:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 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, 10 May 2017 15:07:35 -0000 Dear list, I am still playing with FreeBSD/Crochet/OrangePi-One. In my last attempts, I was able to boot FreeBSD by using two dtb files: [nano]: NanoPi-Neo ($FREEBSDSRC/sys/boot/fdt/dts/arm/nanopi-neo.dts) [plus]: OrangePi-Plus-2E ($FREEBSDSRC/sys/boot/fdt/dts/arm/orangepi-plus-2e.dts) Using [nano] I was able to use ethernet but not USB. Using [plus] I was able to use USB but not ethernet. Now, I merged [nano] and [plus] generating a dts file for OrangePi One (lets call it: [one]). Basically, [one] is a copy of [plus], but the lines regarding ethernet interface are from [nano]. In particular, lines 65-78 of [plus] are deleted and lines 53-63 of [nano] are used instead. [one] works fine on my OrangePi One, I used it in the last couple of days, and both ethernet and USB are working. --------------------------------------------------------------------------------------------- ==Other attempts: Before writing file [one], I also tried to use the dts file for OrangePi One from Linux: [linux]: $FREEBSDSRC/sys/gnu/dts/arm/sun8i-h3-orangepi-one.dts With this file ethernet does not work, and usb works sporadically. In order to add ethernet, I applyed the patches as described in [1]. To be more specific, I only used the patches written in the following text, copied from the cited blog: #==================================================================== # [v4,04/10] ARM: dts: sun8i-h3: Add dt node for the syscon wget https://patchwork.kernel.org/patch/9365773/raw/ \ -O sun8i-emac-patch-4.patch # [v4,05/10] ARM: dts: sun8i-h3: add sun8i-emac ethernet driver wget https://patchwork.kernel.org/patch/9365757/raw/ \ -O sun8i-emac-patch-5.patch # [v4,07/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange PI One wget https://patchwork.kernel.org/patch/9365767/raw/ \ -O sun8i-emac-patch-7.patch #==================================================================== The resulting patched file ([patch]) boots. I can see both ethernet and USB, but ethernet never works, and USB works sporadically. To be more specific: When I attach an USB memory to the port, I can mount it 1 time over 5 attempts, and when things do not work I see the following messages in dmesg: #==================================================================== ugen0.2: at usbus0 umass0 on uhub0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x8100 umass0:0:0: Attached to scbus0 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted #==================================================================== Regarding ethernet, it does never work, and at boot (using DHCP) I see these messages: #==================================================================== awg0: link state changed to DOWN awg0: link state changed to UP Starting Network: lo0 awg0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 awg0: flags=8843 metric 0 mtu 1500 options=8000b ether 02:81:1c:2e:66:ec media: Ethernet none (none ) status: active nd6 options=29 Starting devd. Starting dhclient. DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 15 DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 16 DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 9 No DHCPOFFERS received. No working leases in persistent database - sleeping. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Generating host.conf. Waiting 30s for the default route interface: ............................. #==================================================================== --------------------------------------------------------------------------------------------- ==Work in progress: Now that I have both USB and ethernet, given that the [linux] dts seems to be not working, and given that I was not able to really understand wich dts file is the best one for OrangePi One in the land of Linux, I am inclined to work on [one], because it works and derives from [plus], which was written for a similar board. One of the differences between OrangePi Plus 2E and OrangePi One is the voltage regulator responsible for cpu scaling. I had a look at the values used in the FEX files from Armbian [2] (lines 713-730), and I inserted similar values in the lines 96-97 and 111-121 of [plus]. Things seem to work fine until now, but I really don't know how should I check the correct behavior of cpu-scaling. Moreover, I am not an experienced developer and I am really just putting things together here, so I would like to know if you think I am following the right road. Finally, given that I used a FEX file from Armbian as a reference, and given that I am not sure about the license this file is released with, I do not know what kind of license should I use for my work in progress dts file. I am a beginner here, any kind of help or suggestion is very much appreciated. Regards Aggaz [1] https://blog.christophersmart.com/2016/10/23/building-and-booting-upstream-linux-and-u-boot-for-orange-pi-one-arm-board/ [2] https://github.com/armbian/build/blob/master/config/fex/orangepione.fex From owner-freebsd-arm@freebsd.org Thu May 11 03:38: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 1B91BD685E6; Thu, 11 May 2017 03:38:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E57A9EDF; Thu, 11 May 2017 03:38:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v4B3bsMT074206 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 May 2017 20:37:55 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v4B3bsXP074205; Wed, 10 May 2017 20:37:54 -0700 (PDT) (envelope-from fbsd) Date: Wed, 10 May 2017 20:37:54 -0700 From: bob prohaska To: ports@freebsd.org, freebsd-arm@freebsd.org Subject: www/firefox on RPI2: error: instruction requires: armv6t2 Message-ID: <20170511033754.GA74153@www.zefox.net> References: <80D06D70-8534-456C-A66F-CDD4CE0D5811@FreeBSD.org> <7306a091-1350-d6cb-b329-c56f2d80c0bf@freebsd.org> <20170508161511.GA64826@www.zefox.net> <20170508233241.GA65262@www.zefox.net> <20170509230236.GA69546@www.zefox.net> <20170510151019.GA70628@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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, 11 May 2017 03:38:01 -0000 With freebsd at FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #50 r318138: Wed May 10 10:30:51 PDT 2017 bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm ports at Revision: 440570 and using root@www:/usr/ports/www/firefox # make CFLAGS='-mcpu=cortex-a7' -DBATCH > make.log & the compilation seems to halt with /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/common_audio/signal_processing/filter_ar_fast_q12_armv7.S:88:3: error: instruction requires: armv6t2 sbfx r11, r6, #12, #16 ^ /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/common_audio/signal_processing/filter_ar_fast_q12_armv7.S:99:3: error: instruction requires: armv6t2 sbfx r11, r6, #12, #16 ^ /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/common_audio/signal_processing/filter_ar_fast_q12_armv7.S:142:3: error: instruction requires: armv6t2 sbfx r8, r6, #12, #16 ^ gmake[6]: *** [/usr/ports/www/firefox/work/firefox-53.0.2/config/rules.mk:989: filter_ar_fast_q12_armv7.o] Error 1 I'm told this is likely caused by CFLAGS='-mcpu=cortex-a7', which is needed to avoid a "NEON not enabled" error earlier in the compile. Would a bug report be redundant? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Thu May 11 05:58: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 DCB7BD682DE for ; Thu, 11 May 2017 05:58:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-8.reflexion.net [208.70.210.8]) (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 837B3A2 for ; Thu, 11 May 2017 05:58:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28930 invoked from network); 11 May 2017 05:31:28 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 May 2017 05:31:28 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 11 May 2017 01:31:28 -0400 (EDT) Received: (qmail 2713 invoked from network); 11 May 2017 05:31:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 May 2017 05:31:27 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3ADEAEC8E11; Wed, 10 May 2017 22:31:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: www/firefox on RPI2: error: instruction requires: armv6t2 From: Mark Millard In-Reply-To: <20170511033754.GA74153@www.zefox.net> Date: Wed, 10 May 2017 22:31:26 -0700 Cc: ports@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> References: <80D06D70-8534-456C-A66F-CDD4CE0D5811@FreeBSD.org> <7306a091-1350-d6cb-b329-c56f2d80c0bf@freebsd.org> <20170508161511.GA64826@www.zefox.net> <20170508233241.GA65262@www.zefox.net> <20170509230236.GA69546@www.zefox.net> <20170510151019.GA70628@www.zefox.net> <20170511033754.GA74153@www.zefox.net> To: bob prohaska 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, 11 May 2017 05:58:11 -0000 On 2017-May-10, at 8:37 PM, bob prohaska wrote: > With freebsd at=20 > FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #50 r318138: = Wed May 10 10:30:51 PDT 2017 = bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm >=20 > ports at=20 > Revision: 440570 >=20 > and using=20 > root@www:/usr/ports/www/firefox # make CFLAGS=3D'-mcpu=3Dcortex-a7' = -DBATCH > make.log & >=20 > the compilation seems to halt with > = /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/commo= n_audio/signal_processing/filter_ar_fast_q12_armv7.S:88:3: error: = instruction requires: armv6t2 > sbfx r11, r6, #12, #16 > ^ > = /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/commo= n_audio/signal_processing/filter_ar_fast_q12_armv7.S:99:3: error: = instruction requires: armv6t2 > sbfx r11, r6, #12, #16 > ^ > = /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/commo= n_audio/signal_processing/filter_ar_fast_q12_armv7.S:142:3: error: = instruction requires: armv6t2 > sbfx r8, r6, #12, #16 > ^ > gmake[6]: *** = [/usr/ports/www/firefox/work/firefox-53.0.2/config/rules.mk:989: = filter_ar_fast_q12_armv7.o] Error 1 >=20 > I'm told this is likely caused by CFLAGS=3D'-mcpu=3Dcortex-a7', which = is > needed to avoid a "NEON not enabled" error earlier in the compile. If the .S files (assembler source files) are used via the likes of (from looking at some vintage of config/rules.mk on the web): $(SOBJS): $(REPORT_BUILD) $(AS) -o $@ $(DEFINES) $(ASFLAGS) $($(notdir $<)_FLAGS) = $(LOCAL_INCLUDES) -c $< then the -mcpu=3Dcortex-a7 is likely not involved. Instead such a context would suggest needing to supply some option in ASFLAGS for the $(ASFLAGS) expansion, an option appropriate to whatever the assembler command is [expansion of $(AS)]. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu May 11 20:53:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D1EFD68DF9 for ; Thu, 11 May 2017 20:53:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-7.reflexion.net [208.70.210.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA6D1174E for ; Thu, 11 May 2017 20:53:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1677 invoked from network); 11 May 2017 20:53:34 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 May 2017 20:53:34 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 11 May 2017 16:53:35 -0400 (EDT) Received: (qmail 32295 invoked from network); 11 May 2017 20:53:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 May 2017 20:53:34 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1A700EC8697; Thu, 11 May 2017 13:53:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: www/firefox on RPI2: error: instruction requires: armv6t2 From: Mark Millard In-Reply-To: <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> Date: Thu, 11 May 2017 13:53:33 -0700 Cc: ports@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <80B1CCCF-A151-40B8-87D5-CADD513CFAAD@dsl-only.net> References: <80D06D70-8534-456C-A66F-CDD4CE0D5811@FreeBSD.org> <7306a091-1350-d6cb-b329-c56f2d80c0bf@freebsd.org> <20170508161511.GA64826@www.zefox.net> <20170508233241.GA65262@www.zefox.net> <20170509230236.GA69546@www.zefox.net> <20170510151019.GA70628@www.zefox.net> <20170511033754.GA74153@www.zefox.net> <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> To: bob prohaska 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, 11 May 2017 20:53:37 -0000 On 2017-May-10, at 10:31 PM, Mark Millard = wrote: > On 2017-May-10, at 8:37 PM, bob prohaska wrote: >=20 >> With freebsd at=20 >> FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #50 r318138: = Wed May 10 10:30:51 PDT 2017 = bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm >>=20 >> ports at=20 >> Revision: 440570 >>=20 >> and using=20 >> root@www:/usr/ports/www/firefox # make CFLAGS=3D'-mcpu=3Dcortex-a7' = -DBATCH > make.log & >>=20 >> the compilation seems to halt with >> = /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/commo= n_audio/signal_processing/filter_ar_fast_q12_armv7.S:88:3: error: = instruction requires: armv6t2 >> sbfx r11, r6, #12, #16 >> ^ It would help others help you if the assembler or compiler command that specifically generated this error message was also included in the text that you quote. Then we could see what the command was and what options had been supplied to it (and so what had not been supplied as well). To some extent is is for folks that might not build firefox or even X11 but still might be of some help with if they could see the extra context. But folks that do build firefox might also compare their context's details to your context's details and might report on differences that helped them. >> = /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/commo= n_audio/signal_processing/filter_ar_fast_q12_armv7.S:99:3: error: = instruction requires: armv6t2 >> sbfx r11, r6, #12, #16 >> ^ >> = /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/commo= n_audio/signal_processing/filter_ar_fast_q12_armv7.S:142:3: error: = instruction requires: armv6t2 >> sbfx r8, r6, #12, #16 >> ^ >> gmake[6]: *** = [/usr/ports/www/firefox/work/firefox-53.0.2/config/rules.mk:989: = filter_ar_fast_q12_armv7.o] Error 1 >>=20 >> I'm told this is likely caused by CFLAGS=3D'-mcpu=3Dcortex-a7', = which is >> needed to avoid a "NEON not enabled" error earlier in the compile. >=20 >=20 > If the .S files (assembler source files) are used via the > likes of (from looking at some vintage of config/rules.mk > on the web): >=20 > $(SOBJS): >=20 > $(REPORT_BUILD) > $(AS) -o $@ $(DEFINES) $(ASFLAGS) $($(notdir $<)_FLAGS) = $(LOCAL_INCLUDES) -c $< >=20 > then the -mcpu=3Dcortex-a7 is likely not involved. >=20 > Instead such a context would suggest needing to supply > some option in ASFLAGS for the $(ASFLAGS) expansion, an > option appropriate to whatever the assembler command is > [expansion of $(AS)]. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri May 12 01:44:44 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 4EA70D676D6; Fri, 12 May 2017 01:44:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 27A1C1DE0; Fri, 12 May 2017 01:44:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v4C1ifnh077327 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 May 2017 18:44:42 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v4C1ifNs077326; Thu, 11 May 2017 18:44:41 -0700 (PDT) (envelope-from fbsd) Date: Thu, 11 May 2017 18:44:41 -0700 From: bob prohaska To: Mark Millard Cc: ports@freebsd.org, freebsd-arm Subject: Re: www/firefox on RPI2: error: instruction requires: armv6t2 Message-ID: <20170512014441.GA77264@www.zefox.net> References: <20170508233241.GA65262@www.zefox.net> <20170509230236.GA69546@www.zefox.net> <20170510151019.GA70628@www.zefox.net> <20170511033754.GA74153@www.zefox.net> <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> <80B1CCCF-A151-40B8-87D5-CADD513CFAAD@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80B1CCCF-A151-40B8-87D5-CADD513CFAAD@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 12 May 2017 01:44:44 -0000 On Thu, May 11, 2017 at 01:53:33PM -0700, Mark Millard wrote: > > It would help others help you if the assembler or > compiler command that specifically generated this > error message was also included in the text that > you quote. Then we could see what the command > was and what options had been supplied to it > (and so what had not been supplied as well). > If someone can tell me how to capture that information I'll gladly do it; at this stage I do not know how. The files referenced in the error message have been placed at http://www.zefox.net/~fbsd/rpi2/firefox/assembler_failure/ along with a transcript of stdout/stderr in make.log Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Fri May 12 02:16: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 35F8DD680C0 for ; Fri, 12 May 2017 02:16:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-6.reflexion.net [208.70.210.6]) (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 ED53D1142 for ; Fri, 12 May 2017 02:16:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10617 invoked from network); 12 May 2017 02:16:08 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 12 May 2017 02:16:08 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 11 May 2017 22:16:08 -0400 (EDT) Received: (qmail 3339 invoked from network); 12 May 2017 02:16:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 May 2017 02:16:08 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E2E4DEC7B46; Thu, 11 May 2017 19:16:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: www/firefox on RPI2: error: instruction requires: armv6t2 From: Mark Millard In-Reply-To: <20170512014441.GA77264@www.zefox.net> Date: Thu, 11 May 2017 19:16:07 -0700 Cc: ports@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <85B88765-A708-414B-A465-14A044196D3D@dsl-only.net> References: <20170508233241.GA65262@www.zefox.net> <20170509230236.GA69546@www.zefox.net> <20170510151019.GA70628@www.zefox.net> <20170511033754.GA74153@www.zefox.net> <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> <80B1CCCF-A151-40B8-87D5-CADD513CFAAD@dsl-only.net> <20170512014441.GA77264@www.zefox.net> To: bob prohaska 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, 12 May 2017 02:16:11 -0000 On 2017-May-11, at 6:44 PM, bob prohaska wrote: > On Thu, May 11, 2017 at 01:53:33PM -0700, Mark Millard wrote: >>=20 >> It would help others help you if the assembler or >> compiler command that specifically generated this >> error message was also included in the text that >> you quote. Then we could see what the command >> was and what options had been supplied to it >> (and so what had not been supplied as well). >>=20 > If someone can tell me how to capture that information I'll gladly do = it;=20 > at this stage I do not know how. >=20 > The files referenced in the error message have been placed at > http://www.zefox.net/~fbsd/rpi2/firefox/assembler_failure/ > along with a transcript of stdout/stderr in make.log The (long) line for processing filter_ar_fast_q12_armv7.S was about 19 lines back from the first filter_ar_fast_q12_armv7.S error message in that make.log: (copy/paste may have split the line into multiple below) /usr/bin/cc -std=3Dgnu99 -o filter_ar_fast_q12_armv7.o -DNDEBUG = -DTRIMMED=3D1 -D_FILE_OFFSET_BITS=3D64 -DCHROMIUM_BUILD = -DUSE_LIBJPEG_TURBO=3D1 -DUSE_NSS=3D1 -DGTK_DISABLE_SINGLE_INCLUDES=3D1 = -DENABLE_REMOTING=3D1 -DENABLE_WEBRTC=3D1 -DENABLE_CONFIGURATION_POLICY = -DENABLE_INPUT_SPEECH -DENABLE_NOTIFICATIONS -DENABLE_GPU=3D1 = -DENABLE_EGLIMAGE=3D1 -DUSE_SKIA=3D1 -DENABLE_TASK_MANAGER=3D1 = -DENABLE_WEB_INTENTS=3D1 -DENABLE_EXTENSIONS=3D1 = -DENABLE_PLUGIN_INSTALLATION=3D1 -DENABLE_PROTECTOR_SERVICE=3D1 = -DENABLE_SESSION_SERVICE=3D1 -DENABLE_THEMES=3D1 -DENABLE_BACKGROUND=3D1 = -DENABLE_AUTOMATION=3D1 -DENABLE_PRINTING=3D1 = -DENABLE_CAPTIVE_PORTAL_DETECTION=3D1 -DWEBRTC_RESTRICT_LOGGING = -DWEBRTC_MOZILLA_BUILD -DEXPAT_RELATIVE_PATH -DWEBRTC_ARCH_ARM = -DWEBRTC_ARCH_ARM_V7 -DWEBRTC_BUILD_NEON_LIBS -DWEBRTC_DETECT_NEON = -DWEBRTC_BSD -DWEBRTC_THREAD_RR -DWEBRTC_POSIX = -DWEBRTC_INCLUDE_INTERNAL_AUDIO_DEVICE -D__STDC_FORMAT_MACROS = -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=3D0 -DSTATIC_EXPORTABLE_JS_API = -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -fPIC = -Wa,--noexecstack -include = /usr/ports/www/firefox/work/firefox-53.0.2/obj-armv6-unknown-freebsd12.0/m= ozilla-config.h -DMOZILLA_CLIENT = -I/usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk = -I/usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/com= mon_audio/resampler/include = -I/usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/com= mon_audio/signal_processing/include = -I/usr/ports/www/firefox/work/firefox-53.0.2/obj-armv6-unknown-freebsd12.0= /ipc/ipdl/_ipdlheaders = -I/usr/ports/www/firefox/work/firefox-53.0.2/ipc/chromium/src = -I/usr/ports/www/firefox/work/firefox-53.0.2/ipc/glue -c = /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/commo= n_audio/signal_processing/filter_ar_fast_q12_armv7.S As I guessed the string "-mcpu=3Dcortex-a7" does not appear in the command. But it does indicate that /usr/bin/cc is being used to get to the assembler --which I did not guess. If I guessed right about part of the rule.mk that processed the .S file then the implication would be that: AS=3D/usr/bin/cc So it might be that having ASFLAGS contain -mcpu=3Dcortex-a7 might propagate through to the underlying assembler processing in a way to allow the sbfx instructions by telling it the type of cpu to target. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri May 12 03:14: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 D2E18D691C5 for ; Fri, 12 May 2017 03:14:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-6.reflexion.net [208.70.210.6]) (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 86B8D18AA for ; Fri, 12 May 2017 03:14:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19369 invoked from network); 12 May 2017 03:14:15 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 May 2017 03:14:15 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 11 May 2017 23:14:15 -0400 (EDT) Received: (qmail 1305 invoked from network); 12 May 2017 03:14:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 May 2017 03:14:15 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0ABEEEC7B46; Thu, 11 May 2017 20:14:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: www/firefox on RPI2: error: instruction requires: armv6t2 From: Mark Millard In-Reply-To: <85B88765-A708-414B-A465-14A044196D3D@dsl-only.net> Date: Thu, 11 May 2017 20:14:14 -0700 Cc: ports@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170508233241.GA65262@www.zefox.net> <20170509230236.GA69546@www.zefox.net> <20170510151019.GA70628@www.zefox.net> <20170511033754.GA74153@www.zefox.net> <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> <80B1CCCF-A151-40B8-87D5-CADD513CFAAD@dsl-only.net> <20170512014441.GA77264@www.zefox.net> <85B88765-A708-414B-A465-14A044196D3D@dsl-only.net> To: bob prohaska 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, 12 May 2017 03:14:17 -0000 On 2017-May-11, at 7:16 PM, Mark Millard wrote: > On 2017-May-11, at 6:44 PM, bob prohaska = wrote: >=20 >> On Thu, May 11, 2017 at 01:53:33PM -0700, Mark Millard wrote: >>>=20 >>> It would help others help you if the assembler or >>> compiler command that specifically generated this >>> error message was also included in the text that >>> you quote. Then we could see what the command >>> was and what options had been supplied to it >>> (and so what had not been supplied as well). >>>=20 >> If someone can tell me how to capture that information I'll gladly do = it;=20 >> at this stage I do not know how. >>=20 >> The files referenced in the error message have been placed at >> http://www.zefox.net/~fbsd/rpi2/firefox/assembler_failure/ >> along with a transcript of stdout/stderr in make.log >=20 > The (long) line for processing filter_ar_fast_q12_armv7.S > was about 19 lines back from the first > filter_ar_fast_q12_armv7.S error message in that make.log: > (copy/paste may have split the line into multiple below) >=20 > /usr/bin/cc -std=3Dgnu99 -o filter_ar_fast_q12_armv7.o -DNDEBUG = -DTRIMMED=3D1 -D_FILE_OFFSET_BITS=3D64 -DCHROMIUM_BUILD = -DUSE_LIBJPEG_TURBO=3D1 -DUSE_NSS=3D1 -DGTK_DISABLE_SINGLE_INCLUDES=3D1 = -DENABLE_REMOTING=3D1 -DENABLE_WEBRTC=3D1 -DENABLE_CONFIGURATION_POLICY = -DENABLE_INPUT_SPEECH -DENABLE_NOTIFICATIONS -DENABLE_GPU=3D1 = -DENABLE_EGLIMAGE=3D1 -DUSE_SKIA=3D1 -DENABLE_TASK_MANAGER=3D1 = -DENABLE_WEB_INTENTS=3D1 -DENABLE_EXTENSIONS=3D1 = -DENABLE_PLUGIN_INSTALLATION=3D1 -DENABLE_PROTECTOR_SERVICE=3D1 = -DENABLE_SESSION_SERVICE=3D1 -DENABLE_THEMES=3D1 -DENABLE_BACKGROUND=3D1 = -DENABLE_AUTOMATION=3D1 -DENABLE_PRINTING=3D1 = -DENABLE_CAPTIVE_PORTAL_DETECTION=3D1 -DWEBRTC_RESTRICT_LOGGING = -DWEBRTC_MOZILLA_BUILD -DEXPAT_RELATIVE_PATH -DWEBRTC_ARCH_ARM = -DWEBRTC_ARCH_ARM_V7 -DWEBRTC_BUILD_NEON_LIBS -DWEBRTC_DETECT_NEON = -DWEBRTC_BSD -DWEBRTC_THREAD_RR -DWEBRTC_POSIX = -DWEBRTC_INCLUDE_INTERNAL_AUDIO_DEVICE -D__STDC_FORMAT_MACROS = -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=3D0 -DSTATIC_EXPORTABLE_JS_API = -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL > _LIBXUL -fPIC -Wa,--noexecstack -include = /usr/ports/www/firefox/work/firefox-53.0.2/obj-armv6-unknown-freebsd12.0/m= ozilla-config.h -DMOZILLA_CLIENT = -I/usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk = -I/usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/com= mon_audio/resampler/include = -I/usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/com= mon_audio/signal_processing/include = -I/usr/ports/www/firefox/work/firefox-53.0.2/obj-armv6-unknown-freebsd12.0= /ipc/ipdl/_ipdlheaders = -I/usr/ports/www/firefox/work/firefox-53.0.2/ipc/chromium/src = -I/usr/ports/www/firefox/work/firefox-53.0.2/ipc/glue -c = /usr/ports/www/firefox/work/firefox-53.0.2/media/webrtc/trunk/webrtc/commo= n_audio/signal_processing/filter_ar_fast_q12_armv7.S >=20 > As I guessed the string "-mcpu=3Dcortex-a7" does not appear in > the command. >=20 > But it does indicate that /usr/bin/cc is being used to get to > the assembler --which I did not guess. If I guessed right > about part of the rule.mk that processed the .S file then > the implication would be that: AS=3D/usr/bin/cc >=20 > So it might be that having ASFLAGS contain -mcpu=3Dcortex-a7 > might propagate through to the underlying assembler > processing in a way to allow the sbfx instructions by > telling it the type of cpu to target. Looks like there are two rule.mk assembler areas: ifdef ASFILES # The AS_DASH_C_FLAG is needed cause not all assemblers (Solaris) accept # a '-c' flag. $(ASOBJS): $(REPORT_BUILD_VERBOSE) $(AS) $(ASOUTOPTION)$@ $(ASFLAGS) $($(notdir $<)_FLAGS) = $(AS_DASH_C_FLAG) $(_VPATH_SRCS) endif . . . $(SOBJS): $(REPORT_BUILD) $(AS) -o $@ $(DEFINES) $(ASFLAGS) $($(notdir $<)_FLAGS) = $(LOCAL_INCLUDES) -c $< I had originally only noticed one. Having -mcpu=3Dcortex-a7 in ASFLAGS would contribute to both of the examples. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri May 12 11:14: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 CF9A6D68EB0 for ; Fri, 12 May 2017 11:14:14 +0000 (UTC) (envelope-from amutu@amutu.com) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 8E432AAF for ; Fri, 12 May 2017 11:14:14 +0000 (UTC) (envelope-from amutu@amutu.com) Received: by mail-oi0-x22d.google.com with SMTP id h4so61675227oib.3 for ; Fri, 12 May 2017 04:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amutu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iIAvTy/fiV9UbuLxm4pKEOK10yeqzuSdOlb8wD0Qtkw=; b=QqyZ3Yr0lkFpJ1dsZAgrxpNQ4tvYxBwPrNhg0ceSYBFaRbdn6KXbiHFeoZkh3BscEi erRJkrdw2E4yZBQcrdVLAcbtqDKNgrodLR08p6hCxRwrZBHNb2a63fHN1v9AFztctA39 G6BTqeB4bED8nO/iMpzZX7fJ4Q1BTBgu/fL5NViTSgUc0NezcE1k+UMDLeIPit9mSO7M BQYotGO3ayUxkvBayuYmDwHYX7Rko1HwIWjUwr+x+0rtE+uyA35qsm7RXyMOrhcnlT0w r8ScNWiscOfQgpbq+VNsx2j39YZnLBsVKmS/R4XxIREzbZ7pWwlh3KoQY46Ex7SObDwF Tpjg== 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=iIAvTy/fiV9UbuLxm4pKEOK10yeqzuSdOlb8wD0Qtkw=; b=l4D0qkbty0NnYs+yv1FOsVCBS1SQZI1pB4/5m7nsokhkJWlPOV+6+T6lLFJsLAzOMm 5EYoDfOQhHcuntc5pEzeO7atvPNK3Z5PSqTkTt5Nkj6l76DxqVSrp28EKlHuzTYb//WV 40wO8Qz0GKBiCcNCrOJO21JkRFrTFyG5QxLG+x+DMaEwECX3aSGgQX8OJXdizPU+XBpd M4l24bZYtmDTeW/IwOvI1a00N3ZGRijQYv39j8iFjW+fg1DcRHDsBCKpGvmQVzxcm7C5 2w3Uf+5r1qdAWEdTMjiW0+Ew6+eBEwdogZFYXptXAoJADYPksRCt0/9tQUt0DSaaMu/I JquQ== X-Gm-Message-State: AODbwcAD7yk9kU9kmvHyQU92beNSK1qOeZavr8oGRJHxi3JyQIWSwP02 TCxjhkVDfXjj6Lpj72k= X-Received: by 10.157.63.156 with SMTP id r28mr1860728otc.225.1494587653422; Fri, 12 May 2017 04:14:13 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com. [209.85.218.50]) by smtp.gmail.com with ESMTPSA id h27sm1439204ote.27.2017.05.12.04.14.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 04:14:13 -0700 (PDT) Received: by mail-oi0-f50.google.com with SMTP id w10so61856217oif.0 for ; Fri, 12 May 2017 04:14:12 -0700 (PDT) X-Received: by 10.157.61.52 with SMTP id a49mr1536394otc.30.1494587652452; Fri, 12 May 2017 04:14:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.134.72 with HTTP; Fri, 12 May 2017 04:13:52 -0700 (PDT) In-Reply-To: <0d94c2c1-6b1f-3da1-9de9-f25c84573029@paranoici.org> References: <0d94c2c1-6b1f-3da1-9de9-f25c84573029@paranoici.org> From: Jov Date: Fri, 12 May 2017 19:13:52 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: FreeBSD 12-CURRENT on OrangePi One To: aggaz Cc: freebsd-arm 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: Fri, 12 May 2017 11:14:14 -0000 Good job! I think you can pick up any license you like because you are the owner,but if you wish your work get into the freebsd project(such as crochet),you'd better choose bsd friendly license,like bsd or mit license. 2017-05-10 23:07 GMT+08:00 aggaz : > Dear list, > > I am still playing with FreeBSD/Crochet/OrangePi-One. > > In my last attempts, I was able to boot FreeBSD by using two dtb files: > > [nano]: NanoPi-Neo ($FREEBSDSRC/sys/boot/fdt/dts/arm/nanopi-neo.dts) > [plus]: OrangePi-Plus-2E > ($FREEBSDSRC/sys/boot/fdt/dts/arm/orangepi-plus-2e.dts) > > Using [nano] I was able to use ethernet but not USB. > Using [plus] I was able to use USB but not ethernet. > > Now, I merged [nano] and [plus] generating a dts file for OrangePi One > (lets call it: [one]). > > Basically, [one] is a copy of [plus], but the lines regarding ethernet > interface are from [nano]. > > In particular, lines 65-78 of [plus] are deleted and lines 53-63 of > [nano] are used instead. > > [one] works fine on my OrangePi One, I used it in the last couple of > days, and both ethernet and USB are working. > > > --------------------------------------------------------------------------------------------- > ==Other attempts: > > Before writing file [one], I also tried to use the dts file for OrangePi > One from Linux: > > [linux]: $FREEBSDSRC/sys/gnu/dts/arm/sun8i-h3-orangepi-one.dts > > With this file ethernet does not work, and usb works sporadically. > > In order to add ethernet, I applyed the patches as described in [1]. > To be more specific, I only used the patches written in the following > text, copied from the cited blog: > > #==================================================================== > # [v4,04/10] ARM: dts: sun8i-h3: Add dt node for the syscon > wget https://patchwork.kernel.org/patch/9365773/raw/ \ > -O sun8i-emac-patch-4.patch > > # [v4,05/10] ARM: dts: sun8i-h3: add sun8i-emac ethernet driver > wget https://patchwork.kernel.org/patch/9365757/raw/ \ > -O sun8i-emac-patch-5.patch > > # [v4,07/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange PI One > wget https://patchwork.kernel.org/patch/9365767/raw/ \ > -O sun8i-emac-patch-7.patch > #==================================================================== > > The resulting patched file ([patch]) boots. I can see both ethernet and > USB, but ethernet never works, and USB works sporadically. > > To be more specific: > > When I attach an USB memory to the port, I can mount it 1 time over 5 > attempts, and when things do not work I see the following messages in dmesg: > > #==================================================================== > ugen0.2: at usbus0 > umass0 on uhub0 > umass0: on usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x8100 > umass0:0:0: Attached to scbus0 > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted > #==================================================================== > > > Regarding ethernet, it does never work, and at boot (using DHCP) I see > these messages: > > #==================================================================== > awg0: link state changed to DOWN > awg0: link state changed to UP > Starting Network: lo0 awg0. > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=21 > awg0: flags=8843 metric 0 mtu 1500 > options=8000b > ether 02:81:1c:2e:66:ec > media: Ethernet none (none ) > status: active > nd6 options=29 > Starting devd. > Starting dhclient. > DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 6 > DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 15 > DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 16 > DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 14 > DHCPDISCOVER on awg0 to 255.255.255.255 port 67 interval 9 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > add host 127.0.0.1: gateway lo0 fib 0: route already in table > add host ::1: gateway lo0 fib 0: route already in table > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > Generating host.conf. > Waiting 30s for the default route interface: ............................. > #==================================================================== > > > > --------------------------------------------------------------------------------------------- > ==Work in progress: > > Now that I have both USB and ethernet, given that the [linux] dts seems > to be not working, and given that I was not able to really understand > wich dts file is the best one for OrangePi One in the land of Linux, I > am inclined to work on [one], because it works and derives from [plus], > which was written for a similar board. > > One of the differences between OrangePi Plus 2E and OrangePi One is the > voltage regulator responsible for cpu scaling. > > I had a look at the values used in the FEX files from Armbian [2] (lines > 713-730), and I inserted similar values in the lines 96-97 and 111-121 > of [plus]. > > Things seem to work fine until now, but I really don't know how should I > check the correct behavior of cpu-scaling. > > Moreover, I am not an experienced developer and I am really just putting > things together here, so I would like to know if you think I am > following the right road. > > Finally, given that I used a FEX file from Armbian as a reference, and > given that I am not sure about the license this file is released with, I > do not know what kind of license should I use for my work in progress > dts file. > > I am a beginner here, any kind of help or suggestion is very much > appreciated. > > > Regards > Aggaz > > > > [1] > https://blog.christophersmart.com/2016/10/23/building-and-booting-upstream-linux-and-u-boot-for-orange-pi-one-arm-board/ > > [2] https://github.com/armbian/build/blob/master/config/fex/orangepione.fex > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri May 12 17:45: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 14873D693EF for ; Fri, 12 May 2017 17:45:36 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id D273514A7 for ; Fri, 12 May 2017 17:45:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 488953724 for ; Fri, 12 May 2017 12:45:29 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Possible -HEAD problem with the Pi3 onboard ethernet Message-ID: Date: Fri, 12 May 2017 12:45:28 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080405080609090001080005" 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, 12 May 2017 17:45:36 -0000 This is a cryptographically signed message in MIME format. --------------ms080405080609090001080005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Under fairly heavy stress (~50% of the 100Mbps possible FDX performance) I've now run into a problem that is turning into something I can repeat without too much trouble by transmitting a large file through the device.= The system appears to "crash" from the outside. It's not dead, however -- it's got some sort of network buffer hang going on. This is a Pi3 with current (-HEAD, FreeBSD 12.0-CURRENT #0 r318193M: Thu May 11 16:18:20 CDT 2017) software on it -- reverting to a mid-March kernel did NOT change the behavior. The symptomology is that the unit will start printing this on the console= : May 12 12:25:46 IPGw dhcpd: send_packet: No buffer space available May 12 12:25:46 IPGw dhcpd: dhcp.c:3974: Failed to send 300 byte long packet over ue0.3 interface. ue0.3 is a VLAN for a private subnet and is not specific to the issue; it also complains about no space on the primary too: May 12 12:27:06 IPGw dhcpd: dhcp.c:3974: Failed to send 300 byte long packet over ue0 interface. May 12 12:27:13 IPGw dhcpd: send_packet: No buffer space available netstat -m does /not /show any denied or delayed requests for network buffers or mbuf exhaustion. Systat -vm shows plenty of RAM available (roughly half.) An ifconfig ue0 down / ifconfig ue0 up sequence from the console clears the hang. Has anyone else seen anything similar to this? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080405080609090001080005 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MTIxNzQ1MjhaME8GCSqGSIb3DQEJBDFCBECUEIXq 8ahK+eNTN+rf9053Micgf7b9e7qpbnC/P1OCkW0ddn9ErZdw9L5rfAtoIE1FT2HEaa7gEoWE rSQUL2D4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIApkoL8/gMDwxj PAO0M9038+/mxS+JMovCCHPXCEgYU3xK/U9zQ+M8KXjoqp78cjk05jbi1hSQiBdFkQehEWRd n9qxXTiQC5kF/ozVb0eJB0tWPXgYyWTwNSuTdfQGdF04JI209D1VK1twVLzTMVjFcVRRubJ1 TwT5owJGPLoOkYg6x63lvbB6Zhz7FzbSjfmwW1TFD/DEFkRTQfpYfbbyGOwdlS/XccoR5gY1 BR+fhHSf0N7GB0RRHFxw359xXPCHI4vJLoN3J6suq3phetNDFE6Ew6ihEMp0pApdJCpl7FJj G+a4NRXU0zrEDHZF2sdcW4bRGIVZF3IiKCWqAoA+Jn9FP3WGZ754tKCgpVautZguinW3iqqD 01Xq4BvlFqt1/mgnK0RSSGt0pGDK8brWyOPwWODuJBBDybadbRL+6iQflTr77O3nVQa2DuO6 0wgZl+33siVVIwBHPRfmg7twis1V9dct7ya9nunD7S9xAHY3vOjoci9ZoGYZOo3SYaaM9QQp vumIzSGdwkHogvdpgccRj2YCsVpAGgNHvzw8FhCVgcjZx8Kjhu02CIqhLJyBY1i2vn5DUVag cqZTuVt6XI/yPA7XU4d4IVKXY+qxcn/8tBPA20Fa149jRCMfGNW4C4l8NXTPJNVbc9P2CWwr GWgyd6osWElnnLxdlEiWq10AAAAAAAA= --------------ms080405080609090001080005-- From owner-freebsd-arm@freebsd.org Fri May 12 19:31:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41942D6928F; Fri, 12 May 2017 19:31:42 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 182F078F; Fri, 12 May 2017 19:31:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v4CJVW2W079930 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 May 2017 12:31:33 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v4CJVWD6079929; Fri, 12 May 2017 12:31:32 -0700 (PDT) (envelope-from fbsd) Date: Fri, 12 May 2017 12:31:31 -0700 From: bob prohaska To: Mark Millard Cc: ports@freebsd.org, freebsd-arm Subject: Re: www/firefox on RPI2: error: instruction requires: armv6t2 Message-ID: <20170512193131.GA79348@www.zefox.net> References: <20170509230236.GA69546@www.zefox.net> <20170510151019.GA70628@www.zefox.net> <20170511033754.GA74153@www.zefox.net> <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> <80B1CCCF-A151-40B8-87D5-CADD513CFAAD@dsl-only.net> <20170512014441.GA77264@www.zefox.net> <85B88765-A708-414B-A465-14A044196D3D@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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, 12 May 2017 19:31:42 -0000 On Thu, May 11, 2017 at 08:14:14PM -0700, Mark Millard wrote: > Having -mcpu=cortex-a7 in ASFLAGS would contribute to > both of the examples. > Restarting the make with root@www:/usr/ports/www/firefox # make CFLAGS=-mcpu=cortex-a7 ASFLAGS=-mcpu=cortex-a7 -DBATCH > & make.log & made considerably more progress, but compilation still stopped with errors of the form /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armSP_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S:129:9: error: unknown directive /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armSP_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S:138:23: error: unexpected token in operand /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armSP_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S:152:14: error: invalid operand for instruction Make clean has been run and compilation started anew, using the same make command line, in the hope the mistake was one of consistency. Many thanks for your patience! bob prohaska From owner-freebsd-arm@freebsd.org Fri May 12 20:55: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 EF36AD6A5F6; Fri, 12 May 2017 20:55:19 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id A902110B5; Fri, 12 May 2017 20:55:19 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 2D10839AB; Fri, 12 May 2017 15:55:18 -0500 (CDT) From: Karl Denninger Subject: Re: Possible -HEAD problem with the Pi3 onboard ethernet To: freebsd-arm@freebsd.org, freebsd-net@freebsd.org References: Message-ID: Date: Fri, 12 May 2017 15:55:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060801010608080500020002" 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, 12 May 2017 20:55:20 -0000 This is a cryptographically signed message in MIME format. --------------ms060801010608080500020002 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Update: This MAY be caused by net.inet.tcp.rfc6675_pipe=3D1, which I had recently enabled since I am now moving data over WAN-style distances on a regular basis and since both ends are FreeBSD with this capability I figured it might help performance. If so it almost-certainly isn't ARM-specific...... I shut that off (it was recently turned on) and thus far I'm not able to recreate the network hangs.... Hmmmm... CCing into freebsd-net, as this is looking increasingly like a non-ARM-specific thing. Feel free to remove freebsd-arm from responses (in fact, probably ought to unless someone can confirm it's working properly on other architectures but not on ARM.) On 5/12/2017 12:45, Karl Denninger wrote: > Under fairly heavy stress (~50% of the 100Mbps possible FDX performance= ) > I've now run into a problem that is turning into something I can repeat= > without too much trouble by transmitting a large file through the devic= e. > > The system appears to "crash" from the outside. It's not dead, however= > -- it's got some sort of network buffer hang going on. This is a Pi3 > with current (-HEAD, FreeBSD 12.0-CURRENT #0 r318193M: Thu May 11 > 16:18:20 CDT 2017) software on it -- reverting to a mid-March kernel di= d > NOT change the behavior. > > The symptomology is that the unit will start printing this on the conso= le: > > May 12 12:25:46 IPGw dhcpd: send_packet: No buffer space available > May 12 12:25:46 IPGw dhcpd: dhcp.c:3974: Failed to send 300 byte long > packet over ue0.3 interface. > > ue0.3 is a VLAN for a private subnet and is not specific to the issue; > it also complains about no space on the primary too: > > May 12 12:27:06 IPGw dhcpd: dhcp.c:3974: Failed to send 300 byte long > packet over ue0 interface. > May 12 12:27:13 IPGw dhcpd: send_packet: No buffer space available > > netstat -m does /not /show any denied or delayed requests for network > buffers or mbuf exhaustion. Systat -vm shows plenty of RAM available > (roughly half.) > > An ifconfig ue0 down / ifconfig ue0 up sequence from the console clears= > the hang. > > Has anyone else seen anything similar to this? > --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060801010608080500020002 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MTIyMDU1MTdaME8GCSqGSIb3DQEJBDFCBEB4+LyX +vxtI/d3YaGSxcDauco95qq7i8orVtP1W276Mt4o1rCJDtltX5LWjmuZEuepZnz8y6jqJVpW y7RqEqLwMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAgYtoMKC/ZT0I VN2H65PkG/ds3QOLyGOpEQe8HIZOpi0eTMMHi41YtxhepgGvx/os8Xg8L15/IhG2nQVx69AK 3n+MP1f8MqdDAZKSf3ibQAO2C3FRbEPL9qo01VoIU+TOdQz31dlPnZ7o+bY3W3eCtrf5aQ9I ochAGYhdOmdrK4dsRd7mPtch5bgDlpFN5VNZXyt+4dd00tArOcRRqygcpSd+3AlN30ku7XCI yFmGOClG3+XnrKwjdXhk5BGWMhEprN+uRNPiSjPecDuOXhZBsngh4/lilPPtKvZz1P5bWIzD YD4KajCmUpdoSiXYVR2+RBLA/nTLOOlbO8pBxhzg+fE3nba8bEwoejQLYbzxdQ2SGQU7YAKU SdKcgICo4HWYjF0MNNtmWI+TnQjLiDwVNfI9Xay6WSXJkYLC6R+BuZGcL8Kkh/drvldt8AVs H1hOtcnsECCw5Zmk3mfjOFITHtAk0U3ATjhVExKA1se0oNqnzYLU89v/D/JT4zELUouORh47 Kkz2V/s4+ylJdwnLOa37WsAbqngdbzOi2Zva+kvFlTlz3chUql2YfMMVxkwXIdSEWKh0UPXB SbgKwQyPfSGANxnU2LL5KQPo7gE0nEGJoA83AjImOLAXKFlm7uR8oyzMqvVKidrBGBwqV2DN P2dGZf/0Fi8Ku/f09bwPTc0AAAAAAAA= --------------ms060801010608080500020002-- From owner-freebsd-arm@freebsd.org Fri May 12 21:04: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 740A2D6A8B8 for ; Fri, 12 May 2017 21:04:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F6631791 for ; Fri, 12 May 2017 21:04:49 +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 B610C26189F; Fri, 12 May 2017 23:04:40 +0200 (CEST) Subject: Re: Possible -HEAD problem with the Pi3 onboard ethernet To: Karl Denninger , "freebsd-arm@freebsd.org" References: From: Hans Petter Selasky Message-ID: Date: Fri, 12 May 2017 23:02:43 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.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: Fri, 12 May 2017 21:04:50 -0000 On 05/12/17 19:45, Karl Denninger wrote: > Under fairly heavy stress (~50% of the 100Mbps possible FDX performance) > I've now run into a problem that is turning into something I can repeat > without too much trouble by transmitting a large file through the device. > > The system appears to "crash" from the outside. It's not dead, however > -- it's got some sort of network buffer hang going on. This is a Pi3 > with current (-HEAD, FreeBSD 12.0-CURRENT #0 r318193M: Thu May 11 > 16:18:20 CDT 2017) software on it -- reverting to a mid-March kernel did > NOT change the behavior. > > The symptomology is that the unit will start printing this on the console: > > May 12 12:25:46 IPGw dhcpd: send_packet: No buffer space available > May 12 12:25:46 IPGw dhcpd: dhcp.c:3974: Failed to send 300 byte long > packet over ue0.3 interface. > > ue0.3 is a VLAN for a private subnet and is not specific to the issue; > it also complains about no space on the primary too: > > May 12 12:27:06 IPGw dhcpd: dhcp.c:3974: Failed to send 300 byte long > packet over ue0 interface. > May 12 12:27:13 IPGw dhcpd: send_packet: No buffer space available > > netstat -m does /not /show any denied or delayed requests for network > buffers or mbuf exhaustion. Systat -vm shows plenty of RAM available > (roughly half.) > > An ifconfig ue0 down / ifconfig ue0 up sequence from the console clears > the hang. > > Has anyone else seen anything similar to this? > Hi, It might be a bug in the USB network driver for the RPI. You can try to run usbdump on ugenX.Y for the network interface. usbdump -i usbusX -f Y And see what is going on. --HPS From owner-freebsd-arm@freebsd.org Fri May 12 21:36:57 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB56FD693EF for ; Fri, 12 May 2017 21:36:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-6.reflexion.net [208.70.210.6]) (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 6B7D4AF8 for ; Fri, 12 May 2017 21:36:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25180 invoked from network); 12 May 2017 21:36:50 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 May 2017 21:36:50 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 12 May 2017 17:36:50 -0400 (EDT) Received: (qmail 11179 invoked from network); 12 May 2017 21:36:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 May 2017 21:36:50 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5787BEC8697; Fri, 12 May 2017 14:36:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: www/firefox on RPI2: error: instruction requires: armv6t2 From: Mark Millard In-Reply-To: <20170512193131.GA79348@www.zefox.net> Date: Fri, 12 May 2017 14:36:48 -0700 Cc: ports@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170509230236.GA69546@www.zefox.net> <20170510151019.GA70628@www.zefox.net> <20170511033754.GA74153@www.zefox.net> <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> <80B1CCCF-A151-40B8-87D5-CADD513CFAAD@dsl-only.net> <20170512014441.GA77264@www.zefox.net> <85B88765-A708-414B-A465-14A044196D3D@dsl-only.net> <20170512193131.GA79348@www.zefox.net> To: bob prohaska 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, 12 May 2017 21:36:57 -0000 On 2017-May-12, at 12:31 PM, bob prohaska wrote: > On Thu, May 11, 2017 at 08:14:14PM -0700, Mark Millard wrote: >> Having -mcpu=3Dcortex-a7 in ASFLAGS would contribute to >> both of the examples. >>=20 >=20 > Restarting the make with > root@www:/usr/ports/www/firefox # make CFLAGS=3D-mcpu=3Dcortex-a7 = ASFLAGS=3D-mcpu=3Dcortex-a7 -DBATCH > & make.log & Again the commands might be handy, although in this case the source code being assembled looks more interesting. > made considerably more progress, but compilation still stopped with = errors > of the form > = /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armS= P_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S:129:9: error: unknown = directive Looking on the web the line 129 appears to be: .macro FFTSTAGE scaled, inverse, name It looks like /usr/bin/cc 's processing of .S assembler notation does not support .macro (or the later .endm I suppose). This may mean that AS needs to be replaced so that $(AS) picks a tool that has the support of the syntax. Or may be cc needs use of -B to pick up some specific toolchain's utilities that handle the .macro and its use. > = /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armS= P_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S:138:23: error: = unexpected token in operand This one looks to be for a line that looks like: VMOV half, 0.5 where the earlier line 121 had: #define half D13.F32 The normal form of this instruction might be something like: VMOV.F32 D13, #0.5 that encodes the element type/size in the instruction, instead of in the operand. I'm not sure. Also the immediate value might need a # prefix. But such claims may be tied to the parser in the specific assembler-processing that ends up involved. I do not know how standardized the assembler notation(s) are for the context. > = /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armS= P_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S:152:14: error: invalid = operand for instruction This one looks to be for a line looking like: VLD1 dX0,[pSrc],step where prior lines had: #define pSrc r0 . . . #define step r8 . . . #define dX0 D0.F32 The normal form of this instruction might be something like: VLD1.32 D0,[r0],r8 that encodes the element type/size in the instruction (with the interleave pattern: 1) instead of in the operand. I'm not sure. But such claims may be tied to the parser in the specific assembler-processing that ends up involved. I do not know how standardized the assembler notation(s) are for the context. > Make clean has been run and compilation started anew, using the same = make > command line, in the hope the mistake was one of consistency. My guess from the above is that the problem will repeat in this rebuild. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat May 13 00:34:33 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 9887AD692BC; Sat, 13 May 2017 00:34:33 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 71621C3; Sat, 13 May 2017 00:34:33 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v4D0YVv0080897 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 May 2017 17:34:32 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v4D0YVOT080896; Fri, 12 May 2017 17:34:31 -0700 (PDT) (envelope-from fbsd) Date: Fri, 12 May 2017 17:34:31 -0700 From: bob prohaska To: Mark Millard Cc: ports@freebsd.org, freebsd-arm Subject: Re: www/firefox on RPI2: error: instruction requires: armv6t2 Message-ID: <20170513003431.GA80523@www.zefox.net> References: <20170510151019.GA70628@www.zefox.net> <20170511033754.GA74153@www.zefox.net> <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> <80B1CCCF-A151-40B8-87D5-CADD513CFAAD@dsl-only.net> <20170512014441.GA77264@www.zefox.net> <85B88765-A708-414B-A465-14A044196D3D@dsl-only.net> <20170512193131.GA79348@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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, 13 May 2017 00:34:33 -0000 On Fri, May 12, 2017 at 02:36:48PM -0700, Mark Millard wrote: > > My guess from the above is that the problem will > repeat in this rebuild. > > > That's exactly what happened. A copy of make.log and armSP_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S can be found at http://www.zefox.net/~fbsd/rpi2/firefox/assembler_failure/ It happens that make.log records a number of errors in the configuration phase of compilation. The errors don't seem fatal: Error processing command. Ignoring because optional. (optional:setup.py:python/psutil:build_ext:--inplace) Could they be in some way related to the assembler problem? If other files would be informative I'll gladly post them. Thanks.... bob prohaska From owner-freebsd-arm@freebsd.org Sat May 13 02:00: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 C65B5D6A9B4 for ; Sat, 13 May 2017 02:00:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-7.reflexion.net [208.70.210.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88FB21AD9 for ; Sat, 13 May 2017 02:00:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15608 invoked from network); 13 May 2017 02:03:32 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 May 2017 02:03:32 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 12 May 2017 22:00:04 -0400 (EDT) Received: (qmail 4912 invoked from network); 13 May 2017 02:00:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 May 2017 02:00:04 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A8633EC92B8; Fri, 12 May 2017 19:00:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: www/firefox on RPI2: error: instruction requires: armv6t2 From: Mark Millard In-Reply-To: <20170513003431.GA80523@www.zefox.net> Date: Fri, 12 May 2017 19:00:03 -0700 Cc: ports@freebsd.org, freebsd-arm , jbeich@freebsd.org, Michal Meloun Content-Transfer-Encoding: quoted-printable Message-Id: <6B792DA2-85F3-4504-8325-D65DB23ECD68@dsl-only.net> References: <20170510151019.GA70628@www.zefox.net> <20170511033754.GA74153@www.zefox.net> <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> <80B1CCCF-A151-40B8-87D5-CADD513CFAAD@dsl-only.net> <20170512014441.GA77264@www.zefox.net> <85B88765-A708-414B-A465-14A044196D3D@dsl-only.net> <20170512193131.GA79348@www.zefox.net> <20170513003431.GA80523@www.zefox.net> To: bob prohaska 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, 13 May 2017 02:00:06 -0000 On 2017-May-12, at 5:34 PM, bob prohaska wrote: > On Fri, May 12, 2017 at 02:36:48PM -0700, Mark Millard wrote: >>=20 >> My guess from the above is that the problem will >> repeat in this rebuild. >>=20 >>=20 >>=20 > That's exactly what happened. A copy of make.log and =20 >=20 > armSP_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S >=20 > can be found at >=20 > http://www.zefox.net/~fbsd/rpi2/firefox/assembler_failure/ Your source is different than what I looked at. Yours has capitalized .MACRO instead of having a .macro as the assembler directive: .MACRO FFTSTAGE scaled, inverse, name and that might make a difference for the specific error. I have vague memories of seeing some other list report that involved lower-casing an assembler directive. Jan Beich had a list reply that showed changes to have lower case for such for clang in multiple files: = https://android.googlesource.com/platform/external/chromium_org/third_part= y/openmax_dl/+/5d8507771824%5E%21/ Apparently what is in ports predates such changes. (There may be other things that it predates as well.) Nor does it seem to patch such things. The error messages with "\name" involved seem to be tied to not recognizing .MACRO and .endm (macro directives) and so not doing name substitution from the macro directive's arguments. Most everything else listed as an error in that area looks to be assembler notation mismatches. I've no clue what assembler might accept the notation that is in use. If you change assemblers other things may need to change, such as -mcpu=3Dcorex-a7 might not be the right option syntax for the purpose any more (just for the assembler). > It happens that make.log records a number of errors in the > configuration phase of compilation. The errors don't seem fatal:=20 >=20 > Error processing command. Ignoring because optional. = (optional:setup.py:python/psutil:build_ext:--inplace) >=20 > Could they be in some way related to the assembler problem? I've no real clue but would guess not. > If other files would be informative I'll gladly post them. I'm running out of things that my generic background knowledge covers. Michal Meloun had a reply that mentioned: "many pieces of assembly files still uses pre-UAL syntax" and so may know more about the context than I do. Looking it up UAL seems to be short for "Unified Assembler Language". Apparently pre-UAL does not support 32-bit Thumb Instructions. Jan B. had written: so the following wouldn't help? Index: Mk/bsd.gecko.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Mk/bsd.gecko.mk (revision 440464) +++ Mk/bsd.gecko.mk (working copy) @@ -475,6 +475,10 @@ USE_BINUTILS=3D # intel-gcm.s CFLAGS+=3D -B${LOCALBASE}/bin LDFLAGS+=3D -B${LOCALBASE}/bin . endif +.elif ${ARCH:Marm*} +USE_BINUTILS=3D # media/openmax_dl/ +MOZ_EXPORT+=3D ASFLAGS=3D"${ASFLAGS}" +ASFLAGS+=3D -B${LOCALBASE}/bin .elif ${ARCH:Mpowerpc*} USES:=3D compiler:gcc-c++11-lib ${USES:Ncompiler*c++11*} . if ${ARCH} =3D=3D "powerpc64" That would appear to try to use the assembler from devel/binutils if I gather the intent correctly. It is (implicitly) a reference to /usr/ports/Mk/bsd.gecko.mk (presuming the usual default place for the ports source code tree). Both the Jan B. and the Michal M. quotes are visible in: https://lists.freebsd.org/pipermail/freebsd-ports/2017-May/108511.html There is more there than I've referenced above. May be Jan B. or Michal M. know some about what tool(s) handle such "pre-UAL" syntax and how to use such tools. =3D=3D=3D Mark Millard markmi at dsl-only.net